Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

[Eli Bendersky]

On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis"  wrote:

> > I find that strange, especially for an expert Python dev. I, a newbie,
> > find it far friendlier (and easier for a new programmer to grasp).
> > Maybe it's because I use it all the time, and you don't?
>
> That is most likely the case. You learn by practice. For that very
> reason, the claim "and easier for a new programmer to grasp" is
> difficult to prove. It was easier for *you*, since you started using
> it, and then kept using it. I don't recall any particular obstacles
> learning % formatting (even though I did for C, not for C++).
> Generalizing that it is *easier* is invalid: you just didn't try
> learning that instead first, and now you can't go back in a state
> where either are new to you.
>
> C++ is very similar here: they also introduced a new way of output
> (iostreams, and << overloading). I used that for a couple of years,
> primarily because people said that printf is "bad" and "not object-
> oriented". I then recognized that there is nothing wrong with printf
> per so, and would avoid std::cout in C++ these days, in favor of
> std::printf (yes, I know that it does have an issue with type safety).
>

Not to mention that the performance of iostreams is pretty bad, to the
extent that some projects actively discourage using them in favor of either
C-style IO (fgets, printf, etc.) or custom IO implementations. This is
marginally off-topic, although it does show that an initial thought of
deprecating an existing functionality for new one doesn't always work out
in the long run, even for super-popular languages like C++.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

[Eli Bendersky]

> Indeed, that note was written before we decided that getting rid of
> "%" formatting altogether would be a bad idea.
>
> It would be better to update it to say something like:
>
> "The formatting operations described here are modelled on C's printf()
> syntax. They only support formatting of certain builtin types, and the
> use of a binary operator means that care may be needed in order to
> format tuples and dictionaries correctly. As the new string formatting
> syntax is more powerful, flexible, extensible and handles tuples and
> dictionaries naturally, it is recommended for new code. However, there
> are no current plans to deprecate printf-style formatting."
>

+1 on rephrasing that doc section, but I wouldn't mention deprecation at
all. It's alright to keep calling % formatting "old style" and encouraging
.format instead, of course.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Vinay Sajip]

The PEP does not consider an alternative idea such as using "from __future__
import unicode_literals" in code which needs to run on 2.x, together with e.g. a
callable n('xxx') which can be used where native strings are needed. This avoids
the need to reintroduce the u'xxx' literal syntax, makes it explicit where
native strings are needed, is less obtrusive that u('xxx') or u'xxx' because
typically there will be vastly fewer places where you need native strings, and
is unlikely to impose a major runtime penalty when compared with u('xxx')
(again, because of the lower frequency of occurrence).

Even if you have arguments against this idea, I think it's at least worth
mentioning in the PEP with any counter-arguments you have.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

[Matt Joiner]

Big +1
On Feb 26, 2012 4:41 PM, "Eli Bendersky"  wrote:

>
> On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" wrote:
>
>> > I find that strange, especially for an expert Python dev. I, a newbie,
>> > find it far friendlier (and easier for a new programmer to grasp).
>> > Maybe it's because I use it all the time, and you don't?
>>
>> That is most likely the case. You learn by practice. For that very
>> reason, the claim "and easier for a new programmer to grasp" is
>> difficult to prove. It was easier for *you*, since you started using
>> it, and then kept using it. I don't recall any particular obstacles
>> learning % formatting (even though I did for C, not for C++).
>> Generalizing that it is *easier* is invalid: you just didn't try
>> learning that instead first, and now you can't go back in a state
>> where either are new to you.
>>
>> C++ is very similar here: they also introduced a new way of output
>> (iostreams, and << overloading). I used that for a couple of years,
>> primarily because people said that printf is "bad" and "not object-
>> oriented". I then recognized that there is nothing wrong with printf
>> per so, and would avoid std::cout in C++ these days, in favor of
>> std::printf (yes, I know that it does have an issue with type safety).
>>
>
> Not to mention that the performance of iostreams is pretty bad, to the
> extent that some projects actively discourage using them in favor of either
> C-style IO (fgets, printf, etc.) or custom IO implementations. This is
> marginally off-topic, although it does show that an initial thought of
> deprecating an existing functionality for new one doesn't always work out
> in the long run, even for super-popular languages like C++.
>
> Eli
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Larry Hastings]

On 02/25/2012 03:31 PM, Guido van Rossum wrote:

On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw  wrote:

On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:

* Change the result of os.stat to be a custom class rather than a
   PyStructSequence.  Support the sequence protocol on the custom class but
   mark it PendingDeprecation [...]

+1

Yeah, the sequence protocol is outdated here.

Would this be a mutable or an immutable object?


Immutable, just like the current PyStructSequence object.


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rejecting PEP 410 (Use decimal.Decimal type for timestamps)

[Larry Hastings]

On 02/25/2012 07:04 PM, Guido van Rossum wrote:

As to the changes alluded to in #5: Let os.stat() and friends return
extra fields st_atime_ns [...] We don't need a PEP for
this proposal; we can just open a tracker issue and hash out the
details during the code review.


http://bugs.python.org/issue14127


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Serhiy Storchaka]

26.02.12 11:05, Vinay Sajip написав(ла):

The PEP does not consider an alternative idea such as using "from __future__
import unicode_literals" in code which needs to run on 2.x, together with e.g. a
callable n('xxx') which can be used where native strings are needed. This avoids
the need to reintroduce the u'xxx' literal syntax, makes it explicit where
native strings are needed, is less obtrusive that u('xxx') or u'xxx' because
typically there will be vastly fewer places where you need native strings, and
is unlikely to impose a major runtime penalty when compared with u('xxx')
(again, because of the lower frequency of occurrence).


n = str

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Vinay Sajip]

Serhiy Storchaka  gmail.com> writes:


> n = str

Well, n to indicate that native string is required.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

[Eli Bendersky]

> It probably wouldn't be very difficult to make element_new() the tp_new
> of Element_Type, and expose that type as "Element".
> That would settle the issue nicely and avoid compatibility concerns :)
>
> Regards
>

I guess it's not as simple as that. element_new doesn't quite have the
signature required for tp_new. Besides, a constructor would also be needed
(since a subclass may be interested in calling Element.__init__) and
there's no natural function to serve as the constructor.

I've opened issue 14128 to track this. I plan to implement a standard
tp_new and tp_init functions for Element to expose it as a class from the
module. element_new also happens to be used internally - I'll try to
refactor to avoid code duplication as much as possible.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Steven D'Aprano]

Vinay Sajip wrote:

Serhiy Storchaka  gmail.com> writes:



n = str


Well, n to indicate that native string is required.


str indicates the native string type, because it *is* the native string type. 
By definition, str = str in both Python 2.x and Python 3.x. There's no point 
in aliasing it to "n".


Besides, "n" is commonly used for ints. It would be disturbing for me to read 
code with n a function or type, particularly one that returns a string.


I think your suggestion is not well explained. You suggested a function n, 
expected to take a string literal. The example you gave earlier was:


n('xxx')

But it seems to me that this is a no-op, because 'xxx' is already the native 
string type. In Python 2, it gives a str (byte-string), which the n() function 
converts to a byte-string. In Python 3, it gives a str (unicode-string), which 
the n() function converts to a unicode-string.




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Nick Coghlan]

On Sun, Feb 26, 2012 at 7:05 PM, Vinay Sajip  wrote:
> The PEP does not consider an alternative idea such as using "from __future__
> import unicode_literals" in code which needs to run on 2.x, together with 
> e.g. a
> callable n('xxx') which can be used where native strings are needed. This 
> avoids
> the need to reintroduce the u'xxx' literal syntax, makes it explicit where
> native strings are needed, is less obtrusive that u('xxx') or u'xxx' because
> typically there will be vastly fewer places where you need native strings, and
> is unlikely to impose a major runtime penalty when compared with u('xxx')
> (again, because of the lower frequency of occurrence).
>
> Even if you have arguments against this idea, I think it's at least worth
> mentioning in the PEP with any counter-arguments you have.

The PEP already mentions that. In fact, all bar the first paragraph in
the "Rationale and Goals" section discusses it. However, it's the last
paragraph that explains why using that particular future import is, in
and of itself, a bad idea:


Additionally, the vast majority of people who maintain Python 2.x
codebases are more familiar with Python 2.x semantics, and a per-file
difference in literal meanings will be very annoying for them in the
long run. A quick poll on Twitter about the use of the division future
import supported my suspicions that people opt out of
behaviour-changing future imports because they are a maintenance
burden. Every time you review code you have to check the top of the
file to see if the behaviour was changed. Obviously that was an
unscientific informal poll, but it might be something worth
considering.


As soon as you allow the use of "from __future__ import
unicode_literals" or a module level "__metaclass__ = type", you can't
review diffs in isolation any more - whether the diff is correct or
not will depend on the presence or absence of module level tweak to
the language semantics.

Future imports work well for things like absolute imports, new
keywords, or statements becoming functions - if the future import is
missing when you expected it to be present (or vice-versa) will result
in a quick SyntaxError or ImportError that will point you directly to
the offending code. Unicode literals and implicitly creating new-style
classes are a different matter - for those, if the module level
modification takes place (or doesn't take place when you expected it
to be there), you get unexpected changes in behaviour instead of a
clear exception that refers directly to the source of the problem.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Nick Coghlan]

On Sun, Feb 26, 2012 at 9:00 PM, Steven D'Aprano  wrote:
> I think your suggestion is not well explained. You suggested a function n,
> expected to take a string literal. The example you gave earlier was:
>
> n('xxx')
>
> But it seems to me that this is a no-op, because 'xxx' is already the native
> string type. In Python 2, it gives a str (byte-string), which the n()
> function converts to a byte-string. In Python 3, it gives a str
> (unicode-string), which the n() function converts to a unicode-string.

Vinay's suggestion was that it be used in conjunction with the "from
__future__ import unicode_literals" import, so that you could write:

b"" # Binary data
"" # Text (unicode) data
str("") # Native string type

It reduces the problem (compared to omitting the import and using a
u() function), but it's still ugly and still involves the "action at a
distance" of the unicode literals import.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] struct.pack inconsistencies between platforms

[pmon mail]

Hi

I have found myself in the following troubling situation.

I'm running the following code on a Python 2.6.5 on Linux x86:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> len(struct.pack('L',0))
4

Works as expected and documented (http://docs.python.org/library/struct.html
).

I'm running the same code on a MacPro (OS X 10.7.3) and I'm getting the
following:
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on
darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> len(struct.pack('L',0))
8

Documentation clearly states that the 'L' is a 4 byte integer.

Is this a bug? I'm I missing something?

Thanks
PMon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Vinay Sajip]

Nick Coghlan  gmail.com> writes:

> The PEP already mentions that. In fact, all bar the first paragraph in
> the "Rationale and Goals" section discusses it. However, it's the last

I didn't meaning the __future__ import bit, but a discussion re. alternatives to
u('xxx').

> Future imports work well for things like absolute imports, new
> keywords, or statements becoming functions - if the future import is
> missing when you expected it to be present (or vice-versa) will result
> in a quick SyntaxError or ImportError that will point you directly to
> the offending code. Unicode literals and implicitly creating new-style
> classes are a different matter - for those, if the module level
> modification takes place (or doesn't take place when you expected it
> to be there), you get unexpected changes in behaviour instead of a
> clear exception that refers directly to the source of the problem.

I don't disagree with anything you said here. Perhaps I've been doing too much
work recently with single 2.x/3.x codebase projects, so I've just gotten to like
using Unicode literals without the u prefix. However, as the proposal doesn't
force one to use u prefixes, I'm not really objecting, especially if it speeds
transition to 3.x.

Regards,

Vinay Sajip



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct.pack inconsistencies between platforms

[Eli Bendersky]

On Sun, Feb 26, 2012 at 12:33, pmon mail  wrote:

> Hi
>
> I have found myself in the following troubling situation.
>
> I'm running the following code on a Python 2.6.5 on Linux x86:
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import struct
> >>> len(struct.pack('L',0))
> 4
>
> Works as expected and documented (
> http://docs.python.org/library/struct.html).
>
> I'm running the same code on a MacPro (OS X 10.7.3) and I'm getting the
> following:
> Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
> [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on
> darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import struct
> >>> len(struct.pack('L',0))
> 8
>
> Documentation clearly states that the 'L' is a 4 byte integer.
>
> Is this a bug? I'm I missing something?
>
>
By default pack uses native size, not standard size. On a 64-bit machine:

>>> struct.pack('=L', 0)
'\x00\x00\x00\x00'
>>> struct.pack('L', 0)
'\x00\x00\x00\x00\x00\x00\x00\x00'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Ned Batchelder]

On 2/26/2012 6:14 AM, Nick Coghlan wrote:

As soon as you allow the use of "from __future__ import
unicode_literals" or a module level "__metaclass__ = type", you can't
review diffs in isolation any more - whether the diff is correct or
not will depend on the presence or absence of module level tweak to
the language semantics.

Future imports work well for things like absolute imports, new
keywords, or statements becoming functions - if the future import is
missing when you expected it to be present (or vice-versa) will result
in a quick SyntaxError or ImportError that will point you directly to
the offending code. Unicode literals and implicitly creating new-style
classes are a different matter - for those, if the module level
modification takes place (or doesn't take place when you expected it
to be there), you get unexpected changes in behaviour instead of a
clear exception that refers directly to the source of the problem.
There are already __future__ imports that violate this principle:  from 
__future__ import division.  That doesn't mean I'm in favor of this new 
__future__, just keeping a wide angle on the viewfinder.


--Ned.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Serhiy Storchaka]

Some microbenchmarks:

$ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
1 loops, best of 100: 1.24 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
1 loops, best of 100: 1.59 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123" "str(u'foobarbaz_%d') % x"
1 loops, best of 100: 1.58 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123; n = lambda s: s" 
"n('foobarbaz_%d') % x"
1 loops, best of 100: 1.41 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123; s = 'foobarbaz_%d'" "s % x"
1 loops, best of 100: 1.22 usec per loop

There are no significant overhead to use converters.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Nick Coghlan]

On Sun, Feb 26, 2012 at 10:34 PM, Ned Batchelder  wrote:
> There are already __future__ imports that violate this principle:  from
> __future__ import division.  That doesn't mean I'm in favor of this new
> __future__, just keeping a wide angle on the viewfinder.

Armin's straw poll was actually about whether or not people used the
future import for division, rather than unicode literals. It is indeed
the same problem - and several of us had a strong preference for
forcing float division with "float(x) / y" over relying on the long
distance effect of the future import (although it was only in this
thread that I figured out exactly *why* I don't like those two, but
happily used many of the other future imports when they were
necessary).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Vinay Sajip]

Nick Coghlan  gmail.com> writes:

> It reduces the problem (compared to omitting the import and using a
> u() function), but it's still ugly and still involves the "action at a
> distance" of the unicode literals import.

I agree about the action-at-a-distance leading to non-obvious bugs and wasted
head-scratching time caused by such. It could be mitigated somewhat by
project-level conventions, e.g. that all string literals are Unicode on that
project. Then, if you put yourself in the relevant mindset when working on that
project, there are fewer surprises.

It's probably a matter of choosing the lesser among evils, since the proposal
seems to allow mixing of literals with and without u prefixes in 3.x code -
doesn't that also seem ugly?

When this came up earlier (when I think Chris McDonough raised it) the issue of
what to do on 3.2 came up, and though it has been addressed somewhat in the PEP,
it would be nice to see the suggested on-installation hook fleshed out a little
more.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Jesse Noller]

On Saturday, February 25, 2012 at 10:13 PM, Guido van Rossum wrote:
> If this can encourage more projects to support Python 3 (even if it's
> only 3.3 and later) and hence improve adoption of Python 3, I'm all
> for it.
> 
> A small quibble: I'd like to see a benchmark of a 'u' function implemented in 
> C.
> 
> --Guido
> 

After having this explained quite a bit to me by the more web-savvy folks such 
as Armin and Chris M/etc, I am a +1, the rationale makes sense, and much for 
the same reason that Guido cites, I think this will help with code bases using 
the single code base approach, and assist with overall adoption.

+1

jesse 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Armin Ronacher]

Hi,

On 2/26/12 12:34 PM, Ned Batchelder wrote:
> There are already __future__ imports that violate this principle:  from 
> __future__ import division.  That doesn't mean I'm in favor of this new 
> __future__, just keeping a wide angle on the viewfinder.
That's actually mentioned in the PEP :-)

> A quick poll on Twitter about the use of the division future import
> supported my suspicions that people opt out of behaviour-changing
> future imports because they are a maintenance burden. Every time you
> review code you have to check the top of the file to see if the
> behaviour was changed.


Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Armin Ronacher]

Hi,

On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
> Some microbenchmarks:
>
> $ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
> 1 loops, best of 100: 1.24 usec per loop
> $ python -m timeit -n 1 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
> 1 loops, best of 100: 1.59 usec per loop
> $ python -m timeit -n 1 -r 100 -s "x = 123" "str(u'foobarbaz_%d') % x"
> 1 loops, best of 100: 1.58 usec per loop
> $ python -m timeit -n 1 -r 100 -s "x = 123; n = lambda s: s"
"n('foobarbaz_%d') % x"
> 1 loops, best of 100: 1.41 usec per loop
> $ python -m timeit -n 1 -r 100 -s "x = 123; s = 'foobarbaz_%d'" "s
% x"
> 1 loops, best of 100: 1.22 usec per loop
>
> There are no significant overhead to use converters.
That's because what you're benchmarking here more than anything is the
overhead of eval() :-)  See the benchmark linked in the PEP for one that
measures the actual performance of the string literal / wrapper.


Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Armin Ronacher]

Hi,

On 2/26/12 12:42 PM, Vinay Sajip wrote:
> When this came up earlier (when I think Chris McDonough raised it) the issue 
> of
> what to do on 3.2 came up, and though it has been addressed somewhat in the 
> PEP,
> it would be nice to see the suggested on-installation hook fleshed out a 
> little
> more.
I wanted to do that but the tokenizer module is quite ugly to customize
in order to allow "u" prefixes to strings which is why I postponed that.
 It would work similar to how 2to3 is invoked however.

In case this PEP gets approved I will refactor the tokenize module while
adding support for "u" prefixes and use that as the basis for a
installation hook for older Python 3 versions.


Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Serhiy Storchaka]

26.02.12 14:42, Armin Ronacher написав(ла):

On 2/26/12 12:35 PM, Serhiy Storchaka wrote:

Some microbenchmarks:

$ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
1 loops, best of 100: 1.24 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
1 loops, best of 100: 1.59 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123" "str(u'foobarbaz_%d') % x"
1 loops, best of 100: 1.58 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123; n = lambda s: s"

"n('foobarbaz_%d') % x"

1 loops, best of 100: 1.41 usec per loop
$ python -m timeit -n 1 -r 100 -s "x = 123; s = 'foobarbaz_%d'" "s

% x"

1 loops, best of 100: 1.22 usec per loop

There are no significant overhead to use converters.

That's because what you're benchmarking here more than anything is the
overhead of eval() :-)  See the benchmark linked in the PEP for one that
measures the actual performance of the string literal / wrapper.


$ python -m timeit -n 1 -r 100 ""
1 loops, best of 100: 0.087 usec per loop

Overhead of eval is 5%.

Real code is not single string literal, every string literal occured 
together with a lot of code (getting and setting variables, attribute 
access, function calls, binary operators, unconditional and conditional 
jumps, etc), and total effect of using simple converter will be 
insignificant.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct.pack inconsistencies between platforms

[Paul Moore]

On 26 February 2012 12:34, Eli Bendersky  wrote:
> On Sun, Feb 26, 2012 at 12:33, pmon mail  wrote:
>> Documentation clearly states that the 'L' is a 4 byte integer.
>>
>> Is this a bug? I'm I missing something?
>>
>
> By default pack uses native size, not standard size. On a 64-bit machine:

As the OP points out, the documentation says that the "Standard Size"
is 4 bytes (http://docs.python.org/library/struct.html). While
"Standard Size" doesn't appear to be defined in the documentation, and
the start of the previous section (7.3.2.1. Byte Order, Size, and
Alignment) clearly states that C types are represented in native
format by default, the documentation could probably do with some
clarification.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Eli Bendersky]

>
> -   The formatting operations described here are obsolete and may go away
> in future
> -   versions of Python.  Use the new :ref:`string-formatting` in new code.
> +   The formatting operations described here are modelled on C's printf()
> +   syntax.  They only support formatting of certain builtin types.  The
> +   use of a binary operator means that care may be needed in order to
> +   format tuples and dictionaries correctly.  As the new
> +   :ref:`string-formatting` syntax is more flexible and handles tuples and
> +   dictionaries naturally, it is recommended for new code.  However, there
> +   are no current plans to deprecate printf-style formatting.
>

Please consider just deleting the last sentence. Documentation is meant for
users (often new users) and not core devs. As such, I just don't see what
it adds. If the aim to to document this intent somewhere, a PEP would be a
better place than the formal documentation.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct.pack inconsistencies between platforms

[Eli Bendersky]

On Sun, Feb 26, 2012 at 15:09, Paul Moore  wrote:

> On 26 February 2012 12:34, Eli Bendersky  wrote:
> > On Sun, Feb 26, 2012 at 12:33, pmon mail  wrote:
> >> Documentation clearly states that the 'L' is a 4 byte integer.
> >>
> >> Is this a bug? I'm I missing something?
> >>
> >
> > By default pack uses native size, not standard size. On a 64-bit machine:
>
> As the OP points out, the documentation says that the "Standard Size"
> is 4 bytes (http://docs.python.org/library/struct.html). While
> "Standard Size" doesn't appear to be defined in the documentation, and
> the start of the previous section (7.3.2.1. Byte Order, Size, and
> Alignment) clearly states that C types are represented in native
> format by default, the documentation could probably do with some
> clarification.
>
>
7.2.3.1 says, shortly after the first table:

"

Native size and alignment are determined using the C compiler’s
sizeofexpression. This is always combined with native byte order.

Standard size depends only on the format character; see the table in
the *Format
Characters* 
section.
"

To me this appears to be a reasonable definition of what "standard size"
is.

7.3.2.2 says before the size table:

"Format characters have the following meaning; the conversion between C and
Python values should be obvious given their types. The ‘Standard size’
column refers to the size of the packed value in bytes when using standard
size; that is, when the format string starts with one of '<', '>', '!' or
'='. When using native size, the size of the packed value is
platform-dependent."

Again, taken together with the previous quote, IMHO this defines the
difference between standard and native sizes clearly. If you feel
differently, feel free to open an issue suggesting a better explanation.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] State of PEP-3118 (memoryview part)

[Stefan Krah]

State of PEP-3118 (memoryview part)

Hello,

In Python 3.3 most issues with the memoryview object have been fixed
in a recent commit (3f9b3b6f7ff0). Many features have been added, see:

http://docs.python.org/dev/whatsnew/3.3.html


The underlying problems with memoryview were intricate and required
a long discussion (issue #10181) that led to a complete rewrite
of memoryobject.c.


We have several options with regard to 2.7 and 3.2:

  1) Won't fix.

  2) Backport the changes and disable as much of the new functionality
 as possible.

  3) Backport all of it (this would be the least amount of work and
 could be done relatively quickly).

  4) Nick suggested another option: put a module with the new functionality
 on PyPI. This would be quite a bit of work, and personally I don't
 have time for that.


Options 2) and 3) would ideally entail one backwards incompatible
bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
rejects integers but accepts byte objects, but according to the
struct syntax mandated by the PEP it should be the other way round.


It would be nice to get some opinions and ideas, especially of course
from the release managers.



Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Antoine Pitrou]

On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah  wrote:
> 
> The underlying problems with memoryview were intricate and required
> a long discussion (issue #10181) that led to a complete rewrite
> of memoryobject.c.
> 
> 
> We have several options with regard to 2.7 and 3.2:
> 
>   1) Won't fix.

Given the extent of the rewrite, this one has my preference.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct.pack inconsistencies between platforms

[pmon mail]

Sounds reasonable for me. Thanks!

On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky  wrote:

>
>
> On Sun, Feb 26, 2012 at 15:09, Paul Moore  wrote:
>
>> On 26 February 2012 12:34, Eli Bendersky  wrote:
>> > On Sun, Feb 26, 2012 at 12:33, pmon mail  wrote:
>> >> Documentation clearly states that the 'L' is a 4 byte integer.
>> >>
>> >> Is this a bug? I'm I missing something?
>> >>
>> >
>> > By default pack uses native size, not standard size. On a 64-bit
>> machine:
>>
>> As the OP points out, the documentation says that the "Standard Size"
>> is 4 bytes (http://docs.python.org/library/struct.html). While
>> "Standard Size" doesn't appear to be defined in the documentation, and
>> the start of the previous section (7.3.2.1. Byte Order, Size, and
>> Alignment) clearly states that C types are represented in native
>> format by default, the documentation could probably do with some
>> clarification.
>>
>>
> 7.2.3.1 says, shortly after the first table:
>
> "
>
> Native size and alignment are determined using the C compiler’s 
> sizeofexpression. This is always combined with native byte order.
>
> Standard size depends only on the format character; see the table in the 
> *Format
> Characters* 
> section.
> "
>
> To me this appears to be a reasonable definition of what "standard size"
> is.
>
> 7.3.2.2 says before the size table:
>
> "Format characters have the following meaning; the conversion between C
> and Python values should be obvious given their types. The ‘Standard size’
> column refers to the size of the packed value in bytes when using standard
> size; that is, when the format string starts with one of '<', '>', '!' or
> '='. When using native size, the size of the packed value is
> platform-dependent."
>
> Again, taken together with the previous quote, IMHO this defines the
> difference between standard and native sizes clearly. If you feel
> differently, feel free to open an issue suggesting a better explanation.
>
> Eli
>
>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Close issue #6210: Implement PEP 409

[Antoine Pitrou]

On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan  wrote:
> +
> +No debugging capability is lost, as the original exception context remains
> +available if needed (for example, if an intervening library has incorrectly
> +suppressed valuable underlying details)::

That's debatable, since you now have to *add* code if you want to print
the original exception as well. The new capability improves the
terseness and clarity of error messages at the expense of debuggability.

> +def prepare_subprocess():
> +# don't create core file
> +try:
> +setrlimit(RLIMIT_CORE, (0, 0))
> +except (ValueError, resource_error):
> +pass

Really? This sounds quite wrong, but it should *at least* explain
why a test of the "raise" statement would produce a core file!
(but I think you should consider removing this part)

> +def get_output(self, code, filename=None):
> +"""
> +Run the specified code in Python (in a new child process)
> and read the
> +output from the standard error or from a file (if filename
> is set).
> +Return the output lines as a list.
> +"""

We already have assert_python_ok and friends. It's not obvious what
this additional function achieves. Also, the "filename" argument is
never used.

> +output = re.sub('Current thread 0x[0-9a-f]+',
> +'Current thread XXX',
> +output)

This looks like output from the faulthandler module. Why would
faulthandler kick in here?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Victor Stinner]

> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the requirement that seconds and microseconds are never
> negative; e.g -1 second is represented as -1 days plus 86399 seconds.

Guido, you should switch to Python3! timedelta has a new
total_seconds() method since Python 3.2.
http://docs.python.org/py3k/library/datetime.html#datetime.timedelta.total_seconds

>>> datetime.timedelta(1).total_seconds()
86400.0
>>> datetime.timedelta(seconds=-1).total_seconds()
-1.0

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Victor Stinner]

> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the requirement that seconds and microseconds are never
> negative; e.g -1 second is represented as -1 days plus 86399 seconds.

Guido, you should switch to Python3! timedelta has a new
total_seconds() method since Python 3.2.
http://docs.python.org/py3k/library/datetime.html#datetime.timedelta.total_seconds

>>> datetime.timedelta(1).total_seconds()
86400.0
>>> datetime.timedelta(seconds=-1).total_seconds()
-1.0

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct.pack inconsistencies between platforms

[Paul Moore]

On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky  wrote:
> 7.2.3.1 says, shortly after the first table:
>
> "
>
> Native size and alignment are determined using the C compiler’s sizeof
> expression. This is always combined with native byte order.
>
> Standard size depends only on the format character; see the table in the
> Format Characters section.
>
> "
>
> To me this appears to be a reasonable definition of what "standard size"
> is.

You're right, my apologies. I skimmed a little too much. Actually, I
*could* argue that there is still some ambiguity, but as (a) the OP is
happy, and (b) until I went and read the docs, I would have expected
the current behaviour anyway, that would just just be me being
awkward. So I won't :-)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Simon Cross]

On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum  wrote:
> I still think that when you are actually interested in *using* times,
> the current float format is absolutely fine. Anybody who thinks they
> need to accurately know the absolute time that something happened with
> nanosecond accuracy is out of their mind; given relativity such times
> have an incredibly local significance anyway.

There are good scientific use cases for nanosecond time resolution
(e.g. radio astronomy) where one is actually measuring time down to
that level and taking into account propagation delays. I have first
hand experience of at least one radio telescope (MeerKAT) that is
using Python to process these sorts of timestamps (Maciej even gave a
talk on MeerKAT at PyCon 2011 :).

Often these sorts of applications just use an large integer to hold
the time. Higher-level constructs like datetime tend to be too bulky
and provide functionality that is not particularly relevant. There is
also a lot of pressure to have all the details coded by an in-house
expert (because you need complete control and understanding of them,
so you might as well do it yourself rather than continually patch,
say, Python, to match your instrument's view of how this should all
work).

Hardware capable of generating nanosecond accurate timestamps is,
however, becoming fairly easy to get hold of (a suitable crystalline
clock slaved to a decent GPS unit can get you a lot of the way) and
there are probably quite a few applications where it might become
relevant.

I'm not sure whether any of this is intended to be for or against any
side in the current discussion. :D

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Matt Joiner]

+1 for won't fix.
On Feb 26, 2012 9:46 PM, "Antoine Pitrou"  wrote:

> On Sun, 26 Feb 2012 14:27:21 +0100
> Stefan Krah  wrote:
> >
> > The underlying problems with memoryview were intricate and required
> > a long discussion (issue #10181) that led to a complete rewrite
> > of memoryobject.c.
> >
> >
> > We have several options with regard to 2.7 and 3.2:
> >
> >   1) Won't fix.
>
> Given the extent of the rewrite, this one has my preference.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Larry Hastings]

On 02/26/2012 06:51 AM, Simon Cross wrote:

There are good scientific use cases for nanosecond time resolution
(e.g. radio astronomy) where one is actually measuring time down to
that level and taking into account propagation delays. I have first
hand experience [...]
I'm not sure whether any of this is intended to be for or against any
side in the current discussion. :D


It's probably neutral.  But I do have one question: can you foresee the 
scientific community moving to a finer resolution than nanoseconds in 
our lifetimes?



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Paul Moore]

On 26 February 2012 13:41, Antoine Pitrou  wrote:
>> We have several options with regard to 2.7 and 3.2:
>>
>>   1) Won't fix.
>
> Given the extent of the rewrite, this one has my preference.

+1 (although I'd word it as "fixed in 3.3" rather than "won't fix").

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Tony Koker]

my 2 cents...

being in electronics for over 30 years, it is forever expanding in both
directions, bigger mega, giga, tera, peta, etc. AND smaller nano, pico,
femto, atto.

but, I agree that it is moot, as it is not the range, which is usually
expressed in an exponential component of the system being used (decimal,
hex., etc), and it is more a matter of significant number of digits being
operated on, at that point in time. Basically the zeroes are removed and
tracked separately.

Tony


On Sun, Feb 26, 2012 at 11:12 AM, Larry Hastings  wrote:

>
> On 02/26/2012 06:51 AM, Simon Cross wrote:
>
>> There are good scientific use cases for nanosecond time resolution
>> (e.g. radio astronomy) where one is actually measuring time down to
>> that level and taking into account propagation delays. I have first
>> hand experience [...]
>>
>> I'm not sure whether any of this is intended to be for or against any
>> side in the current discussion. :D
>>
>
> It's probably neutral.  But I do have one question: can you foresee the
> scientific community moving to a finer resolution than nanoseconds in our
> lifetimes?
>
>
> //arry/
>
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> tkoker%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Tony Koker]

Also, data collection will almost always be done by specialized hardware
and the data stored off for deferred processing and analysis.

Tony

On Sun, Feb 26, 2012 at 11:34 AM, Tony Koker  wrote:

> my 2 cents...
>
> being in electronics for over 30 years, it is forever expanding in both
> directions, bigger mega, giga, tera, peta, etc. AND smaller nano, pico,
> femto, atto.
>
> but, I agree that it is moot, as it is not the range, which is usually
> expressed in an exponential component of the system being used (decimal,
> hex., etc), and it is more a matter of significant number of digits being
> operated on, at that point in time. Basically the zeroes are removed and
> tracked separately.
>
> Tony
>
>
>
> On Sun, Feb 26, 2012 at 11:12 AM, Larry Hastings wrote:
>
>>
>> On 02/26/2012 06:51 AM, Simon Cross wrote:
>>
>>> There are good scientific use cases for nanosecond time resolution
>>> (e.g. radio astronomy) where one is actually measuring time down to
>>> that level and taking into account propagation delays. I have first
>>> hand experience [...]
>>>
>>> I'm not sure whether any of this is intended to be for or against any
>>> side in the current discussion. :D
>>>
>>
>> It's probably neutral.  But I do have one question: can you foresee the
>> scientific community moving to a finer resolution than nanoseconds in our
>> lifetimes?
>>
>>
>> //arry/
>>
>> __**_
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/**mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
>> tkoker%40gmail.com
>>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Barry Warsaw]

This seems like too strong a statement:

"Python 2.6 and Python 2.7 support syntax features from Python 3 which for
the most part make a unified code base possible. Many thought that the
unicode_literals future import might make a common source possible, but it
turns out that it's doing more harm than good."

While it may be true for *some* problem domains, such as WSGI apps, it is not
true in general, IMO.  I use this future import all the time in both libraries
and applications and it's almost always helpful.

Cheers,
-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Antoine Pitrou]

Hi,

On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher  wrote:
> 
> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
> literals for Python 3.
> 
> You can read the PEP online: http://www.python.org/dev/peps/pep-0414/

I don't understand this sentence:

> The automatic upgrading of binary strings to unicode strings that
> would be enabled by this proposal would make it much easier to port
> such libraries over.

What "automatic upgrading" is that talking about?

> For instance, the urllib module in Python 2 is using byte strings,
> and the one in Python 3 is using unicode strings.

Are you talking about urllib.parse perhaps?

> By leveraging a native string, users can avoid having to adjust for
> that.

What does "leveraging a native string" mean here?

> The following is an incomplete list of APIs and general concepts that
> use native strings and need implicit upgrading to unicode in Python
> 3, and which would directly benefit from this support

I'm confused. This PEP talks about unicode literals, not native string
literals, so why would these APIs "directly benefit from this support"?

Thanks

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Performance of u()

[Antoine Pitrou]

On Sat, 25 Feb 2012 19:13:26 -0800
Guido van Rossum  wrote:
> If this can encourage more projects to support Python 3 (even if it's
> only 3.3 and later) and hence improve adoption of Python 3, I'm all
> for it.
> 
> A small quibble: I'd like to see a benchmark of a 'u' function implemented in 
> C.

Even without implementing it in C, caching the results makes it much
less prohibitive in tight loops:

if sys.version_info >= (3, 0):
def u(value):
return value
else:
def u(value, _lit_cache={}):
if value in _lit_cache:
return _lit_cache[value]
s = _lit_cache[value] = unicode(value, 'unicode-escape')
return s


u'\N{SNOWMAN}barbaz'   -> 1 loops, best of 3: 0.00928 usec per loop
u('\N{SNOWMAN}barbaz') -> 1000 loops, best of 3: 0.15 usec per loop
u'foobarbaz_%d' % x-> 100 loops, best of 3: 0.424 usec per loop
u('foobarbaz_%d') % x  -> 100 loops, best of 3: 0.598 usec per loop

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

[Joao S. O. Bueno]

On 24 February 2012 22:20,  wrote:

> I find the .format syntax too complicated and difficult to learn. It has
> so many bells and whistles, making it more than just a *mini* language.
> So for my own code, I always prefer % formatting for simplicity.
>
> +1



> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Simon Cross]

On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings  wrote:
> It's probably neutral.  But I do have one question: can you foresee the
> scientific community moving to a finer resolution than nanoseconds in our
> lifetimes?

I think we're already there. Even just in radio astronomy new arrays
like ALMA which operate a terahertz frequencies are looking at
picosecond or possibly femtosecond timing accuracy (ALMA operates at
~1000 times higher frequency than MeerKAT so they need ~1000 times
more accurate timing).

E.g. 
http://www.guardian.co.uk/science/2012/jan/29/alma-radio-telescope-chile-astronomy

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Antoine Pitrou]

On Sun, 26 Feb 2012 19:50:10 +0100
mar...@v.loewis.de wrote:
> >> -   The formatting operations described here are obsolete and may go away
> >> in future
> >> -   versions of Python.  Use the new :ref:`string-formatting` in new code.
> >> +   The formatting operations described here are modelled on C's printf()
> >> +   syntax.  They only support formatting of certain builtin types.  The
> >> +   use of a binary operator means that care may be needed in order to
> >> +   format tuples and dictionaries correctly.  As the new
> >> +   :ref:`string-formatting` syntax is more flexible and handles tuples and
> >> +   dictionaries naturally, it is recommended for new code.  However, there
> >> +   are no current plans to deprecate printf-style formatting.
> >>
> >
> > Please consider just deleting the last sentence. Documentation is meant for
> > users (often new users) and not core devs. As such, I just don't see what
> > it adds. If the aim to to document this intent somewhere, a PEP would be a
> > better place than the formal documentation.
> 
> I'd rather leave the last sentence, and delete the penultimate sentence.
> The last sentence is useful information to the end user ("we will not
> deprecate printf-style formatting, so there is no need to change existing
> code"). I'd drop the penultimate sentence because there is no consensus
> that it is a useful recommendation (and it is certainly not a statement
> of fact).

It would be nice to call it something else than "printf-style
formatting". While it is certainly modelled on printf(), knowledge of C
or printf is not required to understand %-style formatting, nor even to
appreciate it.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

[Guido van Rossum]

On Sun, Feb 26, 2012 at 10:11 AM, Simon Cross
 wrote:
> On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings  wrote:
>> It's probably neutral.  But I do have one question: can you foresee the
>> scientific community moving to a finer resolution than nanoseconds in our
>> lifetimes?
>
> I think we're already there. Even just in radio astronomy new arrays
> like ALMA which operate a terahertz frequencies are looking at
> picosecond or possibly femtosecond timing accuracy (ALMA operates at
> ~1000 times higher frequency than MeerKAT so they need ~1000 times
> more accurate timing).
>
> E.g. 
> http://www.guardian.co.uk/science/2012/jan/29/alma-radio-telescope-chile-astronomy

None of that bears any relation on the precision of the timers
available in the OS through Python's time and os APIs.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Michael Foord]

On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:

> 
> Hi,
> 
> On Sat, 25 Feb 2012 20:23:39 +
> Armin Ronacher  wrote:
>> 
>> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
>> literals for Python 3.
>> 
>> You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
> 
> I don't understand this sentence:
> 
>> The automatic upgrading of binary strings to unicode strings that
>> would be enabled by this proposal would make it much easier to port
>> such libraries over.
> 
> What "automatic upgrading" is that talking about?

If you use native string syntax (no prefix) then moving from Python 2 to Python 
3 automatically "upgrades" (I agree an odd choice of word) byte string literals 
to unicode string literals.

> 
>> For instance, the urllib module in Python 2 is using byte strings,
>> and the one in Python 3 is using unicode strings.
> 
> Are you talking about urllib.parse perhaps?
> 
>> By leveraging a native string, users can avoid having to adjust for
>> that.
> 
> What does "leveraging a native string" mean here?

By using native string syntax (without the unicode literals future import) then 
apis that take a binary string in Python 2 and a unicode string in Python 3 
"just work" with the same syntax. You are "leveraging" native syntax to use the 
same apis with different types across the different version of Python. 


> 
>> The following is an incomplete list of APIs and general concepts that
>> use native strings and need implicit upgrading to unicode in Python
>> 3, and which would directly benefit from this support
> 
> I'm confused. This PEP talks about unicode literals, not native string
> literals, so why would these APIs "directly benefit from this support"?

Because sometimes in your code you want to specify "native strings" and 
sometimes you want to specify Unicode strings. There is no single *syntax* that 
is compatible with both Python 2 and Python 3 that permits this. (If you use 
"u" for Unicode in Python 2 and no prefix for native strings then your code is 
Python 3 incompatible, if you use the future import so that your strings are 
unicode in both Python 2 and Python 3 then you lose the syntax for native 
strings.)

Michael


> 
> Thanks
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Eli Bendersky]

> It would be nice to call it something else than "printf-style
> formatting". While it is certainly modelled on printf(), knowledge of C
> or printf is not required to understand %-style formatting, nor even to
> appreciate it.
>

+1. The section is already titled "old string formatting operations" so if
this name is acceptable it should be reused. If it's not, it should then be
consistently changed everywhere.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Terry Reedy]

On 2/26/2012 1:50 PM, mar...@v.loewis.de wrote:


Zitat von Eli Bendersky :



- The formatting operations described here are obsolete and may go away
in future
- versions of Python. Use the new :ref:`string-formatting` in new code.
+ The formatting operations described here are modelled on C's printf()
+ syntax. They only support formatting of certain builtin types. The
+ use of a binary operator means that care may be needed in order to
+ format tuples and dictionaries correctly. As the new
+ :ref:`string-formatting` syntax is more flexible and handles tuples
and
+ dictionaries naturally, it is recommended for new code. However, there
+ are no current plans to deprecate printf-style formatting.



Please consider just deleting the last sentence. Documentation is
meant for
users (often new users) and not core devs. As such, I just don't see what
it adds. If the aim to to document this intent somewhere, a PEP would
be a
better place than the formal documentation.


I'd rather leave the last sentence, and delete the penultimate sentence.
The last sentence is useful information to the end user ("we will not
deprecate printf-style formatting, so there is no need to change existing
code"). I'd drop the penultimate sentence because there is no consensus
that it is a useful recommendation (and it is certainly not a statement
of fact).


I agree that the 'recommendation' is subjective, even though I strongly 
agree with it *for new Python programmers who are not already familiar 
with printf style formatting*. However, that sort of nuanced 
recommendation goes better in a HowTo. Statements about non-deprecation 
are also out of place as that is the default. So I agree with both of 
you. Let us drop both of the last two sentences. Then we can all be happy.


There is a difference between 'There are no current plans to ...' and 
'We will never ...'. However, '...' should not be discussed or even 
proposed or even mentioned until there is a bug-free automatic 
converter. I think the recent rehashing was mostly a needless irritation 
except as it prompted a doc update.


---
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Armin Ronacher]

Hi,

On 2/26/12 5:45 PM, Antoine Pitrou wrote:
>> The automatic upgrading of binary strings to unicode strings that
>> would be enabled by this proposal would make it much easier to port
>> such libraries over.
> 
> What "automatic upgrading" is that talking about?
The word "upgrade" is probably something that should be changed.  It
refers to the fact that 'foo' is a bytestring in 2.x and the same syntax
means a unicode string in Python 3.  This is exactly what is necessary
for interfaces that were promoted to unicode interfaces in Python 3 (for
instance Python identifiers, URLs etc.)

> Are you talking about urllib.parse perhaps?
Not only the parsing module.  Headers on the urllib.request module are
unicode as well.  What the PEP is referring to is the urllib/urlparse
and cgi module which was largely consolidated to the urllib package in
Python 3.

> What does "leveraging a native string" mean here?
It means by using a native string to achieve the automatic upgrading
which "does the right thing" in a lot of situations.

> I'm confused. This PEP talks about unicode literals, not native string
> literals, so why would these APIs "directly benefit from this support"?
The native string literal already exists.  It disappears if
`unicode_literals` are future imported which is why this is relevant
since the unicode literals future import in 2.x is recommended by some
for making libraries run in both 2.x and 3.x.


Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Chris Angelico]

On Mon, Feb 27, 2012 at 5:54 AM, Antoine Pitrou  wrote:
> It would be nice to call it something else than "printf-style
> formatting". While it is certainly modelled on printf(), knowledge of C
> or printf is not required to understand %-style formatting, nor even to
> appreciate it.

-1. Calling it "printf-style" ties it in with its origins just as the
term "regex" does for the 're' module. There are printf-derived
features in quite a few high level languages; they may differ somewhat
(Pike's sprintf() can do columnar displays; PHP's vsprintf takes an
array, not some weird and mythical varargs token), but in their basics
they will be similar. The name is worth keeping.

Chris Angelico
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Barry Warsaw]

On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:

>It reduces the problem (compared to omitting the import and using a
>u() function), but it's still ugly and still involves the "action at a
>distance" of the unicode literals import.

Frankly, that doesn't bother me at all.  I've been using the future import in
all my code pretty successfully for a long while now.  It's much more
important for a project to use or not use the future import consistently, and
then there really should be no confusion when looking at the code for that
project.

I'm not necessarily saying I'm opposed to the purpose of the PEP.  I do think
it's unnecessary for most Python problem domains, but can appreciate that WSGI
apps are feeling a special pain here that should be addressed somehow.  It
would be nice however if the solution were in the form of a separate module
that could be used in earlier Python versions.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Nick Coghlan]

On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky  wrote:
>
>> It would be nice to call it something else than "printf-style
>> formatting". While it is certainly modelled on printf(), knowledge of C
>> or printf is not required to understand %-style formatting, nor even to
>> appreciate it.
>
>
> +1. The section is already titled "old string formatting operations" so if
> this name is acceptable it should be reused. If it's not, it should then be
> consistently changed everywhere.

I deliberately chose printf-style as being value neutral (whereas
old-style vs new-style carries a heavier recommendation that you
should be using the new one). Sure you don't need to know printf to
understand it, but it needs *some* kind of name, and "printf-style"
acknowledges its roots. Another value-neutral term is "mod-style",
which describes how it is invoked (and I believe we do use that in a
few places already).

I didn't actually expect that paragraph to be incorporated wholesale
into the docs - it was intended as a discussion starter, not a
finished product. Aside from the last two sentences, the other big
problem with it is that print-style formatting *does* support
formatting arbitrary objects, they're just forced to go through type
coercions whereas .format() allows objects to define their own
formatting specifiers (such as datetime with strftime strings).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah.

[Brett Cannon]

On Sun, Feb 26, 2012 at 12:13, antoine.pitrou wrote:

> http://hg.python.org/cpython/rev/1d7472b015f0
> changeset:   75296:1d7472b015f0
> user:Antoine Pitrou 
> date:Sun Feb 26 18:09:50 2012 +0100
> summary:
>  Issue #14080: fix sporadic test_imp failure.  Patch by Stefan Krah.
>
> files:
>  Lib/test/test_imp.py |  1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
>
> diff --git a/Lib/test/test_imp.py b/Lib/test/test_imp.py
> --- a/Lib/test/test_imp.py
> +++ b/Lib/test/test_imp.py
> @@ -325,6 +325,7 @@
> self.addCleanup(cleanup)
> # Touch the __init__.py file.
> support.create_empty_file('pep3147/__init__.py')
> +importlib.invalidate_caches()
> expected___file__ = os.sep.join(('.', 'pep3147', '__init__.py'))
> m = __import__('pep3147')
> self.assertEqual(m.__file__, expected___file__, (m.__file__,
> m.__path__))


Should that just go into support.create_empty_file()? Since it's just a
performance issue I don't see it causing unexpected test failures and it
might help with any future issues.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Greg Ewing]

Stefan Krah wrote:


Options 2) and 3) would ideally entail one backwards incompatible
bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
rejects integers but accepts byte objects, but according to the
struct syntax mandated by the PEP it should be the other way round.


Maybe a compromise could be made to accept both in the
backport? That would avoid breaking old code while allowing
code that does the right thing to work.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Chris McDonough]

On Sun, 2012-02-26 at 16:06 -0500, Barry Warsaw wrote:
> On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:
> 
> >It reduces the problem (compared to omitting the import and using a
> >u() function), but it's still ugly and still involves the "action at a
> >distance" of the unicode literals import.
> 
> Frankly, that doesn't bother me at all.  I've been using the future import in
> all my code pretty successfully for a long while now.  It's much more
> important for a project to use or not use the future import consistently, and
> then there really should be no confusion when looking at the code for that
> project.

That's completely reasonable in a highly controlled project with
relatively few highly-bought-in contributors.  In projects with lots of
hit-and-run contributors, though, it's more desirable to have things
meet a rule of least surprise.

Much of the software I work on is Python 3 compatible, but it's still
used primarily on Python 2.  Because most people still care primarily
about Python 2, and most don't have a lot of Python 3 experience, it's
extremely common to see folks submitting patches with u'' literals in
them.

> I'm not necessarily saying I'm opposed to the purpose of the PEP.  I do think
> it's unnecessary for most Python problem domains, but can appreciate that WSGI
> apps are feeling a special pain here that should be addressed somehow.  It
> would be nice however if the solution were in the form of a separate module
> that could be used in earlier Python versions.

If we use the unicode_literals future import, or some other exernal
module strategy, it doesn't help much with the hitnrun contributor
thing, I fear.

- C


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Cameron Simpson]

On 27Feb2012 07:13, Nick Coghlan  wrote:
| On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky  wrote:
| >> It would be nice to call it something else than "printf-style
| >> formatting". While it is certainly modelled on printf(), knowledge of C
| >> or printf is not required to understand %-style formatting, nor even to
| >> appreciate it.
| >
| >
| > +1. The section is already titled "old string formatting operations" so if
| > this name is acceptable it should be reused. If it's not, it should then be
| > consistently changed everywhere.
| 
| I deliberately chose printf-style as being value neutral (whereas
| old-style vs new-style carries a heavier recommendation that you
| should be using the new one). Sure you don't need to know printf to
| understand it, but it needs *some* kind of name, and "printf-style"
| acknowledges its roots.

+1 here from me too: it _is_ printf in roots and several format
specifiers (%d, %s etc). If you know printf you _immediately_ know a lot
about what you can expect, and if you don't you know know a little about
its roots.

| Another value-neutral term is "mod-style",
| which describes how it is invoked (and I believe we do use that in a
| few places already).

A -1 on "mod-style" from me. While it does use the "%" operator symbol, in no
other way is it like the "mod" arithmetic operation.

I think docs _should_ occasionally hint at preferred approaches. The
new new formatting is a deliberate Python change. Without some
rationale/editorial it flies in the face of the "one obvious way to do
things" notion. It shouldn't be overdone, but neither should it be
absent.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Ignorance is preferable to error; and he is less remote from the truth
who believes nothing, than he who believes what is wrong.
- Thomas Jefferson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Terry Reedy]

Stefan, thank you for the massive rewrite.

On 2/26/2012 11:21 AM, Paul Moore wrote:

On 26 February 2012 13:41, Antoine Pitrou  wrote:

We have several options with regard to 2.7 and 3.2:

   1) Won't fix.


Given the extent of the rewrite, this one has my preference.


+1 (although I'd word it as "fixed in 3.3" rather than "won't fix").


I agree with 3.3 only. My suggestion: when you close the issues, change 
Versions to 3.3 and Resolution to 'fixed'. On the main issue, change 
Type to 'enhancement'. Add a message to others saying something like


"This was fixed for 3.3 in #x by rewriting and enhancing memoryview. 
The new version was not backported because it would either add new 
features, which is forbidden for bugfix releases, or would require 
substantial work to try to disable them without introducing bugs, 
without a guarantee that that would work"


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Georg Brandl]

On 02/26/2012 10:13 PM, Nick Coghlan wrote:

On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky  wrote:



 It would be nice to call it something else than "printf-style
 formatting". While it is certainly modelled on printf(), knowledge of C
 or printf is not required to understand %-style formatting, nor even to
 appreciate it.



 +1. The section is already titled "old string formatting operations" so if
 this name is acceptable it should be reused. If it's not, it should then be
 consistently changed everywhere.


I deliberately chose printf-style as being value neutral (whereas
old-style vs new-style carries a heavier recommendation that you
should be using the new one). Sure you don't need to know printf to
understand it, but it needs *some* kind of name, and "printf-style"
acknowledges its roots. Another value-neutral term is "mod-style",
which describes how it is invoked (and I believe we do use that in a
few places already).


I've seen "percent-formatting", which is neutral, accurate and doesn't
require any previous knowledge.  (The new one could be "format-formatting"
then, which is a tad awkward. :)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] State of PEP-3118 (memoryview part)

[Antoine Pitrou]

On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah  wrote:
> State of PEP-3118 (memoryview part)
> 
> Hello,
> 
> In Python 3.3 most issues with the memoryview object have been fixed
> in a recent commit (3f9b3b6f7ff0).

Oh and congrats for doing this, of course.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah.

[Antoine Pitrou]

On Sun, 26 Feb 2012 16:18:54 -0500
Brett Cannon  wrote:
> >
> > diff --git a/Lib/test/test_imp.py b/Lib/test/test_imp.py
> > --- a/Lib/test/test_imp.py
> > +++ b/Lib/test/test_imp.py
> > @@ -325,6 +325,7 @@
> > self.addCleanup(cleanup)
> > # Touch the __init__.py file.
> > support.create_empty_file('pep3147/__init__.py')
> > +importlib.invalidate_caches()
> > expected___file__ = os.sep.join(('.', 'pep3147', '__init__.py'))
> > m = __import__('pep3147')
> > self.assertEqual(m.__file__, expected___file__, (m.__file__,
> > m.__path__))
> 
> 
> Should that just go into support.create_empty_file()? Since it's just a
> performance issue I don't see it causing unexpected test failures and it
> might help with any future issues.

I don't think adding import-specific workarounds in create_empty_file()
is a very good idea.
(I'm also not sure why that function exists)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Nick Coghlan]

Ah, thanks, I knew there was another term that had a new-style counterpart:
percent formatting vs brace formatting.

--
Sent from my phone, thus the relative brevity :)
On Feb 27, 2012 7:53 AM, "Georg Brandl"  wrote:

> On 02/26/2012 10:13 PM, Nick Coghlan wrote:
>
>> On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky  wrote:
>>
>>>
>>>   It would be nice to call it something else than "printf-style
  formatting". While it is certainly modelled on printf(), knowledge of C
  or printf is not required to understand %-style formatting, nor even to
  appreciate it.

>>>
>>>
>>>  +1. The section is already titled "old string formatting operations" so
>>> if
>>>  this name is acceptable it should be reused. If it's not, it should
>>> then be
>>>  consistently changed everywhere.
>>>
>>
>> I deliberately chose printf-style as being value neutral (whereas
>> old-style vs new-style carries a heavier recommendation that you
>> should be using the new one). Sure you don't need to know printf to
>> understand it, but it needs *some* kind of name, and "printf-style"
>> acknowledges its roots. Another value-neutral term is "mod-style",
>> which describes how it is invoked (and I believe we do use that in a
>> few places already).
>>
>
> I've seen "percent-formatting", which is neutral, accurate and doesn't
> require any previous knowledge.  (The new one could be "format-formatting"
> then, which is a tad awkward. :)
>
> Georg
>
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Brett Cannon]

On Sat, Feb 25, 2012 at 22:13, Guido van Rossum  wrote:

> If this can encourage more projects to support Python 3 (even if it's
> only 3.3 and later) and hence improve adoption of Python 3, I'm all
> for it.
>
>
+1 from me for the same reasons.

If this were to go in then for Python 3.3 the section of the porting HOWTO
on what to do when you support Python 2.6 and later (
http://docs.python.org/howto/pyporting.html#python-2-3-compatible-source)
would change to:

* Use ``from __future__ import print_functions`` OR use ``print(x)`` but
always with a single argument OR use six
* Use ``from __future__ import unicode_literals`` OR make sure to use the
'u' prefix for all Unicode strings (and then mention the concept of native
strings) or use six
* Use the 'b' prefix for byte literals or use six

All understandable and with either a __future__ import solution or
syntactic support solution for all issues, giving people the choice of
either approach for what they prefer for each approach. I would also be
willing to move the Python 2/3 compatible source section to the top and
thus implicitly become the preferred way to port since people in the
community have seemingly been gravitating towards that approach even
without this help.

-Brett


A small quibble: I'd like to see a benchmark of a 'u' function implemented
> in C.
>
> --Guido
>
> On Sat, Feb 25, 2012 at 12:23 PM, Armin Ronacher
>  wrote:
> > Hi,
> >
> > I just uploaded PEP 414 which proposes am optional 'u' prefix for string
> > literals for Python 3.
> >
> > You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
> >
> > This is a followup to the discussion about this topic here on the
> > mailinglist and on twitter/IRC over the last few weeks.
> >
> >
> > Regards,
> > Armin
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Vinay Sajip]

Chris McDonough  plope.com> writes:

> If we use the unicode_literals future import, or some other exernal
> module strategy, it doesn't help much with the hitnrun contributor
> thing, I fear.

Surely some curating of hit-and-run contributions takes place? If you accept
contributions from hit-and-run contributors without changes, ISTM that could
compromise the quality of the codebase somewhat.

Also, is not the overall impact on the codebase of hit-and-run contributors
small compared to more the impact from involved contributors?

Regards,


Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

[Barry Warsaw]

On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:

>On Sat, Feb 25, 2012 at 22:13, Guido van Rossum  wrote:
>
>> If this can encourage more projects to support Python 3 (even if it's
>> only 3.3 and later) and hence improve adoption of Python 3, I'm all
>> for it.
>>
>>
>+1 from me for the same reasons.

Just to be clear, I'm solidly +1 on anything we can do to increase the pace of
Python 3 migration.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Terry Reedy]

On 2/26/2012 5:38 PM, Nick Coghlan wrote:

Ah, thanks, I knew there was another term that had a new-style
counterpart: percent formatting vs brace formatting.


Hooray!
Exact parallel and value-neutral.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Guido van Rossum]

On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy  wrote:
> On 2/26/2012 5:38 PM, Nick Coghlan wrote:
>>
>> Ah, thanks, I knew there was another term that had a new-style
>> counterpart: percent formatting vs brace formatting.
>
> Hooray!
> Exact parallel and value-neutral.

Can we stop it with the "political correctness" already? The old style
is best named printf-style formatting because that's the origin of the
format language, and there are many other programming languages that
support the same formatting language (with minor variations). I care
less about what we call the new style -- "new style" or "format
method" both work for me.

I also would like to suggest that, even if the reality is that we
can't deprecate it today, *eventually*, at *some* *distant* point in
the future we ought to start deprecating printf-style formatting -- it
really does have a couple of nasty traps that keep catching people
unawares. In the mean time it doesn't hurt to use terms that make
people ever so slightly uneasy with using the old style for new code,
while also committing to not throwing it out until Python 4 comes
around.

That said, for consistency's sake, if you add formatting code to an
existing module that uses the old style, please stick to the old
style. And to avoid disasters, also please don't go on a library-wide
rampage of wholesale conversions. The time to start using the new
formatting is when writing new modules or packages, or possibly when
doing a major refactoring/upgrade of an existing module or package.

One thing I'd like to see happening regardless is support for
new-style formatting in the logging module. It's a little tricky to
think how that would work, alas -- should this be a property of the
logger or of the call?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Chris McDonough]

On Sun, 2012-02-26 at 23:06 +, Vinay Sajip wrote:
> Chris McDonough  plope.com> writes:
> 
> > If we use the unicode_literals future import, or some other exernal
> > module strategy, it doesn't help much with the hitnrun contributor
> > thing, I fear.
> 
> Surely some curating of hit-and-run contributions takes place? If you accept
> contributions from hit-and-run contributors without changes, ISTM that could
> compromise the quality of the codebase somewhat.

Nah.  Real developers just accept all pull requests and let god sort it
out. ;-)

But seriously, the less time it takes me to review and fix a pull
request from a casual contributor, the better.

- C


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Cameron Simpson]

On 26Feb2012 15:33, Guido van Rossum  wrote:
| One thing I'd like to see happening regardless is support for
| new-style formatting in the logging module. It's a little tricky to
| think how that would work, alas -- should this be a property of the
| logger or of the call?

Surely the call? The caller doesn't necessarily know anything about the
loggers in play, so if a logger sprouts different message formating
syntax the caller is hosed.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

A Master is someone who started before you did. - Gary Zukav
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Mark Lawrence]

On 26/02/2012 23:33, Guido van Rossum wrote:

On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy  wrote:

On 2/26/2012 5:38 PM, Nick Coghlan wrote:


Ah, thanks, I knew there was another term that had a new-style
counterpart: percent formatting vs brace formatting.


Hooray!
Exact parallel and value-neutral.


Can we stop it with the "political correctness" already? The old style
is best named printf-style formatting because that's the origin of the
format language, and there are many other programming languages that
support the same formatting language (with minor variations). I care
less about what we call the new style -- "new style" or "format
method" both work for me.

I also would like to suggest that, even if the reality is that we
can't deprecate it today, *eventually*, at *some* *distant* point in
the future we ought to start deprecating printf-style formatting -- it
really does have a couple of nasty traps that keep catching people
unawares. In the mean time it doesn't hurt to use terms that make
people ever so slightly uneasy with using the old style for new code,
while also committing to not throwing it out until Python 4 comes
around.

That said, for consistency's sake, if you add formatting code to an
existing module that uses the old style, please stick to the old
style. And to avoid disasters, also please don't go on a library-wide
rampage of wholesale conversions. The time to start using the new
formatting is when writing new modules or packages, or possibly when
doing a major refactoring/upgrade of an existing module or package.

One thing I'd like to see happening regardless is support for
new-style formatting in the logging module. It's a little tricky to
think how that would work, alas -- should this be a property of the
logger or of the call?



Just thinking out loud that a tool along the lines of 2to3 aimed 
specifically at changing string formatting would be some encouragement 
for people to switch.  Maybe a project for someone being looked after on 
the mentors ml?


--
Cheers.

Mark Lawrence.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

[Larry Hastings]

On 02/26/2012 03:33 PM, Guido van Rossum wrote:

One thing I'd like to see happening regardless is support for
new-style formatting in the logging module. It's a little tricky to
think how that would work, alas -- should this be a property of the
logger or of the call?


There already is some support.  logging.Formatter objects can be 
initialized with a "style" parameter, making this a property of the 
logger.  (New in 3.2.)


   http://docs.python.org/py3k/library/logging.html#formatter-objects

Is that what you had in mind?


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Greg Ewing]

Nick Coghlan wrote:


Armin's straw poll was actually about whether or not people used the
future import for division, rather than unicode literals. It is indeed
the same problem


There are differences, though. Personally I'm very glad of the
division import -- it's the only thing that keeps me sane when
using floats. The alternative is not only butt-ugly but imposes
an annoying performance penalty. I don't mind occasionally
needing to glance at the top of a module in order to get the
benefits.

On the other hand, it's not much of a burden to put 'u' in
front of string literals, and there is no performance difference.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 415: Implementing PEP 409 differently

[Benjamin Peterson]

PEP: 415
Title: Implementing PEP 409 differently
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Feb-2012
Post-History: 26-Feb-2012


Abstract


PEP 409 allows PEP 3134 exception contexts and causes to be suppressed when the
exception is printed. This is done using the ``raise exc from None``
syntax. This PEP proposes to implement context and cause suppression
differently.

Rationale
=

PEP 409 changes ``__cause__`` to be ``Ellipsis`` by default. Then if
``__cause__`` is set to ``None`` by ``raise exc from None``, no context or cause
will be printed should the exception be uncaught.

The main problem with this scheme is it complicates the role of
``__cause__``. ``__cause__`` should indicate the cause of the exception not
whether ``__context__`` should be printed or not. This use of ``__cause__`` is
also not easily extended in the future. For example, we may someday want to
allow the programmer to select which of ``__context__`` and ``__cause__`` will
be printed. The PEP 409 implementation is not amendable to this.

The use of ``Ellipsis`` is a hack. Before PEP 409, ``Ellipsis`` was used
exclusively in extended slicing. Extended slicing has nothing to do with
exceptions, so it's not clear to someone inspecting an exception object why
``__cause__`` should be set to ``Ellipsis``. Using ``Ellipsis`` by default for
``__cause__`` makes it asymmetrical with ``__context__``.

Proposal


A new attribute on ``BaseException``, ``__suppress_context__``, will be
introduced. The ``raise exc from None`` syntax will cause
``exc.__suppress_context__`` to be set to ``True``. Exception printing code will
check for the attribute to determine whether context and cause will be
printed. ``__cause__`` will return to its original purpose and values.

There is precedence for ``__suppress_context__`` with the
``print_line_and_file`` exception attribute.

Patches
===

There is a patch on `Issue 14133`_.


References
==

.. _issue 14133:
   http://bugs.python.org/issue6210

Copyright
=

This document has been placed in the public domain.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Terry Reedy]

On 2/26/2012 7:46 AM, Armin Ronacher wrote:

I am not enthusiastic about adding duplication that is useless for 
writing Python 3 code, but like others, I do want to encourage more 
porting of libraries to run with Python 3. I understand that the unicode 
transition seems the be the biggest barrier, especially for some 
applications. It is OK with me if ported code only runs on 3.3+, with 
its improved unicode.


If u'' is added, I would like it to be added as deprecated in the doc 
with a note that it is only intended for multi-version Python 2/3 code.



In case this PEP gets approved I will refactor the tokenize module while
adding support for "u" prefixes and use that as the basis for a
installation hook for older Python 3 versions.


I presume such a hook would simply remove 'u' prefixes and would run 
*much* faster than 2to3. If such a hook is satisfactory for 3.2, why 
would it not be satisfactory for 3.3?


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] New-style formatting in the logging module (was Re: cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats)

[Nick Coghlan]

On Mon, Feb 27, 2012 at 10:44 AM, Larry Hastings  wrote:
> On 02/26/2012 03:33 PM, Guido van Rossum wrote:
>>
>> One thing I'd like to see happening regardless is support for
>> new-style formatting in the logging module. It's a little tricky to
>> think how that would work, alas -- should this be a property of the
>> logger or of the call?
>
>
> There already is some support.  logging.Formatter objects can be initialized
> with a "style" parameter, making this a property of the logger.  (New in
> 3.2.)
>
>   http://docs.python.org/py3k/library/logging.html#formatter-objects
>
> Is that what you had in mind?

It's half the puzzle (since composing the event fields into the actual
log output is a logger action, you know the style when you supply the
format string). The other half is that logging's lazy formatting
currently only supporting printf-style format strings - to use brace
formatting you currently have to preformat the messages, so you incur
the formatting cost even if the message gets filtered out by the
logging configuration. For that, a logger setting doesn't work, since
one logger may be shared amongst multiple modules, some of which may
use printf formatting, others brace formatting.

It could possibly be a flag to getLogger() though - provide a facade
on the existing logger type that sets an additional event property to
specify the lazy formatting style.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 415: Implementing PEP 409 differently

[Nick Coghlan]

Thanks for writing that up. I'd be amenable if the PEP was clearly
updated to say that ``raise exc from cause`` would change from being
syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise
exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause;
_hidden.__suppress_context__ = True; raise exc``. The patch should
then be implemented accordingly (including appropriate updates to the
language reference).

I previously didn't like this solution because I thought it would
require a special case for None in the syntax expansion, but I have
now realised that isn't the case (since the new flag can be set
unconditionally regardless of the value assigned to __cause__).

Code that wants to display both __cause__ and __context__ can then
just either set __cause__ directly, or else later switch off the
context suppression.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Nick Coghlan]

On Mon, Feb 27, 2012 at 11:55 AM, Terry Reedy  wrote:
> I presume such a hook would simply remove 'u' prefixes and would run *much*
> faster than 2to3. If such a hook is satisfactory for 3.2, why would it not
> be satisfactory for 3.3?

Because an import hook is still a lot more complicated than "Write
modern code that runs on 2.6+ and follows certain guidelines and it
will also just run on 3.3+".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Close issue #6210: Implement PEP 409

[Nick Coghlan]

On Sun, Feb 26, 2012 at 11:54 PM, Antoine Pitrou  wrote:
>> +    def prepare_subprocess():
>> +        # don't create core file
>> +        try:
>> +            setrlimit(RLIMIT_CORE, (0, 0))
>> +        except (ValueError, resource_error):
>> +            pass
>
> Really? This sounds quite wrong, but it should *at least* explain
> why a test of the "raise" statement would produce a core file!
> (but I think you should consider removing this part)

I managed to convince myself before checking it in that a bunch of the
weirdness in Ethan's subprocess test made sense, but I think I was
just wrong about that (I certainly can't come up with a sane
rationalisation now).

Assigned a bug to myself to fix it: http://bugs.python.org/issue14136

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com