Re: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook

On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. Löwis" wrote: > There is nothing that prevents people from tagging the tree currently > in subversion, but most of the time, only the release manager does any > tagging. > > If you think that it's a likely problem that people create named > branches by m

Re: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook

Am 27.02.2011 00:21, schrieb Éric Araujo: >> Then we will have to fix the hook each time we want to add a new >> legitimate branch. > The alternative is to edit the hook each time we want to remove a former > legitimate branch, plus have another hook to refuse new named branches. The question is w

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 20:30, schrieb Antoine Pitrou: > > Martin, I have now enabled the eol hook on the test repo (a quick test > seemed to show it works). Could you test again? It seems to work fine, thanks. I modified a file with Visual Studio, and that changed all line endings. I then decided to "fix"

Re: [Python-Dev] of branches and heads

> So, actually, hg promotes a slightly different terminology: > - a "head" is a changeset without a child in the topology So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin _

Re: [Python-Dev] Mercurial conversion repositories

>> changeset: 72694:e65daae6cf44 >> user:Antoine Pitrou >> date:Mon Feb 21 21:30:55 2011 + >> summary: Try s/UINT_MAX/INT_MAX/ > > It's not on an unnamed branch, it's on the "default" branch (which is > omitted for concision by "hg log" and other commands with a similar

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

> Actually, it isn't *required* on each developer's setup, since we > now have a hook that refuses bogus changegroups (if needed, we can even > refuse individual changesets). In most situations, even without the > eol extension line endings won't get modified anyway. I think this is overly optimi

[Python-Dev] hg commit with diff -u output (was Re: hg extensions was Mercurial conversion repositories)

FWIW, this modification to hgeditor does a reasonable approximation of 'bzr commit' including the diff -u output. Cheers, -Barry #!/bin/sh # # This is an example of using HGEDITOR to create of diff to review the # changes while commiting. # If you want to pass your favourite editor some other pa

Re: [Python-Dev] set iteration order

On Feb 26, 2011, at 4:09 PM, Antoine Pitrou wrote: > On Sat, 26 Feb 2011 10:09:33 +0100 > Hagen Fürstenau wrote: >> >> I just hunted down a change in behaviour between Python 3.1 and 3.2 to >> possibly changed iteration order of sets due to the optimization in >> issue #8685. Of course, this or

Re: [Python-Dev] Mercurial conversion repositories

On 2011-02-27 01:50, Barry Warsaw wrote: > On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: > >> You'd have to take this up with Mercurial's BDFL Matt. He is a strong >> advocate for teaching users to learn edit their .hg/hgrc files. > > Well, I guess it's doubtful I'd change his mind then.

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

Hi, On Sat, 26 Feb 2011 18:13:15 -0500 Dj Gilcrease wrote: > > File Format Management > eol > http://mercurial.selenic.com/wiki/EolExtension > required Actually, it isn't *required* on each developer's setup, since we now have a hook that refuses bogus changegroups (if need

Re: [Python-Dev] hg extensions

On Sun, 27 Feb 2011 01:25:12 +0100 Éric Araujo wrote: > > I've just tried bookmarks and I find them very cumbersome compared to > > named branches (which, unfortunately, can't remain local). I wonder > > what guided their design. > > Mimicking git branches. I've hardly ever used git but I would

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: >You'd have to take this up with Mercurial's BDFL Matt. He is a strong >advocate for teaching users to learn edit their .hg/hgrc files. Well, I guess it's doubtful I'd change his mind then. :) >Regarding Bazaar: FWIW, I periodically retried t

Re: [Python-Dev] hg extensions

> I've just tried bookmarks and I find them very cumbersome compared to > named branches (which, unfortunately, can't remain local). I wonder > what guided their design. Mimicking git branches. > (the core issue being that a bookmark blindly follows every commit you > do, while you would need it

Re: [Python-Dev] set iteration order

On Sat, 26 Feb 2011 10:09:33 +0100 Hagen Fürstenau wrote: > > I just hunted down a change in behaviour between Python 3.1 and 3.2 to > possibly changed iteration order of sets due to the optimization in > issue #8685. Of course, this order shouldn't be relied on in the first > place, but the side

Re: [Python-Dev] hg extensions (was: Mercurial conversion repositories)

> >> Branch Management > >>     bookmarks > >>         http://mercurial.selenic.com/wiki/BookmarksExtension > >>         Great for tracking bug fix work without needing to create a > >> separate working directory > > Never use them.  Clones are okay. > > Same here but not everyone likes to do that

Re: [Python-Dev] set iteration order

Hagen Fürstenau wrote: Code with any dependence on the iteration order of unordered collections (other than the guarantee that d.keys() and d.values() match at any given time as long as d is unchanged) is buggy. It's not a matter of dependence on iteration order, but of reproducibility (in my c

Re: [Python-Dev] set iteration order

> It's not a matter of dependence on iteration order, but of > reproducibility (in my case there were minor numerical differences due > to different iteration orders). Can you give a code example? I don’t understand your case. Regards ___ Python-Dev ma

Re: [Python-Dev] set iteration order

> Code with any dependence on the iteration order of unordered collections > (other than the guarantee that d.keys() and d.values() match at any > given time as long as d is unchanged) is buggy. It's not a matter of dependence on iteration order, but of reproducibility (in my case there were minor

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

On 2011-02-27 00:13, Dj Gilcrease wrote: > Branch Management > bookmarks > http://mercurial.selenic.com/wiki/BookmarksExtension Bookmarks will be in Mercurial core for Mercurial 1.8, which will be released in a few days (March 1st). So, with 1.8 it's no longer needed to enable this ext

Re: [Python-Dev] hg extensions (was: Mercurial conversion repositories)

On Sat, Feb 26, 2011 at 6:19 PM, Éric Araujo wrote: >>    transplant >>         http://mercurial.selenic.com/wiki/TransplantExtension >>         required to port patches between major versions > That’s actually not clear in the current PEP / devguide. http://potrou.net/hgdevguide/committing.html#

Re: [Python-Dev] hg extensions

> Never use them. Clones are okay. s/use/used/ ___ 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] hooks: Fix checkbranch hook

> Then we will have to fix the hook each time we want to add a new > legitimate branch. The alternative is to edit the hook each time we want to remove a former legitimate branch, plus have another hook to refuse new named branches. > I have no preference really. Looks like a ±0 to me :) Regards

Re: [Python-Dev] hg extensions (was: Mercurial conversion repositories)

Hi, > shelve > http://mercurial.selenic.com/wiki/ShelveExtension > Store un commited changes away so they dont affect generation > of the patch I never use it. >transplant > http://mercurial.selenic.com/wiki/TransplantExtension > required to port patches be

[Python-Dev] hg extensions was Mercurial conversion repositories

So reading the thread about the conversion and the dev guide at http://potrou.net/hgdevguide/ there seems to not be a list of recommended extensions that the python devs should have and use, only a few examples of their use. so I figured I would build up a list for other people to add to / comment

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon wrote: > There is hg-git, but that is hg on top of git. > Actually, hg-git is bidirectional. The hg-git documentation is written from the perspective of an hg client talking to a git server, but for a DVCS "client" and "server" are a matter of pers

Re: [Python-Dev] Mercurial conversion repositories

On 2011-02-26 22:06, Barry Warsaw wrote: > On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: > >> On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >>> $ cd py27 # now I want to synchronize >>> $ hg pull -u ssh://h...@hg.python.org/cpython >>> >>> but I'm not going to remember that url e

Re: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation?

2011/2/26 Greg Ewing : > From: Grigory Javadyan >> ... def f(): >> ...     a = 42 >> ...     def g(): >> ...             nonlocal a >> ...             del a >> ... >> SyntaxError: can not delete variable 'a' referenced in nested scope > > Is there a rational for this? It seems inconsistent -- if yo

Re: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation?

From: Grigory Javadyan > ... def f(): > ... a = 42 > ... def g(): > ... nonlocal a > ... del a > ... > SyntaxError: can not delete variable 'a' referenced in nested scope Is there a rational for this? It seems inconsistent -- if you can assign to names in outer scop

Re: [Python-Dev] of branches and heads

From: Antoine Pitrou > - a "branch" usually means a "named branch": a set of changesets > bearing the same label (e.g. "default"); that label is freely chosen > by the committer at any point, and enforces no topological > characteristic There are *some* topological restrictions, because hg w

Re: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook

On Sat, 26 Feb 2011 22:36:47 +0100 Éric Araujo wrote: > > +if branch in ('trunk', 'legacy-trunk', > > + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'): > > Wouldn’t using a whitelist instead of a blacklist protect against new > named branches too? Then we will have to fix

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon wrote: > Hg's is the mq (Mercurial Queue) extension. I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Line end problems do occur in real projects. A scintilla-cocoa project was branched off Scintilla to support the Cocoa GUI framework on OS X. Here is one of the revisions in that project: http://bazaar.launchpad.net/~mike-lischke/scintilla-cocoa/trunk/revision/5#include/ScintillaWidget.h If

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 13:30, Barry Warsaw wrote: > On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: > > >For other people's benefit, LoD == line of development (I think). > > Yes. It's just a word that isn't intimately tied to the implementation > details of a specific dVCS. > > >> I clone th

Re: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook

> +if branch in ('trunk', 'legacy-trunk', > + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'): Wouldn’t using a whitelist instead of a blacklist protect against new named branches too? ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation?

2011/2/26 Grigory Javadyan : def f(): > ...     a = 42 > ...     def g(): > ...             nonlocal a > ...             del a > ... > SyntaxError: can not delete variable 'a' referenced in nested scope > > Which looks weird, because the name is referenced in the _enclosed_ > scope, not the _e

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 10:20 PM, Antoine Pitrou wrote: >Often (but not always), when you're wanting to do something, there's an >extension for Mercurial which can be enabled ;) >http://mercurial.selenic.com/wiki/ShareExtension You sound like an iPhone commercial: "There's an app for that." :) -Bar

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: >For other people's benefit, LoD == line of development (I think). Yes. It's just a word that isn't intimately tied to the implementation details of a specific dVCS. >> I clone the remote repository using the command in the devguide, so I now >>

[Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation?

Hi, guys I'm not sure if python-dev is the right place to write to, but I'm really curious about this: >From the Python Language reference: > It is illegal to unbind a name referenced by an enclosing scope; the compiler > will report a SyntaxError. But when I run the following code: a = 3 def x

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw wrote: > > >I find bazaar's model confusing, and hg's intuitive, just like Éric. > >And consider that I learned bazaar before mercurial. To me, it makes > >perfect sense that in a DVCS the "unit" is a directory containing > >a repository and a wor

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: >On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >> $ cd py27 # now I want to synchronize >> $ hg pull -u ssh://h...@hg.python.org/cpython >> >> but I'm not going to remember that url every time. It wouldn't be so bad if >> Mercurial

Re: [Python-Dev] Mercurial conversion repositories

On 27 February 2011 01:40, Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: > >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I > >> could see people getting confused and asking why trunk was closed, > >> and/or not the same as "default". > > > > Pro

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: >You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. >I use it and love it. Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your edito

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

On 27 February 2011 05:23, "Martin v. Löwis" wrote: > It actually happened to me, so please trust me that it's not a legend. > Yes, I could fix it with hg commands, and a lot of text editing. > It took me a day, I considered the repository corrupted so that I > actually had to branch from the las

Re: [Python-Dev] [Python-checkins] cpython: improve license

On 27 February 2011 05:12, Barry Warsaw wrote: > I guess it's possible for change notifications to encompass multiple named > branches though, right? I'm not sure what to do about that, but it seems > like > a less common use case. > Are the change notifications per-commit? If so, there's no wa

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

On 27 February 2011 03:02, "Martin v. Löwis" wrote: > > Committing reopened it > > So what's the point of closing it, then? What effect does that > achieve? http://stackoverflow.com/questions/4099345/is-it-possible-to-reopen-a-closed-branch-in-mercurial/4101279#4101279 The closed flag is just

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: > > >Le 25/02/2011 20:43, Barry Warsaw a écrit : > >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > >> [snip] > >>> Note that each of these branch clones will initially have your local

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 13:46, Barry Warsaw wrote: > On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: > > >What you are asking for is available in TortoiseHg which absolutely > >rocks (if you are not allergic to the idea of a graphical tool). > > Like shellfish, bee-strings, and Perl I'm afrai

Re: [Python-Dev] r88589 - python/branches/py3k/Lib/test/test_logging.py

And if it gets disabled again it should be a skipped test instead of a commented-out test to better keep track that it's turned off. On Fri, Feb 25, 2011 at 14:24, Antoine Pitrou wrote: > On Fri, 25 Feb 2011 18:02:43 +0100 (CET) > vinay.sajip wrote: > > Author: vinay.sajip > > Date: Fri Feb 25

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Martin, I have now enabled the eol hook on the test repo (a quick test seemed to show it works). Could you test again? Regards Antoine. On Sat, 26 Feb 2011 19:23:49 +0100 "Martin v. Löwis" wrote: > Am 26.02.2011 19:13, schrieb Antoine Pitrou: > > > >> In Mercurial, it's just a hook, and opti

[Python-Dev] of branches and heads

On Sat, 26 Feb 2011 10:40:03 -0800 Daniel Stutzbach wrote: > On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > > > There is no such thing as an "unnamed branch". What would "hg branches" > > show? An empty space? > > I understand now why I was confused. I had previously read the sentenc

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: > $ cd py27 # now I want to synchronize > $ hg pull -u ssh://h...@hg.python.org/cpython > > but I'm not going to remember that url every time. It wouldn't be so bad if > Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar

Re: [Python-Dev] Mercurial conversion repositories

>From http://mercurial.selenic.com/wiki/Branch#Named_branches: [...] a good rule of thumb is to use branch names sparingly and for rather longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather not for short lived work of single developers So I think named branches make sense

Re: [Python-Dev] Mercurial conversion repositories

A Mercurial 'merge' is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw wrote: > On Feb 26, 2

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? > I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://m

Re: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

On Sun, Feb 27, 2011 at 3:45 AM, cool-RR wrote: > I think that if someone calls `__enter__` directly, he takes the > responsibility of calling `__exit__`, so we don't really have to help him > with `__del__`. > But other than that I understand the motivation for making it start on > `__init__` ra

Re: [Python-Dev] Mercurial conversion repositories

> >> But is there a need to have any changesets in the "trunk" named branch? > >> Couldn't the historical changesets just be in an unnamed branch, being > >> ancestor of so many named branches? > > > > There is no such thing as an "unnamed branch". What would "hg branches" > > show? An empty spac

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 19:13, schrieb Antoine Pitrou: > >> In Mercurial, it's just a hook, and optional. So we can't be sure all >> users use it correctly - and in my (limited) experience with Mercurial, >> chances are high that users will make mistakes in that respect (i.e. >> in one out of one cross-plat

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote: >>> Named branches are exclusive, they can't be a subset of each other ;) > >Actually, they can. Take the example of the Mercurial repo itself. They >fix bugs in the stable branch and add features in default. When they >merge stable into default a

Re: [Python-Dev] [Python-checkins] cpython: improve license

Am 26.02.2011 19:12, schrieb Barry Warsaw: > Notice the subject line. Can we make commit messages contain the named branch > that the change applies to? If you don't want this request to be forgotten, add it to todo.txt in the pymigr repo. Regards, Martin ___

Re: [Python-Dev] Mercurial conversion repositories

>> But is there a need to have any changesets in the "trunk" named branch? >> Couldn't the historical changesets just be in an unnamed branch, being >> ancestor of so many named branches? > > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? hg branch

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

> In Mercurial, it's just a hook, and optional. So we can't be sure all > users use it correctly - and in my (limited) experience with Mercurial, > chances are high that users will make mistakes in that respect (i.e. > in one out of one cross-platform projects, a committer had issues > with CRLF,

Re: [Python-Dev] [Python-checkins] cpython: improve license

Notice the subject line. Can we make commit messages contain the named branch that the change applies to? The 'cpython' in the header doesn't really tell me whether I should care about this diff or not. Say the change applied to 2.6 but I only care about Python 3. It would be nice if I could ju

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: >Le 25/02/2011 20:43, Barry Warsaw a écrit : >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: >> [snip] >>> Note that each of these branch clones will initially have your local >>> master repo as the default path [3,4]. If you'd like to have

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 18:54, schrieb Antoine Pitrou: > On Sat, 26 Feb 2011 18:48:17 +0100 > martin.v.loewis wrote: >> * some hook should prevent pushing python files indented by tabs. >> * some hook should prevent pushing to the 2.x trunk. >> +* some hook should prevent breaking EOL conventions. > > We

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 18:36 +0100, "Martin v. Löwis" a écrit : > Am 26.02.2011 17:44, schrieb Antoine Pitrou: > > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > >> wrote: > >> Would it be possible to name "trun

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

On Sat, 26 Feb 2011 18:48:17 +0100 martin.v.loewis wrote: > * some hook should prevent pushing python files indented by tabs. > * some hook should prevent pushing to the 2.x trunk. > +* some hook should prevent breaking EOL conventions. We don't have such hook in SVN, why would we need one with

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 17:44, schrieb Antoine Pitrou: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan >> wrote: >> Would it be possible to name "trunk" as "2.x" instead? >> Otherwise I >> could see people getting

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit : > On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou > wrote: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a > écrit : > > > Can we just get rid of "trunk" altogether? It's history is

Re: [Python-Dev] Mercurial conversion repositories

>> Named branches are exclusive, they can't be a subset of each other ;) Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou wrote: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > > Can we just get rid of "trunk" altogether? It's history is a strict > > subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a

Re: [Python-Dev] set iteration order

On 2/26/2011 4:09 AM, Hagen Fürstenau wrote: Hi, I just hunted down a change in behaviour between Python 3.1 and 3.2 to possibly changed iteration order of sets due to the optimization in issue #8685. Of course, this order shouldn't be relied on in the first place, but the side effect of the opt

Re: [Python-Dev] Mercurial conversion repositories

>> Can we just use default for trunk and py3k? For the time when both >> trunk and py3k were active, it would create two unnamed branches on the >> default branch, but one merge would solve that. > > IMO, a dummy merge at the tip of the default branch may confuse users > looking at the history, e

Re: [Python-Dev] Mercurial conversion repositories

On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou wrote: > Besides, it would precisely make it harder to distinguish between > trunk and py3k development at the time both took place in parallel. With the legacy branches now being closed so they don't appear in the default output from hg commands, I

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo wrote: > Le 26/02/2011 17:44, Antoine Pitrou a écrit : > >> Can we just get rid of "trunk" altogether? It's history is a strict > >> subset of the 2.7 branch's history, isn't it? > > > > Named branches are exclusive, they can't be a subset of each o

Re: [Python-Dev] [Python-checkins] r88601 - peps/trunk/pep-0385.txt

On Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou wrote: > +In practice, most Mercurial users under Windows don't seem to have a need > +for the ``eol`` extension, though, and personal experience using a > +Linux-generated SVN checkout through a shared folder under Windows seems > +to confirm that m

Re: [Python-Dev] Mercurial conversion repositories

Le 26/02/2011 17:44, Antoine Pitrou a écrit : >> Can we just get rid of "trunk" altogether? It's history is a strict >> subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a subset of each other ;) Can we just use default for trunk and py3k? For the tim

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > wrote: > Would it be possible to name "trunk" as "2.x" instead? > Otherwise I > could see people getting confused and asking why trunk was > closed,

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan wrote: > Would it be possible to name "trunk" as "2.x" instead? Otherwise I > could see people getting confused and asking why trunk was closed, > and/or not the same as "default". > Can we just get rid of "trunk" altogether? It's history is a stric

Re: [Python-Dev] Mercurial conversion repositories

> Although I now admit "legacy-trunk" sounds quite accurate, and conveys > a clear warning to anyone wondering if they should use it. To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 15:42, schrieb Nick Coghlan: > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: >>> I think people should simply get used to the idea that "default" is >>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >>> ("trunk" sounds a bit obscure at first, for a

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

Le samedi 26 février 2011 à 17:02 +0100, "Martin v. Löwis" a écrit : > > Committing reopened it > > So what's the point of closing it, then? What effect does that > achieve? Again, as I said, it doesn't get displayed anymore with the standard commands "hg branches" and "hg heads". Consider it a c

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

> Committing reopened it So what's the point of closing it, then? What effect does that achieve? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/ma

Re: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

> collections._ChainMap itself is private, so changes can be made to its > API even in a maintenance branch. Makes perfect sense, thanks for the reply :) Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

On Sun, Feb 27, 2011 at 12:40 AM, Éric Araujo wrote: > Isn’t this considered a new feature, unsuitable for 3.2?  (I mean no > disrespect, I just want to understand better what kind of changes can go > in each type of branch.) collections._ChainMap itself is private, so changes can be made to its

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 15:44:08 +0100 Antoine Pitrou wrote: > Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : > > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" > > wrote: > > >> I think people should simply get used to the idea that "default" is > > >> /the/ main branch in Me

Re: [Python-Dev] Mercurial conversion repositories

On 26/02/2011 14:44, Antoine Pitrou wrote: Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to rem

Re: [Python-Dev] Finding buildbot failures

On 26/02/2011 13:46, exar...@twistedmatrix.com wrote: On 01:16 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 19:00, exar...@twistedmatrix.com wrote: On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed o

Re: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

On Sun, 27 Feb 2011 00:39:16 +1000 Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > > Hello, > > I noticed that the `TemporaryDirectory` context manager creates the folder > > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > > hackarounds in `

Re: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

On Sat, Feb 26, 2011 at 4:39 PM, Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > > Hello, > > I noticed that the `TemporaryDirectory` context manager creates the > folder > > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, > and > > hackarounds i

Re: [Python-Dev] Mercurial conversion repositories

Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: > >> I think people should simply get used to the idea that "default" is > >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO > >> ("trunk" sounds a b

Re: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

Hi On Sat, Feb 26, 2011 at 12:52 PM, cool-RR wrote: > I noticed that the `TemporaryDirectory` context manager creates the folder > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > hackarounds in `__del__`. I assume there's a good reason for this decision. > What is i

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: >> I think people should simply get used to the idea that "default" is >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >> ("trunk" sounds a bit obscure at first, for a non-native English >> speaker). > > +1. People

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I >> could see people getting confused and asking why trunk was closed, >> and/or not the same as "default". > > Problem is, you then have 1.5.2 released from the 2.x branch :)

Re: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

Hi, > Author: raymond.hettinger > New Revision: 88526 > Log: Add tests for the collections helper class and sync-up with py3k branch. > Modified: python/branches/release32-maint/Lib/collections.py > +def new_child(self):# like Django's > Context.push() > +'New

Re: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > Hello, > I noticed that the `TemporaryDirectory` context manager creates the folder > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > hackarounds in `__del__`. I assume there's a good reason for this decision. > What

Re: [Python-Dev] Mercurial conversion repositories

Antoine Pitrou wrote: On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0

Re: [Python-Dev] Finding buildbot failures

On 01:16 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 19:00, exar...@twistedmatrix.com wrote: On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier th

Re: [Python-Dev] Finding buildbot failures

On 25/02/2011 19:00, exar...@twistedmatrix.com wrote: On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failin

[Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?

Hello, I noticed that the `TemporaryDirectory` context manager creates the folder on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and hackarounds in `__del__`. I assume there's a good reason for this decision. What is it? Thanks, Ram.

Re: [Python-Dev] Finding buildbot failures

Ezio Melotti gmail.com> writes: > You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots): > > hg clone https://bbreport.googlecode.com/hg/ bbreport > cd bbreport > python bbreport --help > python bbreport 3.x > > (There is some issue with hg revision numbers that I haven't fi

  1   2   >