We Keep Coding

Using a Python Script in My Hype 3 Build

I have a Python script that I would like to run in my Hype 3 build. The script takes an input (several) and outputs an answer based on on the input (but that’s handled in the script) how I could do that?

Tumult Hype’s Export Scripts infrastructure allows code to be run upon export and/or preview. This can be python code, in fact the sample scripts we have are all in Python.
General info: https://tumult.com/hype/export-scripts/
Developer docs & code: https://github.com/tumult/hype-export-scripts/
With this, you can arbitrarily modify Hype’s output however you see fit.
You’ll get a new File > Export as HTML5 > … menu item; this allows choosing a location to save. I don’t think there’s any way to bypass the save dialog at this point. You probably just ignore it. (Though I guess you could also be clever and have a Preview stick your document wherever you want, since previewing doesn’t have a prompt).

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.

Workflow with multiple files using a REPL (Python)

My general workflow is using 2 screens; 1 for the script, 1 for the interactive buffer. I then evaluate parts of the script code in the interactive buffer. This is really nice when working with a small project (I just reevaluate the code I changed at that moment, everything else equal). It allows for (I'm convinced) the fastest iterations in writing a script.
However, I'm now working on a project where I try to be neat and organize my project with a single class per file (or close to it).
Now here lies the issue: While it is easy to evaluate parts of code, in Python it is difficult to import modules once they have already been imported.
Mind that I most of the time have useful objects in the interactive buffer / global scope (perhaps some objects took 10 minutes to be built). This means that I can't just close & reopen everything.
Are others struggling with this as well? How to conveniently work with multiple files and a Python REPL?

Using the brilliant elpy package allows this from the latest release (available on MELPA).
You can assign a dedicated REPL to each script as you like. It helps to rename the REPL sessions using M-x rename-buffer.
Here is a snippet from the relevant documentation:
M-x elpy-shell-toggle-dedicated-shell
By default, python buffers are all attached to a same python shell (that lies in the Python buffer), meaning that all buffers and code
fragments will be send to this shell.
elpy-shell-toggle-dedicated-shell attaches a dedicated python shell
(not shared with the other python buffers) to the current python
buffer. To make this the default behavior (like the deprecated option
elpy-dedicated-shells did), use the following snippet:
(add-hook 'elpy-mode-hook (lambda () (elpy-shell-toggle-dedicated-shell 1)))
M-x elpy-shell-set-local-shell
Attach the current python buffer to a specific python shell (whose name is asked with completion). You can use this function to have one
python shell per project, with:
(add-hook 'elpy-mode-hook (lambda () (elpy-shell-set-local-shell elpy-project-root)))
Here is the relevant GitHub issue, which was merged into the master branch on 16th Feb 2018.

PyCharm "Run configuration" asking for "script parameters"

While writing an application parsing command line arguments I would like to run it with various parameters.
I don't want to create a Run Configuration for every possible command line argument that I want my script to test with. Is there a way in PyCharm (and I guess with any JetBrains IDE) to make a Run Configuration that asks for the Script parameters when executed?
I am currently using PyCharm 3.1 (EAP).

Currently the only possibility is to use the "Before launch | Show this page" option.

I've found today that now is possible to ask for parameters using the "Prompt" macro on the "Run configuration" parameters field.
https://www.jetbrains.com/help/pycharm/code-running-assistance-tutorial.html#parameter-with-macros

Although yole's answer is the de facto way to be prompted for thw arguments before running a program, it is slightly annoying because:
the dialog is visually overwhelming and cluttered instead of focused on what you want to do;
you have to tab to reach the arguments field if you want to use the keyboard exclusively (and why not?);
Nothing you could do about that. (Except maybe file a ticket. Have you done that?)
I'm just adding what I used to do before I knew about Googled for this option for the sake of completeness (obvously, this is a hack in the least glamorous sense of the term). But it did suit my workflow as I often only had discrete lines to test with, and didn't switch that often.
Create a new configuration set to the same file, but with a special 'magic' parameter;
Add code to your script to check if the magic is there;
Use a string variable instead of sys.argv (pass it through lambda args: [__name__] + args.split() to reduce the boilerplate);
???
Profit;

I'm doing this on a Mac, but hopefully this will be helpful for Windows or Linux.
Go to Run > Edit Configurations
There will be a dialog box that opens.
Script: file you want to run (ending with .py)
Script Parameters: the command line arguments
Working Directory: directory where your project is.

My simple answer is adding another wrapper as the cover in the source code which will run on the selection you made through code branch or external command or file, so choosing different branch is just a 'ddp' tap distance in vim(line change for parameter settings). You dont have to depend on pycharm updating by building your own code world:)

Switching from python-mode.el to python.el

I recently tried switching from using python-mode.el to python.el for editing python files in emacs, found the experience a little alien and unproductive, and scurried back. I've been using python-mode.el for something like ten years, so perhaps I'm a little set in my ways. I'd be interested in hearing from anyone who's carefully evaluated the two modes, in particular of the pros and cons they perceive of each and how their work generally interacts with the features specific to python.el.
The two major issues for me with python.el were
Each buffer visiting a python file gets its own inferior interactive python shell. I am used to doing development in one interactive shell and sharing data between python files. (Might seem like bad practice from a software-engineering perspective, but I'm usually working with huge datasets which take a while to load into memory.)
The skeleton-mode support in python.el, which seemed absolutely gratuitous (python's syntax makes such automation unnecessary) and badly designed (for instance, it has no knowledge of "for" loop generator expressions or "<expr 1> if <cond> else <expr 2>" expressions, so you have to go back and remove the colons it helpfully inserts after insisting that you enter the expression clauses in the minibuffer.) I couldn't figure out how to turn it off. There was a python.el variable which claimed to control this, but it didn't seem to work. It could be that the version of python.el I was using was broken (it came from the debian emacs-snapshot package) so if anyone knows of an up-to-date version of it, I'd like to hear about it. (I had the same problem with the version in CVS emacs as of approximately two weeks ago.)

For what it's worth, I do not see the behavior you are seeing in issue #1, "Each buffer visiting a python file gets its own inferior interactive python shell."
This is what I did using python.el from Emacs 22.2.
C-x C-f foo.py
[insert: print "foo"]
C-x C-f bar.py
[insert: print "bar"]
C-c C-z [*Python* buffer appears]
C-x o
C-c C-l RET ["bar" is printed in *Python*]
C-x b foo.py RET
C-c C-l RET ["foo" is printed in the same *Python* buffer]
Therefore the two files are sharing the same inferior python shell. Perhaps there is some unforeseen interaction between your personal customizations of python-mode and the default behaviors of python.el. Have you tried using python.el without your .emacs customizations and checking if it behaves the same way?
The major feature addition of python.el over python-mode is the symbol completion function python-complete-symbol. You can add something like this
(define-key inferior-python-mode-map "\C-c\t" 'python-complete-symbol)
Then typing
>>> import os
>>> os.f[C-c TAB]
you'll get a *Completions* buffer containing
Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
os.fchdir os.fdatasync
os.fdopen os.fork
os.forkpty os.fpathconf
os.fstat os.fstatvfs
os.fsync os.ftruncate
It'll work in .py file buffers too.

I can't reproduce this behavior on Emacs v23.1, this must have been changed since then.
Forget about any mode's skeleton support and use the hyper-advanced and extensible yasnippet instead, it's really worth a try!

Note nearly everything said here is obsolete meanwhile as things changed.
python-mode.el commands are prefixed "py-" basically, you should be able to use commands from both, nonewithstanding which one was loaded first.
python-mode.el does not unload python.el; beside of python-mode-map, which is re-defined.
The diff is in the menu displayed and keysetting however, the last one loaded will determine.

python-mode.el is written by the Python community. python.el is written by the emacs community. I've used python-mode.el for as long as I can remember and python.el doesn't even come close to the standards of python-mode.el. I trust the Python community better than the Emacs community to come up with a decent mode file. Just stick with python-mode.el, is there really a reason not to?

python-mode.el has no support triple-quoted strings, so if your program contains long docstrings, all the syntax coloring (and associated syntaxic features) tends to break down.
my .02

Debian has deleted the python-mode package, alas, so I felt compelled to try python.el. I loaded it and ran "describe-bindings". It appeared to be designed for elisp coders who think c-X ; is the intuitive binding for commenting a line of Python code. (Wow.) Also, I found no way at all to comment a region of code, or, rather, no binding with the strings "region" and "comment" in it.
Good old python-mode can still be cloned via git clone https://gitlab.com/python-mode-devs/python-mode.git. It was last edited a week ago at this writing, so it's safe to assume it's not abandoned.