Hello,
On Thu, 17 Dec 2020 00:03:51 +0100
Marco Sulla wrote:
> On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> wrote:
> > But still, are there Python implementations which compile "(a.b)()"
> > faithfully, with its baseline semantic meaning? Of course
> > there're.
>
> OK, Paul, why don't yo
On 17/12/20 9:56 pm, Paul Sokolovsky wrote:
It's about a new exciting
(hmm, we'll see) feature which, turned out, was there all this time,
... I'm
asking fellow Python programmers if they recognize it. If they do, we
can consider how to get more from that feature,
I don't see how we can get any
On Thu, Dec 17, 2020 at 8:58 AM Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 17 Dec 2020 00:03:51 +0100
> Marco Sulla wrote:
>
> > On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> > wrote:
> > > But still, are there Python implementations which compile "(a.b)()"
> > > faithfully, with its baselin
Hello,
On Thu, 17 Dec 2020 12:46:17 +1300
Greg Ewing wrote:
> On 17/12/20 8:16 am, Paul Sokolovsky wrote:
> > With all the above in mind, Python3.7, in a strange twist of fate,
> > and without much ado, has acquired a new operator: the method call,
> > ".()".
>
> > CPython3.6 and below didn'
On Wed, Dec 16, 2020 at 10:16:01PM +0300, Paul Sokolovsky wrote:
> With all the above in mind, Python3.7, in a strange twist of fate, and
> without much ado, has acquired a new operator: the method call, ".()".
No it hasn't. That's not a language feature, it is not documented as a
language featu
On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously
"optimizes" it,
but simply because it's *unable* to represent the difference between
"a.b()" and "(a.b)()".
I'm pretty sure whoever added the optimisation fully intended it
to a
Hello,
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing wrote:
> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> > CPython compiles "(a.b)()" using LOAD_METHOD not because it
> > consciously "optimizes" it, but simply because it's *unable* to
> > represent the difference between "a.b()" and "(a.b)()
Many open-source developers are committing to several projects, developing
package (for Python). A fraction of developers might need funds for the
continuing development of several projects and to pursue contributing. Sadly,
there is no direct short way for donors to fund python package develope
Here's a related idea you might be interested in:
https://github.com/pypa/pip/issues/5970
On Thu, Dec 17, 2020, 8:19 AM Yash Jha wrote:
> Many open-source developers are committing to several projects, developing
> package (for Python). A fraction of developers might need funds for the
> contin
On 18/12/20 1:52 am, Paul Sokolovsky wrote:
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing wrote:
On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
a) (a.b)() syntax
b) apply() being resurrected
I can't answer that without knowing what alternative semantics
you have in mind for (a.b)(). You haven'
Hello,
On Fri, 18 Dec 2020 03:05:02 +1300
Greg Ewing wrote:
> On 18/12/20 1:52 am, Paul Sokolovsky wrote:
> > On Fri, 18 Dec 2020 01:23:34 +1300
> > Greg Ewing wrote:
> >> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> >>> a) (a.b)() syntax
> >>> b) apply() being resurrected
> >>
> >> I c
Hi all,
Dataclasses provide a unique way of creating parameter bags with decent
typing and validation options. However, they currently lack a meaningful
way of detecting a missing value as a dataclass interface consumer.
Current behavior allows us to specify defaults per property, but defining a
I really like this idea!
I have very often had to create my own MISSING global in modules where None
might actually be a legitimate value for the dataclass member.
And additionally when I am doing thorough type hinting, I haved at times
ended up not only have to do the MISSING object, but a Missi
Hello,
On Thu, 17 Dec 2020 10:03:14 +
Stestagg wrote:
[]
> > > > But still, are there Python implementations which compile
> > > > "(a.b)()" faithfully, with its baseline semantic meaning? Of
> > > > course there're.
> > >
> > > OK, Paul, why don't you propose a PR and a bug report about
Thanks a lot! You guys provide quite better ways than mine!
finally for 1 or 2 arguments, I would use
```
a = a if a is None else self.a
```
if there are too many arguments, I would like to adopt the decoration idea
(Ricky Teachey), which seems better.
Sorry for the `eval` part error, that is not
Damn, I'm a careless programmer for sure.
```
a = a if a is not None else self.a
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas
Your `decorator` idea seems so sweet.
I'm trying to apply it.
> Seems like the type of thing better put in your own toolkit.
Yes, it seems not necessary to put into std lib since we can handle it by
ourselves without producing too many lines of codes.
__
On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky wrote:
> This is not some completely new restriction. For example, following
> already doesn't work in Python:
>
> class A:
> pass
>
> o = A()
> o.__add__ = lambda self, x: print("me called")
>
> o + A() # lambda above is never called
>
But the
Hello,
On Fri, 18 Dec 2020 06:09:56 +1100
Chris Angelico wrote:
> On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky
> wrote:
> > This is not some completely new restriction. For example, following
> > already doesn't work in Python:
> >
> > class A:
> > pass
> >
> > o = A()
> > o.__add__ = la
On 12/17/20 11:09 AM, Chris Angelico wrote:
> I said I wasn't going to respond, but this one is SUCH a common
> misunderstanding that I don't want people led astray by it.
>
> "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"!
Okay, what is it implemented as?
--
~Ethan~
__
17.12.20 21:58, Ethan Furman пише:
> On 12/17/20 11:09 AM, Chris Angelico wrote:
>> "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"!
>
> Okay, what is it implemented as?
First, it can use not only method __add__ of the type of a, but also
method __radd__ of the type of b.
On Fri, Dec 18, 2020 at 01:23:34AM +1300, Greg Ewing wrote:
> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> >CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously
> >"optimizes" it,
> >but simply because it's *unable* to represent the difference between
> >"a.b()" and "(a.b)()".
On 2020-12-15 5:16 a.m., Paul Sokolovsky wrote:
>> The compiler applies it when it
>> can see the only use of the attribute is an immediately following
>> call.
> You're now just a step away from the "right answer". Will you make it?
> I did. And sorry, the whole point of the discussion if to see
On Thu, Dec 17, 2020 at 03:52:51PM +0300, Paul Sokolovsky wrote:
> But I did by now, and you didn't need to wait for me to do it, because
> "(a.b)()" does *exactly* what *you* or anybody else would think it
> does, based on your knowledge of what grouping parens in the
> expressions do. So again,
Hello,
On Thu, 17 Dec 2020 15:28:47 -0500
Alexandre Brault wrote:
> On 2020-12-15 5:16 a.m., Paul Sokolovsky wrote:
> >> The compiler applies it when it
> >> can see the only use of the attribute is an immediately following
> >> call.
> > You're now just a step away from the "right answer". W
On 18/12/20 7:01 am, Paul Sokolovsky wrote:
Now, what if you have an object attribute which stores a callable (no
matter is it's bound method, a function, a class, or whatever)?
You will need to call it as "(obj.callable_ref)(arg, kw=val)".
So, in strict mode, this:
import random
n = random.c
Hello,
On Fri, 18 Dec 2020 12:29:10 +1300
Greg Ewing wrote:
> On 18/12/20 7:01 am, Paul Sokolovsky wrote:
> > Now, what if you have an object attribute which stores a callable
> > (no matter is it's bound method, a function, a class, or whatever)?
> >
> > You will need to call it as "(obj.calla
On 18/12/20 1:48 pm, Paul Sokolovsky wrote:
So, it's already clear that mod.func() syntax will continue to work as
before. I don't foresee any problems with implementing that, do you?
What about this:
import random
class A:
def choice(self, stuff):
return stuff[0]
a = A()
def f(
Hello,
On Fri, 18 Dec 2020 17:42:26 +1300
Greg Ewing wrote:
> On 18/12/20 1:48 pm, Paul Sokolovsky wrote:
> > So, it's already clear that mod.func() syntax will continue to work
> > as before. I don't foresee any problems with implementing that, do
> > you?
>
> What about this:
>
> import ra
29 matches
Mail list logo
