Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

2016-06-08 Thread Franklin? Lee
On Jun 7, 2016 8:52 PM, "Eric Snow" wrote: > * the default class *definition* namespace is now ``OrderdDict`` > * the order in which class attributes are defined is preserved in the By using an OrderedDict, names are ordered by first definition point, rather than location of the used definition.

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

2016-06-08 Thread Victor Stinner
> Abstract > > > This PEP changes the default class definition namespace to ``OrderedDict``. > Furthermore, the order in which the attributes are defined in each class > body will now be preserved in ``type.__definition_order__``. This allows > introspection of the original definition ord

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Victor Stinner
Hi, > Currently, the ``bytes`` and ``bytearray`` constructors accept an integer > argument and interpret it as meaning to create a zero-initialised sequence > of the given size:: > (...) > This PEP proposes to deprecate that behaviour in Python 3.6, and remove it > entirely in Python 3.7. I'm opp

Re: [Python-Dev] C99

2016-06-08 Thread Victor Stinner
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython. In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit.

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Serhiy Storchaka
On 08.06.16 11:04, Victor Stinner wrote: Currently, the ``bytes`` and ``bytearray`` constructors accept an integer argument and interpret it as meaning to create a zero-initialised sequence of the given size:: (...) This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entire

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Serhiy Storchaka
On 08.06.16 02:03, Nick Coghlan wrote: That said, it occurs to me that there's a reasonably strong composability argument in favour of a view-based approach: a view will work with operator.itemgetter() and other sequence consuming APIs, while special methods won't. The "like-memoryview-but-not" v

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Paul Sokolovsky
Hello, On Wed, 8 Jun 2016 11:53:06 +0300 Serhiy Storchaka wrote: > On 08.06.16 11:04, Victor Stinner wrote: > >> Currently, the ``bytes`` and ``bytearray`` constructors accept an > >> integer argument and interpret it as meaning to create a > >> zero-initialised sequence of the given size:: > >>

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Serhiy Storchaka
On 08.06.16 13:37, Paul Sokolovsky wrote: The obvious way to create the bytes object of length n is b'\0' * n. That's very inefficient: it requires allocating useless b'\0', then a generic function to repeat arbitrary memory block N times. If there's a talk of Python to not be laughed at for be

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Paul Sokolovsky
Hello, On Wed, 8 Jun 2016 14:05:19 +0300 Serhiy Storchaka wrote: > On 08.06.16 13:37, Paul Sokolovsky wrote: > >> The obvious way to create the bytes object of length n is b'\0' * > >> n. > > > > That's very inefficient: it requires allocating useless b'\0', then > > a generic function to repeat

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Serhiy Storchaka
On 08.06.16 14:26, Paul Sokolovsky wrote: On Wed, 8 Jun 2016 14:05:19 +0300 Serhiy Storchaka wrote: On 08.06.16 13:37, Paul Sokolovsky wrote: The obvious way to create the bytes object of length n is b'\0' * n. That's very inefficient: it requires allocating useless b'\0', then a generic fu

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Paul Sokolovsky
Hello, On Wed, 8 Jun 2016 14:45:22 +0300 Serhiy Storchaka wrote: [] > > $ ./run-bench-tests bench/bytealloc* > > bench/bytealloc: > > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py > > 11.244s (+237.35%) bench/bytealloc-2-repeat.py > > If the performance of creating an immutable array

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

2016-06-08 Thread Eric Snow
On Wed, Jun 8, 2016 at 12:07 AM, Franklin? Lee wrote: > On Jun 7, 2016 8:52 PM, "Eric Snow" wrote: >> * the default class *definition* namespace is now ``OrderdDict`` >> * the order in which class attributes are defined is preserved in the > > By using an OrderedDict, names are ordered by first d

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Barry Warsaw
On Jun 08, 2016, at 02:01 AM, Martin Panter wrote: >Bytes.byte() is a great idea. But what’s the point or use case of >bytearray.byte(), a mutable array of one pre-defined byte? I like Bytes.byte() too. I would guess you'd want the same method on bytearray for duck typing APIs. -Barry _

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

2016-06-08 Thread Eric Snow
On Wed, Jun 8, 2016 at 1:07 AM, Victor Stinner wrote: >> Abstract >> >> >> This PEP changes the default class definition namespace to ``OrderedDict``. >> Furthermore, the order in which the attributes are defined in each class >> body will now be preserved in ``type.__definition_order__``

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Steven D'Aprano
On Wed, Jun 08, 2016 at 10:04:08AM +0200, Victor Stinner wrote: > It's common that users complain that Python core developers like > breaking the compatibility at each release. No more common as users complaining that Python features are badly designed and crufty and should be fixed. Whatever w

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

2016-06-08 Thread Franklin? Lee
On Jun 8, 2016 8:13 AM, "Paul Sokolovsky" wrote: > > Hello, > > On Wed, 8 Jun 2016 14:45:22 +0300 > Serhiy Storchaka wrote: > > [] > > > > $ ./run-bench-tests bench/bytealloc* > > > bench/bytealloc: > > > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py > > > 11.244s (+237.35%) bench/bytea

[Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Neil Schemenauer
[I've posted something about this on python-ideas but since I now have some basic working code, I think it is more than an idea.] I think the uptake of Python 3 is starting to accelerate. That's good. However, there are still millions or maybe billions of lines of Python code that still needs to

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Ryan Gonzalez
On Jun 8, 2016 4:04 PM, "Neil Schemenauer" wrote: > > [I've posted something about this on python-ideas but since I now > have some basic working code, I think it is more than an idea.] > > I think the uptake of Python 3 is starting to accelerate. That's > good. However, there are still millions

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Fred Drake
On Wed, Jun 8, 2016 at 5:33 PM, Ryan Gonzalez wrote: > What about something like "unpythonic" or similar? Or perhaps... antipythy? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list Pyt

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Greg Ewing
On Jun 8, 2016 4:04 PM, "Neil Schemenauer" > wrote: > > I've temporarily named it "Pragmatic Python". I'd like a better > name if someone can suggest one. Maybe something like Perverted, > Debauched or Impure Python. Python Two and Three Quarters. -- Greg _

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Oleg Broytman
On Thu, Jun 09, 2016 at 10:08:50AM +1200, Greg Ewing wrote: > >On Jun 8, 2016 4:04 PM, "Neil Schemenauer" >> wrote: > > > > > > I've temporarily named it "Pragmatic Python". I'd like a better > > > name if someone can suggest one. Maybe something like Perverted, > > > De

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

2016-06-08 Thread Terry Reedy
On 6/8/2016 4:07 AM, Victor Stinner wrote: Abstract This PEP changes the default class definition namespace to ``OrderedDict``. Furthermore, the order in which the attributes are defined in each class body will now be preserved in ``type.__definition_order__``. This allows introspectio

[Python-Dev] Round 2 of the Python Language Summit coverage at LWN

2016-06-08 Thread Jake Edge
Howdy python-dev, The second batch of articles from the Python Language Summit is now available. The starting point is here: https://lwn.net/Articles/688969/ (or here for non-subscribers: https://lwn.net/SubscriberLink/688969/91cbeeaf32807914/ for the next few hours anyway, it will be open to al

Re: [Python-Dev] Round 2 of the Python Language Summit coverage at LWN

2016-06-08 Thread Ben Finney
Jake Edge writes: > The second batch of articles from the Python Language Summit is now > available. Thank you for writing these (and many other good articles) for Linux Weekly News! High-quality, dependable reporting is very valuable for our community. -- \ “To punish me for my contempt

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Victor Stinner
2016-06-08 23:01 GMT+02:00 Neil Schemenauer : > - code coming out of 2to3 runs correctly on this modified Python Stop using 2to3. This tool adds many useless changes when you only care of Python 2.7 and Python 3.4+. I suggest to use better tools like 2to6, modernize or my own tool: https://pypi.py

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

2016-06-08 Thread Guido van Rossum
Or write your own set of 2to3 fixers that *are* necessary. On Wed, Jun 8, 2016 at 6:11 PM, Victor Stinner wrote: > 2016-06-08 23:01 GMT+02:00 Neil Schemenauer : > > - code coming out of 2to3 runs correctly on this modified Python > > Stop using 2to3. This tool adds many useless changes when you