[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Brendan Barnwell]

On 2021-09-03 14:01, Kevin Mills wrote:

As I said before, the "1,2,3" in `f(1,2,3)` has a very different
meaning than the "1,2,3" in `d[1,2,3]`. One is a (comma-separated)
list of expressions, and one is a single expression, a tuple.

`*(1,2,3)` does not evaluate to the tuple `(1,2,3)`, so I don't think
expecting it to do so in the context of d[*(1,2,3)] makes sense. And,
I would argue that having it to so would be far more inconsistent -
why does it evaluate to the tuple `(1,2,3)` in the context of
`d[*(1,2,3)]`, but not in the context of `f(*(1,2,3))`?


	I agree with others that your proposal would make things confusing. 
It's true that `*(1, 2, 3)` doesn't evaluate to the tuple `(1, 2, 3)`, 
but nonetheless `*(1, 2, 3)` does expand to something that remains 
contained within the argument list where it occurs.  Your proposal would 
cause the `x` in `[*x]`to "leak" beyond the indexing brackets and (as 
you note in another message) would actually create additional indexing 
brackets, whereas there's no situation where existing *-expansion 
creates additional function calls.


	In other words, currently `*` can turn what looks like one function 
call with one thing inside it into one function call with several things 
inside it.  You are proposing to make it so `*` can turn one indexing 
operation with one thing inside it into several indexing operations each 
with one thing inside it.  I think that is quite different.


	To my mind, the operation of indexing itself is not sufficiently 
parallel to function calls to warrant a crossover of `*` between the 
two.  A function call can have multiple arguments, but an indexing 
operation only ever has one index (albeit that index may be a tuple or 
other composite object).  So there is no scope for "unpacking" because 
there are no extra "slots" (akin to separate arguments) to unpack into.


	You're proposing to not just unpack the indexes, but to "unpack" the 
entire indexing operation into multiple such operations, which is a 
bridge too far for (as it appears to be for others).



Also, from a practical perspective, what would even be the point in
allowing the syntax here if `d[*x]` meant exactly the same thing as
`d[x]` (or `d[tuple(x)]` if it's not already a tuple)?


	I agree there would be little point in that.  But that doesn't mean 
that the `*` is now "free" to be used for some other use in this 
context.  Rather, because the existing unpacking behavior of `*` doesn't 
have much use in an indexing context, that to me means that use of `*` 
is "blocked" in this context and we can't use it for anything.  It's 
better to have it not mean anything at all than have it mean something 
different and confusing.


	I would support adding some kind of multi-getter function to the 
stdlib.  I would even support adding multi-get methods to list, dict, 
and tuple so that you could call `my_list.multiget(1, 2, 3)` or 
`my_dict.multiget(*some_keys)` and have it do a series of nested 
indexes.  But I don't think we should add syntax for this, or at least I 
think we should not use `*`-unpacking-like syntax for it.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
   --author unknown
___
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/3P5T77YH6VB4OXNQTO5EK4HCCMH3ELYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Matsuoka Takuo]

Dear Kevin Mills,

I understand your point to some degree, but could you please clarify
it further by answering the following question?

Which of the following expressions will be valid in your model, and as
what currently valid expression will each of the valid ones
evaluated? (For instance, I understand d[*(1,2,3)] will be valid and
evaluated as d[1][2][3] .  Some may seem redundant, but just to be
sure...)

(1) d[*(1,2,3), ]
(2) d[*(),1,2,3,*()]
(3) d[*(1,2,3),*()]
(4) d[]


The reason why this could clarify your point is, for example, it's
tempting to possibly incorrectly assume all (1) to (3) are going to be
valid and equivalent to d[*(1,2,3)] (as their counterparts are in a
function call), which could be a source of confusion since some of
them might be too hard to not interpret as d[1,2,3] if
valid. (E.g., I happen to have recently proposed (1) to (3) and the
like as valid expressions equivalent to d[1,2,3] while not giving any
interpretation to d[*x] here

https://mail.python.org/archives/list/python-ideas@python.org/message/BEGGQEU6MG7RYIY7HB4I6VQ23L6TXB6H/

with a summary

https://mail.python.org/archives/list/python-ideas@python.org/message/KF37FMD5K5M2ZVTJO6IS3J6M7HHE4VRU/
)

Best regards,
Takuo
___
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/PNPRDPWDXN2ONRL2OHQDI5LFZIHJIBYO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Guido van Rossum]

On Fri, Sep 3, 2021 at 5:37 PM Christopher Barker 
wrote:

> On Fri, Sep 3, 2021 at 1:13 PM Guido van Rossum  wrote:
>
>> But the text of the error message will explain all you need for debugging
>> and testing.
>>
>
> debugging, probably yes.
>
> But it's a lot easier to check that a particular Exception is raised than
> to have to check for the Exception and also parse the error message.
>
> Honestly, I haven't figured out a use case for this particular example,
> but I do appreciate finer grained Exceptions in general.
>

Hm. More is not always better. (Today's entry for the 20th "Zen of Python"
line. :-)

-- 
--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/JXXR2LUZKYM4JZ6ID4FLHGCEPHRUAMIW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Christopher Barker]

On Fri, Sep 3, 2021 at 1:13 PM Guido van Rossum  wrote:

> But the text of the error message will explain all you need for debugging
> and testing.
>

debugging, probably yes.

But it's a lot easier to check that a particular Exception is raised than
to have to check for the Exception and also parse the error message.

Honestly, I haven't figured out a use case for this particular example, but
I do appreciate finer grained Exceptions in general.

-CHB

However, finer grained exception may help with debugging and testing.
>
>
>> -CHB
>>
>>
>>
>>
>> find it unlikely that someone would write
>>>
>>> try:
>>> sum(x, y, z)
>>> except TypeError:
>>> ...
>>>
>>> If you bury the sum() call deep inside other code, I'd say your
>>> try/except net is too wide.
>>>
>>> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin <
>>> oscar.j.benja...@gmail.com> wrote:
>>>
 On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka 
 wrote:
 >
 > There are two different kinds of TypeError: if the end user passes an
 > instance of wrong type and if the author of the library makes an error
 > in implementation of some protocols.
 >
 > For example, len(obj) raises TypeError in two cases: if obj does not
 > have __len__ (user error) and if obj.returns non-integer
 (implementation
 > error). for x in obj raises TypeError if obj does not have __iter__
 > (user error) and if iter(obj) does not have __next__ (implementation
 error).
 >
 > User errors can be fixed on user side, implementation errors can only
 be
 > fixed by the author of the class. Even if the user and the author is
 the
 > same person, these errors point to different places of code.
 >
 > Would it be worth to add a special TypeError subclass for
 implementation
 > errors to distinguish them from user errors? How to name it
 > (ImplementationError, ProtocolError, etc)?

 I think that it would be good to make TypeError more fine-grained.
 Another example is:

 >>> sum(1, 2, 3)
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: sum() takes at most 2 arguments (3 given)

 There can be reasons in library code to catch TypeError that might
 arise from bad user input but in those situations you would usually
 not want to catch this TypeError. The error from calling a function
 with the wrong number of arguments would usually mean a bug in the
 library code which should not be caught. Conversely if the user input
 is a callable and you do want to catch the error resulting from it
 being called with the wrong number of arguments then catching
 TypeError is too broad again. Something like BadArgumentsError would
 be better.
>>>
>>>

 --
 Oscar
 ___
 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
 Code of Conduct: http://python.org/psf/codeofconduct/

>>>
>>>
>>> --
>>> --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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> --
>> Christopher Barker, PhD (Chris)
>>
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/Q5EPN4YQ32JYN3SFDDLKYCC7GMKBAGVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Guido van Rossum]

On Fri, Sep 3, 2021 at 5:04 PM Oscar Benjamin 
wrote:

> On Fri, 3 Sept 2021 at 17:32, Guido van Rossum  wrote:
> >
> > On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>
> >> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka 
> wrote:
> >> >
> >> > There are two different kinds of TypeError: if the end user passes an
> >> > instance of wrong type and if the author of the library makes an error
> >> > in implementation of some protocols.
> >> >
> >> > For example, len(obj) raises TypeError in two cases: if obj does not
> >> > have __len__ (user error) and if obj.returns non-integer
> (implementation
> >> > error). for x in obj raises TypeError if obj does not have __iter__
> >> > (user error) and if iter(obj) does not have __next__ (implementation
> error).
> >> >
> >> > User errors can be fixed on user side, implementation errors can only
> be
> >> > fixed by the author of the class. Even if the user and the author is
> the
> >> > same person, these errors point to different places of code.
> >> >
> >> > Would it be worth to add a special TypeError subclass for
> implementation
> >> > errors to distinguish them from user errors? How to name it
> >> > (ImplementationError, ProtocolError, etc)?
> >>
> >> I think that it would be good to make TypeError more fine-grained.
> >> Another example is:
> >>
> >> >>> sum(1, 2, 3)
> >> Traceback (most recent call last):
> >>   File "", line 1, in 
> >> TypeError: sum() takes at most 2 arguments (3 given)
> >>
> >> There can be reasons in library code to catch TypeError that might
> >> arise from bad user input but in those situations you would usually
> >> not want to catch this TypeError. The error from calling a function
> >> with the wrong number of arguments would usually mean a bug in the
> >> library code which should not be caught. Conversely if the user input
> >> is a callable and you do want to catch the error resulting from it
> >> being called with the wrong number of arguments then catching
> >> TypeError is too broad again. Something like BadArgumentsError would
> >> be better.
> >
> > The question is, would anyone ever want to make a distinction between
> the two in *real* code? I find it unlikely that someone would write
> >
> > try:
> > sum(x, y, z)
> > except TypeError:
> > ...
> >
> > If you bury the sum() call deep inside other code, I'd say your
> try/except net is too wide.
>
> You've misunderstood. I do *not* want to catch the exception from sum(x,
> y, z).
>

I know you don't. My point with that example was to show how unlikely it is
that someone would write that in the first place (since the code would
always fail rather than in specific cases).


> Sometimes a situation arises that there is a problem involving an
> exception being raised that is best fixed by catching the exception.
> Python does not provide much of a programmatic API for inspecting
> exceptions beyond simply choosing which class of exceptions to catch.
> That makes it important to limit the class of exceptions caught as
> carefully as possible.
>

I find it unlikely that TypeError (in particular) is of much use for
repairing a situation, precisely because it is raised for situations where
a value has an incorrect type. That sounds to me like either a bug in the
code (and you don't fix bugs by catching exceptions, you fix them by
changing the source code), or something that should be checked explicitly
before making the call (e.g. if you can only sum ints and floats, and your
data is from an unknown source, you should check the data before calling
sum).


> If the exception that needs to be caught is literally TypeError then
> it is not possible to be more precise than simply "except TypeError".
> I have seen code that parses the error messages but that seems flakey
> to me. The problem with "except TypeError" is that it also catches
> exceptions from situations where the exception should very rarely be
> caught e.g. sum(1, 2, 3).
>

This argument would be more convincing if you could quote real code where
this has been a problem.

In the case of sum(), it's no hardship to ensure that you pass a list of
values, avoiding the sum(x, y, z) mistake, so if you wish to catch the
TypeError from sum(a), that should not need this language change.


> If the different cases that currently result in TypeError were broken
> down into more fine-grained exception classes then I think that would
> be good. A similar thing happened for OSError - in that case it was
> previously possible to distinguish cases using the errno attribute but
> it was awkward. In the case of TypeError there is nothing akin to the
> errno attribute so you either catch all TypeError or none.
>

And that's exactly the difference. For OSError it is *obviously* useful to
catch the exception and take different actions based on the errno value,
and using separate subclasses makes such code more robust. I have seen many
such examples in real code (my own, and others'). But wher

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Oscar Benjamin]

On Fri, 3 Sept 2021 at 17:32, Guido van Rossum  wrote:
>
> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin  
> wrote:
>>
>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka  wrote:
>> >
>> > There are two different kinds of TypeError: if the end user passes an
>> > instance of wrong type and if the author of the library makes an error
>> > in implementation of some protocols.
>> >
>> > For example, len(obj) raises TypeError in two cases: if obj does not
>> > have __len__ (user error) and if obj.returns non-integer (implementation
>> > error). for x in obj raises TypeError if obj does not have __iter__
>> > (user error) and if iter(obj) does not have __next__ (implementation 
>> > error).
>> >
>> > User errors can be fixed on user side, implementation errors can only be
>> > fixed by the author of the class. Even if the user and the author is the
>> > same person, these errors point to different places of code.
>> >
>> > Would it be worth to add a special TypeError subclass for implementation
>> > errors to distinguish them from user errors? How to name it
>> > (ImplementationError, ProtocolError, etc)?
>>
>> I think that it would be good to make TypeError more fine-grained.
>> Another example is:
>>
>> >>> sum(1, 2, 3)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: sum() takes at most 2 arguments (3 given)
>>
>> There can be reasons in library code to catch TypeError that might
>> arise from bad user input but in those situations you would usually
>> not want to catch this TypeError. The error from calling a function
>> with the wrong number of arguments would usually mean a bug in the
>> library code which should not be caught. Conversely if the user input
>> is a callable and you do want to catch the error resulting from it
>> being called with the wrong number of arguments then catching
>> TypeError is too broad again. Something like BadArgumentsError would
>> be better.
>
> The question is, would anyone ever want to make a distinction between the two 
> in *real* code? I find it unlikely that someone would write
>
> try:
> sum(x, y, z)
> except TypeError:
> ...
>
> If you bury the sum() call deep inside other code, I'd say your try/except 
> net is too wide.

You've misunderstood. I do *not* want to catch the exception from sum(x, y, z).

Sometimes a situation arises that there is a problem involving an
exception being raised that is best fixed by catching the exception.
Python does not provide much of a programmatic API for inspecting
exceptions beyond simply choosing which class of exceptions to catch.
That makes it important to limit the class of exceptions caught as
carefully as possible.

If the exception that needs to be caught is literally TypeError then
it is not possible to be more precise than simply "except TypeError".
I have seen code that parses the error messages but that seems flakey
to me. The problem with "except TypeError" is that it also catches
exceptions from situations where the exception should very rarely be
caught e.g. sum(1, 2, 3).

If the different cases that currently result in TypeError were broken
down into more fine-grained exception classes then I think that would
be good. A similar thing happened for OSError - in that case it was
previously possible to distinguish cases using the errno attribute but
it was awkward. In the case of TypeError there is nothing akin to the
errno attribute so you either catch all TypeError or none.

--
Oscar
___
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/NOWIPXWRINTFCDZKM35PBBYPGBXSDTXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Greg Ewing]

On 4/09/21 4:32 am, Guido van Rossum wrote:
The question is, would anyone ever want to make a distinction between 
the two in *real* code?


Another problem with this idea is that there isn't just one user
and one author. Library code often calls other library code written
by a different author, so a user error at one level is an implementation
error at another.

--
Greg
___
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/HDBNPF72K7RXWGKML4UDONDCGAQH36G4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Kevin Mills]

As I said before, the "1,2,3" in `f(1,2,3)` has a very different meaning than 
the "1,2,3" in `d[1,2,3]`. One is a (comma-separated) list of expressions, and 
one is a single expression, a tuple.

`*(1,2,3)` does not evaluate to the tuple `(1,2,3)`, so I don't think expecting 
it to do so in the context of d[*(1,2,3)] makes sense. And, I would argue that 
having it to so would be far more inconsistent - why does it evaluate to the 
tuple `(1,2,3)` in the context of `d[*(1,2,3)]`, but not in the context of 
`f(*(1,2,3))`?

Also, from a practical perspective, what would even be the point in allowing 
the syntax here if `d[*x]` meant exactly the same thing as `d[x]` (or 
`d[tuple(x)]` if it's not already a tuple)?
___
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/XGYTJAM5P2BL4NM4SQUE7VLSDYB77OAU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Template Literals for Python (easy and save creation of HTML)

[Thomas Güttler]

Am Fr., 3. Sept. 2021 um 16:53 Uhr schrieb Damian Shaw <
damian.peter.s...@gmail.com>:

> I am not convinced of tying `backticks` for a single markup language.
> Different markup languages presumably have different escape methods? Is
> Python supposed to be explicitly an HTML based language like many of the
> design choices of JavaScript?
>
>
My proposal does not suppose that Python will get explicitly an HTML based
language. I am sorry if you understood this.

Template Literals can be used for any sort of use case. My use case is
HTML. The PEP uses HTML as an example. But the implementation
would not be about HTML at all. Any kind of escaping could be done. This is
up to the user of the Template Literals.



> It also seems like a lot to ask to introduce yet another way of quoting
> strings which doesn't fit with the existing pattern of string quoting.
> Python already has single quotes, double quotes, triple single quotes,
> triple double quotes, and all of these can have an r or f placed in front
> of them to modify their behavior.
>
> I see you have a section on not using the "i" prefix, but I don't
> understand the sentence "This is an handy feature, which would not work
> reliably if there are two different prefixes". What is it trying to say?
> What would not work reliably and why?
>
>
Some lines above your quote I wrote:

"Some IDEs detect that you want use a f-string automtically".

At the moment there is only the "f" prefix. The automatic detection would
not work anymore if there would be two prefixes.
Please speak up again, if you need further explanation.



> I would like to see this PEP have a section on handling security, this PEP
> implies the Python standard library will safely escape HTML for you which
> presumably has security implications? And a section on how it will be
> updated when/if the HTML specification gets updated that may introduce new
> ways HTML can/must be escaped. And a section on what are the valid versions
> of HTML it supports? HTML5 only or does it explicitly support older
> versions of HTML?
>
>
Thank you very much!

That's a good point. I updated the PEP:

{{{
Out of scope: Save escaping of HTML
===

Template Literals are about creating a data structure.

The user of Template Literals could use this data structure for any fancy
kind
of computation.

We estimate most users will use the data structure to create HTML.

Nevertheless, how the user processes the data strucure is up to the user.

Escaping HTML and related security implications are out of scope of this
PEP.

}}}

What do you think about this section. Do you agree? If not, then please
speak up and tell
me what's wrong.

Thank you for your feedback!

  Thomas

>
>
___
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/EFKYD22FWSIS3WDRD4JWNCW64ZIQFEPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Chris Angelico]

On Sat, Sep 4, 2021 at 6:06 AM Kevin Mills  wrote:
> If we don't cheat by comparing expressions to expression lists, the two are 
> fairly analogous. `f(t)` means pass the tuple to the function, and `d[t]` 
> means use the tuple as a key. `f(*t)` means break up the tuple and pass each 
> element as an argument to the function, and `d[*t]` means break up the tuple 
> and pass each element to getitem in turn.
>

Cheat? But that's the exact context in which starred expressions have
meaning. When you call f(1,2,3), you're not calling f(1)(2)(3). You're
passing all of those arguments to a single function call. That's why
d[*t] would have to mean d[1,2,3] not d[1][2][3].

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/K2SHHSBFOW5FPQDHHUB5W6XLSKRAEZZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Guido van Rossum]

But the text of the error message will explain all you need for debugging
and testing.

On Fri, Sep 3, 2021 at 10:08 AM Christopher Barker 
wrote:

>
>
> On Fri, Sep 3, 2021 at 9:35 AM Guido van Rossum  wrote:
>
>> The question is, would anyone ever want to make a distinction between the
>> two in *real* code?
>>
>
> I expect not.
>
> However, finer grained exception may help with debugging and testing.
>
> -CHB
>
>
>
>
> find it unlikely that someone would write
>>
>> try:
>> sum(x, y, z)
>> except TypeError:
>> ...
>>
>> If you bury the sum() call deep inside other code, I'd say your
>> try/except net is too wide.
>>
>> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin 
>> wrote:
>>
>>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka 
>>> wrote:
>>> >
>>> > There are two different kinds of TypeError: if the end user passes an
>>> > instance of wrong type and if the author of the library makes an error
>>> > in implementation of some protocols.
>>> >
>>> > For example, len(obj) raises TypeError in two cases: if obj does not
>>> > have __len__ (user error) and if obj.returns non-integer
>>> (implementation
>>> > error). for x in obj raises TypeError if obj does not have __iter__
>>> > (user error) and if iter(obj) does not have __next__ (implementation
>>> error).
>>> >
>>> > User errors can be fixed on user side, implementation errors can only
>>> be
>>> > fixed by the author of the class. Even if the user and the author is
>>> the
>>> > same person, these errors point to different places of code.
>>> >
>>> > Would it be worth to add a special TypeError subclass for
>>> implementation
>>> > errors to distinguish them from user errors? How to name it
>>> > (ImplementationError, ProtocolError, etc)?
>>>
>>> I think that it would be good to make TypeError more fine-grained.
>>> Another example is:
>>>
>>> >>> sum(1, 2, 3)
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> TypeError: sum() takes at most 2 arguments (3 given)
>>>
>>> There can be reasons in library code to catch TypeError that might
>>> arise from bad user input but in those situations you would usually
>>> not want to catch this TypeError. The error from calling a function
>>> with the wrong number of arguments would usually mean a bug in the
>>> library code which should not be caught. Conversely if the user input
>>> is a callable and you do want to catch the error resulting from it
>>> being called with the wrong number of arguments then catching
>>> TypeError is too broad again. Something like BadArgumentsError would
>>> be better.
>>
>>
>>>
>>> --
>>> Oscar
>>> ___
>>> 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>


-- 
--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/PODUQXNURYYPUJBBYS6T4O4X2XT3WOA2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Kevin Mills]

> One reason MRAB points to.  The `*keys` syntax is more-or-less equivalent to 
> "substitute a tuple" in other Python contexts; you are proposing to give it a 
> completely different meaning.  This would be confusing and inconsistent.

I disagree that it is a completely different meaning. If the issue is that 
f(1,2,3) is the same as f(*(1,2,3)), but d[1,2,3] wouldn't be the same as 
d[*(1,2,3)], that's only because the "1,2,3" in d[1,2,3] already means 
something very different than the "1,2,3" in f(1,2,3).

If we don't cheat by comparing expressions to expression lists, the two are 
fairly analogous. `f(t)` means pass the tuple to the function, and `d[t]` means 
use the tuple as a key. `f(*t)` means break up the tuple and pass each element 
as an argument to the function, and `d[*t]` means break up the tuple and pass 
each element to getitem in turn.

I could see it as somewhat confusing, but I don't agree it's particularly 
inconsistent. It's not exactly the same, of course, because we're invoking 
getitem several times on different objects, rather than once with multiple 
arguments, but that's only because you can't pass multiple arguments to 
getitem, even if you wanted to invoke it directly rather than using square 
brackets, because it only takes one argument (or two, if you want to count 
self).

> However, let's bracket the syntax for a moment.  More important is that 
> "nested" data comes in shapes other than strictly nested dictionaries. This 
> seems to be most common in dealing with JSON data, but in concept it can 
> arise elsewhere.  A variety of libraries address this, with some small 
> differences among them.  Many are inspired by the semi-convention of "JSON 
> Path" that is inspired by XPath for XML.

> For example, what if our data looks like this:

> data = {1: [{2: {3, 4}}, {5: {6,7}}, [8, 9, 0]]}

I'm sorry, but I don't really see how this presents an issue to what I 
suggested, beyond simply that you wouldn't be able to access individual 
elements of the sets (because sets themselves don't support getitem). For 
example, if you wanted to access the 9, you would do:

d[1][-1][1]

Which in my proposed syntax would be:

d[*(1, -1, 1)]

---

What initially sparked this suggestion was an issue where I had to find the 
maximum value in a nested list (where sublists could themselves contain 
sublists, but potentially might not), and modify it to something else.

My initial solution was basically to walk through the list, and keep a list of 
all the indices to get to the currently found maximum. Then, once that's done, 
use the list of indices to modify what is now known to be the true maximum. I 
ended up writing a nested_setitem function since that sort of operation isn't 
natively supported.

Admittedly, I changed it afterwards so that the loop instead stored the sublist 
the maximum was found in and only the index in that sublist, eliminating the 
need for nested_setitem, so even in the problem I was working on, I wouldn't 
have ended up using my own proposed syntax...

So it might not actually be useful, after all.
___
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/EFMKJRCI5HXOEKMNHWNZ5ITABOBYHSSU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[André Roberge]

On Fri, Sep 3, 2021 at 2:05 PM Christopher Barker 
wrote:

>
> This has gotten a bit OT..
>
> Is there’s mailing list or something for folks to discuss the teaching of
> Python? I can’t seem  to find one.
>
>
> In theory, there is edu-sig (
https://www.python.org/community/sigs/current/edu-sig/) but it is
essentially dead.

André Roberge
___
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/3NDTNFQLTDUNFE2W5FQWYWFEN2D2HHE2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Christopher Barker]

On Fri, Sep 3, 2021 at 9:35 AM Guido van Rossum  wrote:

> The question is, would anyone ever want to make a distinction between the
> two in *real* code?
>

I expect not.

However, finer grained exception may help with debugging and testing.

-CHB




find it unlikely that someone would write
>
> try:
> sum(x, y, z)
> except TypeError:
> ...
>
> If you bury the sum() call deep inside other code, I'd say your try/except
> net is too wide.
>
> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin 
> wrote:
>
>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka 
>> wrote:
>> >
>> > There are two different kinds of TypeError: if the end user passes an
>> > instance of wrong type and if the author of the library makes an error
>> > in implementation of some protocols.
>> >
>> > For example, len(obj) raises TypeError in two cases: if obj does not
>> > have __len__ (user error) and if obj.returns non-integer (implementation
>> > error). for x in obj raises TypeError if obj does not have __iter__
>> > (user error) and if iter(obj) does not have __next__ (implementation
>> error).
>> >
>> > User errors can be fixed on user side, implementation errors can only be
>> > fixed by the author of the class. Even if the user and the author is the
>> > same person, these errors point to different places of code.
>> >
>> > Would it be worth to add a special TypeError subclass for implementation
>> > errors to distinguish them from user errors? How to name it
>> > (ImplementationError, ProtocolError, etc)?
>>
>> I think that it would be good to make TypeError more fine-grained.
>> Another example is:
>>
>> >>> sum(1, 2, 3)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: sum() takes at most 2 arguments (3 given)
>>
>> There can be reasons in library code to catch TypeError that might
>> arise from bad user input but in those situations you would usually
>> not want to catch this TypeError. The error from calling a function
>> with the wrong number of arguments would usually mean a bug in the
>> library code which should not be caught. Conversely if the user input
>> is a callable and you do want to catch the error resulting from it
>> being called with the wrong number of arguments then catching
>> TypeError is too broad again. Something like BadArgumentsError would
>> be better.
>
>
>>
>> --
>> Oscar
>> ___
>> 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/TUZTKVO23LZGZ37QX45MJZ3T7LECKIW3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Christopher Barker]

This has gotten a bit OT..

Is there’s mailing list or something for folks to discuss the teaching of
Python? I can’t seem  to find one.

But for now:

You need to talk about the Python execution model, how all values
> are objects,


When you say “execution model” it sound advanced. But if people are to
understand Python at all, they really need to know the basics:

Names vs Values
Identity vs equality
Mutable vs immutable

There is also the question of whether you are teaching Python to folks that
have some programming experience or teaching introductory programming to
complete newbies. I suspect the OP is doing the latter, and there is
something to be said for getting folks used to general programming concepts
before getting into the Python specifics.


An aside: checking identity (using is) is pretty rare in production code,
outside of  “is None” ( and module-specific singletons) beginners will get
pretty darn far if they only know “is” in that context. Kind of like, as
Chris A suggested, how beginners will only know “with” in the context of
opening files, and don’t need to understand the concept of context managers
in general.

What I do is tell students they should use “is None” and then demonstrate
failure of == None with numpy arrays to make the point (I’m not teaching
numpy) In that case, they are not so much learning about object identity as
they are operator overloading—another topic that needs to be covered
eventually.

-CHB

>
> --
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/R5O5M5HI5M7IAKIE5SELAKAL4HDJH6NJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Guido van Rossum]

The question is, would anyone ever want to make a distinction between the
two in *real* code? I find it unlikely that someone would write

try:
sum(x, y, z)
except TypeError:
...

If you bury the sum() call deep inside other code, I'd say your try/except
net is too wide.

On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin 
wrote:

> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka 
> wrote:
> >
> > There are two different kinds of TypeError: if the end user passes an
> > instance of wrong type and if the author of the library makes an error
> > in implementation of some protocols.
> >
> > For example, len(obj) raises TypeError in two cases: if obj does not
> > have __len__ (user error) and if obj.returns non-integer (implementation
> > error). for x in obj raises TypeError if obj does not have __iter__
> > (user error) and if iter(obj) does not have __next__ (implementation
> error).
> >
> > User errors can be fixed on user side, implementation errors can only be
> > fixed by the author of the class. Even if the user and the author is the
> > same person, these errors point to different places of code.
> >
> > Would it be worth to add a special TypeError subclass for implementation
> > errors to distinguish them from user errors? How to name it
> > (ImplementationError, ProtocolError, etc)?
>
> I think that it would be good to make TypeError more fine-grained.
> Another example is:
>
> >>> sum(1, 2, 3)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: sum() takes at most 2 arguments (3 given)
>
> There can be reasons in library code to catch TypeError that might
> arise from bad user input but in those situations you would usually
> not want to catch this TypeError. The error from calling a function
> with the wrong number of arguments would usually mean a bug in the
> library code which should not be caught. Conversely if the user input
> is a callable and you do want to catch the error resulting from it
> being called with the wrong number of arguments then catching
> TypeError is too broad again. Something like BadArgumentsError would
> be better.
>
> --
> Oscar
> ___
> 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Ah, but that's because you're a Python programmer who has been seeped in 
 > the language for many, many years :-)

No, it's because I'm a Lisp programmer for twice as long, and know the
differences among #'=, #'string=, #'equal, #'eql, and #'eq (the last
is `is'`.

 > To most people, "is" and "equals" are synonyms,

In Python, this is a *bug*, and if it's not fixed, they are going to
have a lot of trouble with mutable containers.  Especially as default
values for function arguments.

 > So for somebody who is expecting "is" to be a synonym for `==`, how do 
 > you explain what it actually is? You need to talk about the Python 
 > execution model,

I guess you need this if you want to explain how "x == None" can fail
to do what you want, but that's independent of None's uniqueness.

 > how all values are objects, and that the reason that `x is None`
 > always does the right thing

TOOWTDI violation.  Python has both `==` and `is` *because* they do
different things.  What each does is a right thing.  The programmer's
problem is to learn what each does and when to use it.

 > but `x is []` doesn't is that None is a singleton, so that there is
 > only one object that is None, but the empty list is not, there are
 > many, many distinct empty lists.

I would avoid use of "singleton" personally, since it's also used to
denote a *type* with only one member, and for many students (eg, all
of mine) you would have to define it.  I don't see what "None is a
singleton, so that" adds to

You need to talk about the Python execution model, how all values
are objects, and that the reason that `x is None` always does the
right thing but `x is []` doesn't is that there is only one object
that is None, but the empty list is not, there are many, many
distinct empty lists.

 > You might be able to avoid using the word "singleton",

I just did, or maybe I should say, you just did. ;-)

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/KQGCOPDOSTTL2AXHSCBHQXUXGAM2HO52/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Template Literals for Python (easy and save creation of HTML)

[Damian Shaw]

I am not convinced of tying `backticks` for a single markup language.
Different markup languages presumably have different escape methods? Is
Python supposed to be explicitly an HTML based language like many of the
design choices of JavaScript?

It also seems like a lot to ask to introduce yet another way of quoting
strings which doesn't fit with the existing pattern of string quoting.
Python already has single quotes, double quotes, triple single quotes,
triple double quotes, and all of these can have an r or f placed in front
of them to modify their behavior.

I see you have a section on not using the "i" prefix, but I don't
understand the sentence "This is an handy feature, which would not work
reliably if there are two different prefixes". What is it trying to say?
What would not work reliably and why?

I would like to see this PEP have a section on handling security, this PEP
implies the Python standard library will safely escape HTML for you which
presumably has security implications? And a section on how it will be
updated when/if the HTML specification gets updated that may introduce new
ways HTML can/must be escaped. And a section on what are the valid versions
of HTML it supports? HTML5 only or does it explicitly support older
versions of HTML?

Damian (he/him)

On Fri, Sep 3, 2021 at 9:47 AM Thomas Güttler 
wrote:

> Some weeks ago I started the idea of Template Literals for Python:
>
> https://github.com/guettli/peps/blob/master/pep-.rst
>
> I just switched to a new company (descript.de) and diving into their
> context
> will need some time.
>
> This means I won't work on the Template Literals PEP.
>
> If you like the idea, then it would be great if you work on it.
>
> Regards,
>   Thomas
> ___
> 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/BZWBK2PFBFUXU5PEP7UZORHL23RQVHE4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/VTDQSJDUAERS3XMZ3772P6MFZ3TIGDS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Template Literals for Python (easy and save creation of HTML)

[Thomas Güttler]

Some weeks ago I started the idea of Template Literals for Python:

https://github.com/guettli/peps/blob/master/pep-.rst

I just switched to a new company (descript.de) and diving into their context
will need some time.

This means I won't work on the Template Literals PEP.

If you like the idea, then it would be great if you work on it.

Regards,
  Thomas
___
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/BZWBK2PFBFUXU5PEP7UZORHL23RQVHE4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow starred expressions to be used as subscripts for nested lookups for getitem and setitem

[Matsuoka Takuo]

On Fri, 3 Sept 2021 at 12:06, Steven D'Aprano  wrote:
>
> I think it might be better to start with a *function* that chains
> subscript calls, and perhaps put it in the operator module with
> itemgetter and attrgetter.
>
> # Untested.
> def chained_item(items, obj):
> for key in items:
> obj = obj[key]
> return obj

That's an interesting idea, but why chain only subscript calls?
chained_item chains application of the callable objects from the
iterable

  map(operator.itemgetter, items)

It would be sufficient and more convenient if functools had something
that chains application of any callable objects.

Best regards,
Takuo
___
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/XOLZXM53MUJW4JSZ47J2IU27SNMRFKBG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Oscar Benjamin]

On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka  wrote:
>
> There are two different kinds of TypeError: if the end user passes an
> instance of wrong type and if the author of the library makes an error
> in implementation of some protocols.
>
> For example, len(obj) raises TypeError in two cases: if obj does not
> have __len__ (user error) and if obj.returns non-integer (implementation
> error). for x in obj raises TypeError if obj does not have __iter__
> (user error) and if iter(obj) does not have __next__ (implementation error).
>
> User errors can be fixed on user side, implementation errors can only be
> fixed by the author of the class. Even if the user and the author is the
> same person, these errors point to different places of code.
>
> Would it be worth to add a special TypeError subclass for implementation
> errors to distinguish them from user errors? How to name it
> (ImplementationError, ProtocolError, etc)?

I think that it would be good to make TypeError more fine-grained.
Another example is:

>>> sum(1, 2, 3)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: sum() takes at most 2 arguments (3 given)

There can be reasons in library code to catch TypeError that might
arise from bad user input but in those situations you would usually
not want to catch this TypeError. The error from calling a function
with the wrong number of arguments would usually mean a bug in the
library code which should not be caught. Conversely if the user input
is a callable and you do want to catch the error resulting from it
being called with the wrong number of arguments then catching
TypeError is too broad again. Something like BadArgumentsError would
be better.

--
Oscar
___
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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Chris Angelico]

On Fri, Sep 3, 2021 at 7:35 PM Steven D'Aprano  wrote:
>
> On Fri, Sep 03, 2021 at 03:43:03PM +1000, Chris Angelico wrote:
>
> > Yes, although I'd love to have a good term for "there is only ever one
> > object of this type AND VALUE", rather than "there is only one object
> > of this type", so that True and False could be discussed the same way
> > as singletons.
>
> I believe that the "official" Design Pattern name for something that
> generalisations the Singleton pattern to two or more instances is the
> Multiton:
>
> https://en.wikipedia.org/wiki/Multiton_pattern
>
> but most people just use the term "singleton" in the sense that there is
> only a single True and a single False. Or sometimes "dupleton" or
> "doubleton".
>
> Another term sometimes used is "flyweight", which is also used for
> interned strings and ints.
>
> https://python-patterns.guide/gang-of-four/flyweight/

Fair enough. I'll try to remember that one. Useful term, although a
little less than intuitive.

> What would you call a class that has *no* instances? Obviously that
> would only be useful in a language where classes are first-class
> citizens. Why create a singleton instance if you can just use the class
> object itself?
>

Based on the way Java seems to use it, probably "namespace" would be
the best term. Effectively, a class that never gets instantiated is a
storehouse for static methods, which means it's basically what Python
would do with a module full of top-level functions.

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/LCKZZRN2VR6PVZ4HC2Q5THNQR6WR6KZI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Steven D'Aprano]

On Fri, Sep 03, 2021 at 03:43:03PM +1000, Chris Angelico wrote:

> Yes, although I'd love to have a good term for "there is only ever one
> object of this type AND VALUE", rather than "there is only one object
> of this type", so that True and False could be discussed the same way
> as singletons.

I believe that the "official" Design Pattern name for something that 
generalisations the Singleton pattern to two or more instances is the 
Multiton:

https://en.wikipedia.org/wiki/Multiton_pattern

but most people just use the term "singleton" in the sense that there is 
only a single True and a single False. Or sometimes "dupleton" or 
"doubleton".

Another term sometimes used is "flyweight", which is also used for 
interned strings and ints.

https://python-patterns.guide/gang-of-four/flyweight/

Interestingly, the term "singleton" was used in Python *before* the Gang 
Of Four book used it:

https://python-patterns.guide/gang-of-four/singleton/


What would you call a class that has *no* instances? Obviously that 
would only be useful in a language where classes are first-class 
citizens. Why create a singleton instance if you can just use the class 
object itself?


-- 
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/VYR453KSZPMHAFVZZJJQ56VIYKM5QRTV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Antoine Rozo]

One other solution is to use a `yield from` with an empty iterable,
then you don't need to have an unreachable `yield`.

Le ven. 3 sept. 2021 à 09:52, Serhiy Storchaka  a écrit :
>
> 03.09.21 10:28, Thomas Grainger пише:
> > the way to make an (aysnc)generator that immediately raises 
> > Stop(Async)Iteration immediately is to insert an unreachable `yield` 
> > statement, however there's two ways to do it:
>
> I think it is too uncommon case to specify it in PEP 8.
>
> ___
> 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/M4TIXVDUNKPCHJUR5DNB5QLBYXC5JCWC/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Antoine Rozo
___
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/NDQDM6KJOCHTADZJEV3CGEMJJKKDD4ZK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Serhiy Storchaka]

03.09.21 10:28, Thomas Grainger пише:
> the way to make an (aysnc)generator that immediately raises 
> Stop(Async)Iteration immediately is to insert an unreachable `yield` 
> statement, however there's two ways to do it:

I think it is too uncommon case to specify it in PEP 8.

___
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/M4TIXVDUNKPCHJUR5DNB5QLBYXC5JCWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Thomas Grainger]

Serhiy Storchaka wrote:
> There are two different kinds of TypeError: if the end user passes an
> instance of wrong type and if the author of the library makes an error
> in implementation of some protocols.
> For example, len(obj) raises TypeError in two cases: if obj does not
> have __len__ (user error) and if obj.returns non-integer (implementation
> error). for x in obj raises TypeError if obj does not have __iter__
> (user error) and if iter(obj) does not have __next__ (implementation error).

what's the reason for this not to raise AttributeError? I assume you asked this 
question in relation to the 3.11 changes to `with x:` raising TypeError vs 
AttributeError ?
> User errors can be fixed on user side, implementation errors can only be
> fixed by the author of the class. Even if the user and the author is the
> same person, these errors point to different places of code.
> Would it be worth to add a special TypeError subclass for implementation
> errors to distinguish them from user errors? How to name it
> (ImplementationError, ProtocolError, etc)?

I think ProtocolError would be too easily confused as relating to 
typing.Protocol or asyncio.Protocol
ImplementationError sounds like it's related to `abc`s or NotImplementedError

How about `AttributeNotFoundError` or `AttributeRequiredError` ?
___
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/CGW5TKJJWZSOBYJDGWW3KVTV4XGAZ7CV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Thomas Grainger]

the way to make an (aysnc)generator that immediately raises 
Stop(Async)Iteration immediately is to insert an unreachable `yield` statement, 
however there's two ways to do it:

def example():
if False:
yield

or:


def example():
return
yield

currently test_asyncgen.py uses both, eg:

@types.coroutine
def __anext__(self):
if False:
yield "this is a generator-based coroutine"
if self.yielded >= 2:
raise StopAsyncIteration()
else:
self.yielded += 1
return self.yielded

or:


async def agenfn():
try:
await _async_yield(1)
except MyError:
await _async_yield(2)
return
yield

the `if False: yield` version has a disadvantage in that it can be anywhere in 
the function, if this one is chosen then an additional caveat is that it should 
be the first two statements in a function
if `return; yield` version has an disadvantage in that the unreachable yield 
could be inserted after any `return`, if this one is chosen then an additional 
caveat is that it should be the last two statements in a function and de-dented 
as much as syntactically possible.

Which alternative do you prefer? I prefer `return; yield`
___
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/XUGWXWD7VBJWXBJWEGFT3OUEXCAL5GMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add a special TypeError subclass for implementation errors

[Serhiy Storchaka]

There are two different kinds of TypeError: if the end user passes an
instance of wrong type and if the author of the library makes an error
in implementation of some protocols.

For example, len(obj) raises TypeError in two cases: if obj does not
have __len__ (user error) and if obj.returns non-integer (implementation
error). for x in obj raises TypeError if obj does not have __iter__
(user error) and if iter(obj) does not have __next__ (implementation error).

User errors can be fixed on user side, implementation errors can only be
fixed by the author of the class. Even if the user and the author is the
same person, these errors point to different places of code.

Would it be worth to add a special TypeError subclass for implementation
errors to distinguish them from user errors? How to name it
(ImplementationError, ProtocolError, etc)?

___
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/Y5BBLXXPORROUNWPACTAEIPJZFSKRVHY/
Code of Conduct: http://python.org/psf/codeofconduct/