On Oct 31, 5:12 pm, kj no.em...@please.post wrote:
I give up: what's the trick? (Of course, renaming ham/re.py is
hardly the trick. It's rather Procrustes' Bed.)
I realize that this is probably not the answer you were looking for,
but:
$ python -m ham.spam
or
== ./spammain.py ==
import
On Nov 3, 1:52 am, Carl Banks pavlovevide...@gmail.com wrote:
On Oct 31, 7:12 am, kj no.em...@please.post wrote:
I'm running into an ugly bug, which, IMHO, is really a bug in the
design of Python's module import scheme. Consider the following
directory structure:
ham
|--
En Tue, 03 Nov 2009 12:29:10 -0300, Ask Solem askso...@gmail.com
escribió:
If you have a module named myapp.django, and someone writes a cool
library called
django that you want to use, you can't use it unless you rename your
local django module.
file myapp/django.py:
from
On Oct 31, 7:12 am, kj no.em...@please.post wrote:
I'm running into an ugly bug, which, IMHO, is really a bug in the
design of Python's module import scheme. Consider the following
directory structure:
ham
|-- __init__.py
|-- re.py
`-- spam.py
...with the following very simple files:
On Sun, 01 Nov 2009 01:38:16 -0300, Gabriel Genellina wrote:
Incorrect. Simplicity of implementation and API is a virtue, in and of
itself. The existing module machinery is quite simple to understand,
use and maintain.
Uhm... module objects might be quite simple to understand, but module
En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano
st...@remove-this-cybersource.com.au escribió:
On Sun, 01 Nov 2009 01:38:16 -0300, Gabriel Genellina wrote:
Incorrect. Simplicity of implementation and API is a virtue, in and of
itself. The existing module machinery is quite simple to
Gabriel Genellina wrote:
[snip]
One way to avoid name clashes would be to put the entire standard
library under a package; a program that wants the standard re
module would write import std.re instead of import re, or
something similar. Every time the std package is suggested, the
main argument
On Sun, 01 Nov 2009 17:34:19 -0300, Gabriel Genellina wrote:
En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano
st...@remove-this-cybersource.com.au escribió:
On Sun, 01 Nov 2009 01:38:16 -0300, Gabriel Genellina wrote:
Incorrect. Simplicity of implementation and API is a virtue, in and
En Sun, 01 Nov 2009 19:01:42 -0300, MRAB pyt...@mrabarnett.plus.com
escribió:
Gabriel Genellina wrote:
One way to avoid name clashes would be to put the entire standard
library under a package; a program that wants the standard re
module would write import std.re instead of import re, or
En Sun, 01 Nov 2009 19:51:04 -0300, Steven D'Aprano
st...@remove-this-cybersource.com.au escribió:
On Sun, 01 Nov 2009 17:34:19 -0300, Gabriel Genellina wrote:
En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano escribió:
Shadowing a standard library module
is no different.
But that's
On Oct 31, 3:12 pm, kj no.em...@please.post wrote:
I'm running into an ugly bug, which, IMHO, is really a bug in the
design of Python's module import scheme. Consider the following
directory structure:
ham
|-- __init__.py
|-- re.py
`-- spam.py
...with the following very simple files:
kj, 31.10.2009 16:12:
My sin appears to be having the (empty) file ham/re.py. So Python
is confusing it with the re module of the standard library, and
using it when the inspect module tries to import re.
1) it's a bad idea to name your own modules after modules in the stdlib
2) this has been
In 4aec591e$0$7629$9b4e6...@newsspool1.arcor-online.net Stefan Behnel
stefan...@behnel.de writes:
kj, 31.10.2009 16:12:
My sin appears to be having the (empty) file ham/re.py. So Python
is confusing it with the re module of the standard library, and
using it when the inspect module tries to
On Sat, 2009-10-31 at 16:27 +, kj wrote:
2) this has been fixed in Py3
In my post I illustrated that the failure occurs both with Python
2.6 *and* Python 3.0. Did you have a particular version of Python
3 in mind?
I was not able to reproduce with my python3:
$ head ham/*.py
On Sat, 31 Oct 2009 16:27:20 +, kj wrote:
1) it's a bad idea to name your own modules after modules in the stdlib
Obviously, since it leads to the headaches this thread illustrates. But
there is nothing intrisically wrong with it. The fact that it is
problematic in Python is a design
En Sat, 31 Oct 2009 12:12:21 -0300, kj no.em...@please.post escribió:
I'm running into an ugly bug, which, IMHO, is really a bug in the
design of Python's module import scheme.
The basic problem is that the import scheme was not designed in advance.
It was a very simple thing at first. Then
Bump
In article [EMAIL PROTECTED],
Michael Abbott [EMAIL PROTECTED] wrote:
--- test.py ---
import imptest
execfile('subtest.py', dict(__name__ = 'subtest.py'))
--- imptest.py ---
print 'Imptest imported'
--- subtest.py ---
import imptest
---
$ python test.py
Imptest imported
On Fri, 30 Jun 2006 19:13:00 +0100, Michael Abbott [EMAIL PROTECTED] wrote:
Bump
In article [EMAIL PROTECTED],
Michael Abbott [EMAIL PROTECTED] wrote:
--- test.py ---
import imptest
execfile('subtest.py', dict(__name__ = 'subtest.py'))
--- imptest.py ---
print 'Imptest imported'
---
Michael Abbott wrote:
In article [EMAIL PROTECTED],
Michael Abbott [EMAIL PROTECTED] wrote:
--- test.py ---
import imptest
execfile('subtest.py', dict(__name__ = 'subtest.py'))
--- imptest.py ---
print 'Imptest imported'
--- subtest.py ---
import imptest
---
$ python test.py
Peter Maas wrote:
The docs tell us
(http://www.python.org/doc/2.4.2/lib/built-in-funcs.html):
- begin ---
execfile(filename[, globals[, locals]])
This function is similar to the exec statement, but parses a file
instead of a string. It
In article [EMAIL PROTECTED],
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
Set __name__ to 'subtest' as it would be if you had really imported
subtest and the import system will correctly name the modules, causing
imptest to be imported only once.
Ach. I get it now.
--
21 matches
Mail list logo