Very often I use the following construction (especially in operators):
try:
something
except SomeError:
try:
something_else
except AnotherError:
try:
something_completely_different
except Whatever:
How is this different from the existing exception handling?
>From https://docs.python.org/3/tutorial/errors.html#exceptions :
> The last except clause may omit the exception name(s), to serve as a
wildcard. Use this with extreme caution, since it is easy to mask a real
programming error in this
I'm not advocating for it (nor against it). But the OP proposes something
clear different from the example in current Python.
On Sun, Oct 11, 2020, 12:39 PM Wes Turner
> try:
> f = open('myfile.txt')
> s = f.readline()
> i = int(s.strip())
> except OSError as err:
> print("OS erro
(I must have missed the 'try' suffix)
On Sun, Oct 11, 2020, 1:04 PM Wes Turner wrote:
> Nested exceptions indicated by a 'try' suffix added to the exception
> expression
>
> How could these (else-if and nested conditional) syntaxes be combined?
>
> On Sun, Oct 11, 2020, 12:46 PM David Mertz wro
Nested exceptions indicated by a 'try' suffix added to the exception
expression
How could these (else-if and nested conditional) syntaxes be combined?
On Sun, Oct 11, 2020, 12:46 PM David Mertz wrote:
> I'm not advocating for it (nor against it). But the OP proposes something
> clear different
On Sun, Oct 11, 2020 at 6:48 PM David Mertz wrote:
> I'm not advocating for it (nor against it). But the OP proposes something
> clear different from the example in current Python.
>
> On Sun, Oct 11, 2020, 12:39 PM Wes Turner
>
>> try:
>> f = open('myfile.txt')
>> s = f.readline()
>>
It stood out pretty clearly to me. In my example I added an 'as err' clause
that the OP. That does make it stand out less.
I've used those nested try's myself at times. But I'm concerned the syntax
would encourage an antipattern.
Although they are not identical, it seems like this should address
Arbitrary-precision multiple-precision floats in Python: mpmath, gmpy,
sympy .evalf() / N()
https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
- https://github.com/fredrik-johansson/mpmath
> Python library for arbitrary-precision floating-point arithmetic
- docs: http://mpmath.org/d
SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results
FWIW, SymPy (a CAS: Computer Algebra System) has Infinity,
NegativeInfinity, ComplexInfinity.
Regarding a symbolic result for 1/0:
If 1/0 is infinity (because 0 goes into 1 infinity times),
is 2/0 2*inifnity (because 0 goes into 2 2
On Sun, 11 Oct 2020 at 19:53, Wes Turner wrote:
> Arbitrary-precision multiple-precision floats in Python: mpmath, gmpy, sympy
> .evalf() / N()
mpmath has always a global precision:
http://mpmath.org/doc/current/basics.html#setting-the-precision
About SymPy, I worked a little with it within Sag
On Mon, Oct 12, 2020 at 5:06 AM Wes Turner wrote:
>
> SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results
>
> FWIW, SymPy (a CAS: Computer Algebra System) has Infinity, NegativeInfinity,
> ComplexInfinity.
>
> Regarding a symbolic result for 1/0:
>
> If 1/0 is infinity (because 0 goes
So you're arguing that the scalar is irrelevant?
That `2*inf == inf`?
I disagree because:
```2*inf > inf```
And:
```# Given that:
inf / inf = 1
# When we solve for symbol x:
2*inf*x = inf
2*x = 1
x = 1/2
# If we discard the scalar instead:
2*inf*x = inf
inf*x = inf
x = 1
# I think it's speci
On Mon, Oct 12, 2020 at 8:07 AM Wes Turner wrote:
>
> So you're arguing that the scalar is irrelevant?
> That `2*inf == inf`?
>
> I disagree because:
> ```2*inf > inf```
On what basis? If you start by assuming that infinity is a number,
then sure, you're going to deduce that double it must be a g
On 10/11/20 5:04 PM, Wes Turner wrote:
> So you're arguing that the scalar is irrelevant?
> That `2*inf == inf`?
>
> I disagree because:
> ```2*inf > inf```
>
> And:
>
> ```# Given that:
> inf / inf = 1
>
> # When we solve for symbol x:
> 2*inf*x = inf
> 2*x = 1
> x = 1/2
>
> # If we discard the sc
No, 2 times something is greater than something. Something over something
is 1.
If we change the division axiom to be piecewise with an exception only for
infinity, we could claim that any problem involving division of a symbol is
unsolvable because the symbol could be infinity.
This is incorrect:
Indeed, perhaps virtual particles can never divide by zero and thus the
observed laws of thermodynamic systems are preserved.
Would you please be so kind as to respond in the main thread so that this
is one consecutive thread?
No, 2 times something is greater than something. Something over someth
On Mon, Oct 12, 2020 at 8:42 AM Wes Turner wrote:
>
> No, 2 times something is greater than something. Something over something is
> 1.
>
> If we change the division axiom to be piecewise with an exception only for
> infinity, we could claim that any problem involving division of a symbol is
>
On 10/11/20 5:47 PM, Wes Turner wrote:
> Indeed, perhaps virtual particles can never divide by zero and thus
> the observed laws of thermodynamic systems are preserved.
>
> Would you please be so kind as to respond in the main thread so that
> this is one consecutive thread?
>
> No, 2 times som
On Sun, Oct 11, 2020 at 05:47:44PM -0400, Wes Turner wrote:
> No, 2 times something is greater than something. Something over something
> is 1.
Define "something". Define "times" (multiplication). Define "greater
than". Define "over" (division).
And while you are at it, don't forget to define
Can you explain why Python should behave differently than other
languages?
Python:
>>> math.inf == 2 * math.inf
True
JavaScript:
> Infinity == 2 * Infinity
true
Wolfram Alpha:
https://www.wolframalpha.com/input/?i=inf+%3D+2+*+inf+%3D+3+*+inf
∞ = 2∞ = 3∞
True
On Sun, 2020-10-11 at 17:39 -0400,
Thank you for the overview. It seems as though this community will also
look to IEEE-754 (the IEEE Standard for Floating-Point Arithmetic) for
Reals and also Infinity.
Should Python raise exceptions for Integers or [Complex] Fractions
involving Infinity,
or should Python assume that IEEE-754 is th
(OT:
https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox#Obtaining_infinitely_many_balls_from_one
> Using the Banach–Tarski paradox, it is possible to obtain k copies of a
ball in the Euclidean n-space from one, for any integers n ≥ 3 and k ≥ 1,
i.e. a ball can be cut into k pieces so that
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 the Continuum Hypothesis :-).
I was going t
On 12/10/20 3:44 pm, Wes Turner wrote:
[Microscopic] black holes do deal with infinity in certain regards.)
Not really. General relativity predicts that matter will collapse into
a point of zero size and infinite density inside a black hole. But
that's more likely to mean that GR is wrong under
On Mon, Oct 12, 2020, 1:43 AM Greg Ewing
wrote:
> On 12/10/20 3:44 pm, Wes Turner wrote:
> > [Microscopic] black holes do deal with infinity in certain regards.)
>
> Not really. General relativity predicts that matter will collapse into
> a point of zero size and infinite density inside a black h
On Sun, Oct 11, 2020 at 11:04 PM Wes Turner wrote:
> (and the proposed Python implementation of IEEE-754's alternative to
> ZeroDivisionError)
>
Is anyone actually proposing this (i.e. changing how Python handles
division by zero, or other float exceptions) ?
There IS a proposal on the table to
26 matches
Mail list logo
