[Python-ideas] Re: Addition of a "plus-minus" binary numeric operator

[Ir. Robert Vanden Eynde]

Add you can call this function plusminus
Then use the funcoperators module to write :

upper, lower = a +plusminus- b

pip install funcoperators

Le mar. 14 sept. 2021 à 16:02, Paul Moore  a écrit :

> I doubt it, it seems way too specialised to be worth making into a
> language feature.
>
> If you want to, you can write a function:
>
> def limits(a, b):
> return a+b, a-b
>
> Paul
>
> On Tue, 14 Sept 2021 at 14:55,  wrote:
> >
> > Hi all,
> >
> > I was wondering on whether there is any interest in introducing a
> "plus-minus" operator:
> >
> > Conceptually very simple; instead of:
> >
> > upper, lower = a + b, a - b
> >
> > use instead:
> >
> > upper, lower = a +- b
> >
> > In recent projects I've been working on, I've been having to do the
> above "plus minus" a lot, and so it would simplify/clean-up/reduce error
> potential cases where I'm writing the results explicitly.
> >
> > It isn't a big thing, but seems like a clean solution, that also takes
> advantage of python's inherent ability to return and assign tuples.
> > ___
> > 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/MCAS5B63Q6ND74GEBP2N3OF3HLISSQMA/
> > 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/XYRRZPCPWF6VJTBX3MAWCIQEWXJC5F3X/
> 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/527MLDIJ3EHBPGSS2KJ4CBP3RVMR4JBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Ir. Robert Vanden Eynde]

> solve(x**2 == 1/2)

pip install funcoperators

>>> solve(x ** 2 |Equals| 1/2)
<<< Equals = infix(Eq)
<<< from sympy import Eq

Le mer. 19 mai 2021 à 08:40, Martin Teichmann 
a écrit :

> Hi list,
>
> as you might have noticed, I am trying to improve the syntax and semantics
> for symbolic math in Python. Until now, I have to say, my ideas were not
> that well received, but I learned from the discussion and maybe this time I
> come up with something people like.
>
> To frame the problem, let us try  to solve the equation x ** 2 == 1/2
> using sympy:
>
> >>> from sympy import Eq, solve, symbols, S
> >>> x = symbols("x")
> >>> solve(Eq(x**2, S(1)/2))
> [-sqrt(2)/2, sqrt(2)/2]
>
> that worked well, but actually we would like to write the last line simply
> as
>
> >>> solve(x**2 == 1/2)
>
> as you might notice, this is fully legal Python syntax. Unfortunately the
> semantics is such that sympy has no way to determine what is actually going
> on, this is why they invented all those helper functions shown above.
>
> My idea is now to start at the line above, "x = symbols('x')". I propose a
> new syntax, "symbolic x", which tells the parser that x is a symbolic
> variable, and expressions should not be executed, but handed over as such
> to the calling functions. To stay with the example, the code would look
> like this (this is fake, I did not prototype this yet):
>
> >>> from sympy import solve
> >>> symbolic x
> >>> solve(x**2 == 1/2)
> [-sqrt(2)/2, sqrt(2)/2]
>
> Now to the details. The scope that "symbolic" acts on should be the same
> as the scope of "global". Note that "symbolic x" is currently illegal
> syntax, so we would not even need to make "symbolic" a keyword.
>
> Expressions that contain a symbolic variable are not executed, but instead
> the expression should be given to the function as a tuple, so in the
> example above, solve would be given
> ('==', ('**', ('x', 2)), ('/', 1, 2)). If that looks like LISP to you,
> then you are not completely wrong. The boundaries of expressions are
> function calls, assignments, getitems and getattrs, as they can be
> overloaded much easier by other means. To give an example with gory details
> (again, this is fake):
>
> >>> symbolic x
> >>> d = {"a" : 5}
> >>> c = 7  # not symbolic!
> >>> print(c * x + d["a"])
> ('+', ('*', 7, 'x'), 5)
>
> Maybe we would want to have a new class "expressiontuple" which simply
> acts as a pretty-printer, then the last lines would become
>
> >>> print(x + d["a"])
> 7 * x + 5
>
> What sympy does with this tuple would be fully at its discretion.
>
> I think that other libraries could also benefit from this proposal. As an
> example, in a numerics library (numpy? scipy?) one could improve numerical
> integration as in
>
> >>> symbolic x
> >>> integrate(sin(x), x, 0, pi)
>
> then the integrator could even compile the expression to machine code for
> faster integration.
>
> numpy could also compile expressions to machine code, making it even
> faster than it is now, as in
>
> >>> symbolic x
> >>> f = compile(5 * x + 7 * y, (x, y))
> >>> f(matrix_a, matrix_b)
>
> Let's see how well this proposal fares.
>
> Cheers
>
> Martin
> ___
> 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/ZMUV4OUDUX3NSROM2KRUIQKSIBUCZOCD/
> 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/WWFJQRGBLVJIEHHVDIMJ27W65FSKC6QB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Ir. Robert Vanden Eynde]

SUB

Hello everyone, what is the usual way to "like" a mail in the maillist and
subscribing to the thread ?

By sending a message it adds me to the "Participants" in the webapp which
is neat (I can then search for my messages)

I could do it in the webapp but not everybody will see it

Le mer. 19 mai 2021 à 17:02, David Lowry-Duda  a
écrit :

> > To frame the problem, let us try  to solve the equation x ** 2 == 1/2
> > using sympy:
> >
> > >>> from sympy import Eq, solve, symbols, S
> > >>> x = symbols("x")
> > >>> solve(Eq(x**2, S(1)/2))
> > [-sqrt(2)/2, sqrt(2)/2]
> >
> > that worked well, but actually we would like to write the last line
> simply as
> >
> > >>> solve(x**2 == 1/2)
>
> This is essentially how this would be written in sagemath (a CAS
> exposing various FOSS math software behind a unified python-based
> interface). More about sagemath can be found at https://www.sagemath.org/
>
> In sage, this would be written
>
> solve([x**2 == 1/2], x)
>
> The additional "x" is because sage also accepts things like
>
> y = var('y')
> solve([x**2 == y], x) # solve for x in terms of other variables
>
> Large amounts of sage are written in python, including essentially the
> whole symbolic mathematics stack. I'm personally content with using a
> CAS like sage when I want to manipulate mathematics and keeping symbolic
> math separate from my default python interpreter.
>
> - DLD
> ___
> 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/PMUPJJJ7NSYORYVB27D67YUDT2HWA4OX/
> 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/5MKWRVXL5SIQBEABUWKBRYNPMZV2G4E2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Ir. Robert Vanden Eynde]

Static analysis and factorisation, I sub ! :D

Le mar. 11 mai 2021 à 01:47, Rob Cliffe via Python-ideas <
python-ideas@python.org> a écrit :

>
>
> On 10/05/2021 12:43, Chris Angelico wrote:
> > On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano 
> wrote:
> >> On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
> >>> On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano 
> wrote:
> >> [...]
>  Is there an aim beyond saving two characters?
> >>> It would remove a level of frustration. I've watched a lot of novice
> >>> programmers, and some intermediate programmers, run into a source of
> >>> (now completely unnecessary) pain that changing this:
> >>>
> >>> except ValueError:
> >>>
> >>> into this:
> >>>
> >>> except ValueError, TypeError:
> >>>
> >>> doesn't work. Yes, it's a quick SyntaxError,
> >> You say it is completely unnecessary, but is it? The way `as` currently
> >> works and the way this proposal will have it work are just different
> >> enough to make me fret.
> >>
> >>  import spam, eggs, cheese, aardvark as hovercraft
> >>
> >>  with spam, eggs as f
> >>
> >>  except ValueError, KeyError, TypeError as err
> >>
> >> How long will it be before people, fooled by the similarity to other
> >> uses of `as`, try writing this:
> >>
> >>  except ValueError as verr, KeyError as kerr, TypeError as terr
> >>
> >> and how soon after that before people propose it as an actual feature?
> >>
> >>
> >>> but the editor won't show
> >>> it up (since most editors are Python 2 compatible, and wouldn't be
> >>> checking this level of syntax anyway), so there's X amount of time
> >>> spent coding, then go to run the thing, and it won't work the way they
> >>> expect it to.
> >> "My editor doesn't recognise this error" is not a strong argument in
> >> favour of a change that otherwise adds no new functionality.
> >>
> >>
> >>> If it weren't for the Python 2 issues, would there be any good reason
> >>> for demanding parentheses? We don't need them in a for loop:
> >>>
> >>> for i, thing in enumerate(stuff):
> >> True, but we do need them here:
> >>
> >>  [1,x for x in range(3)]
> >>
> >> even though there is only one possible interpretation of the code. It
> >> can't be `[1, generator]` because the hypothetical generator expression
> >> isn't parenthesized.
> >>
> >> Sometimes we require parens as a "belts and braces" sort of thing.
> >> There's no *actual* syntactic ambiguity, but we require the parens just
> >> to be sure:
> >>
> > a := len('abc')
> >>File "", line 1
> >>  a := len('abc')
> >> ^
> >> SyntaxError: invalid syntax
> > (a := len('abc'))
> >> 3
> >>
> >>
> >> I feel the same about this proposal. Without the brackets grouping the
> >> exceptions, it feels too close to binding only the last one in the group
> >> rather than the entire tuple of exceptions.
> >>
> > What if the parens could be omitted only if there's no 'as' clause?
> > That eliminates the ambiguity. Is it really necessary to clarify what
> > "except TypeError, ValueError:" means, either to the interpreter or to
> > another programmer? Every objection has been based on the confusion of
> > "except TypeError, ValueError as e:", and I agree with that.
> >
> >
> +0.9.  A practical solution, although it makes the language definition
> more complicated.  Practicality beating purity.
> Rob Cliffe
> ___
> 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/7PRV7OMPN52GOFF6HLNPCCD7FBE3MQ2J/
> 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/L7ERN3BHWC652L622ONIRARNWACUJRJT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Ir. Robert Vanden Eynde]

There it is :
https://mail.python.org/archives/list/python-ideas@python.org/message/B4EPUQA3GCAXYWB6YMMNAJPMWP5L3QUH/


Le mar. 18 mai 2021 à 12:43, Ir. Robert Vanden Eynde 
a écrit :

> This thread seems related to the other thread I just answered I don't
> find, I wrote "julia" there, hmmm
>
> Le mar. 18 mai 2021 à 12:41, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> a écrit :
>
>> David Mertz writes:
>>  > On Fri, May 14, 2021, 4:31 PM Jonathan Fine 
>> wrote:
>>  >
>>  > > >>> 1/2 + 1/3
>>  > >> 5/6
>>  > >> >>>> 1 / 2 + 1 / 3
>>  > >> 0.83
>>  > >>
>>  > >
>>  > > I'm sighted. I can see the difference. I suspect a blind person
>> using a
>>  > > screen reader would struggle a lot to spot the difference.
>>
>> This is a really good point.  I think a screen reader that reads out
>> whitespace would be really annoying if it were more frequent than,
>> say, paragraph breaks.
>>
>>  > However, the existing `/` was given a backwards incompatible meaning of
>>  > "true division" and the new `//` operator took on floor division. I
>> still
>>  > believe that was the wrong way around. I thought the existing operator
>>  > should keep the same meaning,
>>
>> That *would* have been true if str = Unicode didn't break the world.
>> But by freshman year in college students expect real division (either
>> with a fractional result or a float result).  I think it was better to
>> cater to that prejudice.  (At least that's true here in Japan, where
>> few students do programming before they get here, and was true in
>> Columbus Ohio a couple decades ago.  These are schools where most
>> students come from pretty good high schools and the students have
>> access to computers to learn programming if they wanted to.)
>>
>>
>> ___
>> 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/TCG5DKNAB3BAJG563IIG6FR5DBZ5ABQL/
>> 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/7OXDH4O5JSTBHBE45YF2FZ5AQI6RIJZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Ir. Robert Vanden Eynde]

This thread seems related to the other thread I just answered I don't find,
I wrote "julia" there, hmmm

Le mar. 18 mai 2021 à 12:41, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> a écrit :

> David Mertz writes:
>  > On Fri, May 14, 2021, 4:31 PM Jonathan Fine 
> wrote:
>  >
>  > > >>> 1/2 + 1/3
>  > >> 5/6
>  > >>  1 / 2 + 1 / 3
>  > >> 0.83
>  > >>
>  > >
>  > > I'm sighted. I can see the difference. I suspect a blind person using
> a
>  > > screen reader would struggle a lot to spot the difference.
>
> This is a really good point.  I think a screen reader that reads out
> whitespace would be really annoying if it were more frequent than,
> say, paragraph breaks.
>
>  > However, the existing `/` was given a backwards incompatible meaning of
>  > "true division" and the new `//` operator took on floor division. I
> still
>  > believe that was the wrong way around. I thought the existing operator
>  > should keep the same meaning,
>
> That *would* have been true if str = Unicode didn't break the world.
> But by freshman year in college students expect real division (either
> with a fractional result or a float result).  I think it was better to
> cater to that prejudice.  (At least that's true here in Japan, where
> few students do programming before they get here, and was true in
> Columbus Ohio a couple decades ago.  These are schools where most
> students come from pretty good high schools and the students have
> access to computers to learn programming if they wanted to.)
>
>
> ___
> 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/TCG5DKNAB3BAJG563IIG6FR5DBZ5ABQL/
> 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/YD7WID5ZTDZIP42ADUVME26XYX5JLHZ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python 3.10: ranges in pattern matching

[Ir. Robert Vanden Eynde]

Scala also has "match" cases that are Class redefinable, used for regex for
example

About integers ranges, we already have the master class : builtins.range

pip install funcoperators deals with the issue like this :

for i in 1 /irange/ 5:
  print(i)  # will print 1 2 3 4 5

Where irange = infix(lambda a,b: range(a, 1+b))

About matching, switch case does not exist in python because if/elif/else
cascade exists

if (x := 5) in irange(1, 5):
  println(stuff1)
elif x == 8
  println(stuff2)
else:
  println(stuff3)

and with factorization :

print(stuff1 if (x := 5) in irange(1, 5) else
stuff2 if x == 8 else
stuff3)

Le mer. 12 mai 2021 à 21:41, Valentin Dymchishin 
a écrit :

> Hi everyone!
> I've just read about pattern matching in Python 3.10, and it sounds really
> nice.
> I've also found out that Rust supports ranges in pattern matching.
>
>
> https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html#matching-ranges-of-values-with-
>
> fn main() {
> let x = 5;
> match x {
> 1..=5 => println!("one through five"),
> _ => println!("something else"),
> }
> }
>
> Can we have something similar please? I think this would be a nice
> addition to Python's pattern matching.
> ___
> 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/CLPYX3HUCH3J4LQEWSTBYBEXBSLJXHOO/
> 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/N6XMXZ73P6GF24NHT4P345ZYDXPAYE4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it

[Ir. Robert Vanden Eynde]

Julia has these kind of builtin things.

The main problem is backward compatibility.
However your tool is useful as a python-to-python parser (from the) (I
remember some static analysis tools like "mpy"?)

pip install funcoperators  solve
the problem differently :

From: (1/2).denominator -}
To: (1 /frac/ 2).denominator
With: frac = infix(Fraction)
With: from Fraction import fractions


Le mar. 18 mai 2021 à 09:40, Martin Teichmann 
a écrit :

> Hi List,
>
> some days ago I posted about my idea let integer division result in
> fractions, not floats. The upshot of the discussion was that it is a pity
> that we do not have literals for fractions, but that there is nothing to do
> about it, as all proposed syntaxes were a bit ugly.
>
> But why do we need to have different syntax for both, isn't it possible to
> simply do both at the same time? The interesting answer is: yes. So my
> proposal is: number literals (which are not integers) are both fractions
> and floats a the same time - only when we start calculating with them, the
> receiving function will pick whatever it prefers. For backwards
> compatiblity the default is float - but you may write code that looks at
> the fraction as well.
>
> I prototyped that here: https://github.com/tecki/cpython/tree/ratiofloat
>
> The idea is the following: when  the parser (technically, the AST
> optimizer) creates the objects that represents the literals, let it add
> some bread crumbs as to where those data are coming from. Currently, 1/2
> just means the float 0.5. Instead, let it be the object of a new class, I
> dubbed it ratiofloat, which inherits from float, but has the exact value
> added to it as well. ratiofloat just adds two C ints to the float class,
> making it a bit bigger. But as I said, only for literals, calculated floats
> still have the same size as before.
>
> To give an example (this is not fake, but from the prototype):
>
> >>> 2/5
> 0.4
> >>> (2/5).denominator
> 5
> >>> isinstance(2/5, float)
> True
> >>> type(2/5)
> 
>
> Note that this is only done at compile time, no such behavior is done at
> run time, everything just behaves like normal floats:
>
> >>> two=2
> >>> five=5
> >>> (two/five)
> 0.4
> >>> (two/five).numerator
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'float' object has no attribute 'numerator'
>
> I have tested this, and all tests pass except those where it is explicitly
> tested whether a value is a float, not one of its subclasses. I ran that
> also through numpy and sympy, and both behave mostly fine, except again
> where the tests are testing whether something is actually a float.
>
> All of this does not only work for integers, but also for float literals:
>
> >>> a=1/3 + 0.1
> >>> a
> 0.43335
> >>> a.numerator
> 13
> >>> a.denominator
> 30
>
> All this is only interesting once you teach some classes about it. To give
> an example here:
>
> >>> from decimal import Decimal
> >>> Decimal(1/3)
> Decimal('0.')
> >>> Decimal(0.1)
> Decimal('0.1')
> >>> from fractions import Fraction
> >>> Fraction(1/3)
> Fraction(1, 3)
> >>> Fraction(0.1)
> Fraction(1, 10)
>
> I also tries to teach sympy about this. While I succeeded in general,
> there were many tests that failed, and that for an interesting reason: the
> sympy tests seem to assume that if you use a float, you want to tell sympy
> to calculate numerically. So for the sympy tests, 0.1*x and x/10 are
> something completely different. IMHO this is actually an abuse of features:
> 0.1 simply is the same as one-tenth, and code should at least try to treat
> it the same, even if it fails at that. Other than that, sympy works fine
> (after I taught it):
>
> >>> from sympy import symbols
> >>> x = symbols("x")
> >>> 1.5*x
> 3*x/2
> >>> x**(0.5)
> sqrt(x)
>
> I think this is now all good enough to be wrapped in a PEP, Chris, can you
> guide me through the bureaucracy?
>
> How would we go forward about this? The good news is that all that I
> described happens at compile time, so we can use a good ole' "from
> __future__ import" approach. So my suggestion is: implement it for 3.11,
> but activate it only with a future import or an interpreter option for the
> command line. This gives libraries time to adopt to this new style. For
> 3.12, make this option the default for the command line. So we can tell
> people to just switch that option off if it doesn't work. And in some far,
> glorious future, when everybody has a from __future__ line in all of their
> files, we can make it a default everywhere.
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3