Am 15.02.2014 23:19, schrieb Paul Moore:
On 13 February 2014 20:58, Paul Moore p.f.mo...@gmail.com wrote:
On 13 February 2014 20:54, Donald Stufft don...@stufft.io wrote:
On Feb 13, 2014, at 3:53 PM, Paul Moore p.f.mo...@gmail.com wrote:
Can someone please take a look at
Hi,
On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote:
Hi,
On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com
wrote:
It appears there's no obvious link from bugs.python.org to the contributor
agreement - you need to go via the unintuitive link
Am 16.02.2014 09:40, schrieb Ezio Melotti:
Hi,
On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote:
Hi,
On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com
wrote:
It appears there's no obvious link from bugs.python.org to the contributor
On 16/02/2014 00:22, Nick Coghlan wrote:
On 16 February 2014 09:20, Ned Deily n...@acm.org wrote:
In article
1392492250.26338.83831085.39a5e...@webmail.messagingengine.com,
Benjamin Peterson benja...@python.org wrote:
On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote:
Although
On Sat, 15 Feb 2014 20:12:33 +0200
Serhiy Storchaka storch...@gmail.com wrote:
I wrote a large patch which modifies the tests to use more specific
methods [1]. Because it is too large, it was divided into many smaller
patches, and separate issues were opened for them. At the moment the
On 16 February 2014 08:19, Georg Brandl g.bra...@gmx.net wrote:
As soon as a patch has been provided and tested, I will make a schedule
for 3.3.5 including the fix. Until then, using 3.3.3 is probably the
best solution.
Fantastic - thanks for that.
Paul
On Sun, Feb 16, 2014 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
The practical benefits of this kind of change in the test suite are
also highly dubious, because they *only help if the test fails at some
point in the future*. At that point, whoever caused the test to fail
will switch
Jeff Allen, 16.02.2014 11:23:
I spend a *lot* of time working with the Python test suite on behalf of
Jython, so I appreciate the care CPython puts into its testing. To a large
extent, tests written for CPython drive Jython development: I suspect I
work with a lot more failing tests than
On Wed, Jan 8, 2014 at 4:45 AM, Serhiy Storchaka storch...@gmail.com wrote:
--canonicalize is not strict. --canonicalize-existing is most strict and
--canonicalize-missing is least strict. When you have a function which have
non-strict behavior (--canonicalize), you can implement a wrapper with
On Sun, Feb 16, 2014 at 11:06 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 16.02.2014 09:40, schrieb Ezio Melotti:
Hi,
On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote:
Hi,
On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com
wrote:
It appears
I came across http://bugs.python.org/issue13663, which is about a
pootle.python.org installation. http://pootle.python.org/ currently
returns a 500. Are we still using Pootle, or should I just close #13663?
(Maybe the installation got broken in the move to OSL and then forgotten?)
--amk
On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote:
I came across http://bugs.python.org/issue13663, which is about a
pootle.python.org installation. http://pootle.python.org/ currently
returns a 500. Are we still using Pootle, or should I just close #13663?
(Maybe the installation got
Am 16.02.2014 16:32, schrieb Benjamin Peterson:
On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote:
I came across http://bugs.python.org/issue13663, which is about a
pootle.python.org installation. http://pootle.python.org/ currently
returns a 500. Are we still using Pootle, or should I
Let's begin with a status update of The Great Argument Clinic Conversion
Derby. In retrospect, the Derby was way too ambitious. Once it started
I was quickly overwhelmed. Even doing nothing but Derby work, all day
every day for two straight weeks, I couldn't keep up with all the bug
16.02.14 10:19, Georg Brandl написав(ла):
As soon as a patch has been provided and tested, I will make a schedule
for 3.3.5 including the fix. Until then, using 3.3.3 is probably the
best solution.
Then could you please include the fix for #20538 (this bug allows easily
crash Python e.g. by
16.02.14 02:05, Nick Coghlan написав(ла):
It's also likely than many of these crashes could only be reproduced
through incorrect usage of the C API.
Rather through queer or malicious usage of Python classes with strange
code in __del__.
For example:
Py_CLEAR_AND_SET
On 2/16/2014 2:52 PM, Serhiy Storchaka wrote:
16.02.14 10:19, Georg Brandl написав(ла):
As soon as a patch has been provided and tested, I will make a schedule
for 3.3.5 including the fix. Until then, using 3.3.3 is probably the
best solution.
Then could you please include the fix for #20538
16.02.14 20:31, Larry Hastings написав(ла):
So here we are in the release candidate period for 3.4, and we still
have all these unmerged Derby patches. And it's simply too late in the
release cycle to merge them for 3.4.0.
Here's how I propose we move forward.
Your plan LGTM (except one
On 02/16/2014 12:36 PM, Serhiy Storchaka wrote:
16.02.14 20:31, Larry Hastings написав(ла):
4) We accelerate the schedule for 3.4.1 slightly, so we can get these
new signatures into the hands of users sooner. Specifically, I propose
we ship 3.4.1 two months after 3.4.0. I figure we would
On Sun, 16 Feb 2014 10:31:21 -0800
Larry Hastings la...@hastings.org wrote:
Here's how I propose we move forward.
1) We merge the Derby patch for the builtins module into 3.4, simply
because it will demo well.
This still brings potential unstability during the rc phase, so I'd
prefer this
Am 16.02.2014 21:14, schrieb Terry Reedy:
On 2/16/2014 2:52 PM, Serhiy Storchaka wrote:
16.02.14 10:19, Georg Brandl написав(ла):
As soon as a patch has been provided and tested, I will make a schedule
for 3.3.5 including the fix. Until then, using 3.3.3 is probably the
best solution.
Then
Am 16.02.2014 22:27, schrieb Larry Hastings:
On 02/16/2014 12:36 PM, Serhiy Storchaka wrote:
16.02.14 20:31, Larry Hastings написав(ла):
4) We accelerate the schedule for 3.4.1 slightly, so we can get these
new signatures into the hands of users sooner. Specifically, I propose
we ship 3.4.1
Larry Hastings wrote:
3) We hold off on merging the rest of the Derby patches until after
3.4.0 final ships, then we merge them into the 3.4 maintenance branch so
they go into 3.4.1.
But wouldn't that be introducing a new feature into a
maintenance release? (I.e. some functions that didn't
In article 3frhkw2rdjz7...@mail.python.org,
georg.brandl python-check...@python.org wrote:
http://hg.python.org/cpython/rev/eef7899ea7ab
changeset: 89212:eef7899ea7ab
user:Georg Brandl ge...@python.org
date:Sun Feb 16 09:46:36 2014 +0100
summary:
Doc: do not rely on
Am 16.02.2014 23:46, schrieb Ned Deily:
In article 3frhkw2rdjz7...@mail.python.org,
georg.brandl python-check...@python.org wrote:
http://hg.python.org/cpython/rev/eef7899ea7ab
changeset: 89212:eef7899ea7ab
user:Georg Brandl ge...@python.org
date:Sun Feb 16 09:46:36 2014
On 17 Feb 2014 02:20, Georg Brandl g.bra...@gmx.net wrote:
Am 16.02.2014 16:32, schrieb Benjamin Peterson:
On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote:
I came across http://bugs.python.org/issue13663, which is about a
pootle.python.org installation. http://pootle.python.org/
Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has
been released, and the next release will be rc2.
You might think that anything you check in to the default branch in
Python trunk will go into 3.4.0 rc2, and after that ships, checkins
would go into 3.4.0 final. Ho ho
On 17 Feb 2014 06:12, Serhiy Storchaka storch...@gmail.com wrote:
16.02.14 02:05, Nick Coghlan написав(ла):
It's also likely than many of these crashes could only be reproduced
through incorrect usage of the C API.
Rather through queer or malicious usage of Python classes with strange
code
On 17 Feb 2014 08:36, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Larry Hastings wrote:
3) We hold off on merging the rest of the Derby patches until after
3.4.0 final ships, then we merge them into the 3.4 maintenance branch so
they go into 3.4.1.
But wouldn't that be introducing a new
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to find the revision number that contains the fix to
follow the process you outline above, so I'm just mentioning it here
on the issue to make sure
Hi,
The PEP 436 is still a draft and not mentionned in Python 3.4
changelog. The PEP proposes to add a DSL, not to modify all modules
implemented in C. I think that it should be marked as Final and
mentionned in the changelog.
http://www.python.org/dev/peps/pep-0436/
2014-02-16 19:31 GMT+01:00
On 02/16/2014 10:31 AM, Larry Hastings wrote:
I'm very sorry that many people contributed to the Derby expecting
their patches to go in to 3.4. This is my fault, for severely
miscalculating how the Derby would play out. And I feel awful
about it.
Don't worry too much. It was a great
FYI, Japanese translation project is now uses Transifex to translate
Py3k document.
https://www.transifex.com/projects/p/python-33-ja/
http://docs.python.jp/3/
On Mon, Feb 17, 2014 at 8:13 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 17 Feb 2014 02:20, Georg Brandl g.bra...@gmx.net wrote:
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to
http://bugs.python.org/issue20651 filed to track this as larry requested.
On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith g...@krypto.org wrote:
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
35 matches
Mail list logo
