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 disc
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 synt
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 expres
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
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
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
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 conta
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 n
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 clas
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-D
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
> "pyt
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
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
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 orde
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 ``extract
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 install
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 ord
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
> *
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 ``e
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 Pytho
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 Pyth
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
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 modi
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
> * Conseq
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 avai
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.__geta
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 cla
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 overr
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,
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
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
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 sh
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
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*
34 matches
Mail list logo
