Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Thu, 20 Feb 2014 10:24:16 +0900 "Stephen J. Turnbull" wrote: > > The argument that a "read-only, no cherrypicking by committers" repo > is nothing but a better tarball is valid, but as I say, AFAICS the > expected gain is pretty marginal. The conflict here is not Larry's > process, it's the decision to make an ambitious release on a short > time schedule. I don't really buy the "short time schedule" argument. The delay between 3.3 and 3.4 is ~18 months as usual. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, 19 Feb 2014 19:20:12 -0800 Larry Hastings wrote: > > As for a "user beware" clone: I worry about providing anything that > looks/tastes/smells like a repo. Someone could still inadvertently push > those revisions back to trunk, and then we'd have a real mess on our > hands. If you're using a separate named branch for your release work, then the hg.python.org hooks will forbid pushing them back to the main repo. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Extent of post-rc churn
http://midwinter.com/~larry/3.4.status/merge.status.html lists enough changes that it sounds more like a bugfix release than "just a few last tweaks after the rc". It would probably help if the what's-new-in-rc2 explicitly mentioned that asyncio is new and provisional with 3.4, and listed its changes in a separate subsection, so that the "final tweaks to something I might already be using" section would be less intimidating. -jJ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A misredirected ticket link in hg.python.org/cpython
Quoting Vajrasky Kok : Go to any commit link in hg.python.org/cpython, for example http://hg.python.org/cpython/rev/d11ca14c9a61. You have this commit message: Issue #6815: os.path.expandvars() now supports non-ASCII Unicode environment variables names and values. [#6815] The [#6815] link is going to http://bugs.python.org/6815. If you follow that link, it redirects to http://legacy.python.org/sf/ and you get message: You did not provide a report number. The link should be http://bugs.python.org/issue6815. The bug really is on www.python.org, which (now) redirects /sf/6815 to http://legacy.python.org/sf/, i.e. it drops the issue number there. Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] DB-API v2.1 or v3 [inspired by: python 3 niggle: None < 1 raises TypeError]
I personally regret that sorting isn't safe, but that ship has sailed. There is practicality benefit in making None compare to everything, just as C and Java do with null pointers -- but it is too late to do by default. Adding a keyword to sorted might be nice -- but then shouldn't it also be added to other sorts, and maybe max/min? It might just be trading one sort of mess for another. What *can* reasonably be changed is the DB-API. Why not just specify that the DB type objects themselves should handle comparison to None? http://www.python.org/dev/peps/pep-0249/#type-objects-and-constructors -jJ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Second preview of 3.4.0rc2 is up
This time I was a lot more careful about Misc/NEWS items. The graft process likes to link in improper changes. So every time I have a graft merge collision, I now recheck what the revision I'm merging has done, and I only keep Misc/NEWS entries that are relevant. I just realized that I based the 3.4 branch on the wrong revision. I had used the last revision before I started tagging 3.4.0rc1 ( 6343bdbb7085) when I should be using the last revision in 3.4.0rc1 before merging back into trunk ( e64ae8b82672). So I get to do it all over from scratch, *again*, for the next attempt. Hooray! You can find the current status and a fresh tarball here: http://midwinter.com/~larry/3.4.status/ Good luck, //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Second preview of 3.4.0rc2 is up
Hi, Thanks Larry for being our release manager. How can we help you? Sorry for giving you too much work with asyncio changes :-) Python 3.4 is the largest release in term of new features since Python 3. To give you an overview of new features, 8 new modules were added between Python 2.7 and 3.3. As many modules have been added between Python 3.3 and 3.4 as between Python 2.7 and Python 3.3! Python 3.4 has 7 new modules: http://techs.enovance.com/6521/openstack_python3 In Python 3.4: 14 PEP have been accepted and implemented. And I didn't count Larry's PEP which still a draft (but its status should be final IMO). Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 22:18, schrieb Nick Coghlan: > and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. well, I think it would be wrong to restrict that for only that reason. I did object to delay the release cycle a second time for completing a feature. If the release has to be delayed for QA reasons, that's a good reason. Having a Debian background myself ;) I'm fine to ship with a rc3 too, and update it post-release, after wading through distribution bureaucracy ... but please don't use this as an example of a distribution influencing an upstream. There are "better" examples for this :-/ Matthias ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 21 Feb 2014 08:38, "Matthias Klose" wrote: > > Am 19.02.2014 22:18, schrieb Nick Coghlan: > > and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. > > well, I think it would be wrong to restrict that for only that reason. I did > object to delay the release cycle a second time for completing a feature. If > the release has to be delayed for QA reasons, that's a good reason. Having a > Debian background myself ;) > > I'm fine to ship with a rc3 too, and update it post-release, after wading > through distribution bureaucracy ... but please don't use this as an example of > a distribution influencing an upstream. There are "better" examples for this :-/ Thanks for the clarification. That said, supporting someone else's external deadline can definitely help with resisting the urge to allow "just one more little adjustment" :) Cheers, Nick. > > Matthias > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 463: Exception-catching expressions
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Feb-2014
Python-Version: 3.5
Post-History: 16-Feb-2014, 21-Feb-2014
Abstract
Just as PEP 308 introduced a means of value-based conditions in an
expression, this system allows exception-based conditions to be used
as part of an expression.
Motivation
==
A number of functions and methods have parameters which will cause
them to return a specified value instead of raising an exception. The
current system is ad-hoc and inconsistent, and requires that each
function be individually written to have this functionality; not all
support this.
* dict.get(key, default) - second positional argument in place of
KeyError
* next(iter, default) - second positional argument in place of
StopIteration
* list.pop() - no way to return a default
* seq[index] - no way to handle a bounds error
* min(sequence, default=default) - keyword argument in place of
ValueError
* sum(sequence, start=default) - slightly different but can do the
same job
* statistics.mean(data) - no way to handle an empty iterator
Rationale
=
The current system requires that a function author predict the need
for a default, and implement support for it. If this is not done, a
full try/except block is needed.
Since try/except is a statement, it is impossible to catch exceptions
in the middle of an expression. Just as if/else does for conditionals
and lambda does for function definitions, so does this allow exception
catching in an expression context.
This provides a clean and consistent way for a function to provide a
default: it simply raises an appropriate exception, and the caller
catches it.
With some situations, an LBYL technique can be used (checking if some
sequence has enough length before indexing into it, for instance). This is
not safe in all cases, but as it is often convenient, programmers will be
tempted to sacrifice the safety of EAFP in favour of the notational brevity
of LBYL. Additionally, some LBYL techniques (eg involving getattr with
three arguments) warp the code into looking like literal strings rather
than attribute lookup, which can impact readability. A convenient EAFP
notation solves all of this.
There's no convenient way to write a helper function to do this; the
nearest is something ugly using either lambda::
def except_(expression, exception_list, default):
try:
return expression()
except exception_list:
return default()
value = except_(lambda: 1/x, ZeroDivisionError, lambda: float("nan"))
which is clunky, and unable to handle multiple exception clauses; or
eval::
def except_(expression, exception_list, default):
try:
return eval(expression, globals_of_caller(), locals_of_caller())
except exception_list as exc:
l = locals_of_caller().copy()
l['exc'] = exc
return eval(default, globals_of_caller(), l)
def globals_of_caller():
return sys._getframe(2).f_globals
def locals_of_caller():
return sys._getframe(2).f_locals
value = except_("""1/x""",ZeroDivisionError,""" "Can't divide by zero" """)
which is even clunkier, and relies on implementation-dependent hacks.
(Writing globals_of_caller() and locals_of_caller() for interpreters
other than CPython is left as an exercise for the reader.)
Raymond Hettinger `expresses`__ a desire for such a consistent
API. Something similar has been `requested`__ `multiple`__ `times`__
in the past.
__ https://mail.python.org/pipermail/python-ideas/2014-February/025443.html
__ https://mail.python.org/pipermail/python-ideas/2013-March/019760.html
__ https://mail.python.org/pipermail/python-ideas/2009-August/005441.html
__ https://mail.python.org/pipermail/python-ideas/2008-August/001801.html
Proposal
Just as the 'or' operator and the three part 'if-else' expression give
short circuiting methods of catching a falsy value and replacing it,
this syntax gives a short-circuiting method of catching an exception
and replacing it.
This currently works::
lst = [1, 2, None, 3]
value = lst[2] or "No value"
The proposal adds this::
lst = [1, 2]
value = lst[2] except IndexError: "No value"
Specifically, the syntax proposed is::
expr except exception_list: default
where expr, exception_list, and default are all expressions. First,
expr is evaluated. If no exception is raised, its value is the value
of the overall expression. If any exception is raised, exception_list
is evaluated, and should result in either a type or a tuple, just as
with the statement form of try/except. Any matching exception will
result in the corresponding default expression being evaluated and
becoming the value of the expression. As with the statement form of
try/except, non-matching exceptions will propagate upward.
Re: [Python-Dev] PEP 463: Exception-catching expressions
On 02/20/2014 07:15 PM, Chris Angelico wrote: PEP: 463 Title: Exception-catching expressions Version: $Revision$ Last-Modified: $Date$ Author: Chris Angelico Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 15-Feb-2014 Python-Version: 3.5 Post-History: 16-Feb-2014, 21-Feb-2014 Nice work with the PEP, Chris! +1 to general idea. (I'll vote on the syntax when the bikeshedding begins ;). -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 463: Exception-catching expressions
On Fri, Feb 21, 2014 at 3:54 PM, Ethan Furman wrote: > (I'll vote on the syntax when the bikeshedding begins ;). Go get the keys to the time machine! Bikeshedding begins a week ago. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What is 'default' point to now?
Now that Larry is working on the 3.4.0 branch away from default, what is default pointing to? 3.4.1 or 3.5? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 463: Exception-catching expressions
On 02/20/2014 09:00 PM, Chris Angelico wrote: On Fri, Feb 21, 2014 at 3:54 PM, Ethan Furman wrote: (I'll vote on the syntax when the bikeshedding begins ;). Go get the keys to the time machine! Bikeshedding begins a week ago. Oh, no, not on PyDev it hasn't! Get ready for round 2! -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What is 'default' point to now?
On 2/20/2014 11:58 PM, Ethan Furman wrote: Now that Larry is working on the 3.4.0 branch away from default, what is default pointing to? 3.4.1 or 3.5? Until a 3.4 branch is split off, default is effectively 3.4.1, which means bugfixes only. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rpm needs python
Hi all, I have two version of python 2.4 and 2.7. By default python version is 2.4 . I want to install need to install some rpm which needs python 2.7 interpreter. how can I enable 2.7 interpreter for only those packages which are requiring python 2.7, I don't want to change my default python version(2.4). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
