-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On behalf of the Python development team, I'm happy to announce
the release of Python 3.3.5, release candidate 1.
Python 3.3.5 includes a fix for a regression in zipimport in 3.3.4
(see http://bugs.python.org/issue20621) and a few other bugs.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. In total, almost 500 API items
are new or improved in Python 3.3. For a more extensive list of
changes in the 3.3 series, see
http://docs.python.org/3.3/whatsnew/3.3.html
To download Python 3.3.5 visit:
http://www.python.org/download/releases/3.3.5/
This is a preview release, please report any bugs to
http://bugs.python.org/
The final release is scheduled one week from now.
Enjoy!
- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlMKIPEACgkQN9GcIYhpnLCjXACfQwbC/eD/lhKAZ+XCwTwYPVWj
GMwAnjWkbdk7hqsKoh12EiagpGApEPSA
=2BCx
-----END PGP SIGNATURE-----
Victor has asked me to cherry-pick 180e4b678003:
http://bugs.python.org/issue20320 (original issue)
http://hg.python.org/cpython/rev/180e4b678003/ (checkin into trunk)
http://bugs.python.org/issue20646 (cherry-pick request)
This revision changes the rounding behavior of fractional-second
timeouts for select.select and select.kqueue. I don't have enough
context to judge whether or not this is bad enough to warrant
cherry-picking, and the discussion on the issue didn't seem to come to a
firm consensus.
Can I get some opinions on this?
FWIW, I'm going to cut the next preview in a few minutes, and this won't
be in it, but I don't actually tag until most of a day from now.
//arry/
On 22 February 2014 00:22, Rob Cliffe <rob.cliffe(a)btinternet.com> wrote:
> Thanks for looking into this Nick.
> I confess I don't entirely understand the technical argument (my
> understanding breaks down at "the subexpressions can't see the class level
> variables", but I don't want to waste anybody's time expecting an
> explanation, I can always look into it myself)
It's a relatively arcane scoping rule that only matters if you have
non-trivial logic at class scope. The vast majority of Python
programmers will never have to care, because they do the typical thing
and their class bodies consist almost entirely of function definitions
and relatively simple assignment statements. However, it's something
that expression level name binding proposals need to take into account
if they want to avoid side effects on the containing scope.
Python's scoping rules are deliberately designed so that methods
*can't* see class attributes directly, they have to access them via
their first argument or the magic __class__ variable (Py3 only for the
latter). For example:
>>> class C:
... attr = "Hello"
... def m(self):
... print(self.attr)
... print(attr)
...
>>> C().m()
Hello
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in m
NameError: global name 'attr' is not defined
The trick that makes it relevant here is that the "hidden" iteration
variable in comprehensions is implemented by creating an implicit
closure and then calling it. From the point of view of the scoping
rules, that implicit closure behaves the same way as any other method
definition, so most of the subexpressions can't see the class
variables. The sole exception is the outermost iterator expression,
because that is evaluated in the containing scope and then passed to
the closure as an argument (this is all based on the way generator
expressions work, and those *have* to be a closure, because they need
to run in their own completely independent frame).
As Chris later noted, you likely *could* still implement expression
local name binding for an except expression without a full closure, it
would just be rather difficult.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Hi,
This is my first year in gsoc. I have been working with python and
django from quite a time. One of the Gsoc proposed ideas drew my attention
and i would surely like to work on that.
I would like to work for creating a extension for idle to integrate
PEP8, what are the prerequisites . I have been studying the PEP8 code past
a week. This might be useful for a quick start to this project. Please
guide.
--
Thanks and Regards,
Navneet suman,
IIIT-Allahabad
+91-9305612151
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has
been released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in
Python trunk will go into 3.4.0 rc2, and after that ships, checkins
would go into 3.4.0 final. Ho ho ho! That's not true! Instead,
anything checked in to "default" between my last revision for "rc1"
(e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only
fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and
final. And my local branch will remain private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
final, please go to the issue tracker and create a new issue with the
following attributes:
The title should start with "3.4 cherry-pick: " followed by the
revision id and a short summary
example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
The version should be "Python 3.4"
The assignee should be "larry"
The priority should be "release blocker"
The comment should *also* contain the revision id (the tracker will
turn it into a link)
I'm also working on automatically publishing the merged/unmerged
revision status to a web page. You can see a mock-up here:
http://www.midwinter.com/~larry/3.4.merge.status.html
The page is marked "beta" because it doesn't have real data yet--I'm
still experimenting with my automation, so I haven't created the real
3.4 local branch yet. Again, just to be crystal-clear: the revisions
marked "merged" on that page are just experiments, they aren't actually
merged for 3.4. Once I'm ready for real merging, I'll remove the beta
warning.
(By the way: on that page, clicking on a revision takes you to the
revision web page. Clicking on the first line of the comment expands it
to show the complete comment.)
Please use your best judgment before asking that a revision be
cherry-picked into 3.4.0. Our goal in the release candidate phase is to
stabilize Python, and to do that we must stop changing it. Only
important interface changes, new features, or bugfixes should be checked
in now, and preferably they should be low-risk.
Cheers,
//arry/
Sorry folks, that was meant to go to python-ideas, not python-dev.
I've been so used to the PEP 463 threads being on python-ideas, I
missed that this was the python-dev one :)
Cheers,
Nick.
Greetings, all!
Larry asked me to bring this to PyDev, so here it is.
The issues involved are:
http://bugs.python.org/issue20534 -> already in RC1
http://bugs.python.org/issue20653 -> hoping to get cherry-picked
Background
==========
When I put Enum together, my knowledge of pickle and its protocols was dreadfully weak. As a result, I didn't make the
best choice in implementing it [1].
Just before RC1 was cut, Serhiy discovered a problem with pickling Enums at protocol four, and with his help I fixed
that (this is the part that is already in RC1). This fix consisted primarily of adding a __reduce_ex__ to the Enum
class, and also checking for all the pickle protocols in a mixed-in type [2], but I left __getnewargs__ in. Not only
that, and worse, I wasn't checking to see if the new subclass had its own __getnewargs__ or __reduce_ex__ before I
invalidated the class for pickling [3]. This means that even though a subclass could have its own __reduce_ex__ to make
pickling/unpickling possible, it will be ignored.
Problem
=======
All the previous changes to disallow something have been for strategic reasons (the usual ones being either consistency,
or "it doesn't make sense for an enum member/class to behave that way"), but this is effectively disallowing a user to
specify how their enums should be pickled, and I am unaware of any reason why this should be.
Discussion
==========
Is there a valid reason to not allow a user to modify how their enums are pickled?
If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but
after 3.4.0 is cut we then have to deal with backwards compatibility issues.
Thanks for your time and thoughts.
--
~Ethan~
[1] I chose __getnewargs__, with the result that originally Enum didn't support pickle protocols 0 or 1, and when 4 was
added later it had trouble with some types of Enum subclasses (tuples, to be exact).
[2] Those protocol methods being __reduce__, __reduce_ex__, __getnewargs__, and __getnewargs_ex__.
[3] This logic error has been there from the beginning, it did not sneak in in the last patch before RC1.
We're now up to 66 cherry-picks. 75%+ of those are asyncio changes.
Hopefully I won't have to redo the cherry-picking from scratch again, I
can just pile more picks on top of the ones I've got.
As before you'll find the results here:
http://midwinter.com/~larry/3.4.status/
//arry/
