[Python-Dev] Summary of Python tracker Issues

2017-05-26 Thread Python tracker 

ACTIVITY SUMMARY (2017-05-19 - 2017-05-26)
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:
  open5999 (+31)
  closed 36241 (+50)
  total  42240 (+81)

Open issues with patches: 2372 


Issues opened (62)
==

#21074: Too aggressive constant folding
http://bugs.python.org/issue21074  reopened by haypo

#30405: build.bat: register binaries for py launcher
http://bugs.python.org/issue30405  opened by terry.reedy

#30406: async and await should be keywords in 3.7
http://bugs.python.org/issue30406  opened by Jelle Zijlstra

#30410: Documentation for sys.stdout encoding does not reflect the new
http://bugs.python.org/issue30410  opened by paul.moore

#30411: git doesn't support "-C" args under 1.8.5 occurs in configure.
http://bugs.python.org/issue30411  opened by Yuan Liu

#30412: mailbox : add option to prevent platform EOL conversion
http://bugs.python.org/issue30412  opened by adder

#30413: Add fnmatch.filterfalse function
http://bugs.python.org/issue30413  opened by steven.daprano

#30416: constant folding opens compiler to quadratic time hashing
http://bugs.python.org/issue30416  opened by dalke

#30417: [buildbot] Disable the cpu resources on slow buildbots
http://bugs.python.org/issue30417  opened by haypo

#30418: test_communicate_epipe() of test_subprocess fails randomly on 
http://bugs.python.org/issue30418  opened by haypo

#30419: Bdb: Update doc page
http://bugs.python.org/issue30419  opened by csabella

#30420: Clarify kwarg handing for subprocess convenience APIs
http://bugs.python.org/issue30420  opened by ncoghlan

#30421: argparse: relative include of config files
http://bugs.python.org/issue30421  opened by roschi

#30422: Add roadmap.txt section to idlelib
http://bugs.python.org/issue30422  opened by terry.reedy

#30424: make pydoc-topics fails
http://bugs.python.org/issue30424  opened by Jelle Zijlstra

#30425: Python 3.6.1 (32-bit)_20170522020736.log
http://bugs.python.org/issue30425  opened by Chakrit Rakhuang

#30427: isinstance checks in os.path.normcase redundant with os.fspath
http://bugs.python.org/issue30427  opened by wolma

#30428: mailbox.MMDF wrongly adds From_ header to file
http://bugs.python.org/issue30428  opened by ralph.corderoy

#30429: bdb and pdb: Add watchpoint function
http://bugs.python.org/issue30429  opened by louielu

#30430: Cannot write to a tun interface file
http://bugs.python.org/issue30430  opened by Rémy Léone

#30431: input function truncates prompt by NULL byte
http://bugs.python.org/issue30431  opened by Костя Чолак

#30433: Devguide lacks instructions for building docs
http://bugs.python.org/issue30433  opened by cjrh

#30434: multiprocessing AuthenticationError "digest sent was rejected"
http://bugs.python.org/issue30434  opened by Soon Jeffrey

#30435: Documentation either unclear or incorrect on comparisons betwe
http://bugs.python.org/issue30435  opened by ipatrol

#30436: importlib.find_spec raises AttributeError when parent is not a
http://bugs.python.org/issue30436  opened by tkhyn

#30437: SSL_shutdown can return meaningless SSL_ERROR_SYSCALL
http://bugs.python.org/issue30437  opened by njs

#30438: tarfile would fail to extract tarballs with files under R/O di
http://bugs.python.org/issue30438  opened by Yaroslav.Halchenko

#30439: Expose the subinterpreters C-API in the stdlib.
http://bugs.python.org/issue30439  opened by eric.snow

#30440: document peephole optimizer effects
http://bugs.python.org/issue30440  opened by dalke

#30441: os.environ raises RuntimeError: dictionary changed size during
http://bugs.python.org/issue30441  opened by osantana

#30442: Skip test_xml_etree under coverage
http://bugs.python.org/issue30442  opened by kushal.das

#30444: Add ability to change "-- more --" text in pager module
http://bugs.python.org/issue30444  opened by Gautam krishna.R

#30446: Embedded 3.6.1 distribution cannot find _socket module
http://bugs.python.org/issue30446  opened by ThomasS

#30448: test_subprocess creates a core dump on FreeBSD
http://bugs.python.org/issue30448  opened by haypo

#30449: Improve __slots__ datamodel documentation
http://bugs.python.org/issue30449  opened by Aaron Hall

#30450: Pull Windows dependencies from GitHub rather than svn.python.o
http://bugs.python.org/issue30450  opened by zach.ware

#30451: parse windows path error in webbrowser.get() and lead to webbr
http://bugs.python.org/issue30451  opened by chainly

#30454: Python module cx_Oracle ld installation issue on Solaris11U3 S
http://bugs.python.org/issue30454  opened by sameernatekar

#30455: Generate C code from token.py and not vice versa
http://bugs.python.org/issue30455  opened by serhiy.storchaka

#30456: 2to3 docs: example of fix for duplicates in second argument of
http://bugs.python.org/issue30456  opened by Eli_B

#30457: Allow retrieve the number of waiters pending for most of the a
http

Re: [Python-Dev] PEP 544: Protocols - second round

2017-05-26 Thread Guido van Rossum 
On Thu, May 25, 2017 at 7:19 AM, Nick Coghlan  wrote:

> Given the abstract, I'd suggest "Structural Subtyping" as a suitable
> title for the PEP.
>

Maybe even "Structural Subtyping (a.k.a. Duck Typing)"



> That said, I think it's fine to use "protocol" throughout the rest of
> the PEP as is currently the case - object protocols and network
> protocols are clearly different things, it's just the bare word
> "Protocols" appearing as a PEP title in the PEP index with no other
> context that's potentially confusing.
>

Agreed.


> I'm +1 on the general idea of the PEP, and only have one question
> regarding the specifics. Given:
>
> import typing
>
> class MyContainer:
> def __len__(self) -> int:
> ...
> def close(self) -> None:
> ...
>
> Would that be enough for a static typechecker to consider MyContainer
> a structural subtype of both typing.Sized and SupportsClose from the
> PEP, even though neither is imported explicitly into the module? I'm
> assuming the answer is "Yes", but I didn't see it explicitly stated
> anywhere.
>

Yes. Imports don't enter the matter. (Things get tied together at the call
sites.) @Ivan: if there isn't an example that makes this clear we should
add one.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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 544: Protocols - second round

2017-05-26 Thread Guido van Rossum 
On Thu, May 25, 2017 at 10:49 AM, Mark Shannon  wrote:

> I really like this PEP in general. I think this brings the type system for
> type-hints closer to Python semantics.
>

Thank you.


> But there are a few points I disagree with.
> I don't think Protocol types should be tied to ABCs. It just makes things
> more complex with no obvious benefit.
>

There are backwards compatibility benefits -- we could make e.g. Sequence a
Protocol in Python 3.7 and it would be possible to write code that inherits
from Sequence and works in Python 3.6 and 3.7. For this to work we need
some support for non-abstract methods in Protocols.


> I also think all references to 'isinstance' and 'issubclass' should be
> removed. Type-hints should not have runtime semantics, beyond those that
> they have as classes.


Again, backwards compatibility.


> In fact, there is no need for protocol types to be classes at all.
>

That's pretty much a separate discussion (see
https://github.com/python/typing/issues/432).

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

[Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

2017-05-26 Thread Nick Coghlan 
Hi folks,

Over on 
https://github.com/pypa/python-packaging-user-guide/pull/305#issuecomment-304169735
we're looking to update the theming of packaging.python.org to match
that of the language documentation at docs.python.org.

Doing that would also entail updating the documentation of the
individual tools and services (pip, pypi, setuptools, wheel, etc) to
maintain consistency with the main packaging user guide, so Jon has
tentatively broken the theme out as a (not yet published anywhere)
"pypa-theme" package to make it easier to re-use across multiple
projects.

The question that occurred to me is whether or not it might make more
sense to instead call that package "psf-docs-theme", to reflect that
it's intended specifically for projects that are legally backed by the
PSF, and that general Python projects looking for a nice,
high-contrast, theme should consider using an org independent one like
Alabaster instead.

Thoughts? Should we stick with pypa-theme as the name? Switch to
psf-docs-theme? Publish both, with pypa-theme adding PyPA specific
elements to a more general psf-docs-theme?

Cheers,
Nick.

P.S. In case folks aren't aware of the full legal arrangements here:
in addition to the informal "Python Packaging Authority" designation,
there's also a formally constituted PSF Packaging Working Group that
provides the legal connection back to the PSF. That means the
relationship between PyPA and the PSF ends up being pretty similar to
the one between python-dev and the PSF, where there's no direct PSF
involvement in day to day development activities, but the PSF provides
the legal and financial backing needed to sustainably maintain popular
community-supported software and services.

Part of my rationale for suggesting the inclusion of "psf" in the
package name is to make it clear that the intent would be to create a
clear and distinctive "trade dress" for the documentation of directly
PSF backed projects:
https://en.wikipedia.org/wiki/Trade_dress#Protection_for_electronic_interfaces_and_websites

Future requests to use the theme (beyond CPython and the PyPA) could
then be run through the PSF Trademarks committee, as with requests to
use the registered marks.

Whereas if we go with pypa-theme, then that would just be a
non-precedent-setting agreement between PyPA and CPython to share a
documentation theme, without trying to define any form of
documentation trade dress for the PSF in general.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com