Has this REALLY not been discussed and rejected long ago?
> But I'm +1 on writing a PEP -- collect all these pros and cons in one
> place to save on future discussion. (And (good) PEP writing is a way to
> earn valuable Python Points!)
>
Exactly -- this is obvious enough that it WILL come
On Sun, Feb 12, 2017 at 3:38 PM, Steven D'Aprano wrote:
> On Sat, Feb 11, 2017 at 06:33:39PM +1300, Greg Ewing wrote:
>> Chris Angelico wrote:
>> >Which is why these proposals always seem to gravitate to "anything you
>> >can assign to",
>>
>> There might be some parsing
On Sat, Feb 11, 2017 at 06:33:39PM +1300, Greg Ewing wrote:
> Chris Angelico wrote:
> >Which is why these proposals always seem to gravitate to "anything you
> >can assign to",
>
> There might be some parsing difficulties with that, e.g.
>
>def foo(x)[5](y, z):
> ...
>
> That should
On Sat, Feb 11, 2017, at 00:33, Greg Ewing wrote:
> Chris Angelico wrote:
> > Which is why these proposals always seem to gravitate to "anything you
> > can assign to",
>
> There might be some parsing difficulties with that, e.g.
>
> def foo(x)[5](y, z):
>...
>
> That should be
Chris Angelico wrote:
Which is why these proposals always seem to gravitate to "anything you
can assign to",
There might be some parsing difficulties with that, e.g.
def foo(x)[5](y, z):
...
That should be acceptable, because foo(x)[5] is something
assignable, but foo(x) looks like
On 10Feb2017 1400, Stephan Hoyer wrote:
An important note is that ideally, we would still have way of indicating
that Spam.func should exists in on the Spam class itself, even if it
doesn't define the implementation. I suppose an abstractmethod
overwritten by the later definition might do the
On Fri, Feb 10, 2017 at 9:20 AM, Nick Coghlan wrote:
> What I would personally hope to see from the proposal is that given:
>
> class Spam:
> pass
>
> def Spam.func(self):
> return __class__
>
> the effective runtime behaviour would be semantically
Hi all,
For what it's worth, I believe that the "class extension" scenario from
Nick can be supported
using plain ol' metaclasses.
Not sure if this covers all desired capabilities, but at least the super()
mechanism works correctly.
Syntax is like this:
class Foo(metaclass=class_extend(Foo)):
On 02/10/2017 10:48 AM, Nick Timkovich wrote:
If everything was contained right in the same file, this is sanctioning
another way to do it (when there should only be one obvious way).
No worries, this way is not obvious.
If you have multiple modules/packages, horrors can evolve where a
Please keep in mind that this idea was not created to improve monkey
patching, it just happens to be one of the side effects due to classes
being objects. The main use case is the ability to set an instance's
callback function (see the Menu example), and to allow the class being
referenced in the
One thing that I don't think has been mentioned, but that brings me from
a +0 to a more negative outlook, is the interaction between this proposal
and some of python's existing class-related features, metaclasses and
descriptors. That is currently we know that function definition, and even
method
On 10 February 2017 at 16:25, Steven D'Aprano wrote:
> On Sat, Feb 11, 2017 at 01:25:40AM +1100, Chris Angelico wrote:
>
>> For what it's worth, my answers would be:
>>
>> __name__ would be the textual representation of exactly what you typed
>> between "def" and the open
On Sat, Feb 11, 2017 at 01:25:40AM +1100, Chris Angelico wrote:
> For what it's worth, my answers would be:
>
> __name__ would be the textual representation of exactly what you typed
> between "def" and the open parenthesis. __qualname__ would be built
> the exact same way it currently is, based
Hi list,
I'm quite neutral to this proposition, as it's not a use case I see
often myself needing.
On Fri, Feb 10, 2017 at 02:55:31PM +0100, Stephan Houben wrote:
[…]
> But if I don't understand the dot in `class foo.bar:', then what?
> It's probably somewhere buried in the language spec for
On Sat, Feb 11, 2017 at 1:16 AM, Nick Coghlan wrote:
> But what do __name__ and __qualname__ get set to?
>
> What happens if you do this at class scope, rather than at module
> level or inside another function?
>
> What happens to the zero-argument super() support at class
On 10 February 2017 at 12:16, Chris Angelico wrote:
> On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote:
>> Furthermore, once we open up this possibility, I would expect requests
>> for things like
>>
>> func_table = {}
>> func_table["foo"] =
On 10 February 2017 at 14:00, Markus Meskanen wrote:
>> > I've started working on a PEP for this since most people seem to be for
>> > it.
>>
>> I don't know how you get "most people" -- there's only been a handful of
>> responses in the few hours since the original
On 10 February 2017 at 13:55, Stephan Houben wrote:
> My point would be that the new syntax *also* requires one to figure out what
> the new syntax does.
This is an extremely good point. It is mentioned when new syntax is
proposed (the term often used is "discoverability")
>
> > I've started working on a PEP for this since most people seem to be for
> it.
>
> I don't know how you get "most people" -- there's only been a handful of
> responses in the few hours since the original post. And apart from one
> explicit -1, I read most of them as neutral, not in favour.
>
Hi all,
I would like to add one more generic remark about syntax extensions,
regarding something
Markus said and which has bothered me before, also related to other syntax
proposals.
"Decorator approach is no different from doing `Foo.bar = bar` under the
function definition I think, except it
On Fri, Feb 10, 2017 at 02:28:25PM +0200, Markus Meskanen wrote:
> I've started working on a PEP for this since most people seem to be for it.
I don't know how you get "most people" -- there's only been a handful of
responses in the few hours since the original post. And apart from one
I've started working on a PEP for this since most people seem to be for it.
Will see how it turns out.
On Fri, Feb 10, 2017 at 2:13 PM, Joao S. O. Bueno
wrote:
> I am definetelly -1 to this idea.
>
> But since you are discussing this seriously, one nice thing is to
>
I am definetelly -1 to this idea.
But since you are discussing this seriously, one nice thing is to
recall how Javascript does that:
`function () ` is an expression that returns the created
function, and thus can be assigned to anything on
the left side.
Of course, that would throw us back to a
On Fri, Feb 10, 2017 at 11:02 PM, Thomas Kluyver wrote:
> On Fri, Feb 10, 2017, at 11:05 AM, Chris Angelico wrote:
>> * What would the __name__ be? In "def ham.spam():", is the name "spam"
>> or "ham.spam"? Or say you have "def x[0]():" - is the name "x[0]" or
>> something
On Fri, Feb 10, 2017, at 11:05 AM, Chris Angelico wrote:
> * What would the __name__ be? In "def ham.spam():", is the name "spam"
> or "ham.spam"? Or say you have "def x[0]():" - is the name "x[0]" or
> something else?
I'd say 'spam' in the first case, and a special value like '' in the latter.
On Fri, Feb 10, 2017 at 10:05:30PM +1100, Chris Angelico wrote:
> * What would the __name__ be? In "def ham.spam():", is the name "spam"
> or "ham.spam"?
"spam" of course, just like it is now:
py> class Ham:
... def spam(self):
... ...
...
py>
py> Ham.spam.__name__
'spam'
You
On 10 February 2017 at 11:16, Chris Angelico wrote:
> On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote:
>> Furthermore, once we open up this possibility, I would expect requests
>> for things like
>>
>> func_table = {}
>> func_table["foo"] =
On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote:
> Furthermore, once we open up this possibility, I would expect requests
> for things like
>
> func_table = {}
> func_table["foo"] = lambda a, b: a+b
> def func_table["bar"] (a,b):
> return a-b
>
> pretty
On 10 February 2017 at 10:45, Markus Meskanen wrote:
> Keep in mind that the extra syntax is *very* minor, and goes hand-to-hand
> with the existing attribute access syntax. Basically it's taking the
> existing syntax to one more place, where it in my opinion should have
On Fri, Feb 10, 2017 at 9:45 PM, Markus Meskanen
wrote:
>> That saves one line, at the cost of introducing even more complexity to
>> the language.
>>
>> Are these use-cases common enough to justify the extra syntax?
>
>
> Keep in mind that the extra syntax is *very*
30 matches
Mail list logo