At the request of the platform experts, 3.5.1 is now scheduled to happen
simultaneously with 2.7.11. That means:
Saturday November 21, 2015
tag 3.5.1rc1
Sunday November 22, 2015
release 3.5.1rc1
Saturday December 5, 2015
tag 3.5.1 final
Sunday December 6, 2015
release 3.5.1 final
I'll update the release schedule soon,
//arry/
Happy November, everyone. It’s nearly time for the next semi-annual
instalment of the 2.7 series. I’m planning to release a 2.7.11 release
candidate on November 21st and 2.7.11 final on December 5.
More than half-done releasing 2.7-ly yours,
Benjamin
On Fri, Oct 23, 2015 at 3:23 AM, Victor Stinner
<victor.stinner(a)gmail.com> wrote:
> Note: I propose "noopt" because we already have "optimization level 0"
> which still uses optimizations, it's the default mode. It's different
> than gcc -O0 which really disables all optimizations. I already prefix
> the "noopt" suffix for .pyc files than "opt--1" proposed by Brett in
> http://bugs.python.org/issue2506
Strictly speaking, this isn't completely true. Most (all?) C/C++
compilers do some level of optimization when they are "disabled".
GCC/Clang, for example, both will do some form of constant folding
with -O0. The compilers are just *much* less aggressive with the
primary goal of making the debugging experience much more enjoyable.
The situation here sounds similar -- we want an option to provide a
better debugging and tracing experience, which seems like a very
reasonable idea to me.
-- Meador
PEP 478 [1] doesn't currently have any info on a planned 3.5.1 release
(and actually, it has 3.5.0 Final listed as a future release). About
when is it likely to happen? The one thing I'm hanging out for is an
installer patch on Windows that detects XP and immediately aborts with
a convenient error; if the number of emails to python-list is
indicative, there are a lot of people out there getting confused.
ChrisA
[1] https://www.python.org/dev/peps/pep-0478/
I'm unable to submit any file to any issue, neither via web-form nor via
e-mail. Checked with different browsers from different computers.
Meta-tracker doesn't work too.
http://psf.upfronthosting.co.za/roundup/meta/issue575
see the following:
lac@smartwheels:~/junk$ echo "print ('hello there')" >string.py
lac@smartwheels:~/junk$ idle-python3.5
hello there
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.5/idlelib/run.py", line 10, in <module>
from idlelib import CallTips
File "/usr/lib/python3.5/idlelib/CallTips.py", line 16, in <module>
from idlelib.HyperParser import HyperParser
File "/usr/lib/python3.5/idlelib/HyperParser.py", line 14, in <module>
_ASCII_ID_CHARS = frozenset(string.ascii_letters + string.digits + "_")
AttributeError: module 'string' has no attribute 'ascii_letters'
IDLE then produces a popup that says:
IDLE's subprocess didn't make connection. Either IDLE can't stat a subprocess por personal firewall software is blocking the connection. <ok>
--------
I think that life would be a whole lot easier for people if instead we got
a message:
Warning: local file /u/lac/junk/string.py shadows module named string in the
Standard Library
I think that it is python exec that would have to do this -- though of
course the popup could also warn about shadowing in general, instead of
sending people on wild goose chases over their firewalls.
Would this be hard to do?
Laura
It mentions fr'...' as a formatted raw string but doesn't say anything about rf'...'. Right now, in implementing PEP 498 support in Howl (https://github.com/howl-editor/howl/pull/118 and https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f6434…), I assumed both were valid. Should the PEP be more specific?
BTW, at the rate language-python is going, GitHub will get syntax highlighting for f-strings in 2050. :D
--
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
