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
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
>> 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
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
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
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 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 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 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 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 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 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
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 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
>> 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 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 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 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
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 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
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 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
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: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 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, 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 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: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: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 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
> 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 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
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
> 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
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
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 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.
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
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
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
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
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
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
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
> _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
45 matches
Mail list logo
