On Oct 31, 5:12 pm, kj 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 ham.spam
$ python
En Tue, 03 Nov 2009 12:29:10 -0300, Ask Solem
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 django.utils.functional import
On Nov 3, 1:52 am, Carl Banks wrote:
> On Oct 31, 7:12 am, kj 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
> > `-- sp
On Oct 31, 7:12 am, kj 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:
>
> % head ha
En Sun, 01 Nov 2009 19:51:04 -0300, Steven D'Aprano
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 what namespaces are for; if the standard
En Sun, 01 Nov 2009 19:01:42 -0300, MRAB
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
something similar.
You c
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ó:
>> 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 m
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 argume
En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano
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 understand,
use and maintain.
Uhm... mod
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 mo
En Sat, 31 Oct 2009 12:12:21 -0300, kj 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 came packages. And
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 desi
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/*
In <4aec591e$0$7629$9b4e6...@newsspool1.arcor-online.net> Stefan Behnel
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 import re.
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 be
On Oct 31, 3:12 pm, kj 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:
>
> % head ha
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:
% head ham/*.py
==> ham/__init__.py <==
==> ham/re.py <==
Hi all,
Running python 2.5, i experience a strange behaviour with the
following code:import imputil
def handle_pye(fullpath, fileinfo, name):
# Print a debugging message
print 'Importing "%s" from "%s"' % (name,fullpath)
data = open(fullpath).read()
return 0, compile(data,fullpath
Alexey Borzenkov wrote:
> After reading PEP-0328 I wanted to give relative imports a try:
>
> # somepkg/__init__.py
>
>
> # somepkg/test1.py
> from __future__ import absolute_import
> from . import test2
>
> if __name__ == "__main__":
> print "Test"
>
> # somepkg/test2.py
>
>
> But it compla
After reading PEP-0328 I wanted to give relative imports a try:
# somepkg/__init__.py
# somepkg/test1.py
from __future__ import absolute_import
from . import test2
if __name__ == "__main__":
print "Test"
# somepkg/test2.py
But it complaints:
C:\1\somepkg>test1.py
Traceback (most recent c
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.
--
http://mail.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 str
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
>> ---
>>
>
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
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
>Impt
25 matches
Mail list logo
