[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-05-09 - 2014-05-16) 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: open4614 ( +3) closed 28674 (+50) total 33288 (+53) Open issues with patches: 2121 Issues opened (40) == #13916: disallow the "surrogatepass" handler for non utf-* encodings http://bugs.python.org/issue13916 reopened by haypo #19385: dbm.dumb should be consistent when the database is closed http://bugs.python.org/issue19385 reopened by serhiy.storchaka #21425: Interactive interpreter doesn't flush stderr prompty http://bugs.python.org/issue21425 reopened by pitrou #21459: DragonFlyBSD support http://bugs.python.org/issue21459 reopened by brett.cannon #21465: sqlite3 Row can return duplicate keys when using adapters http://bugs.python.org/issue21465 opened by BreamoreBoy #21468: NNTPLib connections become corrupt after long periods of activ http://bugs.python.org/issue21468 opened by James.Meneghello #21471: subprocess line-buffering only works in universal newlines mod http://bugs.python.org/issue21471 opened by pitrou #21472: Fix wsgiref handling of absolute HTTP Request-URI http://bugs.python.org/issue21472 opened by mouad #21473: Idle: test startup scripts. http://bugs.python.org/issue21473 opened by terry.reedy #21474: Idle: updata fixwordbreaks() for unicode identifiers http://bugs.python.org/issue21474 opened by terry.reedy #21475: Support the Sitemap and Crawl-delay extensions in robotparser http://bugs.python.org/issue21475 opened by rhettinger #21476: Inconsitent behaviour between BytesParser.parse and Parser.par http://bugs.python.org/issue21476 opened by Åukasz.Kucharski #21477: Idle: improve idle_test,htest http://bugs.python.org/issue21477 opened by terry.reedy #21478: mock calls don't propagate to parent (autospec) http://bugs.python.org/issue21478 opened by and #21479: Document TarFile.open() as a classmethod http://bugs.python.org/issue21479 opened by berker.peksag #21480: A build now requires... http://bugs.python.org/issue21480 opened by skip.montanaro #21481: Argpase Namespace object methods __eq__ and __ne__ raise Type http://bugs.python.org/issue21481 opened by Joe.Borg #21482: get_versions() in cygwinccomiler.py cannot return correct gcc http://bugs.python.org/issue21482 opened by 3togo #21483: Skip os.utime() test on NFS? http://bugs.python.org/issue21483 opened by skip.montanaro #21484: More clarity needed about difference between "x += e" and "x = http://bugs.python.org/issue21484 opened by Kluzniak #21491: race condition in SocketServer.py ForkingMixIn collect_childre http://bugs.python.org/issue21491 opened by idsvandermolen #21493: Add test for ntpath.expanduser http://bugs.python.org/issue21493 opened by Claudiu.Popa #21495: Sane default for logging config http://bugs.python.org/issue21495 opened by guettli #21498: configparser accepts keys beginning with comment_chars when wr http://bugs.python.org/issue21498 opened by The Compiler #21500: Make use of the "load_tests" protocol in test_importlib packag http://bugs.python.org/issue21500 opened by eric.snow #21501: submitting mmap example for use in documentation http://bugs.python.org/issue21501 opened by hudson #21502: freeze.py not working properly with OS X framework builds http://bugs.python.org/issue21502 opened by yjiangnan #21503: Use test_both() consistently throughout test_importlib http://bugs.python.org/issue21503 opened by eric.snow #21504: can the subprocess module war using os.wait4 and so return usa http://bugs.python.org/issue21504 opened by donald.petravick #21505: cx_freeze multiprocessing bug http://bugs.python.org/issue21505 opened by shivani #21506: Windows MSI installer should mklink (symlink) python.exe to py http://bugs.python.org/issue21506 opened by edmorley #21507: set and frozenset constructor should use operator.length_hint http://bugs.python.org/issue21507 opened by lebedov #21508: C API PyArg_ParseTuple doc is innacurate http://bugs.python.org/issue21508 opened by Banger #21509: json.load fails to read UTF-8 file with (BOM) Byte Order Marks http://bugs.python.org/issue21509 opened by Kristian.Benoit #21510: fma documentation should provide better example. http://bugs.python.org/issue21510 opened by jayanthkoushik #21511: Thinko in Lib/quopri.py http://bugs.python.org/issue21511 opened by pfalcon #21513: speed up some ipaddress properties http://bugs.python.org/issue21513 opened by pitrou #21514: update json module docs in light of RFC 7159 & ECMA-404 http://bugs.python.org/issue21514 opened by cvrebert #21515: Use Linux O_TMPFILE flag in tempfile.TemporaryFile? http://bugs.python.org/issue21515 opened by haypo #21516: pathlib.Path(...).is_dir() crashes on some directories (Window http://bugs.python.org/issue21516 opened by theller Most recent 15 issues with no replie
[Python-Dev] Update to PEP 11 to clarify garnering platform support
Here is some proposed wording. Since it is more of a clarification of what it takes to garner support -- which is just a new section -- rather than a complete rewrite I'm including just the diff to make it easier to read the changes. *diff -r 49d18bb47ebc pep-0011.txt* *--- a/pep-0011.txt Wed May 14 11:18:22 2014 -0400* *+++ b/pep-0011.txt Fri May 16 13:48:30 2014 -0400* @@ -2,22 +2,21 @@ Title: Removing support for little used platforms Version: $Revision$ Last-Modified: $Date$ -Author: [email protected] (Martin von Löwis) +Author: Martin von Löwis , +Brett Cannon Status: Active Type: Process Content-Type: text/x-rst Created: 07-Jul-2002 Post-History: 18-Aug-2007 + 16-May-2014 Abstract -This PEP documents operating systems (platforms) which are not -supported in Python anymore. For some of these systems, -supporting code might be still part of Python, but will be removed -in a future release - unless somebody steps forward as a volunteer -to maintain this code. +This PEP documents how an operating system (platform) garners +support in Python as well as documenting past support. Rationale @@ -37,16 +36,53 @@ change to the Python source code will work on all supported platforms. -To reduce this risk, this PEP proposes a procedure to remove code -for platforms with no Python users. +To reduce this risk, this PEP specifies what is required for a +platform to be considered supported by Python as well as providing a +procedure to remove code for platforms with little or no Python +users. +Supporting platforms + + +Gaining official platform support requires two things. First, a core +developer needs to volunteer to maintain platform-specific code. This +core developer can either already be a member of the Python +development team or be given contributor rights on the basis of +maintaining platform support (it is at the discretion of the Python +development team to decide if a person is ready to have such rights +even if it is just for supporting a specific platform). + +Second, a stable buildbot must be provided [2]_. This guarantees that +platform support will not be accidentally broken by a Python core +developer who does not have personal access to the platform. For a +buildbot to be considered stable it requires that the machine be +reliably up and functioning (but it is up to the Python core +developers to decide whether to promote a buildbot to being +considered stable). + +This policy does not disqualify supporting other platforms +indirectly. Patches which are not platform-specific but still done to +add platform support will be considered for inclusion. For example, +if platform-independent changes were necessary in the configure +script which was motivated to support a specific platform that would +be accepted. Patches which add platform-specific code such as the +name of a specific platform to the configure script will generally +not be accepted without the platform having official support. + +CPU architecture and compiler support are viewed in a similar manner +as platforms. For example, to consider the ARM architecture supported +a buildbot running on ARM would be required along with support from +the Python development team. In general it is not required to have +a CPU architecture run under every possible platform in order to be +considered supported. Unsupporting platforms -- -If a certain platform that currently has special code in it is -deemed to be without Python users, a note must be posted in this -PEP that this platform is no longer actively supported. This +If a certain platform that currently has special code in Python is +deemed to be without Python users or lacks proper support from the +Python development team and/or a buildbot, a note must be posted in +this PEP that this platform is no longer actively supported. This note must include: - the name of the system @@ -69,8 +105,8 @@ forward and offer maintenance. -Resupporting platforms --- +Re-supporting platforms +--- If a user of a platform wants to see this platform supported again, he may volunteer to maintain the platform support. Such an @@ -101,7 +137,7 @@ release is made. Developers of extension modules will generally need to use the same Visual Studio release; they are concerned both with the availability of the versions they need to use, and with keeping -the zoo of versions small. The Python source tree will keep +the zoo of versions small. The Python source tree will keep unmaintained build files for older Visual Studio releases, for which patches will be accepted. Such build files will be removed from the source tree 3 years after the extended support for the compiler has @@ -223,6 +259,7 @@ -- .. [1] http://support.microsoft.com/lifecycle/ +.. [
[Python-Dev] Returning None from methods that mutate object state
During a conversation today, I realised that the convention of
returning None from methods that change an object's state isn't
captured the Programming Recommendations section of PEP 8.
Specifically, I'm referring to this behaviour:
>>> [].sort() is None
True
>>> "ABC".lower() is None
False
That's a deliberate design choice, and one that has been explained a
few times on the list when folks ask why "[].sort().reverse()" doesn't
work when "'ABC'.lower().replace('-', '_')" does.
Would it be worth adding such a note? Or is it out of scope?
Cheers,
Nick.
--
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
