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
which needs python 2.7 interpreter. how can I enable 2.7 interpreter for
packages which are requiring python 2.7, I don't want to change my default
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:
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
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://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.
Let's begin with a status update of The Great Argument Clinic Conversion
Derby. In retrospect, the Derby was way too ambitious. Once it started
I was quickly overwhelmed. Even doing nothing but Derby work, all day
every day for two straight weeks, I couldn't keep up with all the bug
fixes, feature requests, correspondence, and documentation updates it
demanded. There was no way I could simultaneously review patches too.
As a result: there is, still, an enormous backlog of Derby patches that
need reviewing. Few of the Derby patches got integrated before we
The underlying theory of the Derby was that it would be a purely
mechanical process. It would be a simple matter of converting the
existing parsing code into its Argument Clinic equivalent, resulting
solely in code churn. And, indeed, a significant portion of the Derby
patches are exactly that. But the conversion process peered into a lot
of dusty corners, and raised a lot of questions, and as a result it was
a much more complicated and time-consuming process than I anticipated.
So here we are in the "release candidate" period for 3.4, and we still
have all these unmerged Derby patches. And it's simply too late in the
release cycle to merge them for 3.4.0.
Here's how I propose we move forward.
1) We merge the Derby patch for the builtins module into 3.4, simply
because it will "demo well". If someone wants to play with signatures
on builtins, I think it's likely they'll try something like "len".
Obviously this wouldn't be permitted to change the semantics of argument
parsing in any way--this would be a "code churn" patch only. (In case
you're wondering, Nick did the conversion of the builtins module, and
naturally I will be reviewing it.)
2) We change all Clinic conversions in 3.4 so they write the generated
code to a separate file--in Clinic parlance, change them so they 'use
the "file" destination'. Going forward this will be the preferred way
to check in Argument Clinic changes into Python.
These first two are the only changes resulting from the Derby that I
will accept between now and 3.4.0 final, and I expect to have them in
for 3.4.0rc2. Continuing from there:
3) We hold off on merging the rest of the Derby patches until after
3.4.0 final ships, then we merge them into the 3.4 maintenance branch so
they go into 3.4.1. We use the time between now and then to get the
patches totally, totally perfect. Again, these patches will not be
permitted to change the parsing semantics of the functions so
converted. I expect to do these checkins in a private branch, and land
the bulk of it immediately upon the opening of the 3.4 maintenance branch.
4) We accelerate the schedule for 3.4.1 slightly, so we can get these
new signatures into the hands of users sooner. Specifically, I propose
we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1
rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.
5) Any proposed changes in Derby patches that change the semantics of a
builtin may only be checked into default for 3.5, after 3.4.0 ships.
I'm very sorry that many people contributed to the Derby expecting their
patches to go in to 3.4. This is my fault, for severely miscalculating
how the Derby would play out. And I feel awful about it. But I'm
convinced the best thing for Python is to hold off on merging until
after 3.4.0 ships.
Sending this to python-dev as I'm wondering if this was considered when
the choice to have objects of different types raise a TypeError when
So, the concrete I case I have is implementing stable ordering for the
python Range objects that psycopg2 uses. These have 3 attributes that
can either be None or, for sake of argument, a numeric value.
To implement __lt__ in Python 2, I could do:
def __lt__(self, other):
if not isinstance(other, Range):
return ((self._lower, self._upper, self._bounds) <
(other._lower, other._upper, other._bounds))
Because None < 1 raises a TypeError, in Python 3 I have to do:
def __lt__(self, other):
if not isinstance(other, Range):
for attr in '_lower', '_upper', '_bounds':
self_value = getattr(self, attr)
other_value = getattr(other, attr)
if self_value == other_value:
elif self_value is None:
elif other_value is None:
return self_value < other_value
Am I missing something? How can I get this method down to a sane size?
Simplistix - Content Management, Batch Processing & Python Consulting
The URL has changed slightly. Please go here:
You'll notice two things:
* a "merge.status.html" file, which shows you the list of revisions
that I've cherry-picked after rc1.
* a tarball containing the resulting source tree.
As I cherry-pick more revisions, I'll add new tarballs and update the
For the record, I've passed over only two requested cherry-pick
revisions so far:
select and kqueue round the timeout aways from zero
improve Enum subclass behavior
I haven't rejected them, I just want more review. If you'd like to see
these changes get cherry-picked for 3.4.0 rc2 (and final) please review
them or convince someone else to contribute a review.
Only thirty cherry-picked revisions so far. Gosh, you're making my life