Ned Batchelder | 3 May 00:57 2016

[issue26914] Fix formatting of lists in PEP 420


New submission from Ned Batchelder:

The numbered and bulletted lists are indented from the body text, which looks good in the .rst, but causes
the lists themselves to be blockquotes.  This leads to confusing formatting on python.org: https://www.python.org/dev/peps/pep-0420/

BTW: this formatting error is rampant among the PEPs... :(

----------
assignee: docs <at> python
components: Documentation
files: pep-0420.patch
keywords: patch
messages: 264677
nosy: docs <at> python, nedbat
priority: normal
severity: normal
status: open
title: Fix formatting of lists in PEP 420
Added file: http://bugs.python.org/file42686/pep-0420.patch

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

(Continue reading)

Rohit Jamuar | 2 May 23:28 2016

[issue26876] Extend MSVCCompiler class to respect environment variables


Rohit Jamuar added the comment:

Just so that I understand it clearly - Inside MSVCCompiler class (in _msvccompiler.py / msvccompiler.py /
msvc9compiler.py ), current implementation of find_exe() finds compiler / linker / ... after parsing
PATH. Should the changes be so, that if DISTUTILS_USE_SDK is set to the environment, the values set to CC /
AR / LD, etc. are used verbatim? Or did you mean to say, that just as CC, LD and AR are being read from the
environment, the same way rc.exe, mc.exe and mt.exe should be read as well, in case DISTUTILS_USE_SDK is
set to the environment?

----------

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Peter Norvig | 2 May 22:59 2016

[issue26913] statistics.mean of bools


New submission from Peter Norvig:

mean([True, True, True, False]) should be 0.75, but it returns 0.25.

The fix is to change _sum so that when the type is bool, the result should be coerced to int, not bool.

Why it is important for statistics.mean to work with bools:
It is natural to say something like
    mean(x > threshold for x in data)
and expect to get the percentage of items in data that are above threshold.

----------
components: Library (Lib)
messages: 264670
nosy: Peter.Norvig
priority: normal
severity: normal
status: open
title: statistics.mean of bools
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue26913>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org
(Continue reading)

Ivan Zakharyaschev | 2 May 22:44 2016

[issue26912] test/test_email/torture_test.py (and test_asian_codecs.py) has a broken import


New submission from Ivan Zakharyaschev:

(An issue similar to http://bugs.python.org/issue26911 , but with a different source file from the tests)

Lib/test/test_email/torture_test.py:15:from email.test.test_email import TestEmailBase

should be:

from test.test_email import TestEmailBase

because the first variant has a non-existing path.

(This makes the auto-requirements generator in ALT Sisyphus to generate a broken/unsatisfiable
dependency on email.test.test_email when building the package from
http://git.altlinux.org/people/imz/packages/python3.git .)

Similarly,

Lib/test/test_email/test_asian_codecs.py:8:from test.test_email.test_email import TestEmailBase

should better not have an extra "test_email" component in the path.

All other imports of test_email in Python 3.5.1 sources are of the form I'm suggesting:

$ git --no-pager grep -Fn .test_email
Lib/test/test_email/__init__.py:9:from test.test_email import __file__ as landmark
Lib/test/test_email/__main__.py:1:from test.test_email import load_tests
Lib/test/test_email/test__encoded_words.py:4:from test.test_email import TestEmailBase
Lib/test/test_email/test__header_value_parser.py:6:from test.test_email import TestEmailBase, parameterize
(Continue reading)

Ivan Zakhryaschev | 2 May 21:45 2016

[issue26911] lib2to3/tests/pytree_idempotency.py has a broken import


New submission from Ivan Zakhryaschev:

Line 21 of lib2to3/tests/pytree_idempotency.py:

import pgen2

This seems to be broken, because it should be:

import lib2to3.pgen2

(This makes the auto-requirements generator in ALT Sisyphus to generate a broken/unsatisfiable
dependency on pgen2 when packaging this into an RPM.)

All other uses of pgen2 in Python 3.5.1 sources use other forms of import: either relative or the absolute
one as I suggest:

$ git grep -F pgen2
lib2to3/btm_matcher.py:        # from .pgen2 import token // token.__dict__.items():
lib2to3/btm_utils.py:from .pgen2 import grammar, token
lib2to3/fixer_util.py:from .pgen2 import token
lib2to3/fixes/fix_apply.py:from ..pgen2 import token
lib2to3/fixes/fix_dict.py:from ..pgen2 import token
lib2to3/fixes/fix_except.py:from ..pgen2 import token
lib2to3/fixes/fix_filter.py:from ..pgen2 import token
lib2to3/fixes/fix_has_key.py:from ..pgen2 import token
lib2to3/fixes/fix_map.py:from ..pgen2 import token
lib2to3/fixes/fix_ne.py:from ..pgen2 import token
lib2to3/fixes/fix_next.py:from ..pgen2 import token
lib2to3/fixes/fix_numliterals.py:from ..pgen2 import token
(Continue reading)

Luigi Semenzato | 2 May 19:50 2016

[issue26910] dictionary literal should not allow duplicate keys


New submission from Luigi Semenzato:

This was already discussed and rejected at https://bugs.python.org/issue16385.  I am reopening because
I am not convinced that the discussion presented all arguments properly.

The original problem description:

lives_in = { 'lion': ['Africa', 'America],
             'parrot': ['Europe'],
             #... 100+ more rows here
             'lion': ['Europe'],
             #... 100+ more rows here
           }

The above constructor overwrites the 'lion' entry silently, often causing unexpected behavior.

These are the arguments presented in favor of the rejection, followed by my rebuttals.

1. "An error is out of the question for compatibility reasons".  No real rebuttal here, except I wonder if
exceptions are ever made and under what circumstances.  I should point out that a warning may also create incompatibilities.

2. "There are ways to rewrite this as a loop on a list".  Yes of course, but the entire point of the dictionary
literal is to offer a concise and convenient notation for entering a dictionary as program text.

3. "Being able to re-write keys is fundamental to Python dicts and why they can be used for Python's mutable
namespaces".  This is fine but it applies to the data structure, not the literal constructor.

4. "A code generator could depend on being able to write duplicate keys without having to go back and erase
previous output".  Yes, but it seems wrong to facilitate automated code generation at the expense of human
(Continue reading)

[issue26909] Serious performance loss (10 times) when NOT using .drain()


New submission from Марк Коренберг:

https://github.com/python/asyncio/issues/338

(example of program shows bug resides on github)

----------
components: asyncio
messages: 264655
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: Serious performance loss (10 times) when NOT using .drain()
type: performance
versions: Python 3.5

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue26909>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Vladimir Rutsky | 2 May 18:59 2016

[issue26908] "1and 0" evaluated a zero, instead of SyntaxError


New submission from Vladimir Rutsky:

Looks like there is no need to place space separators after numbers:

$ python3.5 -c "print(1and 0)"
0
$ python3.5 -c "print([1for i in range(1)])"
[1]

Not sure is this a bug or a feature, but I would expect that this should be SyntaxError, same as here:

$ python3.5 -c "1 and0"
  File "<string>", line 1
    1 and0
         ^
SyntaxError: invalid syntax

If this is a feature, can anyone give reasoning for it?

----------
messages: 264654
nosy: rutsky
priority: normal
severity: normal
status: open
title: "1and 0" evaluated a zero, instead of SyntaxError
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
(Continue reading)

Christian Heimes | 2 May 16:29 2016

[issue26907] Add missing getsockopt constants


New submission from Christian Heimes:

The socket doesn't expose some constants for getsockopt() and setsockopt():

Get domain and protocol from socket fd
SO_DOMAIN
SO_PROTOCOL

enable/disable passing of credentials
SO_PASSCRED

get security context (SELinux context)
SO_PEERSEC

enable/disable passing of security context
SO_PASSSEC

----------
assignee: christian.heimes
messages: 264649
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add missing getsockopt constants
type: enhancement
versions: Python 3.6

_______________________________________
(Continue reading)

Antti Haapala | 2 May 15:07 2016

[issue26906] format(object.__reduce__) fails intermittently


New submission from Antti Haapala:

This is an annoying heisenbug; it seems that some objects cannot be formatted until you explicitly do
obj.__format__. For example `object.__reduce__` behaves like this:

    Python 2.7.10 (default, Oct 14 2015, 16:09:02)
    [GCC 5.2.1 20151010] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> format(object.__reduce__)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Type method_descriptor doesn't define __format__
    >>> format(object.__reduce__)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Type method_descriptor doesn't define __format__
    >>> object.__reduce__.__format__
    <built-in method __format__ of method_descriptor object at 0x7f67563ed0e0>
    >>> format(object.__reduce__)
    "<method '__reduce__' of 'object' objects>"

I can replicate this in 2.7.9, .10 and .11 on Ubuntu and Debian, though it works on Windows Python, works in
2.6.6, and Pythons 3 wherever I've tried, but I've heard this also failing on Python 3.

----------
title: __reduce__ format -> format(object.__reduce__) fails intermittently

_______________________________________
Python tracker <report <at> bugs.python.org>
(Continue reading)

Antti Haapala | 2 May 15:03 2016

[issue26906] __reduce__ format


Changes by Antti Haapala <antti <at> haapala.name>:

----------
nosy: ztane
priority: normal
severity: normal
status: open
title: __reduce__ format
versions: Python 2.7

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue26906>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org


Gmane