As I understand it, the MS VS2010 compiler is required (or at least
best practice) for compiling Python extensions for the python.org
Windows builds of py 3.4 and ?
However, MS now makes it very hard (impossible?) to download VS2010
Express ( or Community, or whatever the free as in beer version is
I realize that this is not python-dev's responsibility, but if there
is any way to either document where it can be found, or put a bit of
pressure on MS to make it available, as they have for VS2008 and
py2.7, that would be great.
Sorry to bug this list, I didn't know where else to reach out to.
 it's actually prefer hard to find out which compiler version is
used for which python version. And has been for years. Would a patch
to the docs, probably here:
Yesterday (27-Sep-2015), four Washington DC area Python developers got
together for a local Python hacking sprint. Andrew, Eric, Jason, and I were
joined remotely by the esteemed R. David Murray. We did stuff and had fun!
We hope to do stuff and have fun again! If you want to join us for stuff and
fun next time, please get in touch.
Here's a write-up of the sprint:
Special thanks to the PSF and Brian Curtin for sponsoring the sprint.
Just so people know, over at the datetime-sig I've accepted PEP 495, which
adds a fold flag to datetime objects to distinguish ambiguous times. This
enables roundripping of conversions for those times where the local clock
is moved backward (creating ambiguous times that could not be distinguished
I would like to thank Alexander and Tim for their unrelenting work on this.
The idea seems simple, but the details were excruciatingly hard to get
right, given the strict backwards compatibility requirements.
There may well be additional beneficial changes to the datetime module. The
datetime-sig is now open for their discussion. However, proposals that
break backwards compatibility are a waste of everybody's time, so be
prepared to explain how your proposal does not break existing code that
works under Python 3.5.
--Guido van Rossum (python.org/~guido)
For now the default value of the stacklevel parameter in warnings.warn()
is 1. But in most cases stacklevel=2 is required, sometimes >2, and I
don't know cases that need stacklevel=1. I propose to make the default
value of stacklevel to be 2. I think that unlikely this will break
existing code. But rather can fix existing bugs. If stacklevel=1 is
required (I don't know cases), it can be explicitly specified.
While finishing up the implementation of PEP 498, I realized that the
PEP has an error. It says that this code:
Is equivalent to:
'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
+ str(expr3).__format__('') + 'ghi'
But that's not correct. The right way to call __format__ is:
That is, the lookup of __format__ is done on the type, not the instance.
Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this and string concatenation, but that's for another day (if
I've posted a new version of the code in issue 24965. I'll update the
PEP itself sometime this weekend.
What is the official order for sections in Misc/NEWS? I'm sure that
"Core and Builtins" is first, and "Library" is second, but after that...
I'm not sure.
This seems about right, though I'm not certain we're 100% consistent
Core and Builtins
Is it documented anywhere? I didn't see it in the Dev Guide.