On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > > I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> > > over a pure objects-on-sys.path approach:
> > >
> > > * Strings can be put in any configuration file, and used in .pth files
> > >
> >
Ian Bicking wrote:
> Maybe you wouldn't have to mix it all together... if sys.path,
> sys.meta_path, and sys.modules (and maybe some other stuff I don't know
> of) were really instance variables of some ModuleEnvironment object, and
> you could instantiate a new ModuleEnvironment that was specif
Guido van Rossum wrote:
> > I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> > over a pure objects-on-sys.path approach:
> >
> > * Strings can be put in any configuration file, and used in .pth files
> >
> > * Strings can be put in environment variables (like PYTHONPATH).
Phillip J. Eby wrote:
> So, what I'd suggest is that the expanded import mechanism would provide a
> registry of extensions and handlers,
Urg, global registries again.
I'd like this better if the scope of a particular extension
and its handler could be restricted to some chosen part of
the pack
Ian Bicking wrote:
> No, I haven't; I assume you mean:
>
> from string import Template or from mypackage.backports.string24
> import Template
No, I mean
from string or mypackage.backports.string24 import Template
which seems to be about the least ugly it can get given
that you need to ex
Hi,
I've another subject related to import machinery to add in this
thread. We've discussed about this at py-dev when I found an
inconsistent import/zipimport behavior with .pyc/.pyo compiled
modules:
http://mail.python.org/pipermail/python-dev/2005-November/057959.html
http://mail.python.org/pip
At 11:37 AM 4/21/2006 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>The second is that PEP 302 only covers "location" importers, not "format"
>>importers. That is, if you want to do something like make Kid or Cheetah
>>templates importable, you have to replace things with new
>>machinery.
Phillip J. Eby wrote:
> The second is that PEP 302 only covers "location" importers, not "format"
> importers. That is, if you want to do something like make Kid or Cheetah
> templates importable, you have to replace things with new machinery. This
> is a more important problem to solve, IMO,
At 10:05 PM 4/21/2006 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>There are only two things wrong with PEP 302 IMO, and neither is its "fault".
>>The first is that the "classic" import machinery isn't on sys.meta_path,
>>and the 'imp' API isn't defined in terms of PEP 302. Those two thing
On 4/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:> Have you seen my proposal for "or" in import statements?> Would you consider that elegant enough?No, I haven't; I assume you mean: from string import Template or from
mypackage.backports.string24import Template... that (realis
At 10:42 AM 4/21/2006 +0100, Guido van Rossum wrote:
>I think I like this. I wonder if there's a parallel with my preference
>for strings as paths instead of path objects...
PEP 302 still has things analagous to path objects, it's just that you're
allowed to define the mapping between strings and
Greg Ewing wrote:
> Ian Bicking wrote:
>>try:
>> from string import Template
>>except ImportError:
>> from mypackage.backports.string24 import Template
>>
>>Doing this in a more elegent or formalized fashion might be nice.
>
>
> Have you seen my proposal for "or" in import statements?
>
Phillip J. Eby wrote:
> There are only two things wrong with PEP 302 IMO, and neither is its "fault".
>
> The first is that the "classic" import machinery isn't on sys.meta_path,
> and the 'imp' API isn't defined in terms of PEP 302. Those two things
> can't change without introducing backward
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> 2) Totally disallow recursive imports (!).
>
> That would be extremely undesirable. I've used languages
> in which mutual imports weren't possible, and it's a
> massive pain in the posterior. You end up having to
> modularise things in awkward and unnatural
On 4/20/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> over a pure objects-on-sys.path approach:
>
> * Strings can be put in any configuration file, and used in .pth files
>
> * Strings can be put in environment variables (l
Ian Bicking wrote:
> try:
> from string import Template
> except ImportError:
> from mypackage.backports.string24 import Template
>
> Doing this in a more elegent or formalized fashion might be nice.
Have you seen my proposal for "or" in import statements?
Would you consider that eleg
Giovanni Bajo wrote:
> 2) Totally disallow recursive imports (!).
That would be extremely undesirable. I've used languages
in which mutual imports weren't possible, and it's a
massive pain in the posterior. You end up having to
modularise things in awkward and unnatural ways to
get around the res
Phillip J. Eby wrote:
> There are only two things wrong with PEP 302 IMO, and neither is its
> "fault".
>
> The first is that the "classic" import machinery isn't on
> sys.meta_path, and the 'imp' API isn't defined in terms of PEP 302.
> Those two things can't change without introducing backward
At 04:33 PM 4/20/2006 +0100, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > > On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > > > I was hoping that for Python 3.0, we could get around to
Jim Jewett wrote:
> On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>
>>With the ambiguity of sys.path, it's hard to statically determine if you
>>have all the requirements.
>
>
> [And, as you said elsewhere, whether it is the version you expected,
> and whether it will actually load or ge
On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> With the ambiguity of sys.path, it's hard to statically determine if you
> have all the requirements.
[And, as you said elsewhere, whether it is the version you expected,
and whether it will actually load or get skipped because of an earlier
im
Guido van Rossum wrote:
>> * Circular imports should fail more nicely. Everyone suffers this at
>> some time; maybe it can't be fixed, but at least it should be clear
>> what's happening.
>
> It probably can't be fixed (or do you see a fix?). Do you mean it
> should be easier to debug, or do you
Guido van Rossum wrote:
> It must not be my day. I don't understand anything you're saying.
Hmm... well, trying again...
> On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>Cleaning up import stuff would be excellent. Time spent debugging
>>imports is time wasted, but it happens all too of
It must not be my day. I don't understand anything you're saying.
On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Cleaning up import stuff would be excellent. Time spent debugging
> imports is time wasted, but it happens all too often.
>
> I would argue against any list of loaders, or list o
Guido van Rossum wrote:
> I'm changing the list and the subject, pulling this quote out of python-dev:
>
> On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>I was hoping that for Python 3.0, we could get around to unkludge the
>>sys.path/meta_path/path_hooks/path_importer_ca
On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > > I was hoping that for Python 3.0, we could get around to unkludge the
> > > sys.path/meta_path/path_hooks/path_importer_cache big ball of ha
Guido van Rossum wrote:
> On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > I was hoping that for Python 3.0, we could get around to unkludge the
> > sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks,
> > possibly by replacing sys.path with something a bit m
I'm changing the list and the subject, pulling this quote out of python-dev:
On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I was hoping that for Python 3.0, we could get around to unkludge the
> sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks,
> possibly
28 matches
Mail list logo
