On Sat, Apr 14, 2012 at 02:51, Victor Stinner victor.stin...@gmail.com wrote:
Hi,
Before posting a first draft of the PEP 418 to python-dev, I have some
questions.
== Naming: time.monotonic() or time.steady()? ==
The clock is monotonic by all reasonable definitions of monotonic (ie
they
On 14 April 2012 06:41, Stephen J. Turnbull step...@xemacs.org 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
On Sat, 14 Apr 2012 02:51:09 +0200
Victor Stinner victor.stin...@gmail.com 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
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 presumably, but perhaps
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
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.
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
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
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon br...@python.org 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
On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon br...@python.org 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.
On 14 April 2012 21:03, Brett Cannon br...@python.org 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
On Sat, Apr 14, 2012 at 17:12, Eric Snow ericsnowcurren...@gmail.comwrote:
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon br...@python.org 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
On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow ericsnowcurren...@gmail.com wrote:
On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon br...@python.org wrote:
An open issue in PEP 302 is whether to require __loader__ attributes on
modules. The claimed worry is memory consumption, but considering importlib
On Sat, Apr 14, 2012 at 18:32, Guido van Rossum gu...@python.org wrote:
On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow ericsnowcurren...@gmail.com
wrote:
On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon br...@python.org wrote:
An open issue in PEP 302 is whether to require __loader__ attributes on
On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon br...@python.org wrote:
On Sat, Apr 14, 2012 at 18:32, Guido van Rossum gu...@python.org 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
On Sat, Apr 14, 2012 at 18:41, Christian Heimes li...@cheimes.de 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
On Sat, Apr 14, 2012 at 18:56, Guido van Rossum gu...@python.org wrote:
On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon br...@python.org wrote:
On Sat, Apr 14, 2012 at 18:32, Guido van Rossum gu...@python.org
wrote:
Funny, I was just thinking about having a simple standard API that
will let
On Sat, Apr 14, 2012 at 4:16 PM, Brett Cannon br...@python.org 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
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 5:06 PM, Christian Heimes li...@cheimes.de 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
+1! Thanks for pushing this.
On Apr 15, 2012 4:04 AM, Brett Cannon br...@python.org 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
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
22 matches
Mail list logo
