We Keep Coding

Embed Python code in Verilog file in Emacs

I am working on a project whereby I need to embed Python within a Verilog file. The Python isn't really intended for execution in the normal sense as it will be read by a secondary tool. The Python will be written blocks that have some fixed demarcation (such as #+BEGIN_SRC, in org-babel).
module name ();
#+BEGIN_SRC python
def my_function ():
...
#+END_SRC
always #(posedge clk)
...
endmodule
Within Emacs this causes havoc, although Python-mode and Verilog-mode work fine, when combining both in the same file things quickly break-down as one would expect. Indentation is hopelessly broken as is syntax-highlighting. I understand this is a very weird thing to do, and I understand that there will almost certainly never been any real need to do this under normal circumstances, however for this particular case it is necessary.
My question: is there anyway within Emacs to specify multiple major modes within the same file. For example, is there some way that I can write a file using Verilog-mode as my major mode, but use Python-mode within the predefined blocks that are then ignored in the reset of the file.

There are a number of possibilities listed here:
http://emacswiki.org/emacs/MultipleModes
I've used multi-mode with latex and haskell, and it works OK.

Python: how to batch rename mixed case to lower case with underscores

I've written a fair bit of my first significant Python script. I just finished reading PEP 8, and I learned that lower_case_with_underscores is preferred for instance variable names. I've been using mixedCase for variable names throughout, and I'd like my code to be make more Pythonic by changing those to lower_case_with_underscores if that's how we do things around here.
I could probably write some script that searches for mixedCase and tries to smartly replace it, but before I potentially reinvent the wheel, my question is whether a solution for that already exists, either within a Python-savvy editor or as a standalone application; or whether there's another approach that would accomplish the task of converting all mixedCase variable names to lower_case_with_underscores. I have searched a fair bit for a solution but didn't turn up anything. Any technique that specifically would yield this result would be appreciated.

I was able to accomplish what I wanted using GNU sed:
sed -i -e :loop -re 's/(^|[^A-Za-z_])([a-z0-9_]+)([A-Z])([A-Za-z0-9_]*)'\
'([^A-Za-z0-9_]|$)/\1\2_\l\3\4\5/' -e 't loop' myFile.py
It finds every instance of mixedCase -- but not CapitalWords, so class names are left intact -- and replaces it with lower_case_with_underscores; e.g. myVariable becomes my_variable, but MyClass remains MyClass.
(On an unrelated note, now that I've done it, I think I prefer the appearance of mixedCase over lower_case_with_underscores. The appearance of so many underscores all over my code is weird. But I'll do things the Python Way and see if I get used to it, particularly if I intend for my code to be seen or worked with by others; or maybe I'll do it the way I like and I've now got a simple way of converting it to the PEP 8 way if I intend to make the code public.)

How do I use multiple .mo files simultaneously for gettext translation?

In short, can I use in python many .mo files for the same language in the same time?
In my python application, I need to use gettext for I18N. This app uses kind of a plug-in system. This means you can download a plug-in and put it in the appropriate directory, and it runs like any other python package. The main application stores the .mo file it uses in let's say ./locale/en/LC_MESSAGES/main.mo. And the plug-in nr 1 has its own .mo file called plugin1.mo in that same directory.
I would use this to load the main.mo I18N messages:
gettext.install('main', './locale', unicode=False)
How can I install the others too, so that all the plug-ins are translated the way they should be?
The solutions I thought of:
Should I gettext.install() in each package's namespace? But this would override the _() defined previously and mess the future translations of the main application.
Is there a way to combine two .mo files in one (when a new plug-in is installed for example)?
At runtime can I combine them into one GNUTranslation object? Or override the default _() method that is added to the global namespace? Then, how would I go with that option?
Instead of _('Hello World'), I would use _('plugin1', 'Hello World in plug-in 1')
Note: The application is not supposed to be aware of all the plug-ins to be installed, so it cannot already have all the messages translated in its main.mo file.

gettext.install() installs the inalterable one and only _ into the builtins (module __builtin__ or builtins in py3) - app-global. This way there is no flexibility.
Note: Python name resolution order is: locals > module-globals > builtins .
So anyway gettext.translation() (Class-based API) or even gettext.GNUTranslations() (e.g. for custom .mo path schemes) would be used explicitely for having multiple translations separately or mixed-style at the same time.
Some options:
Via t = gettext.translation(...); _ = t.ugettext you could simply put separate translations as _ into each module-global namespace - probably more automated way in real world. Just perhaps the main translation could still go into the builtins too (via main_t.install()).
When a mix-all of all/many translations is ok or is what you want, you could chain several translations globally via t.install(); t.add_fallback(t_plugin1); t.add_fallback(t_plugin1);...; - and preserve an app-global approach otherwise.
gettext keywords other than _ could be used - and could be feed via the xgettext -k other_keyword option. But I'd dislike lengthy and module-unique names.
( Yet personally I prefer the keyword I generally over _, and I also enable an operator scheme like I % "some text" instead of _("some text") or I("some text"). Via I = t; t.__call__ = t.__mod__ = t.ugettext effectively; plus a small patch of pygettext.py. This pattern is more pleasant for typing, looks more readable and Pythonic to me, and avoids the crucial/ugly name collision of _ in Python with the interactive-last-result-anaphor (see sys.displayhook) when using gettext'ed modules on interactive Python prompts. _ is also "reserved" as my preferred (local) placeholder for unused values in expressions like _, _, x, y, z, _ = some_tuple.
After all gettext is a rather simple module & mechanism, and things are easily customizable in Python.)

You should use different domains for each plugin. The domain can be package name to prevent conflicts.
I do not understand why you need to translate something outside the plugin by using plugin's domain, but if you really need to, then you should disambiguate the domain each time.
Each plugin can provide it's own "undescore", readily bound to the plugin's domain:
from my.plugin import MessageFactory as _my_plugin
Please, note, that underscore is only a convention so the extraction tools can find i18n-enabled messages in the program. Plugins' messages should be marked with underscore in their respective packages (you do put them into separate packages, right?). In all other places, you are free to call these factories by some other name and leave underscore for the main program translation domain.
I am less sure about .mo-files, but you can surely compile all your .po files into one .mo file. However, if plugins are written by independent uncooperative authors, there could be msgid conflicts.
UPDATE:
If plugins are in the same package with the main app, then there is no sense in using individual translation domains for them (this is not your case). If plugins are in the separate packages, then extraction should be done independently for those packages. In both cases you have no problem with variable _. If for some reason main app wants plugins' translations in its code, use some other name for _, as in the answer. Of course, extraction tools will not identify anything but underscore.
In other words, plugins should care about their translations on their own. The main app could use plugin-specific translation function as part of plug-in API. Extraction or manual addition of strings into po/mo-files are also not of concern for the main app: its up to plugin author to provide translations.

python: naming a module that has a two-word name

I'm trying to put together a really simple module with one .py source file in it, and have already run into a roadblock. I was going to call it scons-config but import scons-config doesn't work in Python. I found this SO question and looked at PEP8 style guide but am kind of bewildered, it doesn't talk about two-word-name conventions.
What's the right way to deal with this?
module name: SconsConfig? scons_config? sconsconfig? scons.config?
name of the single .py file in it: scons-config.py? scons_config.py?
edit: I did see "the use of underscores is discouraged" and that left me at a dead end: should I use "sconsconfig" or "scons_config" (I guess the other ones are out)?

If you have to, always use underscores _.
Using a dot . would not even work, otherwise
from scons.config import whatever
would break.
But PEP 8 clearly describes it:
Package and Module Names
Modules should have short, all-lowercase names. Underscores can be used
in the module name if it improves readability. Python packages should
also have short, all-lowercase names, although the use of underscores is
discouraged.
UPDATE:
To directly target your question: I think sconsconfig is fine. It is not too long and quite readable.
But honestly, I don't think anyone will blame you if you use underscores and your code will run with either decision. There is always a certain level where you should not care that much anymore.

First, the module name is the same as the name of the single .py file. In Python-speak, a collection of several .py files is a package.
PEP-8 discourages breaking up package names with underscores. A quick peak at my site-packages directory shows that multiword names are commonly just run together (e.g., setuptools, sqlalchemy)
Module names (that is, file names) may be broken up by underscores (and I usually do this, because I hate namesthatruntogethersoyoucanhardlyreadthem).
Stick with lower-case only (per PEP-8). This avoids problems when going from case-sensitive to case-insensitive filesystems and vice versa.

Aside from PEP-8, you can also check out how the native Python modules deal with this issue.
If you were to compare the native modules of Python 2 to that of Python 3, you would see that the new tendency with the official devs is to avoid uppercase and underscores. For example, ConfigParser in Python 2 becomes configparser in Python 3.
Looking at this, the best course of action would be to avoid uppercase and underscores, and just join the words together, i.e. sconsconfig.

- is a no go. The symbol is used for minus operator. The same is true in most programming languages. Use _ or otherwise nothing at all.

The origin of using # as a comment in Python?

So I just had like this mental explosion dude! I was looking at my Python source code and was reading some comments and then I looked a the comments again. When I came across this:
#!/usr/bin/env python
# A regular comment
Which made me wonder, was # chosen as the symbol to start a comment because it would allow the python program to be invoked in a shell, like so:
./test.py
and then be ignored once the python interpreter was running?

Yes.
Using # to start a comment is a convention followed by every major interpreted language designed to work on POSIX systems (i.e. not Windows).
It also dovetails nicely with the fact that the sequence "#!" at the beginning of a file is recognized by the OS to mean "run the command on this line" when you try to run the script file itself.
But mostly, it's the commonly accepted convention. If python didn't use # to start a comment, it would confuse a lot of people.
EDIT
Using "#" as a comment marker apparently pre-dates the "#!" hash-bang notation. "#!" was introduced by Dennis Ritchie betwen Unix 7 and 8, while languages that support # as a comment marker existed earlier. For example, the Bourne shell was already the default when Version 7 Unix was introduced.
Therefore, the convention of using "#" as a comment marker probably influenced the choice of "#!" as the command line marker, and not the other way around.

Using # for comments was happening before Python came around. The shebang (#!/usr/bin/env python) convention is almost as old as UNIX itself. The two are intertwined for many interpreted (aka shell) languages.
Might as well study up on the history of the shebang!

"All the rest of the line after character X" is clearly the handiest way to do comments if you have an X available (C++ had to use two characters, //, for the purpose, to offer an alternative to C's clunky PL/I-inspired '/' ... '/' "brackets").
Almost all printable Ascii characters can be used for other purposes in Python -- if the choice is between # and ?, with the first already being familiar from its use in sh, bash, tcl, perl, awk, ... -- it's not a very hard choice, is it? The handiness of hashbang is just a vig.

Very good, you are correct.
This is known as the shebang or hash-bang. I suppose a scripting language could use any comment character it liked and allow #! on the first line as a comment, but it does seem easier to just make # be the comment character...