While the redirect for https://docs.python.org/devguide does not exist yet,
the infrastructure team has been nice enough to set up
https://devguide.python.org for us so that the devguide is served from Read
the Docs. This not only will (eventually) let the infrastructure team have
one less custom piece of doc infrastructure to maintain, but it means
updates to the devguide will be live instantly. Plus the URL is a lot
easier to remember. :)
So a win-win for everyone!
Thank you Steve for looking at this issue and to work on our Windows
2017-06-21 16:31 GMT+02:00 Steve Dower <steve.dower(a)python.org>:
> The last release from the same checkout was fine. I’m more inclined to think
> something went wrong with the pull from Ned’s fork and checking out his tag.
> (Or the fact that it took me three goes to get to that point – my least
> favourite part of the git migration is git...)
> When I get to work I’ll clean it up and try again to see if it repros or was
> a random occurrence.
> Top-posted from my Windows phone
> From: Victor Stinner
> Sent: Wednesday, June 21, 2017 7:23
> To: Steve Dower
> Cc: Python Dev
> Subject: Re: test_sax and test_random fail on Python 3.6.2rc1 on Windows
> 2017-06-21 16:10 GMT+02:00 Steve Dower <steve.dower(a)python.org>:
>> Do we have a minimum git version requirement? Maybe I need to update my
>> build machine.
> After we added .gitattributes, we had to force a fresh Git checkout on
> buildbots. Otherwise, they kept the old and wrong end of line. Maybe
> try to move my checkout and create a new checkout?
2017-06-21 16:10 GMT+02:00 Steve Dower <steve.dower(a)python.org>:
> Do we have a minimum git version requirement? Maybe I need to update my
> build machine.
After we added .gitattributes, we had to force a fresh Git checkout on
buildbots. Otherwise, they kept the old and wrong end of line. Maybe
try to move my checkout and create a new checkout?
The end-of-line hell is not over, test_sax and test_random tests are
still failing if you install Python 3.6.2rc1 on Windows:
These tests rely on files in Lib/test/. The end-of-line of these files
is controlled by .gitattributes, but it seems like the Windows
installer changed the end-of-line or the file were not correctly
created on the Git clone (.gitattributes ignored)?
In my Git checkout on Windows, Lib/test/xmltestdata/test.xml.out and
Lib/test/randv2_32.pck use UNIX end-of-line (\n).
While it's possible to fix test_sax to translate the end-of-line, I
would prefer to not have to modify test_random which opens a pickle
binary file (Lib/test/randv2_32.pck).
So, can someone look how the Windows installer stores and then
installs these files?
I have just noticed that an FTP injection advisory has been made public
on the oss-security list.
The author says that he an exploit exists but it won't be published
until the code is patched
You may be already aware, but it would be good to understand what is the
position of the core developers about this.
The advisory is linked below (with some excerpts in this message):
Protocol injection flaws like this have been an area of research of mine
for the past few couple of years and as it turns out, this FTP protocol
injection allows one to fool a victim's firewall into allowing TCP
connections from the Internet to the vulnerable host's system on any
"high" port (1024-65535). A nearly identical vulnerability exists in
Python's urllib2 and urllib libraries. In the case of Java, this attack
can be carried out against desktop users even if those desktop users do
not have the Java browser plugin enabled.
As of 2017-02-20, the vulnerabilities discussed here have not been patched
by the associated vendors, despite advance warning and ample time to do
Python's built-in URL fetching library (urllib2 in Python 2 and urllib in
Python 3) is vulnerable to a nearly identical protocol stream injection,
but this injection appears to be limited to attacks via directory names
specified in the URL.
The Python security team was notified in January 2016. Information
provided included an outline of the possibility of FTP/firewall attacks.
Despite repeated follow-ups, there has been no apparent action on their
I am posting from gmane, I hope that this is OK.
and had been for at least a few minutes, so it is not just you ;-)
Service Temporarily Unavailable
The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.
Apache/2.2.16 (Debian) Server at bugs.python.org Port 443
Terry Jan Reedy
Regarding the behaviour of the "async with" statement: it seems that the
description of it in PEP492, and the language documentation, do not match
the behaviour of CPython (v3.6.1).
The PEP and the docs here:
say that "async with" is equivalent to a particular use of try/except/else.
But the implementation seems more like a try/except/finally, because the
__aexit__ is always executed, even if a return statement is in the try
block ("else" won't be executed if there's a "return" in the "try"). Also,
as per normal "with", the implementation is a bit more complex than
try/except/finally because you don't want to execute the __aexit__ method
twice if there is an exception in the try.
Can someone please clarify the exact behaviour of "async with"?
Background: in implementing "async with" in MicroPython, we went by the
PEP/docs, and now our behaviour doesn't match that of CPython.
Hello Ms/Mr Python People,
I'm Corwyn Aboy and am a student of the University of the Philippines and
currently working on a project to create a buildbot system on a Windows 10
machine and would like to ask for guidance in doing so. I've read the
BuildbotOnWindows in your wiki.python.org website but have not yet tried it
I would like to ask if the same steps would still apply to installing it on
a Windows 10 machine. It would be really great to hear some feedback as
soon as possible.
Thank you for your time.
Enough changes have accumulated in PEP 538 since the start of the
previous thread that it seems sensible to me to start a new thread
specifically covering the current design (which aims to address all
the concerns raised in the previous thread).
I haven't requoted the PEP in full since it's so long, but will
instead refer readers to the web version:
I also generated a diff covered the full changes to the PEP text:
(this is the diff covering the last few days of changes
Summarising the key technical changes:
* to make the runtime behaviour independent of whether or not locale
coercion took place, stdin and stderr now always have
"surrogateescape" as their error handler in the potential coercion
target locales. This means Python will behave the same way regardless
of whether the locale gets set externally (e.g. by a parent Python
process or a container image definition) or implicitly during CLI
* for the full locales, the interpreter now sets LC_CTYPE and LANG,
*not* LC_ALL. This means LC_ALL is once again a full locale override,
and also means that CPython won't inadvertently interfere with other
locale categories like LC_MONETARY, LC_NUMERIC, etc
* the reference implementation has been refactored so the bulk of the
new code lives in the shared library and is exposed to the linker via
a couple of underscore prefixed API symbols
(_Py_LegacyLocaleDetected() and _Py_CoerceLegacyLocale()). While the
current PEP still keeps them private, it would be straightforward to
make them public for use in embedding applications if we decided we
wanted to do so.
* locale coercion and warnings are now enabled by default on all
platforms that use the autotools-based build chain - the assumption
that some platforms didn't need them turned out to be incorrect
In addition to being updated to cover the above changes, the Rationale
section of the PEP has also been updated to explain why it doesn't
propose setting PYTHONIOENCODING, and to walk through some examples of
the problems with GNU readlines compatibility when the current locale
isn't set correctly.
The essential related changes to the reference implementation can be seen here:
* Always set "surrogateescape" for coercion target locales,
independently of whether or not coercion occurred:
* Stop setting LC_ALL:
(There are also some smaller cleanup commits that can be seen by
browsing that branch on GitHub)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia