On Sat, Jul 3, 2010 at 3:26 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
In the worst case, a function rejects valid data. If I have to choose, I
prefer to reject valid data than a security vulnerability. But audioop has
tests and I don't think that my patch breaks anything :-)
But
But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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
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,
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
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
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 “not
Martin v. Löwis mar...@v.loewis.de 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,
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 developer
Am 04.07.2010 13:37, schrieb Martin Geisler:
Martin v. Löwis mar...@v.loewis.de 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
On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo mer...@netwok.org 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
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 otherbranch. Subsequently committing
the merge (after fixing conflicts) creates a new changeset on the current
Éric Araujo mer...@netwok.org 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 otherbranch. Subsequently
committing the merge (after fixing conflicts) creates
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
[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
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
2010/7/4 Benjamin Peterson benja...@python.org:
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
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
On Sun, 4 Jul 2010 10:34:57 -0500
Benjamin Peterson benja...@python.org 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
On Sun, Jul 4, 2010 at 12:02 PM, Benjamin Peterson benja...@python.org 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.
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)
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org 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
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org 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!
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
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
On Sat, Jul 3, 2010 at 15:40, Martin v. Löwis mar...@v.loewis.de 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
On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote:
Now that Python 2.7 is out, I'd like to thank a few of the people who
made it
Am 04.07.2010 22:45, schrieb Jesse Noller:
On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote:
Now that Python 2.7 is out, I'd like to
28 matches
Mail list logo
