I just tried this and I get a str/bytes issue. I also think your setup3k.py
command is missing ``build`` and your build/scripts-3.2 is missing ``/hg``.
On Wed, Feb 22, 2012 at 19:26, Éric Araujo mer...@netwok.org wrote:
Hi Brett,
I think this message went unanswered, so here’s a late reply:
Hi Brett,
I think this message went unanswered, so here’s a late reply:
Le 07/02/2012 23:21, Brett Cannon a écrit :
On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman dirk...@ochtman.nl wrote:
[...]
Anyway, I think there was enough of a python3 port for Mercurial (from
various GSoC students) that
Le 07/02/2012 23:21, Brett Cannon a écrit :
On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Yeah, startup performance getting worse kinda sucks for command-line
apps. And IIRC it's been getting worse over the past few releases...
Anyway, I think there was enough of a
On Thu, Feb 9, 2012 at 17:00, PJ Eby p...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer m...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant to any discussion of
reworking the import
On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon br...@python.org wrote:
On Thu, Feb 9, 2012 at 17:00, PJ Eby p...@telecommunity.com wrote:
I did some crude timeit tests on frozenset(listdir()) and trapping failed
stat calls. It looks like, for a Windows directory the size of the 2.7
stdlib,
On Fri, Feb 10, 2012 at 15:07, PJ Eby p...@telecommunity.com wrote:
On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon br...@python.org wrote:
On Thu, Feb 9, 2012 at 17:00, PJ Eby p...@telecommunity.com wrote:
I did some crude timeit tests on frozenset(listdir()) and trapping
failed stat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 03:38 PM, Brett Cannon wrote:
Changes in any fashion to the directory. Do filesystems atomically
update the mtime of a directory when they commit a change? Otherwise
we have a potential race condition.
Hmm, maybe I misundersand
On Fri, Feb 10, 2012 at 16:29, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 03:38 PM, Brett Cannon wrote:
Changes in any fashion to the directory. Do filesystems atomically
update the mtime of a directory when they commit a change?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 04:42 PM, Brett Cannon wrote:
On Fri, Feb 10, 2012 at 16:29, Tres Seaver tsea...@palladion.com
wrote:
On 02/10/2012 03:38 PM, Brett Cannon wrote:
Changes in any fashion to the directory. Do filesystems
atomically update the mtime
On Feb 10, 2012 3:38 PM, Brett Cannon br...@python.org wrote:
On Fri, Feb 10, 2012 at 15:07, PJ Eby p...@telecommunity.com wrote:
On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon br...@python.org wrote:
First is that if this were used on Windows or OS X (i.e. the OSs we
support that typically have
On Sat, Feb 11, 2012 at 11:23 AM, PJ Eby p...@telecommunity.com wrote:
What's the downside in that case? You're trying to import something that
just changed in the last fraction of a second... why?
I don't know if it's normal in the Python world, but these sorts of
race conditions occur most
On Wed, Feb 8, 2012 at 20:28, PJ Eby p...@telecommunity.com wrote:
On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon br...@python.org wrote:
On Wed, Feb 8, 2012 at 15:31, Terry Reedy tjre...@udel.edu wrote:
For top-level imports, unless *all* are made lazy, then there *must* be
some
On Wed, Feb 8, 2012 at 20:26, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Feb 9, 2012 at 2:09 AM, Antoine Pitrou solip...@pitrou.net
wrote:
I guess my point was: why is there a function call in that case? The
import statement could look up sys.modules directly.
Or the built-in
On Feb 9, 2012 9:58 AM, Brett Cannon br...@python.org wrote:
This actually depends on the type of ImportError. My current solution
actually would trigger an ImportError at the import statement if no finder
could locate the module. But if some ImportError was raised because of some
other issue
On Thu, Feb 9, 2012 at 13:43, PJ Eby p...@telecommunity.com wrote:
On Feb 9, 2012 9:58 AM, Brett Cannon br...@python.org wrote:
This actually depends on the type of ImportError. My current solution
actually would trigger an ImportError at the import statement if no finder
could locate the
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon br...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Eby p...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing disk access for lazy imports
goes
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannonbr...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Ebyp...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing
On 2/9/2012 3:27 PM, Glenn Linderman wrote:
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannonbr...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Ebyp...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer m...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant to any discussion of
reworking the import mechanism:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Eby p...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer m...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant to any discussion of
reworking the
On 2/9/12 10:15 PM, Antoine Pitrou wrote:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Ebyp...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyerm...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant
On Thu, Feb 9, 2012 at 5:34 PM, Robert Kern robert.k...@gmail.com wrote:
On 2/9/12 10:15 PM, Antoine Pitrou wrote:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Ebyp...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyerm...@mired.org wrote:
For those of you not watching -ideas,
On Fri, Feb 10, 2012 at 1:05 AM, Brett Cannon br...@python.org wrote:
This would then be similar to the way main.c already works when it
interacts with runpy - simple cases are handled directly in C, more
complex cases get handed over to the Python module.
I suspect that if people want the
On 2/9/2012 7:19 PM, PJ Eby wrote:
Right. It was the part of the post that mentioned that all they sped up
was knowing which directory the files were in, not the actual loading of
bytecode. The thought then occurred to me that this could perhaps be
applied to normal importing, as a
On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon br...@python.org wrote:
IOW you want the sys.modules case fast, which I will never be able to
match
compared to C code since that is pure execution with no I/O.
Why
On Tue, Feb 7, 2012 at 18:08, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 7 Feb 2012 17:16:18 -0500
Brett Cannon br...@python.org wrote:
IOW I really do not look forward to someone saying importlib is so
much
slower at importing a module containing ``pass`` when (a) that never
On Tue, Feb 7, 2012 at 21:27, PJ Eby p...@telecommunity.com wrote:
On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon br...@python.org wrote:
On Tue, Feb 7, 2012 at 16:51, PJ Eby p...@telecommunity.com wrote:
On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon br...@python.org wrote:
So, if there is
Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit :
On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou solip...@pitrou.net
wrote:
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon br...@python.org wrote:
IOW you want the sys.modules case fast, which
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy tjre...@udel.edu wrote:
On 2/7/2012 9:35 PM, PJ Eby wrote:
It's just that not everything I write can depend on Importing.
Throw an equivalent into the stdlib, though, and I
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan ncogh...@gmail.com wrote
[SNIP]
The fact that we have an undocumented PEP 302 based reimplementation
of imports squirrelled away in pkgutil to make pkgutil and runpy work
is sheer insanity (replacing *that* with importlib might actually be a
good
On Tue, Feb 7, 2012 at 18:26, Alex Gaynor alex.gay...@gmail.com wrote:
Brett Cannon brett at python.org writes:
IOW you want the sys.modules case fast, which I will never be able to
match
compared to C code since that is pure execution with no I/O.
Sure you can: have a really fast
On Wed, Feb 8, 2012 at 11:09, Antoine Pitrou solip...@pitrou.net wrote:
Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit :
On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou solip...@pitrou.net
wrote:
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon
On Wed, Feb 8, 2012 at 11:15, Brett Cannon br...@python.org wrote:
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan ncogh...@gmail.com wrote
[SNIP]
The fact that we have an undocumented PEP 302 based reimplementation
of imports squirrelled away in pkgutil to make pkgutil and runpy work
is
On 2/8/2012 11:13 AM, Brett Cannon wrote:
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan ncogh...@gmail.com
I'm not sure such an addition would help much with the base
interpreter start up time though - most of the modules we bring in are
because we're actually using them for some
On Wed, 8 Feb 2012 11:07:10 -0500
Brett Cannon br...@python.org wrote:
So, if there is going to be some baseline performance target I need
to
hit
to make people happy I would prefer to know what that (real-world)
benchmark is and what the performance target is going to be
On Wed, Feb 8, 2012 at 14:57, Terry Reedy tjre...@udel.edu wrote:
On 2/8/2012 11:13 AM, Brett Cannon wrote:
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan ncogh...@gmail.com
I'm not sure such an addition would help much with the base
interpreter start up time though - most of the
On 2/8/2012 3:16 PM, Brett Cannon wrote:
On Wed, Feb 8, 2012 at 14:57, Terry Reedy tjre...@udel.edu
Would the following work? Treat a function as a 'loop' in that it
may be executed repeatedly. Treat 'import x' in a function as what
it is, an __import__ call plus a local assignment.
On Wed, Feb 8, 2012 at 15:31, Terry Reedy tjre...@udel.edu wrote:
On 2/8/2012 3:16 PM, Brett Cannon wrote:
On Wed, Feb 8, 2012 at 14:57, Terry Reedy tjre...@udel.edu
Would the following work? Treat a function as a 'loop' in that it
may be executed repeatedly. Treat 'import x' in a
On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon br...@python.org wrote:
On Wed, Feb 8, 2012 at 15:31, Terry Reedy tjre...@udel.edu wrote:
For top-level imports, unless *all* are made lazy, then there *must* be
some indication in the code of whether to make it lazy or not.
Not true; importlib
On Thu, Feb 9, 2012 at 2:09 AM, Antoine Pitrou solip...@pitrou.net wrote:
I guess my point was: why is there a function call in that case? The
import statement could look up sys.modules directly.
Or the built-in __import__ could still be written in C, and only defer
to importlib when the
On Thu, Feb 9, 2012 at 11:28 AM, PJ Eby p...@telecommunity.com wrote:
The main two reasons you wouldn't want imports to *always* be lazy are:
1. Changing sys.path or other parameters between the import statement and
the actual import
2. ImportErrors are likewise deferred until point-of-use,
I'm going to start this off with the caveat that
hg.python.org/sandbox/bcannon#bootstrap_importlib is not completely at
feature parity, but getting there shouldn't be hard. There is a FAILING
file that has a list of the tests that are not passing because importlib
bootstrapping and a comment as to
Brett, thanks for persevering on importlib! Given how complicated imports are
in Python, I really appreciate you pushing this forward. I've been knee deep
in both import.c and importlib at various times. ;)
On Feb 07, 2012, at 03:07 PM, Brett Cannon wrote:
One is maintainability. Antoine
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw ba...@python.org wrote:
Identifying the use cases are important here. For example, even if it were a
lot slower, Mailman wouldn't care (*I* might care because it takes longer to
run my test, but my users wouldn't). But Bazaar or Mercurial users would
On Tue, 7 Feb 2012 15:07:24 -0500
Brett Cannon br...@python.org wrote:
Now I'm going to be upfront and say I really did not want to have this
performance conversation now as I have done *NO* profiling or analysis of
the algorithms used in importlib in order to tune performance (e.g. the
On 7 February 2012 20:49, Antoine Pitrou solip...@pitrou.net wrote:
Well, import time is so important that the Mercurial developers have
written an on-demand import mechanism, to reduce the latency of
command-line operations.
One question here, I guess - does the importlib integration do
On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon br...@python.org wrote:
So, if there is going to be some baseline performance target I need to hit
to make people happy I would prefer to know what that (real-world)
benchmark is and what the performance target is going to be on a non-debug
build.
On Tue, Feb 7, 2012 at 15:49, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 7 Feb 2012 15:07:24 -0500
Brett Cannon br...@python.org wrote:
Now I'm going to be upfront and say I really did not want to have this
performance conversation now as I have done *NO* profiling or analysis of
On Tue, Feb 7, 2012 at 15:24, Barry Warsaw ba...@python.org wrote:
Brett, thanks for persevering on importlib! Given how complicated imports
are
in Python, I really appreciate you pushing this forward. I've been knee
deep
in both import.c and importlib at various times. ;)
On Feb 07,
On Tue, Feb 7, 2012 at 16:19, Paul Moore p.f.mo...@gmail.com wrote:
On 7 February 2012 20:49, Antoine Pitrou solip...@pitrou.net wrote:
Well, import time is so important that the Mercurial developers have
written an on-demand import mechanism, to reduce the latency of
command-line
On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw ba...@python.org wrote:
Identifying the use cases are important here. For example, even if it
were a
lot slower, Mailman wouldn't care (*I* might care because it takes
longer
On Tue, Feb 7, 2012 at 16:51, PJ Eby p...@telecommunity.com wrote:
On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon br...@python.org wrote:
So, if there is going to be some baseline performance target I need to
hit to make people happy I would prefer to know what that (real-world)
benchmark is
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon br...@python.org wrote:
IOW you want the sys.modules case fast, which I will never be able to match
compared to C code since that is pure execution with no I/O.
Why wouldn't continue using C code for that? It's trivial (just a dict
lookup).
On Feb 07, 2012, at 09:19 PM, Paul Moore wrote:
One question here, I guess - does the importlib integration do
anything to make writing on-demand import mechanisms easier (I'd
suspect not, but you never know...) If it did, then performance issues
might be somewhat less of a sticking point, as
On Tue, 7 Feb 2012 17:16:18 -0500
Brett Cannon br...@python.org wrote:
IOW I really do not look forward to someone saying importlib is so much
slower at importing a module containing ``pass`` when (a) that never
happens, and (b) most programs do not spend their time importing but
Brett Cannon brett at python.org writes:
IOW you want the sys.modules case fast, which I will never be able to match
compared to C code since that is pure execution with no I/O.
Sure you can: have a really fast Python VM.
Constructive: if you can run this code under PyPy it'd be easy to
On 2/7/2012 4:51 PM, PJ Eby wrote:
One thing I'm a bit worried about is repeated imports, especially ones
that are inside frequently-called functions. In today's versions of
Python, this is a performance win for command-line tool platform
systems like Mercurial and PEAK, where you want to
On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon br...@python.org wrote:
On Tue, Feb 7, 2012 at 16:51, PJ Eby p...@telecommunity.com wrote:
On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon br...@python.org wrote:
So, if there is going to be some baseline performance target I need to
hit to make
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy tjre...@udel.edu wrote:
importlib could provide a parameterized decorator for functions that are
the only consumers of an import. It could operate much like this:
def imps(mod):
def makewrap(f):
def wrapped(*args, **kwds):
On 2/7/2012 9:35 PM, PJ Eby wrote:
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy tjre...@udel.edu
mailto:tjre...@udel.edu wrote:
importlib could provide a parameterized decorator for functions that
are the only consumers of an import. It could operate much like this:
def imps(mod):
On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy tjre...@udel.edu wrote:
On 2/7/2012 9:35 PM, PJ Eby wrote:
It's just that not everything I write can depend on Importing.
Throw an equivalent into the stdlib, though, and I guess I wouldn't have
to worry about dependencies...
And that is what I
On Tue, Feb 7, 2012 at 8:47 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy tjre...@udel.edu wrote:
On 2/7/2012 9:35 PM, PJ Eby wrote:
It's just that not everything I write can depend on Importing.
Throw an equivalent into the stdlib, though, and I
62 matches
Mail list logo
