Re: [Python-Dev] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 13 Sep, 2013, at 12:42, Nick Coghlan  wrote:

> Perhaps "__getdescriptor__" would work as the method name? Yes, it can 
> technically return a non-descriptor, but the *primary* purpose is to 
> customise the retrieval of objects that will be checked to see if they're 
> descriptors. It *won't* be invoked when looking for ordinary attributes in an 
> instance dict, but *will* be invoked when looking on the class object.

__getdescriptor__ would work. The name is not 100% accurate, but a lot clearer 
than the other alternatives I've seen.

Ronald

P.S. Sorry about the slow response, its hard to find enough time to seriously 
participate in the discussion.

___
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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 13 Sep, 2013, at 14:23, Steven D'Aprano  wrote:

> On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote:
>> Perhaps "__getdescriptor__" would work as the method name? Yes, it can
>> technically return a non-descriptor,
> 
> So technically that name is, um, what's the term... oh yes, "a lie". 
> 
> :-)
> 
> 
>> but the *primary* purpose is to
>> customise the retrieval of objects that will be checked to see if they're
>> descriptors. 
> 
> If that's the case, the PEP should make that clear.
> 
> [Aside: the PEP states that the method shouldn't invoke descriptors. 
> What's the reason for that? If I take the statement literally, doesn't 
> it mean that the method mustn't use any other methods at all? Surely 
> that can't be what is intended, but I'm not sure what is intended.]

What it tries to say is that even if cls.__dict__[name] is a descriptor the
__locallookup__ method should not call its __get__ method. That was more 
relevant
when __locallookup__ had access to the object for which method resolution was 
performed.

I'm pretty sure this muddies the water even further, but don't have a clearer
description at the moment.

> 
> 
>> It *won't* be invoked when looking for ordinary attributes in
>> an instance dict, but *will* be invoked when looking on the class object.
> 
> Just to be clear, if I have:
> 
> instance = MyClass()
> x = instance.name
> 
> and "name" is found in instance.__dict__, then this special method will 
> not be invoked. But if "name" is not found in the instance dict, then 
> "name" will be looked up on the class object MyClass, which may invoke 
> this special method. Am I correct?

No.  This special method will always be called when "instance.__getattribute__" 
eventually
calls PyObject_GenericGetAttribute (otherwise all bets are off).

PyObject_GenericGetAttribute always looks for a candicate descriptor in the 
class (or
one of the other classes on the MRO). When a candidate descriptor is found, and 
this is 
a data descriptor the descriptor is used instead of the value from 
instance.__dict__ (otherwise
the value from instance.__dict__ is used).

Ronald

___
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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 13 Sep, 2013, at 18:19, Steve Dower  wrote:

> From: Steven D'Aprano
>> On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
>> 
>>> Last I checked, looking up in the instance dict us exactly what it
>>> does. Even the example you posted is doing that.
>> 
>> The example from the PEP shows:
>> 
>> return cls.__dict__[name]
>> 
>> not "self.__dict__[name]". It is true that "the instance" in this case 
>> refers to
>> it being an instance of the metaclass, but that instance is, in fact, a
>> class/type. That's why we normally call it "cls" in a metaclass method rather
>> than "self".
> 
> Right, but where's the difference between these two?
> 
> class A:
>def __tdb__(self, name):
>if name == 'some_attribute_on_my_instance_of_A':
>return its_value
>try:
>return self.__dict__[name]
>except KeyError:
>raise AttributeError(name)
> 
> class MetaB:
>def __tdb__(cls, name):
>if name == 'some_attribute_on_my_class_B':
>return its_value
>try:
>return cls.__dict__[name]
>except KeyError:
>raise AttributeError(name)
> 
> (Yes, either of these could be written with __getattribute__, but that 
> function cannot be called by super().)
> 
> As I see it, there are two (correct) ways to interpret what this method is 
> for, which influences what it should be called.
> 
> 1. It directly replaces obj.__dict__[name] everywhere that is done, including 
> internally in the interpreter.
> 2. It is the same as __getattribute__ without the final call to 
> object.__getattribute__
> 
> I guess it's also correct to view it as a special helper for super(), but it 
> is more generally applicable than that.

It directly replaces cls.__dict__[name] for object.__getattribute__ and 
super.__getattribute__.  

The primary reason for writing a proposal is that __getattribute__ can be used 
to override attribute lookup on an instance, but there is way to override how 
super() looks up an attribute.  Using the method for both 
super().__getattribute__ and object.__getattribute__ results in a cleaner model 
than just having a new hook for super().__getattribute__.


> 
> [...]
> 
>> By the way, I think the PEP should have a more complex example. The 
>> SillyObject
>> example is nice and easy to understand, but it doesn't really help with the
>> motivating use-case "dynamic classes that can grow new methods on demand".
>> Ronald, if you're reading this, can you add such an example please? Also,
>> there's a typo in the SillyObject M method ("fourtytwo" should not have a U 
>> in
>> it).
> 
> Agreed. No harm in more examples.

[...]

> 
> A full example of where this may realistically be needed is longer and 
> certainly involves metaclasses, but fundamentally it's just the same as 
> __getattribute__ with slightly different semantics.

PyObjC will be a truly realistic example, but that involves loads of fairly 
complex C code and likely won't help to explain anything beyond (hopefully) 
showing that this proposal can lead to significant code removal in some 
situations.


Ronald

___
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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 14 Sep, 2013, at 8:30, Nick Coghlan  wrote:

[... interesting text that I'll respond to later ...]

> 
> So my proposed name is based on the idea that what Ronald is after
> with the PEP is a hook that *only* gets invoked when the interpreter
> is doing this hunt for descriptors, but *not* for ordinary attribute
> lookups.

I'll describe the usecase that led to my proposal. I'm amongst other the primary
author (and sole maintainer) of PyObjC, which is a bridge between the Python
and Objective-C class/object models.  PyObjC defines a proxy class for every
(Objective-C) class in the Objective-C runtime and when an Objective-C object
is made available to Python code the PyObjC bridge creates a proxy object that 
is an instance of this proxy object.  This is simular what wxWidgets or PyQt 
do, 
but everything is done at runtime by introspecting the Objective-C runtime.

The first time a method is called the bridge looks for an Objective-C selector 
with the same name and adds that to the class dictionary. This works fine for 
normal
method lookups, by overriding __getattribute__, but causes problems with super:
super happily ignores __getattribute__ and peeks in the class __dict__ which may
not yet contain the name we're looking for and that can result in incorrect 
results
(both incorrect AttributeErrors and totally incorrect results when the name is
not yet present in the parent class' __dict__ but is in the grandparent's 
__dict__).

The current release of PyObjC "solves" this problem by providing a subclass of
super (objc.super) that should be used instead of the builtin one and that 
works,
although the implementation of this class is a gross hack.

Users's of PyObjC are currently oblivious of the problem because I sneak in 
objc.super
as a module's globals()['super'] when it imports PyObjC in the currently 
prefered 
way (which is using *-imports: "from Cocoa import *").  I'm currently migrating 
to
deprecating *-imports because those are bad for the usual reasons, but also 
because
framework binding modules are huge and using plain imports makes it possible to 
delay, and often even avoid, the cost of loading stuff from the framework 
binding
modules.  That switch will however make the problem of using __builtin__.super 
extremely
visible for PyObjC users.

That, and the implementation hack of objc.super, is why I started looking for a 
way
to cleanly provide a way to hook into the attribute resolution for super(), 
which ended
up as PEP 447.

Note that the description is slightly simplified from what PyObjC reall does, 
Objective-C
can (and does) have class and instance methods with the same name, because of 
that
all PyObjC classes have a meta class of the same name and that makes everything
even more complicated, but that should not be important for the previous 
description.

PyObjC also enables implementing Objective-C classes in Python, but that's also
not relevant for this discussion.

Ronald

___
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] PEP 447: add type.__locallookup__

[Paul Moore]

On 19 September 2013 10:32, Ronald Oussoren  wrote:
> The first time a method is called the bridge looks for an Objective-C selector
> with the same name and adds that to the class dictionary. This works fine for 
> normal
> method lookups, by overriding __getattribute__, but causes problems with 
> super:
> super happily ignores __getattribute__ and peeks in the class __dict__ which 
> may
> not yet contain the name we're looking for and that can result in incorrect 
> results
> (both incorrect AttributeErrors and totally incorrect results when the name is
> not yet present in the parent class' __dict__ but is in the grandparent's 
> __dict__).

As an alternative approach, could you use a custom dict subclass as
the class __dict__, and catch the peeking in the class __dict__ that
way? Or is this one of those places where only a real dict will do?

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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 19 Sep, 2013, at 12:00, Paul Moore  wrote:

> On 19 September 2013 10:32, Ronald Oussoren  wrote:
>> The first time a method is called the bridge looks for an Objective-C 
>> selector
>> with the same name and adds that to the class dictionary. This works fine 
>> for normal
>> method lookups, by overriding __getattribute__, but causes problems with 
>> super:
>> super happily ignores __getattribute__ and peeks in the class __dict__ which 
>> may
>> not yet contain the name we're looking for and that can result in incorrect 
>> results
>> (both incorrect AttributeErrors and totally incorrect results when the name 
>> is
>> not yet present in the parent class' __dict__ but is in the grandparent's 
>> __dict__).
> 
> As an alternative approach, could you use a custom dict subclass as
> the class __dict__, and catch the peeking in the class __dict__ that
> way? Or is this one of those places where only a real dict will do?

The C code uses PyDict_GetItem and AFAIK that doesn't look for a __getitem__ 
implementation in a subclass.

Ronald

> 
> 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] PEP 447: add type.__locallookup__

[Nick Coghlan]

On 19 Sep 2013 20:00, "Paul Moore"  wrote:
>
> On 19 September 2013 10:32, Ronald Oussoren 
wrote:
> > The first time a method is called the bridge looks for an Objective-C
selector
> > with the same name and adds that to the class dictionary. This works
fine for normal
> > method lookups, by overriding __getattribute__, but causes problems
with super:
> > super happily ignores __getattribute__ and peeks in the class __dict__
which may
> > not yet contain the name we're looking for and that can result in
incorrect results
> > (both incorrect AttributeErrors and totally incorrect results when the
name is
> > not yet present in the parent class' __dict__ but is in the
grandparent's __dict__).
>
> As an alternative approach, could you use a custom dict subclass as
> the class __dict__, and catch the peeking in the class __dict__ that
> way? Or is this one of those places where only a real dict will do?

Even Python 3 doesn't let you control the *runtime* type of the class dict,
only the type used during evaluation of the class body.

I've played with changing that - it makes for a rather special interpreter
experience :)

Cheers,
Nick.

>
> 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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 19 Sep, 2013, at 12:12, Nick Coghlan  wrote:

> 
> On 19 Sep 2013 20:00, "Paul Moore"  wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren  wrote:
> > > The first time a method is called the bridge looks for an Objective-C 
> > > selector
> > > with the same name and adds that to the class dictionary. This works fine 
> > > for normal
> > > method lookups, by overriding __getattribute__, but causes problems with 
> > > super:
> > > super happily ignores __getattribute__ and peeks in the class __dict__ 
> > > which may
> > > not yet contain the name we're looking for and that can result in 
> > > incorrect results
> > > (both incorrect AttributeErrors and totally incorrect results when the 
> > > name is
> > > not yet present in the parent class' __dict__ but is in the grandparent's 
> > > __dict__).
> >
> > As an alternative approach, could you use a custom dict subclass as
> > the class __dict__, and catch the peeking in the class __dict__ that
> > way? Or is this one of those places where only a real dict will do?
> 
> Even Python 3 doesn't let you control the *runtime* type of the class dict, 
> only the type used during evaluation of the class body.

Changing the class dict type from C is easy enough, but as you wrote below 
doing this gives you an interesting experience. Changing PyDict_* to call the 
subclass implementation of the corresponding slot would be easy enough, but 
that changes the behavior of a core CPython API and I wouldn't look forward to 
auditing the CPython code base to check if such a change is safe (let alone all 
other extensions). Some code will use the PyDict_* API instead of the abstract 
API because the former is faster, but at least some callers for PyDict_GetItem 
will do this to explicitly get the base class implementation.

Ronald


> 
> I've played with changing that - it makes for a rather special interpreter 
> experience :)
> 
> Cheers,
> Nick.
> 
> >
> > 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] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 14 Sep, 2013, at 8:30, Nick Coghlan  wrote:

> 
> 
>>> but the *primary* purpose is to
>>> customise the retrieval of objects that will be checked to see if they're
>>> descriptors.
>> 
>> If that's the case, the PEP should make that clear.
> 
> Technically, that's what "Currently object.__getattribute__ and
> super.__getattribute__ peek in the __dict__ of classes on the MRO for
> a class when looking for an attribute." means.
> 
> However, I agree the current wording only conveys that to the handful
> of people that already know exactly when in the attribute lookup
> sequence that step occurs, which is a rather niche audience :)

I've been fooling around with this long enough that I forgot that not
everyone knows this :-).

I guess I'd better include a clearer and more complete description 
of the current attribute resolution protocol and how my proposal affects 
that.  A nice readable Python implementation of that protocol would be nice
to have regardless of the fate of this PEP.

Ronald

___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

We've updated PEP453 based on some of the early feedback we've gotten from -dev 
and Martin.

Major changes:

* Removal of the option to fetch pip from PyPI in order not to modify the trust 
model of the Python installers
* Consequently rename the model from ``getpip`` to ``extractpip``


Also available online at: http://www.python.org/dev/peps/pep-0453/


Abstract


This PEP proposes that the `pip`_ package manager be made available by
default when installing CPython and when creating virtual environments
using the standard library's ``venv`` module via the ``pyvenv`` command line
utility).

To clearly demarcate development responsibilities, and to avoid
inadvertently downgrading ``pip`` when updating CPython, the proposed
mechanism to achieve this is to include an explicit `pip`_ bootstrapping
mechanism in the standard library that is invoked automatically by the
CPython installers provided on python.org.

The PEP also strongly recommends that CPython redistributors and other Python
implementations ensure that ``pip`` is available by default, or
at the very least, explicitly document the fact that it is not included.


Proposal


This PEP proposes the inclusion of an ``extractpip`` bootstrapping module in
Python 3.4, as well as in the next maintenance releases of Python 3.3 and
2.7.

This PEP does *not* propose making pip (or any dependencies) directly
available as part of the standard library. Instead, pip will be a
bundled application provided along with CPython for the convenience
of Python users, but subject to its own development life cycle and able
to be upgraded independently of the core interpreter and standard library.


Rationale
=

Currently, on systems without a platform package manager and repository,
installing a third-party Python package into a freshly installed Python
requires first identifying an appropriate package manager and then
installing it.

Even on systems that *do* have a platform package manager, it is unlikely to
include every package that is available on the Python Package Index, and
even when a desired third-party package is available, the correct name in
the platform package manager may not be clear.

This means that, to work effectively with the Python Package Index
ecosystem, users must know which package manager to install, where to get
it, and how to install it. The effect of this is that third-party Python
projects are currently required to choose from a variety of undesirable
alternatives:

* Assume the user already has a suitable cross-platform package manager
  installed.
* Duplicate the instructions and tell their users how to install the
  package manager.
* Completely forgo the use of dependencies to ease installation concerns
  for their users.

All of these available options have significant drawbacks.

If a project simply assumes a user already has the tooling then beginning
users may get a confusing error message when the installation command
doesn't work. Some operating systems may ease this pain by providing a
global hook that looks for commands that don't exist and suggest an OS
package they can install to make the command work, but that only works
on systems with platform package managers (such as major Linux
distributions). No such assistance is available for Windows and
Mac OS X users. The challenges of dealing with this problem are a
regular feature of feedback the core Python developers receive from
professional educators and others introducing new users to Python.

If a project chooses to duplicate the installation instructions and tell
their users how to install the package manager before telling them how to
install their own project then whenever these instructions need updates
they need updating by every project that has duplicated them. This is
particular problematic when there are multiple competing installation
tools available, and different projects recommend different tools.

This specific problem can be partially alleviated by strongly promoting
``pip`` as the default installer and recommending that other projects
reference `pip's own bootstrapping instructions
`__ rather than
duplicating them. However the user experience created by this approach
still isn't good (especially on Windows, where downloading and running
the ``get-pip.py`` bootstrap script with the default OS configuration is
significantly more painful than downloading and running a binary executable
or installer). The situation becomes even more complicated when multiple
Python versions are involved (for example, parallel installations of
Python 2 and Python 3), since that makes it harder to create and maintain
good platform specific ``pip`` installers independently of the CPython
installers.

The projects that have decided to forgo dependencies altogether are forced
to either duplicate the efforts of other projects by inventing their own
solutions to problems or are required to simply include the o

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

On Sep 19, 2013, at 9:27 AM, Donald Stufft  wrote:

> We've updated PEP453 based on some of the early feedback we've gotten from 
> -dev and Martin.
> 
> Major changes:
> 
> * Removal of the option to fetch pip from PyPI in order not to modify the 
> trust model of the Python installers
> * Consequently rename the model from ``getpip`` to ``extractpip``
> 
> 
> Also available online at: http://www.python.org/dev/peps/pep-0453/
> 
> [snip]

One thing I don't like is the name ``extractpip``, maybe ``installpip`` would 
be better?

Naming things is hard.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 19 Sep 2013 23:30, "Donald Stufft"  wrote:
>
>
> On Sep 19, 2013, at 9:27 AM, Donald Stufft  wrote:
>
> > We've updated PEP453 based on some of the early feedback we've gotten
from -dev and Martin.
> >
> > Major changes:
> >
> > * Removal of the option to fetch pip from PyPI in order not to modify
the trust model of the Python installers
> > * Consequently rename the model from ``getpip`` to ``extractpip``
> >
> >
> > Also available online at: http://www.python.org/dev/peps/pep-0453/
> >
> > [snip]
>
> One thing I don't like is the name ``extractpip``, maybe ``installpip``
would be better?

I figured that was too close to "pip install", not to mention the actual
phrase "install pip". There are also multiple ways to install pip - the new
bootstrap will just be the simplest.

"extractpip" is a bit clunky, but it does exactly what it says on the tin
and should be a hidden implementation detail the vast majority of the time.

I also believe that choice of name may help avoid the problem of users
expecting a global pip update to implicitly affect future virtual
environments.

> Naming things is hard.

Yup :)

Cheers,
Nick.

>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Paul Moore]

On 19 September 2013 14:27, Donald Stufft  wrote:
> Major changes:
>
> * Removal of the option to fetch pip from PyPI in order not to modify the 
> trust model of the Python installers
> * Consequently rename the model from ``getpip`` to ``extractpip``

If extractpip (I agree, I don't like the name, installpip is better)
only ever unpacks the bundled pip, and it's always run, why bother?
Why not just bundle pip directly into site-packages? The extra step
seems to add little or no value.

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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

On Sep 19, 2013, at 9:36 AM, Paul Tagliamonte  wrote:

> On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote:
>> Rationale
>> =
>> 
>> Currently, on systems without a platform package manager and repository,
>> installing a third-party Python package into a freshly installed Python
>> requires first identifying an appropriate package manager and then
>> installing it.
> 
> Howdy Donald,
> 
> Thanks for helping make Python better.
> 
> However, speaking as a Debian-folk (but not for the Debian-folk, I'll
> let barry take care of that), many users of Python software don't even
> know what pip is (or even that Python exists) -- as such, I find it very
> unlikely that a development tool would be shiped as part of the Python
> distribution in Debian. I don't see this changing, even with this pep.
> python-pip is still installable, but I don't see it pulled in by
> default.

That is obviously Debian's right. Hopefully if Debian does *not* pull it in by
default they'll be the odd man out and documentation can be updated to say
that on Debian based systems additional steps to get the "standard" Python
install must be taken. I believe Fedora has +1'd this so if this gets accepted
there will likely be that additional difference.

> 
> 
>> Even on systems that *do* have a platform package manager, it is unlikely to
>> include every package that is available on the Python Package Index, and
> 
> Yes. This is true. However, it's not Debian's job to include all of
> pypi. Pypi allows anyone to upload, and we have quite a bit of attention
> to concerns such as providing source for everything (less of a concern
> for Python, but pickles can still contain data not in the prefered form
> of modification), and proper free software licensing.
> 
> We also have a concern about stability; so we manage all the package set
> together to allow non-technical end-users to install stuff and not worry
> about breaking their system. It's not always the case where you can
> upgrade a library without breaking API.

This statement isn't meant to imply that it's Debian's job to include all of 
PyPI,
it merely calls out the fact that people often do wish to install things that
are not available in an OS repository while they are available on PyPI.

> 
> 
> I'm trimming the rest, since I don't want to get dragged into
> side-conversations about pip as a package manager.
> 
> 
> Cheers,
>  Paul
> 
> 
> -- 
> .''`.  Paul Tagliamonte 
> : :'  : Proud Debian Developer
> `. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
> `- http://people.debian.org/~paultag


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 19 Sep 2013 23:37, "Paul Tagliamonte"  wrote:
>
> On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote:
> > Rationale
> > =
> >
> > Currently, on systems without a platform package manager and repository,
> > installing a third-party Python package into a freshly installed Python
> > requires first identifying an appropriate package manager and then
> > installing it.
>
> Howdy Donald,
>
> Thanks for helping make Python better.
>
> However, speaking as a Debian-folk (but not for the Debian-folk, I'll
> let barry take care of that), many users of Python software don't even
> know what pip is (or even that Python exists) -- as such, I find it very
> unlikely that a development tool would be shiped as part of the Python
> distribution in Debian. I don't see this changing, even with this pep.
> python-pip is still installable, but I don't see it pulled in by
> default.
>
>
> > Even on systems that *do* have a platform package manager, it is
unlikely to
> > include every package that is available on the Python Package Index, and
>
> Yes. This is true. However, it's not Debian's job to include all of
> pypi. Pypi allows anyone to upload, and we have quite a bit of attention
> to concerns such as providing source for everything (less of a concern
> for Python, but pickles can still contain data not in the prefered form
> of modification), and proper free software licensing.
>
> We also have a concern about stability; so we manage all the package set
> together to allow non-technical end-users to install stuff and not worry
> about breaking their system. It's not always the case where you can
> upgrade a library without breaking API.
>
>
> I'm trimming the rest, since I don't want to get dragged into
> side-conversations about pip as a package manager.

That's OK, especially if running "pip" recommends installing "python-pip"
and "pyvenv" and "extractpip" are also separated out so that running
"pyvenv" recommends installing a suitable package that depends on both
Python and "python-pip".

We can add that to the PEP as an alternative approach for redistributors to
take that still offers a reasonable end-user experience.

Cheers,
Nick.

>
>
> Cheers,
>   Paul
>
>
> --
>  .''`.  Paul Tagliamonte 
> : :'  : Proud Debian Developer
> `. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
>  `- http://people.debian.org/~paultag
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

On Sep 19, 2013, at 9:43 AM, Paul Moore  wrote:

> On 19 September 2013 14:27, Donald Stufft  wrote:
>> Major changes:
>> 
>> * Removal of the option to fetch pip from PyPI in order not to modify the 
>> trust model of the Python installers
>> * Consequently rename the model from ``getpip`` to ``extractpip``
> 
> If extractpip (I agree, I don't like the name, installpip is better)
> only ever unpacks the bundled pip, and it's always run, why bother?
> Why not just bundle pip directly into site-packages? The extra step
> seems to add little or no value.
> 
> Paul

Well it's not always run (the PEP has it as an option in the
installers that is checked by default) but even if it were always
installed:

- Nick has stated something about making it clear in the OSs
  installer DB which files are owned by Python and which are
  owned by pip
- Upgrading becomes harder, instead of simply using pip's own
  mechanism the installer needs to take care not to clobber a user
  installed pip that is even newer than the bundled version.
- "Fixing" a broken environment. If someone accidentally uninstalls
   pip this provides a simple way to reinstall it that doesn't require
   the old standby of getpip.py

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Antoine Pitrou]

Le Thu, 19 Sep 2013 09:27:24 -0400,
Donald Stufft  a écrit :
> We've updated PEP453 based on some of the early feedback we've gotten
> from -dev and Martin.
> 
> Major changes:
> 
> * Removal of the option to fetch pip from PyPI in order not to modify
> the trust model of the Python installers
> * Consequently rename the model from ``getpip`` to ``extractpip``

"ensurepip" ?

What happens if there is already a higher pip version installed?
I suppose "extractpip" doesn't do anything in that case?

(sorry, perhaps it's mentioned in the PEP and I haven't seen it.
The PEP has become so long that I've only skimmed through it.)

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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

On Sep 19, 2013, at 9:50 AM, Antoine Pitrou  wrote:

> Le Thu, 19 Sep 2013 09:27:24 -0400,
> Donald Stufft  a écrit :
>> We've updated PEP453 based on some of the early feedback we've gotten
>> from -dev and Martin.
>> 
>> Major changes:
>> 
>> * Removal of the option to fetch pip from PyPI in order not to modify
>> the trust model of the Python installers
>> * Consequently rename the model from ``getpip`` to ``extractpip``
> 
> "ensurepip" ?
> 
> What happens if there is already a higher pip version installed?
> I suppose "extractpip" doesn't do anything in that case?
> 
> (sorry, perhaps it's mentioned in the PEP and I haven't seen it.
> The PEP has become so long that I've only skimmed through it.)

We could explicitly call this out but it's implied it will do nothing
because it's going to just call out to to the privately installed pip
to actually install itself, and pip itself won't "upgrade" to an older
version.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

On Sep 19, 2013, at 9:50 AM, Paul Tagliamonte  wrote:

> On Thu, Sep 19, 2013 at 11:48:49PM +1000, Nick Coghlan wrote:
>> That's OK, especially if running "pip" recommends installing "python-pip" and
>> "pyvenv" and "extractpip" are also separated out so that running "pyvenv"
>> recommends installing a suitable package that depends on both Python and
>> "python-pip".
> 
> Sounds sane to me!
> 
>> We can add that to the PEP as an alternative approach for redistributors to
>> take that still offers a reasonable end-user experience.
> 
> That'd really be great, and I'm sure it'd cut off the small bit of
> concern some Debian-folk have about this stuff :)

This also sounds reasonable to me. Really the PEP is about reducing user 
friction,
especially for new users, so the ideal method is to ensure it's always installed
but it'd be totally OK to do what Nick suggested as that still at leasts lets 
pypi
packages to simply document installing as ``pip install `` and if it's 
not
installed by default on Debian they'll get a good message telling them what they
need to do.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 19 Sep 2013 23:43, "Paul Moore"  wrote:
>
> On 19 September 2013 14:27, Donald Stufft  wrote:
> > Major changes:
> >
> > * Removal of the option to fetch pip from PyPI in order not to modify
the trust model of the Python installers
> > * Consequently rename the model from ``getpip`` to ``extractpip``
>
> If extractpip (I agree, I don't like the name, installpip is better)
> only ever unpacks the bundled pip, and it's always run, why bother?
> Why not just bundle pip directly into site-packages? The extra step
> seems to add little or no value.

It's not always run - it's opt-out for the Windows and Mac OS X installers
and not invoked implicitly at all if installing from source. The bootstrap
also needs to be available for use by "venv".

There's also the significant fact that python-dev still has a blanket ban
on externally maintained standard library modules (for good reasons) and
the clear separation between the bootstrap module and pip itself is what is
allowing this proposal to adhere to that guideline.

Cheers,
Nick.

>
> 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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 19 Sep 2013 23:53, "Antoine Pitrou"  wrote:
>
> Le Thu, 19 Sep 2013 09:27:24 -0400,
> Donald Stufft  a écrit :
> > We've updated PEP453 based on some of the early feedback we've gotten
> > from -dev and Martin.
> >
> > Major changes:
> >
> > * Removal of the option to fetch pip from PyPI in order not to modify
> > the trust model of the Python installers
> > * Consequently rename the model from ``getpip`` to ``extractpip``
>
> "ensurepip" ?

Oh, I like it - describes exactly why the module exists :)

>
> What happens if there is already a higher pip version installed?
> I suppose "extractpip" doesn't do anything in that case?
>
> (sorry, perhaps it's mentioned in the PEP and I haven't seen it.
> The PEP has become so long that I've only skimmed through it.)

As Donald said, the fact nothing happens in that case is currently only
implied by the fact this is the way pip's "--upgrade" option works.

We should make that explicit in the PEP.

Cheers,
Nick.

>
> 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/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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Donald Stufft]

I've updated the PEP to include the solution for Debian that Nick
mentioned and to clarify the behavior in the upgrade case.

Online: http://hg.python.org/peps/rev/6c1b658bc16c


diff -r 2899ba3bcef1 pep-0453.txt
--- a/pep-0453.txt  Thu Sep 19 09:23:03 2013 -0400
+++ b/pep-0453.txt  Thu Sep 19 10:12:59 2013 -0400
@@ -294,7 +294,9 @@

 This ensures that, by default, installing or updating CPython will ensure
Update PEP453 to address Debian's concerns and Antoine's
 that the installed version of pip is at least as recent as the one included
-with that version of CPython.
+with that version of CPython. If a newer version of pip has already been
+installed then ``python -m extractpip --upgrade`` will simply return without
+doing anything.


 Installing from source
@@ -532,6 +534,12 @@
   * This may take the form of separate packages with dependencies on each
 other so that installing the Python package installs the pip package
 and installing the pip package installs the Python package.
+  * Another reasonable way to implement this is to package pip separately but
+ensure that there is some sort of global hook that will recommend
+installing the separate pip package when a user executes ``pip`` without
+it being installed. Systems that choose this option should ensure that
+the ``pyvenv`` command still installs pip into the virtual environment
+by default.

 * Do not remove the bundled copy of pip.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Paul Tagliamonte]

On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote:
> Rationale
> =
> 
> Currently, on systems without a platform package manager and repository,
> installing a third-party Python package into a freshly installed Python
> requires first identifying an appropriate package manager and then
> installing it.

Howdy Donald,

Thanks for helping make Python better.

However, speaking as a Debian-folk (but not for the Debian-folk, I'll
let barry take care of that), many users of Python software don't even
know what pip is (or even that Python exists) -- as such, I find it very
unlikely that a development tool would be shiped as part of the Python
distribution in Debian. I don't see this changing, even with this pep.
python-pip is still installable, but I don't see it pulled in by
default.


> Even on systems that *do* have a platform package manager, it is unlikely to
> include every package that is available on the Python Package Index, and

Yes. This is true. However, it's not Debian's job to include all of
pypi. Pypi allows anyone to upload, and we have quite a bit of attention
to concerns such as providing source for everything (less of a concern
for Python, but pickles can still contain data not in the prefered form
of modification), and proper free software licensing.

We also have a concern about stability; so we manage all the package set
together to allow non-technical end-users to install stuff and not worry
about breaking their system. It's not always the case where you can
upgrade a library without breaking API.


I'm trimming the rest, since I don't want to get dragged into
side-conversations about pip as a package manager.


Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature
___
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] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

[Paul Tagliamonte]

On Thu, Sep 19, 2013 at 11:48:49PM +1000, Nick Coghlan wrote:
> That's OK, especially if running "pip" recommends installing "python-pip" and
> "pyvenv" and "extractpip" are also separated out so that running "pyvenv"
> recommends installing a suitable package that depends on both Python and
> "python-pip".

Sounds sane to me!

> We can add that to the PEP as an alternative approach for redistributors to
> take that still offers a reasonable end-user experience.

That'd really be great, and I'm sure it'd cut off the small bit of
concern some Debian-folk have about this stuff :)


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature
___
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] PEP 447: add type.__locallookup__

[Eric Snow]

On Thu, Sep 19, 2013 at 4:12 AM, Nick Coghlan  wrote:

> On 19 Sep 2013 20:00, "Paul Moore"  wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren 
> wrote:
> > > The first time a method is called the bridge looks for an Objective-C
> selector
> > > with the same name and adds that to the class dictionary. This works
> fine for normal
> > > method lookups, by overriding __getattribute__, but causes problems
> with super:
> > > super happily ignores __getattribute__ and peeks in the class __dict__
> which may
> > > not yet contain the name we're looking for and that can result in
> incorrect results
> > > (both incorrect AttributeErrors and totally incorrect results when the
> name is
> > > not yet present in the parent class' __dict__ but is in the
> grandparent's __dict__).
> >
> > As an alternative approach, could you use a custom dict subclass as
> > the class __dict__, and catch the peeking in the class __dict__ that
> > way? Or is this one of those places where only a real dict will do?
>
> Even Python 3 doesn't let you control the *runtime* type of the class
> dict, only the type used during evaluation of the class body.
>
> I've played with changing that - it makes for a rather special interpreter
> experience :)
>
Same here. :)  The PyDict_* API is not your friend for that.  It's why I
gave up on using a C OrderedDict for tp_dict (opting for a
__definition_order__ attribute on classes instead).

-eric
___
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] PEP 447: add type.__locallookup__

[Eric Snow]

On Thu, Sep 19, 2013 at 4:04 AM, Ronald Oussoren wrote:

> The C code uses PyDict_GetItem and AFAIK that doesn't look for a
> __getitem__
> implementation in a subclass.
>

Yeah, the PyDict_* API is definitely not subclass friendly. :(

-eric
___
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] PEP 447: add type.__locallookup__

[Eric Snow]

On Thu, Sep 19, 2013 at 3:49 AM, Ronald Oussoren wrote:

> On 14 Sep, 2013, at 8:30, Nick Coghlan  wrote:
> > However, I agree the current wording only conveys that to the handful
> > of people that already know exactly when in the attribute lookup
> > sequence that step occurs, which is a rather niche audience :)
>
> I've been fooling around with this long enough that I forgot that not
> everyone knows this :-).
>
> I guess I'd better include a clearer and more complete description
> of the current attribute resolution protocol and how my proposal affects
> that.  A nice readable Python implementation of that protocol would be nice
> to have regardless of the fate of this PEP.
>

+1

-eric
___
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] Use an empty def as a lambda

[Xavier Morel]

On 2013-09-19, at 23:17 , Nick Coghlan wrote:

> On 20 Sep 2013 07:04, "Joe Pinsonault"  wrote:
>> 
>> I think it's a great idea personally. It's explicit and obvious. "lamda"
> is too computer sciencey
> 
> This suggestion has been made many times, occasionally with the associated
> "must be contained in parentheses when used as an expression" caveat that
> is needed to avoid making the language grammar ambiguous at the statement
> level.

Examples of some of these times:

https://wiki.python.org/moin/AlternateLambdaSyntax
https://mail.python.org/pipermail/python-dev/2006-February/060415.html
https://mail.python.org/pipermail/python-dev/2006-February/thread.html#60415

Unless significant new insight is developed or Guido has picked the
functional bug at dropbox, merely suggesting a name change from lambda
to def (which has already been suggested in the past) probably isn't
going to cut it.
___
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] Use an empty def as a lambda

[Nick Coghlan]

On 20 Sep 2013 07:04, "Joe Pinsonault"  wrote:
>
> I think it's a great idea personally. It's explicit and obvious. "lamda"
is too computer sciencey

This suggestion has been made many times, occasionally with the associated
"must be contained in parentheses when used as an expression" caveat that
is needed to avoid making the language grammar ambiguous at the statement
level.

It mainly runs afoul of two problems:

- reusing the same keyword would make the additional syntactic restrictions
of the expression form even more confusing.
- Guido doesn't particularly like the notion of functions-as-expressions in
the first place (which is why lambda was on thin ice when Python 3 was
being designed), so doesn't actually mind the fact that people avoid using
them because they don't like the keyword.

Cheers,
Nick.

>
> On Sep 19, 2013 1:55 PM, "Ben Gift"  wrote:
>>
>> I think the lambda keyword is difficult to understand for many people.
It would be more pythonic to use an empty def call instead.
>>
>> For instance this:
>>
>> words.sort(key = lambda x: x[2])
>>
>> could look like this:
>>
>> words.sort(key = def (x): x[2])
>>
>> It's obvious and explicit that we're creating an unnamed, anonymous
function this way.
>>
>> ___
>> 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/joe.pinsonault%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/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] Use an empty def as a lambda

[Ben Gift]

I think the lambda keyword is difficult to understand for many people. It
would be more pythonic to use an empty def call instead.

For instance this:

words.sort(key = lambda x: x[2])

could look like this:

words.sort(key = def (x): x[2])

It's obvious and explicit that we're creating an unnamed, anonymous
function this way.
___
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] Use an empty def as a lambda

[Joe Pinsonault]

I think it's a great idea personally. It's explicit and obvious. "lamda" is
too computer sciencey
On Sep 19, 2013 1:55 PM, "Ben Gift"  wrote:

> I think the lambda keyword is difficult to understand for many people. It
> would be more pythonic to use an empty def call instead.
>
> For instance this:
>
> words.sort(key = lambda x: x[2])
>
> could look like this:
>
> words.sort(key = def (x): x[2])
>
> It's obvious and explicit that we're creating an unnamed, anonymous
> function this way.
>
> ___
> 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/joe.pinsonault%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] Use an empty def as a lambda

[Alexander Belopolsky]

On Thu, Sep 19, 2013 at 4:54 PM, Ben Gift  wrote:

> It would be more pythonic to use an empty def call instead.


No, it won't.  Python draws a very strong distinction between expressions
and statements.  This line has been blurred somewhat with the advent of
 comprehensions and the if-else expression, but it would still require more
benefit than three characters in a keyword saving to allow def use in both
statements and expressions.

The following, for example, does not look pythonic at all:

*def* transform(*seq*, *func*=*def*(*x*):*x*):
  ...

(Note that I attempted to emulate syntax highlighting to make my point.)
___
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] Use an empty def as a lambda

[Ryan Gonzalez]

Nice idea, BUT...

Not sure how a parser addition that supports it would go. Imagine this: if
you did a one-line function:

def test(x): print(x)

Python could interpret it two ways:

`def` `name` `lparen` `name` `rparen` `colon`...

OR, it could see it as a lambda-like thingamajig and throw a syntax error.
And, if someone accidentally wrote:

def (x): print(x)

Python should throw a syntax error. But it won't. And it'll take the person
a tad bit to realize he forgot the function name. Whoops.

And, it just would be odd in general.


On Thu, Sep 19, 2013 at 3:54 PM, Ben Gift  wrote:

> I think the lambda keyword is difficult to understand for many people. It
> would be more pythonic to use an empty def call instead.
>
> For instance this:
>
> words.sort(key = lambda x: x[2])
>
> could look like this:
>
> words.sort(key = def (x): x[2])
>
> It's obvious and explicit that we're creating an unnamed, anonymous
> function this way.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
___
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] Use an empty def as a lambda

[Steven D'Aprano]

On Thu, Sep 19, 2013 at 01:54:08PM -0700, Ben Gift wrote:
> I think the lambda keyword is difficult to understand for many people. It
> would be more pythonic to use an empty def call instead.

Hi Ben, and welcome! Is this your first post? I'm afraid I don't 
recognise your name.

I think this discussion belongs on the python-ideas mailing list rather 
than here. Proposals for changes to syntax and functionality are 
normally expected to gather feedback on python-ideas before coming to 
python-dev for final approval or rejection.

https://mail.python.org/mailman/listinfo/python-ideas

http://docs.python.org/devguide/communication.html



-- 
Steven
___
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