Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

> Don't know exactly how it's implemented, but I would guess it's using
> "hg incoming --patch" or similar, which would handle this transparently;
> the newer revisions at hg.python.org would just be ignored in generating
> the diff.

That doesn't work exactly: hg incoming --patch could generate multiple
patches for the same file. The button tries to combine them into a
single patch per file (which turns out to be difficult).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

[Mark Hammond]

On 22/03/2011 8:09 AM, Barry Warsaw wrote:

I started an Informational PEP on this at Pycon, and will try to finish a
draft of it this week.  (I'm claiming 396 for it.)


We nearly had a race for that number! FYI, I just checked in pep-0397 
leaving 396 for you :)


Cheers,

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Second draft: PEP397: Python launcher for Windows

[Mark Hammond]

Hi all,
  I've made some changes to the draft PEP and checked it into the PEP 
repository as PEP397.  The reference implementation is currently being 
tracked at http://bugs.python.org/issue11629.


Most of the changes should not be too controversial, but of note:

* I've added lots of discussion about the child-process issue and the 
wording now states, basically, that in-process is not feasible, but if 
we use the win32 Job API we can arrange for the child to be killed with 
the parent on Windows XP and later.  The reference implementation 
demonstrates this thanks to an example from Curt Hagenlocher.


* 64bit and 32bit considerations have been added, along with basic 
information about other distros and implementations.


* The somewhat controversial optional first command-line parameter which 
allows you to specify a particular version for interactive use has grown 
an almost-certain-to-be-controversial option to specify the bittedness 
of the Python you wish to start.  I've added this mainly as it would 
scratch my personal itch as I tend to have 32bit and 64bit 
implementations of most versions available and while this isn't 
particularly common, I'm going to attempt to defend it on the principle 
of "just don't use it if you don't like it" :)  Note the reference 
implementation does not yet implement this, nor does it implement the 
general policy about 32bit vs 64bit considerations.


Please let me know what you think and what objections/comments/etc remain.

Thanks,

Mark
PEP: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond 
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011


Abstract

This PEP describes a Python launcher for the Windows platform.  A 
Python launcher is a single executable which uses a number of 
heuristics to locate a Python executable and launch it with a
specified command line.


Rationale

Windows provides "file associations" so an executable can be associated
with an extension, allowing for scripts to be executed directly in some
contexts (eg., double-clicking the file in Windows Explorer.)  Until now,
a strategy of "last installed Python wins" has been used and while not
ideal, has generally been workable due to the conservative changes in
Python 2.x releases.  As Python 3.x scripts are often syntactically
incompatible with Python 2.x scripts, a different strategy must be used
to allow files with a '.py' extension to use a different executable based
on the Python version the script targets.  This will be done by borrowing
the existing practices of another operating system - scripts will be able
to nominate the version of Python they need by way of a "shebang" line, as
described below.

Unix-like operating systems (referred to simply as "Unix" in this
PEP) allow scripts to be executed as if they were executable images
by examining the script for a "shebang" line which specifies the
actual executable to be used to run the script.  This is described in
detail in the evecve(2) man page [1] and while user documentation will
be created for this feature, for the purposes of this PEP that man
page describes a valid shebang line.

Additionally, these operating systems provide symbolic-links to
Python executables in well-known directories. For example, many
systems will have a link /usr/bin/python which references a
particular version of Python installed under the operating-system.
These symbolic links allow Python to be executed without regard for
where Python it actually installed on the machine (eg., without
requiring the path where Python is actually installed to be
referenced in the shebang line or in the PATH.)  PEP 394 'The "python"
command on Unix-Like Systems' [2] describes additional conventions
for more fine-grained specification of a particular Python version.

These 2 facilities combined allow for a portable and somewhat 
predictable way of both starting Python interactively and for allowing
Python scripts to execute.  This PEP describes an implementation of a 
launcher which can offer the same benefits for Python on the Windows 
platform and therefore allows the launcher to be the executable
associated with '.py' files to support multiple Python versions
concurrently.

While this PEP offers the ability to use a shebang line which should
work on both Windows and Unix, this is not the primary motivation for
this PEP - the primary motivation is to allow a specific version to be
specified without inventing new syntax or conventions to describe it.

An overview of the launcher.

This PEP outlines the general functionality and key guidelines of a
launcher for Windows.  It is accompanied by reference implementation,
written in Python, which defines the detailed implementation.  Over
 

Re: [Python-Dev] Hg: inter-branch workflow

[Stephen J. Turnbull]

"Martin v. Löwis" writes:
 > Am 22.03.2011 02:02, schrieb Eugene Toder:
 > >> Not if the changes you want to suppress are actually also on the same
 > >> branch as the one whose mainline you are trying to see (which they
 > >> typically are, with the branch typically being "default").
 > >
 > > Right, that would amount to not using named branches. But if you
 > > develop on a named feature-branch and merge into "default" when ready
 > > your local history is easy to filter-out without rebasing or
 > > collapsing.
 > 
 > Ah. We don't support this kind of development - no new named branches
 > are allowed in the central repository.

Maybe it would be possible to allow *closed* named branches, which
would support such filtering.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Hrvoje Niksic]

On 03/21/2011 05:44 PM, s...@pobox.com wrote:


Thanks for the example, Hrvoje.

 Hrvoje>  This automatic merging often causes people who migrate to a DVCS
 Hrvoje>  to feel that they have to go through an unnecessary extra step
 Hrvoje>  in their workflows.  But once you grasp the "hole" in the svn
 Hrvoje>  workflow, what svn does (and what one used to take for granted)
 Hrvoje>  tends to become unacceptable, to put it mildly.

In the run-up to a release when there is lots of activity happening, do you
find yourself in a race with other developers to push your changes cleanly?


I work on a small project in comparison to Python, so this doesn't 
happen to me personally.  But such a race is certain to happen on larger 
projects.  But it doesn't mean that we are helpless to prevent it. 
After all, one of the selling points of DVCS is the ability to support 
different integration workflows.


If you (we) are running into a push race with the other developers over 
the central repository's head, this could indicate that the project is 
large enough that the centralized workflow is no longer the appropriate 
one.  If you are not familiar with other DVCS workflows, take a look at, 
for example, chapter 5 of the "Pro Git" book, which describes the 
alternatives such as integrator-manager and dictator-lieutenant 
workflows: http://progit.org/book/ch5-1.html


Python obviously wouldn't benefit from a strict hierarchy implied by the 
dictator-lieutenants model, but perhaps it could switch to something 
between that and the integrator model for the releases. The release 
manager could act as the dictator (as well as integrator), while the 
core committers would be lieutenants (as well as developers).  Just a 
thought.


Hrvoje
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/21/2011 10:48 PM, "Martin v. Löwis" wrote:
>> It does so at the *tree* level, not at an individual file level.
> 
> Thanks - I stand corrected. I was thinking about the file level only (at
> which it doesn't do server-side merging - right?).
> 
> Regards,
> Martin

AIUI, you are correct, svn doesn't do server-side content merging.
John
=:->

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbC4ACgkQJdeBCYSNAANhCQCgpmKnD7QmZQ8Cv1DGPkJw22Q0
/uYAoMc0VNoLq2VMFpu3+uzS2M93x08P
=TL8l
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/22/2011 2:05 AM, Terry Reedy wrote:
> On 3/21/2011 7:14 AM, Nick Coghlan wrote:
> 
>> hg broadens the check and complains if *any* files are not up to date
>> on any of the branches being pushed, thus making it a requirement to
>> do a hg pull and merge on all affected branches before the hg push can
>> succeed. In theory, this provides an opportunity for the developer
>> doing the merge to double check that it didn't break anything, in
>> practice (at least in the near term) we're more likely to see an
>> SVN-like practice of pushing the merged changes without rerunning the
>> full test suite.
> 
> Now that you and John have (finally) explained how 'non-conflict' merges
> can actually contain a conflict (and there could be such for docs as
> well as code*), I think there is a pretty clear guideline for when to
> re-test.
> 
> If my change adds or changes in one file a reference to something in
> another file, or changes or subtracts in one file something that might
> be referenced by other files, and the the change could affect the
> cross-file linkage, and the pulled changes merged with my changes might
> have such linkages, then I should rerun tests on the new merged state.
> (I say 'might' because it is easier and safer to just rerun than to
> check very hard.) Otherwise, it should be safe not to. Correct?
> 

I would agree with 'might' with the very large caveat that cross-file
linkage tends to exist in far more places than most people think. I know
I've done a few "single line fixes" where the test suite showed me that
it wasn't as simple as that. :)

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbIUACgkQJdeBCYSNAAPsbQCbB53ctC5DQ8hQo1U/1crNsxLc
d5EAoIF1/x9hBW2z4X9EfGNaaGM3V8A+
=2HN+
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/21/2011 10:32 PM, Nick Coghlan wrote:
> On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
>  wrote:
>> I don't think that is the main source of complexity.
>> The more difficult and fragile part of the workflows are:
>> * requiring commits to be cross-linked between branches
>> * and wanting changesets to be collapsed or rebased
>>   (two operations that destroy and rewrite history).
> 
> Yep, that sounds about right. I think in the long run the first one
> *will* turn out to be a better work flow, but it's definitely quite a
> shift from our historical way of doing things.
> 
> As far as the second point goes, I'm coming to the view that we should
> avoid rebase/strip/rollback when intending to push to the main
> repository, and do long term work in *separate* cloned repositories.
> Then an rdiff with the relevant cpython branch will create a nice
> collapsed patch ready for application to the main repository (I have
> yet to succeed in generating a nice patch without using rdiff, but I
> still have some more experimentation to do with MvL's last proposed
> command for that before giving up on the idea).
> 
> Cheers,
> Nick.
> 

I don't know what mercurial specifically supports. I believe git has a
'--squash' option at merge/commit time. And bzr has "bzr revert
- --forget-merges". Which lets you do a merge as normal, and then tell it
to forget all of the history that you just merged (treating the commit
as just a collapsed patch).

It is trivial to do this as a DVCS (it is just *omitting* the extra
parent pointer for commit). Though Mercurial's model of extra heads
existing in the branch may make it a bit trickier. (If you omit the head
when committing, it still stays around looking like it is unmerged, so
you need 1 more step of killing the extra head.)

Regardless, I'm sure it is something that could be implemented and
streamlined for Python's use. Maybe someone knows a Mercurial command to
already do it?

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbgIACgkQJdeBCYSNAANAlACfZkegH6t9y0PUH9xufcbCB4PX
8ykAn0A6i7D/+LJ+9+9OwoA27hkAiHUc
=eh4I
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/21/2011 6:53 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
> 
>> So you are worried about the small window between me doing an 'svn up',
>> seeing no changes, and doing an 'svn ci'?  I suppose that is a legitimate
>> concern, but considering the fact that if the same thing happens in hg,
>> the only difference is that I know about it and have to do more work[*],
>> I don't think it really changes anything.  Well, it means that if your
>> culture uses the "always test" workflow you can't be *perfect* about it
>> if you use svn[**], which I must suppose has been your (and Stephen's)
>> point from the beginning.
>>
>> [*] that is, I'm *not* going to rerun the test suite even if I have to
>> pull/up/merge, unless there are conflicts.
> 
> I think if we really want full testing of all changesets landing on
> hg.python.org/cpython we're going to need a submit robot like PQM or Tarmac,
> although the latter is probably too tightly wedded to the Launchpad API, and I
> don't know if the former supports Mercurial.
> 
> With the benefits such robots bring, it's also important to understand the
> downsides.  There are more moving parts to maintain, and because landings are
> serialized, long test suites can sometimes cause significant backlogs.  Other
> than during the Pycon sprints, the backlog probably wouldn't be that big.
> 
> Another complication we'd have is running the test suite cross-platform, but I
> suspect that almost nobody does that today anyway.  So the buildbot farm would
> still be important.
> 
> -Barry

I'm personally a huge fan of 2(multi)-tier testing. So you have a basic
(and fast) test suite that runs across all your modules before every
commit in your mainline. Then a much larger (and slower) test suite that
runs regression testing across all platforms/etc that runs
asynchronously. Which gives you some basic protection against brown-bag
failures (you committed a typo in the main Python.h file, breaking
everyone). And still avoids a huge pushback on throughput.

I think Launchpad is currently looking to do batch-PQM. So that every
commit to the final mainline must pass the full test suite. However the
automated bot can grab multiple requests from the queue at a time, on
the premise that 90% of the time, none of them will break anything. So
you end up with a 100% stable trunk (any given revision committed by the
bot did pass the full test suite), but still get most of the throughput.

Also, by working in batch mode, if you have 20 submissions, and
submission #2 would have broken the test suite, it only bumps some (say
the first 5) submissions, and the other 15 still get to land in an
orderly fashion. You could even put any bumped submissions into a
deferred 'one-by-one' queue.

John
=:->

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ib6QACgkQJdeBCYSNAAPJWwCggyeS5DZlm/DR7bo+1AmpD9rr
YmMAoLFmmu7VBTJJX/khyigaOPU9dDE9
=68rK
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

[Nick Coghlan]

On Tue, Mar 22, 2011 at 9:21 AM, Guido van Rossum  wrote:
> In the light of the recent discussion about Hg clones, perhaps you
> could make this a server-side clone so it's easier for others to play
> along?

Anyone without push rights for hg.python.org may want to fork the
mirror the bitbucket folks set up during the PyCon sprints to avoid
having to push the whole repository up to a separate hosting site:
https://bitbucket.org/mirror/cpython

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Nick Coghlan]

On Tue, Mar 22, 2011 at 8:35 AM, "Martin v. Löwis"  wrote:
>> Well, it's "should", not "must" ;)
>> When writing this, I had in mind that other projects have different
>> workflows, where indeed people never collapse and many tiny changesets
>> (which are only significant as part of a bigger work) end up in the main
>> history. The point is to signal that it's not how we work.
>
> Having to be nitpicking here "not how you (Antoine) want us to work".
> "We" aren't using mercurial long enough to make such a statement.
>
> I still propose to loosen this restriction, and go with that for a
> while. Perhaps improve the email hook to give more condensed reports.
> If people then complain about too much fine-grainedness, we could
> tighten it again.

I think our experience from the sprints was enough to realise that
wording couldn't realistically mean "never do micro commits". If you
commit something, then notice a typo, or that you forgot to update
NEWS or ACKS, then sure, go ahead and push the main commit along with
any small cleanups and merges that were needed.

It was more designed to say "please land big changes as a single
coherent patch, not as a long series of experimentation and
micro-commits".

So "SHOULD" is the right word - we really do want to try to keep
things to coherent patches, but will occasionally have small cleanup
commits as well. That isn't really any different from the way we
worked with SVN, with later commits to add NEWS entries, fix issue
references, etc when the original commit missed something.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/21/2011 9:19 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
> 
>> Keeping the repository clean makes it easier to use a bisection search to
>> hunt down the introduction of a bug.  If  every developer's intermediate
>> commits make it into the main repository, it's hard to go back to an older
>> revision to test something, because many of the older revisions will be
>> broken in some way.
> 
> So maybe this gets at my earlier question about rebase being cultural
> vs. technology, and the response about bzr having a strong sense of mainline
> where hg doesn't.
> 
> I don't use the bzr-bisect plugin too much, but I think by default it only
> follows commits on the main line, unless a bisect point is identified within a
> merge (i.e. side) line.  So again, those merged intermediate changes are
> mostly ignored until they're needed.
> 
> -Barry

Bazaar is, to my knowledge, the only DVCS that has a "mainline"
emphasis. Which shows up in quite a few areas. The defaults for 'log',
having branch-stable revnos[1], and the 'bzr checkout' model for
managing a mainline.

The cultural aspects of this also show up. Since we default to not
showing merge commits in 'bzr log' (or even when shown, they are shown
indented), there is less impetus to remove them by default.[2]

Guido mentioned that when he does long-term development, there are a lot
of advantages to having intermediate snapshots that he can roll back to,
which have questionable benefit in being in the final repository, since
some states were dead-ends that weren't pursued.

I certainly can understand that, but there is at least an argument that
preserving "this approach is a dead-end" also has some merit. If someone
comes to you and says "why didn't you implement it this way", you can
point to it and say "I tried, it didn't work". Which would also give
them a point to start if they really think it is an avenue to pursue
further.

I also remember something my Math teacher once said. That some of the
early proofs were so polished that nobody knew how to "reproduce" them.
Sure, anyone could follow the final proof and say "yes that is correct",
but nobody could *learn* from the proof, because it was missing those
human-level steps of intuition that helped understand *how* the proof
was developed, rather than just what the final state was.

That is not to say that the python.org primary repository should be a
teaching repository. However, I know that I'm personally quite curious
to see how Guido does his work. Insight into the minds of how
interesting people do interesting things and all.


Another key point of how tools influence and interact with culture.
Because bzr has a strong mainline bias, it leads to people interacting
with the tool differently, which strengthens and reinforces it. In
Mercurial, it would be trivial to add a "hg log --only-mainline" that
would always follow a specific parent and show that to you. However,
because Mercurial doesn't default to that view, people don't try to
preserve the mainline. For example, in these graphs are logically the
same, but result in a very different mainline view:


 A -- B -- C
   \\
 D -- E

 A -- B -- C -- E
   \  /
 D --

If you consider D as "I did my work" and E as "and I integrated that
back into trunk".

If you merge the trunk revision C into E, and then push, you end up with
this graph:

 A -- B -- D -- E
   \  /
 C --

And suddenly the revision which was an "important" C change is now gone
on the mainline, and your personal "and I did D" is now a primary
revision. It doesn't matter much for a single revision D and C, but for
anything long lived, you end up with 100 Guido exploratory D revisions,
and some 50+ other python-dev super-stable trunk C revisions. And unless
the tool helps you preserve the ordering[3], you really don't want to
trying to treat them with different levels of authority. Hence, you tend
to collapse, because you really can only trust "E" to be a final stable
change.

John
=:->



[1] any copy of "trunk" has the same revision-id matching revno 1234,
in Mercurial the numbers in 'hg log' correspond to the ordering in
the physical repository, so depend on what order revisions were
merged, etc.

[2] The downside is people having their work merged and then wondering
"where did my commits go", and it looking like this guy named Patch
was an extremely productive developer of Launchpad and Bazaar
(Patch Queue Manager.)

[3] In Bazaar, you can set 'append_revisions_only = True' for
integration branches. Which will refuse to push E if it would
remove C as a mainline revision.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Id5sACgkQJdeBCYSNAAMnjgCbBFiMtdkj8hvJ19dPn3Maz3Bo
TrwAmwfgmg0YMGaCPM+W+kAVVDVvrOlY
=6oWG
-END PGP SIGNATURE-

[Python-Dev] crosses branches?

[skip]

I came across a new message I neither understood before or after searching
for it on Google (and thus the documentation):

% hg pull -u
pulling from /Users/skip/src/hgpython/2.6
searching for changes
adding changesets
adding manifests
adding file changes
added 242 changesets with 766 changes to 263 files
abort: crosses branches (use 'hg merge' or use 'hg update -c')

What does "crosses branches" mean?  From the couple instances I saw in the
docs I found I couldn't tell.

This was in my 2.5 repository, which I recall Guido saying he updated
recently (copyright file or something?).

I should point out that I have a local commit which I don't want to push.
That fixes the build problem with the unexpanded $HeadURL$ svn keyword:

changeset:   68309:c3caaf979b9e
branch:  2.5
parent:  68263:7790ad8332ba
user:Skip Montanaro 
date:Sun Mar 06 21:31:25 2011 -0600
summary: manually expand the defunct HeadURL subversion keyword

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Adrian Buehlmann]

On 2011-03-22 11:19, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 3/21/2011 9:19 PM, Barry Warsaw wrote:
>> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>> Keeping the repository clean makes it easier to use a bisection search to
>>> hunt down the introduction of a bug.  If  every developer's intermediate
>>> commits make it into the main repository, it's hard to go back to an older
>>> revision to test something, because many of the older revisions will be
>>> broken in some way.
>>
>> So maybe this gets at my earlier question about rebase being cultural
>> vs. technology, and the response about bzr having a strong sense of mainline
>> where hg doesn't.
>>
>> I don't use the bzr-bisect plugin too much, but I think by default it only
>> follows commits on the main line, unless a bisect point is identified within 
>> a
>> merge (i.e. side) line.  So again, those merged intermediate changes are
>> mostly ignored until they're needed.
>>
>> -Barry
> 
> Bazaar is, to my knowledge, the only DVCS that has a "mainline"
> emphasis. Which shows up in quite a few areas. The defaults for 'log',
> having branch-stable revnos[1], and the 'bzr checkout' model for
> managing a mainline.
> 

FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
branch name is reserved, and it implies that the head with the highest
revision number from that branch will be checked out on 'hg clone'.

Which is why it makes sense to have something sensible on the default
branch in Mercurial repositories. Or inadvertent people may be surprised
when they clone ("After cloning, the files I have seem to be from a very
old state of the project, WTF?").

What's more, 'hg log' suppresses printing the line 'branch: default' for
changesets on that branch and commits after 'hg init' go into the
default branch if 'hg branch ' hasn't been used. So, the initial
branch name of a fresh working copy is 'default'.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Useful "hg log" trick to only see revisions in the current branch

[Nick Coghlan]

"hg log -b ." restricts the hg log output to the changesets in the
currently active branch.

Other commands (such as "hg outgoing") similarly accept "-b ." to
request restricting their operation to the current branch.

Also, for anyone that wasn't already aware, "hg update" supports tab
completion when switching branches, which can make life a bit easier
when working with named branches.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Nick Coghlan]

On Tue, Mar 22, 2011 at 7:58 AM, Antoine Pitrou  wrote:
> On Tue, 22 Mar 2011 07:32:33 +1000
> Nick Coghlan  wrote:
>>
>> As far as the second point goes, I'm coming to the view that we should
>> avoid rebase/strip/rollback when intending to push to the main
>> repository, and do long term work in *separate* cloned repositories.
>> Then an rdiff with the relevant cpython branch will create a nice
>> collapsed patch ready for application to the main repository (I have
>> yet to succeed in generating a nice patch without using rdiff, but I
>> still have some more experimentation to do with MvL's last proposed
>> command for that before giving up on the idea).
>
> If you use named branches it's very easy, as explained in the devguide:
> http://docs.python.org/devguide/committing.html#long-term-development-of-features

Yeah, it turns out I had messed up the 'respect_LHS_precedence' branch
in my sandbox , which is why the diffs from there were broken (I had
temporarily merged those changes to "default" and then reverted them,
but subsequently merged the reversion back to the feature branch.
Oops. Fixed now, though, so "hg diff -r default" is once again doing
the right thing).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[anatoly techtonik]

I didn't touch Python3 until PyCon, and my first user experience is
not really good. I've got a feeling that Python3 became more ugly,
because it doesn't allow me to think about the logic anymore, and
requires more low-level workarounds even for basic user input/output.

For example, now I need to remember that on Windows I need to flush
output every time when I want the result of print() with end!='\n' to
appear on the screen immediately. And for the most of my legacy
scripts I used end='\n' when I want to output some progress to user. I
am surprised to know this never worked on Linux, but what I really
didn't expect is to see that choice is made not in user's favor, but
in a favor of speed. This way we'll be writing in a cross-platform
assembly language named 'Python' soon. =)
http://bugs.python.org/issue11633
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

[rndblnch]

Nick Coghlan  gmail.com> writes:

> On Tue, Mar 22, 2011 at 9:21 AM, Guido van Rossum  python.org>
wrote:
> > In the light of the recent discussion about Hg clones, perhaps you
> > could make this a server-side clone so it's easier for others to play
> > along?

I don't have push rights so I can not push anything to .
However, I tried to click the "server side clone", and to my surprise, it
worked. I was expecting that some verification would be made, but there is now
a new feature branch at: .
Sorry to have done that, once again, I was not expecting to actually have the
rights to cause any side-effect on . I guess that it may
not be desirable to allow anyone do such server-side clone.

Anyway, I can not push to this feature branch, so for now it's just a clone of
the curent tip.

> Anyone without push rights for hg.python.org may want to fork the
> mirror the bitbucket folks set up during the PyCon sprints to avoid
> having to push the whole repository up to a separate hosting site:
> https://bitbucket.org/mirror/cpython

Done here:


The pep-380 changeset is pushed on top of current tip and is visible here:


renaud




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

[Nick Coghlan]

On Tue, Mar 22, 2011 at 10:06 PM, rndblnch  wrote:
> Sorry to have done that, once again, I was not expecting to actually have the
> rights to cause any side-effect on . I guess that it 
> may
> not be desirable to allow anyone do such server-side clone.

Unmodified clones don't actually take up much space due to the way the
filesystem on the server works, and if they don't get updated within a
short period of being created (i.e. by someone with commit rights),
the server gets rid of them automatically.

>> Anyone without push rights for hg.python.org may want to fork the
>> mirror the bitbucket folks set up during the PyCon sprints to avoid
>> having to push the whole repository up to a separate hosting site:
>> https://bitbucket.org/mirror/cpython
>
> Done here:
> 
>
> The pep-380 changeset is pushed on top of current tip and is visible here:
> 

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Sjoerd Mullender]

On 2011-03-22 11:54, s...@pobox.com wrote:
> I came across a new message I neither understood before or after searching
> for it on Google (and thus the documentation):
> 
> % hg pull -u
> pulling from /Users/skip/src/hgpython/2.6
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 242 changesets with 766 changes to 263 files
> abort: crosses branches (use 'hg merge' or use 'hg update -c')
> 
> What does "crosses branches" mean?  From the couple instances I saw in the
> docs I found I couldn't tell.
> 
> This was in my 2.5 repository, which I recall Guido saying he updated
> recently (copyright file or something?).
> 
> I should point out that I have a local commit which I don't want to push.
> That fixes the build problem with the unexpanded $HeadURL$ svn keyword:
> 
> changeset:   68309:c3caaf979b9e
> branch:  2.5
> parent:  68263:7790ad8332ba
> user:Skip Montanaro 
> date:Sun Mar 06 21:31:25 2011 -0600
> summary: manually expand the defunct HeadURL subversion keyword

Since you have a local change, you cannot use hg pull -u (or rather, hg
update).  Hg wouldn't know where to update to since there are 2 heads in
the branch you're on: the new head from the server and your own head
with your change.

There are two possibilities: hg merge + hg commit to merge your change
with the change from the server, or hg rebase (after you enable the
extension and with extra arguments to specify source and destination
revisions).  This would take your change and graft if on top of the head
from the server.

Instead of using hg pull -u, you could have used hg pull --rebase (after
enabling the extension) to do the rebase automatically.  But that is for
next time.

-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [GSoC] Porting on RPM3

[Panu Matilainen]

On 03/22/2011 03:06 AM, David Malcolm wrote:

[CCing Panu Matilainen, the maintainer of rpm, or, at least rpm 4.*,
which is what all major distributions are using AIUI]

On Mon, 2011-03-21 at 10:50 +0100, "Martin v. Löwis" wrote:

Am 21.03.2011 07:37, schrieb Prashant Kumar:

Hello,
 My name is  Prashant Kumar and I've worked on porting few python
libraries(distutils2, configobj) and I've been looking at the ideas
list for GSoC for a project related to porting.

 I came across [1]  and found it interesting. It mentions that some


Hi Prashant!  Thanks for the interest.

Panu: [1] is http://wiki.python.org/moin/RPMOnPython3 , a Google Summer
of Code proposal to work on the Python 3 bindings to RPM.


of the work has already been done; I would like to look at the code
repository for the same, could someone provide me the link for the
same?



Not so much the code but the person who did the porting. This was Dave
Malcolm (CC'ed); please get in touch with him. Please familiarize
yourself with the existing Python bindings (in the latest RPM 4 release
from rpm.org). You'll notice that this already has Python 3 support;
not sure whether that's the most recent code, though.


Panu Matilainen also worked on the python 3 port of the librpm python
bindings.

For the rpm source code, see: http://rpm.org/wiki/GetSource  (the python
bindings are in a subdirectory of the main source tree).

My initial patchbomb landed on the mailing list here:
   http://lists.rpm.org/pipermail/rpm-maint/2009-October/002528.html
and Panu committed and fixed up the patches around then.

My understanding is that the current status is that the bindings work,
but all values that were formerly exposed to Python 2 as "str" are now
exposed to Python 3 as "bytes", which would require changing all
consumers of the code.


That's more or less where it stands.


I believe Panu has also been working on a rewrite of the Python
bindings, since the existing code is a little messy.
Panu, am I remembering this correctly?


The python binding rewrite was abandoned (it just didn't work out for 
various reasons) and usable bits merged into the existing bindings.
So yes you're correct - there /was/ such a thing but any new work should 
go to the bindings that exist in the main rpm source tree.



The idea is that these types are fundamentally string-like, but
unfortunately rpm has always been a bit loose in its interpretation of
the encoding of byte values in package files and package databases.
There are millions of rpm files out there, and millions of rpm
databases, and all of these are in _some_ encoding.  I have seen
specfiles in which parts of the file were encoded in UTF-8 and other
parts were encoded in Latin-1 (this broke one of my python scripts
horribly).


More precisely, it's not being "a bit loose" about encoding, rpm simply 
doesn't know diddly about encodings and does not make any assumptions or 
interpretations about them. A string in rpm is just a sequence of 
arbitrary non-zero byte values terminated with \0.



Martin and I discussed this last week at PyCon.  I believe the proposal
that we came up with was:
   - try to interpret bytes as UTF-8, using the "surrogateescape"
mechanism, so that if it fails, we can at least preserve the exact bytes
and round-trip


Right, based on a quick skim of the surrogateescape PEP, that seems like 
a reasonable approach (rpm is much like the traditional POSIX interfaces 
which simply do not deal with encoding at all)



Ultimately, this does mean trying to impose some kind of encoding
standard on rpm files and rpm databases, which I think would be a Good
Thing, but is perhaps something of scope creep compared to what the
proposal at [1] says.  See e.g. http://rpm.org/ticket/30


Note that any frpm forced encoding standard could only affect new 
packages, but rpm and the bindings need to be able deal with all the 
junk out in the wild pretty much forever.




Other ideas that occur:
   - does rpmlint check for encoding yet?


IIRC rpmlint can (depending on config probably) check for encoding of 
the paths and the spec itself. However this still doesn't guarantee all 
the string-data in header to be utf, as practically any part(s) of the 
data can come from macros, which are not encoding-aware either.



   - what to do e.g. about canonicalization?  What happens if one rpm
provide a feature named "café" (where the "é" is U+00E9) and another rpm
requires a feature named "café" (where the "é" is U+0065 LATIN SMALL
LETTER E + U+0301 COMBINING ACUTE ACCENT)?  IIRC we ruled that rpms in
Fedora had to have ASCII names, and I'm guessing this applies to
metadata, but we do allow UTF-8 filenames within package payloads
(again, IIRC)


Ouch. Did I already mention that UTF and the encoding business makes my 
head hurt? I guess I didn't, can't think straight because by now I have 
that headache...


Anyway, pretty much all rules in this area are distro specific, as rpm 
doesn't enforce anything wrt encoding.

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[skip]

Stephen> This won't be pleasant if people are sprinting and lots of
Stephen> commits are coming, because you're likely to repeatedly lose
Stephen> the push race.  But in those conditions, nothing is guaranteed
Stephen> to work in decentralized fashion (that's one reason why the
Stephen> Linux kernel uses Linus and lieutenants as a serialization
Stephen> mechanism).

So DVCS scales up to a point, then it breaks and you need to revert to some
sort of serialization scheme?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[James Y Knight]

On Mar 22, 2011, at 7:57 AM, anatoly techtonik wrote:
> For example, now I need to remember that on Windows I need to flush
> output every time when I want the result of print() with end!='\n' to
> appear on the screen immediately. And for the most of my legacy
> scripts I used end='\n' when I want to output some progress to user. I
> am surprised to know this never worked on Linux, but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed. This way we'll be writing in a cross-platform
> assembly language named 'Python' soon. =)
> http://bugs.python.org/issue11633

Yes, on linux, the C library sets up stderr to be unbuffered and stdout to be 
fully buffered unless it points to a terminal, in which case it's line 
buffered. (Of course that  can always be overridden using setvbuf.) So, yes, 
your program never worked on linux. If you'd sent the progress messages to 
stderr, it should've always worked, however.

This is partially specified by POSIX (it leaves leeway up to the implementor to 
choose line buffered or unbuffered when fully buffered isn't called for):
> At program start-up, three streams are predefined and need not be opened 
> explicitly: standard input (for reading conventional input), standard output 
> (for writing conventional output), and standard error (for writing diagnostic 
> output). When opened, the standard error stream is not fully buffered; the 
> standard input and standard output streams are fully buffered if and only if 
> the stream can be determined not to refer to an interactive device.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[skip]

Senthil> Have a look at this issue:
Senthil> http://bugs.python.org/issue11591

Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
Senthil> where the user provided his bitbucket URL for the path he was
Senthil> working on.

I still don't understand what that's supposed to look like.  Is it supposed
to be a URL which refers to my local repository?  If so, I suspect that
means I have to somehow make my repo globally visible and drill a hole in my
NAT firewall.

Senthil> And when you pressed "Create Patch" button, it created a patch
Senthil> and then attached to the issue tracker.  You can click on the
Senthil> review button to post that patch to reitveld and do the
Senthil> review,.

Sorry, I don't see a "Create Patch" button anywhere.  Are you referring to
some sort of Mercurial GUI?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[skip]

Hrvoje> If you are not familiar with other DVCS workflows, take a look
Hrvoje> at, for example, chapter 5 of the "Pro Git" book, which
Hrvoje> describes the alternatives such as integrator-manager and
Hrvoje> dictator-lieutenant workflows: http://progit.org/book/ch5-1.html

Thanks.  That more-or-less answers the question I posed for Stephen a few
minutes ago.  (Oh, that I could read multiple messages in parallel!)

S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Useful "hg log" trick to only see revisions in the current branch

[R. David Murray]

On Tue, 22 Mar 2011 21:11:42 +1000, Nick Coghlan  wrote:
> Also, for anyone that wasn't already aware, "hg update" supports tab
> completion when switching branches, which can make life a bit easier
> when working with named branches.

You are the second person I've heard say this, and it is a little
misleading.  At the point at which you hit 'tab' when typing an hg update
command, hg isn't running.  So it can't be 'hg update' that supports
tab completion, it must be your shell that supports tab completion *for*
hg update.  My zsh shell does, while my bash shell doesn't: because I
don't use bash, I installed mercurial without bash-completion.

So: there is completion support for hg update for both bash and zsh.
Not sure about other shells.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Senthil Kumaran]

On Tue, Mar 22, 2011 at 07:26:25AM -0500, s...@pobox.com wrote:
> 
> Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
> Senthil> where the user provided his bitbucket URL for the path he was
> Senthil> working on.
> 
> I still don't understand what that's supposed to look like.  Is it supposed
> to be a URL which refers to my local repository?  

No, it is the "Remote Repository". It could be one at bitbucket.org or
code.google.com, both of which support creating mercurial
repositories. Or it could be a repository at hg.python.org and with a
url like hg.python.org/sandbox/skip or hg.python.org/skip

You will have to 'push' your changes to those so that they are
publicly visible and then point that url in the bug-tracker.

> If so, I suspect that
> means I have to somehow make my repo globally visible and drill a hole in my
> NAT firewall.

You can do that or use one of existing facilities available for
pushing your code to a public hg repository.


> Senthil> And when you pressed "Create Patch" button, it created a patch
> Sorry, I don't see a "Create Patch" button anywhere.  Are you referring to
> some sort of Mercurial GUI?

No, the same http://bugs.python.org/issue11591
You have to be logged into the tracker to see "Create Patch" under a
section called "Repositories containing patches"

-- 
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Éric Araujo]

> I still don't understand what that's supposed to look like.  Is it supposed
> to be a URL which refers to my local repository?
No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting service).

You have to use one public repo per bug, as roundup will only use the
default branch to compute the diff.  Maybe adding support for named
branches so that you can have one repo used for many bug reports would
be useful.

> Sorry, I don't see a "Create Patch" button anywhere.
On the right of the field containing the repo URI on
http://bugs.python.org/issue11591

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blogroll for the new blog

[Tim Golden]

Well I've created a python-dev category under my usual blog so if you wouldn't 
mind adding that:

  http://ramblings.timgolden.me.uk/category/tech/python/python-dev/

TJG
Tim Golden
Senior Analyst Programmer

CBS Outdoor UK
Camden Wharf
28 Jamestown Road
London
NW1 7BY
T: 020 7482 3000
F: 020 7267 4944


http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/Newsletter-sign-up
Don't waste paper. Think before you print.
The contents of this e-mail are confidential to the ordinary user of the e-mail 
address to which it was addressed, and may also be privileged. If you are not 
the addressee of this e-mail you may not copy, forward, disclose or otherwise 
use it or any part of it in any form whatsoever. If you have received this 
e-mail in error, please e-mail the sender by replying to this message. CBS 
Outdoor Ltd reserves the right to monitor e-mail communications from 
external/internal sources for the purposes of ensuring correct and appropriate 
use of CBS Outdoor facilities. CBS Outdoor Limited, registered in England and 
Wales with company number 02866133 and registered address at Camden Wharf, 28 
Jamestown Road, London, NW1 7BY.





This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[skip]

Sjoerd> Since you have a local change, you cannot use hg pull -u (or
Sjoerd> rather, hg update).  Hg wouldn't know where to update to since
Sjoerd> there are 2 heads in the branch you're on: the new head from the
Sjoerd> server and your own head with your change.

I see lots of heads, but that never prevented an update before.  How do I
tell which two heads are key to this case?  For completeness, here's the
output of hg heads in my 2.5 repository.  I only see one labelled "2.5".
What is the other head to which you referred?

changeset:   68827:3114f26d5d54
tag: tip
user:Victor Stinner 
date:Tue Mar 22 10:46:35 2011 +0100
summary: Issue #11630, issue #3080: Fix refleak introduced by
ef2b6305d395

changeset:   68804:f316e6d6271a
branch:  2.7
parent:  68801:6b2edc385ffe
parent:  68803:b99c94261225
user:Martin v. L?wis 
date:Mon Mar 21 10:32:02 2011 +0100
summary: null merge

changeset:   68309:c3caaf979b9e
branch:  2.5
parent:  68263:7790ad8332ba
user:Skip Montanaro 
date:Sun Mar 06 21:31:25 2011 -0600
summary: manually expand the defunct HeadURL subversion keyword

changeset:   68249:4cd9f5e89061
branch:  3.0
user:Georg Brandl 
date:Sat Mar 05 15:09:43 2011 +0100
summary: Close 3.0 branch.

changeset:   68241:b77918288f7d
branch:  legacy-trunk
user:Georg Brandl 
date:Sat Mar 05 14:57:44 2011 +0100
summary: Close legacy-trunk branch.

changeset:   68239:ceec209b26d4
branch:  2.4
user:Georg Brandl 
date:Sat Mar 05 14:56:41 2011 +0100
summary: Close 2.4 branch.

changeset:   68237:364638d6434d
branch:  2.3
user:Georg Brandl 
date:Sat Mar 05 14:55:46 2011 +0100
summary: Close 2.3 branch.

changeset:   68235:61b0263d6881
branch:  2.2
user:Georg Brandl 
date:Sat Mar 05 14:55:23 2011 +0100
summary: Close 2.2 branch.

changeset:   68233:e849d484029f
branch:  2.1
user:Georg Brandl 
date:Sat Mar 05 14:54:46 2011 +0100
summary: Close 2.1 branch.

changeset:   68231:5fd74354d73b
branch:  2.0
user:Georg Brandl 
date:Sat Mar 05 14:54:19 2011 +0100
summary: Close 2.0 branch.

Sjoerd> There are two possibilities: hg merge + hg commit to merge your
Sjoerd> change with the change from the server, or hg rebase (after you
Sjoerd> enable the extension and with extra arguments to specify source
Sjoerd> and destination revisions).  This would take your change and
Sjoerd> graft if on top of the head from the server.

Looking here at the Common Cases section:

http://mercurial.selenic.com/wiki/RebaseProject

I can see how I have now apparently got this situation:

 C1 --> C2 --> S1
\
 \ --> ... Cn

(where S1 is my local change and C? are the central changesets)

Rebase will do this, right?

 C1 --> C2 --> ... --> Cn --> S1

Am I going to have to rebase then every time I re-pull that repository and
incorporate new upstream changes?  Wouldn't I rather want the chain of
revisions to look like this after the rebase step?

 C1 --> C2 --> S1 --> ... --> Cn

Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Barry Warsaw]

On Mar 21, 2011, at 11:09 PM, Martin v. Löwis wrote:

>However, what some of us requesting is that the "SHOULD collapse"
>in the devguide is changed to a "MAY collapse", making it strictly
>an option of the committer.

+1

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Barry Warsaw]

On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:

>FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>branch name is reserved, and it implies that the head with the highest
>revision number from that branch will be checked out on 'hg clone'.

I think that's different than what John was describing, or perhaps Python's
use of it has the effect of being different.  IIUC, in Mercurial, within the
default branch there's no clear "main line" of development assigned to a path
within the DAG.  All paths are created equal, so it's not possible to
e.g. have log or bisect suppress one path containing feature sub-commits from
the point of departure to the point of recombination (merge).

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Barry Warsaw]

On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote:

>Bazaar apparently has a notion of mainline whereas Mercurial believes
>that all changesets are created equal.  The tools are different.

I'm curious: what are the benefits of the Mercurial model?

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Barry Warsaw]

On Mar 22, 2011, at 07:51 AM, Martin v. Löwis wrote:

>Am 22.03.2011 02:02, schrieb Eugene Toder:
>>> Not if the changes you want to suppress are actually also on the same
>>> branch as the one whose mainline you are trying to see (which they
>>> typically are, with the branch typically being "default").
>>
>> Right, that would amount to not using named branches. But if you
>> develop on a named feature-branch and merge into "default" when ready
>> your local history is easy to filter-out without rebasing or
>> collapsing.
>
>Ah. We don't support this kind of development - no new named branches
>are allowed in the central repository.

It does sound like that restriction is a source of friction for us.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Fred Drake]

On Tue, Mar 22, 2011 at 10:25 AM, Barry Warsaw  wrote:
> I'm curious: what are the benefits of the Mercurial model?

If we're all left confused and unable to use the tools to change the
software, we won't break things.  This is good.  :-)


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Paul Moore]

On 22 March 2011 12:53, Éric Araujo  wrote:
>> I still don't understand what that's supposed to look like.  Is it supposed
>> to be a URL which refers to my local repository?
> No, to a repository published somewhere (hg.python.org, bitbucket (make
> a server-side clone of mirror/cpython), any other hosting service).
>
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff.  Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.

I don't know if it's supported here, but Mercurial allows branch names
in URLS. See "hg help urls" but it's basically something like

http://hg.python.org/cpython#3.1

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Sjoerd Mullender]

On 2011-03-22 15:11, s...@pobox.com wrote:
> 
> Sjoerd> Since you have a local change, you cannot use hg pull -u (or
> Sjoerd> rather, hg update).  Hg wouldn't know where to update to since
> Sjoerd> there are 2 heads in the branch you're on: the new head from the
> Sjoerd> server and your own head with your change.
> 
> I see lots of heads, but that never prevented an update before.  How do I
> tell which two heads are key to this case?  For completeness, here's the
> output of hg heads in my 2.5 repository.  I only see one labelled "2.5".
> What is the other head to which you referred?

Two heads in the same branch.
Are you sure the hg pull part worked?  When I update I see there are
changes on the 2.5 branch which I would expect to see in your list.
It probably never happened before because nobody committed a change to
the 2.5 branch since you made your change.

So, try hg pull and the look at the heads again.

> changeset:   68827:3114f26d5d54
> tag: tip
> user:Victor Stinner 
> date:Tue Mar 22 10:46:35 2011 +0100
> summary: Issue #11630, issue #3080: Fix refleak introduced by
> ef2b6305d395
> 
> changeset:   68804:f316e6d6271a
> branch:  2.7
> parent:  68801:6b2edc385ffe
> parent:  68803:b99c94261225
> user:Martin v. L?wis 
> date:Mon Mar 21 10:32:02 2011 +0100
> summary: null merge
> 
> changeset:   68309:c3caaf979b9e
> branch:  2.5
> parent:  68263:7790ad8332ba
> user:Skip Montanaro 
> date:Sun Mar 06 21:31:25 2011 -0600
> summary: manually expand the defunct HeadURL subversion keyword
> 
> changeset:   68249:4cd9f5e89061
> branch:  3.0
> user:Georg Brandl 
> date:Sat Mar 05 15:09:43 2011 +0100
> summary: Close 3.0 branch.
> 
> changeset:   68241:b77918288f7d
> branch:  legacy-trunk
> user:Georg Brandl 
> date:Sat Mar 05 14:57:44 2011 +0100
> summary: Close legacy-trunk branch.
> 
> changeset:   68239:ceec209b26d4
> branch:  2.4
> user:Georg Brandl 
> date:Sat Mar 05 14:56:41 2011 +0100
> summary: Close 2.4 branch.
> 
> changeset:   68237:364638d6434d
> branch:  2.3
> user:Georg Brandl 
> date:Sat Mar 05 14:55:46 2011 +0100
> summary: Close 2.3 branch.
> 
> changeset:   68235:61b0263d6881
> branch:  2.2
> user:Georg Brandl 
> date:Sat Mar 05 14:55:23 2011 +0100
> summary: Close 2.2 branch.
> 
> changeset:   68233:e849d484029f
> branch:  2.1
> user:Georg Brandl 
> date:Sat Mar 05 14:54:46 2011 +0100
> summary: Close 2.1 branch.
> 
> changeset:   68231:5fd74354d73b
> branch:  2.0
> user:Georg Brandl 
> date:Sat Mar 05 14:54:19 2011 +0100
> summary: Close 2.0 branch.
> 
> Sjoerd> There are two possibilities: hg merge + hg commit to merge your
> Sjoerd> change with the change from the server, or hg rebase (after you
> Sjoerd> enable the extension and with extra arguments to specify source
> Sjoerd> and destination revisions).  This would take your change and
> Sjoerd> graft if on top of the head from the server.
> 
> Looking here at the Common Cases section:
> 
> http://mercurial.selenic.com/wiki/RebaseProject
> 
> I can see how I have now apparently got this situation:
> 
>  C1 --> C2 --> S1
> \
>  \ --> ... Cn
> 
> (where S1 is my local change and C? are the central changesets)
> 
> Rebase will do this, right?
> 
>  C1 --> C2 --> ... --> Cn --> S1
> 
> Am I going to have to rebase then every time I re-pull that repository and
> incorporate new upstream changes?  Wouldn't I rather want the chain of
> revisions to look like this after the rebase step?
> 
>  C1 --> C2 --> S1 --> ... --> Cn
> 
> Skip
> 


-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/22/2011 3:22 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:
> 
>> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>> branch name is reserved, and it implies that the head with the highest
>> revision number from that branch will be checked out on 'hg clone'.
> 
> I think that's different than what John was describing, or perhaps Python's
> use of it has the effect of being different.  IIUC, in Mercurial, within the
> default branch there's no clear "main line" of development assigned to a path
> within the DAG.  All paths are created equal, so it's not possible to
> e.g. have log or bisect suppress one path containing feature sub-commits from
> the point of departure to the point of recombination (merge).
> 
> -Barry

If you think of "mainline" as "trunk" or "master", then yes, Mercurial's
concept is "default".

If you think of "mainline" as a series of commits in a linear sequence,
then there isn't specifically a "main" "line" in Mercurial's world view.

In Bazaar, the sequence of first-parents in the history of a branch's
tip is considered special. Based on the concept that:

 cd me
 bzr merge ../you
 bzr commit -m "I merged you"

Is not the same *social* thing as:

 cd ../you
 bzr merge ../me
 bzr commit -m "You merged me"

Logically, the contents of the tree should be the same. The name of the
person doing it is often different. If you have "blessed branch"
approach to development (which almost all projects do at some level or
other) then merging something into the "blessed branch" is not the same
as merging the "blessed branch" into your personal branch.

For python, the "blessed branch" is http://hg.python.org/cpython.

Consider, if someone merges/pushes a change to that branch, it has very
different social consequences than if someone merges that branch into
their own feature branch. Namely, it is going to be part of the next
released tarball.


Note that hg does distinguish it a little bit. If you look here:
http://hg.python.org/cpython/graph

There is a clear separation of what was merged into the line on the
left, versus what was committed elsewhere. However, there is no
distinction on:
http://hg.python.org/cpython/shortlog

Note also that because 'hg log' doesn't default to only showing you
things on a given branch, you can end up with log views like this:
http://hg.python.org/cpython/graph/693415328363

Where "Relax timing check" has nothing to do with "Issue #10833", but
because the data in the repository has Relax Timing Check placed after
Issue #10833 physically on disk, they end up both getting shown in the
log view.

It certainly is much worse in
http://hg.python.org/cpython/shortlog/693415328363

Where there is no way to tell that the revisions are unrelated, and just
happen to physically reside in same repository.

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Iu5kACgkQJdeBCYSNAAMVQACgpGd53yMnQBjJXuoVLElxC6qN
OqwAmwTdxjIS5tjkf0+iK62DvT/uPLdz
=1YLF
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/22/2011 3:25 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote:
> 
>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal.  The tools are different.
> 
> I'm curious: what are the benefits of the Mercurial model?
> 
> -Barry
> 

- From discussions in #bzr, I would say the primary complaint to our model
is that people feel it means that not all revisions are created equal.

Though honestly, that is true. Getting a revision into Linus's kernel
tree is not the same as getting it into my own branch of the kernel.

I do remember discussions where people felt bad that after integrating
someone else's work, by default it showed their name, rather than the
names of the people who had done the actual work. (Though you could
always use --author if you really wanted to change the name on that commit.)


There is a technical argument. A merging B should be idempotent to B
merging A. And certainly, the file-content should be the same after
either operation.

But as I mentioned in the other email, Barry merging my work and
committing it to the hg.python.org/cpython branch is very different
socially than me merging cpython's branch. So bzr is somewhat
distinguishing "things done on this branch" from "things done in other
branches that I have included into this branch.".


Simplicity. If you enforce the mainline concept with
"append_revisions_only=True" on your trunk branches. Then people who try
to do:

 cd my-work
 merge trunk && commit
 push trunk

Will be blocked. While if you did
 cd trunk
 merge my-work && commit
 push trunk

It would succeed. If a tool doesn't give you a benefit from maintaining
a mainline, there is overhead in preserving it.

If your tool defaults to fast-forward merging, it is also really hard to
get the behavior. (git does this with a config option to disable it, bzr
has it as an option to merge [defaulting to off], and I'm not sure what
Mercurial's default is.)

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ivi4ACgkQJdeBCYSNAAOhzwCg0tD1KdR53fH7OEzhom0IaPOL
niYAn2KsY2jPLJmbXWf8sIauMW+y2hHC
=NFdA
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[skip]

>> I still don't understand what that's supposed to look like.  Is it
>> supposed to be a URL which refers to my local repository?

Senthil> No, it is the "Remote Repository". It could be one at
Senthil> bitbucket.org or code.google.com, both of which support
Senthil> creating mercurial repositories. Or it could be a repository at
Senthil> hg.python.org and with a url like hg.python.org/sandbox/skip or
Senthil> hg.python.org/skip

Senthil> You will have to 'push' your changes to those so that they are
Senthil> publicly visible and then point that url in the bug-tracker.

I can see this turning into a giant bowl of spaghetti.  How in the world are
people supposed to understand how all these repositories are related to each
other?

Senthil> You can do that or use one of existing facilities available for
Senthil> pushing your code to a public hg repository.

Doesn't that just complicate my setup?  Let's just consider the cpython repo
(is that the right term? maybe branch instead?).  Today, I have a local
repository named "cpython" which refers to ssh://h...@hg.python.org/cpython as
its default.  Now you suggest I need to create another public repository.
So my "chain of command" becomes: local depends on my global, which depends
on the real cpython global.  Now replicate that for the different active
branches (2.7, 3.2 at least).

Senthil> And when you pressed "Create Patch" button, it created a patch

>> Sorry, I don't see a "Create Patch" button anywhere.  Are you
>> referring to some sort of Mercurial GUI?

Senthil> No, the same http://bugs.python.org/issue11591 You have to be
Senthil> logged into the tracker to see "Create Patch" under a section
Senthil> called "Repositories containing patches"

I was logged in.  It is not obvious.  In addition, now that I've found it, I
see that there are two.  WTF?

The Roundup interface is getting extraordinarily messy.  In the above case I
count 23 user interface components for just that one case, not including all
the Remove buttons for the individual comments:

   5 in classification
   13 in process
   1 Submit changes button
   2 under Files/file name
   2 under Files/Repositories containing patches

The above count does not include simple HTML links, which themselves can be
just as important as the buttons, text areas and pop up menus.

Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[skip]

Sjoerd> Are you sure the hg pull part worked?

Pretty sure:

2.7% hg pull
Enter passphrase for key '/Users/skip/.ssh/id_rsa':
pulling from ssh://h...@hg.python.org/cpython
searching for changes
no changes found
2.7% cd ../2.6
2.6% hg pull
pulling from /Users/skip/src/hgpython/2.7
searching for changes
no changes found
2.6% cd ../2.5
2.5% hg pull
pulling from /Users/skip/src/hgpython/2.6
searching for changes
no changes found

Sjoerd> So, try hg pull and the look at the heads again.

Looks the same to me.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Sjoerd Mullender]

On 2011-03-22 16:56, s...@pobox.com wrote:
> 
> Sjoerd> Are you sure the hg pull part worked?
> 
> Pretty sure:
> 
> 2.7% hg pull
> Enter passphrase for key '/Users/skip/.ssh/id_rsa':
> pulling from ssh://h...@hg.python.org/cpython
> searching for changes
> no changes found
> 2.7% cd ../2.6
> 2.6% hg pull
> pulling from /Users/skip/src/hgpython/2.7
> searching for changes
> no changes found
> 2.6% cd ../2.5
> 2.5% hg pull
> pulling from /Users/skip/src/hgpython/2.6
> searching for changes
> no changes found
> 
> Sjoerd> So, try hg pull and the look at the heads again.
> 
> Looks the same to me.
> 
> Skip

Perhaps looking at the glog output will shed some light.  If you don't
have it yet, enable the graphlog extension, after which you can use hg
glog to look at your clone.  Look in particular at the changeset which
is marked with an @ sign instead of an o.  That (or those if you're in
the middle of a merge) is the "parent" of your working set.

-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Sjoerd Mullender]

On 2011-03-22 15:11, s...@pobox.com wrote:

I realized I didn't answer this:

> Looking here at the Common Cases section:
> 
> http://mercurial.selenic.com/wiki/RebaseProject
> 
> I can see how I have now apparently got this situation:
> 
>  C1 --> C2 --> S1
> \
>  \ --> ... Cn
> 
> (where S1 is my local change and C? are the central changesets)
> 
> Rebase will do this, right?
> 
>  C1 --> C2 --> ... --> Cn --> S1

Yes, that's correct.

> Am I going to have to rebase then every time I re-pull that repository and
> incorporate new upstream changes?  Wouldn't I rather want the chain of
> revisions to look like this after the rebase step?
> 
>  C1 --> C2 --> S1 --> ... --> Cn

I guess you could try to reverse the source and destination changeset
for the rebase, but I think you will get into trouble this way.  What
rebase does, basically, is to remove the changesets being rebased from
the clone and adding them back somewhere else.  But in doing so, the
changeset changes identity.  This means that afterwards when you do a
pull, those moved changesets will be fetched again from the source clone
(they had been removed from yours, so aren't there anymore) and you will
get a similar graph again, but now the S1 will be a list of changesets
instead of the one.

-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Daniel Stutzbach]

On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull wrote:

> Speaking for myself, I rewrite my git history because it is *not*
> useful to me as is.  Almost all of my git commits have a informational
> half-life measured in hours once they're off tip, because I commit
> with *every* save (I have an after-save-hook to do this), which I do
> "early and often".  Effectively, I use git as an extension to XEmacs's
> undo/redo mechanism.
>

I, too, commit using git with every save (which I do early and often).  It's
saved my butt more than once.  Awhile ago I came across the following nice
tool that puts these intermediate commits in a side branch (that can later
be abandoned) so they never show up in the main history:

https://github.com/bartman/git-wip

I imagine something similar could be written for hg.

-- 
Daniel Stutzbach
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Workflow proposal

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.

All branches (except 2.7) MUST be merged to default, all the time. This
must be enforced by the push hook.

The workflow would be something like this:

1. Update the local clone.
2. I patch 3.1. Test the patch locally.
3. Commit the patch locally.
4. Merge the patch to 3.2 locally.
5. Merge the patch to "default" locally.
6. Push.

If there are no other pushes in the meantime, we are done. If there are
other pushes, we will have a "+1 head" and the push is rejected.

Now we have two options.

The easier and "mercurial" way would be:

6. Pull.
7. Merge the two heads.
8. Merge that merge to the other branches, as necessary. Since the two
heads were already merged to other branches, this merge should be trivial.
9. Push.

If we have some other pushes in the meantime, repeat again from 6. You
will eventually win the race :).

This head merging could be "ugly" to some people (not me), so other
approach would be, if the original "merging" is easy:

6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
"default". Leave the original commit in "3.1" alone.
7. Pull and rebase your commit to the incoming head. Now your local
history is lineal.
8. Do the merge to "3.2" and "default", locally.
9. Try to push.

If there are more pushes in the meantime, repeat from 6.

This second approach keep a lineal history, but it is more "dangerous"
and can be a pain if the merges to "3.2" and "default" are not trivial,
because you must do them several times.

This workflow works well ONLY if we forbid to have active branches
(except "default" and "2.7"). That is, forbidding having branches not
merged to new versions. That is, 3.1 merged to 3.2 and default, 3.2
merged to default. This should be implemented in the push hook.

If some patches in 3.1 should not be in 3.2/default, we MUST do a null
merge anyway. The "no active branches" must not be broken. It should be
a firm policy enforced by the push hook.

So good so far.

But there is a *legitime* reason for pushing a 3.1 patch without
merging... trying the patch in the buildbots, maybe redoing it a few
times, discussing it bugs.python.org, try several approaches, etc,
before closing the issue and merging to 3.2 and "default". But that is
an artifact of the way we interact with the buildbots. If I could do the
following, it would be AMAZING:

1. Write a patch in my local clone.
2. Commit it locally.
3. Push my clone to a SANDBOX in hg.python.org ("hg push sandbox"). This
sandbox is synchronized with the official HG repository. If my push
create a "+1 head", we have a race. I must pull and merge, and try to
push again.
4. When I get my patch in the sandbox. the sandbox accepts it, generate
a patch relative to current tip from hg.python.org, and strip that
commit. The sandbox must be always synchronized with hg.python.org. Its
only mission is to validate that your patch applies cleanly to current
tip, that you have push permissions (security).
5. The buildbots should checkout hg.python.org and apply your patch over
the working directory. Run the buildbots testing.
6. You wait for the results.
7. If you are not ok with the result, your keep modifying your clone.
When you want to try, you push to the sandbox, for trying.
8. When you are satisfied with the result, you do the merge to the other
branches and push to "hg.python.org".

Several people can use the sandbox at the same time, since it is
synchronized with hg.python.org and it strips your patch inmediatelly,
so nobody will see your patch. In fact, this sandbox could add your
patch automatically to the assigned issue (bugs.python.org).

We already have "cloned in the server" repositories, but I am not sure
how to delete them, how to push them to the buildbots (is it efficient?,
of the buildbots must pull the complete repo each time?), I must care
about pushing it the last changes in hg.python.org, etc.

Ideas?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYjehJlgi5GaxT1NAQInJAQAn61i1YFwUB/IXkNazJZfRi3dVYVTikbE
t5qBpvFKZKA/s90y6fP6usa09DZVlYXsb95leMIaTc2BjXzgB5qd9I47rFlA+pbk
mjHbVoDmsNcjjI93lRhZV4p7MSeWWSkNDpF/H3qi/bPw3MKqkJFpT9sVkboBs3iO
UbtKE9+Dnno=
=GVMW
-END PGP SIGNATURE-
___
Python-Dev mail

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mar 22, 2011, at 10:45 AM, John Arbash Meinel wrote:

>I'm personally a huge fan of 2(multi)-tier testing. So you have a basic
>(and fast) test suite that runs across all your modules before every
>commit in your mainline. Then a much larger (and slower) test suite that
>runs regression testing across all platforms/etc that runs
>asynchronously.

Python sort of has that, but I guess it depends on your definition of "fast"
:).  Here are my run times.

'make quicktest': 18m
'make test' : 30m
'make testall'  : 35m

It probably wouldn't be a bad idea to add a very fast "smoke test" for the
case where you get tripped up on the merge dance floor.  When that happens,
you could run your localized tests, and then a set of tests that run in just a
minute or two.

- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNiOmZAAoJEBJutWOnSwa/GGgP/0A0glNa+8qf1Tg//Cqjp6G+
n1YX+0h9pciKqwr1O30y1V+cbak6AMGYG6AZq/Mj6vrcFCobJdhxZja9T7An4TxW
BzW1vCw3eEBG9WC4APG1yaIm4N2+RdDqneJCsh0e84T6J2BxOdJLhW2/Gs2UEN47
j3T4v1qVldGVD/hVms4Z5YjXt1A/jwio2q6tdCLhx6rQbf2D6iXWhZHqAepkJkz8
Rc7+FT8fqbdVQpLmmvf28IjxGANBf1rEhnA4YUaKv1syelo+o7ti+j3icVLG5XNn
qFqIXbTslxMv6DI818gPTYmPDDuGsoaBfXGS1VOeNBhE/Gmqy5h5VfE376Il+tCU
khb7usMzFUjm4BMRovCT+psfIENFqtncuknqrthp20T2UeERetKUCBET4ueIxhiw
T6Vt/AOCx+h31kkjX33xHsFI8mZSZi02Wm/GEAQWvE7w13eI5cA8bvnTR8Nm0aaF
3o/EmoeVPvLruBhmg8iTtLB6nESywntaeMmYIkPHDN7KmvNNKzs/Gg5/mP+77uHm
FdesGi3z8stH6YN7JMdV7CE0MXkoiEepXbdh0PnEMKEmdYuKAmJjnexVuPpRaz5K
KryfbMiFaGBFMBpw2wBc055pzuKBL+kRP9gLRhcpmtgb2PELNKSWnPgEHT1DXsGd
BzSsvD2GHs1rdPOGQyRu
=0qS1
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[R. David Murray]

On Tue, 22 Mar 2011 15:39:55 +0100, Sjoerd Mullender  wrote:
> On 2011-03-22 15:11, s...@pobox.com wrote:
> > I see lots of heads, but that never prevented an update before.  How do I
> > tell which two heads are key to this case?  For completeness, here's the
> > output of hg heads in my 2.5 repository.  I only see one labelled "2.5"
> > What is the other head to which you referred?
> 
> Two heads in the same branch.
> Are you sure the hg pull part worked?  When I update I see there are
> changes on the 2.5 branch which I would expect to see in your list.
> It probably never happened before because nobody committed a change to
> the 2.5 branch since you made your change.

Note that one of the changes in 2.5 was Martin fixing the compile,
so your local commit is no longer required.  What you do with that
information, I don't really know (probably a null merge, but you'll
have to figure out the state of your repo first...or you could start
over with a fresh clone).

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[R. David Murray]

On Tue, 22 Mar 2011 07:21:24 -0500, s...@pobox.com wrote:
> 
> Stephen> This won't be pleasant if people are sprinting and lots of
> Stephen> commits are coming, because you're likely to repeatedly lose
> Stephen> the push race.  But in those conditions, nothing is guaranteed
> Stephen> to work in decentralized fashion (that's one reason why the
> Stephen> Linux kernel uses Linus and lieutenants as a serialization
> Stephen> mechanism).
> 
> So DVCS scales up to a point, then it breaks and you need to revert to some
> sort of serialization scheme?

Note that svnmerge broke at exactly the same scale point, for exactly the
same reason:  every svnmerge touched root properties, thereby effectively
serializing access to the tree.  There were lots of curses from people
trying to svnmerge at the sprints in previous years.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/03/11 11:19, John Arbash Meinel wrote:
> And suddenly the revision which was an "important" C change is now gone
> on the mainline, and your personal "and I did D" is now a primary
> revision. It doesn't matter much for a single revision D and C, but for
> anything long lived, you end up with 100 Guido exploratory D revisions,
> and some 50+ other python-dev super-stable trunk C revisions. And unless
> the tool helps you preserve the ordering[3], you really don't want to
> trying to treat them with different levels of authority. Hence, you tend
> to collapse, because you really can only trust "E" to be a final stable
> change.

Mercurial merge has a "left" and "right" parents concept. Some commands
only follow the "left" side. For instance, "hg log --follow-first".

We could have a trivial "push hook" to enforce that the current tip be
the "left/first" parent for any merge.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYjroJlgi5GaxT1NAQKWewP9GjCnnZhmwRXw+fQX7n9YpTXeE2y2fw6M
lPHkw3EFezYRZCyBE1GEM2pnMboJfoh/SxTRaPP68Tp8sAJ0A/5sN1Xh+hDax2wm
6oSOo6lbtDaEJHNpIZpeEu4Z5Axh9mn851atMvI1iImb1UCAsANsZ7AyNqPZVkxo
EbDa34Ppv2w=
=lYXJ
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

[Michael Foord]

On 22/03/2011 07:21, Mark Hammond wrote:

Hi all,
  I've made some changes to the draft PEP and checked it into the PEP 
repository as PEP397.  The reference implementation is currently being 
tracked at http://bugs.python.org/issue11629.




Hey Mark,

One way of supporting alternative implementations (that may not even 
have a standard install directory) is allowing configuration. e.g. 
config.ini


[paths]
ironpython = c:\Program Files\IronPython 2.7\ipy.exe
ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
jython = c:\Users\foobar\jython2.5\jython.exe

Pythons specified in this way should be recognised in the shebang line 
using any of the formats:


#! ironpython
#! /usr/bin/ironpython
#! /usr/bin/env ironpython

This would also permit alternative install locations. (And it would be 
nice if the launcher could use the config file to *automatically* do the 
right thing for the 'w' variants.)


All the best,

Michael


Most of the changes should not be too controversial, but of note:

* I've added lots of discussion about the child-process issue and the 
wording now states, basically, that in-process is not feasible, but if 
we use the win32 Job API we can arrange for the child to be killed 
with the parent on Windows XP and later.  The reference implementation 
demonstrates this thanks to an example from Curt Hagenlocher.


* 64bit and 32bit considerations have been added, along with basic 
information about other distros and implementations.


* The somewhat controversial optional first command-line parameter 
which allows you to specify a particular version for interactive use 
has grown an almost-certain-to-be-controversial option to specify the 
bittedness of the Python you wish to start.  I've added this mainly as 
it would scratch my personal itch as I tend to have 32bit and 64bit 
implementations of most versions available and while this isn't 
particularly common, I'm going to attempt to defend it on the 
principle of "just don't use it if you don't like it" :)  Note the 
reference implementation does not yet implement this, nor does it 
implement the general policy about 32bit vs 64bit considerations.


Please let me know what you think and what objections/comments/etc 
remain.


Thanks,

Mark


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

> Senthil> You will have to 'push' your changes to those so that they are
> Senthil> publicly visible and then point that url in the bug-tracker.
> 
> I can see this turning into a giant bowl of spaghetti.  How in the world are
> people supposed to understand how all these repositories are related to each
> other?

Yes, it will turn into a giant bowl of spaghetti - that's the whole
point of "Distributed" version control systems.

So: don't bother about this. There is certainly going to be a lot of
repository that you don't know about, just as you didn't know about
patches that may have circulated before. If people want you to know
about a clone, they have to tell you - one way of doing that is to
attach its link to a tracker issue.

> The Roundup interface is getting extraordinarily messy.

So what is your constructive proposal?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Dirkjan Ochtman]

On Tue, Mar 22, 2011 at 19:29, R. David Murray  wrote:
> Note that svnmerge broke at exactly the same scale point, for exactly the
> same reason:  every svnmerge touched root properties, thereby effectively
> serializing access to the tree.  There were lots of curses from people
> trying to svnmerge at the sprints in previous years.

The right solution here is to use different clones for different
projects/areas. The proposed interpreter/stdlib split, for example,
might reduce contention (although I imagine it would reduce it only by
a little bit?). Supposedly other meaningful subdivisions exist. Then
people working on those projects don't keep the central repo occupied,
instead only merging their project tree into the main tree on some
delayed schedule (say, weekly).

This is something that Mozilla has been doing, for example, their JS
interpreter is now developed in a separate clone. It might also be a
good match for sprints, where one room could have its own repo and the
other room has a different repo. Or all the packaging sprinters push
to their cpython-packaging repo.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [GSoC] Porting on RPM3

[Nick Coghlan]

On Tue, Mar 22, 2011 at 7:29 PM, Panu Matilainen
 wrote:
> The bindings cannot go changing header contents to their liking, so any
> canonicalization would have to go into rpm proper, the build-side of things
> to be exact so the runtime doesn't have to care. Requiring rpm to fiddle
> with encodings + canonicalization for every single string it processes at
> runtime would require enormous changes throughout rpm, and presumably at a
> massive performance cost too.

Just a hint from our experience with APIs like os/email/urllib.parse:
you pretty much end up *needing* to have parallel bytes and str APIs
(including higher level data structures that know how to encode and
decode themselves) to get this to work properly. The str APIs will
work 90% of the time, but you still need access to the raw bytes to
recover when the simple approach fails. One key choice to be made is
whether to go the brittle option (i.e. ASCII) for the implicit
decoding, or the permissive one (i.e. UTF-8 with surrogateescape). The
former punts on the complicated encoding issues (e.g. urllib.parse
does this, since correctly formed URLs are meant to be encoded into
pure ASCII), while the latter works by default in more situations, but
can allow malformed data to escape the IO layer and cause problems in
other parts of the program (e.g. many of the os APIs do this, since
real world applications often care more about round tripping correctly
between different OS interfaces).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Useful "hg log" trick to only see revisions in the current branch

[Nick Coghlan]

On Tue, Mar 22, 2011 at 10:49 PM, R. David Murray  wrote:
> So: there is completion support for hg update for both bash and zsh.
> Not sure about other shells.

Thanks for clarifying that, I've long been hazy on the details of how
completion works across various utilities (it also clears up why the
bug with tab completion for a locally built Python landed in
bash-completion's lap).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Paul Moore]

On 22 March 2011 20:44, Dirkjan Ochtman  wrote:
> The right solution here is to use different clones for different
> projects/areas.

I'm not trolling here, just trying to learn something about Mercurial.
Would having separate clones for the various releases (2.7, 3.1, 3.2,
...) rather than named branches, reduce contention? I imagine it would
make porting patches between versions harder, on the other hand...?

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Dirkjan Ochtman]

On Tue, Mar 22, 2011 at 21:56, Paul Moore  wrote:
> On 22 March 2011 20:44, Dirkjan Ochtman  wrote:
>> The right solution here is to use different clones for different
>> projects/areas.
>
> I'm not trolling here, just trying to learn something about Mercurial.
> Would having separate clones for the various releases (2.7, 3.1, 3.2,
> ...) rather than named branches, reduce contention? I imagine it would
> make porting patches between versions harder, on the other hand...?

Probably not really. In particular, since many changes are
forward-ported across branches, you'll still need to push to each of
the release branches... I'm not sure what the ratio for pure-feature
vs. bugfix is; if there is a significant number of pure-feature
patches (i.e. not on any of the release branches), it might help to
separate all of the release branches from the default branch.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[Steven D'Aprano]

anatoly techtonik wrote:

I didn't touch Python3 until PyCon, and my first user experience is
not really good. I've got a feeling that Python3 became more ugly,
because it doesn't allow me to think about the logic anymore, and
requires more low-level workarounds even for basic user input/output.


Do you have any examples other than print?

The main one that comes to my mind is that other than looping, any time 
I want to process dict.items() etc I often need to call list() first. 
Fortunately looping is about 90% of my use-cases for the dict methods, 
but the other 10% nearly always requires a list().



YMMV.



--
Steven

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Nick Coghlan]

On Wed, Mar 23, 2011 at 3:38 AM, Jesus Cea  wrote:
> Now we have two options.
>
> The easier and "mercurial" way would be:
>
> 6. Pull.
> 7. Merge the two heads.
> 8. Merge that merge to the other branches, as necessary. Since the two
> heads were already merged to other branches, this merge should be trivial.
> 9. Push.
>
> If we have some other pushes in the meantime, repeat again from 6. You
> will eventually win the race :).

There's a third option (which is what I've been doing):

6. Pull
7. Merge the heads on the oldest branch that now has multiple heads
8. Merge that branch to the next branch in line as usual.
9. Repeat 7-8 until all branches, up to and including default have been merged
10. Push.

Repeat from 6 if there was another push race.

It keeps the same merge flow as a normal patch (e.g.
3.1->3.2->default) without messing with local history.

As far as the rest of the post goes, in principle I agree with the
goal of letting us run branches from sandbox repositories on the
buildbots, but am happy to leave the details to others to work out. If
the buildbots are currently working the way they did with SVN (clean
checkout every time) they may currently be doing a clean clone of the
repository for every build anyway.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Nick Coghlan]

On Wed, Mar 23, 2011 at 6:44 AM, Dirkjan Ochtman  wrote:
> This is something that Mozilla has been doing, for example, their JS
> interpreter is now developed in a separate clone. It might also be a
> good match for sprints, where one room could have its own repo and the
> other room has a different repo. Or all the packaging sprinters push
> to their cpython-packaging repo.

Yeah, that last is essentially what Tarek did for the Pycon sprints (I
think he even had multiple levels of it - I believe Arc was running a
staging clone as well).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] "Meet the Team" on Python Insider

[Doug Hellmann]

We would like to run a series of interviews with the Python developers to get 
the new blog going. There is a short list of questions below this message. If 
you would like to be included in the series, please reply directly to me with 
your answers.

We will be doing one or two posts per day, depending on the number of responses 
and availability of other information to post. We'll have to wait until we have 
several responses before we start, so we don't announce a new series and then 
post two messages before it peters out. Please help us by sending your answers 
as quickly as you can so we can tell what we'll be dealing with.

Posts will be published in roughly the order the responses are received, with 
the text exactly as you send it (unedited, except for formatting it as HTML). 
If the questions don't apply to you, you can't remember the answer, or don't 
have an answer, then you can either leave that question blank or interpret it 
more broadly and give some related information. Blank questions will be omitted 
from the posts.

Thanks,
Doug



Personal information:

name
location (city, country, whatever you want to give--we don't need your mailing 
address)
home page or blog url

Questions:

1. How long have you been using Python?

2. How long have you been a core committer?

3. How did you get started as a core developer? Do you remember your first 
commit?

4. Which parts of Python are you working on now?

5. What do you do with Python when you aren't doing core development work? (day 
job, other projects, etc.)

6. What do you do when you aren't programming?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Nick Coghlan]

On Wed, Mar 23, 2011 at 6:59 AM, Dirkjan Ochtman  wrote:
> Probably not really. In particular, since many changes are
> forward-ported across branches, you'll still need to push to each of
> the release branches... I'm not sure what the ratio for pure-feature
> vs. bugfix is; if there is a significant number of pure-feature
> patches (i.e. not on any of the release branches), it might help to
> separate all of the release branches from the default branch.

Not really - when you're working on a default-only change, push races
are pretty easy to deal with (merge, test, commit, push, no fiddling
about with different branches).

It's only when you've changed multiple branches *and* hg pull changes
multiple branches that correctly sorting out all the heads on each
branch gets a bit tedious.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

[Barry Warsaw]

On Mar 18, 2011, at 08:50 PM, Guido van Rossum wrote:

>I do distinctly recall __version__ being standardized for other
>purposes too, but I have no idea how to find that reference... It
>probably was well before 2000.

FWIW, I went spelunking in my email archives and the earliest reference to
__version__ I found was in a file called subproc.py posted to comp.lang.python
by Ken Manheimer.  It contained a CVS expanded $Revision$ keyword.

The message is dated January 12, 1995.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Nick Coghlan]

On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw  wrote:
> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
> case where you get tripped up on the merge dance floor.  When that happens,
> you could run your localized tests, and then a set of tests that run in just a
> minute or two.

What would such a smoke test cover, though? It's hard to think of
anything particularly useful in the middle ground between "Can you run
regrtest *at all*?" and "make quicktest".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Nick Coghlan]

On Wed, Mar 23, 2011 at 12:22 AM, Barry Warsaw  wrote:
> I think that's different than what John was describing, or perhaps Python's
> use of it has the effect of being different.  IIUC, in Mercurial, within the
> default branch there's no clear "main line" of development assigned to a path
> within the DAG.  All paths are created equal, so it's not possible to
> e.g. have log or bisect suppress one path containing feature sub-commits from
> the point of departure to the point of recombination (merge).

I was playing actually with the "-b" (branch) option on hg log and
found its behaviour to be a little strange when used on a specific
file.

I'd made a mistake in my sandbox and, as part of a merge from default,
accidentally reverted all the changes on a feature branch.

However, when doing "hg log -b . Objects/abstract.c" the last change
it showed for the file was the last feature addition in the branch,
*NOT* the merge from default where I had accidentally clobbered those
changes.

By looking at changes made on the default branch *as well*, I was able
to identify the offending changeset, do a hg rollback and then commit
that on the feature branch so everything was back the way it should
be. However, I was very, very surprised that hg log on a specific file
within a branch didn't flag the merge revisions that had brought in
changes that affected that file.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

[Guido van Rossum]

All trails eventually lead to Ken! :-)

On Tue, Mar 22, 2011 at 2:30 PM, Barry Warsaw  wrote:
> On Mar 18, 2011, at 08:50 PM, Guido van Rossum wrote:
>
>>I do distinctly recall __version__ being standardized for other
>>purposes too, but I have no idea how to find that reference... It
>>probably was well before 2000.
>
> FWIW, I went spelunking in my email archives and the earliest reference to
> __version__ I found was in a file called subproc.py posted to comp.lang.python
> by Ken Manheimer.  It contained a CVS expanded $Revision$ keyword.
>
> The message is dated January 12, 1995.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Nick Coghlan]

On Wed, Mar 23, 2011 at 12:28 AM, Barry Warsaw  wrote:
>>Ah. We don't support this kind of development - no new named branches
>>are allowed in the central repository.
>
> It does sound like that restriction is a source of friction for us.

I'd like to hold off on abandoning it, though. All the issues we
currently have with applying patches wouldn't magically go away if
those changes were simple merges from named branches instead. You also
create a risk of mistakes like branching from default for a bug fix,
then merging your bug fix branch into 3.1.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

[Oleg Broytman]

On Tue, Mar 22, 2011 at 05:30:09PM -0400, Barry Warsaw wrote:
> a file called subproc.py posted to comp.lang.python
> by Ken Manheimer.

   Can you believe - I still use the module?! (-:

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Éric Araujo]

>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal.  The tools are different.
> I'm curious: what are the benefits of the Mercurial model?

Simplicity.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Nick Coghlan]

On Tue, Mar 22, 2011 at 10:53 PM, Éric Araujo  wrote:
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff.  Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.

Since I run my sandbox that way, I asked Martin about that at Pycon -
it's on his todo list for the integration.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[skip]

Sjoerd> Perhaps looking at the glog output will shed some light.  If you
Sjoerd> don't have it yet, enable the graphlog extension, after which
Sjoerd> you can use hg glog to look at your clone.  Look in particular
Sjoerd> at the changeset which is marked with an @ sign instead of an o.
Sjoerd> That (or those if you're in the middle of a merge) is the
Sjoerd> "parent" of your working set.

...
| | | | | | @  changeset:   68309:c3caaf979b9e
| | | | | |/   branch:  2.5
| | | | | |parent:  68263:7790ad8332ba
| | | | | |user:Skip Montanaro 
| | | | | |date:Sun Mar 06 21:31:25 2011 -0600
| | | | | |summary: manually expand the defunct HeadURL subversion 
keyword
...

I see no other "parent"s.  I have to admit I don't know how to read this
output or what I should look for in the way of conflicts.  Also, it produced
20+MB of output, so I can't just paste it into this message and ask anyone
to read the tea leaves.

Oh, wait a minute.  It looks like Martin relented on his desire not to
modify the 2.5 Mercurial repo:

| | | | o  changeset:   68802:f9763c363cc3
| | | | |  branch:  2.5
| | | | |  parent:  68696:cc959f114739
| | | | |  user:Martin v. Lšwis 
| | | | |  date:Mon Mar 21 10:30:07 2011 +0100
| | | | |  summary: Set subversion version identification to empty 
strings if this is not a subversion

I think that would make my local change unnecessary.  So, my next project is
to try and figure out how to undo my change.  This seemed to work:

hg revert -r 68263 Python/sysmodule.c

Was that the right thing to do?

S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Terry Reedy]

On 3/22/2011 1:38 PM, Jesus Cea wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.

All branches (except 2.7) MUST be merged to default, all the time. This
must be enforced by the push hook.


Seems like a good idea. If a fix is in 3.2 and *not* in default, then we 
have a regression in default. This will be easier and less work when 3.1 
is out and we only have two sequential versions.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Éric Araujo]

> I think that would make my local change unnecessary.  So, my next project is
> to try and figure out how to undo my change.  This seemed to work:
> 
> hg revert -r 68263 Python/sysmodule.c
> 
> Was that the right thing to do?

Use hg backout, not revert.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

[Barry Warsaw]

On Mar 22, 2011, at 02:38 PM, Guido van Rossum wrote:

>All trails eventually lead to Ken! :-)

Indeed!

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Barry Warsaw]

On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:

>On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw  wrote:
>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>> case where you get tripped up on the merge dance floor.  When that happens,
>> you could run your localized tests, and then a set of tests that run in just 
>> a
>> minute or two.
>
>What would such a smoke test cover, though? It's hard to think of
>anything particularly useful in the middle ground between "Can you run
>regrtest *at all*?" and "make quicktest".

make quicktest runs 340 tests, and I'm certain many don't need to be run in a
smoke test.  E.g. 

test_aifc
test_colorsys
test_concurrent_futures
(that's as far as it's gotten so far ;)

Or you could time each individual test, choose a cut off for total test run
and then run whatever you can within that time (on some reference machine).
Or maybe just remove the longest running 50% of the quick tests.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Nick Coghlan]

On Wed, Mar 23, 2011 at 1:37 AM,   wrote:
> Doesn't that just complicate my setup?  Let's just consider the cpython repo
> (is that the right term? maybe branch instead?).  Today, I have a local
> repository named "cpython" which refers to ssh://h...@hg.python.org/cpython as
> its default.  Now you suggest I need to create another public repository.
> So my "chain of command" becomes: local depends on my global, which depends
> on the real cpython global.  Now replicate that for the different active
> branches (2.7, 3.2 at least).

Yes and no.

Historically, you had your local working copy of the SVN repository,
probably a few other working copies for the different maintenance
branches, and then a whole pile of patches for works in progress. If
you had a long running branch you wanted to work on, you probably had
a separate working copy for that as well. A lot of the patches were
probably made publicly available to others by posting them on a
tracker item.

Now, consider my own current hg setup (which I'm reasonably happy with so far):

I have 4 "clean" local repositories which correspond to the active
hg.python.org/cpython branches: py3k=default, python32=3.2,
python31=3.1 and python27=2.7
Of those 4, only py3k actually points at the server by default - the
others either point to py3k (python32, python27) or to python32
(python31).
I have a simple shell script that steps through all 4 branches doing a
"hg pull -u"

This part really isn't all that different from what I had with SVN,
except that it is all a *lot* faster, since everything happens locally
aside from the push/pull steps between my py3k repo and
hg.python.org/cpython.

The big difference is that I now only work in these repositories if I
am getting ready to commit something. Otherwise, I work in a separate
local repository: sandbox.

My public sandbox is a server-side clone of cpython that lives at
hg.python.org/sandbox/ncoghlan
I create feature branches there to work on things that I am developing
myself (when applying patches created by others I'll work in the main
repos)
The default, 3.2, 3.1, etc branches are exact mirrors of the
corresponding branches in cpython
I have an alias set up in .hgrc so that "hg pull cpython" will bring
my sandbox repo up to speed with the latest changes to the main
repository
By pushing changes to my public sandbox, they're not only available
for others to see, but also allow me to easily keep my desktop and
laptop in sync
A simple "hg diff -r default" (or "-r 3.2" etc) from one of my named
branches gives me a patch file I can then import into the main
repositories, ready to commit

I have no need to maintain multiple sandbox repositories, since I just
switch between branches and rebuild as necessary.

Once the named branch support in the roundup integration is working,
I'll never need to manually publish a patch to the tracker again -
I'll just point roundup at the appropriate named branch in my sandbox
and hit the "create patch" button.

And the most interesting part of all this? Someone without push rights
can use the *exact same workflow*, with the only difference being that
their sandbox would be somewhere like bitbucket or Google code, rather
than on hg.python.org.

Instead of dead patches living on the tracker, we instead have
significantly easier to update live branches living in cloned
repositories.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Glenn Linderman]

On 3/22/2011 2:43 PM, Éric Araujo wrote:

Bazaar apparently has a notion of mainline whereas Mercurial believes
that all changesets are created equal.  The tools are different.

I'm curious: what are the benefits of the Mercurial model?

Simplicity.


That's an amusing response, after reading hundreds of emails on this 
list about 5-12 step sequences of commands required to perform one 
operation.  So I must ask: where is the simplicity manifested?


I've been waiting for the hg conversion to start attempting to 
contribute to Python in any significant way, because I didn't know SVN, 
and didn't know hg, and didn't figure I had time to learn both. I 
haven't read the new devguide yet, but from the activity on the list, it 
would seem that either no one else has either, or that it doesn't answer 
the important questions about the hg aspects of the development 
process.  On the other hand, perhaps 5-12 step sequences of commands are 
short in comparison to the steps required for other (non-hg) DVCS tools?


I don't recall 5-12 step sequences in the DVCS PEP when I read it once, 
for any of the tools, but things progressed from the time I read it, so 
maybe they would all have longer sequences.


Back when I used non-distributed VCS systems like SCCS, RCS, PVCS, CVS, 
and Clearcase, I don't recall any operations that took more than 2 or 3 
commands to achieve (merges, of course, were onerous in some of those, 
and locking sometimes stalled progress in some ways in some of those).


Now I'm wondering when the hg issues will be settled enough to attempt 
to read the devguide, and attempt to submit code to the http.server to 
try to fix the many bugs and limitations it has, many of which I've 
worked around or fixed in a private copy of server.py.  No one else 
seemed to be interested enough in those bugs when I reported them to fix 
them prior to the release 3.2, so it seems to me that code is basically 
unmaintained.  The present state of the code is sort of like a dead 
battery... it might function a little but has such severe limits that it 
is not particularly useful... and it is an itch I might be able to scratch.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Sjoerd Mullender]

On 2011-03-22 22:53, s...@pobox.com wrote:
> 
> Sjoerd> Perhaps looking at the glog output will shed some light.  If you
> Sjoerd> don't have it yet, enable the graphlog extension, after which
> Sjoerd> you can use hg glog to look at your clone.  Look in particular
> Sjoerd> at the changeset which is marked with an @ sign instead of an o.
> Sjoerd> That (or those if you're in the middle of a merge) is the
> Sjoerd> "parent" of your working set.
> 
> ...
> | | | | | | @  changeset:   68309:c3caaf979b9e
> | | | | | |/   branch:  2.5
> | | | | | |parent:  68263:7790ad8332ba
> | | | | | |user:Skip Montanaro 
> | | | | | |date:Sun Mar 06 21:31:25 2011 -0600
> | | | | | |summary: manually expand the defunct HeadURL 
> subversion keyword
> ...

Here you see one of your heads.  The lines show the dependencies among
the changesets, and your change has no children (line going up), i.e.
it's a head.

> I see no other "parent"s.  I have to admit I don't know how to read this
> output or what I should look for in the way of conflicts.  Also, it produced
> 20+MB of output, so I can't just paste it into this message and ask anyone
> to read the tea leaves.
> 
> Oh, wait a minute.  It looks like Martin relented on his desire not to
> modify the 2.5 Mercurial repo:
> 
> | | | | o  changeset:   68802:f9763c363cc3
> | | | | |  branch:  2.5
> | | | | |  parent:  68696:cc959f114739
> | | | | |  user:Martin v. Lšwis 
> | | | | |  date:Mon Mar 21 10:30:07 2011 +0100
> | | | | |  summary: Set subversion version identification to empty 
> strings if this is not a subversion

Here I was mistaken, it's not a head since there is a line going up from
this changeset (you didn't show it, but it's there).  But the child of
this changeset is in a different branch (2.6).  So as far as the 2.5
branch is concerned, it's a head.

> 
> I think that would make my local change unnecessary.  So, my next project is
> to try and figure out how to undo my change.  This seemed to work:
> 
> hg revert -r 68263 Python/sysmodule.c
> 
> Was that the right thing to do?

No.  Revert just reverts local (non-committed) changes.

Either you don't need your change anymore and you can strip it (if your
changeset never left this particular clone) (you need the rebase
extension for that), or you can tell Hg that you want to abandon your
head (I'm not actually sure this can be done, and if it can, how), or
you can merge the two changesets: hg update -C 68309; hg merge 68802; hg
commit.  And finally, you can rebase: hg rebase -s 68309 -d 68802.  The
rebase will graft your changeset on top of Martin's.

> 
> S


-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[Greg Ewing]

Steven D'Aprano wrote:

The main one that comes to my mind is that other than looping, any time 
I want to process dict.items() etc I often need to call list() first.


I don't think that's such a bad thing. It makes it clear that
you're performing a more expensive operation than just looking
at the keys.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Senthil Kumaran]

On Tue, Mar 22, 2011 at 03:42:27PM -0700, Glenn Linderman wrote:
> and didn't figure I had time to learn both. I haven't read the new devguide
> yet, but from the activity on the list, it would seem that either no one else

I think, it is a good idea to read that. You might find that many
discussions are stemming from assumptions rather than following the
instructions.

> the devguide, and attempt to submit code to the http.server to try to fix the
> many bugs and limitations it has, many of which I've worked around or fixed in
> a private copy of server.py.  No one else seemed to be interested enough in
> those bugs when I reported them to fix them prior to the release 3.2, so it

I remember your issues, many of them are I would say 'tricky' ones
which would need some time to review/fix. Let's see it to get it in
3.3 release.

> seems to me that code is basically unmaintained.  The present state of the 
> code
> is sort of like a dead battery... it might function a little but has such
> severe limits that it is not particularly useful... and it is an itch I might
> be able to scratch.

If you wish, please maintain a mecurial repository and point the full
code in the bug-reports, it may be easy to pull a patch and patch the
current line of code. 

-- 
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue 10787: Document the probability density function for random.gammavariate.

[Daniel Stutzbach]

Raymond,

The Doc/reference/datamodel.rst change appears unrelated and wasn't in the
3.x version of this commit.  Was the change intentional?

On Tue, Mar 22, 2011 at 3:52 PM, raymond.hettinger <
python-check...@python.org> wrote:

> http://hg.python.org/cpython/rev/42816be02b9b
> changeset:   68845:42816be02b9b
> branch:  2.7
> parent:  68841:50cc60852a76
> user:Raymond Hettinger 
> date:Tue Mar 22 15:52:46 2011 -0700
> summary:
>  Issue 10787: Document the probability density function for
> random.gammavariate.
>
> files:
>  Doc/reference/datamodel.rst
>  Lib/random.py
>
> diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
> --- a/Doc/reference/datamodel.rst
> +++ b/Doc/reference/datamodel.rst
> @@ -1540,10 +1540,10 @@
>
>  The following methods only apply when an instance of the class containing
> the
>  method (a so-called *descriptor* class) appears in the class dictionary of
> -another new-style class, known as the *owner* class. In the examples
> below, "the
> -attribute" refers to the attribute whose name is the key of the property
> in the
> -owner class' ``__dict__``.  Descriptors can only be implemented as
> new-style
> -classes themselves.
> +another new-style class (known as the *owner* class) or one of its
> +descendants.  In the examples below, "the attribute" refers to the
> attribute
> +whose name is the key of the property in the owner class' ``__dict__``.
> +Descriptors can only be implemented as new-style classes themselves.
>
>
>  .. method:: object.__get__(self, instance, owner)
> diff --git a/Lib/random.py b/Lib/random.py
> --- a/Lib/random.py
> +++ b/Lib/random.py
> @@ -490,6 +490,12 @@
>
> Conditions on the parameters are alpha > 0 and beta > 0.
>
> +The probability distribution function is:
> +
> +x ** (alpha - 1) * math.exp(-x / beta)
> +  pdf(x) =  --
> +  math.gamma(alpha) * beta ** alpha
> +
> """
>
> # alpha > 0, beta > 0, mean is alpha*beta, variance is
> alpha*beta**2
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>


-- 
Daniel Stutzbach
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Éric Araujo]

Hi,

>> I have to admit I don't know how to read this output or what I should look
>> for in the way of conflicts.
Are these resources helpful?  (You don’t have to read them all, but if
the first doesn’t work, try the following one.)

About log:
http://mercurial.selenic.com/wiki/TutorialHistory
http://mercurial.selenic.com/wiki/GraphlogExtension
http://mercurial.aragost.com/kick-start/en/basic/#inspecting-history

About merges, heads and parents:
http://hginit.com/04.html
http://mercurial.selenic.com/wiki/Merge
http://mercurial.selenic.com/wiki/UnderstandingMercurial#Revisions.2C_changesets.2C_heads.2C_and_tip
http://mercurial.selenic.com/wiki/MultipleHeads

To help us troubleshoot your issue, can you confirm this: you were in a
clone with the 2.5 branch checked out (“hg id” will tell that), you
pulled from 2.6, and the update action (from “pull -u”) failed.


>> [...] I think that would make my local change unnecessary.
Correct.

>> So, my next project is to try and figure out how to undo my change.
http://mercurial.selenic.com/wiki/PruningDeadBranches#Using_clone
If you follow that method, don’t forget to copy your .hg/hgrc to the new
clone.

>> This seemed to work:
“Seemed” is the right word :(  More on
http://mercurial.selenic.com/wiki/Revert or “hg help revert”.


> No.  Revert just reverts local (non-committed) changes.
This is untrue; Skip used a -r argument.  See above.
One thing to understand is that revert changes file contents only,
whereas update moved you on the revision graph.

> [snip]
Advanced commands like strip (bundled with mq BTW, not rebase) should
*not* be recommended lightly to people who are still learning the normal
use of Mercurial, IMO.  Throwing mentions of rebase, strip, transplant
can be harmful.  Let’s focus on clone, pull, update and merge first.
(That’s why the devguide tries to select one or two workflows; we know
that Mercurial is hella flexible, but choice is not a good thing when
you’re learning.)

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Éric Araujo]

> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
> branch name is reserved, and it implies that the head with the highest
> revision number from that branch will be checked out on 'hg clone'.

This does not fully maps to Bazaar’s concept of mainline, though.

An aside for Bazaar users: Kindly stop referring to Mercurial
repositories as branches, it’s confusing.  Thank you.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[Éric Araujo]

>>> I'm curious: what are the benefits of the Mercurial model?
>> Simplicity.
> 
> That's an amusing response, after reading hundreds of emails on this 
> list
I think the great number of messages is caused by incomplete learning,
confusion caused by familiarity with other tools, FUD and anxiety.

Just in case my position is not clear: I have a lot of sympathy for
people who struggle with the new tool and workflow and do try to help.

> about 5-12 step sequences of commands required to perform one operation.
Committing, merging and sharing are not one operation.

> So I must ask: where is the simplicity manifested?
I used simplicity in its strict (or scientific, if this speaks to you)
meaning: not complex, not many-sided.  Having one thing (a notion of an
unnamed branch) instead of two things (a notion of trunk and a notion of
side branch) is by definition simpler.

I often describe Mercurial’s simplicity (or chosen stupidity) as the
reason for its robustness and consistency.  (For example, the frowning
upon history rewriting, or the absence of octopus merging.)

That said, I cannot learn Mercurial for you, not force you to read the
devguide.  I would advise you to learn Mercurial with one of the many
available resources (http://hginit.com/,
http://mercurial.aragost.com/kick-start/), proceed to the devguide,
clone https://bitbucket.org/mirror/cpython and start fixing things in
http.server (and thanks in advance for that work!).

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Terry Reedy]

On 3/22/2011 8:53 AM, Éric Araujo wrote:

I still don't understand what that's supposed to look like.  Is it supposed
to be a URL which refers to my local repository?

No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting service).

You have to use one public repo per bug, as roundup will only use the
default branch to compute the diff.  Maybe adding support for named
branches so that you can have one repo used for many bug reports would
be useful.


Sorry, I don't see a "Create Patch" button anywhere.

On the right of the field containing the repo URI on
http://bugs.python.org/issue11591


Pressing that button seems to create a duplicate patch, which is not 
good. Given that there is no connection between the repository names 
(which seem to be duplicated) and the resulting file name, there is no 
way to tell whether to press the button or what the result will be.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

[Mark Hammond]

On 23/03/2011 6:12 AM, Michael Foord wrote:

On 22/03/2011 07:21, Mark Hammond wrote:

Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.python.org/issue11629.



Hey Mark,

One way of supporting alternative implementations (that may not even
have a standard install directory) is allowing configuration. e.g.
config.ini

[paths]
ironpython = c:\Program Files\IronPython 2.7\ipy.exe
ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
jython = c:\Users\foobar\jython2.5\jython.exe


Hi Michael,

I'd have no problem with that in general, but how would you feel about 
letting the PEP stand as it is without this additional requirement and 
then treat this as an additional feature to be thrashed out separately? 
 I intentionally worded the PEP to specifically allow these kinds of 
features to be added outside the PEP process.


For example, I guess the name of the INI file wouldn't be config.ini, 
and I guess there might need to be a strategy to allow it to exist in 
multiple places for when users want this feature but don't have write 
access to the location of py.exe.  Then people might want it to be in 
the cwd, or in any parent of the cwd, etc... Further, it might also be 
possible to support this with simple environment variables which might 
wind up being just as (or more) reasonable (the concept of per-user 
environment variables already exist and a UI already exists for editing 
them, and it would allow different cmd-prompts to have different "rules" 
with minimal complexity) - not that I am necessarily advocating this - 
I'd just prefer the PEP to not get bogged down with those kinds of issues.


Cheers,

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

> Pressing that button seems to create a duplicate patch, which is not
> good. Given that there is no connection between the repository names
> (which seem to be duplicated) and the resulting file name, there is no
> way to tell whether to press the button or what the result will be.

Don't worry about this. It will *not* normally generate the same file
twice, but notice that it already created it. It's just because the
same repository was added twice that you can get the same patch out of
it twice also.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Workflow proposal

[Stephen J. Turnbull]

Executive summary:

If we're really serious about serializing the public branches, mq
seems to be the way to go.

Jesus Cea writes:

 > 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
 > "default". Leave the original commit in "3.1" alone.

I would suggest "hg strip --keep" which leaves the working copy
unchanged.  Now commit those changes (locally).  This will result in a
spurious commit by Antoine's standards, but should dramatically
decrease the burden on the contributor.  Daredevils can strip
this one too before committing the merge.

Really it would be preferable to do all this with mq, though. It seems
to me that this is precisely what qrefresh does.  The main issue I can
see is that I don't know an mq command to pop off a "real" commit and
turn it back into an mq patch.  I guess "hg strip --keep; hg qnew
" should do it though.

 > 3. Push my clone to a SANDBOX in hg.python.org ("hg push sandbox"). This
 > sandbox is synchronized with the official HG repository.

This sounds messy and fragile to me.  Better to implement a true
changeset queue manager, IMHO.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Antoine Pitrou]

On Wed, 23 Mar 2011 10:39:01 +0900
"Stephen J. Turnbull"  wrote:
> Executive summary:
> 
> If we're really serious about serializing the public branches, mq
> seems to be the way to go.

I really think that at this point we should continue practicing with
the current setup before deciding on refinements or changes.

>  > 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
>  > "default". Leave the original commit in "3.1" alone.
> 
> I would suggest "hg strip --keep" which leaves the working copy
> unchanged.

Now, "hg strip" should definitely be absent of any recommended or even
suggested workflow. It's a power user tool for the experimented
developer/admin. Not the average hg command.

By the way, whether or not mq gets used is pretty much anyone's private
decision (unless we decide that patches must get split into logical
units and mailbombed for review ala mercurial-devel, which would be a
significant departure from our development habits).

Regards

Antoine.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Stephen J. Turnbull]

s...@pobox.com writes:
 > 
 > Stephen> This won't be pleasant if people are sprinting and lots of
 > Stephen> commits are coming, because you're likely to repeatedly lose
 > Stephen> the push race.  But in those conditions, nothing is guaranteed
 > Stephen> to work in decentralized fashion (that's one reason why the
 > Stephen> Linux kernel uses Linus and lieutenants as a serialization
 > Stephen> mechanism).
 > 
 > So DVCS scales up to a point, then it breaks and you need to revert to some
 > sort of serialization scheme?

No, software engineering scales up to a point, then it breaks and you
need a serialization scheme.  The problem is not the DVCS, it's the
demand for a *centralized*, authoritative, safe, stable version.  DVCS
can scale at least to Linux kernel pace if you only ask for
centralized authoritative.  DVCS is "No Silver Bullet", it only
helps with some accidental costs of development.  It doesn't help with
the costs of review and testing.

There are in fact problems with the current generation of DVCSes.
Lack of plists on commits, for example.  You'd like to have a "tested"
property, in fact two of them (one for the committer, one for the
buildbots).  You'd like to have a "checkpoint" property, which commits
would by default be ignored by "log" and "bisect".  You'd like to have
an "issues" property, a list of issues applicable to this commit.  But
again, these would only reduce accidental costs.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Terry Reedy]

On 3/22/2011 9:51 PM, "Martin v. Löwis" wrote:

Pressing that button seems to create a duplicate patch, which is not
good. Given that there is no connection between the repository names
(which seem to be duplicated) and the resulting file name, there is no
way to tell whether to press the button or what the result will be.


Don't worry about this. It will *not* normally generate the same file
twice, but notice that it already created it. It's just because the
same repository was added twice that you can get the same patch out of
it twice also.


Could duplicate repositories be prevented?


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

Am 23.03.2011 03:47, schrieb Terry Reedy:
> On 3/22/2011 9:51 PM, "Martin v. Löwis" wrote:
>>> Pressing that button seems to create a duplicate patch, which is not
>>> good. Given that there is no connection between the repository names
>>> (which seem to be duplicated) and the resulting file name, there is no
>>> way to tell whether to press the button or what the result will be.
>>
>> Don't worry about this. It will *not* normally generate the same file
>> twice, but notice that it already created it. It's just because the
>> same repository was added twice that you can get the same patch out of
>> it twice also.
> 
> Could duplicate repositories be prevented?

Yes, that would be possible.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

[skip]

Daniel> On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull 
wrote:
>> ... because I commit with *every* save ...  Effectively, I use git as
>> an extension to XEmacs's undo/redo mechanism.

Daniel> I, too, commit using git with every save (which I do early and
Daniel> often).  It's saved my butt more than once

Interesting concept.  So, I take it your commit messages are generally
empty?  Care to share the hook function?  (I trust it understands when you
save files not under version control.)

Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > Now, "hg strip" should definitely be absent of any recommended or even
 > suggested workflow. It's a power user tool for the experimented
 > developer/admin. Not the average hg command.

So what you're saying is that Mercurial by itself can't support the
recommended workflow, because any "collapsing" of commits requires
stripping, whether done by hg strip or implicitly by some other
"non-average" hg command.

 > By the way, whether or not mq gets used is pretty much anyone's private
 > decision (unless we decide that patches must get split into logical
 > units and mailbombed for review ala mercurial-devel, which would be a
 > significant departure from our development habits).

I don't see the connection; mq supplies "qfinish" for the purpose of
turning a patch into a commit.  All I'm suggesting is that "qrefresh"
is a nicer way to handle both the collapsing process and the strip/
re-merge/recommit process, although there is the problem of reverting
the commit back to an mq patch, which AFAIK requires a "strip --keep"
followed by "qnew".

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[skip]

Senthil> You will have to 'push' your changes to those so that they are
Senthil> publicly visible and then point that url in the bug-tracker.
>> 
>> I can see this turning into a giant bowl of spaghetti.  How in the
>> world are people supposed to understand how all these repositories
>> are related to each other?

Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
Martin> whole point of "Distributed" version control systems.

No, you don't understand.  Just the repositories I will have to deal with
will turn into a big bowl of spaghetti.  I could care less about everything
else.

>> The Roundup interface is getting extraordinarily messy.

Martin> So what is your constructive proposal?

I don't know how constructive you will find it without a patch, but here is
a short brain dump.

In general, the display should be weighted more heavily with content most
relevant to the current stage of the issue.  Elide or condense the other
stuff.  I know nothing about modern day website development, but I imagine
someone who does could work some JavaScript magic without a lot of trouble.
For example:

* As soon as a case is "active" (left as an exercise for the reader to
  determine) most of the content I find useful occurs below the fold
  (attached files, review links, recent messages).

* As soon as a case is opened, maybe after initial triage (do we need a
  new stage, "triage complete"?) by a core developer, it seems unlikely
  that most of the elements of the classification section will change.
  That can probably be a collapsed, and available to expose with a
  little expander button for interested parties.

* I suspect parts of the process section can get a similar treatment
  (status, dependencies, etc).  Adding to the nosy list or subtracting
  from it (need a new [-] button) should always be visible).  I don't
  find the limited width text field all that useful.

* Maybe the Files section should migrate to the top of the page once it
  starts accumulating contents (or maybe when the stage is "patch
  review").  Again, collapse the display so only the most recent patches
  are visible seems reasonable to me.

* I don't know if it's possible to do easily, but when uploading a new
  version of a patch the user could be prompted to select other patches
  (or maybe they could be selected based on having the same name?)
  which the new patch makes obsolete so they can be elided from the
  default display.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Éric Araujo]

> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.

Pretty average: http://mercurial.selenic.com/wiki/PruningDeadBranches

> I don't see the connection; mq supplies "qfinish" for the purpose of
> turning a patch into a commit.  All I'm suggesting is that "qrefresh"
> is a nicer way to handle both the collapsing process and the strip/
> re-merge/recommit process, although there is the problem of reverting
> the commit back to an mq patch, which AFAIK requires a "strip --keep"
> followed by "qnew".

I like mq as a power tool, but only for short-term work.  Most of the
time I don’t need it.  Refreshing is painful to me whereas merging is
straightforward.  Mercurial devs themselves advocate real branches
(named, pbranch or what-have-you) for long-term work.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[skip]

Dirkjan> The right solution here is to use different clones for
Dirkjan> different projects/areas. The proposed interpreter/stdlib
Dirkjan> split, for example, might reduce contention (although I imagine
Dirkjan> it would reduce it only by a little bit?). 

How about splitting the documentation and the code into separate
repositories (I believe that is the proper term, though perhaps "clone" is -
Dirkjan is the expert)?

Moving onto something related, but different, I find that people bandy about
terms which I just can't seem to find defined very well anywhere I've
looked.  The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary)
would seem to be the obvious place to look, but it doesn't define the terms
"branch" or "clone" (nor does it obviously differentiate a "named branch"
from any other kind of "branch").  I hesitate to overload those words with
the meanings I've acquired using Subversion and CVS, because they will
probably be wrong in subtle ways.  Also, "rebase" is not defined in the
glossary.

There are clearly lots of Mercurial-related documents on the web.  There is
no editorial  review of their quality other than Google page rank.  Is there a
prioritized list of stuff one should read?

Again, I reveal my ignorance with stunning alacrity.  My apologies to the
experts.

>From Joel Spolsky:

If you've been using Subversion, Mercurial is going to be confusing.

Got that right...

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[skip]

Nick> 7. Merge the heads on the oldest branch that now has multiple heads

Two more stupid questions:

1.  Don't all branches have multiple heads?  Every time I execute hg heads I
see many.

2.  Oldest in what way?  Pythonically (2.6 is older than 2.7 though it might
have more recent checkins) or revision-wise (rev 68001 is newer than
68000)?

If I had more time I'm sure I could ask more questions.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[skip]

>> hg revert -r 68263 Python/sysmodule.c
>> 
>> Was that the right thing to do?

merwok> Use hg backout, not revert.

They differ, how?

S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crosses branches?

[Éric Araujo]

> They differ, how?

Well, they’re not the same commands at all.  Revert changes the contents
of one or more files; backout renders a changeset moot by creating a new
changeset with the reverse diff.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Workflow proposal

[Nick Coghlan]

On Wed, Mar 23, 2011 at 1:43 PM,   wrote:
>
>    Nick> 7. Merge the heads on the oldest branch that now has multiple heads
>
> Two more stupid questions:
>
> 1.  Don't all branches have multiple heads?  Every time I execute hg heads I
>    see many.

The branches we mainly care about should generally only have 1 head in
the public repository (the tip for the default branch, the last merge
point to default for 3.2 and 2.7, the last merge point to 3.2 for
3.1).

> 2.  Oldest in what way?  Pythonically (2.6 is older than 2.7 though it might
>    have more recent checkins) or revision-wise (rev 68001 is newer than
>    68000)?

Oldest in terms of the bug fix merging workflow (i.e.
3.1->3.2->default, or 2.6->2.7 if you're actually updating more than
just 2.7 in the 2.x series)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com