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

[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 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.python.org/pypi/sixer
>
> "Add Python 3 support to Python 2 applications using the six module."
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



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

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

[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.python.org/pypi/sixer

"Add Python 3 support to Python 2 applications using the six module."

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

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

[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 of authority, Fate has made me an |
  `\   authority myself.” —Albert Einstein, 1930-09-18 |
_o__)  |
Ben Finney

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

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

[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 all after that using either link.)

I have added five more sessions since last week's three, still six more
to go, which should all be done by next week (and I'll post here again).

Python's GitHub migration and workflow changes:
https://lwn.net/Articles/689937/
https://lwn.net/SubscriberLink/689937/1fd56367a74206bf/

The state of mypy: https://lwn.net/Articles/690081/
https://lwn.net/SubscriberLink/690081/5c35679cafe42d1b/

An introduction to pytype: https://lwn.net/Articles/690150/
https://lwn.net/SubscriberLink/690150/660acde532afb8a3/

PyCharm and type hints: https://lwn.net/Articles/690186/
https://lwn.net/SubscriberLink/690186/848c447551204ffe/

Python 3.6 and 3.7 release cycles: https://lwn.net/Articles/690404/
https://lwn.net/SubscriberLink/690404/73cfb918fa21d27c/

The articles will be freely available (without using the
SubscriberLink) to the world at large in a week (and the next batch the
week after that) ... until then, feel free to share the SubscriberLinks.

Hopefully I have captured things reasonably well.  If there are
corrections or clarifications needed, though, I recommend posting them
as comments on the article.

enjoy!

jake

-- 
Jake Edge - LWN - j...@lwn.net - http://lwn.net
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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
introspection of the original definition order, e.g. by class decorators.

Note: just to be clear, this PEP is *not* about changing ``__dict__`` for
classes to ``OrderedDict``.


What is the cost in term of performance?

What can be slower: define a new class and/or instanciate a class?


A class is defined once, used many times to instantiate instances.  Each 
instance is typically used many times, with many lookups.  So it is 
self.class_attribute lookups, like method lookups, that likely matter 
the most, and which are not changed by the PEP.


--
Terry Jan Reedy

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

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

[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,
> > > Debauched or Impure Python.
> 
> Python Two and Three Quarters.

   QOTW! :-D

> -- 
> Greg

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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

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

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

[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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 or maybe billions of lines
> of Python code that still needs to be ported.  It is beneficial to
> the Python ecosystem if this code can get ported.
>
> My idea is to make a stepping stone version of Python, between 2.7.x
> and 3.x that eases the porting job.  The high level goals are:
>
> - code coming out of 2to3 runs correctly on this modified Python
>
> - code that runs without warnings on this modified Python will run
>   correctly on Python 3.x.
>
> Achieving these goals is not technically possible.  Still, I want to
> reduce as much as possible the manual work involved in porting.
> Incrementally fixing code that generates warnings is a lot easier
> than trying to fix an entire application or library at once.
>
> I have a very early version on github:
>
> https://github.com/nascheme/ppython
>
> I'm hoping if people find it useful then they would contribute
> backwards compatibility fixes that help their applications or
> librarys run.  I am currently running a newly 2to3 ported
> application on it.  At this time there is no warning generated but I
> would rather get a warning then have one of my customers run into a
> porting bug.
>
> To be clear, I'm not proposing that these backwards compatiblity
> features go into Python 3.x or that this modified Python becomes the
> standard version.  It is purely an intermediate step in getting code
> ported to Python 3.
>
> 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.
>

...Perverted Python? Ouch.

What about something like "unpythonic" or similar?

> Regards,
>
>   Neil
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 be ported.  It is beneficial to
the Python ecosystem if this code can get ported.

My idea is to make a stepping stone version of Python, between 2.7.x
and 3.x that eases the porting job.  The high level goals are:

- code coming out of 2to3 runs correctly on this modified Python

- code that runs without warnings on this modified Python will run
  correctly on Python 3.x.

Achieving these goals is not technically possible.  Still, I want to
reduce as much as possible the manual work involved in porting.
Incrementally fixing code that generates warnings is a lot easier
than trying to fix an entire application or library at once.

I have a very early version on github:

https://github.com/nascheme/ppython

I'm hoping if people find it useful then they would contribute
backwards compatibility fixes that help their applications or
librarys run.  I am currently running a newly 2to3 ported
application on it.  At this time there is no warning generated but I
would rather get a warning then have one of my customers run into a
porting bug.

To be clear, I'm not proposing that these backwards compatiblity
features go into Python 3.x or that this modified Python becomes the
standard version.  It is purely an intermediate step in getting code
ported to Python 3.

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.

Regards,

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

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

[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/bytealloc-2-repeat.py
> >
> > If the performance of creating an immutable array of n zero bytes is
> > important in MicroPython, it is worth to optimize b"\0" * n.
>
> No matter how you optimize calloc + something, it's always slower than
> just calloc.

`bytes(n)` *is* calloc + something. It's a lookup of and call to a global
function. (Unless MicroPython optimizes away lookups for builtins, in which
case it can theoretically optimize b"\0".__mul__.)

On the other hand, b"\0" is a constant, and * is an operator lookup that
succeeds on the first argument (meaning, perhaps, a successful branch
prediction). As a constant, it is only created once, so there's no
intermediate object created.

AFAICT, the first requires optimizing global function lookups + calls, and
the second requires optimizing lookup and *successful* application of
__mul__ (versus failure + fallback to some __rmul__), and repetitions of a
particular `bytes` object (which can be interned and checked against). That
means there is room for either to win, depending on the efforts of the
implementers.

(However, `bytearray` has no syntax for literals (and therefore easy
constants), and is a more valid and, AFAIK, more practical concern.)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 we do, we can't win. If we fix misfeatures, people complain. If 
we don't fix them, people complain. Sometimes the same people, depending 
on their specific needs. "Fix this, because it annoys me, but don't fix 
that, because I'm used to it and it doesn't annoy me any more."

*shrug*

Ultimately it comes down to a subjective feeling as to which is worse. 
My own subjective feeling is that, in the long run, we'll be better off 
fixing bytes than keeping it, and the longer we wait to fix it, the 
harder it will be.


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

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

[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__``.  This allows
>> introspection of the original definition order, e.g. by class decorators.
>>
>> Note: just to be clear, this PEP is *not* about changing ``__dict__`` for
>> classes to ``OrderedDict``.
>
> What is the cost in term of performance?

Do you mean the cost of the PEP?  The extra cost is negligible:
creating an OrderedDict + mutation operations on it.  Note that it is
only used during class definition (execution of the class body).

>
> What can be slower: define a new class and/or instanciate a class?

By "instantiate" do you mean the equivalent of "type(...)" or do you
mean creating a new instance of a class?  As noted above, the impact
of using OrderedDict during class definition is negligible.  During
definition the cost of other operations will usually dwarf any extra
overhead from using an OrderedDict.

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

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

[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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 definition point, rather
> than location of the used definition.
>
> For example, the definition order of the following will be "x, y", even
> though the definitions actually bound to the name are in order "y, x".
> class C:
> x = 0
> def y(self): return 'y'
> def x(self): return 'x'
>
> Is that okay?

In practice that will seldom be an issue.  In the few cases where it
could possibly be a problem, the class may explicitly set
__definition_order__.

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

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

[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 of n zero bytes is 
> important in MicroPython, it is worth to optimize b"\0" * n.

No matter how you optimize calloc + something, it's always slower than
just calloc.

> For now CPython is the main implementation of Python 3 

Indeed, and it already has bytes(N). So, perhaps nothing should be done
about it except leaving it alone. Perhaps, more discussion should go
into whether there's need for .iterbytes() if there's [i:i+1] already.
(I personally skip that, as I find [i:i+1] perfectly ok, and while I
can't understand how people may be not ok with it up to wanting
something more, I leave such possibility).

> and bytes(n)
> is slower than b"\0" * n in CPython.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 function to repeat arbitrary memory block N times. If
there's a talk of Python to not be laughed at for being SLOW, there
would rather be efficient ways to deal with blocks of binary data.


Do you have any evidences for this claim?


Yes, it's written above, let me repeat it: bytes(n) is (can be)
calloc(1, n) underlyingly, while b"\0" * n is a more complex algorithm.



$ ./python -m timeit -s 'n = 1' -- 'bytes(n)'
100 loops, best of 3: 1.32 usec per loop
$ ./python -m timeit -s 'n = 1' -- 'b"\0" * n'
100 loops, best of 3: 0.858 usec per loop


I don't know how inefficient CPython's bytes(n) or how efficient
repetition (maybe 1-byte repetitions are optimized into memset()?), but
MicroPython (where bytes(n) is truly calloc(n)) gives expected results:

$ ./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 of n zero bytes is 
important in MicroPython, it is worth to optimize b"\0" * n.


For now CPython is the main implementation of Python 3 and bytes(n) is 
slower than b"\0" * n in CPython.



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

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

[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 arbitrary memory block N times. If
> > there's a talk of Python to not be laughed at for being SLOW, there
> > would rather be efficient ways to deal with blocks of binary data.
> 
> Do you have any evidences for this claim?

Yes, it's written above, let me repeat it: bytes(n) is (can be)
calloc(1, n) underlyingly, while b"\0" * n is a more complex algorithm. 

> 
> $ ./python -m timeit -s 'n = 1' -- 'bytes(n)'
> 100 loops, best of 3: 1.32 usec per loop
> $ ./python -m timeit -s 'n = 1' -- 'b"\0" * n'
> 100 loops, best of 3: 0.858 usec per loop

I don't know how inefficient CPython's bytes(n) or how efficient
repetition (maybe 1-byte repetitions are optimized into memset()?), but
MicroPython (where bytes(n) is truly calloc(n)) gives expected results:

$ ./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


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 being SLOW, there would rather
be efficient ways to deal with blocks of binary data.


Do you have any evidences for this claim?

$ ./python -m timeit -s 'n = 1' -- 'bytes(n)'
100 loops, best of 3: 1.32 usec per loop
$ ./python -m timeit -s 'n = 1' -- 'b"\0" * n'
100 loops, best of 3: 0.858 usec per loop


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

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

[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::
> >> (...)
> >> This PEP proposes to deprecate that behaviour in Python 3.6, and
> >> remove it entirely in Python 3.7.
> >
> > I'm opposed to this change (presented like that). Please stop
> > breaking the backward compatibility in minor versions.
> 
> The argument for deprecating bytes(n) is that this has different
> meaning in Python 2,

That's artifact (as in: defect) of "bytes" (apparently) being a flat
alias of "str" in Python2, without trying to validate its arguments. It
would be sad if thinkos in Python2 implementation dictate how Python3
should work. It's not too late to fix it in Python2 by issuing s CVE
along the lines of "Lack of argument validation in Python2 bytes()
constructor may lead to insecure code."

> and when backport a code to Python 2 or write
> 2+3 compatible code there is a risk to make a mistake. This argument
> is not applicable to bytearray(n).
> 
> > *If* you still want to deprecate bytes(n), you must introduce an
> > helper working on *all* Python versions. Obviously, the helper must
> > be avaialble and work for Python 2.7. Maybe it can be the six
> > module. Maybe something else.
> 
> 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 being SLOW, there would rather
be efficient ways to deal with blocks of binary data.

> It works in all Python versions starting from 2.6. I don't see the
> need in bytes(n) and bytes.zeros(n). There are no special methods for
> creating a list or a string of size n.

So, above, unless you specifically mean having bytearray.zero() and not
having bytes.zero(). But then the whole purpose of the presented PEP is
make API more, not less consistent. Having random gaps in bytes vs
bytearray API isn't going to help anyone.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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" view type
could also take any bytes-like object as input, similar to memoryview
itself.


Something like:

class chunks:
def __init__(self, seq, size):
self._seq = seq
self._size = size

def __len__(self):
return len(self._seq) // self._size

def __getitem__(self, i):
chunk = self._seq[i: i + self._size]
if len(chunk) != self._size:
raise IndexError
return chunk

(but needs more checks and slices support).

It would be useful for general sequences too.

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

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

[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
entirely in Python 3.7.


I'm opposed to this change (presented like that). Please stop breaking
the backward compatibility in minor versions.


The argument for deprecating bytes(n) is that this has different meaning 
in Python 2, and when backport a code to Python 2 or write 2+3 
compatible code there is a risk to make a mistake. This argument is not 
applicable to bytearray(n).



*If* you still want to deprecate bytes(n), you must introduce an
helper working on *all* Python versions. Obviously, the helper must be
avaialble and work for Python 2.7. Maybe it can be the six module.
Maybe something else.


The obvious way to create the bytes object of length n is b'\0' * n. It 
works in all Python versions starting from 2.6. I don't see the need in 
bytes(n) and bytes.zeros(n). There are no special methods for creating a 
list or a string of size n.



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

Re: [Python-Dev] C99

[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. It was very common to
get a compilation error only on MSVC when a variable was defined in
the middle of a function. We are now using
-Werror=declaration-after-statement with GCC because of MSVC!

Maybe GCC has an option to ask for the subset of the C99 standard
compatible with MSVC? Something like "-std=c99 -pedantic"?

Note: I tried -pedantic, GCC emits a lot of warnings on code which
looks valid and/or is protected with #ifdef for features specific to
GCC like computed goto.

Victor

2016-06-07 21:45 GMT+02:00 Guido van Rossum :
> We should definitely keep supporting MSVC.
>
> --Guido (mobile)
>
> On Jun 7, 2016 12:39 PM, "Sturla Molden"  wrote:
>>
>> Victor Stinner  wrote:
>>
>> > Is it worth to support a compiler that in 2016 doesn't support the C
>> > standard released in 1999, 17 years ago?
>>
>> MSVC only supports C99 when its needed for C++11 or some MS extension to
>> C.
>>
>> Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC
>> are the viable options we have on Windows (and perhaps Embarcadero, but I
>> haven't used C++ builder for a very long time). Even MinGW does not fully
>> support C99, because it depends on Microsoft's CRT. If we think MSVC and
>> MinGW are worth supporting, we cannot just use C99 indiscriminantly.
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 opposed to this change (presented like that). Please stop breaking
the backward compatibility in minor versions.

I'm porting Python 2 code to Python 3 for longer than 2 years. First,
Python 3 only proposed to immediatly drop Python 2 support using the
2to3 tool. It simply doesn't work because you must port incrementally
all dependencies, so you must write code working with Python 2 and
Python 3 using the same code base. A few people tried to duplicate
repositories, projects, project name, etc. to have one version for
Python 2 and one version for Python 3, but IMHO it's even worse. It's
very difficult to handle dependencies using that.

It took a few years until six was widely used and that pip was popular
enough to be able to add six as a *dependency* (and not put an old
copy in the project).

Basically, you propose to introduce a backward incompatible change for
free (I fail to see the benefit of replacing bytes(n) with
bytes.zeros(n)) and without obvious way to write code compatible with
Python <= 3.6 and Python >= 3.7.

Moreover, a single cycle is way too short to port all code in the wild.

It's common that users complain that Python core developers like
breaking the compatibility at each release. Recently, I saw a list of
applications which need to be ported to Python 3.5, while they work
perfectly on Python 3.4.

*If* you still want to deprecate bytes(n), you must introduce an
helper working on *all* Python versions. Obviously, the helper must be
avaialble and work for Python 2.7. Maybe it can be the six module.
Maybe something else.

In Perl 5, there is a nice "use 5.12;" pragma to explicitly ask to
keep the compatiiblity with Perl 5.12. This pragma allows to change
the language more easily, since you can port code file by file. I
don't know if it's technically possible in Python, maybe not for all
kinds of backward incompatible changes.

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

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

[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 order, e.g. by class decorators.
>
> Note: just to be clear, this PEP is *not* about changing ``__dict__`` for
> classes to ``OrderedDict``.

What is the cost in term of performance?

What can be slower: define a new class and/or instanciate a class?

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

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

[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.

For example, the definition order of the following will be "x, y", even
though the definitions actually bound to the name are in order "y, x".
class C:
x = 0
def y(self): return 'y'
def x(self): return 'x'

Is that okay?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

Ethan Furman writes:

 > * Deprecate passing single integer values to ``bytes`` and
 >   ``bytearray``

Why?  This is a slightly awkward idiom compared to .zeros (EITBI etc),
but your 32-bit clock will roll over before we can actually remove it.
There are a lot of languages that do this kind of initialization of
arrays based on ``count``.  If you want to do something useful here,
add an optional argument (here in ridiculous :-) generality:

bytes(count, tile=[0]) -> bytes(tile * count)

where ``tile`` is a Sequence of a type that is acceptable to bytes
anyway, or Sequence[int], which is treated as

b"".join([bytes(chr(i)) for i in tile] * count])

Interpretation of ``count`` of course  i bikesheddable, with at least
one alternative interpretation (length of result bytes, with last tile
truncated if necessary).

 > * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors

this is an API break if you take the deprecation as a mandate (which
eventual removal does indicate).  And backward compatibility for
clients of the bytes API means that we violate TOOWTDI indefinitely,
on a constructor of quite specialized utility.  Yuck.

-1 on both.

Barry Warsaw writes later in thread:

 > We can't change bytes.__getitem__ but we can add another method
 > that returns single byte objects?  I think it's still a bit of a
 > pain to extract single bytes even with .iterbytes().

+1  ISTM that more than the other changes, this is the most important
one.

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