On Thu, 20 Jan 2011 15:59:39 +0200
Nadeem Vawda wrote:
> On Thu, Jan 20, 2011 at 3:11 PM, Antoine Pitrou wrote:
> > On Thu, 20 Jan 2011 10:47:04 +0100 (CET)
> > raymond.hettinger wrote:
> >>
> >> +Code Repository
> >> +===
> >>
On Thu, 20 Jan 2011 21:09:47 +0100
"M.-A. Lemburg" wrote:
> brett.cannon wrote:
> > Author: brett.cannon
> > Date: Thu Jan 20 20:34:35 2011
> > New Revision: 88127
> >
> > Log:
> > Remove some outdated files from Misc.
> >
> > Removed:
> >python/branches/py3k/Misc/README.AIX
>
> Are you sur
On Thu, 20 Jan 2011 15:27:08 -0500
Glyph Lefkowitz wrote:
>
> To support the latter, could we just make sure that zipimport has a
> consistent,
> non-locale-or-operating-system-dependent interpretation of encoding?
It already has, but it's dependent on a flag in the zip file itself
(actually, o
On Thu, 20 Jan 2011 22:25:17 -0500
James Y Knight wrote:
>
> On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote:
>
> > On Thu, 20 Jan 2011 15:27:08 -0500
> > Glyph Lefkowitz wrote:
> >>
> >> To support the latter, could we just make sure that zipimport
On Thu, 20 Jan 2011 22:16:36 -0500
James Y Knight wrote:
>
> On Jan 20, 2011, at 9:31 PM, Ezio Melotti wrote:
> >> Modified: peps/trunk/pep-.txt
> >> ==
> >> --- peps/trunk/pep-.txt (original)
> >> +++ peps/tr
On Fri, 21 Jan 2011 08:23:31 -0500
James Y Knight wrote:
> >
> > I think most mail readers are able to word-wrap raw text correctly
> > (even though it still makes your messages look bad amongst a thread of
> > nicely-formatted 80-column messages).
> > The real annoyance is when reading Web archi
On Sat, 22 Jan 2011 14:04:00 -0500
Terry Reedy wrote:
> The 3.x docs mostly started fresh with 3.0. The major exception is the
> What's new section, which goes back to 2.0. The 2.x stuff comprises
> about 650KB in the repository and whatever that translates into in the
> distribution. I cannot
On Sun, 23 Jan 2011 18:12:26 +0100 (CET)
antoine.pitrou wrote:
> Author: antoine.pitrou
> Date: Sun Jan 23 18:12:25 2011
> New Revision: 88147
>
> Log:
> Issue #10987: Fix the recursion limit handling in the _pickle module.
I forgot to mention that it was ok'ed by Georg, so there it is.
Regards
On Sun, 23 Jan 2011 18:45:50 -0500
Terry Reedy wrote:
> On 1/23/2011 1:58 PM, Antoine Pitrou wrote:
>
> >> Issue #10987: Fix the recursion limit handling in the _pickle module.
>
> 12 hours after the report!
>
> I am still curious why a previous exception changed p
On Mon, 24 Jan 2011 01:28:26 +0100
"Martin v. Löwis" wrote:
>
> I wonder whether we could sprinkle more exception-set? checks in
> the interpreter loop, at least in debug mode.
Yes, this would be nice. Nicer if it can be centralized, of course.
That said, it probably wouldn't have helped here, s
On Mon, 24 Jan 2011 20:33:07 +1000
Nick Coghlan wrote:
> On Mon, Jan 24, 2011 at 6:22 AM, Brett Cannon wrote:
> >> In "Getting Set Up" it describes how to build a pydebug build. Is that
> >> really necessary for those who plan only to contribute by working on
> >> pure Python code?
> >>
> >
> > Y
On Mon, 24 Jan 2011 07:56:56 -0600
"Earney, Billy C." wrote:
> Greetings!
>
> I know that this list is for python development questions/comments, but I
> wanted to bring up the tahoe-lafs project [...]
You should really post such messages to comp.lang.python.
_
On Sat, 22 Jan 2011 17:08:00 -0800
Brett Cannon wrote:
>
> Two, what should the final URL be? Georg picked the current one and I
> am happy with it.
Ditto for me.
> Three, where should it be linked from? docs.python.org homepage?
> Four, what to do with www.python.org/dev/? Redirect for all the
On Mon, 24 Jan 2011 11:46:45 -0800
Raymond Hettinger wrote:
>
> This isn't a critical issue (nothing is broken) but we're a week from another
> release candidate, so the new Py3.2 package organization (unittest was flat
> in Py3.1 and its test were under Lib/test) is about to become a de-facto
On Mon, 24 Jan 2011 21:17:34 +0100
"Martin v. Löwis" wrote:
> I have been thinking about Unicode representation for some time now.
> This was triggered, on the one hand, by discussions with Glyph Lefkowitz
> (who complained that his server app consumes too much memory), and Carl
> Friedrich Bolz (
Le mardi 25 janvier 2011 à 00:07 +0100, "Martin v. Löwis" a écrit :
> >> I'd like to propose PEP 393, which takes a different approach,
> >> addressing both problems simultaneously: by getting a flexible
> >> representation (one that can be either 1, 2, or 4 bytes), we can
> >> support the full ran
Le mardi 25 janvier 2011 à 00:14 +0100, "Martin v. Löwis" a écrit :
> >> This isn't a critical issue (nothing is broken) but we're a week
> >> from another release candidate, so the new Py3.2 package
> >> organization (unittest was flat in Py3.1 and its test were under
> >> Lib/test) is about to be
On Tue, 25 Jan 2011 01:00:28 +0100 (CET)
benjamin.peterson wrote:
> Author: benjamin.peterson
> Date: Tue Jan 25 01:00:28 2011
> New Revision: 88178
>
> Log:
> another pretty crasher served up by pypy
Some comments would be nice. Right now it looks pretty close to
deliberately obfuscated code (e
Le mardi 25 janvier 2011 à 20:11 +0200, Maciej Fijalkowski a écrit :
> On Tue, Jan 25, 2011 at 1:26 PM, Antoine Pitrou wrote:
> > On Tue, 25 Jan 2011 01:00:28 +0100 (CET)
> > benjamin.peterson wrote:
> >> Author: benjamin.peterson
> >> Date: Tue Jan 25 01:00
For the record:
> I also don't see how this could save a lot of memory. As an example
> take a French text with say 10mio code points. This would end up
> appearing in memory as 3 copies on Windows: one copy stored as UCS2 (20MB),
> one as Latin-1 (10MB) and one as UTF-8 (probably around 15MB, de
On Tue, 25 Jan 2011 21:08:01 +1000
Nick Coghlan wrote:
>
> One change I would propose is that rather than hiding flags in the low
> order bits of the str pointer, we expand the use of the existing
> "state" field to cover the representation information in addition to
> the interning information.
Le mercredi 26 janvier 2011 à 21:50 -0800, Gregory P. Smith a écrit :
> >
> > Incidentally, to slightly reduce the overhead the unicode objects,
> > there's this proposal: http://bugs.python.org/issue1943
>
> Interesting. But that aims more at cpu performance than memory
> overhead. What I see i
> > Incidentally, to slightly reduce the overhead the unicode objects,
> > there's this proposal: http://bugs.python.org/issue1943
>
> I wonder what aspects of this patch and discussion should be integrated
> into the PEP. The notion of allocating the memory in the same block is
> already conside
On Sat, 29 Jan 2011 11:00:48 +0100
Stefan Behnel wrote:
>
> I know, that's not what I meant. But this PEP would enable a C API that
> provides direct access to the underlying buffer. Just as is currently
> provided for the Py_UNICODE array, but with a stable ABI because the buffer
> type won't
Hello,
> I'm pretty sure the best long term fix is to move the kill processing
> into the clean script (as per issue 9973) rather than where it
> currently is in the build script, but so far I don't think the idea
> has been able to attract the interest of anyone who can actually
> commit such a
On Mon, 31 Jan 2011 00:08:25 -0800
Guido van Rossum wrote:
>
> (Basically I am biased to believe that stat() is a pretty slow system
> call -- this may just be old NFS lore though.)
I don't know about NFS, but starting a Python interpreter located on a
Samba share from a Windows VM is quite slow
On Mon, 31 Jan 2011 13:28:39 +0100
"Jurjen N.E. Bos" wrote:
> I just did it: my first python source code hack.
> I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to
> short pointer, and lo and behold, a crude measurement indicates one
> to two percent speed increase.
> That is
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
> I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
> more beneficial to development as it doesn't require switching from
> console to browser for submitting changes.
Ok, why don't you contribute to Mercurial instea
On Mon, 31 Jan 2011 23:50:18 +0200
anatoly techtonik wrote:
> On Mon, Jan 31, 2011 at 10:54 PM, Antoine Pitrou wrote:
> > On Mon, 31 Jan 2011 20:45:45 +
> > techto...@gmail.com wrote:
> >> I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
On Wed, 2 Feb 2011 12:04:44 +0100
Sandro Tosi wrote:
> > +Security
> > +
> > +A branch less than five years old but no longer in maintenance mode.
> > +
> > +The only changes made to a branch that is being maintained for security
> > +purposes are somewhat obviously those related to securi
On Thu, 03 Feb 2011 21:52:40 +0100
Victor Stinner wrote:
> Le jeudi 03 février 2011 à 12:22 -0500, Reid Kleckner a écrit :
> > On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner
> > wrote:
> > > - SIGABRT is not handled
> >
> > Why not?
>
> Just because I forgot to handle it. But I don't know if i
On Sat, 5 Feb 2011 18:39:21 +
Paul Moore wrote:
> I've not seen any python-dev mails for a day or so. Is there a problem
> with the list?
I think it's just that nobody posted.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Sun, 06 Feb 2011 02:10:15 +0100
brett.cannon wrote:
>
> To create your patch, you should generate a unified diff from your checkout's
> top-level directory::
>
> -svn diff > patch.diff
> +hg outgoing --path > patch.diff
Should be --patch.
The problem is that it will show one seve
On Sun, 06 Feb 2011 19:10:37 +0100
Éric Araujo wrote:
> Le 06/02/2011 17:15, Antoine Pitrou a écrit :
> > On Sun, 06 Feb 2011 02:10:15 +0100
> > brett.cannon wrote:
> >> To create your patch, you should generate a unified diff from your
> >> che
On Mon, 07 Feb 2011 13:26:28 +0100
Georg Brandl wrote:
> Am 06.02.2011 21:13, schrieb Brett Cannon:
>
> >>> To undo a patch, you can revert **all** changes made in your checkout::
> >>>
> >>> -svn revert -R .
> >>> +hg revert --all
> >>> +
> >>
> >> Or "hg revert -a", which is nicer to t
On Mon, 07 Feb 2011 13:27:31 +
Michael Foord wrote:
> On 07/02/2011 12:25, Georg Brandl wrote:
> > Am 07.02.2011 00:21, schrieb Nick Coghlan:
> >> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote:
> >>> I would rather not have new hg users have to install an extension just
> >>> to get a si
On Mon, 07 Feb 2011 14:34:35 +
Michael Foord wrote:
> >>>
> >> And from the description it sounds like rdiff will be very useful for
> >> our usecase.
> > I'm not sure it is really. When you commit multiple changesets
> > locally you really want to use something like named branches or mq to
>
On Sun, 6 Feb 2011 12:13:08 -0800
Brett Cannon wrote:
> >
> > We could perhaps present SVN-like "work in the working copy" workflow
> > (without local commits), and let seasoned hg users choose other
> > workflows they like more (they don't need our help anyway).
>
> I would rather give people so
On Wed, 09 Feb 2011 10:37:11 +
Mark Shannon wrote:
> >
> > Why redundant?
>
> Because they are all attribute getter and setters. For example:
>
> PyUnicodeDecodeError_GetStart(exc, x) <=>
> PyObject_GetAttr(exc, "start", x)
>
> This sort of redundancy seems sensible for list, tuple and suc
On Wed, 09 Feb 2011 12:11:43 +
Mark Shannon wrote:
> Various others have been added:
>
> int Py_EnterRecursiveCall(char *where)
> void Py_LeaveRecursiveCall()
> int Py_ReprEnter(PyObject *object)
> void Py_ReprLeave(PyObject *object)
Again, they haven't been "added". They have been there for
On Wed, 09 Feb 2011 14:13:11 -
exar...@twistedmatrix.com wrote:
> >And, since the C API has never been anywhere near as tightly
> >controlled as the language definition, alternative implementations are
> >going to garner more sympathy if they restrict their concerns to the
> >growth of the stab
On Wed, 09 Feb 2011 21:17:51 +0100
brett.cannon wrote:
>
>
> -One should always work from a checkout of the CPython source code. While it
> may
> +One should always work from a working copy of the CPython source code.
> +While it may
> be tempting to work from the downloaded copy you already
> >
> >> -To get a read-only checkout of CPython's source, you need to checkout the
> >> source
> >> -code. To get a read-only checkout of
> >> +To get a read-only checkout of CPython's source, you need a working copy
> >> the
> >> +source code. To get a read-only checkout of
> >
> > Why talk ab
>
> Please, don't just document all these.
> Don't add them to the API, unless they are really needed.
We only add functions when they are actually needed (by us, usually).
> I'm not picking on PySys_FormatStderr, or its author here,
> I'm just using it as an example, it seems fairly typical.
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy wrote:
> On 2/11/2011 4:29 AM, Mark Shannon wrote:
> > Nick Coghlan wrote:
>
> >> Now that the issue has been brought up, it can certainly be taken into
> >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
> >> even more restric
On Fri, 11 Feb 2011 10:11:54 -0800
Daniel Stutzbach wrote:
> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote:
> >
> > And finally remember that asyncore is the most monkey-patched module
> > in the world. :-)
>
>
> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
W
On Sat, 12 Feb 2011 22:42:41 +0100
Éric Araujo wrote:
> > antoine.pitrou pushed f22bac464e11 to devguide:
> > summary:
> > Comment out the "make patchcheck" advice, since it doesn't work for a
> > non-SVN workflow.
>
> patchcheck should work after
> http://svn.python.org/view?view=rev&revision=
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
> Nick Coghlan wrote:
>
> > Flawed API + popularity = years of fun*
>
> So maybe it's time to design a new module with a better API
> and deprecate the old one?
That's called Twisted.
___
Python-D
On Sun, 13 Feb 2011 19:18:52 +1000
Nick Coghlan wrote:
>
> If there is an essential subset of the API that the Twisted devs think
> would be a suitable replacement for asyncore, while providing a more
> straightforward migration path into Twisted itself, then it certainly
> makes sense to include
> It would then be subject to python-dev development policy rather than
> twisted dev policy (which is even stricter!). Would the twisted devs
> *really* want that? We could use the same processes we have for
> "externally maintained" libraries, but they have without fail caused us
> problems.
On Sun, 13 Feb 2011 14:47:01 +
Alexis Métaireau wrote:
>
> * Is it possible to give me the rights to edit the reports for the
> distutils2 component ?
Done. Actually, you have general developer rights, since there doesn't
seem to be a way (in the GUI) to restrict those to a specific componen
On Wed, 16 Feb 2011 10:52:16 -0800
Brett Cannon wrote:
> On Wed, Feb 16, 2011 at 09:34, Terry Reedy wrote:
> > I would like the next release called 3.2.0 rather than just 3.2.
> >
> > 'x.y' is known to be ambiguous and confusing.
> >
> > In most actual usages, I believe, it refers to the latest
On Sat, 19 Feb 2011 23:07:17 +1000
Nick Coghlan wrote:
>
> While this is definitely untidy, it doesn't strike me as a release
> blocker. More of a "fix it in 3.2.1", since the status quo will
> *work*, it just means the precompiled file will be ignored on first
> execution with newer Python versi
On Fri, 18 Feb 2011 08:09:12 +0100
Dirkjan Ochtman wrote:
> On Fri, Feb 18, 2011 at 00:17, "Martin v. Löwis" wrote:
> > I think it's fair to say that the project currently rests, lacking
> > a project lead. The most recent timeline is that conversion should
> > be completed by PyCon, and, failing
Le samedi 19 février 2011 à 14:27 +0100, "Martin v. Löwis" a écrit :
> Am 19.02.2011 14:14, schrieb Antoine Pitrou:
> > On Sat, 19 Feb 2011 23:07:17 +1000
> > Nick Coghlan wrote:
> >>
> >> While this is definitely untidy, it doesn't strike me as a
On Tue, 22 Feb 2011 13:14:18 +0100
Jesus Cea wrote:
>
> This seems to be a bug in Python 3.2. Any suggestion?.
Report an issue and investigate :)
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
On Tue, 22 Feb 2011 11:06:41 -0800
Guido van Rossum wrote:
> >
> > Probably because (a) the person who first wrote them used char* instead of
> > const char*, and (b) it gives us API flexibility by not promising to not
> > alter the char array at some point in the future.
>
> I'm sorry, but (b) d
On Tue, 22 Feb 2011 21:48:51 +0100
Stefan Behnel wrote:
> Reid Kleckner, 22.02.2011 21:21:
> > On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
> >> Also changing it now would be a giant hassle, leading to so-called "const
> >> poisoning" where many, many APIs need to be changed before everythin
On Wed, 23 Feb 2011 07:52:23 +1000
Nick Coghlan wrote:
> On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote:
> > The very long term view is for %-formatting to go away, but that's as far as
> > the thinking has gone. There are currently no plans to introduce any
> > deprecation warning, and I h
On Tue, 22 Feb 2011 18:08:01 -0500
Alexander Belopolsky wrote:
> On Mon, Feb 21, 2011 at 6:34 PM, David Claridge wrote:
> ..
> > I was wondering if there is some reason why C API functions like
> > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
> > rather than const char*s?
>
Le mardi 22 février 2011 à 18:30 -0500, Alexander Belopolsky a écrit :
> On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou wrote:
> ..
> > I don't think it's a good idea to backport visible API changes.
> > (someone successfully compiling on 2.7.N could then hav
Hello,
I think it was a slight mistake to remove the link to the issue tracker
from the sidebar in the "core development" section. Dave Beazley just
complained about it
(http://twitter.com/dabeaz/status/40397577916661760) and I think it
will probably confuse other people too. Could we add it back
On Wed, 23 Feb 2011 10:30:54 -0800
Brett Cannon wrote:
> I won't add the link back, but I will try to change the global link on the
> website to point to the devguide. python.org/dev/ at this point exists
> purely to not break pre-existing links.
There are items there that are out of scope for th
On Wed, 23 Feb 2011 11:21:58 -0800
Brett Cannon wrote:
> On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou wrote:
>
> > On Wed, 23 Feb 2011 10:30:54 -0800
> > Brett Cannon wrote:
> > > I won't add the link back, but I will try to change the global link on
>
Hello,
Georg and I have been working on converting the SVN repository to
Mercurial. We can now present you a test repository (actually, two).
CPython repository: http://hg.python.org/cpython/
--
This is the main conversion repository. It contains all history of
trunk and py3k (
On Fri, 25 Feb 2011 19:13:49 +1100
Neil Hodgson wrote:
>With hg 1.7.5 on Windows 7 I performed a non-core checkout:
>
> hg clone http://hg.python.org/cpython
>
>The eol extension is enabled in global settings.
Yes, please try to disable it. The issue is we have a .hgeol in the
repositor
On Thu, 24 Feb 2011 17:39:40 -0800
Brett Cannon wrote:
> >
> > Your clone will contain the following branches:
> >
> >$ hg branches
> >default68026:f12ef116dd10
> >3.268025:cef92ee1a323
> >2.768010:8174d00d0797
> >
Hi Barry,
> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
>
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/proje
On Fri, 25 Feb 2011 13:52:58 +0100
Antoine Pitrou wrote:
> On Fri, 25 Feb 2011 19:13:49 +1100
> Neil Hodgson wrote:
> >With hg 1.7.5 on Windows 7 I performed a non-core checkout:
> >
> > hg clone http://hg.python.org/cpython
> >
> >The eol ext
On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
giampaolo.rodola wrote:
> +#else
> +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> +: PyLong_AsLong(arg);
> +#endif
There's something fishy here. Why would you call PyLong_AsLong() if
PyLong_Check() is false?
Regards
Anto
Le vendredi 25 février 2011 à 20:11 +0200, Ross Lagerwall a écrit :
> On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote:
> > On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
> > giampaolo.rodola wrote:
> >
> > > +#else
> > > +*((off_t*)addr) = Py
On Fri, 25 Feb 2011 18:10:28 + (UTC)
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?
Not really, bu
On Fri, 25 Feb 2011 14:43:15 -0500
Barry Warsaw wrote:
>
> I'll have to remember that 'hg pull' does not update the working copy by
> default, and eventually I'll figure out the whole merge thing.
You can use "hg pull -u" to update (and "hg pull -uv" if you want to
see the list of updated files)
Le samedi 26 février 2011 à 08:40 +1100, Neil Hodgson a écrit :
> Antoine Pitrou:
>
> > It should now be fixed in current SVN, meaning the final conversion
> > should be perfectly usable with the eol extension enabled.
>
>Good.
>
> > Do you find other iss
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
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
> > default 68026:f12ef116dd10
> > 3.2 68025:cef92ee1a323
> > 2.7
Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit :
> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote:
> >> I think people should simply get used to the idea that "default" is
> >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
> >> ("trunk" sounds a b
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 `
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 &qu
Le samedi 26 février 2011 à 17:02 +0100, "Martin v. Löwis" a écrit :
> > Committing reopened it
>
> So what's the point of closing it, then? What effect does that
> achieve?
Again, as I said, it doesn't get displayed anymore with the standard
commands "hg branches" and "hg heads".
Consider it a c
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,
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?
> >
> > Na
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&quo
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
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:
>
> 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,
nnamed 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:e65daae6c
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 wh
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 Merc
On Sat, 26 Feb 2011 16:06:45 -0500
Barry Warsaw wrote:
>
> >I find bazaar's model confusing, and hg's intuitive, just like Éric.
> >And consider that I learned bazaar before mercurial. To me, it makes
> >perfect sense that in a DVCS the "unit" is a directory containing
> >a repository and a wor
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
> >> 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
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
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
Hi,
On Sat, 26 Feb 2011 18:13:15 -0500
Dj Gilcrease wrote:
>
> File Format Management
> eol
> http://mercurial.selenic.com/wiki/EolExtension
> required
Actually, it isn't *required* on each developer's setup, since we
now have a hook that refuses bogus changegroups (if need
On Sun, 27 Feb 2011 08:09:21 +0100
"Martin v. Löwis" wrote:
> >> changeset: 72694:e65daae6cf44
> >> user:Antoine Pitrou
> >> date:Mon Feb 21 21:30:55 2011 +
> >> summary: Try s/UINT_MAX/INT_MAX/
> >
> > It'
On Sun, 27 Feb 2011 07:46:51 +0100
"Martin v. Löwis" wrote:
> > 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 l
On Sun, 27 Feb 2011 04:17:06 +0100
eric.araujo wrote:
> Advertise hg import over patch.
>
> hg import understands the extended git diff format, which supports renames,
> changes to the executable bit and changes in binary files.
Yes, but it's too easy to forget the awkward "--no-commit" option
On Sun, 27 Feb 2011 04:17:07 +0100
eric.araujo wrote:
> summary:
> patchcheck does work
How does it find out which changesets it should operate on?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Sun, 27 Feb 2011 04:17:09 +0100
eric.araujo wrote:
>
> - Move a link target after its use
> - Add a todo about tracker markup
> - Remove one XXX that was in a warning block, not a comment
Well, this is a XXX because that means we could find something else to
advocate, not because the reader m
3301 - 3400 of 4909 matches
Mail list logo
