In short
How to force python interpreter to load the most up-to-date code version of my module everytime I make some changes in the module code?
Or at least reload the last modified version by typing
>>> from myModule import *
into console, without necessity to restart whole python console and setup everything again and again anytime I make some changes? This is extremely unpleasant behavior for debugging.
--------- LONGER STORY -----------
I tried to delete the .pyc file, and import it again - but it has no effect. It does't even create .pyc file again - so I expect it completely ignore my "import" command if the module is already loaded.
this also does not help:
>>> mymodule.myfunc() # the old version
>>> del myModule # unload mymodle from python conole / interpeter
... # now I removed .pyc
... # now I make some modifications in mymodule.myfunc() code
>>> mymodule.myfunc() # module is unknonwn, ... OK
>>> import myModule # try to load modified version
>>> mymodule.myfunc() # stil the old version :(((((, How it can remember?
I have tried also Spyder where is this feature called "User Module Deleter (UMD)"
http://pythonhosted.org/spyder/console.html#reloading-modules-the-user-module-deleter-umd
which I thought should do exactly this, but it seem it doesn't (Yes, I checked that it is turned on).
Maybe I'm missing something - can somebody explain me how is it supposed to be used?
Is this somehow affected by the fact that the imported module is not in "Working directory" but in PYTHONPATH ?
(Spyder dev here) I think at the moment you are not able to reload a module directly in the console (but we are considering to change this in the future).
The idea about UMD is that it will reload your modules but only if you run a file from the editor that imports them. It doesn't work if you want to reload them directly in the console.
Let's say you developed a module, then you are probably using it in a different script that (most likely) you'll be writing in our editor and send it to run to our console. UMD is a little bit of magic that reloads it for you when that happens.
Maybe useful for others. In Spyder 3.0.0, the modules can be reloaded by,
Tools -> Update modules names list.
It worked for me.
Related
I have this problematic import.
import * as Collection from '../../lib/collection.js'
root
> lib
>> collection.js
> tests
>> folder1
>>> collection.spec.js
how can resolve this relative path with something like
import * as Collection from '#/lib/collection.js'
OR
import * as Collection from 'lib/collection.js'
tried both. neither worked.
any ideas?
I’m not sure what you mean when you say “problematic”, as that import looks correct/like it should work fine. Is it not working for you?
If your concern is that you’d rather avoid having to go up directories with ../ leading to the two options you tried, and you’re trying to get something like that to work, that’s addressed better than I could elsewhere such as this accepted answer about what # does and the others. Short answers:
lib/collection.js isn’t relative, and would refer to a package (see also Node’s doc on import specifiers
#/lib/collection.js isn’t a natively supported JavaScript syntax and requires a module loader/bundler, but should work once set up.
So I've been trying to get electron working with Perl6 and looks like after all my efforts of hacking things to get them to work, it just doesn't want to do it's thing. I have used the following script (one of the examples from the electron repo on git):
#!/usr/bin/env perl6
use v6;
use Electron;
my $app = Electron::App.instance;
LEAVE {
$app.destroy if $app.defined;
}
say Electron::Dialog.show-open-dialog.perl;
say Electron::Dialog.show-save-dialog.perl;
say Electron::Dialog.show-message-box.perl;
Electron::Dialog.show-error-box("Text", "Content");
prompt("Press any key to exit");
On Running I get this error:
Dynamic variable #*INC not found
in submethod initialize at C:\rakudo\share\perl6\site\sources\42D84B59BC3C5A414EA59CC2E3BC466BBAF78CDA line 54
in method instance at C:\rakudo\share\perl6\site\sources\42D84B59BC3C5A414EA59CC2E3BC466BBAF78CDA line 33
in block <unit> at test.p6 line 9
Actually thrown at:
in method throw at C:\rakudo/share/perl6/runtime/CORE.setting.moarvm line 1
in block at C:\rakudo\share\perl6\site\sources\42D84B59BC3C5A414EA59CC2E3BC466BBAF78CDA line 55
in submethod initialize at C:\rakudo\share\perl6\site\sources\42D84B59BC3C5A414EA59CC2E3BC466BBAF78CDA line 48
in method instance at C:\rakudo\share\perl6\site\sources\42D84B59BC3C5A414EA59CC2E3BC466BBAF78CDA line 33
in block <unit> at test.p6 line 9
And after looking at the submethod i noticed that this was part of the electron module for perl6 and it seems to not like the use of #*INC within the module.
Has anyone managed to successfully use the electron module with Perl6? Has anyone else come across this error? Is there an easy way around it?
I can probably modify the module to get it to compile and run but I wouldn't know where to start with replacing the #*INC.
$*REPO is the 6.c replacement for #INC in Perl 5
In Perl 5 the #INC variable is a global array of paths to be searched when Perl is looking for modules (analogous to the PATH variable used by many OSes to contain the paths to be searched when that OS is looking for programs).
Until recently Perl 6 had a corresponding #*INC variable.
Having an array for this turned out to be inappropriate for 6.c given concurrent module loading and advanced module selection features introduced by the Perl 6 module repository mechanism.
About a month or two before 6.c a lead dev (Stefan Seifert aka nine) switched module loading to use a chained repo approach via a new $*REPO scalar and obsoleted the include array.
For various reasons they did this without a deprecation period.
Any pre 6.c modules that directly mention #*INC need an update and some haven't yet gotten that update. The Electron module was one such -- until you filed an issue (thanks!) and the module's author responded by fixing it.
I'm not aware of any "official" design or enduser documentation of $*REPO. The best info is probably to be found by asking user nine on the freenode IRC channel #perl6-toolchain (logs; join).
I'm trying to internationalize / translate a python app that is implemented as a wx.App(). I have things working for the most part -- I see translations in the right places. But there's a show-stopper bug: crashing at hard-to-predict times with errors like:
Traceback: ...
self.SetStatusText(_('text to be translated here'))
TypeError: 'numpy.ndarray' object is not callable
I suspect that one or more of the app's dependencies (there are quite a few) is clobbering the global translation function, _( ). One likely way would be doing so by using _ as the name of a dummy var when unpacking a tuple (which is fairly widespread practice). I made sure its not my app that is doing this, so I suspect its a dependency that is. Is there some way to "defend" against this, or otherwise deal with the issue?
I suspect this is a common situation, and so people have worked out how to handle it properly. Otherwise, I'll go with something like using a nonstandard name, such as _translate, instead of _. I think this would work, but be more verbose and a little harder to read., e.e.,
From the above I can not see what is going wrong.
Don't have issues with I18N in my wxPython application I do use matplotlib and numpy in it (not extensive).
Can you give the full traceback and/or a small runnable sample which shows the problem.
BTW, have you seen this page in the wxPython Phoenix doc which gives some other references at the end.
wxpython.org/Phoenix/docs/html/internationalization.html
Aha, if Translate works then you run into the issue of Python stealing "", you can workaround that by doing this:
Install a custom displayhook to keep Python from setting the global _ (underscore) to the value of the last evaluated expression. If we don't do this, our mapping of _ to gettext can get overwritten. This is useful/needed in interactive debugging with PyShell.
you do this by defining in your App module:
def _displayHook(obj):
"""Custom display hook to prevent Python stealing '_'."""
if obj is not None:
print repr(obj)
and then in your wx.App.OnInit method do:
# work around for Python stealing "_"
sys.displayhook = _displayHook
I am new to IPython and I am using the Canopy distribution. The default value of the shell's working directory is /home/username. This is a bit painful, when I work on files which need other files present in the corresponding folder that I am working in.
So, I always manually change it to folder in which the file (which I am trying to execute) is present.
I found this relevant question, but my question is slightly different. Also, I couldn't understand the answer provided there really well.
Is there a shorter way of setting up the working directory of the IPython shell to that of the file on which I am working? Like a command?
Thanks for your help
You can use cd inside of iPython. cd stands for change directory
> cd /home/username/my_otherdirectory
This is a feature that is on our list of features, but quite low on priority. Canopy provides a right click context menu option to switch to the currently active editor's directory (see this).
Also, as a temporary work-around, you could use the following macro to get your job done.
# -*- coding: utf-8 -*-
def run():
code_task = get_active_task()
from os.path import dirname
def change_directory():
code_editor = code_task.active_editor
if not code_editor:
return
python_pane = code_task.python_pane
active_dir = dirname(code_editor.obj.path)
python_pane.execute_command(u'cd %s\n' % active_dir)
code_task.on_trait_change(change_directory, 'active_editor')
Note: You'll have to run this macro, each time you have closed and reopened the editor window.
See 1 and 2 for instructions on how to create a macro and for more information about macros in Canopy.
Right click on python tab in Canopy and from menu select 'Keep Directory Synced to Editor'. It will set directory containing your source file as your current working directory.You can set any directory as your working directory by selecting 'Change Working Directory' from right click menu
I want to let perl use the DBI module in my own path(suppose, /home/users/zdd/perl5/lib/DBI), but the sysem also has a DBI module which is /usr/lib/perl5/lib/DBI.
when I write the following code in my script, perl use the system path be default, how to force it use the one under my path?
use lib './perl5/lib/DBI';
use DBI;
sub test {
....
}
/usr/lib/perl5/lib/DBI was added to the PATH environment variable in my bash profile, it was used by many scripts, so I can't disable it.
The file for the main DBI module is in ./perl5/lib. So your path is not pointing to it.
The DBI folder contains sub-modules of DBI, e.g. DBI::Foo (the :: in module names is a representation of your module directory structure).
Try using ./perl5/lib as your library instead.
Also, using a relative path will fail if the current directory is not what you think it is. If you are in doubt, have your script call cwd to see what the current directory is.
For debugging purposes, it may be helpful to use:
no lib '[main Perl module library path here]';
That way you can be sure you are only using your custom module path. Any failure to find a module will cause an error, rather than silently using the system version.
Update: For more information, see Perldoc on use lib. Perl will use the library that you have specified first. If it does not, that indicates it is not actually finding the module in the location you have given.
In addition to what dan1111 suggested, I would also recommend you print out #INC (just before your use DBI statement) and dump %INC (just after your use DBI statement) to see what your script is doing. That may help you debug the issue.