[Python-ideas] Re: Allow modifying message of TypeError from NotImplemented

[Serhiy Storchaka]

19.06.21 06:30, wyz2...@163.com пише:
> Python raises TypeError when NotImplemented is returned from __add__, 
> __invert__ etc. and __radd__ etc. aren't available.
> However, this disallows the customization of error messages. For example, in 
> Python 3.8, __float__ etc. were removed from complex to allow methods like 
> __rfloat__. But this makes abs(z) undiscoverable for many users. The original 
> error message is very helpful.
> I suggest to make a way for this usage. Maybe NotImplementedType can accept 
> *args, and NotImplemented can be callable, equal to __init__:
> 
 class A:
> def __add__(self, other):
> return NotImplemented  # Just like before
> def __neg__(self, other):
> return NotImplemented(f'bad operand type for unary -: 
> {type(self).__name__!r}; use ~ to invert')  # <--
> def __invert__(self):
> return ~5
 a = A()
 a + 2
> TypeError: unsupported operand type(s) for +: 'A' and 'int'
 -a
> TypeError: bad operand type for unary -: 'A'; use ~ to invert
 ~a
> -6

NotImplemented is a singleton. And all code which tests for
NotImplemented does it by checking identity. Returning any other object
instead of the NotImplemented would not work.

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R6P566R4YQBRRB3KMEROK7FGSRIWJXCO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: channel or message queue in asyncio

[Rene Nejsum]

Sound like a good idea. 

Would be supernice if the channel could receive (ch.get()) multiple types of 
events like: network messages (socket), UI input (mouse and keyboard events), 
file events (select?), timeouts, kernel events (shutdown) and signals besides 
internal messages (ch.put) 

br
/Rene
___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/35LMAHKRJTBJOGLBVBA4Q34RZXBDK255/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow modifying message of TypeError from NotImplemented

[Jeff Allen]

On 19/06/2021 05:38, Steven D'Aprano wrote:

On Sat, Jun 19, 2021 at 03:30:05AM -, wyz2...@163.com wrote:


Python raises TypeError when NotImplemented is returned from __add__,
__invert__ etc. and __radd__ etc. aren't available.

Roughly correct. It's more complex than that.

I just wanted to add that NotImplemented is *only* for binary (and 
binary comparison) operators.


https://docs.python.org/3/library/constants.html?highlight=notimplemented#NotImplemented

Ok, also when __length_hint__ can't help. Generally though, other 
contexts from which the special method might be called do not check for it.


--

Jeff Allen

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6ERUPVCUFKYKHMT5CUNVRZ4ZRIBMNJSZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Marc-Andre Lemburg]

On 19.06.2021 17:17, Serhiy Storchaka wrote:
> 19.06.21 18:12, Marc-Andre Lemburg пише:
>>> But there could be endless debate about whether flatten( ("x", "y") ) should
>>> return a list or a tuple...
>>
>> Have it return an iterator :-)
> 
> flatten = itertools.chain.from_iterable

Well, like I said: modulo the discussion around what "flatten"
should mean, e.g. you will probably want to have flatten() go
a certain number of levels deep and not necessarily flatten
strings.

But yes, such a definition is certainly a good start.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 19 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5C2JB3QU7E4S5MMRI7NCRSZ52MFKZCC5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

19.06.21 18:12, Marc-Andre Lemburg пише:
>> But there could be endless debate about whether flatten( ("x", "y") ) should
>> return a list or a tuple...
> 
> Have it return an iterator :-)

flatten = itertools.chain.from_iterable

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SIUTAQ5UGRQ7SDDOXQJ2LWLFUJ6SOKEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Marc-Andre Lemburg]

On 19.06.2021 17:03, Guido van Rossum wrote:
> I think I would find flatten(a) more readable than [*chunk for chunk in a], 
> and
> more discoverable: this operation is called "flatten" in other languages, so
> users are going to search the docs or help for that.

+1

> But there could be endless debate about whether flatten( ("x", "y") ) should
> return a list or a tuple...

Have it return an iterator :-)

flatten() would be in the same category of builtins as reversed()
and enumerate().

I think we'll see more discussion about exactly how to flatten
the structures, e.g. do you stop at strings or flatten them into
lists of characters ? But I'm sure we'd reach a sensible default
which makes most happy.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 19 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3TKI5PMVNMBXBXEOFIVZTX77MSAVJVYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Guido van Rossum]

On Fri, Jun 18, 2021 at 10:15 PM Steven D'Aprano 
wrote:

> On Fri, Jun 18, 2021 at 09:33:49PM -0700, Guido van Rossum wrote:
>
> > Now, this shouldn't be considered an airtight argument against [*chunk
> for
> > ...], but it does show that there's no straightforward explanation of its
> > meaning through equivalence (like the OP seemed to think), and I think
> this
> > is what Serhiy was also getting at in his post.
>
> Indeed. I was initially confused by what Ben thought was a simple and
> obvious connection between star unpacking in some other contexts and his
> suggestion for comprehensions. The analogy with `[*a]` never crossed my
> mind, and I don't think that we should look at this as literally the
> application of sequence unpacking in a comprehension, for reasons I gave
> in my earlier post.
>
> But having it explained to me, I think that treating this as an analogy
> rather than literal unpacking works. We already give unary star and
> double star a number of meanings, not all of which are related:
>
>
> - import wildcard;
>
> - capture positional and keyword parameters `def func(*args, **kw)`
>
> - sequence and keyword unpacking in function calls;
>
> - sequence capture in assignment targets `head, *a, tail = items`
>
> - sequence unpacking in list etc displays;
>
>
> Have I missed any?
>

What you seem to be (intentionally) missing is that all but the import
wildcard *are* closely related, even though they are specified separately
in the syntax. (Saying that they are unrelated would be like saying that
the name occurring after a 'def' keyword and the function name occurring in
a function call are unrelated. :-)


> We could define *star comprehensions* as syntactic sugar for nested
> comprehensions, to aid in flattening nested sequences and mappings.
>
> [*expression for name in sequence if condition]
>
> results in this:
>
> result = []
> for name in sequence:
> if condition:
> for tmp in expression:
> result.append(tmp)
> return result
>
> I haven't thought deeply into this, but I think that if the starred
> expression is anything but a simple name, it may require parentheses?
>
> *name  # okay
> *(name.attr or [])  # everything else needs parens
>

The grammar for the last three forms you give allows pretty much any
expression, for example
https://github.com/python/cpython/blob/291848195f85e23c01adb76d5a0ff9c6eb7f2614/Grammar/python.gram#L504-L506


> Alternatively, we could just do something that people have been asking
> about since Python 1.5 and provide a flatten builtin or list method :-)
>

Probably a builtin, since in my mind I want to write flatten(a), never
a.flatten(), and it would be useful for any kind of sequence of sequences
(or even iterable of iterables).

I think I would find flatten(a) more readable than [*chunk for chunk in a],
and more discoverable: this operation is called "flatten" in other
languages, so users are going to search the docs or help for that.

But there could be endless debate about whether flatten( ("x", "y") )
should return a list or a tuple...

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KTZLOA6DIRIJ4QHCZBVQGD36AX6JZQ5V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Ricky Teachey]

On Sat, Jun 19, 2021, 5:00 AM Steven D'Aprano  wrote:

Why are we arguing about `[x,y for y in a]` when nobody has requested
that syntax?


--
Steve


I've wanted many times to be able to write the star unpack there, even as a
relatively modestly experienced python user. But it has never occurred to
me to write this one.
___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FGIJE5HY3GQ775EPGHLATPXMLE37PN5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

19.06.21 07:33, Guido van Rossum пише:
> [1] Does the unary star operator have a name when used like this in
> Python? In JavaScript the equivalent syntax ("...chunk", where the "..."
> are a literal ellipsis) is called "spread". We could borrow this term.

I would not call is an operator. Operator forms an expression, but *x is
not an expression. It is not more operator than colon.

Is there such term as "syntax form" in English? I would call *x, x for x
in a, x:y syntax forms. They are not expressions, but can be part of
expression. They can only be used in some context, and the meaning
depends on the context (x:y are two different things in {x:y} and in
a[x:y]).

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IMA7PCUKNNUYPDBODYJBFPXQWVFOAYMW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

18.06.21 18:42, Mathew Elman пише:
> I don't see how allowing 
> 
> [x, y for x in a] 
> 
> follows from allowing 
> 
> [*chunk for chunk in list_of_lists].

Because in all other contexts you can replace `*(x, y)` with `x, y`.

f(*(x, y)) => f(x, y)
[*(x, y)] => [x, y]
{*(x, y)} => {x, y}
*(x, y), => x, y, => (x, y)

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C3DS6LLJFLHHGO4DTNCNE76DT23IDZ6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Steven D'Aprano]

Why are we arguing about `[x,y for y in a]` when nobody has requested 
that syntax?


-- 
Steve
___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/P42P3BOUGPO6JYPXD2QCGSLRRB72HOK3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

18.06.21 17:38, Guido van Rossum пише:
> Note the ambiguity around whether the user might have meant
> 
>     [x,(y for y in a)]
> 
> or
> 
>     [(x, y) for y in a]

Yes, I think that it could be interpreted in one of the following ways:

 [x, (y for y in a)]
 [x, *(y for y in a)]
 [(x, y) for y in a]
 [*(x, y) for y in a]  # if allow [*chunk for ...]

Any interpretation can be well-justified and formally non-ambiguous once
we choose the one to be allowed. But it will still *look* ambiguous, so
it is better to avoid such syntax in Python which is famous for its
clear syntax.

I withed that I could write just [*chunk for ...] several times per
year, but I understand that there were reasons to not allow it.

___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G2IQF7OYBCCRC4OKDK3DR4ZM4CE3YTRV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Chris Angelico]

On Sat, Jun 19, 2021 at 5:13 PM Rob Cliffe via Python-ideas
 wrote:
>
>
>
> On 19/06/2021 05:33, Guido van Rossum wrote:
>
> On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano  wrote:
>>
>> On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
>>
>> > Note the ambiguity around whether the user might have meant
>> >
>> > [x,(y for y in a)]
>> >
>> > or
>> >
>> > [(x, y) for y in a]
>>
>> We already have a rule to disambiguate generator comprehensions: they
>> must always be parenthesized unless they are already parenthised:
>>
>> g = (y for y in a)  # parens required
>> t = 999, (y for y in a)  # parens required
>>
>> func((y for y in a))  # inner parens optional
>
>
> Yes, that's exactly what I was referring to.
>
>> > That’s a good enough reason for me to also disallow *chunks.
>>
>> That's an odd way to look at it. We must disallow an unambiguous syntax
>> because a completely different syntax would have been ambiguous if we
>> didn't already have a rule in place that disambiguates it.
>
>
> Maybe, but the two are not unrelated. In other contexts, when we accept 
> "*chunk", and 'chunk' equals "1, 2", we also accept "1, 2" in the original 
> position, and it means the same thing. This is useful as an explanation of 
> the semantics of the unary '*' operator[1]. For example
>
> # Given:
> chunk = 1, 2
>
> # Equivalent:
> f(*chunk)
> f(1, 2)
>
> # Equivalent:
> [*chunk]
> [1, 2]
>
> So then if we were to allow this:
>
> [*chunk for chunk in ...]
>
> we ought to consider this equivalent:
>
> [1, 2 for chunk in ...]
>
> (Note there's nothing that says the expressions to the left of 'for' need to 
> involve the for-control variable 'chunk'. :-)
>
> Now, this shouldn't be considered an airtight argument against [*chunk for 
> ...], but it does show that there's no straightforward explanation of its 
> meaning through equivalence (like the OP seemed to think), and I think this 
> is what Serhiy was also getting at in his post.
>
> __
> [1] Does the unary star operator have a name when used like this in Python? 
> In JavaScript the equivalent syntax ("...chunk", where the "..." are a 
> literal ellipsis) is called "spread". We could borrow this term.
>
> I'm not convinced.
> 1, 2 + x
> does not mean the same as
> chunk + x
> but it would be if there were parentheses around the "1, 2".  The same 
> applies to your example.

A closer equivalent would be:

*chunk + x

which is illegal.

ChrisA
___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FSKCXUN4X7WR3SUAF522YPVZ6PUV7LRV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Rob Cliffe via Python-ideas]

On 19/06/2021 05:33, Guido van Rossum wrote:
On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano > wrote:


On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:

> Note the ambiguity around whether the user might have meant
>
>     [x,(y for y in a)]
>
> or
>
>     [(x, y) for y in a]

We already have a rule to disambiguate generator comprehensions: they
must always be parenthesized unless they are already parenthised:

    g = (y for y in a)  # parens required
    t = 999, (y for y in a)  # parens required

    func((y for y in a))  # inner parens optional

Yes, that's exactly what I was referring to.

> That’s a good enough reason for me to also disallow *chunks.

That's an odd way to look at it. We must disallow an unambiguous
syntax
because a completely different syntax would have been ambiguous if we
didn't already have a rule in place that disambiguates it.


Maybe, but the two are not unrelated. In other contexts, when we 
accept "*chunk", and 'chunk' equals "1, 2", we also accept "1, 2" in 
the original position, and it means the same thing. This is useful as 
an explanation of the semantics of the unary '*' operator[1]. For example


# Given:
chunk = 1, 2

# Equivalent:
f(*chunk)
f(1, 2)

# Equivalent:
[*chunk]
[1, 2]

So then if we were to allow this:

[*chunk for chunk in ...]

we ought to consider this equivalent:

[1, 2 for chunk in ...]

(Note there's nothing that says the expressions to the left of 'for' 
need to involve the for-control variable 'chunk'. :-)


Now, this shouldn't be considered an airtight argument against [*chunk 
for ...], but it does show that there's no straightforward explanation 
of its meaning through equivalence (like the OP seemed to think), and 
I think this is what Serhiy was also getting at in his post.


__
[1] Does the unary star operator have a name when used like this in 
Python? In JavaScript the equivalent syntax ("...chunk", where the 
"..." are a literal ellipsis) is called "spread". We could borrow this 
term.



I'm not convinced.
    1, 2 + x
does not mean the same as
    chunk + x
but it would be if there were parentheses around the "1, 2".  The same 
applies to your example.

Best wishes
Rob Cliffe
___
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IY3YRVXDW47NL44IHODOWUA4DPKVFS2H/
Code of Conduct: http://python.org/psf/codeofconduct/