+1 here. Previously, it wasn't a reasonable requirement, since CPython
itself didn't comply with it.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
+1 for initial proposition.
On Tue, Apr 17, 2012 at 6:59 PM, Brett Cannon wrote:
> Anyone other than Eric have something to say on this proposal? Obviously the
> discussion went tangential before I saw a clear consensus that what I was
> proposing was fine with people.
>
>
> On Sat, Apr 14, 2012
Anyone other than Eric have something to say on this proposal? Obviously
the discussion went tangential before I saw a clear consensus that what I
was proposing was fine with people.
On Sat, Apr 14, 2012 at 16:56, Brett Cannon wrote:
> An open issue in PEP 302 is whether to require __loader__ at
On Apr 15, 2012, at 6:38 PM, Barry Warsaw wrote:
> On Apr 15, 2012, at 02:12 PM, Glyph wrote:
>
>> Twisted has such a thing, mostly written by me, called
>> twisted.python.modules.
>>
>> Sorry if I'm repeating myself here, I know I've brought it up on this list
>> before, but it seems germane t
On Apr 15, 2012, at 02:12 PM, Glyph wrote:
>Twisted has such a thing, mostly written by me, called
>twisted.python.modules.
>
>Sorry if I'm repeating myself here, I know I've brought it up on this list
>before, but it seems germane to this thread. I'd be interested in getting
>feedback from the i
On Apr 14, 2012, at 03:32 PM, Guido van Rossum wrote:
>Funny, I was just thinking about having a simple standard API that
>will let you open files (and list directories) relative to a given
>module or package regardless of how the thing is loaded.
I tend to use the "basic resource access" API of
On Apr 14, 2012, at 3:32 PM, Guido van Rossum wrote:
> Funny, I was just thinking about having a simple standard API that
> will let you open files (and list directories) relative to a given
> module or package regardless of how the thing is loaded.
Twisted has such a thing, mostly written by m
On Apr 14, 2012, at 7:59 PM, Guido van Rossum wrote:
> On Sat, Apr 14, 2012 at 5:06 PM, Christian Heimes wrote:
>> Am 15.04.2012 00:56, schrieb Guido van Rossum:
>>> Well, if it's a real file, and you need a stream, that's efficient,
>>> and if you need the data, you can read it. But if it comes
On Sun, Apr 15, 2012 at 8:32 AM, Guido van Rossum wrote:
> Funny, I was just thinking about having a simple standard API that
> will let you open files (and list directories) relative to a given
> module or package regardless of how the thing is loaded. If we
> guarantee that there's always a __lo
On Sun, Apr 15, 2012 at 12:59 PM, Guido van Rossum wrote:
> Hm... Can you give an example of a library that needs a real file?
> That sounds like a poorly designed API.
If you're invoking a separate utility (e.g. via it's command line
interface), you may need a real filesystem path that you can p
On Sat, Apr 14, 2012 at 5:06 PM, Christian Heimes wrote:
> Am 15.04.2012 00:56, schrieb Guido van Rossum:
>> Well, if it's a real file, and you need a stream, that's efficient,
>> and if you need the data, you can read it. But if it comes from a
>> loader, and you need a stream, you'd have to wrap
Am 15.04.2012 00:56, schrieb Guido van Rossum:
> Well, if it's a real file, and you need a stream, that's efficient,
> and if you need the data, you can read it. But if it comes from a
> loader, and you need a stream, you'd have to wrap it in a StringIO
> instance. So having two APIs, one to get a
On Sat, Apr 14, 2012 at 18:56, Guido van Rossum wrote:
> On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon wrote:
> > On Sat, Apr 14, 2012 at 18:32, Guido van Rossum
> wrote:
> >> Funny, I was just thinking about having a simple standard API that
> >> will let you open files (and list directories)
On Sat, Apr 14, 2012 at 18:41, Christian Heimes wrote:
> Am 15.04.2012 00:32, schrieb Guido van Rossum:
> > Funny, I was just thinking about having a simple standard API that
> > will let you open files (and list directories) relative to a given
> > module or package regardless of how the thing i
On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon wrote:
> On Sat, Apr 14, 2012 at 18:32, Guido van Rossum wrote:
>> Funny, I was just thinking about having a simple standard API that
>> will let you open files (and list directories) relative to a given
>> module or package regardless of how the thin
On Sat, Apr 14, 2012 at 18:32, Guido van Rossum wrote:
> On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow
> wrote:
> > On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon wrote:
> >> An open issue in PEP 302 is whether to require __loader__ attributes on
> >> modules. The claimed worry is memory consumptio
Am 15.04.2012 00:32, schrieb Guido van Rossum:
> Funny, I was just thinking about having a simple standard API that
> will let you open files (and list directories) relative to a given
> module or package regardless of how the thing is loaded. If we
> guarantee that there's always a __loader__ that
On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow wrote:
> On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon wrote:
>> An open issue in PEP 302 is whether to require __loader__ attributes on
>> modules. The claimed worry is memory consumption, but considering importlib
>> and zipimport are already doing thi
On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon wrote:
> An open issue in PEP 302 is whether to require __loader__ attributes on
> modules. The claimed worry is memory consumption, but considering importlib
> and zipimport are already doing this that seems like a red herring.
> Requiring it, though,
An open issue in PEP 302 is whether to require __loader__ attributes on
modules. The claimed worry is memory consumption, but considering importlib
and zipimport are already doing this that seems like a red herring.
Requiring it, though, opens the door to people relying on its existence and
thus st
20 matches
Mail list logo
