Am 04.07.2010 22:45, schrieb Jesse Noller:
> On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé wrote:
>> On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
>>> On 4 July 2010 17:02, Benjamin Peterson wrote:
Now that Python 2.7 is out, I'd like to thank a few of the people who
made it possible
On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé wrote:
> On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
>> On 4 July 2010 17:02, Benjamin Peterson wrote:
>>> Now that Python 2.7 is out, I'd like to thank a few of the people who
>>> made it possible:
>>
>> And not forgetting Benjamin himself for m
On Sat, Jul 3, 2010 at 15:40, "Martin v. Löwis" wrote:
> Am 03.07.2010 16:34, schrieb Christian Heimes:
>> Am 03.07.2010 09:00, schrieb "Martin v. Löwis":
I'm trying to test out a patch to add a timeout in subprocess.py on
Windows, so I need to build Python with Visual Studio. The docs
On 7/4/2010 2:31 AM, Éric Araujo wrote:
But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/
Turns out the audioop is one of the best covered modules, at 98%
--
Terry Jan Reedy
___
Python-Dev m
Dear colleagues:
I'd like to have your input on
http://bugs.python.org/issue9141
"Allow objects to decide if they can be collected by GC."
This generalizes the dynamic discovery of finalization state of objects, as
already provided for generator objects with PyGen_NeedsFinalizing(),to any
objec
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
> On 4 July 2010 17:02, Benjamin Peterson wrote:
>> Now that Python 2.7 is out, I'd like to thank a few of the people who
>> made it possible:
>
> And not forgetting Benjamin himself for managing the whole thing!
+1. Thanks a lot for your hard wo
On 4 July 2010 17:02, Benjamin Peterson wrote:
> Now that Python 2.7 is out, I'd like to thank a few of the people who
> made it possible:
And not forgetting Benjamin himself for managing the whole thing!
Paul.
___
Python-Dev mailing list
Python-Dev@py
Hello pydev
I’d like to volunteer to maintain a tool but I’m not sure where I can
help. I’m already proposing changes to Brett for
Tools/scripts/patchcheck.py, and I have commented on Tools/i18n bugs,
but these ones are already maintained by their authors (e.g. Barry is
assigned pygettext bugs) an
On Sun, Jul 4, 2010 at 12:02 PM, Benjamin Peterson wrote:
..
> - Alexander Belopolsky for taking up datetime.
I am honored that my contributions have been noticed, but would not be
able to contribute as much without support from Mark Dickinson.
___
Pyth
On Sun, 4 Jul 2010 10:34:57 -0500
Benjamin Peterson wrote:
> On behalf of the Python development team, I'm jocund to announce the second
> release candidate of Python 2.7.
>
> Python 2.7 will be the last major version in the 2.x series. However, it will
> also have an extended period of bugfix m
On 07/04/2010 08:34 AM, Benjamin Peterson wrote:
On behalf of the Python development team, I'm jocund to announce the second
release candidate of Python 2.7.
s/second release candidate/release/
*standing ovation*
//larry//
___
Python-Dev mailin
2010/7/4 Benjamin Peterson :
> On behalf of the Python development team, I'm jocund to announce the second
> release candidate of Python 2.7.
Arg!!! This should, of course, be "final release".
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-D
Now that Python 2.7 is out, I'd like to thank a few of the people who
made it possible:
- Martin for building Windows Installers to my schedule, maintaining
the tracker and PyPi, and providing lots of guidance and advice.
- Ronald for building Mac installers.
- Tarek for picking up the reins of di
[Martin Geisler]
> You basically need to replay the changes -- the transplant extension can
> do this for you. This is more or less a wrapper around 'hg export'
> (gives you a diff) and 'hg import' (applies the diff).
Core developers seem to be okay with svnmerge, so perhaps a
familiar-looking com
On behalf of the Python development team, I'm jocund to announce the second
release candidate of Python 2.7.
Python 2.7 will be the last major version in the 2.x series. However, it will
also have an extended period of bugfix maintenance.
2.7 includes many features that were first released in Pyt
Éric Araujo writes:
>> I'm not sure if I misunderstand Martin's intent, but in principle, if
>> you want to merge one changes (not changesets!) branch into another,
>> all you need to do would be "hg merge ". Subsequently
>> committing the merge (after fixing conflicts) creates a new changeset
>>
> I'm not sure if I misunderstand Martin's intent, but in principle, if you
> want to merge one changes (not changesets!) branch into another, all you
> need to do would be "hg merge ". Subsequently committing
> the merge (after fixing conflicts) creates a new changeset "on" the current
> branch.
On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo wrote:
> By the way, is eol a requirement for people using Windows tools with
> limitations only, or for every person that will clone Python?
It's designed so that everyone can run it regardless of platform. If
someone chooses not to use it and messes
Am 04.07.2010 13:37, schrieb Martin Geisler:
> "Martin v. Löwis" writes:
>
>>> My question is basically the same as Terry Reedy's, but I'm going to
>>> phrase it a bit differently:
>>>
>>> This is perhaps a naive question, but why do you create a second local
>>> clone instead of just creating a
Not requiring any Mercurial extension to contribute to Python would be a
nice policy to lower the entry bar.
>>>
>>> That is already defeated by the need for the eol extension (which is now
>>> built-in in hg 1.6). Activating mq is something every developer should
>>> manage...
>>
>> Oka
Am 04.07.2010 13:53, schrieb Éric Araujo:
>>> Not requiring any Mercurial extension to contribute to Python would be a
>>> nice policy to lower the entry bar.
>>
>> That is already defeated by the need for the eol extension (which is now
>> built-in in hg 1.6). Activating mq is something every de
"Martin v. Löwis" writes:
>> My question is basically the same as Terry Reedy's, but I'm going to
>> phrase it a bit differently:
>>
>> This is perhaps a naive question, but why do you create a second local
>> clone instead of just creating a branch?
>
> IIUC, if you create a named branch, the b
>> Not requiring any Mercurial extension to contribute to Python would be a
>> nice policy to lower the entry bar.
>
> That is already defeated by the need for the eol extension (which is now
> built-in in hg 1.6). Activating mq is something every developer should
> manage...
Okay, make that “no
Am 04.07.2010 13:29, schrieb Éric Araujo:
> The other risk with history-editing extensions is that they use the
> merge and rebase machinery to do their work, so they require a clean
> working directory. Otherwise you may loose uncommitted changes.
That's true.
> Not requiring any Mercurial exten
The other risk with history-editing extensions is that they use the
merge and rebase machinery to do their work, so they require a clean
working directory. Otherwise you may loose uncommitted changes.
Not requiring any Mercurial extension to contribute to Python would be a
nice policy to lower the
Am 04.07.2010 00:59, schrieb "Martin v. Löwis":
>> This is perhaps a naive question, but hat do you gain with the
>> intermediate mirror clone of upstream? (Other than filling more of your
>> disk?)
>
> In addition to the answer you got: this way of working is also the
> process that I arrived at,
Hi all !
I am sorry about the flood of mails in checkins this morning. It was annoying.
It seems to me that this is a general problem that will appear in
CPython too once it's in mercurial.
I think this can be easily fixed by a patch policy. I have just sent a
mail to python-ideas about this, to
27 matches
Mail list logo
