_Py_IDENTIFIER(xxx) defines a variable called PyId_xxx, so xxx can
only be ASCII: the C language doesn't accept non-ASCII identifiers.
That's not exactly true. In C89, source code is in the source character
set, which is implementation-defined, except that it must contain
the basic character
2012/2/7 Martin v. Löwis mar...@v.loewis.de:
_Py_IDENTIFIER(xxx) defines a variable called PyId_xxx, so xxx can
only be ASCII: the C language doesn't accept non-ASCII identifiers.
That's not exactly true. In C89, source code is in the source character
set, which is implementation-defined,
On Mon, Feb 6, 2012 at 6:12 PM, Steven D'Aprano st...@pearwood.info wrote:
On Mon, Feb 06, 2012 at 09:01:29PM +0100, julien tayon wrote:
Hello,
Proposing vector operations on dict, and acknowledging there was an
homeomorphism from rooted n-ary trees to dict, was inducing the
On Mon, Feb 6, 2012 at 14:49, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 6 Feb 2012 09:57:56 -0500
Brett Cannon br...@python.org wrote:
Thanks for any help people can provide me on this now 5 year quest to get
this work finished.
Do you have any plan to solve the performance issue?
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
-gps
___
Python-Dev mailing list
Python-Dev@python.org
2012/2/7 Gregory P. Smith g...@krypto.org
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
The Microsoft compilers on Windows do not support C99:
- Declarations must be at the
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
Does C99 specify the encoding? Can we expect UTF-8?
No, it's implementation-defined. However, that really doesn't matter
much for the macro (it does matter for the Mercurial repository):
The files on disk are mapped, in an implementation-defined manner,
into the source character set. All
Am 07.02.2012 20:10, schrieb Gregory P. Smith:
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
As Amaury says: Visual Studio still doesn't support C99. The story is
both funny
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.
I'd rather restore support for allowing UTF-8 source here (I don't think
that requiring ASCII really improves much), than rename the macro.
Done, I reverted my change.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
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, Feb 7, 2012 at 1:41 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 07.02.2012 20:10, schrieb Gregory P. Smith:
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
As
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
Hi,
I added PyUnicode_DecodeLocale(), PyUnicode_DecodeLocaleAndSize() and
PyUnicode_EncodeLocale() to Python 3.3 to fix bugs. I hesitate to
expose this codec in Python: it can be useful is some cases,
especially if you need to interact with C functions.
The glib library has functions using the
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 one hand I agree that ET should be emphasized since it's the better
API with a much faster implementation. But I also understand Martin's
point of view that minidom has its place, so IMHO some sort of
compromise should be reached. Perhaps we can recommend using ET for
those not
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
Hello,
Here's a note from What's new in Python 3.0:
A common pattern in Python 2.x is to have one version of a module
implemented in pure Python, with an optional accelerated version
implemented as a C extension; for example, pickle and cPickle. This
places the burden of importing the
On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky eli...@gmail.com wrote:
Is there a good reason why xml.etree.ElementTree /
xml.etree.cElementTree did not receive this treatment?
See PEP 360, which lists Externally Maintained Packages. In the past
we allowed additions to the standard library
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
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky eli...@gmail.com wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib by Florent Xicluna [...]. Is this not true?
I don't know. I
On Wed, Feb 8, 2012 at 06:41, Fred Drake fdr...@acm.org wrote:
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky eli...@gmail.com wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib
On Tue, Feb 7, 2012 at 22:15, Nick Coghlan ncogh...@gmail.com wrote:
Folding the two
implementations together in the standard library would mean officially
declaring that xml.etree is now an independently maintained fork of
Fredrik's version rather than just a snapshot in time of a
particular
On Wed, Feb 8, 2012 at 06:15, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky eli...@gmail.com wrote:
Is there a good reason why xml.etree.ElementTree /
xml.etree.cElementTree did not receive this treatment?
See PEP 360, which lists Externally Maintained
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky eli...@gmail.com wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is one source of confusion: what are you referring to an
an import
On Wed, Feb 8, 2012 at 07:10, Fred Drake fdr...@acm.org wrote:
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky eli...@gmail.com wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is one
Eli Bendersky, 08.02.2012 07:07:
On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote:
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is
The facade can be added to xml/etree/ElementTree.py since that's the
only documented module. It can attempt to do:
from _elementtree import *
(which is what cElementTree.py) does, and on failure, just go on doing
what it does now.
Basically, cElementTree (actually the accelerator module)
Is the idea to have:
bfoo.decode(locale)
be roughly equivalent to
encoding = locale.getpreferredencoding(False)
bfoo.decode(encoding)
?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Fred Drake, 08.02.2012 05:41:
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib by Florent Xicluna [...]. Is this not true?
I
45 matches
Mail list logo
