webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
Laura
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 ?[1]
However, MS now makes it very hard (impossible?) to download VS2010
Express ( or Community, or whatever the free as in beer version is
called).
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.
-Chris
[1] 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:
https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
Be considered?
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:
https://gitlab.com/python-smtpd-hackers/aiosmtpd/wikis/2015-09-27-hackfest
Special thanks to the PSF and Brian Curtin for sponsoring the sprint.
Cheers,
-Barry
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
before).
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:
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
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:
type(expr1).__format__(expr1, spec1)
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
ever).
I've posted a new version of the code in issue 24965. I'll update the
PEP itself sometime this weekend.
On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky <
alexander.belopolsky(a)gmail.com> wrote:
>
> PEP 495 [1] is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
> objects.
A major issue has come up since my announcement above. Tim Peters have
noticed that PEP 495 would violate the "hash invariant" unless the fold
attribute is accounted for in inter-zone comparisons.
See [2] for details. This issue has been resolved by modifying the
definition [3] of the "==" operator for aware datetimes with post-PEP
tzinfo. Note that no program will be affected by this change unless it
uses a post-PEP tzinfo implementation.
I made some smaller changes [4] to the PEP as well and it should finally be
ready for pronouncement.
[1]: https://www.python.org/dev/peps/pep-0495
[2]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html
[3]:
https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison
[4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt