On Mon, Oct 12, 2020 at 6:52 PM wrote:
> Greg Ewing wrote:
> > > You can reduce the amount of boilerplate by doing something
> > like this:
> > class MySpecialException(Exception):
> > pass
> > def handle_my_special_exception(a, b, c, d, e, f):
> >
> > try:
> > if some_test_th
On 10/12/20 10:18 PM, William Pickard wrote:
> Once against, need I remind you that Python doesn't support defining output
> variables like C#/.NET does, the only way to do it is via the globals/locals
> dict objects which must either be manually provided or fetched from the
> stacktrace.
Pytho
Once against, need I remind you that Python doesn't support defining output
variables like C#/.NET does, the only way to do it is via the globals/locals
dict objects which must either be manually provided or fetched from the
stacktrace.
___
Python-idea
Greg Ewing wrote:
> > You can reduce the amount of boilerplate by doing something
> like this:
> class MySpecialException(Exception):
> pass
> def handle_my_special_exception(a, b, c, d, e, f):
>
> try:
> if some_test_that_fails(variables):
>raise MySpecialException(a, b
I think this can stand on its own without needing to be borrowed from another
language. This pattern of needing special objects for exceptions causes me to
avoid them since the boilerplate overhead discourages their use.
___
Python-ideas mailing list --
On 13/10/20 10:16 am, jmwar...@gmail.com wrote:
class MySpecialException(Exception):
def __init__(self, some, variables, i, am, tracking):
self.some = some
...
...
try:
if some_test_that_fails(variables):
raise MySpecialException(a, b, c, d, e, f)
except MySpecialException
Name a language that supports capturing/raising exceptions that allow this.
Not only that, Python doesn't even support output variables like C#/.NET does.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-idea
I generally find exception objects are really just boilerplate heavy objects
masking what I really want them to be, function calls:
class MySpecialException(Exception):
def __init__(self, some, variables, i, am, tracking):
self.some = some
...
...
try:
if some_test_that_fails(variab
On 12/10/20 10:39 am, Wes Turner wrote:
We should not discard the scalar in scalar*infinity expressions.
I don't think that would help as much as you seem to imagine it would.
Consider f(x) = 1/x**2, g(x) = 1/x**3, h(x) = f(x) / g(x).
Keeping a scalar multiplier attached to infinities isn't
On Mon, 12 Oct 2020 at 07:23, Christopher Barker wrote:
>
> FWIW, if a change were to be made, I'd rather it be some kind of float error
> handling context: either a global setting, like numpy's, or a context
> manager. With, of course, the default behavior just like it's been forever.
You can
On Mon, Oct 12, 2020, 9:50 AM Stephen J. Turnbull
> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of ordinals, but
> it should work I think). (Maybe the surreals are constructed from the
> ordinals as the reals are
On Mon, 12 Oct 2020 at 14:51, Stephen J. Turnbull
wrote:
>
> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of
> ordinals, but it should work I think).
I don't think it does. The ordinals are based on the idea of
*or
David Mertz writes:
> On Sun, Oct 11, 2020, 9:07 PM Steven D'Aprano
>
> > Even in the cardinal numbers, two times infinity (aleph-0) is just
> > aleph-0; however you might be pleased to know that two to the power of
> > aleph-0 is aleph-1.
> >
>
> Oh... So you're one of those who believe
It is suggested to employ if/else, the new pattern matching feature, or
functional decomposition rather than nesting exceptions.
https://discuss.python.org/t/add-way-to-reenter-previous-try-block/4526/2
Pattern matching will look syntactically cleaner.
Exceptions are slow (only when an exception
On Mon, Oct 12, 2020 at 09:40:40PM +1100, Steven D'Aprano wrote:
> Using the proposed syntax, both of these would be written as:
>
> try:
> ...
> except A try:
> ...
> except B:
> ...
> except C:
> ...
>
> with no way of telling whether the "except
On Sun, Oct 11, 2020 at 01:04:46PM -0400, Wes Turner wrote:
> (I must have missed the 'try' suffix)
Indeed. And this is, in my opinion, a major problem with the suggestion.
It obfuscates the code, hiding the fact that a new try block has been
started.
To be fair to the proposal, it does save a
This is quite similar to something I suggested on Python Discussions
https://discuss.python.org/t/add-way-to-reenter-previous-try-block/4526
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pytho
17 matches
Mail list logo
