> _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 characte
2012/2/7 "Martin v. Löwis" :
>> _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
On Mon, Feb 6, 2012 at 6:12 PM, Steven D'Aprano 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
> > possibility of maki
On Mon, Feb 6, 2012 at 14:49, Antoine Pitrou wrote:
> On Mon, 6 Feb 2012 09:57:56 -0500
> Brett Cannon 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?
>
I have not even looked a
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
http://mail.python.org/mailman/lis
2012/2/7 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?
>
The Microsoft compilers on Windows do not support C99:
- Declarations must be at the start of a b
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 menti
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw 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 care
> a lot.
On Tue, 7 Feb 2012 15:07:24 -0500
Brett Cannon 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
> function that ha
On 7 February 2012 20:49, Antoine Pitrou 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
anything to make writi
> 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 proces
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 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. And if people
> 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
http://mail.python.org/m
On Tue, Feb 7, 2012 at 15:49, Antoine Pitrou wrote:
> On Tue, 7 Feb 2012 15:07:24 -0500
> Brett Cannon 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 im
On Tue, Feb 7, 2012 at 15:24, Barry Warsaw 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, 2012, at 03:0
On Tue, Feb 7, 2012 at 16:19, Paul Moore wrote:
> On 7 February 2012 20:49, Antoine Pitrou 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 gue
On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman wrote:
> On Tue, Feb 7, 2012 at 21:24, Barry Warsaw 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
On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote:
> On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon 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
On Tue, Feb 7, 2012 at 1:41 PM, "Martin v. Löwis" 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 Amaury says
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon 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).
Regards
Antoine.
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 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
> > > inst
Brett Cannon 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 just:
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 del
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 *c
On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon wrote:
>
> On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote:
>
>> On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon 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 tha
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy 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):
>print('first
On 2/7/2012 9:35 PM, PJ Eby wrote:
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy 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):
def makew
>> 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 sp
On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy 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 think (ag
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 accele
On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky 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 without requirin
On Tue, Feb 7, 2012 at 8:47 PM, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy 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 w
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 don't know. I took this to
On Wed, Feb 8, 2012 at 06:41, Fred Drake wrote:
> 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 [.
On Tue, Feb 7, 2012 at 22:15, Nick Coghlan 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 version (wh
On Wed, Feb 8, 2012 at 06:15, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky 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
> w
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 one source of confusion: what are you referring to an
an "import façade"? When I l
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 one source of confusion: w
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 g
>> 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 accel
Is the idea to have:
b"foo".decode("locale")
be roughly equivalent to
encoding = locale.getpreferredencoding(False)
b"foo".decode(encoding)
?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
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 tr
45 matches
Mail list logo
