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-in
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
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
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.
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(Asyn
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.
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 tha
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: i
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 ite
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 ide
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 anot
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'`.
> T
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, 202
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
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
>
>
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/) bu
> 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 i
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
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
Am Fr., 3. Sept. 2021 um 16:53 Uhr schrieb Damian Shaw <
[email protected]>:
> 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 ma
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 co
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, s
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 aut
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 <
> [email protected]> wrote:
> >>
> >> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka
> wrote:
> >> >
> >> > There are two
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 pars
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 Ex
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 und
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'
28 matches
Mail list logo