I'm going to guess my bootstrap patch caused most of these. =) test_capi is
now plugged, so I'm going to assume Python/pythonrun.c:import_init() is
taken care of. The real question is where in
http://hg.python.org/cpython/rev/2dd046be2c88 are the other leaks coming
from. Any help would be great as
+1! Thanks for pushing this.
On Apr 15, 2012 4:04 AM, "Brett Cannon" wrote:
> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In
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 4:16 PM, Brett Cannon wrote:
> Once again, it's just code that needs updating to run on Python 3.3 so I
> don't view it as a concern. Going from list.append() to list.insert() (even
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.
I'm fine with that.
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 17:12, Eric Snow wrote:
> On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon wrote:
> > To start off, what I am about to propose was brought up at the PyCon
> > language summit and the whole room agreed with what I want to do here,
> so I
> > honestly don't expect much of an ar
On 14 April 2012 21:03, Brett Cannon wrote:
> So what I propose to do is stop having import have any kind of implicit
> machinery. This means sys.meta_path gets a path finder that does the heavy
> lifting for import and sys.path_hooks gets a hook which provides a default
> finder.
+1 to your prop
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,
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon wrote:
> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In the "ancient" import.c d
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
To start off, what I am about to propose was brought up at the PyCon
language summit and the whole room agreed with what I want to do here, so I
honestly don't expect much of an argument (famous last words).
In the "ancient" import.c days, a lot of import's stuff was hidden deep in
the C code and
On 14.04.2012 20:12, Brett Cannon wrote:
My multi-year project -- started in 2006 according to my blog -- to rewrite
import in pure Python and then bootstrap it into CPython as *the* implementation
of __import__() is finally over (mostly)! Hopefully I didn't break too much code
in the process. =)
My multi-year project -- started in 2006 according to my blog -- to rewrite
import in pure Python and then bootstrap it into CPython as *the*
implementation of __import__() is finally over (mostly)! Hopefully I didn't
break too much code in the process. =)
Now this is "mostly" finished because the
Thought I'd tie this thread up with a successful method, as I've just compiled
Python-2.7.3 and have got the benchmarks to run slightly faster than the system
Python :D
** First benchmark **
metabuntu:benchmarks> python perf.py -r -b apps /usr/bin/python
../Python-2.7.3/python
Running 2to3...
>> I prefer "steady" over "monotonic" because the steady property is what
>> users really expect from a "monotonic" clock. A monotonic but not
>> steady clock may be useless.
>
> "steady" is ambiguous IMO. It can only be "steady" in reference to
> another clock - but which one ? (real time presumab
On Sat, 14 Apr 2012 02:51:09 +0200
Victor Stinner wrote:
>
> time.monotonic() does not fallback to the system clock anymore, it is
> now always monotonic.
Then just call it "monotonic" :-)
> I prefer "steady" over "monotonic" because the steady property is what
> users really expect from a "mon
On 14 April 2012 06:41, Stephen J. Turnbull wrote:
> A clock can be accurate in measuring
> duration even though it is not accurate in measuring the point in
> time. [It's hard to see how the opposite could be true.]
Pedantic point: A clock that is stepped (say, by NTP) is precisely one
that is
23 matches
Mail list logo
