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 <benjamin(a)python.org>
>date: Sat Feb 26 12:06:36 2011 -0600
>summary:
> improve license
>
>files:
> LICENSE
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 Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou
<python-checkins(a)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 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 | ncoghlan(a)gmail.com | Brisbane, Australia
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
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;
}
> http://hg.python.org/cpython/rev/41071f447b15
> changeset: 68041:41071f447b15
> branch: trunk
> tag: tip
> parent: 62750:800f6c92c3ed
> user: Georg Brandl <georg(a)python.org>
> 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
> After migration
> ===============
>
> +* set up automatic installation of changes to ssh keys, decide upon
> + account managers
I would like account managers to be decided before the conversion.
I personally won't be available as an account manager anymore. The new
account managers are then, of course, free to establish any workflow
they deem appropriate.
> +* adapt build identification for Windows build process
I think this should also be done before the migration.
Regards,
Martin