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
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
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://hg.python.org/cpython/rev/41071f447b15
changeset: 68041:41071f447b15
branch: trunk
tag: tip
parent: 62750:800f6c92c3ed
user:Georg Brandl ge...@python.org
date:Sat Feb 26 07:48:21 2011 +0100
summary:
Close the trunk branch.
What's the effect of
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
Ezio Melotti ezio.melotti at 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
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.
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
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
Antoine Pitrou wrote:
On Sat, 26 Feb 2011 12:32:04 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
$ hg branches
default68026:f12ef116dd10
3.268025:cef92ee1a323
2.7
On Sat, Feb 26, 2011 at 10:52 PM, cool-RR cool...@cool-rr.com 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
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
On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.net 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
On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de 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.
Hi
On Sat, Feb 26, 2011 at 12:52 PM, cool-RR cool...@cool-rr.com 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
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 mar...@v.loewis.de 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
On Sat, Feb 26, 2011 at 4:39 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Feb 26, 2011 at 10:52 PM, cool-RR cool...@cool-rr.com wrote:
Hello,
I noticed that the `TemporaryDirectory` context manager creates the
folder
on `__init__` rather than on `__enter__`, resulting in complexity,
On Sun, 27 Feb 2011 00:39:16 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Feb 26, 2011 at 10:52 PM, cool-RR cool...@cool-rr.com wrote:
Hello,
I noticed that the `TemporaryDirectory` context manager creates the folder
on `__init__` rather than on `__enter__`, resulting in complexity,
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 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öwismar...@v.loewis.de wrote:
I think people should simply get used to the idea that default is
/the/ main branch in Mercurial (*). It's
On Sat, 26 Feb 2011 15:44:08 +0100
Antoine Pitrou solip...@pitrou.net 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 mar...@v.loewis.de
wrote:
I think people should simply get used to the idea that default is
On Sun, Feb 27, 2011 at 12:40 AM, Éric Araujo mer...@netwok.org 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
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
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
Am 26.02.2011 15:42, schrieb Nick Coghlan:
On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de 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,
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
On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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
Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit :
On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com
wrote:
Would it be possible to name trunk as 2.x instead?
Otherwise I
could see people getting confused and asking why trunk was
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
On Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou
python-check...@python.org 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
On Sat, 26 Feb 2011 17:49:32 +0100
Éric Araujo mer...@netwok.org 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
On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou solip...@pitrou.net 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
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,
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
On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net 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
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
Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit :
On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a
écrit :
Can we just get rid of trunk altogether? It's
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 ncogh...@gmail.com
wrote:
Would it be possible to name trunk as 2.x instead?
Otherwise I
could see people
On Sat, 26 Feb 2011 18:48:17 +0100
martin.v.loewis python-check...@python.org 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,
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 ncogh...@gmail.com
wrote:
Would it be possible to name
Am 26.02.2011 18:54, schrieb Antoine Pitrou:
On Sat, 26 Feb 2011 18:48:17 +0100
martin.v.loewis python-check...@python.org 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
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
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
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,
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
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
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
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
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
On Sun, Feb 27, 2011 at 3:45 AM, cool-RR cool...@cool-rr.com 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
On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@pitrou.net 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.
A Mercurial 'merge' http://mercurial.selenic.com/wiki/Branch 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 ba...@python.org wrote:
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
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org 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
On Sat, 26 Feb 2011 10:40:03 -0800
Daniel Stutzbach stutzb...@google.com wrote:
On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@pitrou.net 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
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 mar...@v.loewis.de wrote:
Am 26.02.2011 19:13, schrieb Antoine Pitrou:
In Mercurial, it's just a
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 solip...@pitrou.net wrote:
On Fri, 25 Feb 2011 18:02:43 +0100 (CET)
vinay.sajip python-check...@python.org wrote:
On Fri, Feb 25, 2011 at 13:46, Barry Warsaw ba...@python.org 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
On Sat, Feb 26, 2011 at 10:08, Barry Warsaw ba...@python.org 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
On 27 February 2011 03:02, Martin v. Löwis mar...@v.loewis.de 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
On 27 February 2011 05:12, Barry Warsaw ba...@python.org 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,
On 27 February 2011 05:23, Martin v. Löwis mar...@v.loewis.de 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
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
On 27 February 2011 01:40, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.net 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
On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org 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
On Sat, 26 Feb 2011 16:06:45 -0500
Barry Warsaw ba...@python.org 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
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
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
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
2011/2/26 Grigory Javadyan grigory.javad...@gmail.com:
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_
+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
On Sat, Feb 26, 2011 at 13:30, Barry Warsaw ba...@python.org 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
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
On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon br...@python.org 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
On Sat, 26 Feb 2011 22:36:47 +0100
Éric Araujo mer...@netwok.org 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
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
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,
2011/2/26 Greg Ewing greg.ew...@canterbury.ac.nz:
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
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 ba...@python.org 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
On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon br...@python.org 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
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
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
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
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
On Sat, Feb 26, 2011 at 6:19 PM, Éric Araujo mer...@netwok.org 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.
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
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
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
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
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
On Sat, 26 Feb 2011 10:09:33 +0100
Hagen Fürstenau ha...@zhuliguan.net 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
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
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
On Sun, 27 Feb 2011 01:25:12 +0100
Éric Araujo mer...@netwok.org 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
Hi,
On Sat, 26 Feb 2011 18:13:15 -0500
Dj Gilcrease digitalx...@gmail.com 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
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. :)
On Feb 26, 2011, at 4:09 PM, Antoine Pitrou wrote:
On Sat, 26 Feb 2011 10:09:33 +0100
Hagen Fürstenau ha...@zhuliguan.net 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
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
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
changeset: 72694:e65daae6cf44
user:Antoine Pitrou solip...@pitrou.net
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
1 - 100 of 104 matches
Mail list logo
