How do you find what exceptions a class can throw?

[Chris Green]

I am using poplib.POP3_SSL() and I want to know what exceptions can be
thrown when I instantiate it.  Presumably it inherits them because
there's nothing much in the documentation page for poplib.POP3_SSL().

I specifically want to trap timeout exceptions.

(... and, yes, I know I should maybe move to IMAP but that's too much
work at the moment!)

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[dn via Python-list]

On 20/12/2020 22:39, Chris Green wrote:

I am using poplib.POP3_SSL() and I want to know what exceptions can be
thrown when I instantiate it.  Presumably it inherits them because
there's nothing much in the documentation page for poplib.POP3_SSL().

I specifically want to trap timeout exceptions.

(... and, yes, I know I should maybe move to IMAP but that's too much
work at the moment!)



This morning, reading the results of the Virtual Python Core Developer 
Sprint 2020 
(https://pyfound.blogspot.com/2020/12/virtual-python-core-developer-sprint.html) 
and from there, PEP 594 -- Removing dead batteries from the standard 
library (https://www.python.org/dev/peps/pep-0594/), the impression 
gained is that the old/existing PSL offerings, eg poplib, are soon to be 
deprecated, in favor of asyncio and presumably something like aioimap 
(https://pypi.org/project/aioimaplib/).


Async handles with timeouts implicitly.

Apologies for the lack of direct-answer. That's as far as my reading has 
taken me. Hopefully someone, more in-the-know, will be able to advise...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get(key, default) evaluates default even if key exists

[Roel Schroeven]

Ethan Furman schreef op 16/12/2020 om 17:59:

Or, if the computationally massively expensive call uses potentially
different arguments for each invocation:

  some_var = d.get('a') or cme(arg1, arg2, ...)


I don't like that because it is very fragile: the expression will 
evaluate to the second part not only when 'a' is not in the dictionary 
but also whenever the value corresponding to key 'a' is false-y.


Example:

def slow_function(a, b):
# Pretend this is slow, or there is any other reason for this
# function to be called only when strictly necessary.
print('slow_function called')
return a + b

d = {
'spam': 0,
'ham': 1,
'parrot': 2,
}

some_var = d.get('spam') or slow_function(31, 11)
print(some_var)

Result: slow_function is called, and some_var equals 42 instead of 0.

You could make it work reliable by using a unique sentinel value and the 
walrus operator:


SENTINEL = object()
some_var = (
r
if (r := d.get('spam', SENTINEL)) is not SENTINEL
else slow_function(31, 11)
)

But I don't like that either because it's way too complicated.

What could be useful in some use cases, I think, is a wrapper function 
that evaluates the function lazily:


def dict_get_lazily(d, key, fnc, *args, **kwargs):
try:
return d[key]
except KeyError:
return fnc(*args, **kwargs)

some_var = dict_get_lazily(d, 'spam', some_function, 31, 11)



--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get(key, default) evaluates default even if key exists

[2QdxY4RzWzUUiLuE]

On 2020-12-19 at 22:29:34 +0100,
Roel Schroeven  wrote:

> What could be useful in some use cases, I think, is a wrapper function
> that evaluates the function lazily:
> 
> def dict_get_lazily(d, key, fnc, *args, **kwargs):
> try:
> return d[key]
> except KeyError:
> return fnc(*args, **kwargs)
> 
> some_var = dict_get_lazily(d, 'spam', some_function, 31, 11)

There's no need to pass all those arguments through dict_get_lazily, and
the language already has a way to evaluate an expression lazily:

def dict_get_lazily(d, key, f):
try:
return d[key]
except KeyError:
return f()

some_var = dict_get_lazily(d, 'spam', lambda: some_function(31, 11))

So, beyond a cache (of which there are many variations and many
implementations for many use cases), what are the use cases for an
entire dictionary of lazily computed values?  And if my application has
to know when to access d['key'] directly and when to call
dict_get_lazily(d, 'key', f), then whom am I fooling by "hiding" the
lazy evaluation?  But if I always call dict_get_lazily when I access d,
then why do those two or three lines belong in the standard library
instead of my application or my private toolbox?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get(key, default) evaluates default even if key exists

[Chris Angelico]

On Mon, Dec 21, 2020 at 12:47 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2020-12-19 at 22:29:34 +0100,
> Roel Schroeven  wrote:
>
> > What could be useful in some use cases, I think, is a wrapper function
> > that evaluates the function lazily:
> >
> > def dict_get_lazily(d, key, fnc, *args, **kwargs):
> > try:
> > return d[key]
> > except KeyError:
> > return fnc(*args, **kwargs)
> >
> > some_var = dict_get_lazily(d, 'spam', some_function, 31, 11)
>
> There's no need to pass all those arguments through dict_get_lazily, and
> the language already has a way to evaluate an expression lazily:
>
> def dict_get_lazily(d, key, f):
> try:
> return d[key]
> except KeyError:
> return f()
>
> some_var = dict_get_lazily(d, 'spam', lambda: some_function(31, 11))
>

class LazyDict(dict):
def __missing__(self, key):
# Pretend this is slow
print("slow function called")
return 31 + 11

d = LazyDict({
'spam': 0,
'ham': 1,
'parrot': 2,
})
print(d['spam'])
print(d['eggs'])

Guaranteed to be called when and only when the key is missing. This
does imply a variant architecture in which the data structure itself
is aware of the calculations necessary to generate the data, so it may
not be appropriate to all situations, but it's clean, easy, and
efficient.

If you can't do this, I'd recommend using the try/except method, maybe
wrapped up in a function if you want to. In the case where the key is
found, the cost is one try block and one lookup - barely more than any
other option (for the record, a try block is pretty cheap in CPython,
and it's only costly when you hit an exception); and where it isn't
found, it's two lookups plus the cost of generating the default (and
we've already established that generating the default is expensive,
otherwise setdefault would be appropriate).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Chris Green]

Stefan Ram  wrote:
> Chris Green  writes:
> >I am using poplib.POP3_SSL() and I want to know what exceptions can be
> >thrown when I instantiate it.  Presumably it inherits them because
> >there's nothing much in the documentation page for poplib.POP3_SSL().
> 
>   Both Java and C++ have tried to introduce a static
>   declaration of exceptions IIRC, but IIRC this was less
>   popular as it led to problems.
> 
>   Ultimately, it is not possible to tell what exceptions 
>   a call might throw. In such a case, it may help to explain
>   to the newsgroup why this information is needed.
> 
So that, as is always advised, I can catch the specific exception
being thrown!

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[2QdxY4RzWzUUiLuE]

On 2020-12-20 at 16:02:53 +,
Regarding "Re: How do you find what exceptions a class can throw?,"
Chris Green  wrote:

> Stefan Ram  wrote:
> > Chris Green  writes:
> > >I am using poplib.POP3_SSL() and I want to know what exceptions can be
> > >thrown when I instantiate it.  Presumably it inherits them because
> > >there's nothing much in the documentation page for poplib.POP3_SSL().
> > 
> >   Both Java and C++ have tried to introduce a static
> >   declaration of exceptions IIRC, but IIRC this was less
> >   popular as it led to problems.
> > 
> >   Ultimately, it is not possible to tell what exceptions 
> >   a call might throw. In such a case, it may help to explain
> >   to the newsgroup why this information is needed.
> > 
> So that, as is always advised, I can catch the specific exception
> being thrown!

To the point:  what are you going to do with it once you catch it?

Are you prepared to handle every exception individually, or are you
fishing for exceptions that you think might be worth catching?

Remember, you get reporting (a traceback) and program cleanup and exit
for free.  What will catching an exception *add* to the user experience?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Julio Di Egidio]

On Sunday, 20 December 2020 at 18:18:26 UTC+1, Chris Green wrote:

> If I ignore the exception then the 
> program just exits, if I want the program to do something useful about 
> it (like try again) then I have to catch the specific exception as I 
> don't want to try again with other exceptions.

As other have hinted at, it's about handling, not so much about catching.

That said, the docs are your friend:


"exception poplib.error_proto -- Exception raised on any errors from this 
module (errors from socket module are not caught) [where "error_proto" I 
suppose stands for "protocol error"]. The reason for the exception is passed to 
the constructor as a string."  (It's also documented in the code docs...)

So that's one exception and the only explicit one (see below) specific to that 
module.  Then you should check the exceptions in the socket module:


Incidentally, I have peeked at the source code for poplib, and the initializer 
of poplib.POP3_SSL also raises ValueError on invalid arguments.  I suppose 
similar should be expected from the socket module.  But these are the 
exceptions that typically are not handled: one has to validate input, so that, 
at that point, a ValueError, or a TypeError (or a KeyError, etc.) is rather a 
bug.  Anyway, this is another story...

Julio
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Chris Green]

2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2020-12-20 at 16:02:53 +,
> Regarding "Re: How do you find what exceptions a class can throw?,"
> Chris Green  wrote:
> 
> > Stefan Ram  wrote:
> > > Chris Green  writes:
> > > >I am using poplib.POP3_SSL() and I want to know what exceptions can be
> > > >thrown when I instantiate it.  Presumably it inherits them because
> > > >there's nothing much in the documentation page for poplib.POP3_SSL().
> > > 
> > >   Both Java and C++ have tried to introduce a static
> > >   declaration of exceptions IIRC, but IIRC this was less
> > >   popular as it led to problems.
> > > 
> > >   Ultimately, it is not possible to tell what exceptions 
> > >   a call might throw. In such a case, it may help to explain
> > >   to the newsgroup why this information is needed.
> > > 
> > So that, as is always advised, I can catch the specific exception
> > being thrown!
> 
> To the point:  what are you going to do with it once you catch it?
> 
> Are you prepared to handle every exception individually, or are you
> fishing for exceptions that you think might be worth catching?
> 
> Remember, you get reporting (a traceback) and program cleanup and exit
> for free.  What will catching an exception *add* to the user experience?

If it's a timeout exception I'm going to delay a little while and then
try again.  The timeout is probably because the server is busy.

If it's not a timeout then I'll (as you suggest) leave it to terminate
the program and report the error.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> > Remember, you get reporting (a traceback) and program cleanup and exit
> > for free.  What will catching an exception *add* to the user experience?
>
> If it's a timeout exception I'm going to delay a little while and then
> try again.  The timeout is probably because the server is busy.

So what you are looking for is the form of a potential
"timeout exception" (say, exception name) ?

Provoke one and have a look.

Then catch what you saw.

Karsten
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Re: How do you find what exceptions a class can throw?

[Julio Di Egidio]

On Sunday, 20 December 2020 at 19:35:21 UTC+1, Karsten Hilbert wrote:

> > If it's a timeout exception I'm going to delay a little while and then 
> > try again. The timeout is probably because the server is busy.
> 
> So what you are looking for is the form of a potential 
> "timeout exception" (say, exception name) ? 
> 
> Provoke one and have a look. 
> 
> Then catch what you saw.



Programmers don't guess...

HTH,

Julio
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Chris Green]

Stefan Ram  wrote:
> Chris Green  writes:
> >So that, as is always advised, I can catch the specific exception
> >being thrown!
> 
>   It usually is advisable to be more specific when catching
>   exceptions. The worst thing to do is surely a bare "except:"
>   which then ignores the exception.
> 
>   A general "except Exception:" is slightly better, since it
>   will not catch SystemExit and KeyboardInterrupt exceptions.
> 
>   According to me, you should only catch a specific exception
>   if you know better than your caller what to do in this case.
>   Otherwise just let it pass through to your caller.
> 
> 
"better than your caller"???  If I ignore the exception then the
program just exits, if I want the program to do something useful about
it (like try again) then I have to catch the specific exception as I
don't want to try again with other exceptions.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> > So what you are looking for is the form of a potential
> > "timeout exception" (say, exception name) ?
> >
> > Provoke one and have a look.
> >
> > Then catch what you saw.
>
> 
>
> Programmers don't guess...

I did not suggest guessing.

I suggested gathering scientific evidence by
running a controlled experiment.

Or should I say "Programmers don't trust..." ?

Karsten
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Grant Edwards]

On 2020-12-20, 2qdxy4rzwzuui...@potatochowder.com 
<2qdxy4rzwzuui...@potatochowder.com> wrote:
> Chris Green  wrote:
>
>>>   Ultimately, it is not possible to tell what exceptions 
>>>   a call might throw.

While it may not be "ultimately possible", in practice it usually
is. Most libarary documentation lists exceptions thrown by fuctions
and explains what causes them.

>>>   In such a case, it may help to explain
>>>   to the newsgroup why this information is needed.
>>
>> So that, as is always advised, I can catch the specific exception
>> being thrown!
>
> To the point: what are you going to do with it once you catch it?

Seriously? You've never written code that handled an exception?

> Are you prepared to handle every exception individually,

Of course he isn't.

> or are you fishing for exceptions that you think might be worth
> catching?

You handle whatever exception(s) you expect, and let the others pass
up to higher levels. There are lots of cases where there may be one or
two exceptions that you want to handle.

> Remember, you get reporting (a traceback) and program cleanup and
> exit for free.  What will catching an exception *add* to the user
> experience?

Yes, if you can deal with it in such a way that normal execution of
the program (from the user's POV) continues. Exceptions aren't always
bugs and errors. Sometimes it's just an uncommon use-case that is
foreseen and dealt with.




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Re: Re: How do you find what exceptions a class can throw?

[Julio Di Egidio]

On Sunday, 20 December 2020 at 19:54:08 UTC+1, Karsten Hilbert wrote:
> > > So what you are looking for is the form of a potential 
> > > "timeout exception" (say, exception name) ? 
> > > 
> > > Provoke one and have a look. 
> > > 
> > > Then catch what you saw. 
> > 
> >  
> > 
> > Programmers don't guess...
> 
> I did not suggest guessing. 

Yes, you did.  :)

> I suggested gathering scientific evidence by 
> running a controlled experiment.

Programming is not a science: in fact, computer science is a mathematics, and 
engineering is engineering.

Rather (speaking generally), the "trial and error" together with "not reading 
the docs" is a typical beginner's mistake.

> Or should I say "Programmers don't trust..." ? 

Trust me: it takes 100x getting anything done plus keep up with your prayers, 
and it takes 100^100x learning anything solid, as in just forget about it.  
Indeed, consider that we are rather going to the formal verification of 
programs, software, and even hardware...

Julio
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> Trust me: it takes 100x getting anything done plus keep up with your prayers, 
> and it takes 100^100x learning anything solid, as in just forget about it.  
> Indeed, consider that we are rather going to the formal verification of 
> programs, software, and even hardware...

I sincerly wish you that your hope becomes reality within your lifetime.

Karsten
-- 
https://mail.python.org/mailman/listinfo/python-list

list() strange behaviour

[danilob]

Hi,
I'm an absolute beginner in Python (and in English too ;-)
Running this code:


--
# Python 3.9.0

a = [[1, 2, 0, 3, 0],
 [0, 4, 5, 0, 6],
 [7, 0, 8, 0, 9],
 [2, 3, 0, 0, 1],
 [0, 0, 1, 8, 0]]


b = ((x[0] for x in a))

print(list(b))
print(list(b))
---


I get this output:

[1, 0, 7, 2, 0]
[]


I don't know why the second print() output shows an empty list.
Is it possible that the first print() call might have changed the value 
of "b"?


Thank you in advance.
--
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[2QdxY4RzWzUUiLuE]

On 2020-12-20 at 18:25:40 -,
Grant Edwards  wrote:

> On 2020-12-20, 2qdxy4rzwzuui...@potatochowder.com 
> <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > Chris Green  wrote:
> >
> >>>   Ultimately, it is not possible to tell what exceptions 
> >>>   a call might throw.
> 
> While it may not be "ultimately possible", in practice it usually
> is. Most libarary documentation lists exceptions thrown by fuctions
> and explains what causes them.
> 
> >>>   In such a case, it may help to explain
> >>>   to the newsgroup why this information is needed.
> >>
> >> So that, as is always advised, I can catch the specific exception
> >> being thrown!
> >
> > To the point: what are you going to do with it once you catch it?
> 
> Seriously? You've never written code that handled an exception?

No.  Of course I've written code that catches exceptions.

Have you ever written code that ignored an exception, explicitly or
implicitly?  Of course you have.

My point was to get the OP to think about *handling* exceptions, not
just catching them because a library function throws them, or trying to
deal with everything that might happen in the future.

> > Are you prepared to handle every exception individually,
> 
> Of course he isn't.

How do we know that?

> > or are you fishing for exceptions that you think might be worth
> > catching?
> 
> You handle whatever exception(s) you expect, and let the others pass
> up to higher levels. There are lots of cases where there may be one or
> two exceptions that you want to handle.

Subsequent emails indicate that Chris Green does as well, but it took a
while to get there (or perhaps I just misunderstood all those vague
references to catching exceptions).

> > Remember, you get reporting (a traceback) and program cleanup and
> > exit for free.  What will catching an exception *add* to the user
> > experience?
> 
> Yes, if you can deal with it in such a way that normal execution of
> the program (from the user's POV) continues. Exceptions aren't always
> bugs and errors. Sometimes it's just an uncommon use-case that is
> foreseen and dealt with.

Agreed.  Some programs recover from and continue under (for their own
definitions of "recover" and "continue") horrendous conditions, other
programs dump a traceback and let a user/operator/customer deal with it.
Chris Green gave little or no indication of expectations or desires.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list() strange behaviour

[Tim Chase]

On 2020-12-20 21:00, danilob wrote:
> b = ((x[0] for x in a))

here you create a generator

> print(list(b))
> [1, 0, 7, 2, 0]

and then you consume all the things it generates here which means
that when you go to do this a second time

> print(list(b))

the generator is already empty/exhausted so there's nothing more to
yield, giving you the empty result that you got:

> []


If you want to do this, convert it to a list once:

 >>> c = list(b)

or use a list-comprehension instead creating a generator

 >>> c = [x[0] for x in a]

and then print that resulting list:

 >>> print(c)
 >>> print(c)

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list() strange behaviour

[Cameron Simpson]

On 20Dec2020 21:00, danilob  wrote:
>I'm an absolute beginner in Python (and in English too ;-)

Well your English is far better than my very poor second language.

>Running this code:
>--
># Python 3.9.0
>
>a = [[1, 2, 0, 3, 0],
> [0, 4, 5, 0, 6],
> [7, 0, 8, 0, 9],
> [2, 3, 0, 0, 1],
> [0, 0, 1, 8, 0]]

This is a list of lists.

>b = ((x[0] for x in a))

This is a generator comprehension, and _not_ a list. Explainations 
below.

>print(list(b))
>print(list(b))
>---
>I get this output:
>
>[1, 0, 7, 2, 0]

As you expect.

>[]

As a surprise.

>I don't know why the second print() output shows an empty list.
>Is it possible that the first print() call might have changed the value 
>of "b"?

It hasn't but, it has changed its state. Let me explain.

In Python there are 2 visually similar list-like comprehensions:

This is a _list_ comprehension (note the surrounding square brackets):

[ x for x in range(5) ]

It genuinely constructs a list containing:

[ 0, 1, 2, 3, 4 ]

and would behave as you expect in print().

By contrast, this is a generator comprehension (note the round 
brackets):

( x for x in range(5) )

This is a "lazy" construct, and is like writing a generator function:

def g():
for x in range(5):
yield x

It is a little iterable which _counts_ from 0 through 4 inclusive and 
yields each value as requested.

Try putting a:

print(b)

before your other print calls. It will not show a list.

So, what is happening?

b = ((x[0] for x in a))

This makes a generator comprehension. The outermost brackets are 
redundant, by the way, and can be discarded:

b = (x[0] for x in a)

And does this (using my simpler example range(5)):

>>> b=(x for x in range(5))
>>> b
 at 0x10539e120>

When you make a list from that:

>>> L = list(b)
>>> L
[0, 1, 2, 3, 4]

the generator _runs_ and emits the values to be used in the list. If you 
make another list:

>>> L = list(b)
>>> L
[]

The generator has finished. Using it again produces no values, and so 
list() constructs an empty list.

That is what is happening in your print statements.

If, instead, you had gone:

b = [x[0] for x in a]

Then "b" would be an actual list (a sequence of values stored in memory) 
and your prints would have done what you expect.

Python has several "lazy" operations available, which do not do the 
entire computation when they are defined; instead they give you a 
"generator" which performs the computation incrementally, running until 
the next value is found - when the user asks for the next value, _then_ 
the generator runs until that value is obtained and "yield"ed.

Supposing your array "a" were extremely large, or perhaps in some way 
stored in a database instead of in memory. It might be expensive or very 
slow to get _all_ the values. A generator lets you get values as they 
are required.

A generator expression like this:

b = ( x for x in range(5) )

counts from 0 through 4 inclusively (or 0 through 5, excluding 5, which 
is how ranges egenrally work in Python) when asks. As a function it 
might look like this:

def b():
for x in range(5)
yield x

When you call "list(b)" the list constructor collects values from 
"iter(b)", which iterates over "b". Like this, written longhand:

L = []
for value in b:
L.append(b)

Written even longer:

L = []
b_values = iter(b)
while True:
try:
value = next(b_values)
except Stopiteration:
break
L.append(value)

which more clearly shows a call to "next()" to run the iterator b_values 
once, until it yields a value.

The Python for-statement is a builtin convenient way to write the 
while-loop above - it iterates over any iterable like "b".

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Cameron Simpson]

On 20Dec2020 20:34, Karsten Hilbert  wrote:
>> Trust me: it takes 100x getting anything done plus keep up with your 
>> prayers, and it takes 100^100x learning anything solid, as in just forget 
>> about it.  Indeed, consider that we are rather going to the formal 
>> verification of programs, software, and even hardware...
>
>I sincerly wish you that your hope becomes reality within your 
>lifetime.

Aye, since "we are rather going to the formal verification of programs, 
software, and even hardware" was true when I was at university. In the 
1980s and 1990s.

Gathering evidence is indeed part of science, and computer science is 
indeed mathematics, but alas programmering is just a craft and software 
engineering often ... isn't.

Anyway, I would hope we're all for more rigour rather than less.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Julio Di Egidio]

On Sunday, 20 December 2020 at 23:16:10 UTC+1, cameron...@gmail.com wrote:
> On 20Dec2020 20:34, Karsten Hilbert  wrote: 
> >> Trust me: it takes 100x getting anything done plus keep up with your 
> >> prayers, and it takes 100^100x learning anything solid, as in just forget 
> >> about it. Indeed, consider that we are rather going to the formal 
> >> verification of programs, software, and even hardware... 
> > 
> >I sincerly wish you that your hope becomes reality within your 
> >lifetime.
> 
> Aye, since "we are rather going to the formal verification of programs, 
> software, and even hardware" was true when I was at university. In the 
> 1980s and 1990s. 

You could have taken the chance to pay attention, as after 30 years of fake 
agility, lies over the very state of the art, and of course the chronic 
spectacular failures, the defamation game and the misery of an entire industry, 
we are eventually getting back to where we were.  And, while we are still quite 
far from an end-to-end integrated experience, by now, Dec 2020, it is already 
the case that there are enough systems, libraries/components and of course the 
underlying theory that for the practitioner (i.e. the professional in the 
field) the problem at the moment is rather which ones to commit to (i.e. invest 
money and time into).

> Gathering evidence is indeed part of science, and computer science is 
> indeed mathematics, but alas programmering is just a craft and software 
> engineering often ... isn't. 

Programming is a *discipline*, while you keep echoing cheap and vile marketing 
nonsense.

> Anyway, I would hope we're all for more rigour rather than less. 

I am sure you do, rigour mortis eventually...

EOD.

Julio
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Ethan Furman]

On 12/20/20 6:06 PM, Julio Di Egidio wrote:


You could have taken the chance to pay attention



Programming is a *discipline*, while you keep echoing cheap and vile marketing 
nonsense.



I am sure you do, rigour mortis eventually...


Mean-spirited and hostile messages are not welcome on this list.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[Chris Angelico]

On Mon, Dec 21, 2020 at 1:11 PM Julio Di Egidio  wrote:
> > Gathering evidence is indeed part of science, and computer science is
> > indeed mathematics, but alas programmering is just a craft and software
> > engineering often ... isn't.
>
> Programming is a *discipline*

It's a discipline, a science, AND an art. I love programming :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: How do you find what exceptions a class can throw?

[Avi Gross via Python-list]

The original question sounded like someone was asking what errors might be
thrown for a routine they wrote that used other components that might
directly throw exceptions or called yet others, ad nauseum.

Some have questioned the purpose.

I can well imagine that if such info was available, you could construct a
data structure such as a graph and trace every possible error  that could
propagate back. But I am not so sure it is that simple.

Some of the intervening functions will quite possibly deal with those
errors. If a routine downstream already knows a further function might
divide by zero, it may arrange to capture that exception and deal with it.
So it will not likely propagate up from that source, albeit a second path
may also possibly let it propagate through on another such bad calculation
that does not deal with it.. 

Further, some programs have code that checks the environment and may use
different functions/methods if on one kind of machine or OS or version of
python than another. Ideally you would need to know the profile for the
build you are on. And with interpreted languages, some are not so much built
ahead of time as assembled as they go. Loading an alternate module or
library with functions having the same names, may bring in a very different
profile of possible exceptions.

And what if your function is later used by others and they do not know you
added code to intercept all possible interruptions and chose how to deal
with them and they write code hoping to intercept something that then never
arrives. Things may fail differently than expected. Some nice programming
tricks that depend on it failing sometimes, may no longer work as expected.

What exactly is the right way to deal with each interrupt? Choices range
from ignoring them while squelching them, to passing them along relatively
unchanged, perhaps logging what came by, raising a different exception,
perhaps your own new variety, or just halting everything. 

Any time some deeper software is changed, as for a bug fix, they may change
the profile of propagated errors. A routine that once worried about running
out of memory may instead change to only working on memory pre-allocated in
large blocks yet leave in the code that would throw an exception if it is
ever reached. It may be it can now never happen but yet you might still be
on the lookout for it, especially if the documentation does not change or
you do not read it each and every time.

I also wonder at the complexity of the code needed. If a given error in a
dozen places can generate the same exception, can you tell them apart so
each has an appropriate solution or do you lump them together? Can you
replace a function with a few lines of code with thousands of lines of
just-in-case code and remain viable if every function does this and you have
giant programs that use lots of CPU and memory?

I would say it is a more laudable goal for each function to publish what
interrupts they do NOT handle that might come through and perhaps why. Any
they claim to handle make it moot what happens further along the stream if
done right. Bulletproofing even then may seem harmless, of course. I have
had cases where I intercepted ALL errors when a rare case broke code I used
that  I did not write. I got an odd error  maybe once every million times
running on random simulated data and I just wanted to throw that result away
and keep a subset of those that worked and converged and passed some
post.tests. It did not matter to me why it failed, just that it not be
allowed to crash the program entirely. Trying to deal with every possible
exception would have been overkill.

So, I do sympathize with a wish to be able to decide what errors might arise
and be able to decide if having your code deal with it makes sense. I just
suggest whatever you do in the general case may not be optimal. It may do
too much and yet allow problems to seep through.





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you find what exceptions a class can throw?

[2QdxY4RzWzUUiLuE]

On 2020-12-20 at 21:46:48 -0500,
Avi Gross via Python-list  wrote:

[...]

> I would say it is a more laudable goal for each function to publish
> what interrupts they do NOT handle that might come through and perhaps
> why ...

I'm not disagreeing.  Documenting important decisions and the reasons
behind them is amongst the best of Best Practices.

That said, either way, it's the same thing.  If A calls B, and B calls
C, and B claims *not* to handle exceptions X and Y, then A has to track
down everything else that might come from C, and we're right back to
square one (or square zero, but I digress).

> So, I do sympathize with a wish to be able to decide what errors might
> arise and be able to decide if having your code deal with it makes
> sense. I just suggest whatever you do in the general case may not be
> optimal. It may do too much and yet allow problems to seep through.

Excellent point, and well said.

So how do we eliminate the general case?  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list() strange behaviour

[Cameron Simpson]

On 21Dec2020 08:09, Cameron Simpson  wrote:
>>b = ((x[0] for x in a))
>
>This is a generator comprehension, and _not_ a list.

I should amend this: a "generator _expression_", not comprehension. A 
"generator comprehension" is not a thing.

Apologies,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list