[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
> 

[Python-ideas] Re: Bringing the print statement back

[Robert Vanden Eynde]

That makes me think of ruby where you can omit some of the function call.

On Wed, Jun 10, 2020, 02:08 Guido van Rossum  wrote:

> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
> prototype:
>
> Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun  9 2020,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> >>> print 2+2
> 4
> >>> print "hello world"
> hello world
> >>> print "hello", input("Name:")
> Name:Guido
> hello Guido
> >>> print 1, 2, 3, sep=", "
> 1, 2, 3
> >>>
>
> But wait, there's more! The same syntax will make it possible to call
> *any* function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>
> Really, *any* method:
>
> >>> class C:
> ...   def foo(self, arg): print arg
> ...
> >>> C().foo 2+2
> 4
> >>>
>
> There are downsides too, though. For example, you can't call a method
> without arguments:
>
> >>> print
> 
> >>>
>
> Worse, the first argument cannot start with a parenthesis or bracket:
>
> >>> print (1, 2, 3)
> 1 2 3
> >>> C().foo (1, 2, 3)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: C.foo() takes 2 positional arguments but 4 were given
> >>> print (2+2), 42
> 4
> (None, 42)
> >>> C().foo [0]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'method' object is not subscriptable
> >>>
>
> No, it's not April 1st. I am seriously proposing this (but I'll withdraw
> it if the response is a resounding "boo, hiss"). After all, we currently
> have a bunch of complexity in the parser just to give a helpful error
> message to people used to Python 2's print statement:
>
> >>> print 1, 2, 3
>   File "", line 1
> print 1, 2, 3
>   ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1,
> 2, 3)?
> >>>
>
> And IIRC there have been a number of aborted attempts at syntactic hacks
> to allow people to call functions (like print) without parentheses,
> although (I think) none of them made it into a PEP. The PEG parser makes
> this much simpler, because it can simply backtrack -- by placing the
> grammar rule for this syntax (tentatively called "call statement") last in
> the list of alternatives for "small statement" we ensure that everything
> that's a valid expression statement (including print() calls) is still an
> expression statement with exactly the same meaning, while still allowing
> parameter-less function calls, without lexical hacks. (There is no code in
> my prototype that checks for a space after 'print' -- it just checks that
> there's a name, number or string following a name, which is never legal
> syntax.)
>
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype
> does not support things like this:
>
> >>> a = (len "abc")
>   File "", line 1
> a = (len "abc")
>  ^
> SyntaxError: invalid syntax
> >>>
>
> I think that strikes a reasonable balance between usability and reduced
> detection of common errors.
>
> I could also dial it back a bit, e.g. maybe it's too much to allow
> 'C().foo x' and we should only allow dotted names (sufficient to access
> functions in imported modules and method calls on variables). Or maybe we
> should only allow simple names (allowing 'len x' but disallowing
> 'sys.getrefcount x'. Or maybe we should really only bring back print
> statements.
>
> I believe there are some other languages that support a similar grammar
> (Ruby? R? Raku?) but I haven't investigated.
>
> Thoughts?
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/
> 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/UCXI3HUCPAQVQ7RWCTDXMY6UP2DYKE2X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom string prefixes

[Robert Vanden Eynde]

On Another Subject, we could also have a language change staying that those
two lines are equivalent :

something"hello"
something("hello")

So that, any callable in the context can be used as a prefix ?

On Tue, Aug 27, 2019, 01:11  wrote:

> In Python strings are allowed to have a number of special prefixes:
>
> b'', r'', u'', f''
> + their combinations.
>
> The proposal is to allow arbitrary (or letter-only) user-defined prefixes
> as well.
> Essentially, a string prefix would serve as a decorator for a string,
> allowing the
> user to impose a special semantics of their choosing.
>
> There are quite a few situations where this can be used:
> - Fraction literals: `frac'123/4567'`
> - Decimals: `dec'5.34'`
> - Date/time constants: `t'2019-08-26'`
> - SQL expressions: `sql'SELECT * FROM tbl WHERE a=?'.bind(a=...)`
> - Regular expressions: `rx'[a-zA-Z]+'`
> - Version strings: `v'1.13.0a'`
> - etc.
>
> This proposal has been already discussed before, in 2013:
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/M3OLUURUGORLUEGOJHFWEAQQXDMDYXLA/
>
> The opinions were divided whether this is a useful addition. The opponents
> mainly argued that as this only "saves a couple of keystrokes", there is no
> need to overcomplicate the language. It seems to me that now, 6 years
> later,
> that argument can be dismissed by the fact that we had, in fact, added new
> prefix "f" to the language. Note how the "format strings" would fall
> squarely
> within this framework if they were not added by now.
>
> In addition, I believe that "saving a few keystroked" is a worthy goal if
> it adds
> considerable clarity to the expression. Readability counts. Compare:
>
> v"1.13.0a"
> v("1.13.0a")
>
> To me, the former expression is far easier to read. Parentheses,
> especially as
> they become deeply nested, are not easy on the eyes. But, even more
> importantly,
> the first expression much better conveys the *intent* of a version string.
> It has
> a feeling of an immutable object. In the second case the string is passed
> to the
> constructor, but the string has no meaning of its own. As such, the second
> expression feels artificial. Consider this: if the feature already
> existed, how *would*
> you prefer to write your code?
>
> The prefixes would also help when writing functions that accept different
> types
> of their argument. For example:
>
> collection.select("abc")   # find items with name 'abc'
> collection.select(rx"[abc]+")  # find items that match regular
> expression
>
> I'm not discussing possible implementation of this feature just yet, we
> can get to
> that point later when there is a general understanding that this is worth
> considering.
> ___
> 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/3Z2YTIGJLSYMKKIGRSFK2DTDIXXVDGEK/
> 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/5VEZTGHHWIGL46LNYBKJB5BAPUBCLTCM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Make $ a valid identifier and a singleton

[Robert Vanden Eynde]

I used "..." in my lib to do that :

from funcoperators import bracket

@bracket
def foo(x, y):
   print(x, y)

partialized = foo[..., 10]
partialized(5)

https://pypi.org/project/funcoperators/

Le dim. 23 juin 2019 à 21:34, James Lu  a écrit :
>
> Make $ a valid identifier and a singleton.
>
>
> $ is a useful placeholder in [].
>
>
> Possible function partial syntax:
>
>
> def foo(x, y):
>
> print(x, y)
>
>
> partialized = foo[$, 10]
>
> partialized(5)
>
> # => 5 10
>
>
> ___
> 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/V7ZCLM3RIVB7CM36OOVW7Q5TQLFGOPUA/
> 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/52GKJTA3NNJQX2NXX5NFHSJ2NSZ6OJUA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `if-unless` expressions in Python

[Robert Vanden Eynde]

>   print([
>  3,
>  if False never_called() unless False,
>  if False never_called() unless False,
>  2,
>  if True 5 unless False,
>  4
>]) # => [3, 2, 5, 4]

Do you mean this ?Currently what I use is the `*` operator on lists :

```
print([
3,
]
+ ([never_called()] if False else [])
+ [
2,
]
+ ([5] if True else [])
+ [
4
]) # => [3, 2, 5, 4]
```
(put the whitespaces where you want)

And if the call to `never_called()` is not important (no need for
shortcircuit) :

```
print([
3,
]+ [
   never_called()
] * False + [
2,
] + [
   5
] * True + [
4
]) # => [3, 2, 5, 4]
```
(put the whitespaces where you want)

You could do things like L = [4,5,2] + ['hello', world'] * (a == 5) + [8,9]

Of course, that's not as optimised as :
L = []
L += [4,5,2]
if a == 5: L += ['hello', world']
L += [8,9]
___
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/4YJ3EXF77KFD3ZMJMNWM33CKE7KE7JU2/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

[Robert Vanden Eynde]

Le mer. 15 mai 2019 à 07:37, Anders Hovmöller  a
écrit :

>
>
> > On 15 May 2019, at 03:07, Robert Vanden Eynde 
> wrote:
> >
> > Currently if one wants to provide positional arguments after keyword
> arguments, it's not possible, one must begin with positional arguments [1]
> or use keyword arguments [2] :
>
>
 In my opinion the goal should be that there is no such thing as positional
> only arguments in python. It's just a bad idea. No r al arguments that can
> be both positional or keyword at the call site, or keyword only. Those are
> good and make sense. Adding a third option is just added complexity.
>

But what if on the call side the user wants to specify y before x but the
definition side wanted "positional only args" for performance reason ?

On another note, there's no way to specify "positional only arguments" in
"pure python" using a syntax used in the documentation like "def f(x, y,
/)" (but def f(*args) will do the trick).

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

[Robert Vanden Eynde]

Currently if one wants to provide positional arguments after keyword
arguments, it's not possible, one must begin with positional arguments [1]
or use keyword arguments [2] :

```
def f(x, *, long_name='foo'): return ...

f(2, long_name='bar')  # [1]
f(long_name='bar', x=2)  # [2]
```

The problem is that it's not always possible to do so because some
functions cannot have keyword arguments (because they call a C function)
like math.hypot :

```
import math
math.hypot(y=5, x=2)  # TypeError
```

A solution is to use partial.

```
from functools import partial
partial(f, long_name='bar')(2)
```

But that begins to be "functional programming style" and that doesn't solve
the case where one would like to change the order of (I created
funcoperators.elipartial for that reason) :

```
from funcoperators import elipartial
elipartial(math.hypot, ..., 5)(2)
```

Of course one could create a tuple and a dict they call f(*a, **k) but
cannot be used inside an expression.

```
k = dict(long_name='bar')
a = (2, )
f(*a, **k)
```

So what would be a good new syntax for that or workaround I didn't think of
?

```
f(**dict(long_name='bar'), *(2, ))

f(long_name='bar', 0=2)
math.hypot(0=5, 1=2)

f(long_name='bar', args[0]=2)
math.hypot(args[0]=5, args[1]=2)

...
```

I don't know if such an idea has been asked before (I don't know how to
formulate it).

robertvandeneynde.be
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal: "?" Documentation Operator and easy reference to argument types/defaults/docstrings

[Robert Vanden Eynde]

Looks like a more complicated way to say :

def f(x:'int : which does stuff' = 5, y:'int : which does more stuffs')

The code reading the annotations (like the linter) might then parse it
simply using .split.

robertvandeneynde.be

Le ven. 26 avr. 2019 à 00:41, Peter O'Connor  a
écrit :

> Dear all,
>
> Despite the general beauty of Python, I find myself constantly violating
> the "don't repeat yourself" maxim when trying to write clear, fully
> documented code.  Take the following example:
>
> def func_1(a: int = 1, b: float = 2.5) -> float:
> """
> Something about func_1
> :param a: Something about param a
> :param b: Something else about param b
> :return: Something about return value of func_1
> """
> return a*b
>
> def func_2(c:float=3.4, d: bool =True) -> float:
> """
> Something about func_2
> :param c: Something about param c
> :param d: Something else about param d
> :return: Something about return value
> """
> return c if d else -c
>
> def main_function(a: int = 1, b: float = 2.5, d: bool = True) -> float:
> """
> Something about main_function
> :param a: Something about param a
> :param b: Something else about param b
> :param d: Something else about param d
> :return: Something about return value
> """
> return func_2(func_1(a=a, b=b), d=d)
>
> Which has the following problems:
> - Defaults are defined in multiple places, which very easily leads to bugs
> (I'm aware of **kwargs but it obfuscates function interfaces and usually
> does more harm than good)
> - Types are defined in multiple places
> - Documentation is copy-pasted when referencing a single thing from
> different places.  (I can't count the number of types I've written ":param
> img: A (size_y, size_x, 3) RGB image" - I could now just reference a single
> RGB_IMAGE_DOC variable)
> - Argument names need to be written twice - in the header and
> documentation - and it's up to the user / IDE to make sure they stay in
> sync.
>
> I propose to resolve this with the following changes:
> - Argument/return documentation can be made inline with a new "?"
> operator.  Documentation becomes a first class citizen.
> - Argument (type/default/doc) can be referenced by "func.args..type"
> / "func.args..default" / "func.args..doc".
> Positional reference: e.g. "func.args[1].default" also allowed.  If not
> specified, they take a special, built-in "Undefined" value (because None
> may have another meaning for defaults).  Return type/doc can be referenced
> with "func.return.type" / "func.return.doc".
>
> This would result in the following syntax:
>
> def func_1(
> a: int = 1 ? 'Something about param a',
> b: float = 2.5 ? 'Something else about param b',
> ) -> float ? 'Something about return value of func_1':
> """ Something about func_1 """
> return a*b
>
> def func_2(
> c: float=3.4 ? 'Something about param c',
> d: bool =True ? 'Something else about param d',
> ) -> float ? 'Something about return value':
> """ Something about func_2 """
> return c if d else -c
>
> def main_function(
> a: func_1.args.a.type = func_1.args.a.default ?
> func_1.args.a.doc,
> b: func_1.args.b.type = func_1.args.b.default ?
> func_1.args.b.doc,
> d: func_2.args.d.type = func_2.args.d.default ?
> func_2.args.d.doc,
> ) -> func_2.return.type ? func2.return.doc:
> """ Something about main_function """
> return func_2(func_1(a=a, b=b), d=d)
>
> If the main_function header seems repetitious (it does) we could allow for
> an optional shorthand notation like:
>
> def main_function(
> a :=? func_1.args.a,
> b :=? func_1.args.b,
> d :=? func_2.args.d,
> ) ->? func_2.return:
> """ Something about main_function """
> return func_2(func_1(a=a, b=b), d=d)
>
> Where "a :=? func_1.args.a" means "argument 'a' takes the same
> type/default/documentation as argument 'a' of func_1".
>
> So what do you say?  Yes it's a bold move, but I think in the long term
> it's badly needed.  Perhaps something similar has been proposed already
> that I'm not aware of.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] contains_any_in and contains_all_in

[Robert Vanden Eynde]

>
> Trivial with re module, which will answer thequestion in one pass.
>

re.search('|'.join(map(re.escape, ['string1', 'string2', 'string3'])),
master_string)

For those who might find it non trivial.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] contains_any_in and contains_all_in

[Robert Vanden Eynde]

Here comes funcoperators again :

if master_string -contains_any_in- ['string1', 'string2', 'string3']:

Given

from funcoperators import infix

@infix
def contains_any_in(string, iterable):
   return any(item in string for item in iterable)

pip install funcoperators
https://pypi.org/project/funcoperators/

robertvandeneynde.be

Le mar. 23 avr. 2019 à 22:39, João Matos  a écrit :

> Hello,
>
> If we want to check if a string contains any/all of several other strings
> we have to use several or/and conditions or any/all.
>
> For any:
> if ('string1' in master_string or 'string2' in master_string
> or 'string3' in master_string):
>
> or
>
> if any(item in master_string for item in ['string1', 'string2', 'string3'
> ]):
>
> For all:
> if ('string1' in master_string and 'string2' in master_string
> and'string3' in master_string):
>
> or
>
> if all(item in master_string for item in ['string1', 'string2', 'string3'
> ]):
>
> I suggest adding some "sugar" to make it more readable by adding
> contains_any_in and contains_all_in to look like this
>
> For any:
> if master_string contains_any_in ['string1', 'string2', 'string3']:
>
> For all:
> if master_string contains_all_in ['string1', 'string2', 'string3]:
>
>
> What do you think?
>
>
> Thanks,
>
> JM
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Starap function exists but it seems there's not such thing as "doublestarmap"

[Robert Vanden Eynde]

robertvandeneynde.be

Le mer. 10 avr. 2019 à 12:55, Krokosh Nikita  a écrit :

> I need smth like starstarmap('{a} / {b}/ {c}'.format, [{a:1, b:2, c:3},
> {a:4, b:5, c:6}, ...])
>

That's

def starstarmap(f, it):
  return (f(**x) for x in it)

That looks like a recipe, not a basis function ^^
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New explicit methods to trim strings

[Robert Vanden Eynde]

> And this really is simple enough that I don't want to reach for regex's
> for it. That is, I'd write it by hand rather than mess with that.
>

Well, with re.escape it's not messy at all :

import re
def trim_mailto(s):
  regex = re.compile("^" + re.escape("mailto:;))
  return regex.sub('', s)

With literally means "if you have mailto: at the beginning, replace it with
the empty string"

You could do a ltrim function in one line :

def ltrim(s, x):
return re.sub("^" + re.escape(x), '', s)

Escape will take care of escaping special characters, so the regex
escape(x) matches exactly the string "x".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Attribute-Getter Syntax Proposal

[Robert Vanden Eynde]

You can do :

I suggest this syntax:
> >>> map(.upper(), ['a', 'b', 'c'])
>

map(dot('upper'), 'a b c'.split())
map(dot('replace', 'x', 'y'), 'xo do ox'.split())

def dot(name, *args, **kwargs):
return lambda self: getattr(self, name)(*args, **kwargs)


> This would also work for attributes:
> >>> map(.real, [1j, 2, 3+4j])
>

from operator import itemgetter
map(itergetter('real'), [...])

from operator import itemgetter as gatt
map(itergetter('real'), [...])


Also, check out my package funcoperators on pip for neat functional
programming syntaxes

https://pypi.org/project/funcoperators/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add a "week" function or attribute to datetime.date

[Robert Vanden Eynde]

Currently one can do week = d.isocalendar()[1]

The iso definition of a week number has some nice properties.

robertvandeneynde.be

On Fri, 1 Mar 2019, 11:44 Antonio Galán,  wrote:

> The week number is usually refered to the week of the year, but the week
> of the month is also interesting, for example for some holiday which depend
> on the week number of the month, so in analogy with "weekday" we can use
> "yearweek" and "monthweek"
> El vie., 1 de marzo de 2019 9:33, Adrien Ricocotam 
> escribió:
>
>> I like the idea. But how to distinguish it from the number of week past
>> since the beginning of the month ?
>>
>> But that’s great.
>>
>> On Fri 1 Mar 2019 at 09:31, Antonio Galán  wrote:
>>
>>> Hi, datetime.date.today() (or other day)  has attributes .year and
>>> .month wich return the year and the month of that date, also it has a
>>> function weekday() wich return the number of the day in the week.
>>>
>>> I think it is a good idea add a function or attribute "week" wich return
>>> the number of the week on the year. It is useful to execute scripts once a
>>> week for example.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Robert Vanden Eynde]

On Thu, 21 Feb 2019, 16:44 Rhodri James,  wrote:

> On 21/02/2019 15:31, Robert Vanden Eynde wrote:
> > In funcoperators, because the dot operator is just syntaxic sugar for
> > functions getattr and setattr with a string,
> [snip hideousness]
>
> I have to say, that's a pretty strong argument for not touching
> funcoperators with a ten foot bargepool.
>

What do you mean ?

I don't mind touching funcoperators, I try to understand the need and find
solutions using existing tools.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Robert Vanden Eynde]

In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,

a.hello.world
# can be implemented using infix
a -o- 'hello' -o- 'world'
# or using postfix
a |dot('hello') |dot('world')

# using
from funcoperators import postfix, infix
o = infix(getattr)
def dot(n):
return postfix(lambda x: getattr(x, n))

For methods, one could write :

a.upper().replace('x', 'y')
# can be implemented by
a |meth('upper') |meth('replace', 'x', 'y')

# using
def meth(x, *a, **b):
 return postfix (lambda self: getattr(self, x)(*a, **b))

And one could do
upper = postfix(str.upper)
def replace(*a, **b):
return postfix(lambda self: self.replace(*a, **b))

# to be able to do :
a |upper |replace('a', 'b')

And of course you can create your own functions to have the behavior you
want.




robertvandeneynde.be

On Thu, 21 Feb 2019, 13:22 Steven D'Aprano,  wrote:

> Correcting myself twice now, that's not a good sign... :-)
>
> On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
>
> > But there's a deeper problem with this entire concept, regardless of
> > syntax, one which to my knowledge nobody has mentioned yet: it simply
> > isn't compatible with the way operators work in Python at the moment.
> > More on this in another post (coming soon).
>
> On further thought, I would like to withdraw that claim.
>
> Actual operators like + - etc of course are implemented using dunder
> methods, but "pseudo-operators" like the dot aren't. If we had such a
> fluent method chain operator, it would be more like dot than ordinary
> operators.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Robert Vanden Eynde]

Heyy, it's funcoperators idea !

>>> [1,2,3].append(4)::sort()::max() +1


[1, 2, 3] |append(4) |to(sorted) |to(max) |to(plus1)

You just have to :

pip install funcoperators

from funcoperators import postfix as to

plus1 = postfix(lambda x: x+1)

from funcoperators import postfix
def append(x):
  return postfix(lambda L: L + [x])

The module also propose a way to have infix operators, so if you want to
have the "::" operator that have the same precedence than "/", you could
call it "/ddot/" and do :

[1,2,3] /ddot/ append(4) /ddot/ sort /ddot/ max +1

But for your case (creating Bash like "pipes" the above solution seems
better).

https://pypi.org/project/funcoperators/

PS: you could create "modify and return" version of "append" or "sort" like
this :

def append(x):
   @postfix
   def new(L):
   L.append(x)
   return L
   return new

Then you'd have :
>>> a = [1,2,3]
>>> b = a |append(5) |append(6)
>>> a is b
True
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

[Robert Vanden Eynde]

On Sat, 2 Feb 2019, 21:46 Brendan Barnwell   some_list @ str.lower @ tokenize @ remove_stopwords
>

→ some_list @ to(str.lower) @ to(tokenize) @ to(remove_stopwords)

Where from funcoperators import postfix as to
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Clearer communication

[Robert Vanden Eynde]

* I didn't have time to read the whole convo' yet *

I think linking to a tutorial on "how to use a mailing list" that shows
some examples on popular email client like Gmail on android or Mail in iOS
would be something really helpful to beginners.

When they subscribe, a bot would send that link alongside a nice welcoming
message.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Clearer communication

[Robert Vanden Eynde]

>
>
> I honestly cannot tell if you are being rhetorical, or if you are
> so technically naive that you genuinely don't know that this is an email
> mailing list rather than instant messenger or IRC or some other form of
> instantaneous chat.
>
Both :p

Newcomers that never spoke on a forum are sometimes lost, they don't see
the structure. Therefore I'm helping those newcomers, and the old timer
will be like "yeah, he technically defines terms that are obvious for me".

When I was a newcomer on this list, I was lost, people said things like
"don't up post" or "don't put the answer below" or "answer inline" in a
jargon I didn't know about.

I'm CS teacher, and I see everyday that things not said explicitly create
misunderstanding to newcomers.


> [...]
> > When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before
> > you Leap), I write a long, but structured message, such that people see
> > first the structure, (intro, body, conclusion), and look in the message
> if
> > they want.
>
> That doesn't sound like the sorts of messages you have been sending
> here recently.
>
Yep, depending on the thread, I'm either type EAFP or LBYL, and I think
people can easily guess which type :) (long message = LBYL).

However, I don't always "read myself two times" before I send (because of
my EAFP nature) so my last mail for example was LBYL but has some spelling
mistakes.

--

And I guess people will ask if they are not sure.

I don't mean this as a criticism of such short posts. Sometimes all that
> needs to be said is a single sentence.

Agreed !!

But when you describe your
> posting style one way, but actually post another way, that is precisely
> the sort of confusing lack of clarity that this thread is about.
>
Indeed, mixing standards is bad, but on the other hand, people can think
"Robert is Eafp", "Robert is more LBYL when writing long messages")
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Clearer communication

[Robert Vanden Eynde]

Email Can be fast, as long as it is structured.

The list only impose the structure of "Thread" ie. Two mails are in the
same thread if they have the same subject.

Each thread can have it's own format.

Email use the quoting mechanism using leading ">" ane generally people do
not like html (switch to TextOnly in your mail client if it helps you).

Therefore inline images are not used often (one prefer).

In the end, anyone can see the list of email, by date, or by thread, on
https://mail.python.org/pipermail/python-ideas/2019-February/thread.html


On Fri, 1 Feb 2019, 18:42 Adrien Ricocotam 

Did you use inclusive writing ? :D do you speak French ? :D Generally I
suggest using the middle dot, "·" easily accessible by copy paste, or by
long pressing the "-" key on android.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Clearer communication

[Robert Vanden Eynde]

That's a nice question !

The main thing is "is this list more EmailLike or MessengerLike"

When I speak on Messenger (or any instantaneous conversation software) I
send a lot of very small messages, like "+1", it's interactive, I'm
expecting a short answer.

If I say something stupid, I undo, if I can't undo because the delay of my
client is done, I send another message beginning with "Oops" or something
obvious. It's the EAFP (Easier to ask for forgiveness than Permission)
style.

The point is "looking ar my first few words, people understand the message"

When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before
you Leap), I write a long, but structured message, such that people see
first the structure, (intro, body, conclusion), and look in the message if
they want.

On Fri, 1 Feb 2019, 17:40 James Lu  A lot of the traffic on this email list is people saying “I don’t
> understand” or “that’s not what I meant” or trying to re-explain. A lot of
> “-1”s are really “I don’t see the usefulness of this”.
>
>
> So I want an open discussion on: How can we communicate clearer?
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

[Robert Vanden Eynde]

I love moredots ❤️

With pip install funcoperators, one can implement the *dotmul* iff dotmul
can be implemented as a function.

L *dotmul* 1

Would work.

Or even a simple tweak to the library would allow L *dot* s to be [x*s for
x in L] and L /dot/ s to be [x/s for x in L]"

I'd implement something like "if left is iterable and right is not, apply
[x*y for x in left] else if both are iterable, apply [x*y for x,y in
zip(left, right)] etc."

Iterble

Disclaimer : I'm the creator of funcoperators

On Fri, 1 Feb 2019, 00:23 Steven D'Aprano  On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas
> wrote:
>
> > I do a lot of numerical programming, and used to use MATLAB and now
> numpy a
> > lot. So I am very used to "vectorization" -- i.e. having operations that
> > work on a whole collection of items at once.
> [...]
> > You can imagine that for more complex expressions the "vectorized"
> approach
> > can make for much clearer and easier to parse code. Also much faster,
> which
> > is what is usually talked about, but I think the readability is the
> bigger
> > deal.
>
> Julia has special "dot" vectorize operator that looks like this:
>
>  L .+ 1   # adds 1 to each item in L
>
>  func.(L)   # calls f on each item in L
>
> https://julialang.org/blog/2017/01/moredots
>
> The beauty of this is that you can apply it to any function or operator
> and the compiler will automatically vectorize it. The function doesn't
> have to be written to specifically support vectorization.
>
>
> > So what does this have to do with the topic at hand?
> >
> > I know that when I'm used to working with numpy and then need to do some
> > string processing or some such, I find myself missing this
> "vectorization"
> > -- if I want to do the same operation on a whole bunch of strings, why
> do I
> > need to write a loop or comprehension or map? that is:
> >
> > [s.lower() for s in a_list_of_strings]
> >
> > rather than:
> >
> > a_list_of_strings.lower()
>
> Using Julia syntax, that might become a_list_of_strings..lower(). If you
> don't like the double dot, perhaps str.lower.(a_list_of_strings) would
> be less ugly.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

> def stringify(*args, *, sep:str=SomeDefault):
>
I meant def stringify(*args, sep:str=SomeDefault)

So an idea would use duck typing to find out if we have 1 iterable or a
multiple stuff :

def stringify(*args, sep:str=SomeDefault, fmt=''):
it = args[0] if len(args) == 1 and hasattr(args[0], '__iter__') else
args
return sep.join(format(x, fmt) for x in it)

But 閭 duck typing is nasty... I don't want that in the stdlib (but in a
pip package, sure!)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

>
> def stringify(self, sep):
>  return sep.join(str(i) for i in self)
>
= map(sep.join(map(str, self))

However some folks want:

def stringify(*args, *, sep:str=SomeDefault):
return sep.join(map(str, args))

In order to have:

>>> stringify(1, 2, "3", sep="-")
1-2-3

And I agree about the formatting, we know that str(x) and format(x) are
synonyms so I'd suggest:

def stringify(*args, *, sep:str=SomeDefault, fmt=''):
return sep.join(format(x, fmt) for x in args)

And the implicit call to str is really not surprising for a function called
stringify IMO

If you want a language designed specifically for text processing, use Perl.
>
True ! However typing python -cp "1+1" is really tempting...

>
Python is deliberately strongly typed, so that:
>
> 2 + “2”
>
> Raises an error. Why should:
>
> “”.join([2, “2”]) not raise an error as well?
>
I agree
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

I love it when the discussion goes fast like here! :D

The messages are short or long-structured-and-explaining, I love it :)

-- Sorry if I may look like a troll sometimes, I truly like the
conversation and I want to share the excitement :)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

On Wed, 30 Jan 2019, 04:46 David Mertz wrote:

Of course not! [...]
>
I agree


> Of course, it also doesn't work on dictionaries. [...]
>
I agree
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

> stringify = lambda it: type(it)(map(str, it))
>

stringify(range(5)) doesn't work ^^

One advantage or having a standard function is that it has been designed by
a lot of persons for all possible use cases :)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

+1

On Wed, 30 Jan 2019, 02:57 David Mertz  "Not every five line function needs to be in the standard library"
>
> ... even more true for every one line function.  I can think of a few
> dozen variations of similar but not quite identical behavior to my little
> stringify() that "could be useful."  Python gives us easy composition to
> create each of them.  It's not PHP, after all.
>
> On Tue, Jan 29, 2019 at 8:52 PM Alex Shafer  wrote:
>
>> That would be strongly preferred to duplication across hundreds of use
>> cases and thousands (millions?) of users. Not all of them are likely to
>> come up with the most efficient implementation either.
>>  Original Message 
>> On Jan 29, 2019, 18:44, David Mertz < me...@gnosis.cx> wrote:
>>
>>
>> stringify = lambda it: type(it)(map(str, it))
>>
>> Done! Does that really need to be in the STDLIB?
>>
>> On Tue, Jan 29, 2019, 7:11 PM Alex Shafer via Python-ideas <
>> python-ideas@python.org wrote:
>>
>>> 1) I'm in favor of adding a stringify method to all collections
>>>
>>> 2) strings are special and worthy of a "special case" because strings
>>> tend to be human readable and are used in all kinds of user interface.
>>>
>>>
>>>
>>>  Original Message 
>>> On Jan 29, 2019, 16:04, Steven D'Aprano < st...@pearwood.info> wrote:
>>>
>>>
>>> On Tue, Jan 29, 2019 at 10:51:26PM +0100, Jamesie Pic wrote:
>>>
>>> > What do you think of list.stringify(delim) ?
>>>
>>> What's so special about lists? What do you think of:
>>>
>>> tuple.stringify
>>> deque.stringify
>>> iterator.stringify
>>> dict.keys.stringify
>>>
>>> etc. And what's so special about strings that lists have to support a
>>> stringify method and not every other type?
>>>
>>> list.floatify
>>> list.intify
>>> list.tuplify
>>> list.setify
>>> list.iteratorify
>>>
>>> Programming languages should be more about composable, re-usable general
>>> purpose components more than special cases.
>>>
>>> --
>>> Steve
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

+1 Good performance analysis IMHO :)

On Tue, 29 Jan 2019, 22:24 Jonathan Fine  I've not been following closely, so please forgive me if I'm repeating
> something already said in this thread.
>
> Summary: str.join allows us to easily avoid, when assembling strings,
> 1. Quadratic running time.
> 2. Redundant trailing comma syntax error.
>
> The inbuilt help(str.join) gives:
> S.join(iterable) -> str
> Return a string which is the concatenation of the strings in the
> iterable.  The separator between elements is S.
>
> This is different from sum in two ways. The first is the separator S.
> The second is performance related. Consider
> s = 0
> for i in range(100):
> s += 1
> and
> s = ''
> for i in range(100):
> s += 'a'
>
> The first has linear running time (in the parameter represented by
> 100). The second has quadratic running time (unless string addition is
> doing something clever, like being lazy in evaluation).
>
> The separator S is important. In Python a redundant trailing comma, like
> so,
> val = [0, 1, 2, 3,]
> is both allowed and useful. (For example, when the entries are each on
> a simple line, it reduces the noise that arises when an entry is added
> at the end. And when the entries are reordered.)
>
> For some languages, the redundant trailing comma is a syntax error. To
> serialise data for such languages, you can do this:
> >>> '[{}]'.format(', '.join(map(str, v)))
> '[0, 1, 2, 3]'
>
> From here, by all means repackage for your own convenience in your own
> library, or use a third party library that already has what you want.
> (A widely used pypi package has, I think, a head start for adoption
> into the standard library.)
>
> By the way, as search for "python strtools" gives me
> https://pypi.org/project/extratools/
> https://www.chuancong.site/extratools/functions/strtools/
>
> https://pypi.org/project/str-tools/. # This seems to be an empty stub.
>
> --
> Jonathan
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

+1 to that email !! (how to do that in email haha)

On Tue, 29 Jan 2019, 21:50 Chris Barker via Python-ideas <
python-ideas@python.org wrote:

> A couple notes:
>
> On Tue, Jan 29, 2019 at 5:31 AM Jamesie Pic  wrote:
>
>> can you clarify the documentation
>> topic you think should be improved or created ? "Assembling strings"
>>
>
> I would think "assembling strings", though there is a lot out there
> already.
>
>
>> or "inconsistencies between os.path.join and str.join" ?
>>
>
> well, if we're talking about moving forward, then the Path object is
> probably the "right" way to join paths anyway :-)
>
> a_path / "a_dir" / "a_filename"
>
> But to the core language issue -- I started using Python with 1.5.* and
> back then join() was in the string module (and is there in 2.7 still)
>
> And yes, I did expect it to be a list method...
>
> Then it was added as a method of the string object.
>
> And I thought THAT was odd -- be really appreciated that I didn't need to
> import a module to do something fundamental.
>
> But the fact is, that joining strings is fundamentally a string operation,
> so it makes sense for it to be there.
>
> In earlier py2, I would have thought, maybe it should be a list method --
> it's pretty darn common to join lists of strings, yes? But what about
> tuples? Python was kind of all about sequences -- so maybe all sequences
> could have that method -- i.e part of the sequence ABC.
>
> But with > py3k, Python is more about iterables than sequences -- and join
> (and many other methods and functions) operate on any iterable -- and this
> is a really good thing.
>
> So add join to ALL iterables? That makes little sense, and really isn't
> possible -- an iterable is something that conforms to the iterator protocol
> -- it's not a type, or even an ABC.
>
> So in the end, join really does only make sense as string method.
>
> Or Maybe as a built in -- but we really don't need any more of those.
>
> If you want to argue that str.join() should take multiple arguments, like
> os.path.join does, then, well we could do that -- it currently takes one
> and only one argument, so it could be extended to join multiple arguments
> -- but I have hardly ever seem a use case for that.
>
> The mistake I'm still doing after 10 years of Python
>>
>
> hmm -- I've seen a lot of newbies struggle with this, but haven't had an
> issue with it for years myself.
>
>
>> >>> '/'.join('some', 'path')
>> TypeError: join() takes exactly one argument (2 given)
>>
>
> pathlib aside, that really isn't the right way to join paths .
> os.path.jon exists for a (good) reasons. One of which is this:
>
> In [22]: os.path.join("this/", "that")
> Out[22]: 'this/that'
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

Oh and if you want to write ['a', 'b', 'c'].join('.')

Check out pip install funcoperators and you can write :

['a', 'b', 'c'] |join('.')

Given you defined the function below :

from funcoperators import postfix
def join(sep):
return postfix(lambda it: sep.join(map(str, it))

You can even choose the operator :

['a', 'b', 'c'] -join('.')
['a', 'b', 'c'] /join('.')
['a', 'b', 'c'] @join('.')
...

Disclaimer : I'm the creator of funcoperators

On Tue, 29 Jan 2019, 02:43 Jamesie Pic  Hello,
>
> During the last 10 years, Python has made steady progress in convenience
> to assemble strings. However, it seems to me that joining is still, when
> possible, the cleanest way to code string assembly.
>
> However, I'm still sometimes confused between the different syntaxes used
> by join methods:
>
> 0. os.path.join takes *args
> 1. str.join takes a list argument, this inconsistence make it easy to
> mistake with the os.path.join signature
>
> Also, I still think that:
>
> '_'.join(['cancel', name])
>
> Would be more readable as such:
>
> ['cancel', name].join('_')
>
> Not only this would fix both of my issues with the current status-quo, but
> this would also be completely backward compatible, and probably not very
> hard to implement: just add a join method to list.
>
> Thanks in advance for your reply
>
> Have a great day
>
> --
> ∞
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

So you'd propose to add some kind of

def Join(sep, *args):
 return sep.join(map(str, args))

To the standard lib ?

Or to add another method to str class that do that ?

class str:
 ...
 def Join(self, *args):
 return self.join(map(str, args))

I agree such a function is super convenient but does it need to be added to
the standard lib I have it in my custom utils.py and my PYTHONTARTUP.py
file so that I can use it everywhere.

Call it Join, superjoin, joinargs...

On Tue, 29 Jan 2019, 02:43 Jamesie Pic  Hello,
>
> During the last 10 years, Python has made steady progress in convenience
> to assemble strings. However, it seems to me that joining is still, when
> possible, the cleanest way to code string assembly.
>
> However, I'm still sometimes confused between the different syntaxes used
> by join methods:
>
> 0. os.path.join takes *args
> 1. str.join takes a list argument, this inconsistence make it easy to
> mistake with the os.path.join signature
>
> Also, I still think that:
>
> '_'.join(['cancel', name])
>
> Would be more readable as such:
>
> ['cancel', name].join('_')
>
> Not only this would fix both of my issues with the current status-quo, but
> this would also be completely backward compatible, and probably not very
> hard to implement: just add a join method to list.
>
> Thanks in advance for your reply
>
> Have a great day
>
> --
> ∞
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Robert Vanden Eynde]

>
>
> Personally what I find is perverse is that .join is a method of
> strings
> but does NOT call str() on the items to be joined.


Yeah, that's a good reason to use .format when you have a fixed number of
arguments.

"{}, {}, {}, {}".format(some, random, stuff, here)

And then there is map.

Otherwise .join is very common on iterables like

'\n'.join(make_string(object) for object in something)

'\n'.join(map(make_string, something))

'\n'.join(map(str, nonstr))

'\n'.join('{}: {}'.format(x, y) for x,y in blabla)

'\n'.join(map('[{}]'.format, stuff))

A "join format" construct is very typical in codes producing strings from
iterable.

I agree on the part "a list doesn't always contain string so why would it
have a join method".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] About the passing the function arguments in Keyword form.

[Robert Vanden Eynde]

It's very important that f(z=5) Raises an exception if z is not an argument.

For your case, I'd do a wrapper, instead lf calling f(z=5) you can call
UniversalCall(f, x=1, y=2, z=5) if you want to specify it on the caller
side.

Or else, you can create a decorator :

@universal_callable
def f(x, y):
...

f(x=1, y=2, z=5)  # works !

On Mon, 24 Dec 2018, 11:21 李默  I am having an idea on loosing the argument validity check when passing
> the function arguments in keyword way.
> For example:
> ---
> def f(x, y):
>
> print(x, y)def call_f():
> f(x=7, y=9, z=9)
>
> call_f()
>
> --
>
> In the current of python, the extra pass of 'z' would let the interpreter 
> raise an exception and stop work.  My idea is that the interpreter need not 
> stop because all the needed args are completely provided.  Of course for this 
> toy example, 'f' can be define as  f(x, y, **kwargs) to achieve the same 
> goal.  However,  essentially it is reasonably to keep interpreter going as 
> long as enough args are passed.  And this modification can bring more freedom 
> of programming.
>
>
> Think about the following situations:
>
> situation 1) there are many 'f's written by other people, and their args are 
> very similar and your job is to run each of them to get some results.
>
> -
>
> ##code by others:
>
> def f0():
>   ...
> def f1(x):
>   ...
> def f2(x, y):
>   ...
> def f3(x, y, z):
>   ...
>
> #if passing extra args are valid, you can run all the functions in the 
> following way, which is very compact and easy to read.
>
> def test_universal_call():
>
>   funcs = [f0, f1, f2, f3]
>   args = {'x':1, 'y':5, 'z':8}
>   for f in funcs:
>   f(**args)
>
> --
>
>
> situation 2) there are several steps for make one product, each step is in an 
> individual function and needs different args.
>
> --
>
> def make_oil(oil):
>   ...
>
> def make_water( water):
>   ...
>
> def make_powder(powder):
>   ...
>
> ## if passing extra args are valid, you can run all the functions in the 
> following way, which is very compact and easy to read.
>
> def dish():
>   procedures = [make_oil, make_water, make_powder]
>
>   args = {'oil' : 1, 'water': 10, 'powder': 4}
>   for f in procedures:
>   f(**args)
>
>
> ---
>
>
> This idea is different from **kwargs. **kwargs are used when user wants to 
> record all the keywords passed. This idea is that even if the user doesn’t 
> want to record the arguments, that extra pass of keyword arguments wont’t 
> cause an exception.
>
>
>
> Sorry for bothering you guys if this is a stupid idea.
>
> Happy to hear your suggestions.
>
>
> Li Mo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Range and slice syntax

[Robert Vanden Eynde]

I'm wondering how your examples would go with from funcoperators import
infix (https://pypi.org/project/funcoperators/)

sum(1:6) # instead of sum(range(1, 6))
>
>
sum(1 /exclusive/ 6)

list(1:6)
>
>
list(1 /exclusive/ 6)
set(1 /exclusive/ 1)

Note that you can pick another name.
Note that you can pick another function :

@infix
def inclusive (a, b):
   return range(a, b+1)

sum(1 /inclusive/ 6)

for i in (1:6):
>
> print(i**2)
>
>
for i in 1 /exclusive/ 6:
print(i**2)

(i**2 for i in (1:6))
>
>
(i ** 2 for i in 1 /exclusive/ 6)

It also makes forming reusable slices clearer and easier:
>
> my_slice = (:6:2) # instead of slice(None, 6, 2)
> my_list[my_slice]
>
>
I don't have exact equivalent here, I would create a function or explicitly
say slice(0, 6, 2)

This is similar to passing a range/slice object into the respective
> constructor:
>
>
> [1:6] # list(1:6) or [1, 2, 3, 4, 5]
> {1:6} # set(1:6) or {1, 2, 3, 4, 5}
>
>
As mentioned before {1:6} is a dict.

Here are a few more examples:
>
>
> for i in (:5): # 5 elements 0 to 4, i.e. range(5)
>
> print(i**2)
>
>
Everybody knows i in range(5).


>  for i in (1:): # counts up from one for as long as you want, i.e. count(1)
>
>
Well, count(1) is nice and people can google it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] dict.setdefault_call(), or API variations thereupon

[Robert Vanden Eynde]

>
> The two are less connected than you seem to think.
>

Really ? What's the use mainstream use cases for setdefault ?
I was often in the case of Alex.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

>
> Does it make sense to draw some sort of parallel between next(myiterator,
> default="whatever") and mylist.pop(default="whatever")? They exhaust the
> iterator/list then start emitting the default argument (if provided).
>

Yep that's what I just did in my previous mail.

"""
I think the same way about set.pop, list.pop.
About .index I agree adding default= would make sense but that's not
exactly the same thing as the others.
"""

Being picky: "TypeError: next() takes no keyword arguments", that's
next(myierator, "whatever") ;)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

>
> There are a number of PEPs in the 8000s that would be worth reading.
>

Will read that *à l'occaz*, closing the disgression now ^^
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

>
> In this case, the governance model for the Python language is being
> discussed.
>

This was the info I was missing, where is it discussed ? Not only on this
list I assume ^^


> Upvotes and downvotes don't mean anything. [...]
>

Yes, that's why random people wouldn't vote.
But like, voting between like the 10 core devs where they all have the same
importance,
that does help for choosing "to merge or not to merge", isn't it ?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

Just English Vocabulary, what do you mean by "being in the air at the
moment" ?
Like, that's a subject that a lot of people in here like to talk ?

Yes, to merge or not to merge, but people can UpVote/DownVote can't they ?
:D

Le ven. 2 nov. 2018 à 01:15, Chris Angelico  a écrit :

> On Fri, Nov 2, 2018 at 11:12 AM Ethan Furman  wrote:
> >
> > On 10/31/2018 02:29 PM, Chris Angelico wrote:
> >
> > > Exactly how a team of core devs can make unified
> > > decisions is a little up in the air at the moment
> >
> > I wouldn't worry too much about it.  I don't think we have ever made
> > entirely unified decisions.
> >
>
> LOL, there is that. But somehow, a single decision has to be made:
> merge or don't merge? And getting a group of people to the point of
> making a single decision is the bit that's up in the air.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Robert Vanden Eynde]

And with libraries like pip install funcoperators or pip install infix, you
can even write it infix :D

from funcoperators import infix
@infix
def superop(d1, sc):
return {k: (v *superopp* sc) for k, v in d1.items()}

print({'a': 8} *superop* 5)


Le mer. 31 oct. 2018 à 18:35, Vladimir Filipović  a
écrit :

> Julien, would I be correct if I summarized the changes you have in
> mind like this:
>
> for dictionaries d1 and d2,
> non-Mapping ("scalar") sc,
> binary operation ⊛,
> and unary operation 퓊 (such as negation or abs()):
>
> d1 ⊛ sc == {k: (v ⊛ sc) for k, v in d1.items()}
> sc ⊛ d1 == {k: (sc ⊛ v) for k, v in d1.items()}
> 퓊(d1) == {k: 퓊(v) for k, v in d1.items()}
> d1 ⊛ d2 == {k: (d1[k] ⊛ d2[k]) for k in d1.keys() & d2.keys()}
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

Oooh, PEP463, you're reason with I switch to LBYL or write studpid try
except functions so much times.

Oh and also the local assignement "let/where/statement" :D

x = (y+1 where y = 3.14) because x = [y+1 for y in [3.14]][0] is an
overkill and ugly.

Should I write a PEP even though I know it's going to be rejected because
the mailing list was not really into it ?

Le mer. 31 oct. 2018 à 18:37, Michael Selik  a écrit :

> On Wed, Oct 31, 2018 at 10:17 AM Eric Fahlgren 
> wrote:
>
>> On Wed, Oct 31, 2018 at 2:42 AM Chris Angelico  wrote:
>>
>>> https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>>>
>>
>> That was exactly my reaction, too, and usually is whenever one of these
>> "add a default" or similar ideas pops up.  463 should be re-examined, I was
>> very hopeful when it went through the wringer the first time, but alas it
>> was not to be.
>>
>
> I'll add my vote to re-examining PEP 463.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

I think the same way about set.pop, list.pop.

About .index I agree adding default= would make sense but that's not
exactly the same thing as the others.

Do we have somewhere else a place where a linear search already accepts a
default= kwarg ?

def index(self, x):
   for i,y in enumerate(self):
   if x == y:
  return i
   raise ValueError

We do have "next", the default version of .index is currently implentable
as :

next((i for i, y in enumerate(self) if x == y), -1)

If I want -1 for default.

Le mer. 31 oct. 2018 à 10:23, Nicolas Rolin  a
écrit :

>
> As a user I always found a bit disurbing that dict pop method have a
> default while list and set doesn't.
> While it is way more computationally easy to check wether a list or a set
> is empty that to check if a key is in a dict, it still create a signature
> difference for no real reason (having a default to a built-in in python is
> pretty standard).
> It would be nice if every built-in/method of built-in type that returns a
> value and raise in some case have access to a default instead of raise, and
> not having to check the doc to see if it supports a default.
>
> We could for exemple ask ourselves wether or not list.index should have a
> default, as it is a method that we explecitely excpect to return a value
> and might just raise instead.
>
> 2018-10-31 2:08 GMT+01:00 Steven D'Aprano :
>
>> On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
>> > 31.10.18 01:44, Giampaolo Rodola' пише:
>> > >Sorry in advance if this has been proposed in the past but I couldn't
>> > >find anything on python-ideas:
>> > >
>> > > >>> l = []
>> > > >>> l.pop(default=1)
>> > >1
>> [...]
>>
>> > It is just
>> >
>> > l.pop() if l else default
>>
>> It might *do* the same thing, but it doesn't communicate the
>> programmer's intention as well.
>>
>> {}.pop('key', default) could be written using LBYL too, but the
>> intention is much clearer given an explicit default argument.
>>
>> The only advantage of the "if l" version is that if the default is
>> expensive to calculate, we can short-circuit it.
>>
>>
>> > or
>> >
>> > (l or [default]).pop()
>>
>> That's clever, but it is also wasteful, building a single-item list only
>> to immediately pop the item out of it and throw the list away.
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "l.pop() if l else None"
>> 1000 loops, best of 3: 0.0739 usec per loop
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "(l or [None]).pop()"
>> 100 loops, best of 3: 0.421 usec per loop
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
>
> --
> *Nicolas Rolin* | Data Scientist
> + 33 631992617 - nicolas.ro...@tiime.fr 
>
>
> *15 rue Auber, **75009 Paris*
> *www.tiime.fr *
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Robert Vanden Eynde]

Julien, your article is very pleasant to read (and funny) but as other say
the mailing list is not there to share some articles, but for proposition
to the standard python library,

do our own lib on github and pypi first if you want to Share some code to
the world !

And if project becomes super useful to everyone one day, it may come one
day to the standard library so that everybody will have it.

Cheers,

Robert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal for an inplace else (?=) operator

[Robert Vanden Eynde]

That's an idea that could be added to my thread "dialects of python" in
order to compile some fancy or specific syntax to regular python.

Le sam. 22 sept. 2018 à 13:53, Lee Braiden  a écrit :

> Could I get some feedback on this?  I'd like to know if anyone thinks it
> might make it through the pep process before spending too much (more) time
> on it.  That said, it seems valuable to me, and I'm willing to put in the
> time, of course, IF it has a chance.
>
> ---
>
> Problem:
>
> Due to (biggest python WTF) (Problem 1), which prevents actual default
> argument values being set in a function signature, many
> functions look like:
>
> > def teleport(from, to, passenger, hitchhiker=None,
> food_accessory=None, comfort_accessory=None):
> > if hitchhiker is None:
> > hitchhiker = Fly()
> >
> > if food_accessory is None:
> > food_accessory = Cheeseburger()
> >
> > if comfort_accessory is None:
> > comfort_accessory = Towel()
> >
> > ...
>
> This None checking and setting is unwieldy (Problem 2) boilerplate,
> which is responsible for many extra lines of code in python
> (Problem 3), and tends to distract from the real code (Problem 4) in a
> function.
>
> To reduce boilerplate, a ternary or binary expression can be used:
>
> > def teleport(from, to, passenger, hitchhiker=None,
> accessories=[]):
> > hitchhiker = hitchhiker if hitchhiker or Fly()
> # Existing Solution A
>
> > def teleport(from, to, passenger, hitchhiker=None,
> accessories=[]):
> >hitchhiker = hitchhiker or Fly()
> # Existing Solution B
>
> These help, but are still quite repetitive:
>
> * Existing Solution A is often avoided simply because many Pythonistas
> dislike tenery expressions (perhaps due to
>   readability or hidden code branch concerns), and can quickly become
> unwieldy when the new value (Fly()) is a more
>   complex expression, such as a list comprehension:
>
> > def teleport(from, to, passenger, hitchhiker=None,
> accessories=[]):
> >hitchhiker = hitchhiker if hitchhiker or filter(lambda h: not
> h.already_hitching(), available_hitchhikers)[0]
>
> * Existing Solution B is less unwieldy (solving Problem 2), yet still
> suffers from repetition (Problems 2, 3, and 4).
>
> In a similar scenario, when we want to populate an empty list (say,
> accesories), we could write:
>
> > accessories |= [Cheeseburger(), Towel()]
>  # Almost-Solution C
>
> However, this is not actually a solution, because:
>
> * The inplace-or (|=) operator is not provided for None in python:
>
>   > food_accessor = None
>   > food_accessory |= Cheeseburger()
>
>   Traceback (most recent call last):
>   File "", line 1, in 
>   TypeError: unsupported operand type(s) for |=: 'NoneType' and
> 'Cheeseburger'
>
>   This could be added, but would not solve the issue, because:
>
> * If an non-default (non-None) argument value WERE provided, we be
> would modifying
>   the argument unintentionally:
>
> > class Larry:
> > def __ior__(self, other):
> > print("{} modified".format(self))
> >
> > teleport(..., hitchhiker=Larry(), ...)
> <__main__.Larry object at 0x7f1ad9828be0> modified
>
> And so Problems 1,2,3, and 4 are compounded.
>
> Proposal:
>
> The addition of a ?= operator could provide an elegant solution:
>
> > def teleport(from, to, hitchiker=None, food_accessory=None,
> comfort_accessory=None):
> > hitchhiker ?= Fly()
> > food_accessory ?= Cheeseburger()
> > comfort_accessory ?= Towel()
>
> In these examples,
>
> > a = None
> > a ?= b
>
> > c = [1, 2]
> > c ?= d
>
> Would be equivalent to (assuming ?= was called __ielse__):
>
> > class ExtendedNone(NoneType)
> > def __ielse__(self, other):
> > return other
> >
> > class ielse_list(list):
> > def __ielse__(self, other):
> > return self
> >
> > None = ExtendedNone()
> >
> > a = None
> > a = a.__ielse__(b)
> >
> > c = iff_list([1, 2])
> > c = a.__ielse__(d)
>
> Although explicitly provided for list above, this ielse operator could
> be defined
> (again, as `return other` for NoneType only, but defaulted to `return
> self` for
> all other values of `a`, requiring very little implementation effort
> or intrusion
> into other types.
>
> Possible interaction with typing
>
> It may be also possible to define a ? suffix on function arguments, so
> that:
>
> > def func(a?):
> > a ?= [1,2]
>
>  greatly shorting the 

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Robert Vanden Eynde]

As said 100 times in the list, email is powerful, configurable but needs a
lot of configuration (especially hard on mobile) and has a lot of rules
(don't top post, reply to the list, don't html, wait, html is alright)
whereas a web based alternative is easier to grasp (more modern) but adds
more abstraction.

I can't find the link we had explaining the difference between those two,
but mailing list is easily searchable and archivable and readable on a
terminal.

However, providing guis to mailing list is a nice in between to have the
better of two worlds.

About moderation, what's the problem on the list ?

Le mar. 18 sept. 2018 à 10:44, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> a écrit :

> Mike Miller writes:
>
>  > A decent mail program can thread discussions and ignore the boring
>  > ones.
>
> +100, but realistically, people aren't going to change their MUAs,
> especially on handhelds.  The advantage of something like Discourse is
> that the server side controls the UX, and that's what people who don't
> want to change MUAs usually want.
>
> IMO the problems of these lists are a scale problem -- too many
> people, too many posts.  As far as I can see, the only way to "fix" it
> is to become less inclusive, at least in terms of numbers.
>
> It's possible that a different technology will allow us to become more
> inclusive in terms of diversity at the same time that we become fewer.
>
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Pattern Matching Syntax (reprise)

[Robert Vanden Eynde]

Needless to say it's interesting to see what others language have (pros and
cons), I'm thinking about Scala for example (but I'm sure perl can show us
a long list of pros and cons).

Le mar. 18 sept. 2018 à 13:38, Tobias Kohn  a écrit :

> Hello Everyone,
>
> Please excuse my being late for properly responding to the last thread on
> "Pattern Matching Syntax" [1].  As Robert Roskam has already pointed out at
> the beginning of that thread, there has been much previous discussion about
> adding pattern matching to Python, and several proposals exist.  It is
> therefore not my intention to propose yet another syntax choice for pattern
> matching, but more to share my experience with implementing it, in the hope
> of making a worthwhile contribution to the overall discussion.
>
> This summer, I basically ended up requiring pattern matching in Python for
> a research project I am working on.  Some initial hacks have then grown
> into a library for pattern matching in Python [2].  On the one hand, my
> design is certainly heavily influence by Scala, with which I also work on a
> regular basis.  On the other hand, I ran into various difficulties,
> challanges, and it has been particularly important to me to find a design
> that blends well with Python, and harnesses what Python already offers.
>
> I have written down my experience in the form of a discussion on several
> options concerning syntax [3], and implementation [4], respectively.  As
> the articles have turned out longer than I originally intended, it might
> take up too much time for those who have little interest in this matter in
> the first place.  However, considering that the subject of pattern matching
> has been coming up rather regularly, my experience might help to contribute
> something to the discussion.  Let me provide a brief summary here:
>
> *1. Pattern Matching is not Switch/Case*
> --
> When I am talking about pattern matching, my goal is to do a deep
> structural comparison, and extract information from an object.  Consider,
> for instance, the problem of optimising the AST of a Python program, and
> eliminate patterns of the form `x + 0`, and `x - 0`.  What pattern matching
> should be offering here is a kind of comparison along the lines of:
> `if node == BinOp(?, (Add() or Sub()), Num(0)): ...`
> Ideally, it should also return the value of what is marked by the question
> mark `?` here, and assign it to a variable `left`, say.  The above
> comparison is often written as something like, e. g.:
> `case BinOp(left, Add()|Sub(), Num(0)): ...`
> This use of `case`, however, is not the same as a switch-statement.
>
> *2. Orthogonality*
> 
> Getting the syntax and semantics of nested blocks right is hard.  Every
> block/suite in Python allows any kind of statements to occur, which allows
> for things like nested functions definitions, or having more than just
> methods in a class.  If we use a two-levelled block-structure, we run into
> the problem of finding good semantics for what the following means (note
> the variable `x` here):
> ```
> match node:
> x = 0
> case BinOp(left, Add(), Num(0)):
> ...
> x += 1
> case BinOp(left, Mul(), Num(1)):
> ...
> ```
> In the case of a "switch block", such additional statements like the
> `x=0`, and `x+=1` can become quite problematic.  On the other hand,
> requiring all statements inside the block to be case-statements violates
> the orthogonality found otherwise in Python.
>
> I feel that this dilemma is one of the core issues why the syntax of
> switch statements, or pattern matching seems so exceptionally hard.  In the
> end, it might therefore, indeed, make more sense to find a structure that
> is more in line with if/elif/else-chains.  This would lead to a form of
> pattern matching with little support for switch-statement, though.
>
> *3. Implementation*
> -
> For the implementation of pattern matching, my package compiles the
> patterns into context-manager-classes, adds these classes in the background
> to the code, and then uses `with`-statements to express the
> `case`-statement.  If have found a neat way to make the execution of a
> `with`-statement's body conditional.
>
> Two things have been curcially important in the overall design: first, the
> "recompilation" cannot change the structure of the original code, or add
> any line.  This way, all error messages, and tooling should work as
> expected; the invasive procedure should be as minimal as possible.  Second,
> it is paramount that the semantics of how Python works is being preserved.
> Even though the actual matching of patterns is done in external classes,
> all names must be resolved "locally" where the original `case`-statement
> lives.  Similarly, the variables defined by the pattern are to local
> variables, which are assigned if, and only if, the pattern actually matches.
>
> Should pattern matching ever be added to Python 

Re: [Python-ideas] Keyword only argument on function call

[Robert Vanden Eynde]

If you want to force using pos args, go ahead and use Python docstring
notation we'd write def quad(a,b,c, /)

The names should not be renamed because they already have a normal ordering
x ** n.

This notation is standard, so it would be a shame to use something people
don't use.

However, I recently used a quad function in one of my uni course where the
different factors are computed with a long expression, so keyword
arguments, so I'd call:

Vout = quad(
a=... Some long expression
spanning a lot of lines ...,
b=... Same thing ...,
c=... Same thing...)

Without the a= reminder, one could count the indentation.

And if you'd think it's a good idea to refactor it like that ...

a = ... Some long expression
spanning a lot of lines ...
b = ... Same thing ...
c = ... Same thing...

Vout = quad(a,b,c)

Then you're in the case of quad(*, a, b, c) (even if here, one would never
def quad(c,b,a)).

Wheter or not this refactor is more clear is a matter of "do you like
functional programming".

However, kwargs arz more useful in context where some parameters are
optional or less frequentely used. But it makes sense (see Pep about
mandatory kwargs).

Kwargs is a wonderful invention in Python (or, lisp).

Le ven. 7 sept. 2018 à 18:54, David Mertz  a écrit :

> Here's a function found online (I'm too lazy to write my own, but it would
> be mostly the same). Tell me how keyword arguments could help this... Or
> WHAT names you'd give.
>
>
>1. def quad(a,b,c):
>2. """solves quadratic equations of the form
>3. aX^2+bX+c, inputs a,b,c,
>4. works for all roots(real or complex)"""
>5. root=b**2-4*a*c
>6. if root <0:
>7. root=abs(complex(root))
>8. j=complex(0,1)
>9. x1=(-b+j+sqrt(root))/2*a
>10. x2=(-b-j+sqrt(root))/2*a
>11. return x1,x2
>12. else:
>13. x1=(-b+sqrt(root))/2*a
>14. x2=(-b-sqrt(root))/2*a
>15. return x1,x2
>
>
> After that, explain why forcing all callers to name their local variables
> a, b, c would be a good thing.
>
> On Fri, Sep 7, 2018, 12:18 PM Robert Vanden Eynde 
> wrote:
>
>>
>>> I disagree.  Keyword arguments are a fine and good thing, but they are
>>> best used for optional arguments IMHO.  Verbosity for the sake of
>>> verbosity is not a good thing.
>>
>>
>> I disagree, when you have more than one parameter it's sometimes
>> complicated to remember the order. Therefore, when you name your args, you
>> have way less probability of passing the wrong variable, even with only one
>> arg.
>>
>> Verbosity adds redundancy, so that both caller and callee are sure they
>> mean the same thing.
>>
>> That's why Java has types everywhere, such that the "declaration part"
>> and the "use" part agree on the same idea (same type).
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Robert Vanden Eynde]

>
>
> I disagree.  Keyword arguments are a fine and good thing, but they are
> best used for optional arguments IMHO.  Verbosity for the sake of
> verbosity is not a good thing.


I disagree, when you have more than one parameter it's sometimes
complicated to remember the order. Therefore, when you name your args, you
have way less probability of passing the wrong variable, even with only one
arg.

Verbosity adds redundancy, so that both caller and callee are sure they
mean the same thing.

That's why Java has types everywhere, such that the "declaration part" and
the "use" part agree on the same idea (same type).
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python dialect that compiles into python

[Robert Vanden Eynde]

Many features on this list propose different syntax to python, producing 
different python "dialects" that can statically be transformed to python :

- a,b += f(x) → _t = f(x); a += _t; b += _t;  (augmented assignement unpacking)
- a = 2x + 1 → a = 2*x + 1  (juxtaposition is product)
- f(*, x, y) → f(x=x, y=y)  (simplekwargs)
- DSL specific language
- all def become @partially def
- etc...

Using a modified version of ast, it is relatively easy to modifiy the syntax 
tree of a program to produce another program. So one could compile the "python 
dialect" into regular python. The last example with partially for example 
doesn't even need new syntax.

Those solutions that are too specific would then be provided as a module on pip 
that has a common interface for "compiling" :

$ cat test.dialect.py
#! dialect: juxtaposition
a = 2x + 1

$ python -m compile test.dialect.py
$ cat test.py
#! compiled with dialect juxtaposition
a = 2x + 1

The generated file should also be read only if the filesystem provides the 
option.

In the web world, it's very common to compile into html, css or js. One of the 
reason was that the web must be vry generic and will not try to fit 
everyone needs.

- less compiles scss into css
- coffeescript into js
- source map provides a standard way to map each line of the new file into 
lines of the old files (useful for exceptions !)

One useful feature of those compilers is the --watch Option that allows to 
avoid to launch the compilation manually.

Of course, in the js world, the syntax was improved in the end after a long 
maturation of the compiling and not compiling libraries.

In the java world, languages such as Scala compile into bytecode, that's 
another idea.

If a standard module like "compile" is written, users can write their own 
module that will automatically be read by "compile" (for example, pip install 
compile_juxtaposition would allow the juxtaposition dialect). Compile doesn't 
even have to be on the standard python, it can be a lib.

One could write a module using multiple dialect like dialect: juxtaposition, 
simplekwargs

The order would be technically important but functionally non important.

Actually, I might start to write this lib, that looks fun.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Robert Vanden Eynde]

I'm trying to see how it can be done with current python.

from somelib import auto

auto(locals(), function, 'a', 'b', 'c', d=5)
auto(locals(), function).call('a', 'b', 'c', d=5)
auto(locals(), function)('a', 'b', 'c', d=5)
auto(locals()).bind(function).call('a', 'b', 'c', d=5)

One of those syntax for a class auto could be chosen but it allows you to
give locals in the call.

However, locals() gives a copy of the variables so it must be given as this
code illustrates :

 def f(x):
  y = x+1
  a = locals()
  g = 4
  print(a)

f(5)  # {'y': 6, 'x': 5}


Le jeu. 6 sept. 2018 à 15:18, Calvin Spealman  a
écrit :

>
>
> On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano 
> wrote:
>
>> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
>>
>> > I have a working implementation for a new syntax which would make
>> > using keyword arguments a lot nicer. Wouldn't it be awesome if instead
>> > of:
>> >
>> >   foo(a=a, b=b, c=c, d=3, e=e)
>> >
>> > we could just write:
>> >
>> >   foo(*, a, b, c, d=3, e)
>> >
>> > and it would mean the exact same thing?
>>
>> No.
>>
>>
>> > This would not just be shorter but would create an incentive for
>> > consistent naming across the code base.
>>
>> You say that as if consistent naming is *in and of itself* a good thing,
>> merely because it is consistent.
>>
>> I'm in favour of consistent naming when it helps the code, when the
>> names are clear and relevant. But why should I feel bad about failing to
>> use the same names as the functions I call? If some library author names
>> the parameter to a function "a", why should I be encouraged to use
>> that same name *just for the sake of consistency*?
>>
>
> I've been asking this same question on the Javascript/ES6 side of my work
> ever since unpacking was introduced there which baked hash-lookup into
> the unpacking at a syntax level.
>
> In that world its impacted this same encouragement of "consistency" between
> local variable names and parameters of called functions and it certainly
> seems
> popular in that ecosystem. The practice still feels weird to me and I'm on
> the fence
> about it.
>
> Although, to be honest, I'm definitely leaning towards the "No, actually,
> it is a
> good thing." I grew up, development-speaking, in the Python world with a
> strong emphasis drilled into me that style constraints make better code and
> maybe this is just an extension of that.
>
> Of course, you might not always want the same name, but it is only
> encouraged
> not required. You can always rename variables.
>
> That said... I'm not actually a fan of the specific suggested syntax:
>
> >  foo(*, a, b, c, d=3, e)
>
> I just wanted to give my two cents on the name consistency issue.
>
>
>
>> > So the idea is to generalize the * keyword only marker from function
>> > to also have the same meaning at the call site: everything after * is
>> > a kwarg. With this feature we can now simplify keyword arguments
>> > making them more readable and concise. (This syntax does not conflict
>> > with existing Python code.)
>>
>> It's certainly more concise, provided those named variables already
>> exist, but how often does that happen? You say 30% in your code base.
>>
>> (By the way, well done for writing an analysis tool! I mean it, I'm not
>> being sarcastic. We should have more of those.)
>>
>> I disagree that f(*, page) is more readable than an explicit named
>> keyword argument f(page=page).
>>
>> My own feeling is that this feature would encourage what I consider a
>> code-smell: function calls requiring large numbers of arguments. Your
>> argument about being concise makes a certain amount of sense if you are
>> frequently making calls like this:
>>
>> # chosing a real function, not a made-up example
>> open(file, mode=mode, buffering=buffering, encoding=encoding,
>>  errors=errors, newline=newline, closefd=closefd, opener=opener)
>>
>> If 30% of your function calls look like that, I consider it a
>> code-smell.
>>
>> The benefit is a lot smaller if your function calls look more like this:
>>
>> open(file, encoding=encoding)
>>
>> and even less here:
>>
>> open(file, 'r', encoding=self.encoding or self.default_encoding,
>>  errors=self.errors or self.default_error_handler)
>>
>> for example. To get benefit from your syntax, I would need to
>> extract out the arguments into temporary variables:
>>
>> encoding = self.encoding or self.default_encoding
>> errors = self.errors or self.default_error_handler
>> open(file, 'r', *, encoding, errors)
>>
>> which completely cancels out the "conciseness" argument.
>>
>> First version, with in-place arguments:
>> 1 statement
>> 2 lines
>> 120 characters including whitespace
>>
>> Second version, with temporary variables:
>> 3 statements
>> 3 lines
>> 138 characters including whitespace
>>
>>
>> However you look at it, it's longer and less concise if you have to
>> create temporary variables to make use of 

Re: [Python-ideas] Add recordlcass to collections module

[Robert Vanden Eynde]

What's the difference between you proposition and dataclasses ? Introduced
in Python 3.7 ?

Le sam. 1 sept. 2018 à 19:33, Jonathan Goble  a écrit :

> On Sat, Sep 1, 2018 at 1:08 PM Angus Hollands  wrote:
>
>> As to the other questions, yes, do we need another module in the standard
>> library?
>>
>
> Wouldn't need a new module. This would be a perfect fit for the existing
> collections module where namedtuple already resides.
>
> I Googled "pypi namedlist", and the top three results were all other
> implementations of named lists or something similar:
> - namedlist , which I have
> personally used and found extremely useful
> - list-property 
> - mutabletuple 
>
> Clearly the concept is useful enough to have several competing
> implementations on PyPI, and to me that is a point in favor of picking an
> implementation and adding it to the stdlib as the one obvious way to do it.
> So +1 from me.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] On evaluating features [was: Unpacking iterables for augmented assignment]

[Robert Vanden Eynde]

>
>
> By the same logic, wouldn't such a naive user also expect:
>
>  a, b, c = 0
>
> to set three variables to 0?
>
>
Let's notice that this syntax is valid:

a = b = c = 0

But for += there is no such direct translation.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

Therefore one can do a decorator that gives .partial:

def partialize(f):
from functools import partial
f.partial = lambda *a, **b: partial(f, *a, **b)
return f

@partialize
def f(x,y):
return x-y

g = f.partial(5)
g(3)

That's the same idea as funcoperators.partially but doesn't return a new
function (which has the advantage of keeping help(f))

Le sam. 11 août 2018 à 14:53, Robert Vanden Eynde  a
écrit :

>
>
> Le sam. 11 août 2018 à 10:34, Vincent Maillol 
> a écrit :
>
>> Hello,
>>
>> Currently the user defined functions are mutables, there can be existed
>> python codes like this:
>>
>> >>> def foo():
>> ... pass
>> ...
>> >>> if not hasattr(foo, 'partial'):
>> ... foo.partial = {}
>> ...
>>
>> Adding a new method to function object can break existing projects, but
>> it is without impact with buit-in functions because they are immutables.
>>
>>
> Or use a decorator like in the lib ?
>
> from funcoperators import partially
>
> @partially
> def f(x, y):
> return x-y
>
> g = f.part(4)
> g(5)
>
> The mutability solution however cannot have a "self" argument :
>
> def f(x,y):
> return x-y
>
> f.stuff = lambda self: self(5, 2)
> f.stuff()  # missing self
>
> One would have to give "f".
>
> f.partial = lambda *a, **b: functools.partial(f, *a, **b)
>
> g = f.partial(4)
> g(5)
>
>
>> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>>
>>> I'd rather have functools.partial() to be added as a new method on
>>> function objects.
>>>
>>> >
>>> > fromfunctools importpartial
>>> >
>>> >
>>> > def add(x:int,y:int)->int:
>>> > returnx +y
>>> >
>>> >
>>> > add_2 = partial(add,2)
>>> >
>>>
>>> Would become:
>>>
>>> add_2 = add.partial(2)
>>>
>>> Nothing to change on the parser, no obscure syntax for future readers,
>>> and we can get the opportunity of rewriting partial() in C as right now
>>> it is amazingly way, way slower than a lambda.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

Le sam. 11 août 2018 à 10:34, Vincent Maillol  a
écrit :

> Hello,
>
> Currently the user defined functions are mutables, there can be existed
> python codes like this:
>
> >>> def foo():
> ... pass
> ...
> >>> if not hasattr(foo, 'partial'):
> ... foo.partial = {}
> ...
>
> Adding a new method to function object can break existing projects, but it
> is without impact with buit-in functions because they are immutables.
>
>
Or use a decorator like in the lib ?

from funcoperators import partially

@partially
def f(x, y):
return x-y

g = f.part(4)
g(5)

The mutability solution however cannot have a "self" argument :

def f(x,y):
return x-y

f.stuff = lambda self: self(5, 2)
f.stuff()  # missing self

One would have to give "f".

f.partial = lambda *a, **b: functools.partial(f, *a, **b)

g = f.partial(4)
g(5)


> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>
>> I'd rather have functools.partial() to be added as a new method on
>> function objects.
>>
>> >
>> > fromfunctools importpartial
>> >
>> >
>> > def add(x:int,y:int)->int:
>> > returnx +y
>> >
>> >
>> > add_2 = partial(add,2)
>> >
>>
>> Would become:
>>
>> add_2 = add.partial(2)
>>
>> Nothing to change on the parser, no obscure syntax for future readers,
>> and we can get the opportunity of rewriting partial() in C as right now
>> it is amazingly way, way slower than a lambda.
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

You can read the other functionalities on the project page :
https://pypi.org/project/funcoperators/

And if you want to solve the "can't partial from right that allows to use
the Ellipsis '...' :

# the built-in "pow" doesn't take keyword arguments, so partial can't be
used.

from funcoperators import elipartial, bracket

square = elipartial (pow, ..., 2)  # = pow(something, 2)

square(3)  # 9

@bracket
def f(x,y,z):
return x - y + 2 * z

r = f(1,2,3)
g = f[1, ..., 3]  # g = a function with one argument: y
r = g(2)

bracket merges the concept of partiallymulti, and elipartial. Partially
Multi allowing to write f[1, 2] as a sugar for f[1][2] (which is different
than partial(f, (1,2)) ).

Le dim. 5 août 2018 à 00:18, Daniel.  a écrit :

> That's an awesome library! Congratulation for doing this and thanks for
> sharing!
>
> Em sáb, 4 de ago de 2018 às 13:42, Robert Vanden Eynde <
> robertv...@gmail.com> escreveu:
>
>> The funcoperators lib on pypi does exactly that:
>>
>> from funcoperators import partially
>>
>> @partially
>> def add(x: int, y: int) -> int:
>> return x + y
>>
>> add_2 = add[2]
>>
>> @partiallymulti
>> def stuff(x,y,z):
>> return x - y + 2*z
>>
>> sort = partially(sorted)
>> sort_by_x = sort.key(key=lambda element: element.x)
>>
>> The ".key" means "give a keyword argument".
>> The ".val" or [] gives a positional argument.
>> The ".part" accept positional and keyword arguments.
>>
>> Le sam. 4 août 2018 à 18:03, Fabrizio Messina  a
>> écrit :
>>
>>>
>>> Hello, I would like to propose a new method to create a partial function.
>>>
>>> At the moment we have to load the *partial* function from the *functool*
>>> library, and apply it to an existing function, e.g.
>>>
>>> from functools import partial
>>>
>>>
>>> def add(x: int, y: int) -> int:
>>> return x + y
>>>
>>>
>>> add_2 = partial(add, 2)
>>>
>>>
>>>
>>> While partial expose the mechanism excellently its instantiation method
>>> is, at times, not very friendly, I would like to propose a syntactic sugar
>>> to create partial functions, in the case you create a partial function
>>> using *curly braces*:
>>>
>>>
>>> def add(x: int, y: int) -> int:
>>> return x + y
>>>
>>> add_2 = add{2}
>>>
>>>
>>> At the moment this causes SyntaxError so the change is retro-compatible.
>>>
>>> In the case of key word arguments we could have:
>>>
>>> sort_by_x = sort{key=lambda element: element.x}
>>>
>>>
>>> That could be good as it would be an easy way to pre-load functions
>>> without having to eagerly compute it, but without needing to pass the
>>> entire function parameters to to other scopes.
>>>
>>>
>>> # prepare the function
>>> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
>>> user: user.creation_date}
>>>
>>> # continue with job at hand
>>> ...
>>>
>>> # some where else, maybe another process
>>> sorted_users = list(get_sorted_users())
>>>
>>>
>>>
>>> Even create a factory method on the fly:
>>> @dataclass
>>> class Product:
>>> name: str
>>> category: Category
>>> price: Decimal
>>>
>>>
>>> smartphone_factory = Product{category=smartphone_category}
>>>
>>>
>>>
>>> Now all this can already be done with partial, but adding this syntactic
>>> sugar would reduce the perception of `partial` as an advanced feature,
>>> alleviating the use of closures created only for the sake of avoiding an
>>> explicit partial.
>>>
>>> In my opinion this syntactic sugar has a lot of potential adoption seen
>>> the general interest in functional programming.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

> @partiallymulti
> def stuff(x,y,z):
> return x - y + 2*z
>

f = stuff[1,2]
f(4)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

The funcoperators lib on pypi does exactly that:

from funcoperators import partially

@partially
def add(x: int, y: int) -> int:
return x + y

add_2 = add[2]

@partiallymulti
def stuff(x,y,z):
return x - y + 2*z

sort = partially(sorted)
sort_by_x = sort.key(key=lambda element: element.x)

The ".key" means "give a keyword argument".
The ".val" or [] gives a positional argument.
The ".part" accept positional and keyword arguments.

Le sam. 4 août 2018 à 18:03, Fabrizio Messina  a
écrit :

>
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment we have to load the *partial* function from the *functool*
> library, and apply it to an existing function, e.g.
>
> from functools import partial
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
>
> add_2 = partial(add, 2)
>
>
>
> While partial expose the mechanism excellently its instantiation method
> is, at times, not very friendly, I would like to propose a syntactic sugar
> to create partial functions, in the case you create a partial function
> using *curly braces*:
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add{2}
>
>
> At the moment this causes SyntaxError so the change is retro-compatible.
>
> In the case of key word arguments we could have:
>
> sort_by_x = sort{key=lambda element: element.x}
>
>
> That could be good as it would be an easy way to pre-load functions
> without having to eagerly compute it, but without needing to pass the
> entire function parameters to to other scopes.
>
>
> # prepare the function
> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
> user: user.creation_date}
>
> # continue with job at hand
> ...
>
> # some where else, maybe another process
> sorted_users = list(get_sorted_users())
>
>
>
> Even create a factory method on the fly:
> @dataclass
> class Product:
> name: str
> category: Category
> price: Decimal
>
>
> smartphone_factory = Product{category=smartphone_category}
>
>
>
> Now all this can already be done with partial, but adding this syntactic
> sugar would reduce the perception of `partial` as an advanced feature,
> alleviating the use of closures created only for the sake of avoiding an
> explicit partial.
>
> In my opinion this syntactic sugar has a lot of potential adoption seen
> the general interest in functional programming.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] With expressions

[Robert Vanden Eynde]

>
>
>
>
> A with-statement is great for when you care about the
> implementation details. Somebody has to care about the process of
> opening a file, reading from it and closing it. But when you *don't*
> care about those implementation details, a simple interface like a
> read() function is superior to a with-statement, *or* a with-expression,
> which shoves those details in your face.
>

Totally agree. In the case where you care about the implementation details.
You can explain to a beginner:

something = (f.read() with open('...') as f)

Is another way to write:

with open('filename') as f:
something = f.read()

Exactly like the ternary if.

And I agree that because with is often relevant for "implementation
details" or beginning use as a "enter.. exit' statement (like a cpp
destructor), it matches more imperative programming.

with stack.push_matrix(Scale(4)):
triangle = draw_triangle_using(stack)

Is used for it's "enter/close" functionality, but can still be used like:

triangle = (draw_triangle_using(stack) with stack.push_matrix(Scale(4)) as
NotUsed)

But the "as close" is useless here.


>
> > and in most cases when
> > reading the code you then have to look at the function to see if
> > anything else is done there.
>
> I doubt that many people really spend a lot of time digging into
> functions to see whether they do more than what they say. Unless and
> until I ran into unexpected problems, I'd be no more inclined to look
> into a function called "read" than I would be to do the same to len or
> math.sin. I'm sure it does what it says it does.
>

Fair point, the "def" statements generally are passed when read so they
don't really count as overhead.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] With expressions

[Robert Vanden Eynde]

> I know what functional programming is. What I don't understand is what
> you mean when you say that the F.P. community "seems to be more
> interested in python". Surely they are more interested in functional
> languages than a multi-paradigm language like Python which does not
> privilege functional idioms over imperative idioms.
>
>
Just a personal feeling, it's not really thought out.

> > try...except exceptions have been proposed before and rejected.
> >
> > I'm wondering why, that must have been the same reasons of not accepting
> > "with".
>
> Read the PEP. Or the (long!) discussions on Python-Ideas and Python-Dev.
>
> https://www.python.org/dev/peps/pep-0463/
>
> >


I'm reading it. The prelude at the beginning then says there are no
convincing use case if I get it right?


>
> Which is why I said it was not a good example. If you're going to
> propose syntax, you ought to give good examples, not bad examples.
>

When showing toy examples I thought some people would think "indeed, that
happens to me often".


> In any case, this is not a proposal for a "where" expression. You aren't
> going to convince people to add a "with" expression by showing them
> expression forms of "if", "for" or hypothetical "where". Each feature
> must justify itself, not sneak in behind another feature.
>

Indeed, I'm talking about it because I think it all relates to
"expressionalize simple statements", that's also why I speak about FP,
because that's an "expression-first" paradigm.


>
> Or factor your code into named functions with isolated namespaces, so
> the f in one function doesn't clobber the f in another function.
> Structured programming won the debate against unstructured programming a
> long time ago.
>
> https://en.wikipedia.org/wiki/Structured_programming#History
>
>
> [...]


Of course I would do that, i completely agree that refactoring is useful,
but as shown in the end of my post:

filename = compute_filename(...)
lines = compute_lines(...)
parsed_data = compute_parsed_data(...)

The functions body being a bit too small to be refactored and doesn't
really have another meaning of "code to compute filename", I feel like the
"filename =" already catches the idea, I feel like repeating myself (DRY).

And the function body in those cases is not very reusable so it doesn't
make sense to give it a meaningful name.

I would do a named function otherwise indeed.


> > One difficultly of finding use cases, it that it's about changing the
> > paradigm, probably all cases have a really readable implementation in
> > current python / imperative style. But when I see:
> >
> > try:
> > a_variable = int(input("..."))
> > except ValueError:
> > try:
> >a_variable = fetch_db()
> > except DbError:
> >a_variable = default
> >
> > I really think "why can't I put it one one line like I do with if".
> >
> > a_variable = (int(input("...")) except ValueError:
> >fetch_db() except DbError:
> >default)
>
> Whereas when I see somebody using a double if...else expression in a
> single line, I wish they would spread it out over multiple lines so it
> is readable and understandable, instead of trying to squeeze the maximum
> amount of code per line they can.
>

Multiline is clearly better yes. When I say 'one line' I'm just saying
"using the expression-statement but probably gonna span it on multiple
lines because the Expressions are not short.


>
> > For "with", I'm just wondering "why do I have to indent, it will lose the
> > focus of the reader on the result itself".
>
> If this is a problem, then you can easily focus the reader on the
> result by factoring the code into a named function.
>
> text = read('filename')
>
> requires no indentation, no complicated new syntax, and it is easily
> extensible to more complex examples:
>
> text = (prefix + (read('filename') or 'default') + moretext).upper()
>
> This argument isn't about whether it might occasionally be useful to use
> a with expression, but whether it is useful *enough* to justify adding
> new syntax to the language.
>

For 'with', as you all say, it really boils down to finding use cases other
than "file manipulation". It's true I can't think of any (expect the fact
it does create a function that may not have a meaningful name).


>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] With expressions

[Robert Vanden Eynde]

>
> Expressionization may break the "one and only on obvious way" guideline,
> but it can offer concise, readable code in a lot of instances where a
> statement-based version would be clumsy and noisy, and there's already some
> precedent for it:
>
> function declaration => lambda
> for-loops => generator expressions and comprehensions
> if-else => ternary statements
>

Totally agree. That's the problem when being multi paradigm, but we already
have that "problem" and that's alright.


> With the exception of lambda, expressionized statements usually allow one
> to put the "meat before the vegetables" so to speak. That is; the highest
> value part of the expression comes first and all the book-keeping follows
>

As the code I showed, being just that:

filename = ...
lines = ...
parsed_data = ...

With implementation details? The highest value is there, the alg is clear.,
one fetches the filename, one preprocess the lines, then parse the data.



> One tactic that other expressionizations have taken is to limit the scope.
> For instance, the ternary operation only covers expressionization of
> "if-else" not "just if" or "if-elif-..." or "if-elif-...-else", and
> generator expressions don't allow the 'else' clause
>  of normal
> for-loops. So maybe you can obviate some of the edge cases by requiring an
> as clause or something. I don't know how that would help with the
> suppress(AttributeError) case thought...
>

About if elif elif else, ternary if does have that:

y = (x+1 if x < 0 else
   x-1 if x > 0 else
   0)

Limiting the scope is interesting, for "with" the only limitation in that
the body must have exactly one assignment, like in the ternary if case?

a = ([l.strip() for l in f.readlines()] with open ('name') as f)

By cutting the edge cases, "with something():" is not possible, only "with
... as" being possible?

But the "scope limitation" for try except in expression concept would be
not to have "else" or "finally"? The else and finally clauses do not make
sense in Expression style assignment anyway.

a = (int('stuff') except ValueError: 5)


> On Fri, Aug 3, 2018 at 12:56 PM, Todd  wrote:
>
>> On Thu, Aug 2, 2018 at 5:35 AM, Ken Hilton  wrote:
>>
>>> Hi, I don't know if someone has already suggested this before, but here
>>> goes:
>>>
>>> With expressions allow using the enter/exit semantics of the with
>>> statement inside an expression context. Examples:
>>>
>>> contents = f.read() with open('file') as f #the most obvious one
>>> multiplecontents = [f.read() with open(name) as f for name in names]
>>> #reading multiple files
>>>
>>> I don't know if it's worth making the "as NAME" part of the with
>>> mandatory in an expression - is this a valid use case?
>>>
>>> data = database.selectrows() with threadlock
>>>
>>> Where this would benefit: I think the major use case is `f.read() with
>>> open('file') as f`. Previous documentation has suggested
>>> `open('file').read()` and rely on garbage collection; as the disadvantages
>>> of that became obvious, it transitioned to a method that couldn't be done
>>> in an expression:
>>>
>>> with open('file') as f:
>>> contents = f.read()
>>>
>>> Therefore `f.read() with open('file') as f`, I think, would be much
>>> welcomed as the best way to read a file in an expression.
>>>
>>> For those wondering about the scope semantics of the "as NAME", I think
>>> they would be identical to the scope semantics of the "for" expression -
>>> i.e. these are legal:
>>>
>>> contents = f.read() with open('file') as f
>>> grid = [[i] * 4 for i in range(4)]
>>>
>>> But these are not:
>>>
>>> contents = f.read() with open('file') as f
>>> f.seek(0)
>>> grid = [[i] * 4 for i in range(4)]
>>> grid[i][i] = 4
>>>
>>> Is this a good idea? Are there some subtleties I've failed to explain?
>>> Please let me know.
>>>
>>> Sharing,
>>> Ken Hilton
>>>
>>>
>> If this is a common enough operation for you, it would be trivially easy
>> to just write a function that does this.  There is already a module on pypi
>> that has this function: read_and_close.
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] With expressions

[Robert Vanden Eynde]

Thanks for answering each line. If someone wants "too long didn't read",
just check my code at the paragraph "readlines is a toy example, but maybe
the code would be more creative".

Le ven. 3 août 2018 à 03:07, Steven D'Aprano  a écrit :

> On Thu, Aug 02, 2018 at 03:13:25PM +0200, Robert Vanden Eynde wrote:
>
> > This brings the discussion of variable assignement in Expression.
> Functional
> > programming community seems to be more interested in python.
>
> I'm not sure what you mean there. Your English grammar is just slightly
> off, enough to make your meaning unclear,

sorry.
>

When I say "functional programming", I speak about the paradigm used in
language like Haskell. In language like those, all constructs are
"expression-based". I consider the code "result = 5 if condition else 2"
more "functional style" than "if condition: result = 5; else: result = 2".
Functional style focus on the result, uses expressions. Imperative focus on
the process, "we must do a condition, then we set the variable, else, we
set a variable to something else".


>
> > lines = (f.readlines() with open('hello') as f)
>
> readlines has the same problems as read, as I described earlier, and the
> same trivial three-line solution.
>
>
> > digit = (int('hello') except ValueError: 5)
>
> try...except exceptions have been proposed before and rejected.
>

I'm wondering why, that must have been the same reasons of not accepting
"with".

if condition:
something = x
else:
something = y

Can be refactored

something = x if condition else y

Or

something = (x if condition else
y)

But,

try:
something = x
except:
something = y

Can't?

The use cases seems similar.

One can use the first form, using more of a imperative programming, or the
second line, which is more "functional programming", more expressions
oriented.


>
> > value = (x+y**2 where x,y = (2,4))
>
> A "where" *statement* is interesting, but this is not a good example of
> it. The above is better written in the normal syntax:
>
> value = 2 + 4**2


That's the discussion we had on the list called "variable assignement in
expressions". What you did here is inlining the variables, technically it's
not possible if you're calling a function and using the variable more than
once.

So we're really comparing it to :

x,y = (2,4)
value = x+y**2

Or

x = 2
y = 4
value = x+y**2

Where the idea is to separate the steps of a computation, introducing
temporary variables with a meaningful name is useful (And as mentioned, if
a function is called and the variable reused, it's called once, but that's
not the main point).

In Haskell there is "value = (x = 2 in y = 4 in x+y**2)" or similar.

position = initial + speed * time
position_inch = distance / 2.54

Vs

position_inch = (initial + speed * time) / 2.54

The programmer chooses what's more clear given the context and the audience.

Or maybe he wants to emphasize that the code creates a position_inch
variable usable in the code after ?

Or both, he wants to explain how he computes position_inch using a
temporary variable but doesn't want the rest of the code depend o
"position" ?).

Yes the del is generally useless, more about  leaking below.


> no need to introduce temporary variables that exist only to obfuscate
> the code.
>
>
> > values = [x+y**2 for x in range(5) for y in range(7)]
> > values = [x+y**2 for x,y in product (range(5), range(7))]
> > y = 5 if condition else 2
>
> These already exist, because they are useful.
>

I see those as a refactoring of imperative programming style as well
(values = []; for ...: values.append(...))

>
> > y = (lambda x: x+2)(x=5)
>
> This is not a good example of the use of a lambda. Better:
>
> y = 5 + 2
>

Same thing as in the where syntax. However, some constructs are easier to
refactor as

def meaningfulname(x):
 return x+2

y = meaningfulname(5)


> Why bother writing a function with such a simple body if you are going
> to immediately call it on the spot? Unless the body is more complex, or
> you are going to call it elsewhere, or call it repeatedly, the lambda
> adds nothing.
>

Indeed, in complex expressions.

Or if I want to separate the steps of a computation.

position = initial + speed * time
position_inch = distance / 2.54


> Nobody denies that *some* statements are well-suited and useful as
> expressions. The question is whether "with" is one of those.
>

I'm just pointing out those constructs are very similar, it kind of makes
sense to compare them.

Of course I don't know about real world examples that would simplify a
code. But often as I'm a "expression first" guy

I write:

resu

Re: [Python-ideas] With expressions

[Robert Vanden Eynde]

This brings the discussion of variable assignement in Expression. Functional
programming community seems to be more interested in python.

lines = (f.readlines() with open('hello') as f)
digit = (int('hello') except ValueError: 5)
value = (x+y**2 where x,y = (2,4))
values = [x+y**2 for x in range(5) for y in range(7)]
values = [x+y**2 for x,y in product (range(5), range(7))]
y = 5 if condition else 2
y = (lambda x: x+2)(x=5)

vs

with open('hello') as f:
lines = f.readlines()
del f  # f is leaked !

x,y = 2,4
value = x+y**2
del x, y  # x,y are leaked !

try:
digit = (int('hello')
except ValueError:
digit = 5

if condition:
y = 5
else:
y = 2

def f(x):
return x+2
y = f(x=2)
del f  # we want an anonymous function !

Those "oneliners" is not only the will to be quicker in interactive mode,
it's the way functional programming Thinks.

If we add one, it's Logical to add the others to be consistent.

Of course, one can always write functions like read_text but the ide of
those construction is like the lambda, we want anonymous.

Le jeu. 2 août 2018 à 13:56, Steven D'Aprano  a écrit :

> On Thu, Aug 02, 2018 at 11:35:11AM +0200, Ken Hilton wrote:
>
> > Where this would benefit: I think the major use case is `f.read() with
> > open('file') as f`.
> [...]
> > Therefore `f.read() with open('file') as f`, I think, would be much
> > welcomed as the best way to read a file in an expression.
>
> Perhaps so, but do we want to encourage that to the point of adding
> syntax to make it easier?
>
> f.read() is a (mild) code-smell. Unless your file is guaranteed to be
> smaller than the amount of free memory, it risks starting your OS
> thrashing. IMO that makes this an idiom only suitable for quick and
> dirty scripts where the the user knows the limitations of the script and
> can abide by them.
>
> (In these days of computers with multiple gigabytes of RAM, reading in
> an entire file is not as risky as it used to be. But on the other hand,
> in these days of terrabyte and even petabyte storage devices, there are
> more *really large* files too.)
>
> Don't get me wrong -- f.read() is not necessarily bad. I often write
> scripts that slurp in an entire file at once, but they're typically
> throw-away scripts, and I'm also the user of the script and I know not
> to call it on files above a certain size. (As Miss Piggy once said,
> "Never eat more in one sitting than you can lift.")
>
> But I'm not sure if this sort of thing is something we want to
> *encourage* rather than merely *allow*. Best practice for reading files
> is, after all, a with statement for a reason: we expect to read text
> files line by line, often wrapped in a try...except to handle
> exceptions.
>
> For your use-case, I suspect the best thing is a utility function:
>
> def read(name, size=-1, **kwargs):
> with open(name, **kwargs) as f:
> return f.read(size)
>
> Not every three-line function needs to be a built-in, let alone
> given syntax :-)
>
>
> > For those wondering about the scope semantics of the "as NAME", I think
> > they would be identical to the scope semantics of the "for" expression
>
> Its not really a "for expression" -- its a *comprehension*, which is
> much more than merely a for expression:
>
> # this isn't legal
> result = for x in seq
>
> One important difference is that unlike this proposed "with" expression,
> comprehensions have an obvious pair of delimiters which enclose the
> expression and give it a natural beginning and end. There's no need to
> memorise arcane operator precedences and parsing rules to work out where
> the "with...as" variable will be legal.
>
> Another important difference is that while there are good reasons for
> putting comprehension loop variables in their own sub-local scope, I
> don't see any such benefit to doing the same for this proposed with
> expression. I don't think we should encourage the proliferation of more
> and more layers of extra scopes. We already have six:
>
> sublocal (comprehensions)
> local
> nonlocal (enclosing functions)
> class
> global (module)
> builtins
>
>
> Let's be cautious about adding more varieties of sublocal scope.
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Robert Vanden Eynde]

Shortcuts designed for CLI are just to "be more mnemonic" have to be considered 
with caution.
If gettext is a package, it means the whole python community shoud agree on 
that.
msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long 
lasting command. Or it could be 'python -m gettest msgfmt'.
If you're using CLI, 90% of chances you know that if you don't like "python -m 
gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m 
gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans 
Something".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Robert Vanden Eynde]

Shortcuts designed for CLI are just to "be more mnemonic" have to be considered 
with caution.
If gettext is a package, it means the whole python community shoud agree on 
that.
msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long 
lasting command. Or it could be 'python -m gettest msgfmt'.
If you're using CLI, 90% of chances you know that if you don't like "python -m 
gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m 
gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans 
Something".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: Deferred Default Arguments?

[Robert Vanden Eynde]

> Someone wrote :
> Thank you for your deferred default values idea, which we're now
working on together.
>
https://github.com/petered/peters_example_code/blob/master/peters_example_code/deferral.py

Allowing to write:

from deferral import deferrable_args, deferred
@deferrable_args
def f(x, y=2, z=3):
return (x,y,z)

f(5, deferred, 7) == (5,2,7)

(I'd rename "deferrable_args" to simply "deferrable")

The api chosen in deferall.py is a deferall.deferred, one could also use
None or Ellipsis ? That looks nice :

from deferral import elideferrable
@elideferrable
def f(x, y=2, z=3):
return (x,y,z)

f(5, ..., 7) == (5, 2, 7)

from deferral import nonedeferrable
@nonedeferrable
def f(x, y=2, z=3):
return (x,y,z)

f(5, None, 7) == (5, 2, 7)

Le mar. 24 juil. 2018 à 14:26, Kyle Lahnakoski  a
écrit :

>
> I agree this is a problem, which I have seen solved by removing the
> method signature, which is unfortunate:
>
> > def flexible_method(**kwargs):
> > # Read the code to find out the expected parameters
>
> I have an @override decorator to handle this type of pattern. It will
> perform the null-coalescing with properties found in a special "kwargs"
> parameter. "kwargs" is assigned a dict that has a copy of the method
> arguments. The value of a callee's argument is, in order,
>
> * a not None value provided by the caller or
> * a not None value found in the kwargs dict or
> * the default value provided by the method declaration or
> * None
>
> I was not clear on where you wanted to define your defaults.  Either
> like this:
>
> > @override
> > def subfunction_1(a=None, b=None, c=None, kwargs=None):
> > return a+b*c
> >
> > @override
> > def subfunction_2(d=None, e=None, f=None, kwargs=None):
> > return d*e+f
> >
> > @orverride
> > def main_function(a=2, b=3, c=4, d=5, e=6, f=7, kwargs=None):
> > return subfunction_1(a, b, c) + subfunction_2(d, e, f)
> > return subfunction_1(kwargs) + subfunction_2(kwargs)  # IF YOU
> WANT TO BE LAZY
>
> or like this:
>
> > @override
> > def subfunction_1(a=2, b=3, c=4, kwargs=None):
> > return a+b*c
> >
> > @override
> > def subfunction_2(d=5, e=6, f=7, kwargs=None):
> > return d*e+f
> >
> > @orverride
> > def main_function(a=None, b=None, c=None, d=None, e=None, f=None,
> kwargs=None):
> > return subfunction_1(a, b, c) + subfunction_2(d, e, f)
> > return subfunction_1(kwargs) + subfunction_2(kwargs)  # IF YOU
> WANT TO BE LAZY
>
> both are identical except for where you declare the default values.
>
>
> https://github.com/klahnakoski/mo-kwargs
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Can we add "zip and assert equal length" to the standard library?

[Robert Vanden Eynde]

This is a functionality I sometimes need.

Maybe you can do a pull request to more-itertools and that would be the end
of it? I don't know if that's general enough for being added to the
standard library, more-itertools seems the way to go for me. Go find out if
raising a ValueError suits their Api (at least one of their function,
"first" does it).

The David's comment makes senses, what happens when you pass an infinite
iterable, will it be consumed half? That seems logical.

from itertools import count
it = count(0)
try:
   L = zip_equal(range(5), it)
except ValueError:
   print(next(it)) # prints 6 but I'd expect 5

However, maybe that's irrelevant because most of the time you don't care
about the iterable when the exception is raised.

Le sam. 28 juil. 2018 à 01:54, David Mertz  a écrit :

> I have never wanted this behavior myself.  So that's 0% of the time for
> me.  I happily believe that Peter O'Connor wants it 90% of the time...
> although I guess it suggests he probably organizes his algorithms
> differently than I do at some broader level.  For my needs, zip() is
> common, and itertools.zip_longest() is somewhat uncommon, but not unheard
> of.
>
> I do note that https://more-itertools.readthedocs.io also does not have
> this zip_equal() functionality. At least I don't see it (I could have
> missed it under a different name, but I looked around). This is pretty
> clearly the most widely used "extra stuff that might go in itertools"
> library.
>
> I think part of the problem is that raising an exception when something is
> exhausted (other than StopIteration) is contrary to the spirit of itertools
> (or more_itertools).  I think part of the reason those iterator functions
> do not do that is that an exception often indicates "something went wrong,"
> but if this problem occurs after an indefinitely long iteration that is
> later than you'd like to know.
>
> A more common pattern, in my experience would be to put an exception in
> the higher-up block where an iterator is consumed.  Various "things went
> wrong" conditions can be checked, not exclusively that one iterator ran out
> before the other.
>
> On Fri, Jul 27, 2018 at 1:03 PM Peter O'Connor 
> wrote:
>
>> I find that about 90% of the time I want want to zip iterators together,
>> I expect them to be the same length and want to throw an exception if they
>> aren't.  Yet there is not currently a solution for this in the standard
>> library for this, and as a result I always have to take this function
>> everywhere I go:
>>
>>
>> def zip_equal(*iterables):
>> """
>> Zip and raise exception if lengths are not equal.
>>
>> Taken from solution by Martijn Pieters, here:
>>
>> http://stackoverflow.com/questions/32954486/zip-iterators-asserting-for-equal-length-in-python
>>
>> :param iterables: Iterable objects
>> :return: A new iterator outputting tuples where one element comes
>> from each iterable
>> """
>> sentinel = object()
>> for combo in zip_longest(*iterables, fillvalue=sentinel):
>> if any(sentinel is c for c in combo):
>> raise ValueError('Iterables have different lengths.
>> Iterable(s) #{} (of 0..{}) ran out first.'.format([i for i, c in
>> enumerate(combo) if c is sentinel], len(combo)-1))
>> yield combo
>>
>> Would anybody object to adding this to the standard library for Python
>> 3.8?
>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Change repr of collections.OrderedDict to be more dict-like

[Robert Vanden Eynde]

Sorry Steven I didn't see your clever dict.__repr__ solution that Chris
pointed out too. That's what I was looking for ^^

And now for pprint, apparently that doesn't seem difficult to implement.

About the part where "the representation looses the type information",
pformat(od) could be "OrderedDict{1:2, 3,4}" or "OrderedDict({1:2, 3:4})"
but I don't ask for repr or pprint to change, just curious about how to
implement that.



Le ven. 27 juil. 2018 à 11:53, Chris Angelico  a écrit :

> On Fri, Jul 27, 2018 at 7:45 PM, Thomas Jollans  wrote:
> > On 27/07/18 08:06, Robert Vanden Eynde wrote:
> >
> > Thanks for your response, I want to print/repr an OrderedDict() without
> > relying on the fact that "dict are ordered" ie. I want a solution <
> python
> > 3.7.
> > Currently, if I do repr( OrderedDict([(1,2),(3,4)]) ), I get the string
> > "OrderedDict([(1,2),(3,4)])", I'd like a function that would return the
> > string "{1: 2, 3: 4}" in the correct order.
> > If I do repr(dict( OrderedDict([(1,2),(3,4)]) )) I get "{1: 2, 3: 4}"
> > because dict are ordered since python 3.7.
> > And for pprint, currently pformat( OrderedDict([(1,2),(3,4)]) ) gives the
> > string 'OrderedDict([(1, 2), (3, 4)])' (and adds \n for bigger dict).
> > I could do pprint(dict( OrderedDict([(1,2),(3,4)]) )) but again that
> relies
> > on python 3.7 behavior.
> > I'm wondering if there exists an easy way to code this "order preserving
> > repr and pprint/pformat".
> >
> >
> > It's a fairly non-standard thing to do as you're not representing the
> > ordered dict itself, but it's easy enough...
> >
> >>>> od = OrderedDict([('a', 1), ('b', 2)])
> >>>> '{%s}' % ', '.join('{!r}: {!r}'.format(k, v) for (k, v) in
> od.items())
> > "{'a': 1, 'b': 2}"
> >>>>
> >
> > It's a bit more work if you want pretty-printing.
> >
> > And there's always json.
>
> >>> from collections import OrderedDict
> >>> od = OrderedDict([('a', 1), ('b', 2)])
> >>> dict.__repr__(od)
> "{'a': 1, 'b': 2}"
>
> :)
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Change repr of collections.OrderedDict to be more dict-like

[Robert Vanden Eynde]

Thanks for your response, I want to print/repr an OrderedDict() without relying 
on the fact that "dict are ordered" ie. I want a solution < python 3.7.
Currently, if I do repr( OrderedDict([(1,2),(3,4)]) ), I get the string 
"OrderedDict([(1,2),(3,4)])", I'd like a function that would return the string 
"{1: 2, 3: 4}" in the correct order.
If I do repr(dict( OrderedDict([(1,2),(3,4)]) )) I get "{1: 2, 3: 4}" because 
dict are ordered since python 3.7.
And for pprint, currently pformat( OrderedDict([(1,2),(3,4)]) ) gives the 
string 'OrderedDict([(1, 2), (3, 4)])' (and adds \n for bigger dict).
I could do pprint(dict( OrderedDict([(1,2),(3,4)]) )) but again that relies on 
python 3.7 behavior.
I'm wondering if there exists an easy way to code this "order preserving repr 
and pprint/pformat".

Le ven. 27 juil. 2018 à 07:58, Steven D'Aprano 
mailto:st...@pearwood.info>> a écrit :
On Fri, Jul 27, 2018 at 05:30:35AM +, Robert Vanden Eynde wrote:

> Currently, what's the best way to implement a function
> f(OrderedDict([(1,2),(3,4)])) == '{1: 2, 3: 4}', works for all
> possible types, and also availaible for pprint with nice indent?

I don't understand the question, and I especially don't understand the
"all possible types" part. Do you actually mean *all* possible types,
like int, float, str, MyClassThatDoesSomethingWeird?

But guessing (possibly incorrectly) what you want:

py> from collections import OrderedDict
py> od = OrderedDict([(1,2),(3,4)])
py> od == {1:2, 3: 4}
True

If efficiency is no concern, then the simplest way to get something that
has a dict repr from an OrderedDict is to use a dict:

py> dict(od)
{1: 2, 3: 4}

This also works as OrderedDict is a subclass of dict, and should avoid
the cost of building an entire dict:

py> dict.__repr__(od)
'{1: 2, 3: 4}'


> If I
> could set a parameter in ipython or python repl that would print that,
> that would already be very useful.

See sys.displayhook.



--
Steve
___
Python-ideas mailing list
Python-ideas@python.org<mailto:Python-ideas@python.org>
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Change repr of collections.OrderedDict to be more dict-like

[Robert Vanden Eynde]

Currently, what's the best way to implement a function 
f(OrderedDict([(1,2),(3,4)])) == '{1: 2, 3: 4}', works for all possible types, 
and also availaible for pprint with nice indent?
If I could set a parameter in ipython or python repl that would print that, 
that would already be very useful.

Le ven. 27 juil. 2018 à 07:23, Steven D'Aprano 
mailto:st...@pearwood.info>> a écrit :
On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
> I often use doctests to verify APIs and behaviors when I update code. I
> know I'm in a minority and most developers slightly disparage doctests.

I don't know why you think that "most developers" disparage doctests.
Perhaps they're the same ones who think that "read the source" is all
the documentation anyone needs.

I know I don't. I love them. Tim Peters loves them (he should, he wrote
the module) and if its good enough for Uncle Timmy then anyone who
disparages them better have a damn good reason.

Doc tests aren't perfect, but they fill a very important niche which is
otherwise badly neglected by developers.

I think we'd need to ask on Python-Dev to be sure, but my understanding
is that backwards compatibility guarantees for reprs are weaker than
those for regular APIs but stronger than those for error messages.

Earlier, Michael Selik mailto:m...@selik.org>> wrote:

> > Given the way different Python prompts feel free to change reprs, I always
> > understood the repr to have no compatibility guarantees.

That doesn't follow. The Python language makes no guarantees about
how applications can display objects to the user, and a REPL is just
another application. I suppose there might be an implied expectation
that the official REPL that comes with the standard interpreter probably
shouldn't make too many changes to the way things are displayed, but
that's as far as it goes.

[Michael (I think)]
> > Breaking doctests is somewhat annoying, but I understand that to be more
> > about verifying the accuracy of documentation than verifying the
> > correctness of code.

Breaking doctests is more than "somewhat annoying", and you seem to have
missed the point that the way we verify the accuracy of documentation is
by verifying the correctness of code.

> > It's handy for following TDD, but that's during the
> > initial development and a changed repr won't interfere.

I don't understand the reasoning here. Surely doctests are *less*
valuable during initial development, when function APIs are in rapid
change. (On the other hand, I use doctests to nail down what API I
want, before I have an implementation.)

Unless you delete all your documentation or stop running doctests when
the project reaches the first stable version, I don't understand why you
think that changing reprs won't interfere.



--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] As-do statements/anonymous blocks in python

[Robert Vanden Eynde]

> lumberjack(15, %)
> # is equivalent to the expression
> lambda x: lumberjack(15, %)

You mean lambda x: lumberjack(15, x) ?

So you'd want a better syntax for functools.partial, here your example is
partial(lumberjack, 15).

However this syntax you allow to write lumberjack(%, 15) which is only
possible with partial using keyword arguments, like lumberjack (y=15)
(given that the second argument is called "y") and in that case I know at
least one library on pip doing the job with Ellipsis :

from funcoperators import elipartial
elipartial(lumberjack, ..., 15)
# gives lambda x: lumberjack (x, 15)

elipartial (lumberjack, ..., 15, ..., 12, ...)
# gives lambda x, y, z: lumberjack(x, 15, y, 12, z)

And the lib even provide a decorator to have that kind of syntax using "[" :

partially(lumberjack)[15]
would be the same as partial(lumberjack, 15)

So, that functionality does really need new syntax.


Le jeu. 26 juil. 2018 à 14:07, Michel Desmoulin 
a écrit :

> I like the concept, and I several times wished I could have had a
> reference to the block of code in a `with` clause.
>
> However, it is unlikely to happen:
>
> 1 - Guido restricted lambda to one expression, and this would just be a
> way around that
>
> 2 - This will be tempting to use for callbacks and chaining things,
> leading to the nesting hell we tried very carefully to avoid fom other
> languages. The example for sorted is also kinda twisted.
>
> 3 - Most of the example (and you show it yourself with flask) are
> already possible with a more verbose syntaxe based on decorators. Example:
>
>
> @atexit.register
> def _():
> print('Goodbye')
>
> 4 - introducing a new keyword is the hardest thing you can ever ask on
> this list.
>
>
>
> Le 25/07/2018 à 19:07, James Lu a écrit :
> > I'm open to any changes or criticism.
> >
> > ```
> > import atexit
> > as atexit.register:
> > # ...do various cleanup tasks...
> > print('Goodbye')
> >
> > # is approximately equivalent to =>
> > import atexit
> > def _():
> > # ...do various cleanup tasks...
> > print('Goodbye')
> > atexit.register(_)
> >
> > # flask example
> > @app.route("/")
> > def hello():
> > return "Hello World!"
> > # is approximately equivalent to =>
> > as app.route('/'):
> > return "Hello World!"
> >
> > @app.route('/user/')
> > def show_user_profile(username):
> > # show the user profile for that user
> > return 'User %s' % username
> >
> > as app.route('/user/') do username:
> > return "Hello World!"
> >
> > def print_sorted(iterable, block):
> > sorted(iterable, )
> >
> > l = [1, 2, 3, 4, 'spam']
> >
> > as l.sort(key=%) do obj:
> > return str(obj)
> >
> > # multiple arguments
> > as spam do a, b:
> > ...
> > ```
> > ## `%`  function call syntax
> > Calling a function with a single percent in place of an argument creates
> > a new function.
> >
> > ```
> > lumberjack(15, %)
> > # is equivalent to the expression
> > lambda x: lumberjack(15, %)
> > ```
> > Using `*` instead of `%` could also be possible.
> >
> > ```
> > import threading, time
> > def interval(seconds, block):
> > def target():
> > while True:
> > time.sleep(seconds)
> > if block():  # stop looping if block returns True
> > break
> > threading.Thread(target=target).start()
> >
> > as interval(5, %):
> >print("chirp")
> > # => chirp every 5 seconds on a seperate thread
> > as threading.Timer(5, %):
> >print("hi")
> > # => say "hi" in 5 seconds
> > ```
> >
> > ## `^` currying function definition syntax?
> > I'm not sure this is necessary or a good idea.
> > ```
> > def interval(seconds, ^block):
> > def target():
> > while True:
> > time.sleep(seconds)
> > if block():  # stop looping if block returns True
> > break
> > threading.Thread(target=target).start()
> > # is aprroximately equivalent to
> > def interval(seconds, block=None):
> > def inner(block):
> > def target():
> > while True:
> > time.sleep(seconds)
> > if block():
> > break
> > threading.Thread(target=target).start()
> > if block == None:
> > def outer(block):
> > return inner(block)
> > else:
> > return inner(block)
> >
> > as interval(5):
> > print('chirp')
> > # equivalent to
> > interval(5)(lambda: print('chirp'))
> > ```
> > ### Lazy evaluation of chained `%` calls?
> > This would allow things like:
> > ```
> > start_on_new_thread = threading.Thread(target=%).start()
> > def bong():
> > while True:
> > time.sleep(6*60)
> > print('BONG')
> > start_on_new_thread(bong)
> > # alternatively
> > as start_on_new_thread:
> > while True:
> > time.sleep(6*60)
> > print('BONG')
> > ```
> >
> > ## As-do statements in classes
> > ```
> > class M():
> >  def __init__(self):
> >  self.time = 5
> >  as 

Re: [Python-ideas] A better (simpler) approach to PEP 505

[Robert Vanden Eynde]

The default could be at the end with an argument to unboxing :

favorite = NoneAware(cfg).user.profile.food.unbox("Spam")


Le lun. 23 juil. 2018 à 17:26, Paul Moore  a écrit :

> On 23 July 2018 at 16:12, David Mertz  wrote:
> > The need addressed by PEP 505 is real; it's also MUCH more niche and
> > uncommon than something that would merit new syntax.  Moreover, the
> actual
> > legitimate purpose served by the PEP 505 syntax is easily served by
> existing
> > Python simply by using a wrapper class.
> >
> > Here is a way of solving the "deep attribute access to messy data"
> problem
> > that is:
> >
> > (1) Much more explicit
> > (2) Requires no change in syntax
> > (3) Will not be a bug magnet
> > (4) Inasmuch as there are semantic traps, they are announced by the use
> of a
> > class whose documentation would be pointed to for readers
>
> [...]
>
> > I haven't implemented the equivalent dictionary lookups in the below.
> That
> > would be straightforward, and I'm sure my 5 minute throwaway code could
> be
> > improved in other ways also.  But something better than this in the
> standard
> > library would address ALL the actual needs described in PEP 505.  Even
> the
> > pattern Steve Dower is especially fond of like:
> >
> > favorite = cfg?.user?.profile?.food ?? "Spam"
> >
> >
> > (i.e. a configuration may be incomplete at any level, if levels are
> missing
> > default favorite food is Spam).  We could simply spell that:
> >
> > favorite = NoneAware(cfg, "Spam").user.profile.food.unbox()
>
> Thank you. That's the sort of "what would this look like if
> implemented as a library rather than language syntax" solution that I
> had in mind with my earlier post.
>
> I would be very interested to hear discussion of the pros and cons of
> adding new syntax to the language as per PEP 505 in comparison to a
> solution like this (ultimately more fleshed out and "production
> quality") rather than comparisons PEP 505 to raw "roll your own"
> Python code.
>
> For me:
>
> * Library solution works with all versions of Python
> * The need for unbox is a little ugly, but arguably less so than ?.
> (conceded that's a subjective view)
> * Mixing ?. and . is terser than unboxing and reboxing - but are there
> any real examples where that's needed?
> * Having the default at the beginning rather than at the end doesn't
> follow natural reading order (but again that's pretty subjective)
>
> There's little here that isn't subjective, so I expect a lot of heated
> debate that ultimately convinces no-one. But the "you can use this
> solution now" aspect of the library solution seems pretty compelling
> to me - at least in terms of "let's publish the library solution and
> then based on experience with it, review PEP 505".
>
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

[Robert Vanden Eynde]

If we're about to use a new keyword, it could be infix too:

a = b ifnone c

Although the assignment version looks unusual:

b ifnone= c

Then with the "default b = c" would look like this:

ifnone b = c

Le jeu. 19 juil. 2018 à 15:30, Calvin Spealman  a
écrit :

> Operators that only vary by case would be... confusing. I'm not super keen
> on the other syntax (either the ?? or .? operators) but I do think they
> read well in C# where they come from. Different things work in different
> languages, some times.
>
> What about a new keyword: default
>
> So you'd write the above examples like this:
>
> default hi = len(a)  # Only executes the assignment if the left-hand is
> None
> default encoding = sys.getdefaultencoding()
>
> On Thu, Jul 19, 2018 at 9:06 AM, Pål Grønås Drange 
> wrote:
>
>> > I've started a subthread, just to discuss the ?= and ?? operators. And
>> > something newish, that I call OR.
>>
>> I would think `||` would be much better.
>>
>> It could be a kind of "semantic or" which could use the aforementioned
>> dunder has_value.
>>
>> -1, though, but to the general None-awareness.
>>
>> Pål
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

[Robert Vanden Eynde]

 > I like your alias(...) function, with that one, an application
 > could code my function like try name(x) expect
 > alias(x).abbreviations[0]. If the abbreviation list is sorted by
 > AdditionToUnicodeDate.

I don't understand why that's particularly useful, especially in the
Han case (see below).

Since python 3.3 has the NameAliases.txt builtin in the distribution in order 
to full fil \N{} construct, I think it would be nice to have an api to access 
this files, to do like unicodedata.alias('\n').abbreviations[:3] == ['LF', 
'NL', 'EOL']


I don't understand what you're asking for.  The Unicode Standard
already provides canonical names.

Not for control characters.

About the Han case, they all have a unicodedata.name 
don't they ? (Sorry if I misread your message)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add the imath module

[Robert Vanden Eynde]

About the name, why not intmath ?
And why not using sage ?
Or create a package on pypi ?

Le jeu. 12 juil. 2018 à 15:11, Serhiy Storchaka  a
écrit :

> 12.07.18 14:55, Serhiy Storchaka пише:
> > What are your thoughts about adding a new imath module for integer
> > mathematics? It could contain the following functions:
>
> I forgot yet one useful function:
>
> def divide_and_round(a, b):
>  q, r = divmod(a, b)
>  r *= 2
>  greater_than_half = r > b if b > 0 else r < b
>  if greater_than_half or r == b and q % 2 == 1:
>  q += 1
>  return q
>
> (This is a copy of the implementation from datetime.py, there are yet
> few implementations in Python and C in other files.)
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

[Robert Vanden Eynde]

I like your alias(...) function, with that one, an application could code my 
function like try name(x) expect alias(x).abbreviations[0]. If the abbreviation 
list is sorted by AdditionToUnicodeDate.

Or

try:
return name(x)
expect:
 if category(x) == 'Cc':
return alias(x).abbreviations[0]
else:
raise

That would then raise only for unassigned codepoints.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

[Robert Vanden Eynde]

Yes, my gmail client transformed unicodata . name to a url. I hope the mobile 
gmail client won't do it here.

Yes current version is 11. I noticed it after sending the mail, I've compared 
to the version 6 and all my arguments are still valid (they just added some 
characters in the "correction" set).

As I'm at, I mentionned the ffef character but we don't care about it because 
it already has a name, so that's mostly a control character issue.

Yes a new function name is also what I prefer but I thought it would clutter 
the unicodata namespace.

I like your alias(...) function, with that one, an application could code my 
function like try name(x) expect alias(x).abbreviations[0]. If the abbreviation 
list is sorted by AdditionToUnicodeDate.

However, having a standard canonical name for all character in the stdlib would 
help people choosing the same convention. A new function like "canonical_name" 
or a shorter name would be an idea.

Instead of name(char, abbreviation=True, correction=False) I would have 
Imagined a "default_behavior" ala csv.dialect such that name(char, 
default_bevior=unicodata.first_abbreviation) would use my algorithm. 
first_abbreviation would be a enum, or like in csv.dialect a class like : class 
first_abbreviation: abbreviation = True; correction = False; ...

But I guess that's too specific, abbreviation=True would mean "take the first 
abbreviation in the list".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

[Robert Vanden Eynde]

unicodedata.name raises KeyError for a few unicode 
characters like '\0' or '\n', altough the documentation is very clear on the 
implementation, this is often not what people want, ie. a string describing the 
character.

In Python 3.3, the name aliases became accepted in unicodedata.lookup('NULL') 
and '\N{NULL}' == '\N{NUL}'.

One could expect that lookup(name(x)) == x for all unicode character but this 
property doesn't hold because of the few characters that do not have a name 
(mainly control characters).

The use case where the KeyError is raised when a codepoint for a unused 
character or newest version of unicode is however still useful.

In the NameAliases https://www.unicode.org/Public/6.3.0/ucd/NameAliases.txt one 
can see that some characters have multiple aliases, so there are multiple ways 
to map a character to a name.

I propose adding a keyword argument, to 
unicodedata.name that would implement one of some 
useful behavior when the value does not exist. In that case.

One simple behavior would be to chose the name in the "abbreviation" list. 
Currently all characters except three only have one and only one abbreviation 
so that would be a good pick, so I'd imagine name('\x00', abbreviation=True) == 
'NUL'

The three characters in NameAlias.txt that have more than one abbreviation are :

'\n' with  ['LF', 'NL', 'EOL']
'\t' with ['HT', 'TAB']
'\ufeff' with ['BOM', 'ZWNBSP']

In case multiple abbreviations exist, one could take the first introduced to 
unicode (for backward compability with python versions). If this is a tie, one 
could take the first in the list. If it has no name and no abbreviation, 
unicodata.name raises an error or returns default as 
usual.

lookup(name(x)) == x for all x is natural isn't it ?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

[Robert Vanden Eynde]

{1,2,7}.freeze() or {1,2,7}.to_frozenset() seem very natural and if this can be 
optimized to avoid the copy, it's perfect.
For bytearray, one use case would be to optimise bytearray([1,2,7,2]) in 
something like [1,2,7,2].to_byterray().
About bytes, one could have (1,2,7,2).to_bytes() instead of bytes((1,2,7,2)) 
because b'\x01\x02\x07\x02' is long and boring.
What about variables in the values {1,2,x}.freeze() should work too ?
bytes((1,2,7,x)) is not writable as a b string and creates a copy.


Le jeu. 12 juil. 2018 à 02:24, Chris Angelico 
mailto:ros...@gmail.com>> a écrit :
On Thu, Jul 12, 2018 at 10:13 AM, Gregory P. Smith 
mailto:g...@krypto.org>> wrote:
>
> On Wed, Jul 11, 2018 at 4:45 PM Jelle Zijlstra 
> mailto:jelle.zijls...@gmail.com>>
> wrote:
>> This could be done safely and without too much craziness if .freeze() on a
>> set returned a new frozenset. The compiler could then safely optimize {a,
>> set, literal}.freeze() into a frozenset literal, because methods on builtin
>> types cannot be monkeypatched. There's been talk of a similar optimization
>> on calls to .format() on string literals (not sure whether it's been
>> implemented).
>>
>> Whether implementing that is a good use of anyone's time is a different
>> question.
>
>
> Neat optimization.  I hadn't considered that.  We do know for sure it is a
> builtin type at that point.
>
> If that were implemented, bytes objects could gain a to_bytearray() (along
> the lines of the int.to_bytes() API) method that could be optimized away in
> literal circumstances.

Be careful: a bytearray is mutable, so this isn't open to very many
optimizations. A .freeze() method on sets would allow a set display to
become a frozenset "literal", stored as a constant on the
corresponding function object, the way a tuple is; but that's safe
because the frozenset doesn't need to concern itself with identity,
only value. Example:

def f(x):
a = (1, 2, 3) # can be optimized
b = (x, 4, 5) # cannot
c = [6, 7, 8] # cannot

Disassemble this or look at f.__code__.co_consts and you'll see (1, 2,
3) as a single constant; but the others have to be built.

+1 on set.freeze(); +0 on bytes.to_bytearray().

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

[Robert Vanden Eynde]

I completely get your pain, the Copy seems like a waste of ressource.
However I think making an optimisation on the C-Level is better than 
introducing the litteral, because Python is a general purpose langauge and most 
of the appplication don't need frozenset or bytearrays and that would clutter 
the base elements one must know and introduce questions on beginners.

So yes, I'm +1 on your (a) solution if it is completely a C-Level optimisation. 
Your (c) solution is an idea. Again, C-Level optimisation, because 
usuability-wise, what's wrong with a copy of a hash table ?

The problem with the f{} syntax is that the letters come from nowhere, 
frozenset{'hello', 'world'} would be a better syntax but it looks like "{} is a 
slicing operator like frozenset[''hello', 'world'] would call 
frozetset.__getitem__( ('hello', 'world') ).

Le jeu. 12 juil. 2018 à 01:26, Gregory P. Smith 
mailto:g...@krypto.org>> a écrit :
Completely obvious what it does, but it irritates my aesthetic sensibilities 
every time I see:
  frozenset({spam, eggs})

Why? Because I assume under the hood that creates a set of spam and eggs before 
calling frozenset to copy it into a new frozenset object before the original 
set is garbage collected.  Wasteful.  This is in fact what happens in CPython 
3.7 today.

I'd love to avoid this.  I have no rational measured reason to believe it even 
matters (thus seeding this on python-ideas and not elsewhere), even though it 
would technically speed up frozenset creation.

(a) detecting frozenset({}) as syntax to encode a frozenset in the python 
bytecode would be somewhat magical.  it could break the person unfortunate 
enough to monkeypatch out the frozenset builtin (really? don't do that!).

(b) abusing the concept of letter prefixes as we already have for strings on {} 
syntax would be possible but not at all obvious to a reader:

  f{} or c{} or r{} perhaps.  but then someone would want a frozendict.

(c) adding a .freeze() method to sets which would raise an exception if the 
set's refcount were > 1 and would mutate the type of the set object into a 
frozenset object in place.  refcount assertions are bad, not all VMs need 
refcounts.  The concept of a method that can mutate the type of the underlying 
object in place is... unpythonic.  even though technically possible to 
implement within CPython.

I'm -1 on all of my ideas above.  But figured I'd toss them out there as food 
for thought for the concept.

We lived for years without even having a set literal in the first place. So 
this isn't a big deal.

frozenset is not the only base type that lacks a literals leading to loading 
values into these types involving creation of an intermediate throwaway object: 
bytearray.  bytearray(b'short lived bytes object')

I was going to suggest complex was in this boat as well, but upon investigation 
we appear to do constant folding (or amazing parsingon that so 0.3+0.6j does 
turn into a single LOAD_CONST instead of two consts and an addition.  Nice!  
Not that I expect practical code to use complex numbers.

-gps
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] datetime.timedelta literals

[Robert Vanden Eynde]

I found it fun to be able to write minutes(50) alongside with 50 * minutes so I 
did that :

from datetime import date, time, datetime, timedelta

class CallableTimedelta(timedelta):
def __call__(self, x):
return self * x

seconds, milliseconds, microseconds, days, hours, minutes, weeks = 
(CallableTimedelta(**{x:1}) for x in ('seconds', 'milliseconds', 
'microseconds', 'days', 'hours', 'minutes', 'weeks'))

print(minutes(50) / seconds) # 3000.0
print(50 * minutes / seconds) # 3000.0
print(minutes(50).total_seconds()) # 3000.0




2018-06-07 13:34 GMT+02:00 Pål Grønås Drange 
mailto:paal.dra...@gmail.com>>:

For closure, I've added a package, timeliterals

(env) [pgdr@hostname ~]$ pip install timeliterals
(env) [pgdr@hostname ~]$ python
>>> from timeliterals import *
>>> 3*hours
datetime.timedelta(0, 10800)
>>> 3*minutes
datetime.timedelta(0, 180)
>>> 3*seconds
datetime.timedelta(0, 3)

The source code is at https://github.com/pgdr/timeliterals

I'm not going to submit a patch to datetime at this time, but I will if people
would be interested.

- Pål

On 5 Jun 2018 13:56, "Jacco van Dorp" 
mailto:j.van.d...@deonet.nl>> wrote:
i'd also be pretty simple to implement

Just list:
minute = timedelta(minutes=1)
hour = timedelta(hours=1)
etc...

and you could import and use them like that. Or if you really want to
write 5*m, the just from datetime import minute as m
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Alternative spelling for list.append()

[Robert Vanden Eynde]

I understand the view from the poster, most basic list operations are using 
brackets, ie reading and writing with [], delete with del L[], why not append ?
And being used extensively, that brackets are annoying.
And yes, += [] is more "concise" than .append() so some people would think it's 
more clear because "it's smaller" (they'd be wrong as the OP mentioned).

But it would break the "There is only one Obvious way to do it" principle.
People would take time to figure out "okay, what should I write ? What's the 
most Pythonic ?"

If someone wants to use their own list class, it's doable with the current 
syntax :

class List(list):
def __lshift__(self, x):
self.append(x)
return self

a = List([1,2,7,2])
a = a << 1 << 5
a <<= 0

2018-06-18 1:36 GMT+02:00 Clint Hepner 
mailto:clint.hep...@gmail.com>>:


> On Jun 17, 2018, at 4:18 PM, Chris Angelico 
> mailto:ros...@gmail.com>> wrote:
>
>> On Mon, Jun 18, 2018 at 3:01 AM, Mikhail V 
>> mailto:mikhail...@gmail.com>> wrote:
>> The idea is to introduce new syntax for the list.append() method.
>>
>>
>> Syntax:
>>
>> Variant 1.
>> Use special case of index, namely omitted index:
>>
>>mylist[] = item
>
> Creation of syntax cannot be done for just one type.

That’s false. @ was added solely for matrix multiplication.

>
> Regardless, I am still a strong -1 on introducing another way to spell
> list.append().

-1 as well. Has any one but the proposer shown any support for it yet?

—
Clint

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Alternative spelling for list.append()

[Robert Vanden Eynde]

Some api (in c++ at least) use "<<" for appending.

A = [1,2,7,2]
A <<= 5
A == [1,2,7,2,5]

The A[] = syntax has it's benefits being used in php (and I think some
other lang).

Le dim. 17 juin 2018 à 19:12, Michael Selik  a écrit :

> On Sun, Jun 17, 2018, 10:01 AM Mikhail V  wrote:
>
>> The idea is to introduce new syntax for the list.append() method.
>>
>
> While you have summarized your proposal, you haven't included a summary of
> the criticism.
>
> Also, one thing that's very common for proposals to change syntax and
> create new uses for operators is to show real code from major libraries
> that benefit from the change.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Robert Vanden Eynde]

Then of you also want 45, you could do % 15 ? :D

Le mer. 13 juin 2018 à 12:07, Stephan Houben  a
écrit :

> 2018-06-13 12:00 GMT+02:00 Robert Vanden Eynde :
>
>> What was wrong with my initial implementation with a lookup table ? :D
>>
>> def sind(x):
>> if x % 90 == 0:
>> return (0, 1, 0, -1)[int(x // 90) % 4]
>> else:
>> return sin(radians(x))
>>
>
> I kinda missed it, but now you ask:
>
> 1. It's better to reduce the angle while still in degrees since one of the
> advantages
>of degrees is that the reduction can be done exactly. Converting very
> large angles
>first to radians and then taking the sine can introduce a large error,
>
> 2. I used fmod instead of % on advice in this thread.
>
> 3. I also wanted to special case, 30, 45, and 60.
>
>
>>
>> If you want to support multiples of 30, you can do % 30 and // 30.
>>
>
> Sure, but I also wanted to special-case 45.
>
> Stephan
>
>
>>
>> Le mer. 13 juin 2018 à 09:51, Stephan Houben  a
>> écrit :
>>
>>> Op di 12 jun. 2018 12:41 schreef Nathaniel Smith :
>>>
>>>> On Tue, Jun 12, 2018, 00:03 Stephan Houben 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I wrote a possible implementation of sindg:
>>>>>
>>>>> https://gist.github.com/stephanh42/336d54a53b31104b97e46156c7deacdd
>>>>>
>>>>> This code first reduces the angle to the [0,90] interval.
>>>>> After doing so, it can be observed that the simple implementation
>>>>>   math.sin(math.radians(angle))
>>>>> produces exact results for 0 and 90, and a result already rounded to
>>>>> nearest for
>>>>> 60.
>>>>>
>>>>
>>>> You observed this on your system, but math.sin uses the platform libm,
>>>> which might do different things on other people's systems.
>>>>
>>>
>>>
>>> Ok, I updated the code to treat all the values 0, 30, 45, 60 and 90
>>> specially.
>>>
>>> Stephan
>>>
>>>
>>>>
>>>>> For 30 and 45, this simple implementation is one ulp too low.
>>>>> So I special-case those to return the correct/correctly-rounded value
>>>>> instead.
>>>>> Note that this does not affect monotonicity around those values.
>>>>>
>>>>
>>>> Again, monotonicity is preserved on your system, but it might not be on
>>>> others. It's not clear that this matters, but then it's not clear that any
>>>> of this matters...
>>>>
>>>> -n
>>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Robert Vanden Eynde]

What was wrong with my initial implementation with a lookup table ? :D

def sind(x):
if x % 90 == 0:
return (0, 1, 0, -1)[int(x // 90) % 4]
else:
return sin(radians(x))

If you want to support multiples of 30, you can do % 30 and // 30.

Le mer. 13 juin 2018 à 09:51, Stephan Houben  a
écrit :

> Op di 12 jun. 2018 12:41 schreef Nathaniel Smith :
>
>> On Tue, Jun 12, 2018, 00:03 Stephan Houben  wrote:
>>
>>> Hi all,
>>>
>>> I wrote a possible implementation of sindg:
>>>
>>> https://gist.github.com/stephanh42/336d54a53b31104b97e46156c7deacdd
>>>
>>> This code first reduces the angle to the [0,90] interval.
>>> After doing so, it can be observed that the simple implementation
>>>   math.sin(math.radians(angle))
>>> produces exact results for 0 and 90, and a result already rounded to
>>> nearest for
>>> 60.
>>>
>>
>> You observed this on your system, but math.sin uses the platform libm,
>> which might do different things on other people's systems.
>>
>
>
> Ok, I updated the code to treat all the values 0, 30, 45, 60 and 90
> specially.
>
> Stephan
>
>
>>
>>> For 30 and 45, this simple implementation is one ulp too low.
>>> So I special-case those to return the correct/correctly-rounded value
>>> instead.
>>> Note that this does not affect monotonicity around those values.
>>>
>>
>> Again, monotonicity is preserved on your system, but it might not be on
>> others. It's not clear that this matters, but then it's not clear that any
>> of this matters...
>>
>> -n
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Robert Vanden Eynde]

As mentioned, with complex numbers the radians make more sense and of course 
cmath.sind(x) + 1j * cmath.sind(x) != cmath.exp(1j * x).

However, adding degrees version for cmath (import cmath) is still useful, 
cmath.rectd, cmath.phased, cmath.polard etc.

2018-06-11 19:24 GMT+02:00 Michael Selik 
mailto:m...@selik.org>>:
Would sind and cosd make Euler's formula work correctly?

sind(x) + i * sind(x) == math.e ** (i * x)

I suspect that adding these functions is kind of like those cartoons where the 
boat is springing leaks and the character tried to plug them with their 
fingers. Floating point is a leaky abstraction.

Perhaps you'd prefer an enhancement to the fractions module that provides real 
(not float) math?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Trigonometry in degrees

[Robert Vanden Eynde]

I agree that a big python library is more close to the standard python lib than 
matlab. However, helping transition from matlab is a great concern in the 
python scientific community, because matlab is used is a lot of engineering 
classes at University.

That's a tough call hmmm.

I'll look at the implementation of scipy.special.sindg and friends to see 
if/how they have optimisations for exact values.


Le dim. 10 juin 2018 à 16:44, Stephan Houben 
mailto:stephan...@gmail.com>> a écrit :
2018-06-09 8:18 GMT+02:00 Robert Vanden Eynde 
mailto:robertvandeney...@hotmail.com>>:
For the naming convention, scipy using sindg (therefore Nor sind nor sindeg) 
will make the sind choice less obvious. However if Matlab and Julia chooses 
sind that's a good path to go, Matlab is pretty popular, as other pointed out, 
with Universities giving "free" licences and stuff. With that regards, scipy 
wanting to "be a replacement to Matlab in python and open source" it's 
interesting they chose sindg and not the Matlab name sind.


I would suggest that compatibility with a major Python library such as SciPy is 
more important than compatibility
with other programming languages.

I would go even further and argue that scipy.special.sindg and its friends 
cosdg and tandg
can serve as the reference implementation for this proposal.

Stephan



For the "d" as suffix that would mean "d" as "double" like in opengl. Well, 
let's remember that in Python there's only One floating type, that's a double, 
and it's called float... So python programmers will not think "sind means it 
uses a python float and not a python float32 that C99 sinf would". Python 
programmers would be like "sin takes float in radians, sind takes float in 
degrees or int, because int can be converted to float when there's no overflow".

Le sam. 9 juin 2018 à 04:09, Wes Turner 
mailto:wes.tur...@gmail.com>> a écrit :
# Python, NumPy, SymPy, mpmath, sage trigonometric functions
https://en.wikipedia.org/wiki/Trigonometric_functions

## Python math module
https://docs.python.org/3/library/math.html#trigonometric-functions
- degrees(radians): Float degrees
- radians(degrees): Float degrees

## NumPy
https://docs.scipy.org/doc/numpy/reference/routines.math.html#trigonometric-functions
- degrees(radians) : List[float] degrees
- rad2deg(radians): List[float] degrees
- radians(degrees) : List[float] radians
- deg2rad(degrees): List[float] radians

https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html


## SymPy
http://docs.sympy.org/latest/modules/functions/elementary.html#sympy-functions-elementary-trigonometric
http://docs.sympy.org/latest/modules/functions/elementary.html#trionometric-functions

- sympy.mpmath.degrees(radians): Float degrees
- sympy.mpmath.radians(degrees): Float radians

- https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy
  - cosd, sind
  - 
https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy#comment50176770_31072815

> Let x, theta, phi, etc. be Symbols representing quantities in radians. 
Keep a list of these symbols: angles = [x, theta, phi]. Then, at the very end, 
use y.subs([(angle, angle*pi/180) for angle in angles]) to change the meaning 
of the symbols to degrees"


## mpmath
http://mpmath.org/doc/current/functions/trigonometric.html
- sympy.mpmath.degrees(radians): Float degrees
- sympy.mpmath.radians(degrees): Float radians


## Sage
https://doc.sagemath.org/html/en/reference/functions/sage/functions/trig.html



On Friday, June 8, 2018, Robert Vanden Eynde 
mailto:robertvandeney...@hotmail.com>> wrote:
- Thanks for pointing out a language (Julia) that already had a name 
convention. Interestingly they don't have a atan2d function. Choosing the same 
convention as another language is a big plus.

- Adding trig function using floats between 0 and 1 is nice, currently one 
needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds 
like turn).

- Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or 
sinturn(x).

Grads are in the idea of turns but with more problems, as you guys said, grads 
are used by noone, but turns are more useful. sin(tau * t) For The Win.

- Even though people mentionned 1/6 not being exact, so that advantage over 
radians isn't that obvious ?

from math import sin, tau
from fractions import Fraction
sin(Fraction(1,6) * tau)
sindeg(Fraction(1,6) * 360)

These already work today by the way.

- As you guys pointed out, using radians implies knowing a little bit about 
floating point arithmetic and its limitations. Integer are more simple and less 
error prone. Of course it's useful to know about floats but in many case it's 
not necessary to learn about it right away, young students just want their 
player in the game move in a straight line when angle = 90.

- sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) !

Re: [Python-ideas] A "within" keyword

[Robert Vanden Eynde]

Classes Provide already some features of a namespace :

class cool_namespace:
A = 8

@staticmethod
def f():
return "yo"

@staticmethod
def g():
return (1 + cool_namespace.A) * cool_namespace.f()

And if you're tired of writing @staticmethod, you can write a class
decorator "namespace" :

@namespace
class cool_namespace:
A = 8

def f():
return "yo"

def g():
return (1 + cool_namespace.A) * cool_namespace.f()

And I think this decorator already exists somewhere.

Le sam. 9 juin 2018 à 10:21, Steven D'Aprano  a écrit :

> On Fri, Jun 08, 2018 at 03:07:28PM -0700, Michael Selik wrote:
>
> > You can use ``eval`` to run an expression, swapping in a different
> globals
> > and/or locals namespace. Will this serve your purpose?
> >
> > In [1]: import types
> > In [2]: ns = types.SimpleNamespace(a=1)
> > In [3]: eval('a', ns.__dict__)
> > Out[3]: 1
>
> The public API for getting an object namespace is vars(ns).
>
> But why would we write eval('a', vars(ns)) instead of getattr(ns, 'a')
> or even better just ns.a? Is your Python code too fast and you need to
> slow it down? *wink*
>
> eval and exec are useful when the code you want to run needs to be
> constructed at runtime. Its not generally useful when you know what you
> want ahead of time as in your example above.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

- Thanks for pointing out a language (Julia) that already had a name 
convention. Interestingly they don't have a atan2d function. Choosing the same 
convention as another language is a big plus.

- Adding trig function using floats between 0 and 1 is nice, currently one 
needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds 
like turn).

- Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or 
sinturn(x).

Grads are in the idea of turns but with more problems, as you guys said, grads 
are used by noone, but turns are more useful. sin(tau * t) For The Win.

- Even though people mentionned 1/6 not being exact, so that advantage over 
radians isn't that obvious ?

from math import sin, tau
from fractions import Fraction
sin(Fraction(1,6) * tau)
sindeg(Fraction(1,6) * 360)

These already work today by the way.

- As you guys pointed out, using radians implies knowing a little bit about 
floating point arithmetic and its limitations. Integer are more simple and less 
error prone. Of course it's useful to know about floats but in many case it's 
not necessary to learn about it right away, young students just want their 
player in the game move in a straight line when angle = 90.

- sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind 
of an exception.




Le ven. 8 juin 2018 à 09:11, Steven D'Aprano 
mailto:st...@pearwood.info>> a écrit :
On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
> On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano 
> mailto:st...@pearwood.info>> wrote:
> > Although personally I prefer the look of d as a prefix:
> >
> > dsin, dcos, dtan
> >
> > That's more obviously pronounced "d(egrees) sin" etc rather than "sined"
> > "tanned" etc.
>
> Having it as a suffix does have one advantage. The math module would
> need a hyperbolic sine function which accepts an argument in; and
> then, like Charles Napier [1], Python would finally be able to say "I
> have sindh".

Ha ha, nice pun, but no, the hyperbolic trig functions never take
arguments in degrees. Or radians for that matter. They are "hyperbolic
angles", which some electrical engineering text books refer to as
"hyperbolic radians", but all the maths text books I've seen don't call
them anything other than a real number. (Or sometimes a complex number.)

But for what it's worth, there is a correspondence of a sort between the
hyperbolic angle and circular angles. The circular angle going between 0
to 45° corresponds to the hyperbolic angle going from 0 to infinity.

https://en.wikipedia.org/wiki/Hyperbolic_angle

https://en.wikipedia.org/wiki/Hyperbolic_function


> [1] Apocryphally, alas.

Don't ruin a good story with facts ;-)



--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

- I didn't know there were sinf in C (that's since C99), I was aware of the
'd' postfix in opengl.

So yeah, sind would be a bad idea, but sindeg or degsin would be too long,
hmm, and I can settle for the Pre or Post fix. sindeg(90) degsin(90) are
both pretty, the first emphasize on the "degree" part and the second on the
"sin(90)" part. I feel I prefer sindeg, cosdeg, atandeg, atan2deg,
phasedeg, rectdeg hmhm

By the way I've seen a stackoverflow answer using Sin and Cos with a
capital letter, doesn't seem very explicit to me.

- I could do a pypi for it for sure, I didn't know it was that easy to
create a repo actually. degreesmath (and degreesmath.cmath ?) would be a
good package name but again I don't want to name the functions sin, cos.
People could rename them on import anyway (let the fools be fools as long
as they don't hurt anyone).

- I agree radians should be the default, but is it especially Because
sin/cos must be in radians ? And because it's more efficient ? The problem
arrises when Mixing units in the same program.

However, should everyone use m³ and not Liters because they're the SI units
? That's more a problems of "mixing units and not sticking to one
convention". I've seen lot of libraries using degrees (and not just good
old glRotate).

Let's notice there are some libraries that wrap units so that one can mix
them safely (and avoid to add meters to seconds).

Let's be honest, radians are useful only when converting arc length, areas
or dealing with derivatives, signals, or complex numbers (engineering
stuffs), and efficiency of sin/cos implementations. When doing simple 2D/3D
applications, angles are just angles and nobody needs to know that
derivative of sin(ax) is a·cos(ax) if x is in radians.

- Integers are more convenient than float, you could add 1 degree every
frame at 60fps to a counter and after 60 frames you'll do a full turn,
adding tau/360 doesn't add so well (floating point representation). Having
exact representation for multiple of 90 degrees is a big plus. Another
advantage is also being able to check if the angle is particular (multiple
of 30 or 90 for example). Especially python Integers with infinite
precision.

- Everyone knows degrees, whereas radians are known only by people that had
math in 10th grade. I know it's easy to say "just convert" but trust me,
not everyone is confident with unit conversions, when you ask "what's the
unit of angle ?" people will think of degrees.

- Changing the behavior for current cos/sin function to have cos(pi/2)
being exact is a bad idea in my opinion, the good old sin/cos from C exist
for a long time and people rely on the behaviors. That would break too much
existing code for no much trouble. And would slow Current applications
relying on the efficiency of the C functions.

- I totally agree writing degrees(...) and radians(...) make it clear and
explicit. That's why I strongly discourage people defining their own "sin"
function that'd take degrees, therefore I look for a new function name
(sindeg).

Le ven. 8 juin 2018 à 00:17, Hugh Fisher  a écrit :

> > Date: Thu, 7 Jun 2018 12:33:29 +
> > From: Robert Vanden Eynde 
> > To: python-ideas 
> > Subject: [Python-ideas] Trigonometry in degrees
> > Message-ID:
> > >
> > I suggest adding degrees version of the trigonometric functions in the
> math module.
> >
> > - Useful in Teaching and replacing calculators by python, importing
> something is seen by the young students much more easy than to define a
> function.
>
> I agree that degrees are useful for teaching. They are also very
> useful for graphics
> programming, especially with my favourite OpenGL API. But I think that
> the use of
> radians in programming language APIs is more prevalent, so the initial
> advantage
> of easy learning will be outweighed by the long term inconvenience of
> adjusting to
> what everyone else is doing.
>
> Writing degrees(x) and radians(x) is a little inconvenient, but it
> does make it clear
> what units are being used. And even if your proposal is adopted, there
> is still going
> to be a lot of code around that uses the older math routines. With the
> current API
> it is a least safe to assume that angles are radians unless stated
> otherwise.
>
> > - Special values could be treated, aka when the angle is a multiple of
> 90, young students are often surprise to see that cos(pi/2) != 0
> >
> > Testing for a special value Isn't very costly (x % 90 == 0) but it could
> be pointed out that there is a small overhead using the "degrees"
> equivalent of trig function because of the radians to degrees conversion
> And the special values testing.
>
> Not just young students :-) I agree with this, but I would prefer the
> check to be in
> the implementat

[Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

I suggest adding degrees version of the trigonometric functions in the math 
module.

- Useful in Teaching and replacing calculators by python, importing something 
is seen by the young students much more easy than to define a function.

- Special values could be treated, aka when the angle is a multiple of 90, 
young students are often surprise to see that cos(pi/2) != 0

Testing for a special value Isn't very costly (x % 90 == 0) but it could be 
pointed out that there is a small overhead using the "degrees" equivalent of 
trig function because of the radians to degrees conversion And the special 
values testing.

- Standard names will be chosen so that everyone will use the same name 
convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, 
atan2d.

Another option would be to add "deg" or prepend "d" or "deg" however the name 
should be short.

sind, dsin, sindeg or degsin ?

We can look in other languages what they chose.

Creating a new package like 'from math.degrees import cos' however I would not 
recommend that because "cos" in the source code would mean to lookup the import 
to know if it's in degrees or radians (and that leads to very filthy bugs). 
Also "degrees" is already so the name would have to change the name of the 
package.

- Also in the cmath module. Even though the radians make more sense in the 
complex plane. The same functions sin cos tan, asin acos atan, alongside with 
phase and polar.

Here's my current implementation :

def cosd(x):
if x % 90 == 0:
return (1, 0, -1, 0)[int(x // 90) % 4]
else:
return cos(radians(x))

def sind(x):
if x % 90 == 0:
return (0, 1, 0, -1)[int(x // 90) % 4]
else:
return sin(radians(x))

def tand(x):
if x % 90 == 0:
return (0, float('inf'), 0, float('-inf'))[int(x // 90) % 4]
else:
return tan(radians(x))

The infinity being positive of negative is debatable however, here I've chosen 
the convention lim tan(x) as x approaches ±90° from 0

def acosd(x):
if x == 1: return 0
if x == 0: return 90
if x == -1: return 180
return degrees(acos(x))

def asind(x):
if x == 1: return 90
if x == 0: return 0
if x == -1: return -90
return degrees(asin(x))

However, currently [degrees(acos(x)) for x in (1,0,-1)] == [0, 90, 180] on my 
machine so maybe the test isn't necessary.

Testing for Special values of abs(x) == 0.5 could be an idea but I don't think 
the overhead is worth the effort.

Probably this has already been discussed but I don't know how to check that.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] datetime.timedelta literals

[Robert Vanden Eynde]

second, minute, hour (singular) timedelta objects in the module are a good
idea, one could do 5 * minute to get a timedelta or one could do value /
minute to get a float.

a = datetime.now()
b = datetime(2018, 2, 3) + 5 * minute
print((a - b).total_seconds())
print((a - b) / minute)



Le mar. 5 juin 2018 à 10:23, Jacco van Dorp  a écrit :

> 2018-06-05 10:08 GMT+02:00 Pål Grønås Drange :
> >> You can't import literals. They're syntax, not just bound names.
> >
> > I'm way out of my comfort zone now, but the parser could for
> > `123.45_f`
> > give
> > `__literal_f__(123.45)`
> > and then that function should be imported.
> >
> > I'm sure this idea has many shortcomings that I don't see, but that was
> the
> > reason why I wanted to import stuff.
> >
> > Pål
>
> Before your code is executed, python scans your entire file for syntax
> errors. Since 123.45_f is currently not a valid literal, it'll just
> print a syntax error without even looking at your imports.
>
> To change that, the very core of python would need to look completely
> different. It'd be a metric fuckton of work for a whole lot of people.
> Im not a core dev myself or anything, but i'm pretty confident that
> this isn't going to happen for a rather minor need like this.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/