Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Gregory P. Smith]

http://bugs.python.org/issue20651 filed to track this as larry requested.


On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith  wrote:

> For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
>
>
> On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore  wrote:
>
>>  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 it's not missed...
>>
>> Paul
>>
>> On 16 February 2014 23:25, Larry Hastings  wrote:
>> >
>> >
>> > 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 ho!  That's not true!  Instead, anything checked in
>> to
>> > "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0
>> final
>> > will by default go into 3.4.1.  Only fixes that I cherry-pick into my
>> local
>> > branch will go into 3.4.0 rc2 and final.  And my local branch will
>> remain
>> > private until 3.4.0 final ships!
>> >
>> > If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
>> final,
>> > please go to the issue tracker and create a new issue with the following
>> > attributes:
>> >
>> > The title should start with "3.4 cherry-pick: " followed by the
>> revision id
>> > and a short summary
>> >   example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
>> > The version should be "Python 3.4"
>> > The assignee should be "larry"
>> > The priority should be "release blocker"
>> > The comment should *also* contain the revision id (the tracker will
>> turn it
>> > into a link)
>> >
>> > I'm also working on automatically publishing the merged/unmerged
>> revision
>> > status to a web page.  You can see a mock-up here:
>> >
>> > http://www.midwinter.com/~larry/3.4.merge.status.html
>> >
>> > The page is marked "beta" because it doesn't have real data yet--I'm
>> still
>> > experimenting with my automation, so I haven't created the real 3.4
>> local
>> > branch yet.  Again, just to be crystal-clear: the revisions marked
>> "merged"
>> > on that page are just experiments, they aren't actually merged for 3.4.
>> > Once I'm ready for real merging, I'll remove the beta warning.
>> >
>> > (By the way: on that page, clicking on a revision takes you to the
>> revision
>> > web page.  Clicking on the first line of the comment expands it to show
>> the
>> > complete comment.)
>> >
>> >
>> > Please use your best judgment before asking that a revision be
>> cherry-picked
>> > into 3.4.0.  Our goal in the release candidate phase is to stabilize
>> Python,
>> > and to do that we must stop changing it.  Only important interface
>> changes,
>> > new features, or bugfixes should be checked in now, and preferably they
>> > should be low-risk.
>> >
>> > Cheers,
>> >
>> >
>> > /arry
>> >
>> > ___
>> > Python-Dev mailing list
>> > Python-Dev@python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> >
>> https://mail.python.org/mailman/options/python-dev/p.f.moore%40gmail.com
>> >
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Gregory P. Smith]

For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.


On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore  wrote:

>  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 it's not missed...
>
> Paul
>
> On 16 February 2014 23:25, Larry Hastings  wrote:
> >
> >
> > 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 ho!  That's not true!  Instead, anything checked in
> to
> > "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0
> final
> > will by default go into 3.4.1.  Only fixes that I cherry-pick into my
> local
> > branch will go into 3.4.0 rc2 and final.  And my local branch will remain
> > private until 3.4.0 final ships!
> >
> > If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
> final,
> > please go to the issue tracker and create a new issue with the following
> > attributes:
> >
> > The title should start with "3.4 cherry-pick: " followed by the revision
> id
> > and a short summary
> >   example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
> > The version should be "Python 3.4"
> > The assignee should be "larry"
> > The priority should be "release blocker"
> > The comment should *also* contain the revision id (the tracker will turn
> it
> > into a link)
> >
> > I'm also working on automatically publishing the merged/unmerged revision
> > status to a web page.  You can see a mock-up here:
> >
> > http://www.midwinter.com/~larry/3.4.merge.status.html
> >
> > The page is marked "beta" because it doesn't have real data yet--I'm
> still
> > experimenting with my automation, so I haven't created the real 3.4 local
> > branch yet.  Again, just to be crystal-clear: the revisions marked
> "merged"
> > on that page are just experiments, they aren't actually merged for 3.4.
> > Once I'm ready for real merging, I'll remove the beta warning.
> >
> > (By the way: on that page, clicking on a revision takes you to the
> revision
> > web page.  Clicking on the first line of the comment expands it to show
> the
> > complete comment.)
> >
> >
> > Please use your best judgment before asking that a revision be
> cherry-picked
> > into 3.4.0.  Our goal in the release candidate phase is to stabilize
> Python,
> > and to do that we must stop changing it.  Only important interface
> changes,
> > new features, or bugfixes should be checked in now, and preferably they
> > should be low-risk.
> >
> > Cheers,
> >
> >
> > /arry
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/p.f.moore%40gmail.com
> >
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pootle.python.org is down

[INADA Naoki]

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  wrote:
>
> On 17 Feb 2014 02:20, "Georg Brandl"  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/ 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?)
>> >
>> > Per the comments in that bug (esp from Martin), I think we should just
>> > remove pootle.python.org for good.
>>
>> For now.
>
> We should ideally figure out another way to provide support for docs
> translations, though. I already have a slot at the language summit to talk
> about how we manage docs development in general, so if anyone has info on
> the current status of docs translation efforts, I'd be happy to bring that
> up as well.
>
> Cheers,
> Nick.
>
>>
>> Georg
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Ethan Furman]

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 effort, and much got done that will be 
integrated soon.



But I'm convinced the best thing for Python is to hold off on
 merging until after 3.4.0 ships.


If 3.4.1 will be released so soon, just hold off on all the Derby changes until 
then.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Victor Stinner]

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 Larry Hastings :
> 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".

Where is the issue to implement this feature? Anyway, I expect a huge
patch which is non-trivial and so very risky for such a very important
module :-/ It's too late IMO.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Paul Moore]

 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 it's not missed...

Paul

On 16 February 2014 23:25, Larry Hastings  wrote:
>
>
> 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 ho!  That's not true!  Instead, anything checked in to
> "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final
> will by default go into 3.4.1.  Only fixes that I cherry-pick into my local
> branch will go into 3.4.0 rc2 and final.  And my local branch will remain
> private until 3.4.0 final ships!
>
> If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final,
> please go to the issue tracker and create a new issue with the following
> attributes:
>
> The title should start with "3.4 cherry-pick: " followed by the revision id
> and a short summary
>   example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
> The version should be "Python 3.4"
> The assignee should be "larry"
> The priority should be "release blocker"
> The comment should *also* contain the revision id (the tracker will turn it
> into a link)
>
> I'm also working on automatically publishing the merged/unmerged revision
> status to a web page.  You can see a mock-up here:
>
> http://www.midwinter.com/~larry/3.4.merge.status.html
>
> The page is marked "beta" because it doesn't have real data yet--I'm still
> experimenting with my automation, so I haven't created the real 3.4 local
> branch yet.  Again, just to be crystal-clear: the revisions marked "merged"
> on that page are just experiments, they aren't actually merged for 3.4.
> Once I'm ready for real merging, I'll remove the beta warning.
>
> (By the way: on that page, clicking on a revision takes you to the revision
> web page.  Clicking on the first line of the comment expands it to show the
> complete comment.)
>
>
> Please use your best judgment before asking that a revision be cherry-picked
> into 3.4.0.  Our goal in the release candidate phase is to stabilize Python,
> and to do that we must stop changing it.  Only important interface changes,
> new features, or bugfixes should be checked in now, and preferably they
> should be low-risk.
>
> Cheers,
>
>
> /arry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/p.f.moore%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Nick Coghlan]

On 17 Feb 2014 08:36, "Greg Ewing"  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 feature into a
> maintenance release? (I.e. some functions that didn't
> have introspectable signatures before would gain them.)

>From a compatibility point of view, 3.4.0 will already force introspection
users and tool developers to cope with the fact that some, but not all,
builtin and extension types provide valid signature data. Additional clinic
conversions that don't alter semantics then just move additional callables
into the "supports programmatic introspection" category.

It's certainly in a grey area, but "What's in the best interest of end
users?" pushes me in the direction of counting clinic conversions that
don't change semantics as bug fixes - they get improved introspection
support sooner, and it shouldn't make life any harder for tool developers
because all of the adjustments for 3.4 will be to the associated functional
changes in the inspect module.

The key thing is to make sure to postpone any changes that impact
*semantics* (like adding keyword argument support).

Larry's plan sounds OK to me, although at this point I'd be happier leaving
even the builtin conversion until 3.4.1 (especially if we decide to publish
that not long after PyCon US).

Cheers,
Nick.

>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros

[Nick Coghlan]

On 17 Feb 2014 06:12, "Serhiy Storchaka"  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 in __del__.

This change doesn't fix any of the known crashers in Lib/test/crashers,
though - I applied the patch locally and checked.

>> For example:
>>
>>  Py_CLEAR_AND_SET
>>  Py_XCLEAR_AND_SET
>>
>> Such that Py_CLEAR and Py_XCLEAR are equivalent to:
>
>
> There is no Py_XCLEAR. Py_CLEAR itself checks its argument for NULL (as
Py_XDECREF and Py_XINCREF). And these names looks too cumbersome to me.
>
>
>> While the name does suggest the macro will expand to:
>>
>>  Py_CLEAR(target);
>>  target = value;
>>
>> which isn't quite accurate, it's close enough that people should still
>> be able to understand what the operation does.
>
>
> This is not just inaccurate, this is wrong. Py_REPLACE first assigns new
value and then DECREF old value.

The point is that people already know what Py_CLEAR does. This operation is
like Py_CLEAR (the old reference is only removed *after* the pointer has
been updated), except that the value it is being replaced with can be
something other than NULL. If the replacement value *is* NULL, then the new
operation is *exactly* equivalent to Py_CLEAR.

Operations that do related things should ideally have related names. The
point of my deliberately erroneous expansion is that it's an error a reader
can make while still correctly understanding the *logic* of the code, even
though they're missing a subtlety of the mechanics.

> So it rather can be named as Py_SET_AND_DECREF, but of course this name
looks ugly and confusing.

An explicit name like Py_SET_AND_DECREF would also be reasonable. It's
substantially less confusing than Py_REPLACE, as it is less ambiguous about
whether or not the refcount on the new value is adjusted.

Cheers,
Nick.

>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Larry Hastings]

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 ho!  That's not true! Instead, 
anything checked in to "default" between my last revision for "rc1" 
(e64ae8b82672) and 3.4.0 final will by default go into 3.4.1.  Only 
fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and 
final.  And my local branch will remain private until 3.4.0 final ships!


If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or 
final, please go to the issue tracker and create a new issue with the 
following attributes:


   The title should start with "3.4 cherry-pick: " followed by the
   revision id and a short summary
  example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
   The version should be "Python 3.4"
   The assignee should be "larry"
   The priority should be "release blocker"
   The comment should *also* contain the revision id (the tracker will
   turn it into a link)

I'm also working on automatically publishing the merged/unmerged 
revision status to a web page.  You can see a mock-up here:


   http://www.midwinter.com/~larry/3.4.merge.status.html

The page is marked "beta" because it doesn't have real data yet--I'm 
still experimenting with my automation, so I haven't created the real 
3.4 local branch yet.  Again, just to be crystal-clear: the revisions 
marked "merged" on that page are just experiments, they aren't actually 
merged for 3.4.  Once I'm ready for real merging, I'll remove the beta 
warning.


(By the way: on that page, clicking on a revision takes you to the 
revision web page.  Clicking on the first line of the comment expands it 
to show the complete comment.)



Please use your best judgment before asking that a revision be 
cherry-picked into 3.4.0.  Our goal in the release candidate phase is to 
stabilize Python, and to do that we must stop changing it. Only 
important interface changes, new features, or bugfixes should be checked 
in now, and preferably they should be low-risk.


Cheers,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pootle.python.org is down

[Nick Coghlan]

On 17 Feb 2014 02:20, "Georg Brandl"  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/ 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?)
> >
> > Per the comments in that bug (esp from Martin), I think we should just
> > remove pootle.python.org for good.
>
> For now.

We should ideally figure out another way to provide support for docs
translations, though. I already have a slot at the language summit to talk
about how we manage docs development in general, so if anyone has info on
the current status of docs translation efforts, I'd be happy to bring that
up as well.

Cheers,
Nick.

>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore

[Georg Brandl]

Am 16.02.2014 23:46, schrieb Ned Deily:
> In article <3frhkw2rdjz7...@mail.python.org>,
>  georg.brandl  wrote:
> 
>> http://hg.python.org/cpython/rev/eef7899ea7ab
>> changeset:   89212:eef7899ea7ab
>> user:Georg Brandl 
>> date:Sun Feb 16 09:46:36 2014 +0100
>> summary:
>>   Doc: do not rely on checked-out Sphinx toolchain from svn.python.org 
>>   anymore
>> 
>> Nowadays it is likely that people will have Sphinx installed,
>> and if not, they will know how to install it.
>> 
>> This also simplifies life a lot for distribution packagers,
>> who typically do not want the doc build process to connect
>> to external web resources.
> 
> This checkin breaks the OS X installer builds, see for instance:
> 
> http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513
> 
> I've opened Issue20644 to address updating the OS X installer build 
> process and buildbot to deal with this change.  I imagine it also 
> affects the Windows installer build.  This change should not be 
> cherry-picked into 3.4.x until these issues are addressed.

Thanks, I hope it will be easy to fix.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore

[Ned Deily]

In article <3frhkw2rdjz7...@mail.python.org>,
 georg.brandl  wrote:

> http://hg.python.org/cpython/rev/eef7899ea7ab
> changeset:   89212:eef7899ea7ab
> user:Georg Brandl 
> date:Sun Feb 16 09:46:36 2014 +0100
> summary:
>   Doc: do not rely on checked-out Sphinx toolchain from svn.python.org 
>   anymore
> 
> Nowadays it is likely that people will have Sphinx installed,
> and if not, they will know how to install it.
> 
> This also simplifies life a lot for distribution packagers,
> who typically do not want the doc build process to connect
> to external web resources.

This checkin breaks the OS X installer builds, see for instance:

http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513

I've opened Issue20644 to address updating the OS X installer build 
process and buildbot to deal with this change.  I imagine it also 
affects the Windows installer build.  This change should not be 
cherry-picked into 3.4.x until these issues are addressed.

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Greg Ewing]

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
have introspectable signatures before would gain them.)

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Georg Brandl]

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 two months after 3.4.0.  I figure we would release 3.4.1
>>> rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.
>>
>> How this will affect the schedule for 3.3.x? Will it accelerately switched to
>> security-only fix mode?
> 
> That would really be a question for Georg Brandl, the 3.3 release manager. 
> However I don't know why 3.4.1 would have any effect on 3.3, regardless of 
> when
> it was released.

There's no effect; the final 3.3.x point release (hopefully 3.3.6) will be
released after 3.4.0 final, with the branch going into security maintenance
mode afterwards.

Currently I'd be fine with doing 3.3.6 in parallel with 3.4.1, but that is not
a requirement and I don't want to finalize that schedule yet.

cheers,
Georg


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

[Georg Brandl]

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 could you please include the fix for #20538 (this bug allows easily
>> crash Python e.g. by special HTTP request or e-mail). And I think it is
>> very important to port the fix for #19619. Simple patch for #17671 fixes
>> other crash (less important, because can be triggered only by
>> programming error).
> 
> A 3.3.5 should have all the bugfixes committed before the candidate release.

Exactly.  If these are all committed by the rc (only #19619 is missing AFAICT),
they will go in.

The 3.3.5 rc will be released next weekend, Feb 22th, and the final (if nothing
else comes up) on Mar 1st.

cheers,
Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Antoine Pitrou]

On Sun, 16 Feb 2014 10:31:21 -0800
Larry Hastings  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 patch to wait for 3.4.1.

Quoting Wikipedia:
"A release candidate (RC) is a beta version with potential to be a final
product, which is ready to release unless significant bugs emerge."

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[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 two months after 3.4.0.  I figure we would release 3.4.1
rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.


How this will affect the schedule for 3.3.x? Will it accelerately 
switched to security-only fix mode?


That would really be a question for Georg Brandl, the 3.3 release 
manager.  However I don't know why 3.4.1 would have any effect on 3.3, 
regardless of when it was released.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

[Serhiy Storchaka]

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 question below).


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 release 3.4.1
rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.


How this will affect the schedule for 3.3.x? Will it accelerately 
switched to security-only fix mode?



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

[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 could you please include the fix for #20538 (this bug allows easily
crash Python e.g. by special HTTP request or e-mail). And I think it is
very important to port the fix for #19619. Simple patch for #17671 fixes
other crash (less important, because can be triggered only by
programming error).


A 3.3.5 should have all the bugfixes committed before the candidate release.

--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros

[Serhiy Storchaka]

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
 Py_XCLEAR_AND_SET

Such that Py_CLEAR and Py_XCLEAR are equivalent to:


There is no Py_XCLEAR. Py_CLEAR itself checks its argument for NULL (as 
Py_XDECREF and Py_XINCREF). And these names looks too cumbersome to me.



While the name does suggest the macro will expand to:

 Py_CLEAR(target);
 target = value;

which isn't quite accurate, it's close enough that people should still
be able to understand what the operation does.


This is not just inaccurate, this is wrong. Py_REPLACE first assigns new 
value and then DECREF old value. So it rather can be named as 
Py_SET_AND_DECREF, but of course this name looks ugly and confusing.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

[Serhiy Storchaka]

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 special HTTP request or e-mail). And I think it is 
very important to port the fix for #19619. Simple patch for #17671 fixes 
other crash (less important, because can be triggered only by 
programming error).



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.4: What to do about the Derby patches

[Larry Hastings]

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 
fixes, feature requests, correspondence, and documentation updates it 
demanded.  There was no way I could simultaneously review patches too.


As a result: there is, still, an enormous backlog of Derby patches that 
need reviewing.  Few of the Derby patches got integrated before we 
reached rc1.


The underlying theory of the Derby was that it would be a purely 
mechanical process.  It would be a simple matter of converting the 
existing parsing code into its Argument Clinic equivalent, resulting 
solely in code churn.  And, indeed, a significant portion of the Derby 
patches are exactly that.  But the conversion process peered into a lot 
of dusty corners, and raised a lot of questions, and as a result it was 
a much more complicated and time-consuming process than I anticipated.


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.

1) We merge the Derby patch for the builtins module into 3.4, simply 
because it will "demo well".  If someone wants to play with signatures 
on builtins, I think it's likely they'll try something like "len".  
Obviously this wouldn't be permitted to change the semantics of argument 
parsing in any way--this would be a "code churn" patch only.  (In case 
you're wondering, Nick did the conversion of the builtins module, and 
naturally I will be reviewing it.)


2) We change all Clinic conversions in 3.4 so they write the generated 
code to a separate file--in Clinic parlance, change them so they 'use 
the "file" destination'.  Going forward this will be the preferred way 
to check in Argument Clinic changes into Python.


These first two are the only changes resulting from the Derby that I 
will accept between now and 3.4.0 final, and I expect to have them in 
for 3.4.0rc2.  Continuing from there:


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.  We use the time between now and then to get the 
patches totally, totally perfect.  Again, these patches will not be 
permitted to change the parsing semantics of the functions so 
converted.  I expect to do these checkins in a private branch, and land 
the bulk of it immediately upon the opening of the 3.4 maintenance branch.


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 release 3.4.1 
rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.


5) Any proposed changes in Derby patches that change the semantics of a 
builtin may only be checked into default for 3.5, after 3.4.0 ships.



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.  But I'm 
convinced the best thing for Python is to hold off on merging until 
after 3.4.0 ships.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pootle.python.org is down

[Georg Brandl]

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 just close #13663?
>> (Maybe the installation got broken in the move to OSL and then
>> forgotten?)
> 
> Per the comments in that bug (esp from Martin), I think we should just
> remove pootle.python.org for good.

For now.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pootle.python.org is down

[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 just close #13663?
> (Maybe the installation got broken in the move to OSL and then
> forgotten?)

Per the comments in that bug (esp from Martin), I think we should just
remove pootle.python.org for good.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] pootle.python.org is down

[A.M. Kuchling]

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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CLA link from bugs.python.org

[Ezio Melotti]

On Sun, Feb 16, 2014 at 11:06 AM, Georg Brandl  wrote:
> Am 16.02.2014 09:40, schrieb Ezio Melotti:
>> Hi,
>>
>> On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti  wrote:
>>> Hi,
>>>
>>> On Sun, May 5, 2013 at 4:23 AM, Tim Delaney  
>>> wrote:
 It appears there's no obvious link from bugs.python.org to the contributor
 agreement - you need to go via the unintuitive link Foundation ->
 Contribution Forms (and from what I've read, you're prompted when you add a
 patch to the tracker).

 I'd suggest that if the "Contributor Form Received" field is "No" in user
 details, there be a link to http://www.python.org/psf/contrib/.

>>>
>>> See http://psf.upfronthosting.co.za/roundup/meta/issue461.
>>>
>>
>> This is now done: users who submit(ted) patches without having signed
>> the contributor agreement will get a note in tracker with the link and
>> a short explanation.
>> (Sorry it took me so long to get this fixed.)
>
> Thanks, that is a great improvement.  (Although I don't think I like the
> red background color... )

Agreed, that's why I timemachined it gray:
http://hg.python.org/tracker/python-dev/rev/4cdbeb1c74c6#l2.11

>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ezio.melotti%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The desired behaviour for resolve() when the path doesn't exist

[Vajrasky Kok]

On Wed, Jan 8, 2014 at 4:45 AM, Serhiy Storchaka  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
> strict behavior (--canonicalize-existing), but not vice verse.
>

Sorry, only now that I have time to look into this. So what we are
going to do before implementing the behaviour for
resolve(strict=False) is to change the behaviour of
resolve(strict=True) from --canonicalize-existing to --canonicalize?
Is there any time left because we are in RC1 already? Should we
postpone it to 3.5? But then, we'll have backward compatibility
problem.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using more specific methods in Python unit tests

[Stefan Behnel]

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 anyone here.

Careful with such a bold statement. ;)


> What Nick says above is also not false, as general guidance, but taken as
> an iron rule seem to argue against concurrent development at all. Don't we
> manage this change pretty well already? I see little risk of problems 1-3
> in the actual proposal, as the changes themselves are 99% of the "drop-in
> replacement" type:
> 
> -self.assertTrue(isinstance(x, int))
> +self.assertIsInstance(x, int)

While I generally second Nick's objections to this, I also agree that the
kind of change above is such an obvious and straight forward improvement
(since unittest doesn't have py.test's assert analysis) that I'm +1 on
applying them. I've been annoyed more than once by a test failure in
CPython's test suite (when compiled with Cython) that required me to look
up and read the test source and rerun it locally in order to actually
understand what was happening. Seeing a more informative error message
right on our CI server would certainly help, if only to get a quicker idea
if this failure is worth taking a closer look at.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using more specific methods in Python unit tests

[Mark Dickinson]

On Sun, Feb 16, 2014 at 12:22 AM, Nick Coghlan  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 into debugging mode, and a couple of relevant points
> apply:
>

One place where those points don't apply so cleanly is when the test
failure is coming from continuous integration and can't easily be
reproduced locally (e.g., because there's a problem on a platform you don't
have access to, or because it's some kind of threading-related intermittent
failure that's exacerbated by the timing conditions on a particular
machine).  In those situations, an informative error message can easily
save significant debugging time.

Count me as +1 on the test updates, provided they're done carefully.  (And
all those I've looked at from Serhiy do indeed look careful.)

-- 
Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

[Paul Moore]

On 16 February 2014 08:19, Georg Brandl  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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using more specific methods in Python unit tests

[Antoine Pitrou]

On Sat, 15 Feb 2014 20:12:33 +0200
Serhiy Storchaka  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 
> major part of the original patch has already been committed. Many thanks 
> to Ezio for making a review for the majority of the issues. Some changes 
> have been made by other people in unrelated issues.
> 
> Although Raymond approved a patch for test_bigmem [2], his expressed the 
> insistent recommendation not to do this. So I stop committing new 
> reviewed patches. Terry recommended to discuss this in Python-Dev. What 
> are your thoughts?

When it comes specifically to test_bigmem, it is important for error
messages to be informative, because the failures may be hard (if not
enough RAM) or very long to diagnose on a developer's machine. So +1 to
changing test_bigmem.

As for the rest of the test suite, I find the "assertSpecific" form
more readable that "assertTrue(... with some operator)". But I may be
in a minority here :-)

As for the "code churn" argument, I find that a much less important
concern for the test suite than for the rest of the code.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using more specific methods in Python unit tests

[Jeff Allen]

On 16/02/2014 00:22, Nick Coghlan wrote:

On 16 February 2014 09:20, Ned Deily  wrote:

In article
<1392492250.26338.83831085.39a5e...@webmail.messagingengine.com>,
  Benjamin Peterson  wrote:

On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote:

Although Raymond approved a patch for test_bigmem [2], his expressed the
insistent recommendation not to do this. So I stop committing new
reviewed patches. Terry recommended to discuss this in Python-Dev. What
are your thoughts?

I tend to agree with Raymond. I think such changes are very welcome when
the module or tests are otherwise being changed, but on their on
constitute unnecessary churn.


Right, there are a few key problems with large scale style changes to
the test suite:

1. The worst case scenario is where we subtly change a test so that it
is no longer testing what it is supposed to be testing, allowing the
future introduction of an undetected regression. This isn't
particularly *likely*, but a serious problem if it happens.

2. If there are pending patches for that module that include new
tests, then the style change may cause the patches to no longer apply
cleanly, require rework of bug fix and new feature patches to
accommodate the style change.

3. Merges between branches may become more complicated (for reasons
similar to 2), unless the style change is also applied to the
maintenance branches (which is problematic due to 1).
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 anyone here. Where we 
have a custom test, I often update them from in the latest CPython tests.


Often a test failure is not caused by code I just wrote, but by adding a 
CPython test or removing a "skip if Jython", and not having written 
anything yet. While the irrefutable "False is not true" always raises a 
smile, I'd welcome something more informative. It's a more than a 
"style" issue.


What Nick says above is also not false, as general guidance, but taken 
as an iron rule seem to argue against concurrent development at all. 
Don't we manage this change pretty well already? I see little risk of 
problems 1-3 in the actual proposal, as the changes themselves are 99% 
of the "drop-in replacement" type:


-self.assertTrue(isinstance(x, int))
+self.assertIsInstance(x, int)

I found few places, on a quick scan, that risked changing the meaning: 
they introduce an if-statement, or refactor the expression -- I don't 
mean they're actually wrong. The point about breaking Serhiy's patch 
into independent parts will help manage with merging and this risk.


The tests are not library code, but their other use is as an example of 
good practice in unit testing. I pretty much get my idea of Python's 
test facilities from this work. It was a while before I realised more 
expressive methods were available.


Jeff

Jeff Allen

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CLA link from bugs.python.org

[Georg Brandl]

Am 16.02.2014 09:40, schrieb Ezio Melotti:
> Hi,
> 
> On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti  wrote:
>> Hi,
>>
>> On Sun, May 5, 2013 at 4:23 AM, Tim Delaney  
>> wrote:
>>> It appears there's no obvious link from bugs.python.org to the contributor
>>> agreement - you need to go via the unintuitive link Foundation ->
>>> Contribution Forms (and from what I've read, you're prompted when you add a
>>> patch to the tracker).
>>>
>>> I'd suggest that if the "Contributor Form Received" field is "No" in user
>>> details, there be a link to http://www.python.org/psf/contrib/.
>>>
>>
>> See http://psf.upfronthosting.co.za/roundup/meta/issue461.
>>
> 
> This is now done: users who submit(ted) patches without having signed
> the contributor agreement will get a note in tracker with the link and
> a short explanation.
> (Sorry it took me so long to get this fixed.)

Thanks, that is a great improvement.  (Although I don't think I like the
red background color... )

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CLA link from bugs.python.org

[Ezio Melotti]

Hi,

On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti  wrote:
> Hi,
>
> On Sun, May 5, 2013 at 4:23 AM, Tim Delaney  
> wrote:
>> It appears there's no obvious link from bugs.python.org to the contributor
>> agreement - you need to go via the unintuitive link Foundation ->
>> Contribution Forms (and from what I've read, you're prompted when you add a
>> patch to the tracker).
>>
>> I'd suggest that if the "Contributor Form Received" field is "No" in user
>> details, there be a link to http://www.python.org/psf/contrib/.
>>
>
> See http://psf.upfronthosting.co.za/roundup/meta/issue461.
>

This is now done: users who submit(ted) patches without having signed
the contributor agreement will get a note in tracker with the link and
a short explanation.
(Sorry it took me so long to get this fixed.)

Best Regards,
Ezio Melotti

> Best Regards,
> Ezio Melotti
>
>> Tim Delaney
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

[Georg Brandl]

Am 15.02.2014 23:19, schrieb Paul Moore:
> On 13 February 2014 20:58, Paul Moore  wrote:
>> On 13 February 2014 20:54, Donald Stufft  wrote:
>>>
>>> On Feb 13, 2014, at 3:53 PM, Paul Moore  wrote:
>>>
 Can someone please take a look at http://bugs.python.org/issue20621
 for me? It appears that there is a significant problem with zipimport
 in 3.3.4. It's causing breakage in virtualenv but I've isolated the
 issue to what I think is Python itself.

 Basically, until this bug is fixed, virtualenv won't work on Windows
 with Python 3.3.4, as far as I can tell.
>>>
>>> Does it affect 3.4?
>>
>> Just checked that. No, it's not an issue in 3.4rc0. Nor is it in
>> 3.3.3, so it's a regression in the 3.3 series only.
> 
> OK, this appears to be a serious regression that breaks virtualenv.
> Steve Dower suggested a workaround on the tracker, but I don't think
> that can be made to work in the case of virtualenv (for reasons not
> worth explaining now, ask me if you want the details though).
> 
> Given where we are, what is the way forward here? I'm not entirely
> sure what I should be saying to the user who reported the bug in
> virtualenv. I think I'll recommend downgrading to 3.3.3 for now, but
> it would be good to be able to give an idea of what the longer term
> solution is likely to be.

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.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com