[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2014-08-08 - 2014-08-15)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4602 ( +0)
  closed 29371 (+31)
  total  33973 (+31)

Open issues with patches: 2175 


Issues opened (23)
==

#21166: Bus error in pybuilddir.txt 'python -m sysconfigure --generate
http://bugs.python.org/issue21166  reopened by ned.deily

#22176: update internal libffi copy to 3.1, introducing AArch64 and PO
http://bugs.python.org/issue22176  opened by doko

#22177: Incorrect version reported after downgrade
http://bugs.python.org/issue22177  opened by jpe5605

#22179: Focus stays on Search Dialog when text found in editor
http://bugs.python.org/issue22179  opened by BreamoreBoy

#22181: os.urandom() should use Linux 3.17 getrandom() syscall
http://bugs.python.org/issue22181  opened by haypo

#22182: distutils.file_util.move_file unpacks wrongly an exception
http://bugs.python.org/issue22182  opened by Claudiu.Popa

#22185: Occasional RuntimeError from Condition.notify
http://bugs.python.org/issue22185  opened by dougz

#22186: Typos in .py files
http://bugs.python.org/issue22186  opened by iwontbecreative

#22187: commands.mkarg() buggy in East Asian locales
http://bugs.python.org/issue22187  opened by jwilk

#22188: test_gdb fails on invalid gdbinit
http://bugs.python.org/issue22188  opened by lekensteyn

#22189: collections.UserString missing some str methods
http://bugs.python.org/issue22189  opened by ncoghlan

#22191: warnings.__all__ incomplete
http://bugs.python.org/issue22191  opened by pitrou

#22192: dict_values objects are hashable
http://bugs.python.org/issue22192  opened by roippi

#22193: Add _PySys_GetSizeOf()
http://bugs.python.org/issue22193  opened by serhiy.storchaka

#22194: access to cdecimal / libmpdec API
http://bugs.python.org/issue22194  opened by pitrou

#22195: Make it easy to replace print() calls with logging calls
http://bugs.python.org/issue22195  opened by pitrou

#22196: namedtuple documentation could/should mention the new Enum typ
http://bugs.python.org/issue22196  opened by lelit

#22197: Allow better verbosity / output control in test cases
http://bugs.python.org/issue22197  opened by pitrou

#22198: Odd floor-division corner case
http://bugs.python.org/issue22198  opened by mark.dickinson

#22199: 2.7 sysconfig._get_makefile_filename should be sysconfig.get_m
http://bugs.python.org/issue22199  opened by jamercee

#22200: Remove distutils checks for Python version
http://bugs.python.org/issue22200  opened by takluyver

#22201: python -mzipfile fails to unzip files with folders created by 
http://bugs.python.org/issue22201  opened by Antony.Lee

#22203: inspect.getargspec() returns wrong spec for builtins
http://bugs.python.org/issue22203  opened by suor



Most recent 15 issues with no replies (15)
==

#22201: python -mzipfile fails to unzip files with folders created by 
http://bugs.python.org/issue22201

#22200: Remove distutils checks for Python version
http://bugs.python.org/issue22200

#22197: Allow better verbosity / output control in test cases
http://bugs.python.org/issue22197

#22196: namedtuple documentation could/should mention the new Enum typ
http://bugs.python.org/issue22196

#22194: access to cdecimal / libmpdec API
http://bugs.python.org/issue22194

#22189: collections.UserString missing some str methods
http://bugs.python.org/issue22189

#22188: test_gdb fails on invalid gdbinit
http://bugs.python.org/issue22188

#22181: os.urandom() should use Linux 3.17 getrandom() syscall
http://bugs.python.org/issue22181

#22179: Focus stays on Search Dialog when text found in editor
http://bugs.python.org/issue22179

#22173: Update lib2to3.tests and test_lib2to3 to use test discovery
http://bugs.python.org/issue22173

#22164: cell object cleared too early?
http://bugs.python.org/issue22164

#22163: max_wbits set incorrectly to -zlib.MAX_WBITS in tarfile, shoul
http://bugs.python.org/issue22163

#22159: smtpd.PureProxy and smtpd.DebuggingServer do not work with dec
http://bugs.python.org/issue22159

#22158: RFC 6531 (SMTPUTF8) support in smtpd.PureProxy
http://bugs.python.org/issue22158

#22153: There is no standard TestCase.runTest implementation
http://bugs.python.org/issue22153



Most recent 15 issues waiting for review (15)
=

#22200: Remove distutils checks for Python version
http://bugs.python.org/issue22200

#22199: 2.7 sysconfig._get_makefile_filename should be sysconfig.get_m
http://bugs.python.org/issue22199

#22193: Add _PySys_GetSizeOf()
http://bugs.python.org/issue22193

#22186: Typos in .py files
http://bugs.python.org/issue22186

#22185: Occasional RuntimeError from Condition.notify
http://bugs.python.org/issue22185

#22182: distutils.file_util.move_file unpacks wrongly an exception
http://bugs.python.org/issue22182

#22173:

Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

[Guido van Rossum]

This feels chatty. I'd like the PEP to call out the specific proposals and
put the more verbose motivation later. It took me a long time to realize
that you don't want to deprecate bytes([1, 2, 3]), but only bytes(3). Also
your mention of bytes.byte() as the counterpart to ord() confused me -- I
think it's more similar to chr(). I don't like iterbytes as a builtin,
let's keep it as a method on affected types.


On Thu, Aug 14, 2014 at 10:50 PM, Nick Coghlan  wrote:

> I just posted an updated version of PEP 467 after recently finishing
> the updates to the Python 3.4+ binary sequence docs to decouple them
> from the str docs.
>
> Key points in the proposal:
>
> * deprecate passing integers to bytes() and bytearray()
> * add bytes.zeros() and bytearray.zeros() as a replacement
> * add bytes.byte() and bytearray.byte() as counterparts to ord() for
> binary data
> * add bytes.iterbytes(), bytearray.iterbytes() and memoryview.iterbytes()
>
> As far as I am aware, that last item poses the only open question,
> with the alternative being to add an "iterbytes" builtin with a
> definition along the lines of the following:
>
> def iterbytes(data):
> try:
> getiter = type(data).__iterbytes__
> except AttributeError:
> iter = map(bytes.byte, data)
> else:
> iter = getiter(data)
> return iter
>
> Regards,
> Nick.
>
> PEP URL: http://www.python.org/dev/peps/pep-0467/
>
> Full PEP text:
> =
> PEP: 467
> Title: Minor API improvements for bytes and bytearray
> Version: $Revision$
> Last-Modified: $Date$
> Author: Nick Coghlan 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2014-03-30
> Python-Version: 3.5
> Post-History: 2014-03-30 2014-08-15
>
>
> Abstract
> 
>
> During the initial development of the Python 3 language specification, the
> core ``bytes`` type for arbitrary binary data started as the mutable type
> that is now referred to as ``bytearray``. Other aspects of operating in
> the binary domain in Python have also evolved over the course of the Python
> 3 series.
>
> This PEP proposes a number of small adjustments to the APIs of the
> ``bytes``
> and ``bytearray`` types to make it easier to operate entirely in the binary
> domain.
>
>
> Background
> ==
>
> To simplify the task of writing the Python 3 documentation, the ``bytes``
> and ``bytearray`` types were documented primarily in terms of the way they
> differed from the Unicode based Python 3 ``str`` type. Even when I
> `heavily revised the sequence documentation
> `__ in 2012, I retained
> that
> simplifying shortcut.
>
> However, it turns out that this approach to the documentation of these
> types
> had a problem: it doesn't adequately introduce users to their hybrid
> nature,
> where they can be manipulated *either* as a "sequence of integers" type,
> *or* as ``str``-like types that assume ASCII compatible data.
>
> That oversight has now been corrected, with the binary sequence types now
> being documented entirely independently of the ``str`` documentation in
> `Python 3.4+ <
> https://docs.python.org/3/library/stdtypes.html#binary-sequence-types-bytes-bytearray-memoryview
> >`__
>
> The confusion isn't just a documentation issue, however, as there are also
> some lingering design quirks from an earlier pre-release design where there
> was *no* separate ``bytearray`` type, and instead the core ``bytes`` type
> was mutable (with no immutable counterpart).
>
> Finally, additional experience with using the existing Python 3 binary
> sequence types in real world applications has suggested it would be
> beneficial to make it easier to convert integers to length 1 bytes objects.
>
>
> Proposals
> =
>
> As a "consistency improvement" proposal, this PEP is actually about a few
> smaller micro-proposals, each aimed at improving the usability of the
> binary
> data model in Python 3. Proposals are motivated by one of two main factors:
>
> * removing remnants of the original design of ``bytes`` as a mutable type
> * allowing users to easily convert integer values to a length 1 ``bytes``
>   object
>
>
> Alternate Constructors
> --
>
> The ``bytes`` and ``bytearray`` constructors currently accept an integer
> argument, but interpret it to mean a zero-filled object of the given
> length.
> This is a legacy of the original design of ``bytes`` as a mutable type,
> rather than a particularly intuitive behaviour for users. It has become
> especially confusing now that some other ``bytes`` interfaces treat
> integers
> and the corresponding length 1 bytes instances as equivalent input.
> Compare::
>
> >>> b"\x03" in bytes([1, 2, 3])
> True
> >>> 3 in bytes([1, 2, 3])
> True
>
> >>> bytes(b"\x03")
> b'\x03'
> >>> bytes(3)
> b'\x00\x00\x00'
>
> This PEP proposes that the current handling of integers in the bytes and
> byte

Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

[Serhiy Storchaka]

15.08.14 08:50, Nick Coghlan написав(ла):

* add bytes.zeros() and bytearray.zeros() as a replacement


b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need 
to learn new method. And it works right now.



* add bytes.iterbytes(), bytearray.iterbytes() and memoryview.iterbytes()


What are use cases for this? I suppose that main use case may be writing 
the code compatible with 2.7 and 3.x. But in this case you need a 
wrapper (because these types in 2.7 have no the iterbytes() method). And 
how larger would be an advantage of this method over the 
``map(bytes.byte, data)``?



___
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 for bytes & bytearray

[Victor Stinner]

2014-08-15 21:54 GMT+02:00 Serhiy Storchaka :
> 15.08.14 08:50, Nick Coghlan написав(ла):
>> * add bytes.zeros() and bytearray.zeros() as a replacement
>
> b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need to
> learn new method. And it works right now.

FYI there is a pending patch for bytearray(int) to use calloc()
instead of malloc(). It's faster for buffer for n larger than 1 MB:
http://bugs.python.org/issue21644

I'm not sure that the optimization is really useful.

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 467: Minor API improvements for bytes & bytearray

[Victor Stinner]

2014-08-15 7:50 GMT+02:00 Nick Coghlan :
> As far as I am aware, that last item poses the only open question,
> with the alternative being to add an "iterbytes" builtin (...)

Do you have examples of use cases for a builtin function? I only found
5 usages of bytes((byte,)) constructor in the standard library:

$ grep -E 'bytes\(\([^)]+, *\)\)' $(find -name "*.py")
./Lib/quopri.py:c = bytes((c,))
./Lib/quopri.py:c = bytes((c,))
./Lib/base64.py:b32tab = [bytes((i,)) for i in _b32alphabet]
./Lib/base64.py:_a85chars = [bytes((i,)) for i in range(33, 118)]
./Lib/base64.py:_b85chars = [bytes((i,)) for i in _b85alphabet]

bytes.iterbytes() can be used in 4 cases on 5. Adding a new builtin
for a single line in the whole standard library doesn't look right.

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] Multiline with statement line continuation

[Ethan Furman]

On 08/12/2014 08:38 PM, Steven D'Aprano wrote:


[1] Technically not, since it's the comma, not the ( ), which makes a
tuple, but a lot of people don't know that and treat it as if it the
parens were compulsary.


It might as well be, because if there can be a non-tuple way to interpret the comma that way takes precedence, and then 
the parens /are/ required to disambiguate and get the tuple you wanted.


--
~Ethan~
___
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] Multiline with statement line continuation

[Ethan Furman]

On 08/13/2014 10:32 AM, Steven D'Aprano wrote:


(2) Also note that *this is already the case*, since tuples are made by
the commas, not the parentheses. E.g. this succeeds:

# Not a tuple, actually two context managers.
with open("/tmp/foo"), open("/tmp/bar", "w"):
pass


Thanks for proving my point!  A comma, and yet we did *not* get a tuple from it.

--
~Ethan~
___
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] Multiline with statement line continuation

[Georg Brandl]

On 08/15/2014 11:08 PM, Ethan Furman wrote:
> On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
>>
>> (2) Also note that *this is already the case*, since tuples are made by
>> the commas, not the parentheses. E.g. this succeeds:
>>
>> # Not a tuple, actually two context managers.
>> with open("/tmp/foo"), open("/tmp/bar", "w"):
>> pass
> 
> Thanks for proving my point!  A comma, and yet we did *not* get a tuple from 
> it.

Clearly the rule is that the comma makes the tuple, except when it doesn't :)

Georg

___
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] Multiline with statement line continuation

[Steven D'Aprano]

On Fri, Aug 15, 2014 at 02:08:42PM -0700, Ethan Furman wrote:
> On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
> >
> >(2) Also note that *this is already the case*, since tuples are made by
> >the commas, not the parentheses. E.g. this succeeds:
> >
> ># Not a tuple, actually two context managers.
> >with open("/tmp/foo"), open("/tmp/bar", "w"):
> >pass
> 
> Thanks for proving my point!  A comma, and yet we did *not* get a tuple 
> from it.

Um, sorry, I don't quite get you. Are you agreeing or disagreeing with 
me? I spent half of yesterday reading the static typing thread over on 
Python-ideas and it's possible my brain has melted down *wink* but I'm 
confused by your response.

Normally when people say "Thanks for proving my point", the implication 
is that the person being thanked (in this case me) has inadvertently 
undercut their own argument. I don't think I have. I'm suggesting that 
the argument *against* the proposal:

"Multi-line with statements should not be allowed, because:

with (spam,
  eggs,
  cheese):
...

is syntactically a tuple"


is a poor argument (that is, I'm disagreeing with it), since *single* 
line parens-free with statements are already syntactically a tuple:

with spam, eggs, cheese:  # Commas make a tuple, not parens.
...

I think the OP's suggestion is a sound one, and while Nick's point that 
bulky with-statements *may* be a sign that some re-factoring is needed, 
there are many things that are a sign that re-factoring is needed and 
I don't think this particular one warrents rejecting what is otherwise 
an obvious and clear way of using multiple context managers.


-- 
Steven
___
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] Multiline with statement line continuation

[Ethan Furman]

On 08/15/2014 08:08 PM, Steven D'Aprano wrote:

On Fri, Aug 15, 2014 at 02:08:42PM -0700, Ethan Furman wrote:

On 08/13/2014 10:32 AM, Steven D'Aprano wrote:


(2) Also note that *this is already the case*, since tuples are made by
the commas, not the parentheses. E.g. this succeeds:

# Not a tuple, actually two context managers.
with open("/tmp/foo"), open("/tmp/bar", "w"):
pass


Thanks for proving my point!  A comma, and yet we did *not* get a tuple
from it.


Um, sorry, I don't quite get you. Are you agreeing or disagreeing with
me? I spent half of yesterday reading the static typing thread over on
Python-ideas and it's possible my brain has melted down *wink* but I'm
confused by your response.


My point is that commas don't always make a tuple, and your example above is a case in point:  we have a comma 
separating two context managers, but we do not have a tuple, and your comment even says so.



is a poor argument (that is, I'm disagreeing with it), since *single*
line parens-free with statements are already syntactically a tuple:

 with spam, eggs, cheese:  # Commas make a tuple, not parens.


This point I do not understand -- commas /can/ create a tuple, but don't /necessarily/ create a tuple.  So, 
semantically: no tuple.  Syntactically: I don't think there's a tuple there this way either.  I suppose one of us should 
look it up in the lexar.  ;)


--
~Ethan~
___
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 for bytes & bytearray

[Nick Coghlan]

On 16 August 2014 03:48, Guido van Rossum  wrote:
> This feels chatty. I'd like the PEP to call out the specific proposals and
> put the more verbose motivation later.

I realised that some of that history was actually completely
irrelevant now, so I culled a fair bit of it entirely.

> It took me a long time to realize
> that you don't want to deprecate bytes([1, 2, 3]), but only bytes(3).

I've split out the four subproposals into their own sections, so
hopefully this is clearer now.

> Also
> your mention of bytes.byte() as the counterpart to ord() confused me -- I
> think it's more similar to chr().

This was just a case of me using the wrong word - I meant "inverse"
rather than "counterpart".

> I don't like iterbytes as a builtin, let's
> keep it as a method on affected types.

Done. I also added an explanation of the benefits it offers over the
more generic "map(bytes.byte, data)", as well as more precise
semantics for how it will work with memoryview objects.

New draft is live at http://www.python.org/dev/peps/pep-0467/, as well
as being included inline below.

Regards,
Nick.

===

PEP: 467
Title: Minor API improvements for bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-03-30
Python-Version: 3.5
Post-History: 2014-03-30 2014-08-15 2014-08-16


Abstract


During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series.

This PEP proposes four small adjustments to the APIs of the ``bytes``,
``bytearray`` and ``memoryview`` types to make it easier to operate entirely
in the binary domain:

* Deprecate passing single integer values to ``bytes`` and ``bytearray``
* Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors
* Add ``bytes.byte`` and ``bytearray.byte`` alternative constructors
* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
  ``memoryview.iterbytes`` alternative iterators


Proposals
=

Deprecation of current "zero-initialised sequence" behaviour


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::

>>> bytes(3)
b'\x00\x00\x00'
>>> bytearray(3)
bytearray(b'\x00\x00\x00')

This PEP proposes to deprecate that behaviour in Python 3.5, and remove it
entirely in Python 3.6.

No other changes are proposed to the existing constructors.


Addition of explicit "zero-initialised sequence" constructors
-

To replace the deprecated behaviour, this PEP proposes the addition of an
explicit ``zeros`` alternative constructor as a class method on both
``bytes`` and ``bytearray``::

>>> bytes.zeros(3)
b'\x00\x00\x00'
>>> bytearray.zeros(3)
bytearray(b'\x00\x00\x00')

It will behave just as the current constructors behave when passed a single
integer.

The specific choice of ``zeros`` as the alternative constructor name is taken
from the corresponding initialisation function in NumPy (although, as these
are 1-dimensional sequence types rather than N-dimensional matrices, the
constructors take a length as input rather than a shape tuple)


Addition of explicit "single byte" constructors
---

As binary counterparts to the text ``chr`` function, this PEP proposes the
addition of an explicit ``byte`` alternative constructor as a class method
on both ``bytes`` and ``bytearray``::

>>> bytes.byte(3)
b'\x03'
>>> bytearray.byte(3)
bytearray(b'\x03')

These methods will only accept integers in the range 0 to 255 (inclusive)::

>>> bytes.byte(512)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: bytes must be in range(0, 256)

>>> bytes.byte(1.0)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'float' object cannot be interpreted as an integer

The documentation of the ``ord`` builtin will be updated to explicitly note
that ``bytes.byte`` is the inverse operation for binary data, while ``chr``
is the inverse operation for text data.

Behaviourally, ``bytes.byte(x)`` will be equivalent to the current
``bytes([x])`` (and similarly for ``bytearray``). The new spelling is
expected to be easier to discover and easier to read (especially when used
in conjunction with indexing operations on binary sequence types).

As a separate method, the new spelling will also work better with higher
order functions like ``map``.


Addition of optimised iterator methods that produce ``bytes`` objects
--

Re: [Python-Dev] Multiline with statement line continuation

[Steven D'Aprano]

On Fri, Aug 15, 2014 at 08:29:09PM -0700, Ethan Furman wrote:
> On 08/15/2014 08:08 PM, Steven D'Aprano wrote:

[...]
> >is a poor argument (that is, I'm disagreeing with it), since *single*
> >line parens-free with statements are already syntactically a tuple:
> >
> > with spam, eggs, cheese:  # Commas make a tuple, not parens.
> 
> This point I do not understand -- commas /can/ create a tuple, but don't 
> /necessarily/ create a tuple.  So, semantically: no tuple.

Right! I think we are in agreement. It's not that with statements 
actually generate a tuple, but that they *look* like they include a 
tuple. That's what I meant by "syntactically a tuple", sorry if that was 
confusing. I didn't mean to suggest that Python necessarily builds a 
tuple of context managers.

If people were going to be prone to mistake

with (a, b, c): ...

as including a tuple, they would have already mistaken:

with a, b, c: ...

the same way. But they haven't.


-- 
Steven
___
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