[Python-Dev] set iteration order

[Hagen Fürstenau]

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 optimization might be worth mentioning
in "What's new", maybe also pointing out that the old behaviour can be
simulated with {x for x in a if x not in b} in place of "a-b".

Cheers,
Hagen

___
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] Mercurial conversion repositories

[Martin v. Löwis]

> 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 will recognize "trunk" as a svn think. If that doesn't
clue them in, they will ask, and every other person will know.

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] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2

[Eric Smith]

Can you open an issue in the bug tracker?

Thanks.

On 2/25/2011 3:48 AM, Juraj Ivančić wrote:

It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation

http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads

Minimal repro:

#include "Python.h"
int main()
{
PyEval_InitThreads();
return 0;
}

___
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/eric%2Ba-python-dev%40trueblade.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] [Python-checkins] cpython (trunk): Close the "trunk" branch.

[Martin v. Löwis]

> http://hg.python.org/cpython/rev/41071f447b15
> changeset:   68041:41071f447b15
> branch:  trunk
> tag: tip
> parent:  62750:800f6c92c3ed
> user:Georg Brandl 
> date:Sat Feb 26 07:48:21 2011 +0100
> summary:
>   Close the "trunk" branch.

What's the effect of "closing" a branch in Mercurial?
I can still commit to it, hg branches still shows it
(but shows 3.2 as "inactive"???). How can I find out
that the branch is closed?

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] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2

[Juraj Ivančić]

On 26.2.2011 10:28, Eric Smith wrote:

On 2/25/2011 3:48 AM, Juraj Ivančić wrote:

It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation

http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads

Minimal repro:

#include "Python.h"
int main()
{
PyEval_InitThreads();
return 0;
}


Can you open an issue in the bug tracker?


http://bugs.python.org/issue11329

___
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] Finding buildbot failures

[Vinay Sajip]

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 fixed yet, 
> but the above command should work fine)

Thanks, Ezio, that's really handy! Just what I needed. Example output (for those
who haven't used the tool) is at

https://gist.github.com/845082

Regards,

Vinay Sajip

___
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] Why does TemporaryDirectory not wait for `__enter__`?

[cool-RR]

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.
___
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] Finding buildbot failures

[Michael Foord]

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 
failing

builds and then looking at the stdio output in a browser?


That's one of the big advantages that Jenkins (nee Hudson) has over 
buildbot - drilling down into individual test failures through the 
web ui. Your test run needs to generate appropriate xml for that to 
work though.


Buildbot can do this too.  It can even do it without xml, although it 
does need *some* parseable format, which I think the Python test suite 
is a long way from.




That would be a great improvement to the Python buildbot infrastructure. 
(Probably a bit small for a GSOC project on its own.) I've had great 
success using pyjunitxml to generate Hudson compatible reports from 
unittest test runs (extremely easy to use), and if buildbot *can* handle 
junit xml format reports then it may be the path of least resistance:


https://launchpad.net/pyjunitxml

I tried searching (both google and the buildbot docs) for ways to 
generate more complete reports or to integrate junitxml with builbot, 
but failed. Can you point me at anything?


All the best,

Michael


Jean-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/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] Finding buildbot failures

[exarkun]

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 than using the Web interface to browse to 
failing

builds and then looking at the stdio output in a browser?


That's one of the big advantages that Jenkins (nee Hudson) has over 
buildbot - drilling down into individual test failures through the 
web ui. Your test run needs to generate appropriate xml for that to 
work though.


Buildbot can do this too.  It can even do it without xml, although it 
does need *some* parseable format, which I think the Python test suite 
is a long way from.


That would be a great improvement to the Python buildbot 
infrastructure. (Probably a bit small for a GSOC project on its own.) 
I've had great success using pyjunitxml to generate Hudson compatible 
reports from unittest test runs (extremely easy to use), and if 
buildbot *can* handle junit xml format reports then it may be the path 
of least resistance:


https://launchpad.net/pyjunitxml

I tried searching (both google and the buildbot docs) for ways to 
generate more complete reports or to integrate junitxml with builbot, 
but failed. Can you point me at anything?


I think this is the relevant pages in the buildbot manual for custom 
reporting:


 http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html 
#BuildStep-LogFiles


There's also
http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand

which is basically the same idea as junitxml, but not actually junitxml 
itself, so I'd probably go that way.  However if you really need 
junitxml for something, there are tools for converting between subunit 
and junitxml.


Jean-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] Mercurial conversion repositories

[Ethan Furman]

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:8174d00d0797
   3.167955:5be8b695ea86
   2.667287:5e26a860eded
   2.565464:e4ecac76e499
   trunk  62750:800f6c92c3ed
   3.060075:1d05144224fe
   2.458552:df72cac1899e
   2.345731:a3d9a9730743
   2.240444:d55ddc8c8501
   2.130171:06fcccf6eca8
   2.018214:dc0dfc9565cd

The branch "default" is the current py3k branch from SVN. The branch
"trunk" represents SVN trunk history until 2.7 was branched for
maintenance.

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".


That was my first idea, but then I realized that the branch includes 1.x
and even pre-1.0 commits, so "2.x" might actually be more
confusing/misleading and hide the fact that the full trunk history is
there.


Maybe prePy3k, then?  Trunk, after all, is not very descriptive.  Or is 
that name also inaccurate?


~Ethan~
___
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] Why does TemporaryDirectory not wait for `__enter__`?

[Nick Coghlan]

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 is it?

>From the docstring: "This has the same behavior as mkdtemp but can be
used as a context manager." Like files, it *can* be used as a context
manager, but doesn't have to be.

Also, the complexity wouldn't go away even if the directory creation
was delayed until the __enter__ invocation. People can still call
__enter__ directly, so __del__ would still be obliged to try to clear
things up as best it could.

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] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

[Éric Araujo]

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 ChainMap with a new dict followed by all previous maps.'
> +return self.__class__({}, *self.maps)
> +
> +@property
> +def parents(self):  # like Django's Context.pop()
> +'New ChainMap from maps[1:].'
> +return self.__class__(*self.maps[1:])

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.)

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] Mercurial conversion repositories

[Nick Coghlan]

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 :)

In that case, "legacy-trunk" would seem clearer.

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] Mercurial conversion repositories

[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 non-native English
>> speaker).
>
> +1. People will recognize "trunk" as a svn think. If that doesn't
> clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

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] Why does TemporaryDirectory not wait for `__enter__`?

[Andreas Stührk]

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 it?

The reason is that you can use `TemporaryDirectory` without a context
manager too. Note that creating things in  `__init__` rather than in
`__enter__` isn't unusual -- it is done in the same way for regular
files. I'm not sure what you mean with "hackarounds in `__del__`", but
I assume you mean the code in `cleanup()`. That code tries to do the
right thing on interpreter shutdown when parts of the interpreter are
already gone and it emits a `ResourceWarning` if called implicitly
(IOW: when you didn't use `TemporaryDirectory` as a context manager
and didn't call its `cleanup()` method). So a bit of complexity is
there, but it really isn't about where the directory is created.

Regards,
Andreas
___
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] Mercurial conversion repositories

[Antoine Pitrou]

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 bit obscure at first, for a non-native English
> >> speaker).
> >
> > +1. People will recognize "trunk" as a svn think. If that doesn't
> > clue them in, they will ask, and every other person will know.
> 
> But why not choose a name where they don't even have to ask?

Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
Other names would probably be less exact or less precise.

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] Why does TemporaryDirectory not wait for `__enter__`?

[cool-RR]

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 in `__del__`. I assume there's a good reason for this
> decision.
> > What is it?
>
> From the docstring: "This has the same behavior as mkdtemp but can be
> used as a context manager." Like files, it *can* be used as a context
> manager, but doesn't have to be.
>
> Also, the complexity wouldn't go away even if the directory creation
> was delayed until the __enter__ invocation. People can still call
> __enter__ directly, so __del__ would still be obliged to try to clear
> things up as best it could.
>
> Cheers,
> Nick.


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__` rather then `__enter__`. I'll just make my own version of it that
will work on `__enter__` instead.

Thanks,
Ram.
___
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] Why does TemporaryDirectory not wait for `__enter__`?

[Antoine Pitrou]

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 `__del__`. I assume there's a good reason for this decision.
> > What is it?
> 
> >From the docstring: "This has the same behavior as mkdtemp but can be
> used as a context manager." Like files, it *can* be used as a context
> manager, but doesn't have to be.
> 
> Also, the complexity wouldn't go away even if the directory creation
> was delayed until the __enter__ invocation. People can still call
> __enter__ directly, so __del__ would still be obliged to try to clear
> things up as best it could.

Calling __enter__ directly without caring to call __exit__ afterwards
should certainly be considered a user bug (not to mention of dubious
utility in this case, since it's easier to spell mkdtemp() than
TemporaryDirectory().__enter__()).

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] Finding buildbot failures

[Michael Foord]

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 on buildbot 
builds? I mean,
is there anything easier than using the Web interface to browse to 
failing

builds and then looking at the stdio output in a browser?


That's one of the big advantages that Jenkins (nee Hudson) has over 
buildbot - drilling down into individual test failures through the 
web ui. Your test run needs to generate appropriate xml for that to 
work though.


Buildbot can do this too.  It can even do it without xml, although 
it does need *some* parseable format, which I think the Python test 
suite is a long way from.


That would be a great improvement to the Python buildbot 
infrastructure. (Probably a bit small for a GSOC project on its own.) 
I've had great success using pyjunitxml to generate Hudson compatible 
reports from unittest test runs (extremely easy to use), and if 
buildbot *can* handle junit xml format reports then it may be the 
path of least resistance:


https://launchpad.net/pyjunitxml

I tried searching (both google and the buildbot docs) for ways to 
generate more complete reports or to integrate junitxml with builbot, 
but failed. Can you point me at anything?


I think this is the relevant pages in the buildbot manual for custom 
reporting:


 http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html 
#BuildStep-LogFiles


There's also
http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand 



which is basically the same idea as junitxml, but not actually 
junitxml itself, so I'd probably go that way.  However if you really 
need junitxml for something, there are tools for converting between 
subunit and junitxml.


Thanks Jean-Paul.

Michael



Jean-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/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] Mercurial conversion repositories

[Michael Foord]

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 remember IMHO
("trunk" sounds a bit obscure at first, for a non-native English
speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't
clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
Other names would probably be less exact or less precise.


Well, except for the prevalence of "trunk" as terminology to mean "place 
where current development happens". It will lead to odd conversations 
like:  "is trunk the trunk?", "no trunk is what used to be trunk, 
default is now trunk".


Renaming it "legacy-trunk" is no less precise, but more explicative.

Michael


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/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] Mercurial conversion repositories

[Antoine Pitrou]

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 Mercurial (*). It's even easier to remember IMHO
> > >> ("trunk" sounds a bit obscure at first, for a non-native English
> > >> speaker).
> > >
> > > +1. People will recognize "trunk" as a svn think. If that doesn't
> > > clue them in, they will ask, and every other person will know.
> > 
> > But why not choose a name where they don't even have to ask?
> 
> Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
> Other names would probably be less exact or less precise.

Although I now admit "legacy-trunk" sounds quite accurate, and conveys
a clear warning to anyone wondering if they should use it.

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] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

[Nick Coghlan]

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
API even in a maintenance branch.

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] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

[Éric Araujo]

> 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/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

> 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/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 convention rather than some kind of hard stop against
future commits.

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] Mercurial conversion repositories

[Martin v. Löwis]

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 non-native English
>>> speaker).
>>
>> +1. People will recognize "trunk" as a svn think. If that doesn't
>> clue them in, they will ask, and every other person will know.
> 
> But why not choose a name where they don't even have to ask?

That could be better. Unfortunately, nobody has proposed a name
that has this property and is also correct.

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] Mercurial conversion repositories

[Martin v. Löwis]

> 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 and especially a tree remaining
attached to the root after the trunk is cut"
___
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] Mercurial conversion repositories

[Daniel Stutzbach]

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 strict subset
of the 2.7 branch's history, isn't it?

-- 
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] Mercurial conversion repositories

[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 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 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 ;)
(in other words: 2.7 starts where trunk stops; trunk changesets are
strict ancestors of 2.7)

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] Mercurial conversion repositories

[Éric Araujo]

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 time when both
trunk and py3k were active, it would create two unnamed branches on the
default branch, but one merge would solve that.

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] [Python-checkins] r88601 - peps/trunk/pep-0385.txt

[Nick Coghlan]

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 modern tools work well without it.

Feedback from the Mozilla and XEmacs folks at the time of that
discussion suggested that EOL issues *were* a potential issue, and
that having to revert unintentional commits of CRLF line endings was
an annoyingly common problem.

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] Mercurial conversion repositories

[Antoine Pitrou]

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 other ;)
> 
> 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, especially if they try a graphical display of
the DAG (e.g. "hg glog" or the graph page in the Web UI).

Besides, it would precisely make it harder to distinguish between
trunk and py3k development at the time both took place in parallel.

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] Mercurial conversion repositories

[Nick Coghlan]

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'm fine with keeping the old "trunk"
name from SVN. It was only when those commands were displaying both
"trunk" and "default" that it bothered me.

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] Mercurial conversion repositories

[Éric Araujo]

>> 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, especially if they try a graphical display of
> the DAG (e.g. "hg glog" or the graph page in the Web UI).

The dummy merge would not stay long: The commits targeted at 3.3 would
be its children.

> Besides, it would precisely make it harder to distinguish between
> trunk and py3k development at the time both took place in parallel.

IIUC, there would be two parallel lines of history (unnnamed branches).
 Would that be hard to read?

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] set iteration order

[Terry Reedy]

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 optimization might be worth mentioning
in "What's new", maybe also pointing out that the old behaviour can be
simulated with {x for x in a if x not in b} in place of "a-b".


-1
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 is not the place of What's new to cater to buggy code.
Besides which, there is no guarantee that the 'x in a' part of the 
suggestion will will remain the same from version to version or even 
from run to run.


--
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] Mercurial conversion repositories

[Daniel Stutzbach]

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 subset of each other ;)
> (in other words: 2.7 starts where trunk stops; trunk changesets are
> strict ancestors of 2.7)
>

Maybe I don't fully understand how Mercurial branches work or how it defines
terminology (in fact, that is likely :) ).  What's the difference between
the statement "trunk changesets are strict ancestors of 2.7" and the
statement "trunk's history is a strict subset of 2.7's history"?

-- 
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] Mercurial conversion repositories

[Éric Araujo]

>> 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 is to say, someone pulling default also gets the
changesets from stable that are ancestors of the merge changset.  Or in
other words, if you check out default, you get all bug fixes from stable.

HTH
___
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] Mercurial conversion repositories

[Antoine Pitrou]

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
> 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 ;)
> (in other words: 2.7 starts where trunk stops; trunk
> changesets are
> strict ancestors of 2.7)
> 
> 
> Maybe I don't fully understand how Mercurial branches work or how it
> defines terminology (in fact, that is likely :) ).  What's the
> difference between the statement "trunk changesets are strict
> ancestors of 2.7" and the statement "trunk's history is a strict
> subset of 2.7's history"?

Apparently you overlooked the first statement:
"Named branches are exclusive".
In other words, a changeset can be in only one named branch.
So it's impossible for a branch to be a subset or superset of another.
(except the trivial case of an empty branch :-)).



___
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] Mercurial conversion repositories

[Martin v. Löwis]

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 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 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 ;)
> (in other words: 2.7 starts where trunk stops; trunk changesets are
> strict ancestors of 2.7)

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?

I'd like to prevent people from mistakenly committing onto the trunk,
which would be easiest if trunk didn't exist at all.

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] pymigr: Ask for hgeol-checking hook.

[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 don't have such hook in SVN, why would we need one with Mercurial ?


___
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] Mercurial conversion repositories

[Antoine Pitrou]

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 "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 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 ;)
> > (in other words: 2.7 starts where trunk stops; trunk changesets are
> > strict ancestors of 2.7)
> 
> 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?

> I'd like to prevent people from mistakenly committing onto the trunk,
> which would be easiest if trunk didn't exist at all.

Well, the push you request in the todo should do the trick.
We can also call it "legacy-trunk", too :)

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] pymigr: Ask for hgeol-checking hook.

[Martin v. Löwis]

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 don't have such hook in SVN, why would we need one with Mercurial ?

In subversion, it's a builtin feature of subversion (svn:eol-style);
subversion will automatically convert all files correctly (if
svn:eol-style is specified correctly, which it is, for most of the
files).

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, leading to catastrophic repository corruption).

So I think it's absolutely necessary that files with incorrect
eol-style are blocked from being pushed. Or else we will all
suffer and eventually die :-)

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] Mercurial conversion repositories

[Barry Warsaw]

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 the default
>>> push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd
>>> want to edit the [paths] section in the .hg/hgrc file in each of the
>>> branch repos.
>
>I plan on having one clone per branch but pushing and pulling from only
>one repository, so I don’t need to edit hgrcs.

So let's start from the basics.  I want separate working directories for each
active line-of-development (I'll use that term instead of "branch"),
e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and
3.3.  I will not be doing feature or bug development in any of these
directories.  They are purely for local tracking of the remote masters.  Thus,
I want to be able to synchronize any one of those LoDs against the remote
master with one command, like I would using Subversion's 'svn up'.

I clone the remote repository using the command in the devguide, so I now have
a 'cpython' directory containing the history of all LoDs, but with a working
directory that reflects the 'default' LoD.  Now, in the parent of 'cpython', I
do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26
$ hg clone -u 2.7 cpython py27
# repeat and rinse for all other active LoDs

(Aside: that cpython directory still bugs me.  It doesn't naturally reflect a
LoD, so why do I have to stare at it?  Yes, I can make it play double duty by
naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
artificial.)

Now I want to synchronize my local py27 directory with the state of that LoD
on python.org.  This is a two step process:

$ cd py27 # now I want to synchronize
$ (cd ../cpython && hg pull)
$ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master
operation is one command.

I could do this:

$ 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 does.

>Anecdote: I migrated from Subversion to Mercurial a few years ago, and
>found Mercurial branches very intuitive.  When I saw mentions of Bazaar
>branches I was driven nuts by (what I saw as) the conflation between a
>branch and a clone.  Later I understood how it made sense from the
>perspective of Bazaar, so I shifted my judgment from “insanely
>confusing” to “a particular choice that I don’t approve” .

That's funny because to my eyes, Mercurial conflates "branches" and "clones".
Why a clone operation should give me the history for all lines-of-development
inside a working directory for one "arbitrary" one strikes me as bizarre
(pardon the pun :).  I get that for folks who like the "svn switch" method of
working on multiple LoDs, this probably makes a lot of sense.  I don't
personally like or trust that approach much though.

>What I’m saying is that a lot of Bazaar terminology using “branch” does
>not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
>we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
>one named branch.  I think you know that already, since you went from
>using Bazaar terms applied to Mercurial to mixing terms from both
>(“clone a new branch working directory” → “clone a repo”, probably).  I
>salute your willingness to learn Mercurial, considering how fluent (and
>fluffly) you appear to be with Bazaar.

This is an inevitable problem with trying to converse fluently about three
major dVCSs and at least one or two other non-dVCSs.  They all use the same
words to mean vaguely similar things, but quickly get bogged down in the
implementation details assigned to those words.  It all makes perfect sense
when you've been immersed in those technologies, but it makes discussions and
comparisons exceedingly difficult.  I've no doubt it's doubly painful to many
people who have no prior experience with a dVCS.

(Aside: Bazaar could have potentially eased these folks transition because you
can use Bazaar just like you would Subversion - as a centralized VCS --
without stopping others from using it with full dVCS features on the same code
base.  I don't know if Mercurial offers the same flexibility.)

It's a little like trying to teach Python to a Java programmer.  "Object",
"Class", "Instance", "Import" all mean roughly similar things, which lulls you
into a false sense of understanding.  We learn by holding up the new to the
light of the familiar and looking for interference patterns. :)

>> I'll have to remember that 'hg pull' does not update the working copy by
>> default,
>
>That pull does not update is a feature: The operation between a remote
>repo and the local repo (the .hg

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

[Barry Warsaw]

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 just delete this message without reading the body.

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.

-Barry

On Feb 26, 2011, at 07:05 PM, benjamin.peterson wrote:

>benjamin.peterson pushed 0873fb83f1e2 to cpython:
>
>http://hg.python.org/cpython/rev/0873fb83f1e2
>changeset:   68052:0873fb83f1e2
>tag: tip
>user:Benjamin Peterson 
>date:Sat Feb 26 12:06:36 2011 -0600
>summary:
>  improve license
>
>files:
>  LICENSE


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] pymigr: Ask for hgeol-checking hook.

[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-platform projects, a committer had issues
> with CRLF, leading to catastrophic repository corruption).

“Catastrophic” repository “corruption”? This sounds very strongly like
an urban legend.
Perhaps some files had later to be fixed. But that shouldn't be out of
the realm of normal Mercurial commands (aka "edit file to fix endings,
then hg commit and hg push").

> So I think it's absolutely necessary that files with incorrect
> eol-style are blocked from being pushed. Or else we will all
> suffer and eventually die :-)

Well, the latter is a given, isn't it? ;)

Anyway, hgeol actually seems to include such a hook. I'll try to enable
it.

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] Mercurial conversion repositories

[Martin v. Löwis]

>> 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 branches doesn't list unnamed branches. "hg heads" omits any branch
name for unnamed branches. See the cpythonextras repository for examples:

changeset:   72694:e65daae6cf44
user:Antoine Pitrou 
date:Mon Feb 21 21:30:55 2011 +
summary: Try s/UINT_MAX/INT_MAX/

This is listed as a head, but not of a named branch.

>> I'd like to prevent people from mistakenly committing onto the trunk,
>> which would be easiest if trunk didn't exist at all.
> 
> Well, the push you request in the todo should do the trick.

Yes, that would also work. However, when then somebody proposed that
we may not need the trunk branch at all in the conversion result
(which I still think is the case - we don't need it), I noticed
that this would solve the problem in a more clean manner.

> We can also call it "legacy-trunk", too :)

I think we can do better. I also dislike "hg log --only-branch default"
to only go back to 2006 (to aeefba456e4d), when this revision actually
does have a parent (namely, on the trunk branch, 4b41806a0326).

So I would propose this attribution to branches:
- everything that is ancestor of the default branch is attributed
  to the default branch, back to the very beginning of the repository.
- Everything currently on trunk that wouldn't be on default is then
  attributed to the oldest branch that it is an ancestor of, in the
  order 2.0, 2.1, 2.2, ... 2.7.

So e.g. the 2.7 branch would go back to where it branched from the 2.6
branch (after the actual creation of the 2.6 branch in svn), which
would go back to where it branched from 2.5, and so on.

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] [Python-checkins] cpython: improve license

[Martin v. Löwis]

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
___
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] Mercurial conversion repositories

[Barry Warsaw]

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 and commit, default becomes a superset of
>stable.  That is to say, someone pulling default also gets the
>changesets from stable that are ancestors of the merge changset.  Or in
>other words, if you check out default, you get all bug fixes from stable.

That makes sense, but correct me if I'm wrong, it's the 'merge' operation that
made this happen, right?  A merge essentially brings the changesets from one
branch into another.

-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] pymigr: Ask for hgeol-checking hook.

[Martin v. Löwis]

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-platform projects, a committer had issues
>> with CRLF, leading to catastrophic repository corruption).
> 
> “Catastrophic” repository “corruption”? This sounds very strongly like
> an urban legend.
> Perhaps some files had later to be fixed. But that shouldn't be out of
> the realm of normal Mercurial commands (aka "edit file to fix endings,
> then hg commit and hg push").

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 last ok revision, and redo all checkins
since (I also discarded changes which I didn't chose to redo). It was
a real catastrophe to me.

Since the changes actually changed all lines, "hg blame" became useless,
which was unacceptable.

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] Mercurial conversion repositories

[Antoine Pitrou]

> >> 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 branches doesn't list unnamed branches. "hg heads" omits any branch
> name for unnamed branches. See the cpythonextras repository for examples:
> 
> 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
output).

> >> I'd like to prevent people from mistakenly committing onto the trunk,
> >> which would be easiest if trunk didn't exist at all.
> > 
> > Well, the push you request in the todo should do the trick.
> 
> Yes, that would also work. However, when then somebody proposed that
> we may not need the trunk branch at all in the conversion result
> (which I still think is the case - we don't need it), I noticed
> that this would solve the problem in a more clean manner.

But you *need* the changesets from the trunk branch. You are just
arguing for giving them another label (including "" or "default"),
hence:

> > We can also call it "legacy-trunk", too :)
> 
> I think we can do better. I also dislike "hg log --only-branch default"
> to only go back to 2006 (to aeefba456e4d), when this revision actually
> does have a parent (namely, on the trunk branch, 4b41806a0326).

I'm not convinced that small quirks of using "hg log" are important at
this point. Also, you could try other options of "hg log" such as
"--follow".

If we called ex-trunk the same name as ex-py3k ("default"), things would
probably be quite more confusing, since inspecting a changeset wouldn't
tell you immediately where it comes from (2.x or 3.x development).

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] Why does TemporaryDirectory not wait for `__enter__`?

[Robert Collins]

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__` rather then `__enter__`. I'll just make my own version of it that
> will work on `__enter__` instead.
> Thanks,
> Ram.

TempDir from 'fixtures' (http://pypi.python.org/pypi/fixtures) will do
what you want - __enter__ creates the directory, __exit__ deletes it.

Cheers,
Rob
___
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] Mercurial conversion repositories

[Daniel Stutzbach]

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://mercurial.selenic.com/wiki/BranchingExplained

But as I dig deeper, I see that there is only one unnamed branch, and it
actually does have an implicit name: "default".

It appears Mercurial supports at least three different kinds of branching:
cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
 So a named branch can contain more than one branch.

Were there reasons for going with named branches over bookmarks?  PEP 385
discusses only cloning and named branches.  I'm just curious, not trying to
start a long discussion. :-)

-- 
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] Mercurial conversion repositories

[Santoso Wijaya]

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, 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 and commit, default becomes a superset of
> >stable.  That is to say, someone pulling default also gets the
> >changesets from stable that are ancestors of the merge changset.  Or in
> >other words, if you check out default, you get all bug fixes from stable.
>
> That makes sense, but correct me if I'm wrong, it's the 'merge' operation
> that
> made this happen, right?  A merge essentially brings the changesets from
> one
> branch into another.
>
> -Barry
>
> ___
> 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/santoso.wijaya%40gmail.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] Mercurial conversion repositories

[Santoso Wijaya]

>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 here. Bookmarks are really for
potential branches, experimental features, for example, for easier
navigation for the developer's convenience. Named branches, on the other
hand, are better for posterity reasons.

~/santa


On Sat, Feb 26, 2011 at 10:40 AM, 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 sentence
> "Both Git and Mercurial support unnamed local branches." at
> http://mercurial.selenic.com/wiki/BranchingExplained
>
> But as I dig deeper, I see that there is only one unnamed branch, and it
> actually does have an implicit name: "default".
>
> It appears Mercurial supports at least three different kinds of branching:
> cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
>  So a named branch can contain more than one branch.
>
> Were there reasons for going with named branches over bookmarks?  PEP 385
> discusses only cloning and named branches.  I'm just curious, not trying to
> start a long discussion. :-)
>
> --
>  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/santoso.wijaya%40gmail.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] Mercurial conversion repositories

[R. David Murray]

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 does.

How does setting it in the hgrc differ from "remebering" it?  I've never
been comfortable with the bzr --remember option because I'm never
sure what it is remembering.  Much easier for me to see it in a config
file.  But, then, that's how my brain works, and other people's will
work differently.

> On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >branches I was driven nuts by (what I saw as) the conflation between a
> >branch and a clone.  Later I understood how it made sense from the
> >perspective of Bazaar, so I shifted my judgment from “insanely
> >confusing” to “a particular choice that I don’t approve” .
> 
> That's funny because to my eyes, Mercurial conflates "branches" and "clones".
> Why a clone operation should give me the history for all lines-of-development
> inside a working directory for one "arbitrary" one strikes me as bizarre
> (pardon the pun :).  I get that for folks who like the "svn switch" method of
> working on multiple LoDs, this probably makes a lot of sense.  I don't
> personally like or trust that approach much though.

I agree with you that I don't trust the 'svn switch' style.  I also find
it slow.  However

> >That pull does not update is a feature: The operation between a remote
> >repo and the local repo (the .hg directory) is separate from the
> >operation from the local repo to the working directory.  When you know
> >that you want pull + update (like when you have a clean working
> >directory), you use “hg pull -u”.  (I don’t like the fetch command.)
> 
> Sure, I get that.  Again, this feature appears odd because I have the full
> history of all LoDs embedded in a working directory of a single LoD.  With the
> arrangement I outlined above (which is independent of the dVCS backing it), it
> makes no sense for each LoD working directory to contain all the history of
> all the other LoDs.
> 
> In Bazaar, a "branch" is an independent LoD and it's "repository" contains
> only its own history.  Sure, it might have identical history with other LoDs
> up to the point of divergence, and I have ways to efficiently share that
> history across multiple LoD working directories, but they are still separate
> and I don't need them if I don't care about them.  With Mercurial, all history
> for all LoDs in a repository always come along for the ride.

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 working copy, and that the repository is *the*
repository.  That is, it has everything related to the project in it,
just like the master SVN repository does (plus, since it is a DVCS,
whatever I've committed locally but not pushed to the master).  To have
a repository that only has some of the stuff in it is, IMO, confusing.
I advocated for having all the Python history in one repo partly for
that reason.

I can intellectually see your point about not really *needing* the stuff
for the LODs if you are only working on LOD X, but just like 'svn switch'
makes me uncomfortable, I'm just not *comfortable* not having the whole
repo in there :)

As an example, with mercurial, I feel comfortable moving directories
around and renaming them (with the help of google it took me about 1
minute to figure out how to keep the association between the repository
instances intact).  With bazaar I got in trouble trying to do that,
because the interrelationship between the working copy directories
(and their subsets of the repo?) and the master repo(?) was not clear.
I never did figure out how to make it work, I ended up starting over
with a new clone.

Now, as I get farther into learning mercurial I may well find things that
are just as confusing as I found that aspect of bazaar, but at least I
am comfortable with the outermost layer: the repo is the repo is the repo.

--
R. David Murray  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

[Python-Dev] of branches and heads

[Antoine Pitrou]

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 sentence
> "Both Git and Mercurial support unnamed local branches." at
> http://mercurial.selenic.com/wiki/BranchingExplained
> 
> But as I dig deeper, I see that there is only one unnamed branch, and it
> actually does have an implicit name: "default".


Ok, so beware, the term "branch" can conflate two concepts:
- a path in the topology (or line of development)
- a "named branch" in hg terminology

So, actually, hg promotes a slightly different terminology:
- a "head" is a changeset without a child in the topology
- 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 (even though in practice it will have, since it's the
  whole point from the user's perspective, and also because hg's
  default behaviour and concept of a "current branch" encourages it)

A (named) branch can have zero, one, or several heads:
- zero head: if all branch-local heads have a child in another named
  branch (for example, "trunk" is linearly followed by "2.7")
- several heads: if several lines of development were started in this
  branch without bothering to give them separate names

When you have several heads on a branch, you can merge them together if
you want to reconcile the lines of development they represent.

When you have several branches with at least one head each, you can
also merge them together: you must be careful to choose which named 
branch the merge changeset will be part of (for example, if you want
to merge "3.1" into "3.2", you will certainly want the merge changeset
to be part of "3.2", otherwise "3.1" will get a lot of unwanted
features ;-)).

Note: a branch with zero head is marked "inactive" in "hg branches".
This basically means that it has already been merged in another branch.
(of course, you can still develop in that branch, which will certainly
create a new head as soon as you commit your first new changeset)

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] pymigr: Ask for hgeol-checking hook.

[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?

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 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, leading to catastrophic repository corruption).
> > 
> > “Catastrophic” repository “corruption”? This sounds very strongly like
> > an urban legend.
> > Perhaps some files had later to be fixed. But that shouldn't be out of
> > the realm of normal Mercurial commands (aka "edit file to fix endings,
> > then hg commit and hg push").
> 
> 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 last ok revision, and redo all checkins
> since (I also discarded changes which I didn't chose to redo). It was
> a real catastrophe to me.
> 
> Since the changes actually changed all lines, "hg blame" became useless,
> which was unacceptable.
> 
> 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] r88589 - python/branches/py3k/Lib/test/test_logging.py

[Brett Cannon]

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 18:02:43 2011
> > New Revision: 88589
> >
> > Log:
> > logging: enabled test which was intermittently failing on buildbots.
>
>
> Looks like it fails again:
>
> (
> http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio)
>
> ==
> ERROR: test_compute_rollover_MIDNIGHT
> (test.test_logging.TimedRotatingFileHandlerTest)
> --
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1990, in tearDown
>os.unlink(self.fn)
> WindowsError: [Error 32] The process cannot access the file because it is
> being used by another process:
> 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log'
>
> ==
> FAIL: test_compute_rollover_MIDNIGHT
> (test.test_logging.TimedRotatingFileHandlerTest)
> --
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 2053, in test_compute_rollover
>self.assertEqual(exp, rh.computeRollover(0.0))
> AssertionError: 82800 != 18000.0
>
> ==
> FAIL: test_compute_rollover_S
> (test.test_logging.TimedRotatingFileHandlerTest)
> --
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1981, in setUp
>BaseTest.setUp(self)
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 95, in setUp
>raise AssertionError('Unexpected handlers: %s' % hlist)
> AssertionError: Unexpected handlers: [ 0x0DAFC5B0>]
>
> ==
> FAIL: test_compute_rollover_W0
> (test.test_logging.TimedRotatingFileHandlerTest)
> --
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1981, in setUp
>BaseTest.setUp(self)
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 95, in setUp
>raise AssertionError('Unexpected handlers: %s' % hlist)
> AssertionError: Unexpected handlers: [ 0x0DAFC5B0>]
>
>
> ___
> 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/brett%40python.org
>
___
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] Mercurial conversion repositories

[Brett Cannon]

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 afraid. :)
>
> >You can even select indvidually inside a file which lines to commit or
> >not. A bit risky but very handy when you have a few oneliners to commit
> >or not to commit.
>
> You mean, TortoiseHg supports incremental commits on a single file?  That's
> kind of neat, but scary. ;)
>

The record extension lets regular Mercurial do that as well. I think git
supports a similar thing.

-Brett


>
> -Barry
>
> ___
> 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/brett%40python.org
>
>
___
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] Mercurial conversion repositories

[Brett Cannon]

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
> >>> master repo as the default path [3,4]. If you'd like to have the
> default
> >>> push/pull path to point to ssh://h...@hg.python.org/cpython instead,
> you'd
> >>> want to edit the [paths] section in the .hg/hgrc file in each of the
> >>> branch repos.
> >
> >I plan on having one clone per branch but pushing and pulling from only
> >one repository, so I don’t need to edit hgrcs.
>
> So let's start from the basics.  I want separate working directories for
> each
> active line-of-development (I'll use that term instead of "branch"),
> e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2,
> and
> 3.3.  I will not be doing feature or bug development in any of these
> directories.  They are purely for local tracking of the remote masters.
>  Thus,
> I want to be able to synchronize any one of those LoDs against the remote
> master with one command, like I would using Subversion's 'svn up'.
>

For other people's benefit, LoD == line of development (I think).


>
> I clone the remote repository using the command in the devguide, so I now
> have
> a 'cpython' directory containing the history of all LoDs, but with a
> working
> directory that reflects the 'default' LoD.  Now, in the parent of
> 'cpython', I
> do the following to get my separate-directory-LoDs:
>
> $ hg clone -u 2.6 cpython py26
> $ hg clone -u 2.7 cpython py27
> # repeat and rinse for all other active LoDs
>
>
That's one way of doing it.


> (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
> a
> LoD, so why do I have to stare at it?  Yes, I can make it play double duty
> by
> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
> artificial.)
>

It's a clone repository of CPython; the name makes perfect sense. You are
focusing on what the repository happens to be updated to ATM, not the fact
that the repository itself represents any and all LoDs.


>
> Now I want to synchronize my local py27 directory with the state of that
> LoD
> on python.org.  This is a two step process:
>
> $ cd py27 # now I want to synchronize
> $ (cd ../cpython && hg pull)
> $ hg pull -u
>
> Editing hgrc to point to hg.python.org means the sync-to-remote-master
> operation is one command.
>
> I could do this:
>
> $ 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
> does.
>

So does Hg: simply edit your .hgrc to have it both pull and push to the same
URL.

Or you can save yourself some trouble, and simply clone the repository at a
specific branch:

  hg clone ssh://h...@hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the
branch.


>
> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >branches I was driven nuts by (what I saw as) the conflation between a
> >branch and a clone.  Later I understood how it made sense from the
> >perspective of Bazaar, so I shifted my judgment from “insanely
> >confusing” to “a particular choice that I don’t approve” .
>
> That's funny because to my eyes, Mercurial conflates "branches" and
> "clones".
> Why a clone operation should give me the history for all
> lines-of-development
> inside a working directory for one "arbitrary" one strikes me as bizarre
> (pardon the pun :).


Because Hg views a clone as that: a clone of the entire repository. A branch
just happens to be a part of the repository. And because it is the entire
repository it has to have you point somewhere, so it goes with default since
a lot of people never even work somewhere other than on default.


>  I get that for folks who like the "svn switch" method of
> working on multiple LoDs, this probably makes a lot of sense.  I don't
> personally like or trust that approach much though.
>

Neither do I in an svn context and why Hg does let you check out just a
branch and have all pulls and pushes only go to that branch.


>
> >What I’m saying is that a lot of Bazaar terminology using “branch” does
> >not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
> >we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
> >one named branch.  I think you know that already, since you went from
> >using Bazaar terms applied to Mercurial to mixing terms from both
> >(“clone a new branch working directory” → “clone a repo”, probably).  I
> >salute your willingness to learn Mercurial, considering how fluent (and
> >fluffly) you appear to be with Bazaar.
>
> Th

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

[Tim Delaney]

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 used to filter out closed branches from hg branches
and hg heads unless you use the --closed option - it doesn't prevent you
from using the branches.

Basically, it reduces the noise, especially if you have very branchy
development like I personally prefer (a named branch per task/issue). If you
only use anonymous branches, except for your feature branches (e.g. 3.2,
2.7) then you'd probably never close a branch.

Tim Delaney
___
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: improve license

[Tim Delaney]

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 way that a single
change notification could be for more than one named branch.

If the notifications are per-pull/per-push, then yes it could be for
multiple branches.

In either case, it should definitely be possible to put the name(s) of the
branches in the change notifications - in either type of hook you can
inspect the changesets and determine what branch they are on.

Tim Delaney
___
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] pymigr: Ask for hgeol-checking hook.

[Tim Delaney]

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 last ok revision, and redo all checkins
> since (I also discarded changes which I didn't chose to redo). It was
> a real catastrophe to me.
>
> Since the changes actually changed all lines, "hg blame" became useless,
> which was unacceptable.
>

I'd disagree that that is catastrophic repository corruption - it's fixable
by creating a new clone from before the "corruption", discarding the old one
and redoing the changes (possibly via cherry-picking).

Catastrophic corruption of a mercurial repository happens when the history
itself becomes corrupted. This should never happen under normal usage, but
it is possible to happen if you commit using an older version of hg to a
repo that's been created (or modified) by a newer version.

You can pull from a newer version repo using the older version, but you
shouldn't ever commit to it (including pushing) except through the "remote"
interfaces (where the remote hg is the one doing the actual commits).

Tim Delaney
___
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] Mercurial conversion repositories

[Barry Warsaw]

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
editor with two files, one is the commit message and the other is the diff.
(The script itself is a bit buggy too. ;)

But it's a good clue, and I've modified the default hgeditor script to get
closer, and fix the bug I noticed.  I basically append the diff to the
temporary log message file.  It's still not right though because if the diff
lines aren't prepended with 'HG:', they end up in the commit message.  Arg.

Oh well, I can clearly hack a more complicated script together.  It's such a
blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by
default.

-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] Mercurial conversion repositories

[Tim Delaney]

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".
> >
> > Problem is, you then have 1.5.2 released from the 2.x branch :)
>
> In that case, "legacy-trunk" would seem clearer.


+1

Exactly what I was about to suggest.

Tim Delaney
___
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] Mercurial conversion repositories

[Barry Warsaw]

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 remembered the pull URL for me, as (you guessed it :) Bazaar does.
>
>How does setting it in the hgrc differ from "remebering" it?

It's different because you don't use a familiar interface to set it (i.e hg).
You have to know to hack a file to make it work.  That's not awesome user
interface. ;)

>I've never been comfortable with the bzr --remember option because I'm never
>sure what it is remembering.  Much easier for me to see it in a config file.
>But, then, that's how my brain works, and other people's will work
>differently.

It's easy to tell what it remembers because it's exactly what you told it to
remember ;).  But I guess you're talking about push and pull automatically
remembering the location when none was previously set.  I love that feature.

And of course, bzr 'remembers' by setting a value in a config file, which of
course you *could* hack if you wanted to.  It's just that you don't normally
have to open your editor and remember which value in which config file you
have to manually modify to set the push and pull locations.  I think that's a
win, but YMMV. :)

Oh, and 'bzr info' always tells you what the push and pull locations are.

>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 working copy, and that the repository is *the*
>repository.  That is, it has everything related to the project in it,
>just like the master SVN repository does (plus, since it is a DVCS,
>whatever I've committed locally but not pushed to the master).  To have
>a repository that only has some of the stuff in it is, IMO, confusing.
>I advocated for having all the Python history in one repo partly for
>that reason.

I would feel better about Mercurial's if the repo where not intimately tied
with a default working tree (yes, I know -U).  In a sense, that's what
Bazaar's shared repositories are: a place where all your history goes.  In
Bazaar's model though, it's not tied to a specific working tree, and it's
hidden in a dot-directory.

It's still kind of beside the point - this is the way Mercurial works, and I
don't really mean this thread to be an in-depth comparison between the two.

-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] Mercurial conversion repositories

[Antoine Pitrou]

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 working copy, and that the repository is *the*
> >repository.  That is, it has everything related to the project in it,
> >just like the master SVN repository does (plus, since it is a DVCS,
> >whatever I've committed locally but not pushed to the master).  To have
> >a repository that only has some of the stuff in it is, IMO, confusing.
> >I advocated for having all the Python history in one repo partly for
> >that reason.
> 
> I would feel better about Mercurial's if the repo where not intimately tied
> with a default working tree (yes, I know -U).  In a sense, that's what
> Bazaar's shared repositories are: a place where all your history goes.  In
> Bazaar's model though, it's not tied to a specific working tree, and it's
> hidden in a dot-directory.

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

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

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

[Grigory Javadyan]

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():
 global a
 del(a)

print(a)
x()

it works fine; and when I change the order of calls:

x()
print(a)

I get a NameError, not a SyntaxError.

Now I asked the same question on python-list and people suggested that
the true meaning of that rule is:

>>> 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 _enclosing_ scope. Is there a typo in the documentation
or am I missing something?
___
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] Mercurial conversion repositories

[Barry Warsaw]

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
>> have
>> a 'cpython' directory containing the history of all LoDs, but with a
>> working
>> directory that reflects the 'default' LoD.  Now, in the parent of
>> 'cpython', I
>> do the following to get my separate-directory-LoDs:
>>
>> $ hg clone -u 2.6 cpython py26
>> $ hg clone -u 2.7 cpython py27
>> # repeat and rinse for all other active LoDs
>>
>>
>That's one way of doing it.

I'm sure there are many different ways of setting things up.  I am totally in
favor of the devguide documenting and encouraging one particular way, and I'm
sure Mercurial will prove to be a flexible tool that can conform to user's
preferences rather than the other way 'round.

>> (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
>> a
>> LoD, so why do I have to stare at it?  Yes, I can make it play double duty
>> by
>> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
>> artificial.)
>>
>It's a clone repository of CPython; the name makes perfect sense. You are
>focusing on what the repository happens to be updated to ATM, not the fact
>that the repository itself represents any and all LoDs.

No, I get all that.  I'm just not sure why I should care where all the history
is stored.  I'm not actually going to do any coding in the cpython directory,
so it just seems like a wart I have to carry around.  But as I said before,
this is the Mercurial Way, so be it.

>> Now I want to synchronize my local py27 directory with the state of that
>> LoD
>> on python.org.  This is a two step process:
>>
>> $ cd py27 # now I want to synchronize
>> $ (cd ../cpython && hg pull)
>> $ hg pull -u
>>
>> Editing hgrc to point to hg.python.org means the sync-to-remote-master
>> operation is one command.
>>
>> I could do this:
>>
>> $ 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
>> does.
>>
>
>So does Hg: simply edit your .hgrc to have it both pull and push to the same
>URL.

Right, see my follow up to RDM.

>Or you can save yourself some trouble, and simply clone the repository at a
>specific branch:
>
>  hg clone ssh://h...@hg.python.org/cpython#2.7
>
>I believe that might even strip out other history outside the scope of the
>branch.

That might be a better way if it doesn't slurp down the entire repository
history.

>> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
>> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
>> >branches I was driven nuts by (what I saw as) the conflation between a
>> >branch and a clone.  Later I understood how it made sense from the
>> >perspective of Bazaar, so I shifted my judgment from “insanely
>> >confusing” to “a particular choice that I don’t approve” .
>>
>> That's funny because to my eyes, Mercurial conflates "branches" and
>> "clones".
>> Why a clone operation should give me the history for all
>> lines-of-development
>> inside a working directory for one "arbitrary" one strikes me as bizarre
>> (pardon the pun :).
>
>Because Hg views a clone as that: a clone of the entire repository. A branch
>just happens to be a part of the repository. And because it is the entire
>repository it has to have you point somewhere, so it goes with default since
>a lot of people never even work somewhere other than on default.

Yep, I get all that.  It's Mercurial's model of the world.

>Yes, fun isn't it? Makes me that much more glad I don't have to care about
>other DVCSs anymore; make the decision of which one to go through was
>painful partially for this reason.

Lucky you!  I interact with tons of projects, so I still have to deal with
everything from CVS to git.  This will be my first serious foray into hg, and
for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so I'm
really happy this is finally happening, despite any initial grumbling you're
reading into my posts. :)

>> >> I'll have to remember that 'hg pull' does not update the working copy by
>> >> default,
>> >
>> >That pull does not update is a feature: The operation between a remote
>> >repo and the local repo (the .hg directory) is separate from the
>> >operation from the local repo to the working directory.  When you know
>> >that you want pull + update (like when you have a clean working
>> >directory), you use “hg pull -u”.  (I don’t like the fetch command.)
>>
>> Sure, I get that.  Again, this feature appears odd because I have the full
>> history of all LoDs embedded in a working directory of a single LoD.
>
>Not single, _current_. I know you don't like the 

Re: [Python-Dev] Mercurial conversion repositories

[Barry Warsaw]

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."

:)

-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] Unbinding a name referenced by an enclosing scope - error in documentation?

[Benjamin Peterson]

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 _enclosing_ scope. Is there a typo in the documentation
> or am I missing something?

Actually you can do that now 3.2+. I've now removed that sentence;.



-- 
Regards,
Benjamin
___
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

[Éric Araujo]

> +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.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] Mercurial conversion repositories

[Brett Cannon]

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 the remote repository using the command in the devguide, so I
> now
> >> have
> >> a 'cpython' directory containing the history of all LoDs, but with a
> >> working
> >> directory that reflects the 'default' LoD.  Now, in the parent of
> >> 'cpython', I
> >> do the following to get my separate-directory-LoDs:
> >>
> >> $ hg clone -u 2.6 cpython py26
> >> $ hg clone -u 2.7 cpython py27
> >> # repeat and rinse for all other active LoDs
> >>
> >>
> >That's one way of doing it.
>
> I'm sure there are many different ways of setting things up.  I am totally
> in
> favor of the devguide documenting and encouraging one particular way, and
> I'm
> sure Mercurial will prove to be a flexible tool that can conform to user's
> preferences rather than the other way 'round.
>
> >> (Aside: that cpython directory still bugs me.  It doesn't naturally
> reflect
> >> a
> >> LoD, so why do I have to stare at it?  Yes, I can make it play double
> duty
> >> by
> >> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that
> feels
> >> artificial.)
> >>
> >It's a clone repository of CPython; the name makes perfect sense. You are
> >focusing on what the repository happens to be updated to ATM, not the fact
> >that the repository itself represents any and all LoDs.
>
> No, I get all that.  I'm just not sure why I should care where all the
> history
> is stored.  I'm not actually going to do any coding in the cpython
> directory,
> so it just seems like a wart I have to carry around.  But as I said before,
> this is the Mercurial Way, so be it.
>
> >> Now I want to synchronize my local py27 directory with the state of that
> >> LoD
> >> on python.org.  This is a two step process:
> >>
> >> $ cd py27 # now I want to synchronize
> >> $ (cd ../cpython && hg pull)
> >> $ hg pull -u
> >>
> >> Editing hgrc to point to hg.python.org means the sync-to-remote-master
> >> operation is one command.
> >>
> >> I could do this:
> >>
> >> $ 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
> >> does.
> >>
> >
> >So does Hg: simply edit your .hgrc to have it both pull and push to the
> same
> >URL.
>
> Right, see my follow up to RDM.
>
> >Or you can save yourself some trouble, and simply clone the repository at
> a
> >specific branch:
> >
> >  hg clone ssh://h...@hg.python.org/cpython#2.7
> >
> >I believe that might even strip out other history outside the scope of the
> >branch.
>
> That might be a better way if it doesn't slurp down the entire repository
> history.
>
> >> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >> >branches I was driven nuts by (what I saw as) the conflation between a
> >> >branch and a clone.  Later I understood how it made sense from the
> >> >perspective of Bazaar, so I shifted my judgment from “insanely
> >> >confusing” to “a particular choice that I don’t approve” .
> >>
> >> That's funny because to my eyes, Mercurial conflates "branches" and
> >> "clones".
> >> Why a clone operation should give me the history for all
> >> lines-of-development
> >> inside a working directory for one "arbitrary" one strikes me as bizarre
> >> (pardon the pun :).
> >
> >Because Hg views a clone as that: a clone of the entire repository. A
> branch
> >just happens to be a part of the repository. And because it is the entire
> >repository it has to have you point somewhere, so it goes with default
> since
> >a lot of people never even work somewhere other than on default.
>
> Yep, I get all that.  It's Mercurial's model of the world.
>
> >Yes, fun isn't it? Makes me that much more glad I don't have to care about
> >other DVCSs anymore; make the decision of which one to go through was
> >painful partially for this reason.
>
> Lucky you!  I interact with tons of projects, so I still have to deal with
> everything from CVS to git.  This will be my first serious foray into hg,
> and
> for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so
> I'm
> really happy this is finally happening, despite any initial grumbling
> you're
> reading into my posts. :)
>
> >> >> I'll have to remember that 'hg pull' does not update the working copy
> by
> >> >> default,
> >> >
> >> >That pull does not update is a feature: The operation between a remote
> >> >repo and the local repo (the .hg directory) is separate from the
> >> >operation from the local repo to the working directory.  When you know
> >> >that you want pull + update (lik

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

[Neil Hodgson]

   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 the ScintillaWidget.h changes aren't visible (after a brief
wait) then click on the arrow next to it. There are only 3 real
changed lines in this file (which are changing comments from C++ to C)
but the whole file appears to have been changed.

   This is far from the worst I have seen with some revisions showing
almost every line in a project changed.

   There are several effects from this:
1) The blame command loses usefulness as all lines in the file appear
to be from this revision.
2) Downloads become bigger, and take longer.
3) Fixing the issues takes time, effort and junks the history further.

   Neil
___
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] Mercurial conversion repositories

[Dj Gilcrease]

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@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

[Antoine Pitrou]

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 the hook each time we want to add a new
legitimate branch.  I have no preference really.

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] of branches and heads

[Greg Ewing]

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 won't
let you assign a branch name that's been used before to a node
unless one of its parents has that name. So you can't create
two disconnected subgraphs whose nodes have the same branch
name.

-- 
Greg

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.
___
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] Unbinding a name referenced by an enclosing scope - error in documentation?

[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 you can
assign to names in outer scopes, you should be able to del them
as well.

-- 
Greg

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.
___
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] Unbinding a name referenced by an enclosing scope - error in documentation?

[Benjamin Peterson]

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 you can
> assign to names in outer scopes, you should be able to del them
> as well.

Notice that it's now been changed...


-- 
Regards,
Benjamin
___
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] Mercurial conversion repositories

[Adrian Buehlmann]

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 every time.  It wouldn't be so bad if
>>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.
>>
>> How does setting it in the hgrc differ from "remebering" it?
> 
> It's different because you don't use a familiar interface to set it (i.e hg).
> You have to know to hack a file to make it work.  That's not awesome user
> interface. ;)

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.

And he's quite firm on not wanting to have Mercurial touch .hg/hgrc --
with the single exception being to write a initial .hg/hgrc on 'hg
clone', containing the default path with the location from where the
repo was cloned.

Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
- and always gave up again looking at bzr due to the horrible slowness
of that command. If I have to use a DVCS I want to be able to check the
integrity of my clones in reasonable time. I do it with a cron job on
our internal server here and I expect it to have finished checking all
our repos when I get to my desk in the morning and look into my email
inbox, reading the daily email with the result of the verify runs.

After all, we do have everything secured with hashes, so we can use
them, don't we?

>> I've never been comfortable with the bzr --remember option because I'm never
>> sure what it is remembering.  Much easier for me to see it in a config file.
>> But, then, that's how my brain works, and other people's will work
>> differently.
> 
> It's easy to tell what it remembers because it's exactly what you told it to
> remember ;).  But I guess you're talking about push and pull automatically
> remembering the location when none was previously set.  I love that feature.
> 
> And of course, bzr 'remembers' by setting a value in a config file, which of
> course you *could* hack if you wanted to.  It's just that you don't normally
> have to open your editor and remember which value in which config file you
> have to manually modify to set the push and pull locations.  I think that's a
> win, but YMMV. :)
> 
> Oh, and 'bzr info' always tells you what the push and pull locations are.

You can use 'hg paths' for that:

See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the
command line.

>> 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 working copy, and that the repository is *the*
>> repository.  That is, it has everything related to the project in it,
>> just like the master SVN repository does (plus, since it is a DVCS,
>> whatever I've committed locally but not pushed to the master).  To have
>> a repository that only has some of the stuff in it is, IMO, confusing.
>> I advocated for having all the Python history in one repo partly for
>> that reason.
> 
> I would feel better about Mercurial's if the repo where not intimately tied
> with a default working tree (yes, I know -U).  In a sense, that's what
> Bazaar's shared repositories are: a place where all your history goes.  In
> Bazaar's model though, it's not tied to a specific working tree, and it's
> hidden in a dot-directory.
> 
> It's still kind of beside the point - this is the way Mercurial works, and I
> don't really mean this thread to be an in-depth comparison between the two.

I'm quite surprised indeed to read that much about Bazaar in this thread
here :)
___
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] Mercurial conversion repositories

[Daniel Stutzbach]

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 perspective.

I spent some time on Friday setting up hg-git on my workstation and making a
few test commits.  It took me awhile to figure out how to get everything
working, but it seems to work smoothly now.  At some point I'll update
http://wiki.python.org/moin/Git with instructions.

-- 
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] hg extensions was Mercurial conversion repositories

[Dj Gilcrease]

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 on

File Format Management
eol
http://mercurial.selenic.com/wiki/EolExtension
required

flake8
http://pypi.python.org/pypi/flake8/
recommended especially for new commiters as it will validate
pep8 compliance and check for common errors
*Maybe update it to do pep7 compliance checks on the c files as well?

Patch Management
mq
http://mercurial.selenic.com/wiki/MqExtension
This is the one the devguide uses in examples

rebase
http://mercurial.selenic.com/wiki/RebaseExtension
used with the --collapse option it is very easy to build up a
patch patch with incremental commits, but discard the private history
of the developer
This one makes more sense to me personally then mq and fits
how my standard workflow goes better

shelve
http://mercurial.selenic.com/wiki/ShelveExtension
Store un commited changes away so they dont affect generation
of the patch

transplant
http://mercurial.selenic.com/wiki/TransplantExtension
required to port patches between major versions

record
http://mercurial.selenic.com/wiki/RecordExtension
Allows cherry picking of commits to build a patch, Also works with mq

Crecord
http://mercurial.selenic.com/wiki/CrecordExtension
appears to be a c optimized version or record

Branch Management
bookmarks
http://mercurial.selenic.com/wiki/BookmarksExtension
Great for tracking bug fix work without needing to create a
separate working directory
recommended that the central repo NOT have the extension
enabled so as to ensure bookmarks are a local only tracking system
___
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 extensions (was: Mercurial conversion repositories)

[Éric Araujo]

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 between major versions
That’s actually not clear in the current PEP / devguide.

> record
> http://mercurial.selenic.com/wiki/RecordExtension
> Allows cherry picking of commits to build a patch, Also works with mq
“Cherry-picking“ means “selecting some changesets for pull”, not
“selecting some diff hunks for commit”.

> Crecord
> http://mercurial.selenic.com/wiki/CrecordExtension
> appears to be a c optimized version or record
Not at all.  It has the same functionality as record, only in a curses
UI instead of an unusable line-based interface.

> 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.

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] [Python-checkins] hooks: Fix checkbranch hook

[É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.

>  I have no preference really.
Looks like a ±0 to me :)

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 extensions

[Éric Araujo]

> 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] hg extensions (was: Mercurial conversion repositories)

[Dj Gilcrease]

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#porting-between-major-versions

>
>>     record
>>         http://mercurial.selenic.com/wiki/RecordExtension
>>         Allows cherry picking of commits to build a patch, Also works with mq
> “Cherry-picking“ means “selecting some changesets for pull”, not
> “selecting some diff hunks for commit”.

/shrug to me you cherry pick what you want to commit, shelve the rest,
create your patch then unshelve and continue development. Just a
matter of semantics :)

>
>>     Crecord
>>         http://mercurial.selenic.com/wiki/CrecordExtension
>>         appears to be a c optimized version or record
> Not at all.  It has the same functionality as record, only in a curses
> UI instead of an unusable line-based interface.

Ya I have never used either of them

>
>> 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 and in the dev guide they
use an example of working with only 1 working directory so the
bookmark extension would be useful to people who want to follow that
method of development
___
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 extensions was Mercurial conversion repositories

[Adrian Buehlmann]

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 extension in the configuration -- the feature will be
built-in.
___
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] set iteration order

[Hagen Fürstenau]

> 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 numerical differences due
to different iteration orders). I think we also warn about changes in
pseudorandom number sequences, although you could argue that no code
should depend on specific pseudorandom numbers.

Cheers,
Hagen

___
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] set iteration order

[Éric Araujo]

> 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 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] set iteration order

[Steven D'Aprano]

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 case there were minor numerical differences due
to different iteration orders). 


If those differences are insignificant to you, then why do you care?

If they are significant enough that (say) tests were failing, then your 
results depend on the iteration order of a set, and your code is buggy 
and should be fixed. Or perhaps your tests are too strict.




I think we also warn about changes in
pseudorandom number sequences, although you could argue that no code
should depend on specific pseudorandom numbers.


The random module provides an API for repeating sequences of 
pseudorandom numbers: the seed. So you *can* depend on specific numbers, 
if you need to.


Sets and dicts do not provide any such API. The order even changes with 
the history of the object: two equal sets can have different iteration 
orders.


Personally, I don't care whether or not we mention that set iteration 
order has changed. It seems too trivial to worry much about it.


+0



--
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] hg extensions (was: Mercurial conversion repositories)

[Antoine Pitrou]

> >> 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 and in the dev guide they
> use an example of working with only 1 working directory so the
> bookmark extension would be useful to people who want to follow that
> method of development

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.

(the core issue being that a bookmark blindly follows every commit you
do, while you would need it to follow upstream instead!)

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] set iteration order

[Antoine Pitrou]

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 effect of the optimization might be worth mentioning
> in "What's new", maybe also pointing out that the old behaviour can be
> simulated with {x for x in a if x not in b} in place of "a-b".

I'm against such a mention. It would give the impression that we
support some semblance of reproduceability in iteration order, which is
not true. If you use sets or dicts, you must deal with the fact that
the iteration order will be totally random from your (the programmer's)
POV.

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] hg extensions

[Éric Araujo]

> 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 to follow upstream instead!)

I don’t really understand (I don’t really want to, I don’t care for
bookmarks), but maybe this will help:
http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration

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] Mercurial conversion repositories

[Barry Warsaw]

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 the speed of 'bzr check'
>- and always gave up again looking at bzr due to the horrible slowness
>of that command. If I have to use a DVCS I want to be able to check the
>integrity of my clones in reasonable time. I do it with a cron job on
>our internal server here and I expect it to have finished checking all
>our repos when I get to my desk in the morning and look into my email
>inbox, reading the daily email with the result of the verify runs.
>
>After all, we do have everything secured with hashes, so we can use
>them, don't we?

Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
or felt the need to. ;)

>> Oh, and 'bzr info' always tells you what the push and pull locations are.
>
>You can use 'hg paths' for that:

Nice, thanks.

-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 extensions

[Antoine Pitrou]

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 be surprised if its change
tracking abilities were so poor.

> > (the core issue being that a bookmark blindly follows every commit you
> > do, while you would need it to follow upstream instead!)
> 
> I don’t really understand (I don’t really want to, I don’t care for
> bookmarks), but maybe this will help:
> http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration

That's vaguely better (since it allows to advance one bookmark instead
of both), but it still doesn't allow tracking incoming upstream changes.
Meaning that as soon as I "hg pull" (not to mention "hg merge"), I lose
the ability to easily make a collapsed diff of my local changes.

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] hg extensions was Mercurial conversion repositories

[Antoine Pitrou]

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 needed, we can even
refuse individual changesets).  In most situations, even without the
eol extension line endings won't get modified anyway.

> flake8
> http://pypi.python.org/pypi/flake8/
> recommended especially for new commiters as it will validate
> pep8 compliance and check for common errors

IMHO, nothing replaces human reviews and communication for style
and other likewise issues.

> Patch Management
> mq
> rebase
> shelve

All these depend on each developer's taste, as long as only collapsed
patches get submitted and committed.

> transplant
> http://mercurial.selenic.com/wiki/TransplantExtension
> required to port patches between major versions

Not really required, and actually controversial since it commits
automatically (we would like people to commit and test *before*
committing, otherwise buildbots can get bogus changesets and spurious
failures).

> bookmarks
> http://mercurial.selenic.com/wiki/BookmarksExtension
> Great for tracking bug fix work without needing to create a
> separate working directory
> recommended that the central repo NOT have the extension
> enabled so as to ensure bookmarks are a local only tracking system

Actually quite poor for tracking bug fix work (see my other messages in
this thread :-)).

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] Mercurial conversion repositories

[Adrian Buehlmann]

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. :)

Yep.

>> Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
>> - and always gave up again looking at bzr due to the horrible slowness
>> of that command. If I have to use a DVCS I want to be able to check the
>> integrity of my clones in reasonable time. I do it with a cron job on
>> our internal server here and I expect it to have finished checking all
>> our repos when I get to my desk in the morning and look into my email
>> inbox, reading the daily email with the result of the verify runs.
>>
>> After all, we do have everything secured with hashes, so we can use
>> them, don't we?
> 
> Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
> or felt the need to. ;)

That's quite amazing. If I talk with people about that, it often turns
out that they don't check the integrity of their repos.

Well, hg verify *is* through and fast enough. That's good enough for me.

And being slow is not sufficient to earn my trust.

FWIW, be aware that Mercurial does not do integrity checks on normal
operations, so chances are you will be able to use a repo that fails
verify for quite a while -- without even noticing it.

For example you can remove *some* file X inside .hg/store/data and
continue to add history to that repo without any sign of errors, as long
as the file X isn't used during the operations you do.
___
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] set iteration order

[Raymond Hettinger]

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 order shouldn't be relied on in the first
>> place, but the side effect of the optimization might be worth mentioning
>> in "What's new", maybe also pointing out that the old behaviour can be
>> simulated with {x for x in a if x not in b} in place of "a-b".
> 
> I'm against such a mention. It would give the impression that we
> support some semblance of reproduceability in iteration order, which is
> not true. If you use sets or dicts, you must deal with the fact that
> the iteration order will be totally random from your (the programmer's)
> POV.

I concur with Antoine.

Also, it wasn't the iteration order that changed; sets still iterate in the 
same order.
What changed was the algorithm for creating a new set using a set difference 
operation.

Raymond
___
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] hg commit with diff -u output (was Re: hg extensions was Mercurial conversion repositories)

[Barry Warsaw]

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 parameters
# only for Mercurial, modify this:
case "${EDITOR}" in
"")
EDITOR="sensible-editor"
;;
emacs)
EDITOR="$EDITOR -nw"
;;
gvim|vim)
EDITOR="$EDITOR -f -o"
;;
esac


HGTMP=""
cleanup_exit() {
rm -rf "$HGTMP"
}

# Remove temporary files even if we get interrupted
trap "cleanup_exit" 0 # normal exit
trap "exit 255" HUP INT QUIT ABRT TERM

HGTMP=$(mktemp -d ${TMPDIR-/tmp}/hgeditor.XX)
[ x$HGTMP != x -a -d $HGTMP ] || {
  echo "Could not create temporary directory! Exiting." 1>&2
  exit 1
}

(
grep '^HG: changed' "$1" | cut -b 13- | while read changed; do
"$HG" diff "$changed" >> "$HGTMP/diff"
done
)

cat "$1" > "$HGTMP/msg"
LINES=`wc -l $HGTMP/msg`
echo "" >> "$HGTMP/msg"
cat "$HGTMP/diff" >> "$HGTMP/msg"

MD5=$(which md5sum 2>/dev/null) || MD5=$(which md5 2>/dev/null)
[ -x "${MD5}" ] && CHECKSUM=`${MD5} "$HGTMP/msg"`
$EDITOR "$HGTMP/msg" || exit $?

if [ -x "${MD5}" ]
then
echo "$CHECKSUM" | ${MD5} -c >/dev/null 2>&1 && exit 13
fi

cat "$HGTMP/msg" | head -n $LINES > "$HGTMP/commit"
mv "$HGTMP/commit" "$1"

exit $?


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 extensions was Mercurial conversion repositories

[Martin v. Löwis]

> 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 optimistic. Visual Studio will break all your
files if you don't use that extension (and you actually use it to
modify source code).

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