date:20140221

[Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Larry Hastings



We're now up to 66 cherry-picks.  75%+ of those are asyncio changes.

Hopefully I won't have to redo the cherry-picking from scratch again, I 
can just pile more picks on top of the ones I've got.


As before you'll find the results here:

   http://midwinter.com/~larry/3.4.status/



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

Re: [Python-Dev] rpm needs python

2014-02-21 Thread Terry Reedy


On 2/21/2014 2:06 AM, anju Tiwari wrote:


I have two version of python 2.4 and 2.7.
By default python version is 2.4 . I want to install need to install
some rpm
which needs python 2.7 interpreter. how can I enable 2.7 interpreter for
only those
packages which are requiring python 2.7, I don’t want to change my
default python version(2.4).


Ask usage questions like this on python-list or similar user forums. 
pydev is for development *of* python, not *with* python.



--
Terry Jan Reedy


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

[Python-Dev] cherry pick a change to Enum

2014-02-21 Thread Ethan Furman

Greetings, all!

Larry asked me to bring this to PyDev, so here it is.

The issues involved are:

http://bugs.python.org/issue20534 -> already in RC1
http://bugs.python.org/issue20653 -> hoping to get cherry-picked

Background
==
When I put Enum together, my knowledge of pickle and its protocols was dreadfully weak. As a result, I didn't make the
best choice in implementing it [1].

Just before RC1 was cut, Serhiy discovered a problem with pickling Enums at protocol four, and with his help I fixed
that (this is the part that is already in RC1). This fix consisted primarily of adding a __reduce_ex__ to the Enum
class, and also checking for all the pickle protocols in a mixed-in type [2], but I left __getnewargs__ in. Not only
that, and worse, I wasn't checking to see if the new subclass had its own __getnewargs__ or __reduce_ex__ before I
invalidated the class for pickling [3]. This means that even though a subclass could have its own __reduce_ex__ to make
pickling/unpickling possible, it will be ignored.

Problem
===
All the previous changes to disallow something have been for strategic reasons (the usual ones being either consistency,
or "it doesn't make sense for an enum member/class to behave that way"), but this is effectively disallowing a user to
specify how their enums should be pickled, and I am unaware of any reason why this should be.

Discussion
==

Is there a valid reason to not allow a user to modify how their enums are
pickled?

If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but
after 3.4.0 is cut we then have to deal with backwards compatibility issues.

Thanks for your time and thoughts.

--
~Ethan~

[1] I chose __getnewargs__, with the result that originally Enum didn't support pickle protocols 0 or 1, and when 4 was
added later it had trouble with some types of Enum subclasses (tuples, to be exact).

[2] Those protocol methods being __reduce__, __reduce_ex__, __getnewargs__, and
__getnewargs_ex__.

[3] This logic error has been there from the beginning, it did not sneak in in
the last patch before RC1.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Ned Deily

In article <[email protected]>,
 Larry Hastings  wrote:
> As before you'll find the results here:
> 
> http://midwinter.com/~larry/3.4.status/

Status says that: 

eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from 
svn.python.org anymore

is unmerged, which is what Georg and I agreed upon in Issue20661.  Yet, 
in the current python.3.4.2014.02.21.00.07.42.tgz tarball, that change 
appears to be present and, as such, causes installer builds to fail.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
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

2014-02-21 Thread Andreas Röhler


Am 20.02.2014 02:24, schrieb Stephen J. Turnbull:
[ ... ]

Sure, but it *doesn't* help in knowing which ones are *correctly*
addressed.  These *are* ambitious changes; some of the remaining bugs
may be very deep.  The obvious fixes may do more harm than good.  Ie,
"more eyes" is (a) mostly a fallacy (as Heinlein put it, the wisdom of
a group is less than or equal to the maximum of the wisdom of the
members) and (b) in any case the "more eyes" effect is diluted if
people are deliberately looking at different parts of the code.



All depends from the way, a group is organized, composed etc.
What might stiffle results in a group for example is hierarchy, resp. a fear to 
get chastised by the leader.

After all I'm not in position to make a guess here - but rather would expect 
much higher results by groups-coop than from most gifted single person among.


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

Re: [Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Larry Hastings


On 02/21/2014 01:30 AM, Ned Deily wrote:

In article <[email protected]>,
  Larry Hastings  wrote:

As before you'll find the results here:

 http://midwinter.com/~larry/3.4.status/

Status says that:

eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from
svn.python.org anymore

is unmerged, which is what Georg and I agreed upon in Issue20661.  Yet,
in the current python.3.4.2014.02.21.00.07.42.tgz tarball, that change
appears to be present and, as such, causes installer builds to fail.



Whoopsie!  My local branch is actually correct.  But!  I effectively did 
this in my automation:


   % hg clone 3.4 python-{time}
   % cd python-{time}
   % rm -rf .hg* .bzr* .git*
   % cd ..
   % tar cvfz python-{time}.tgz python-{time}

Can you spot the error?  That's right: when you clone, the clone always 
starts out in "default".  So all the tarballs I've published so far have 
been wrong.  ARGH.  Sorry!


I've added a "hg branch 3.4" in a judicious spot in my automation. The 
resulting tarball doesn't have the sphinx toolchain change.


Look for a new tarball in a few minutes, once "make test" finishes,


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

Re: [Python-Dev] cherry pick a change to Enum

2014-02-21 Thread Antoine Pitrou

On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman  wrote:
> 
> Discussion
> ==
> 
> Is there a valid reason to not allow a user to modify how their enums are 
> pickled?
> 
> If not, should we put the change in RC2 / Final?  The main reason I'm pushing 
> for this is that Enum is still new, but 
> after 3.4.0 is cut we then have to deal with backwards compatibility issues.

I think this should be cherry-picked.
(but see my comment on the issue)

Regards

Antoine.


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

Re: [Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Arfrever Frehtes Taifersar Arahesis

2014-02-21 11:06 Larry Hastings napisał(a):
> On 02/21/2014 01:30 AM, Ned Deily wrote:
> > In article <[email protected]>,
> >   Larry Hastings  wrote:
> >> As before you'll find the results here:
> >>
> >>  http://midwinter.com/~larry/3.4.status/
> > Status says that:
> >
> > eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from
> > svn.python.org anymore
> >
> > is unmerged, which is what Georg and I agreed upon in Issue20661.  Yet,
> > in the current python.3.4.2014.02.21.00.07.42.tgz tarball, that change
> > appears to be present and, as such, causes installer builds to fail.
> >
> 
> Whoopsie!  My local branch is actually correct.  But!  I effectively did 
> this in my automation:
> 
> % hg clone 3.4 python-{time}
> % cd python-{time}
> % rm -rf .hg* .bzr* .git*
> % cd ..
> % tar cvfz python-{time}.tgz python-{time}
> 
> Can you spot the error?  That's right: when you clone, the clone always 
> starts out in "default".  So all the tarballs I've published so far have 
> been wrong.  ARGH.  Sorry!
> 
> I've added a "hg branch 3.4" in a judicious spot in my automation.

You can use 'hg clone -u 3.4 3.4 python-{time}'.

$ hg clone --help
...
To check out a particular version, use -u/--update, or -U/--noupdate to
create a clone with no working directory.
...
 -u --updaterev REV revision, tag or branch to check out


--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Antoine Pitrou

On Fri, 21 Feb 2014 02:06:07 -0800
Larry Hastings  wrote:
> 
> Whoopsie!  My local branch is actually correct.  But!  I effectively did 
> this in my automation:
> 
> % hg clone 3.4 python-{time}
> % cd python-{time}
> % rm -rf .hg* .bzr* .git*
> % cd ..
> % tar cvfz python-{time}.tgz python-{time}

You could use "hg archive".

Regards

Antoine.


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

Re: [Python-Dev] PEP 463: Exception-catching expressions

2014-02-21 Thread Nick Coghlan

On 21 February 2014 13:15, Chris Angelico  wrote:
> PEP: 463
> Title: Exception-catching expressions
> Version: $Revision$
> Last-Modified: $Date$
> Author: Chris Angelico 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 15-Feb-2014
> Python-Version: 3.5
> Post-History: 16-Feb-2014, 21-Feb-2014
>
>
> Abstract
> 
>
> Just as PEP 308 introduced a means of value-based conditions in an
> expression, this system allows exception-based conditions to be used
> as part of an expression.

Great work on this Chris - this is one of the best researched and
justified Python syntax proposals I've seen :)

> Open Issues
> ===
>
> Parentheses around the entire expression
> 
>
> Generator expressions require parentheses, unless they would be
> strictly redundant.  Ambiguities with except expressions could be
> resolved in the same way, forcing nested except-in-except trees to be
> correctly parenthesized and requiring that the outer expression be
> clearly delineated.  `Steven D'Aprano elaborates on the issue.`__
>
> __ https://mail.python.org/pipermail/python-ideas/2014-February/025647.html

I'd like to make the case that the PEP should adopt this as its
default position. My rationale is mainly that if we start by requiring
the parentheses, it's pretty straightforward to take that requirement
away in specific cases later, as well as making it easier to introduce
multiple except clauses if that ever seems necessary.

However, if we start without the required parentheses, that's it - we
can't introduce a requirement for parentheses later if we decide the
bare form is too confusing in too many contexts, and there's plenty of
potential for such confusion.

In addition to the odd interactions with other uses of the colon as a
marker in the syntax, including suite headers, lambdas and function
annotations, omitting the parentheses makes it harder to decide which
behaviour was intended in ambiguous cases, while the explicit
parentheses would force the writer to be clear which one they meant.
Consider:

x = get_value() except NotFound: foo is not None

There are two plausible interpretations of that:

x = (get_value() except NotFound: foo) is not None
x = get_value() except NotFound: (foo is not None)

With the proposed precedence in the PEP (which I agree with), the
latter is the correct interpretation, but that's not at all obvious to
the reader - they would have to "just know" that's the way it works.
By contrast, if the parentheses are required, then the spelling would
have to be one of the following to be legal:

x = (get_value() except NotFound: foo is not None)
x = (get_value() except NotFound: foo) is not None

Which means the ":" and the closing ")" nicely bracket the fallback
value in both cases and make the author's intent relatively clear.

The required parentheses also help in the cases where there is a
nearby colon with a different meaning:

   if check() except Exception: False:
...
   if (check() except Exception: False):
...

   lambda x: calculate(x) except Exception: None
   lambda x: (calculate(x) except Exception: None)

   def f(a: "OS dependent" = os_defaults[os.name] except KeyError: None): pass
   def f(a: "OS dependent" = (os_defaults[os.name] except KeyError: None)): pass

Rather than making people consider "do I need the parentheses in this
case or not?", adopting the genexp rule makes it simple: yes, you need
them, because the compiler will complain if you leave them out.

> Retrieving a message from either a cache or the internet, with auth
> check::
>
> logging.info("Message shown to user: %s",((cache[k]
> except LookupError:
> (backend.read(k) except OSError: 'Resource not available')
> )
> if check_permission(k) else 'Access denied'
> ) except BaseException: "This is like a bare except clause")

I don't think taking it all the way to one expression shows the new
construct in the best light. Keeping this as multiple statements
assigning to a temporary variable improves the readability quite a
bit:

if not check_permission(k):
msg = 'Access denied'
else:
msg = (cache[k] except LookupError: None)
if msg is None:
msg = (backend.read(k) except OSError: 'Resource not available')

logging.info("Message shown to user: %s", msg)

I would also move the "bare except clause" equivalent out to a
separate example. Remember, you're trying to convince people to *like*
the PEP, not scare them away with the consequences of what happens
when people try to jam too much application logic into a single
statement. While we're admittedly giving people another tool to help
them win obfuscated Python contests, we don't have to *encourage* them
:)

> try:
> if check_permission(k):
> try:
> _ = cache[k]
> except LookupError:
> try:
>

Re: [Python-Dev] cherry pick a change to Enum

2014-02-21 Thread Nick Coghlan

On 21 February 2014 20:29, Antoine Pitrou  wrote:
> On Fri, 21 Feb 2014 00:36:09 -0800
> Ethan Furman  wrote:
>>
>> Discussion
>> ==
>>
>> Is there a valid reason to not allow a user to modify how their enums are 
>> pickled?
>>
>> If not, should we put the change in RC2 / Final?  The main reason I'm 
>> pushing for this is that Enum is still new, but
>> after 3.4.0 is cut we then have to deal with backwards compatibility issues.
>
> I think this should be cherry-picked.
> (but see my comment on the issue)

That course of action makes sense to me, too. While we ideally want to
catch design bugs during beta, the fact is that we sometime won't
notice them until the release candidate phase, and it makes sense to
fix them before the final release.

However, it also makes sense to discuss the corner cases here before
deciding how to proceed, and if we uncover any more after rc2, such a
change would probably be a trigger for a 3rd release candidate
(although that would ultimately be Larry's call as release manager).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

2014-02-21 Thread Paul Moore

On 21 February 2014 11:35, Nick Coghlan  wrote:
>> Just as PEP 308 introduced a means of value-based conditions in an
>> expression, this system allows exception-based conditions to be used
>> as part of an expression.
>
> Great work on this Chris - this is one of the best researched and
> justified Python syntax proposals I've seen :)

Agreed - given the number of differing opinions on python-ideas, it's
particularly impressive how well the debate was conducted too.

Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

96 matches

Mail list logo