Re: [Python-ideas] Add a __cite__ method for scientific packages

[Matt Arcidy]

On Fri, Jun 29, 2018, 17:14 Andrei Kucharavy 
wrote:

> One more thing. There's precedent for this: when you start an interactive
>> Python interpreter it tells you how to get help, but also how to get
>> copyright, credits and license information:
>>
>> $ python3
>> Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 26 2018, 19:50:54)
>> [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> credits
>> Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of
>> thousands
>> for supporting Python development.  See www.python.org for more
>> information.
>> >>>
>>
>
This is thin justification to add something to core.

It seems like the very small percentage of academic users whose careers
depend on this cannot resolve the political issue of forming a standards
body.

I don't see how externalizing the standard development will help.  Kudos
for shortcutting the process in a practical way to just get it done,  but
this just puts core devs in the middle of silly academic spats.  A language
endorsed citation method isn't a 'correct' method, and without the broad
consensus that currently doesn't exist, this becomes _your_ method, a
picked winner but ultimately a lightning rod for bored tenured professors
with personal axes to grind.  If this were about implementing an existing
correct method I'm sure a grad student would be tasked with it for an
afternoon.

This is insanely easy to implement in docstrings, or a standard import, or
mandatory include, or decorator, or anywhere else, it's just a parsing
protocol.  I believe 3.7 now exposes docstrings in the AST, meaning a
simple static analyzer can handle all of PyPi, giving you crazy granularity
if citations existed.  Don't you want to cite the exact algorithm used in
an imported method, not just lump them all into one call?  Heck, I bet you
could use type annotations.

This really feels like you've got an amazing multi-tool but you want to
turn the world, not the screw. This isn't a tool the majority of people
will use, even if the citations exist.

Don't get me wrong, I love designing standards and protocols, but this is
pretty niche.

I assume it won't be mandatory so I'm tilting at windmills,  but then if
it's not mandatory, what's the point of putting it in core?  Just create a
jstor style git server where obeying the citation protocol is mandatory.
Of course, enforcing a missing citation is impossible, but it does mean
citations can be generated by parsing imports.  This is how it will evolve
over time, by employing core devs on that server framework.




>> It makes total sense to add citations/references to this list (and those
>> should probably print a reference for Python followed by instructions on
>> how to get references for other packages and how to properly add a
>> reference to your own code).
>>
>>
> If that's possible, that would be great!
>
>
>> I think that an approach similar to help/quit/exit is warranted. The
>> cite()/citation() function need not be *literally* built into the
>> language, it could be an external function written in Python and added
>> to builtins by the site.py module.
>
>
> I was not aware this was a possibility - it does seem like a good option!
>
> If I were you, I'd try organizing a birds-of-a-feather at the next
>> SciPy conference, or start getting in touch with others working on
>> this (duecredit devs, the folks listed on that citationPEP thing,
>> etc.), and go from there. (Feel free to CC me if you do start up some
>> effort like this.)
>
>
> Not all packages are within the numpy/scipy universe - Pandas and Seaborn
> are notable examples.
>
> I bought this thread to the attention of some major scientific package
> maintainers as well as the main citationPEP author. I am not entirely sure
> where this conversations could be moved outside python-ideas given we are
> talking about something universal across packages, but would gladly take
> any suggestions.
>
> There isn't actually any formal method for registering special names
>> like __version__, and they aren't treated specially by the language.
>> They're just variables that happen to have a funny name. You shouldn't
>> start using them willy-nilly, but you don't actually have to ask
>> permission or anything. And it's not very likely that someone else
>> will come along and propose using the name __citation__ for something
>> that *isn't* a citation :-).
>
>
> Thanks for the explanation - Python development and maintenance do seem to
> be a complex process from the outside and this kind of subtleties are not
> always easy to distinguish :).
>
> The way to do this is to first get your solution implemented as a
>> third-party library and adopted by the scientific packages, and then
>> start thinking about whether it would make sense to move the library
>> into the standard library. It's relatively easy to move things into
>> the standard library. The hard part is making 

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

[Matt Arcidy]

On Mon, Jun 18, 2018, 19:25 Chris Barker via Python-ideas <
python-ideas@python.org> wrote:

> On Sat, Jun 16, 2018 at 10:57 PM, Tim Peters  wrote:
>
> Ya, decimal fp doesn't really solve anything except the shallow surprise
>> that decimal fractions generally aren't exactly representable as binary
>> fractions.  Which is worth a whole lot for casual users, but doesn't
>> address any of the deep problems (to the contrary, it makes those a bit
>> worse).
>>
>
> It's my suspicion that the story is the same with "degree-based" trig :-)
>
> Which is why, if you want "nice-looking" results, it seems one could
> simply accept a decimal digit or so less precision, and use the "regular"
> FP trig functions, rounding to 14 or so decimal digits.
>
> Though if someone really wants to implement trig in native degrees -- more
> power to 'em.
>
> However -- if this is really such a good idea -- wouldn't someone have
> make a C lib that does it? Or has someone? Anyone looked?
>


quite a few in fact, including cos(n*pi)
https://www.boost.org/doc/libs/1_52_0/boost/units/cmath.hpp




> -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] Link accepted PEPs to their whatsnew section?

[Matt Arcidy]

On Wed, Jun 13, 2018, 06:51 Nick Coghlan  wrote:

> On 13 June 2018 at 11:06, Michael Selik  wrote:
>
>> Google will probably fix this problem for you after dataclasses become
>> popular. The docs will gain a bunch of inbound links and the issue will
>> (probably) solve itself as time passes.
>>
>
> Sometimes when reading a PEP it isn't especially clear exactly which
> version it landed in, or whether or not there were significant changes
> post-acceptance based on issues discovered during the beta period, though.
>
> So the idea of a "Release-Note" header that points to the version specific
> What's New entry seems like a decent idea to me (and may actually help the
> What's New section supplant the PEP in search results).
>

perhaps some machine readable format of the release tag on the PEP which is
then read when generating the notes, and pulls it in?  include the link to
the PEP in the notes as well.  just tag the PEP with release and forget
about it.

no idea if that fits into the process, just a thought.


> Cheers,
> Nick.
>
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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

[Matt Arcidy]

Sorry for top posting, but these aren't really opinions for the
debate, just information.  I haven't seen them mentioned, and none
grouped nicely under someone's reply.

Number representation::
IEEE-754 doubles cannot represent pi correctly at any bit-depth (i
mean, obviously, but more seriously).
input pi = 3.14159265358979323846264338327
output pi = 3.14159265358979311599796346854

The cutoff is the value everyone uses, which is what is in math.pi
among other places.
3.141592653589793

Any conversion using this value of pi is already wrong, and the input
to the function is already wrong.  The function doesn't matter.  It's
always underestimating if using pi.  I'm clarifying this because it's
separate from any discussion of functions.  More accurate or different
functions cannot use a better input pi.

Calculator: http://www.binaryconvert.com/convert_double.html
input pi source: https://www.piday.org/million/

Libraries:
Boost implements a cos_pi function, it's algorithm will probably be
useful to look at.

glibc implements cos/sin as a look-up table, which is most likely
where any other implementation will end up, as it is a common
endpoint.  I've seen this on different architectures and libraries.
(sincostab.h if you want to google glibc's table).  Maybe there is a
hilarious index lookup off-by-1 there, I didn't look.

Tables are the basis for the calculation in many libraries  in march
architectures, so I wanted to point that out to any function
designers.  A new implementation may come down to calculating right
index locations.
For a degree based implementation, the same algorithm can be used with
a different table input that is calibrated to degrees.
Likewise,  a pi based implementation, the same but for the pi scale
factor input.
Nothing needs to be done designed other than a new lookup table
calibrated for the "base" of a degree, radian, or pi..  it will have
the same output precision issues calculating index values, but at
least the input will be cleaner.

This is not me saying what should be done, just giving information
that may hopefully be useful

Small note about python's math:
The python math library does not implement algorithms, it exposes the
c functions.  You can see C/C++ has this exact issue performing the
calculation there.  As that is "the spec," the spec is defined with
the error.  The math library is technically correct given it's stated
purpose and result.
Technically correct, the best kind of correct.
https://www.youtube.com/watch?v=hou0lU8WMgo


On Mon, Jun 11, 2018 at 10:53 PM Tim Peters  wrote:
>
> [Steven D'Aprano]
>>
>> ...
>>
>> The initial proposal is fine: a separate set of trig functions that take
>> their arguments in degrees would have no unexpected surprises (only the
>> expected ones). With a decent implementation i.e. not this one:
>>
>> # don't do this
>> def sind(angle):
>> return math.sin(math.radians(angle))
>
>
> But that's good enough for almost all real purposes.  Indeed, except for 
> argument reduction, it's essentially how scipy's sindg and cosdg _are_ 
> implemented:
>
> https://github.com/scipy/scipy/blob/master/scipy/special/cephes/sindg.c
>
>>
>> and equivalent for cos, we ought to be able to get correctly rounded
>> values for nearly all the "interesting" angles of the circle, without
>> those pesky rounding issues caused by π not being exactly representable
>> as a float.
>>
> If people are overly ;-) worried about tiny rounding errors, just compute 
> things with some extra bits of precision to absorb them.  For example, 
> install `mpmath` and use this:
>
>  def sindg(d):
> import math, mpmath
> d = math.fmod(d, 360.0)
> if abs(d) == 180.0:
> return 0.0
> with mpmath.extraprec(12):
> return float(mpmath.sin(mpmath.radians(d)))
>
> Then, e.g,
>
> >>> for x in (0, 30, 90, 150, 180, 210, 270, 330, 360):
> ... print(x, sindg(x))
> 0 0.0
> 30 0.5
> 90 1.0
> 150 0.5
> 180 0.0
> 210 -0.5
> 270 -1.0
> 330 -0.5
> 360 0.0
>
> Notes:
>
> 1. Python's float "%" is unsuitable for argument reduction; e.g.,
>
> >>> -1e-14 % 360.0
> 360.0
>
> `math.fmod` is suitable, because it's exact:
>
> >>> math.fmod(-1e-14, 360.0)
> -1e-14
>
> 2. Using a dozen extra bits of precision make it very likely you'll get the 
> correctly rounded 53-bit result; it will almost certainly (barring bugs in 
> `mpmath`) always be good to less than 1 ULP.
>
> 3. Except for +-180.  No matter how many bits of float precision (including 
> the number of bits used to approximate pi) are used, converting that to 
> radians can never yield the mathematical `pi`; and sin(pi+x) is approximately 
> equal to -x for tiny |x|; e.g., here with a thousand bits:
>
> >>> mpmath.mp.prec = 1000
> >>> float(mpmath.sin(mpmath.radians(180)))
> 1.2515440597544546e-301
>
> So +-180 is special-cased.  For cosdg, +-{90. 270} would need to be 
> special-cased for the same reason.
>
> ___
> 

Re: [Python-ideas] Reuse "for" to express "given"

[Matt Arcidy]

On Thu, May 24, 2018, 14:48 Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

>
>
> On Thu, May 24, 2018 at 4:59 PM Matt Arcidy <marc...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 24, 2018, 11:47 Alexander Belopolsky <
>> alexander.belopol...@gmail.com> wrote:
>>
>>> > But I do have a mathematics background, and I don't remember ever
>>> seeing
>>> > "for x = value" used in the sense you mean.
>>>
>>> That's so because in mathematics, "for" is spelled ":" as in
>>>
>>>  {2*a* : *a*∈*Z*}
>>>
>>> If you can read the above, you should not have trouble reading
>>>
>>>  {2*a* + *b* : *a*∈*Z *: *b = *1}
>>>
>>
>> Inverted "A" is "for all", and colon means "such that".  It may be
>> acceptable somewhere to use a colon as you do,
>>
>
> See <https://en.wikipedia.org/wiki/Set_notation>.  Also, "[list
> comprehensions] is Python's way of implementing a well-known notation for
> sets as used by mathematicians." <
> https://www.python-course.eu/list_comprehension.php>.  Although, the
> latter uses "|" instead of ":".
>

My point was more along the lines of math doesn't use ":" for "for".  "for"
exists in math as a different symbol. Even in set builder notation ":"
isn't interpretted as "for", it's "such that."

Maybe the math discussion is totally tangential.  I'm not clear why I'm
making these points really, apologies if I took this off course, I'm happy
to concede the math and just keep my other points.  I don't think "for" is
bad compared to some other alternatives, but I don't see it better than
":=" in the contexts you've raised.  Even in the implementation of set
building, "for" is only used to build the sets element wise, not as a
partitioning, and is not a property if the set itself.


Thanks,
___
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] Reuse "for" to express "given"

[Matt Arcidy]

On Thu, May 24, 2018, 11:47 Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> > But I do have a mathematics background, and I don't remember ever seeing
> > "for x = value" used in the sense you mean.
>
> That's so because in mathematics, "for" is spelled ":" as in
>
>  {2*a* : *a*∈*Z*}
>
> If you can read the above, you should not have trouble reading
>
>  {2*a* + *b* : *a*∈*Z *: *b = *1}
>

Inverted "A" is "for all", and colon means "such that".  It may be
acceptable somewhere to use a colon as you do, but the lone colon
unambiguously is "such that" when constructing sets.  I never once saw
colon used this way, and would be interested to see it in a proper math
paper to correct my world view.

"for" only reads as "such that" as:
"A such that x = 1"
"A, for x = 1" which sounds a bit Shakespearian and is definitely not
common.

standard math:
"2a plus b for all integers such that b is 1."
or
"2a plus b for each integer such that b is 1"

using "for" as ":":
"2a plus b for a in integers for b in 1"
or
"2a plus b for a eauals integers for b eauals 1"
or
"2a plus b for all a in integers for all b in 1"

Understandable, but I would get zero point on my homework for those, they
are correct.

In the context of math in general, ":=" makes more sense, and is actual
math notation for assignment:

http://mathworld.wolfram.com/Colon.html


ignoring math:

I'm kind of fine with nudging the meaning of "for" as you describe to be
assignment, it's close enough, such that it's not a long leap.  I think
this point is the best case for "for",  but I don't think being the only
language to do this is great, and I usually don't care about language
similarities.   I lack breadth, however, so please correct me here.

However, I cannot say this is superior to ":=" based on the same logic, as
":=" achieves the same ends with less semantic confusion, typing, and uses
earlier indication of assignment.


And please note that making "for" ambiguous when there is already the
ambiguity in post fix notation makes the spelling less desirable to me. In
this spelling, for one assignment, there are two ambiguities that must be
resolved: the assigned name and the meaning of "for", though the latter is
cleared up quickly.  This small ambiguity is still there and I don't see a
reason to introduce it.

Thanks



> ___
> 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] Modern language design survey for "assign and compare" statements

[Matt Arcidy]

On Mon, May 21, 2018, 03:58 Rhodri James <rho...@kynesim.co.uk> wrote:

> On 20/05/18 06:19, Matt Arcidy wrote:
> > On Sat, May 19, 2018, 11:07 Kirill Balunov <kirillbalu...@gmail.com>
> wrote:
> >
> >>
> >>
> >> I think I have a very strong argument "why are not others valid" -
> Because
> >> already three months have passed and among 1300+ messages there was not
> a
> >> single real example where assignment expression would be convenient or
> >> useful outside `while` and `if` statements. If you have a
> counterargument
> >> (with an example), I would be glad to see.
> >>
> >
> > comprehensions.  I don't think you read any of the messages.  about 1000
> > were solely about comprehensions.
>
> I'm afraid I haven't seen a convincing example of an useful assignment
> expression in a comprehension that wasn't also a convincing example of
> things that shouldn't have been comprehensions in the first place.
>

I haven't seen a convincing counter argument that doesn't axiomatically
depend on personal opinion.  Can you define your "shouldn't" in a way that
isn't just your personal taste?  I can't know from your statement here.


> --
> Rhodri James *-* Kynesim Ltd
> ___
> 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] Modern language design survey for "assign and compare" statements

[Matt Arcidy]

Anyone can trivially construct a scope that limits applicable cases to
support a specific point.  This thread is pointless without full context.

On Sun, May 20, 2018, 11:05 Mike Miller  wrote:

> For more background, this is the thread that inspired this one:
>
>  https://mail.python.org/pipermail/python-dev/2018-April/153071.html
>
>
> -Mike
> ___
> 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] Modern language design survey for "assign and compare" statements

[Matt Arcidy]

On Sat, May 19, 2018, 11:07 Kirill Balunov  wrote:

>
>
> I think I have a very strong argument "why are not others valid" - Because
> already three months have passed and among 1300+ messages there was not a
> single real example where assignment expression would be convenient or
> useful outside `while` and `if` statements. If you have a counterargument
> (with an example), I would be glad to see.
>

comprehensions.  I don't think you read any of the messages.  about 1000
were solely about comprehensions.

How about every example brought up in 1300+ messages that assignment
expressions could handle that otherwise required far more code?  Some
including imports?

Did you miss where _every_ counter example was either doing what assignment
expressions do with more code, or where outright misunderstandings of how
they will work?  Did you read Chris' responses where he clearly refused
each example?

 Really hard to see how you got that take away if you read those messages.
Basically you are not backed up at all by citing that.

assignment expressions handle many cases with ONE syntax.  They are the
"one way to do it" where "it" covers every example brought up so far.


>
>
___
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] Inline assignments using "given" clauses

[Matt Arcidy]

On Sun, May 13, 2018, 11:28 Brendan Barnwell  wrote:

> On 2018-05-13 04:23, Steven D'Aprano wrote:
> > In my experience mathematicians put the given *before* the statement:
> >
> > Given a, b, c three sides of a triangle, then
> >
> > Area = sqrt(s*(s-a)*(s-b)*(s-c))
> >
> > where s = (a + b + c)/2 is the semi-perimeter of the triangle.
> >
> > For the record, that is almost exactly what I wrote for a student
> > earlier today, and its not just me, it is very similar to the wording
> > used on both Wolfram Mathworld and Wikipedia's pages on Heron's Formula.
> >
> > http://mathworld.wolfram.com/HeronsFormula.html
> >
> > https://en.wikipedia.org/wiki/Heron%27s_formula
> >
> >
> > Putting "given" after the expression is backwards.
>
> Yes, but that's because we're ruling out the use of "where".  At
> this
> point I would be fine with "snicklefritz" as the keyword.  The point is
> that I want to put SOMETHING after the expression, and this is not at
> all unusual.  See for instance Wikipedia pages on the Reimann zeta
> function
> (https://en.wikipedia.org/wiki/Riemann_zeta_function#Definition),
> gravitation equation
> (https://en.wikipedia.org/wiki/Gravity#Newton%27s_theory_of_gravitation),
> and
> compound interest
> (
> https://en.wikipedia.org/wiki/Compound_interest#Mathematics_of_interest_rate_on_loans).
>
>   If we have to use the word "given" even though the word mathematicians
> would use in that position is "where", that's not such a big deal.
>

it is a big deal.  postfix requires more cognitive load, we will have no
idea up front what's going on except for trivial exames.  more givens, more
cognitive load.

if you think spending that is fine for you, I can't argue, but to say it
doesn't matter isn't correct.

2.exames which get far worse for complex cases.  left for the for can be as
complex.as.you wish.
1:
[ x + y for t in range(10)  ... ]

2:
x = 10
y = 20
[ x + y for t in range(10) ...]

up till you read ... you have no idea there even will be a substitution.
The lower is even worse, you think you know, but then have to redo the
whole problem with new information.

also :
mathematicians don't just put the _word_ "given", they put givens, things
that are known or assumed to be true.  Axioms and definitions, where
definitions assign names to values.  This is for formal arguements.
reassigning values is handled in post fix occasionally once it is clear
what x and y are.  but that's not what we are talking about if the name
doesn't exist already.

again, you want to use given, that's fine, but the math argument is wrong,
as is the "it doesn't matter" argument, assuming the current neurological
model for working memory continues to hold.

 Maybe the difference is small, especially after familiarity sets in, but
that doesn't mean the difference in load isn't there.  it will only
increase for more complex statements with more givens.

>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
> --author unknown
> ___
> 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] Inline assignments using "given" clauses

[Matt Arcidy]

On Fri, May 11, 2018, 17:04 Tim Peters <tim.pet...@gmail.com> wrote:

> [Matt Arcidy]
> >> Note Tim came up with a real metric:
> >> 2 * count(":=")/len(statement).
> >> It's objective.  it's just unclear if a higher score is better or worse.
> >> However, one could say "a Tim of .3 is considered too high" as a
> guideline.
>
> [Steven D'Aprano]
> > I think Tim was making a joke about demanding objective measurements of
> > subjective things.
> >
> > Certainly he hasn't done any research or study to justify that metric.
> > He just plucked the formula out of thin air.
>
> It was the outcome of an intense 17-year research project.
>
>
> > Or at least no peer reviewed research.
>
> Au contraire!  My peers are here, and that message was reviewed by at
> least 3 people on this list.
>
> That said, I am a fan of objectively measuring subjective things, just
> not of taking the measurements seriously ;-)
>

apparently my joke was objectively not funny :-)  I thought calling it a
"Tim" was sufficient.

Im not serious about actually ranking for the purposes of a PEP.  I brought
it up when I felt the subjectivity was making the debate worse.

Reiterating my point, n long sub-threads about fonts, screens, etc are
ridiculous when those exist outside the pyfile.  I don't know why personal
preference for a font would stop a useful tool.  Hopefully those arguments
are ignored.  Likewise for googlability, teachability, cross-language
similarity and familiarity.  If the tool is useful, that's all that will
matter with respect to these points, they solve themselves.

I happen to be working on a ranking tool for code (not quality, just an
ordering to find entry points for new devs), so i tossed the idea in.  it
seemed appropriate to remind people that the fact that not everyone uses
green to highlight "+" doesn't make "+" somehow more or less _useful_
(people -1'd just for legibility alone because of their personal feelings)

I'm not sure where people stand on usefulness, but it's clear this tool is
a pattern.  No counter example of "but I can already do this" is related to
other counter examples in the way that named expressions solves all of
them, and does it succinctly regardless of chosen syntax.  Some required
imports!

Obviously making these decisions with the future unknown is nearly
impossible and requires careful consideration of all points, but I don't
think Hypothetical Bill's perscription glasses should determine syntax
decisions.

Best of luck with the hard parts, clearly I hope the PEP makes it.


>
>
> If people do want to take it seriously, check out prior Python art first:
>

Awesome, thanks!

>
> http://radon.readthedocs.io/en/latest/intro.html
> ___
> 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] Inline assignments using "given" clauses

[Matt Arcidy]

Apology for top post, but this is a general statement about Readability and
not a response to an individual.

it would be nice to list the objective parts separate from the "argument"
(i.e. debate, not fight), perhaps list them then make a case for which
metric is a more important, and which values produce better results.

Key strokes, keyboard location, location of information vs where it is
used, cognitive load (objective barring neuroscience changes) are all
objective points (along with many other points raised).

"Better" will be decided by Guido I guess, but listing objective points
with explanatory examples gives a basis for that discussion.

Legibility, for example, is not objective at all, it has nothing to do with
syntax.  This covers fonts, colors, monitors, lighting, chairs, lunch,
etc.  None of this is relevent to the symbols or their ordering in a file
we all must read.

Teachability likewise.  My opinion here is learnability is far more
important anyways, I am 90% self taught going back 25 years, but this is
equally unquantifiable.  Perhaps just trust students to learn as an author
must trust a reader.

Of course, let it not be lost that determining teachability and
learnability for something which doesn't even exist yet is quite
challenging.

Any quantification will give more information than only naked impassioned
pleas to Readability.

Note Tim came up with a real metric:
2 * count(":=")/len(statement).
It's objective.  it's just unclear if a higher score is better or worse.
However, one could say "a Tim of .3 is considered too high" as a guideline.

Perhaps coders find these opportunities to express feelings and opinion
cathartic after speaking to the most pedantic creature on Earth
(compilier/computer) but I think exercising the high skill level available
here to dissect and find objective statements is a worthy puzzle.

On Fri, May 11, 2018, 11:14 Brendan Barnwell  wrote:

> On 2018-05-11 11:08, Brendan Barnwell wrote:
> > . . . and it's true the latter is a bit more verbose in that case for
> > little extra benefit.  But when the locally-defined value is used within
> > a more complicated expression (like the quadratic formula example), I
> > think readability goes down significantly.  To appease Tim, instead of
> > using the quadratic formula, though, I will use a more realistic example
> > that comes up fairly often for me: wanting to do some kind of
> > normalization on a piece of data for a comparison, while keeping the
> > unnormalized data for use within the block:
> >
> >   if some_condition and (stuff:=
> > get_user_input()).lower().strip().replace('-', ''):
> >
> > versus
> >
> >   if some_condition and stuff.lower().strip().replace('-', '') given
> > stuff = get_user_input():
>
> Ironically I weakened my argument by forgetting to finish my
> expression
> there.  I intended that chain of method calls to be used in a comparison
> to make the surrounding expression more complex.  So revise the above to
>
> if some_condition and (stuff :=
> get_user_input()).lower().strip().replace('-', '') == existing_value:
>
> versus
>
> if some_condition and stuff.lower().strip().replace('-', '') ==
> existing_value given stuff = get_user_input():
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
> --author unknown
> ___
> 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] A comprehension scope issue in PEP 572

[Matt Arcidy]

On Sun, May 6, 2018 at 7:37 PM, Matt Arcidy <marc...@gmail.com> wrote:
>> Personally, I'd still like to go back to := creating a statement-local
>> name, one that won't leak out of ANY statement. But the tide was
>> against that one, so I gave up on it.
>
> yes.
>
> I have some probably tangential to bad arguments but I'm going to make
> them anyways, because I think := makes the most sense along with SLNB.
>
> first, := vs post-hoc (e.g. where or given)
>
> base case:
> [ x for x in range(1) ]
> while obvious to all of us, reading left to right does not yield what
> x is till later.
> [ (x, y) for x in range(1) for y in range(1) ] doubly so.
> If x or y were defined above, it would not be clear until the right
> end if what contex they had.
>
> [ (x, y) for x in range(n) given y = f(n) ]
> i dont know what's the iterator till  after 'for'
>
> [ (x, y:=f(n) for x in range(n) ]
> At a minimum, I learn immediately that y is not the iterator.
> Slightly less cognitive load.
>
> it's not that one is better, or that either is unfamiliar, it's about
> having to hold a "promise" in my working memory, vs getting an
> immediate assignment earlier.  (it's a metric!)
>
> now my silly argument.
> ":" is like a "when" operator.
>
> if y==x:
keyboard fail.

if y == x:
   # execute when y == x

for x in y:
# execute when x in y

class/def f:
# execute when in f

x := 1  # x = 1 when in local scope

Stretch!  told you ti was silly.
>
>
>
>>
>> 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] A comprehension scope issue in PEP 572

[Matt Arcidy]

> Personally, I'd still like to go back to := creating a statement-local
> name, one that won't leak out of ANY statement. But the tide was
> against that one, so I gave up on it.

yes.

I have some probably tangential to bad arguments but I'm going to make
them anyways, because I think := makes the most sense along with SLNB.

first, := vs post-hoc (e.g. where or given)

base case:
[ x for x in range(1) ]
while obvious to all of us, reading left to right does not yield what
x is till later.
[ (x, y) for x in range(1) for y in range(1) ] doubly so.
If x or y were defined above, it would not be clear until the right
end if what contex they had.

[ (x, y) for x in range(n) given y = f(n) ]
i dont know what's the iterator till  after 'for'

[ (x, y:=f(n) for x in range(n) ]
At a minimum, I learn immediately that y is not the iterator.
Slightly less cognitive load.

it's not that one is better, or that either is unfamiliar, it's about
having to hold a "promise" in my working memory, vs getting an
immediate assignment earlier.  (it's a metric!)

now my silly argument.
":" is like a "when" operator.

if y==x:



>
> 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] Inline assignments using "given" clauses

[Matt Arcidy]

On Fri, May 4, 2018, 11:35 Guido van Rossum  wrote:

> On Fri, May 4, 2018 at 11:11 AM, Tim Peters  wrote:
>
>> [Nick Coghlan ]
>> > ...
>> > Using a new keyword (rather than a symbol) would make the new construct
>> > easier to identify and search for, but also comes with all the
>> downsides of
>> > introducing a new keyword.
>>
>> That deserves more thought.  I started my paying career working on a
>> Fortran compiler, a language which, by design, had no reserved words
>> (although plenty of keywords).  The language itself (and
>> vendor-specific extensions) never had to suffer "but adding a new
>> keyword could break old code!" consequences.
>>
>> In practice that worked out very well,  Yes, you _could_ write
>> hard-to-read code using language keywords as, e.g., identifier names
>> too, but, no, absolutely nobody did that outside of "stupid Fortran
>> tricks" posts on Usenet ;-)  It had the _intended_ effect in practice:
>>  no breakage of old code just because the language grew new
>> constructs.
>>
>> It's no longer the case that Python avoided that entirely, since
>> "async def", "async for", and "async with" statements were added
>> _without_ making "async" a new reserved word.  It may require pain in
>> the parser, but it's often doable anyway.  At this stage in Python's
>> life, adding new _reserved_ words "should be" an extremely high bar -
>> but adding new non-reserved keywords (like "async") should be a much
>> lower bar.
>>
>
> Do note that this was a temporary solution. In 3.5 we introduced this
> hack. In 3.6, other uses of `async` and `await` became deprecated (though
> you'd have to use `python -Wall` to get a warning). In 3.7, it's a syntax
> error.
>
>
>> That said, I expect it's easier in general to add a non-reserved
>> keyword introducing a statement (like "async") than one buried inside
>> expressions ("given").
>>
>
> I'd also say that the difficulty of Googling for the meaning of ":="
> shouldn't be exaggerated. Currently you can search for "python operators"
> and get tons of sites that list all operators.
>

Without adding hits to the search algorithm, this will remain the case.
Google must have clicks to rank up.  Right now there is no page, nothing on
a high "Google juice" page like python.org, no one searching for it, and no
mass of people clicking on it.  no SO questions, etc.

there is a transient response for all change.  uniqueness and length of
search term is just a faster one.  All python syntax is findable eventually
due to popularity.  plus a better search is "why would I use...in python"
or similar.

= python also doesn't bring up anything interesting that wouldn't be had
because of just "python".  The details are too mundane and/or technical and
everyone knows already.

>
that being said, if := had been (theoretically) included from the
beginning, would people continue to have issues with it?  unlikely, but I
can't know.  familiarity will cure many of these issues of readability or
symbolic disagreement no matter what is chosen (well, to a point).  it's
unfortunate that changes have to be made up front with so little
information like that, so I'm not advocating anything based on this, just
pointing it out.


I do think post hoc assignment will cause a cognitive load, like trying to
figure out which variable is the iterator, and having to keep two contexts
till the end of a comp with one given statement.

[f(x) + a for all a in blah given x=1]

not worse than a double nested comp though.

>
> I also note that Google seems to be getting smarter about non-alphabetic
> searches -- I just searched for "python << operator" and the first hit was
> https://wiki.python.org/moin/BitwiseOperators
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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] Objectively Quantifying Readability

[Matt Arcidy]

On Tue, May 1, 2018 at 5:35 PM, Mikhail V  wrote:

> to be pedantic - ReallyLongDescriptiveIdentifierNames
> has also an issue with "I" which might confuse because it
> looks same as little L. Just to illustrate that choice of
> comparison samples is very sensitive thing.
> In such a way an experienced guy can even scam
> the experimental subjects by making samples which
> will show what he wants in result.

I love this discussion, but I think anything that isn't included in a
.py file would have to be outside the scope, at least of the alpha
version :).  I am really interested in these factors in general,
however.  Now I'm surprised no one asks which font each other are
using when determining readability.

"serif?  are you mad?  no wonder!"
"+1 on PEP conditional on mandatory yellow (#FFEF00) keyword syntax
highlighting in vim"

-Matt

>
>
> Mikhail
> ___
> 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] Objectively Quantifying Readability

[Matt Arcidy]

On Tue, May 1, 2018 at 1:29 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Mon, Apr 30, 2018 at 8:46 PM, Matt Arcidy <marc...@gmail.com> wrote:
>> On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano <st...@pearwood.info> wrote:
>>> (If we know that, let's say, really_long_descriptive_identifier_names
>>> hurt readability, how does that help us judge whether adding a new kind
>>> of expression will hurt or help readability?)
>>
>> A new feature can remove symbols or add them.  It can increase density
>> on a line, or remove it.  It can be a policy of variable naming, or it
>> can specifically note that variable naming has no bearing on a new
>> feature.  This is not limited in application.  It's just scoring.
>> When anyone complains about readability, break out the scoring
>> criteria and assess how good the _comparative_ readability claim is:
>> 2 vs 10?  4 vs 5?  The arguments will no longer be singularly about
>> "readability," nor will the be about the question of single score for
>> a specific statement.  The comparative scores of applying the same
>> function over two inputs gives a relative difference.  This is what
>> measures do in the mathematical sense.
>
> Unfortunately, they kind of study they did here can't support this
> kind of argument at all; it's the wrong kind of design. (I'm totally
> in favor of being more evidence-based decisions about language design,
> but interpreting evidence is tricky!) Technically speaking, the issue
> is that this is an observational/correlational study, so you can't use
> it to infer causality. Or put another way: just because they found
> that unreadable code tended to have a high max variable length,
> doesn't mean that taking those variables and making them shorter would
> make the code more readable.
>
I think you are right about the study, but are tangential to what I am
trying to say.

I am not inferring causality when creating a measure.  In the most
tangible example, there is no inference that the euclidean measure
_creates_ a distance, or that _anything_ creates a distance at all, it
merely generates a number based on coordinates in space.  That
generation has specific properties which make it a measure, or a
metric, what have you.

The average/mean is another such object: a measure of central tendency
or location.  It does not infer causality, it is merely an algorithm
by which things can be compared.  Even misapplied, it provides a
consistent ranking of one mean higher than another in an objective
sense.

Even if not a single person agrees that line length is a correct
measure for an application, it is a measure.  I can feed two lines
into "len" and get consistent results out.   This result will be the
same value for all strings of length n, and for a string with length m
> n, the measure will always report a higher measured value for the
string of length m than the string of length n.   This is straight out
of measure theory, the results are a distance between the two objects,
not a reason why.

The same goes for unique symbols.  I can count the unique symbols in
two lines, and state which is higher.  This does not infer a
causality, nor do _which_ symbols matter in this example, only that I
can count them, and that if count_1 == count_2, the ranks are equal
aka no distance between them, and if count_1 > count_2, count 1 is
ranked higher.

The cause of complexity can be a number of things, but stating a bunch
of criteria to measure is not about inference.  Measuring the
temperature of a steak doesn't infer why people like it medium rare.
It just quantifies it.

> This sounds like a finicky technical complaint, but it's actually a
> *huge* issue in this kind of study. Maybe the reason long variable
> length was correlated with unreadability was that there was one
> project in their sample that had terrible style *and* super long
> variable names, so the two were correlated even though they might not
> otherwise be related. Maybe if you looked at Perl, then the worst
> coders would tend to be the ones who never ever used long variables
> names. Maybe long lines on their own are actually fine, but in this
> sample, the only people who used long lines were ones who didn't read
> the style guide, so their code is also less readable in other ways.
> (In fact they note that their features are highly correlated, so they
> can't tell which ones are driving the effect.) We just don't know.
>

Your points here are dead on.  It's not like a single metric will be
the deciding factor.  Nor will a single rank end all disagreements.
It's a tool.  Consider line length 79, that's an explicit statement
about readability, it's "hard coded" in the language.  Disagreement
with the value 79 or even the metric line-length doesn't mean i

Re: [Python-ideas] Objectively Quantifying Readability

[Matt Arcidy]

On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Mon, Apr 30, 2018 at 11:28:17AM -0700, Matt Arcidy wrote:
>
>> A study has been done regarding readability in code which may serve as
>> insight into this issue. Please see page 8, fig 9 for a nice chart of
>> the results, note the negative/positive coloring of the correlations,
>> grey/black respectively.
>
> Indeed. It seems that nearly nothing is positively correlated to
> increased readability, aside from comments, blank lines, and (very
> weakly) arithmetic operators. Everything else hurts readability.
>
> The conclusion here is that if you want readable source code, you should
> remove the source code. *wink*
>
>
>> https://web.eecs.umich.edu/~weimerw/p/weimer-tse2010-readability-preprint.pdf
>>
>> The criteria in the paper can be applied to assess an increase or
>> decrease in readability between current and proposed changes.  Perhaps
>> even an automated tool could be implemented based on agreed upon
>> criteria.
>
>
> That's a really nice study, and thank you for posting it. There are some
> interested observations here, e.g.:
>
> - line length is negatively correlated with readability;
>
>   (a point against those who insist that 79 character line
>   limits are irrelevant since we have wide screens now)
>
> - conventional measures of complexity do not correlate well
>   with readability;
>
> - length of identifiers was strongly negatively correlated
>   with readability: long, descriptive identifier names hurt
>   readability while short variable names appeared to make
>   no difference;
>
>   (going against the common wisdom that one character names
>   hurt readability -- maybe mathematicians got it right
>   after all?)
>
> - people are not good judges of readability;
>
> but I think the practical relevance here is very slim. Aside from
> questions about the validity of the study (it is only one study, can the
> results be replicated, do they generalise beyond the narrowly self-
> selected set of university students they tested?) I don't think that it
> gives us much guidance here. For example:

I don't propose to replicate correlations.  I don't see these
"standard" terminal conclusions as forgone when looking at the idea as
a whole, as opposed to the paper itself, which they may be.  The
authors crafted a method and used that method to do a study, I like
the method.  I think I can agree with your point about the study
without validating or invalidating the method.

>
> 1. The study is based on Java, not Python.

An objective measure can be created, based or not on the paper's
parameters, but it clearly would need to be adjusted to a specific
language, good point.

Here "objective" does not mean "with absolute correctness" but
"applied the same way such that a 5 is always a 5, and a 5 is always
greater than 4."  I think I unfortunately presented the paper as "The
Answer" in my initial email, but I didn't intend to say "each detail
must be implemented as is" but more like "this is a thing which can be
done."  Poor job on my part.

>
> 2. It looks at a set of pre-existing source code features.
>
> 3. It gives us little or no help in deciding whether new syntax will or
> won't affect readability: the problem of *extrapolation* remains.
>
> (If we know that, let's say, really_long_descriptive_identifier_names
> hurt readability, how does that help us judge whether adding a new kind
> of expression will hurt or help readability?)

A new feature can remove symbols or add them.  It can increase density
on a line, or remove it.  It can be a policy of variable naming, or it
can specifically note that variable naming has no bearing on a new
feature.  This is not limited in application.  It's just scoring.
When anyone complains about readability, break out the scoring
criteria and assess how good the _comparative_ readability claim is:
2 vs 10?  4 vs 5?  The arguments will no longer be singularly about
"readability," nor will the be about the question of single score for
a specific statement.  The comparative scores of applying the same
function over two inputs gives a relative difference.  This is what
measures do in the mathematical sense.

Maybe the "readability" debate then shifts to arguing criteria: "79?
Too long in your opinion!"  A measure will at least break
"readability" up and give some structure to that argument.  Right now
"readability" comes up and starts a semi-polite flame war.  Creating
_any_ criteria will help narrow the scope of the argument.

Even when someone writes perfectly logical statements about it, the
statements can always be dismantled because it's based in 

[Python-ideas] Objectively Quantifying Readability

[Matt Arcidy]

The number and type of arguments about readability as a justification,
or an opinion, or an opinion about an opinion seems counter-productive
to reaching conclusions efficiently.  I think they are very important
either way, but the justifications used are not rich enough in
information to be very useful.

A study has been done regarding readability in code which may serve as
insight into this issue. Please see page 8, fig 9 for a nice chart of
the results, note the negative/positive coloring of the correlations,
grey/black respectively.

https://web.eecs.umich.edu/~weimerw/p/weimer-tse2010-readability-preprint.pdf

The criteria in the paper can be applied to assess an increase or
decrease in readability between current and proposed changes.  Perhaps
even an automated tool could be implemented based on agreed upon
criteria.

Opinions about readability can be shifted from:
 - "Is it more or less readable?"
to
 - "This change exceeds a tolerance for levels of readability given
the scope of the change."

Still need to argue "exceeds ...given" and "tolerance", but at least
the readability score exists, and perhaps over time there will be
consensus.

Note this is an attempt to impact rhetoric in PEP (or other)
discussions, not about  supporting a particular PEP.  Please consider
this food for thought to increase the efficacy and efficiency of PEP
discussions, not as commenting on any specific current discussion,
which of course is the motivating factor of sending this email today.

I think using python implicitly accepts readability being partially
measurable, even if the resolution of current measure is too low to
capture the changes currently being discussed.  Perhaps using this
criteria can increase that resolution.

Thank you,
- Matt
___
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] Sublocal scoping at its simplest

[Matt Arcidy]

On Sat, Apr 28, 2018, 20:16 Chris Angelico  wrote:

> There's been a lot of talk about sublocal scopes, within and without
> the context of PEP 572. I'd like to propose what I believe is the
> simplest form of sublocal scopes, and use it to simplify one specific
> special case in Python.
>
> There are no syntactic changes, and only a very slight semantic change.
>
> def f():
> e = 2.71828
> try:
> 1/0
> except Exception as e:
> print(e)
> print(e)
> f()
>
> The current behaviour of the 'except... as' statement is as follows:
>
> 1) Bind the caught exception to the name 'e', replacing 2.71828
> 2) Execute the suite (printing "Division by zero")
> 3) Set e to None
> 4) Unbind e
>
> Consequently, the final print call raises UnboundLocalError. I propose
> to change the semantics as follows:
>
> 1) Bind the caught exception to a sublocal 'e'
> 2) Execute the suite, with the reference to 'e' seeing the sublocal
> 3) Set the sublocal e to None
> 4) Unbind the sublocal e
>
> At the unindent, the sublocal name will vanish, and the original 'e'
> will reappear. Thus the final print will display 2.71828, just as it
> would if no exception had been raised.
>
>
Does this mean indentation is now a scope, or colons are a scope, or is
that over simplifying?

either seems to be more consistent with the patterns set by class and
function defs, barring keywords.

not sure if relevant but curious.

I think with sublocal scope, reuse of a name makes more sense.  Currently,
if using sensible, descriptive names, it really doesn't make sense to go
from food = apple to food = car as the value between scopes, but it
happens.  And if from fruit = apple to fruit = orange (eg appending a msg
to a base string) it _could_ be nice to restore to apple once finished.

Obviously that's simple enough to do now, I am only illustrating my point.
I know bad code can be written with anything, this is not my point.  It can
be seen as enforcing that, what every nonsense someone writes like
fruit=car, there is at least some continuity of information represented by
the name... till they do it again once out of the sublocal scope of course.

as for the value of this use case, I do not know.


> The above definitions would become language-level specifications. For
> CPython specifically, my proposed implementation would be for the name
> 'e' to be renamed inside the block, creating a separate slot with the
> same name.
>
> With no debates about whether "expr as name" or "name := expr" or
> "local(name=expr)" is better, hopefully we can figure out whether
> sublocal scopes are themselves a useful feature :)
>
> 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] Descouraging the implicit string concatenation

[Matt Arcidy]

On Thu, Mar 15, 2018 at 8:58 PM, Rob Cliffe via Python-ideas
 wrote:
>
>
> On 14/03/2018 17:57, Chris Angelico wrote:
>
> On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård 
> wrote:
>
> Of course you can always make error, even in a single letter.
> But I think there is a big difference between mixing up +-/* and **
> where the operator is in "focus" and the implicit concatenation where
> there is no operator.
> A common problem is that you have something like
> foo(["a",
>  "b",
>  "c"
> ]).bar()
> but then you remember that there also needs to be a "d" so you just add
> foo(["a",
>  "b",
>  "c"
>  "d"
> ]).bar()
> Causing an error, not with the "d" expression you are working on but
> due to what you thought was the previous expression but python turns
> it into one.
> The , is seen as a delimiter by the programmer not as part of the
> operation (or the lack of the ,).
>
> You're creating a list. Put a comma at the end of every line; problem
> solved. Your edit would be from this:
>
> foo(["a",
> "b",
> "c",
> ]).bar()
>
> to this:
>
> foo(["a",
> "b",
> "c",
> "d",
> ]).bar()
>
> and there is no bug. In fact, EVERY time you lay out a list display
> vertically (or dict or set or any equivalent), ALWAYS put commas. That
> way, you can reorder the lines freely (you don't special-case the last
> one), you can append a line without changing the previous one (no
> noise in the diff), etc, etc, etc.
>
>
> My thoughts exactly.  I make it a personal rule to ALWAYS add a comma to
> every line, including the last one, in this kind of list (/dict/set etc.).
> Python allows it - take advantage of it!  (A perhaps minor-seeming feature
> of the language which actually is a big benefit if you use it.)  Preferably
> with all the commas vertically aligned to highlight the structure (I'm a
> great believer BTW in using vertical alignment, even if it means violating
> Python near-taboos such as more that one statement per line).  Also I would
> automatically put the first string (as well as the last) on a line by
> itself:
> foo([
> "short string"  ,
> "extremely long string" ,
> "some other string"   ,
> ])
> Then as Chris says (sorry to keep banging the drum), the lines can trivially
> be reordered, and adding more lines never causes a problem as long as I
> stick to the rule.  Which I do automatically because I think my code looks
> prettier that way.
>
> From a purist angle, implicit string concatenation is somewhat inelegant
> (where else in Python can you have two adjacent operands not separated by an
> operator/comma/whatever?  We don't use reverse Polish notation).  And I
> could live without it.  But I have found it useful from time to time:
> constructing SQL queries or error messages or other long strings that I
> needed for some reason, where triple quotes would be more awkward (and I
> find line continuation backslashes ugly, *especially* in mid-string).  I
> guess my attitude is: "If you want to read my Python code, 90%+ of the time
> it will be *obvious* that these strings are *meant* to be concatenated.  But
> if it isn't, then you need to learn some Python basics first (Sorry!).".
>
> I have never as far as I can remember had a bug caused by string
> concatenation.  However, it is possible that I am guilty of selective
> memory.
>
> +1, though, for linters to point out possible errors from possible
> accidental omission of a comma (if they don't already).  It never hurts to
> have our code checked.



The linters I know use parsed ast nodes, so if it's not valid grammar,
it won't parse.  The _linters_ don't check for cases like f(a b)
because that's not valid grammar and already caught by the parser.  I
think that's what you were noting when you said "if they don't
already"?

As for the issue in general,  this is my understanding of linters:

The code is loaded immediate into the ast parser.  There's a no
post-hoc way to know why the node is a string literal.  Specifically
the nodes for  "ab" and "a""b" are identical Str nodes.  Reversing
from the Str node is impossible (unless a
flag/attribute/context/whatever gets added), as the information is
destroyed by then.

The following might be possible:
1) The line number for a node n1 provides a way select the code
between nodes n1 and the next node n2,  which contains  the offending
string.  This code needs to be retrieved from somewhere (easily kept
from the beginning if not already)
2) A quick reparse of just that chunk will confirm that it contains
the target node, so the code retrieval for the target node can be
sanity checked (it's not exact retrieval of just the code we want,
it's guaranteed to overshoot as resolution is on line numbers.)
3) ? (note below)
4) A quick check shows the tokenizer can differentiate the styles of
literal.   It gives 2 STRING for 

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

[Matt Arcidy]

if Linux kernel can handle it, there is no argument for it being factually
superior or inferior.  It is only preference.

There is nothing stopping a forum link being created and posted to the list
as an alternative right now.

The result of that experiment would be the answer.

On Wed, Feb 28, 2018, 14:14 Oleg Broytman  wrote:

> The topic has been discussed to death with all possible pros and cons.
> I've published my personal collection of pros and cons at
> http://phdru.name/Software/mail-vs-web.html
>
>And my personal bottom line is: I still prefer mailing lists but I
> know their advantages and disadvantages and I've invested a lot of
> resources to learn and configure my tools.
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> 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 572: Statement-Local Name Bindings

[Matt Arcidy]

-0 unless archived appropriately.  List is the standard for decades.  but I
guess things change and I get old.

On Wed, Feb 28, 2018, 13:49 Robert Vanden Eynde 
wrote:

> We are currently like a dozen of people talking about multiple sections of
> a single subject.
>
> Isn't it easier to talk on a forum?
> *Am I the only one* who thinks mailing list isn't easy when lots of
> people talking about multiple subjects?
>
> Of course we would put the link in the mailing list so that everyone can
> join.
>
> A forum (or just few "issues" thread on github) is where we could have
> different thread in parallel, in my messages I end up with like *10
> comments not all related*, in a forum we could talk about everything and
> it would still be organized by subjects.
>
> Also, it's more interactive than email on a global list, people can talk
> to each other in parallel, if I want to answer about a mail that was 10
> mail ago, it gets quickly messy.
>
> We could all discuss on a gist or some "Issues" thread on GitHub.
>
> 2018-02-28 22:38 GMT+01:00 Robert Vanden Eynde :
>
>> Le 28 févr. 2018 11:43, "Chris Angelico"  a écrit :
>>
>> > It's still right-to-left, which is as bad as middle-outward once you
>> > combine it with normal left-to-right evaluation. Python has very
>> > little of this [..]
>>
>> I agree []
>>
>> >> 2) talking about the implementation of thektulu in the "where =" part.
>>
>> > ?
>>
>> In the Alternate Syntax, I was talking about adding a link to the thektulu
>> (branch where-expr)
>> 
>> implementation as a basis of proof of concept (as you did with the other
>> syntax).
>>
>> >> 3) "C problem that an equals sign in an expression can now create a
>> name inding, rather than performing a comparison."
>>
>> As you agreed, with the "ch with ch = getch()" syntax we won't
>> accidentally switch a "==" for a "=".
>>
>> I agree this syntax :
>>
>> ```
>> while (ch with ch = getch()):
>> ...
>> ```
>>
>> doesn't read very well, but in the same way as in C or Java while(ch =
>> getch()){} or worse ((ch = getch()) != null) syntax.
>> Your syntax "while (getch() as ch):" may have a less words, but is still
>> not clearer.
>>
>> As we spoke on Github, having this syntax in a while is only useful if
>> the variable does leak.
>>
>> >> 5) Any expression vs "post for" only
>>
>> > I don't know what the benefit is here, but sure. As long as the
>> > grammar is unambiguous, I don't see any particular reason to reject
>> > this.
>>
>> I would like to see a discussion of pros and cons, some might think like
>> me or disagree, that's a strong langage question.
>>
>> > 6) with your syntax, how does the simple case work (y+2 with y = x+1) ?
>>
>> What simple case? The case where you only use the variable once? I'd
>> write it like this:
>>
>> (x + 1) + 2
>>
>> >> The issue is not only about reusing variable.
>>
>> > If you aren't using the variable multiple times, there's no point
>> > giving it a name. Unless I'm missing something here?
>>
>> Yes, variables are not there "just because we reuse them", but also to
>> include temporary variables to better understand the code.
>> Same for functions, you could inline functions when used only once, but
>> you introduce them for clarity no ?
>>
>> ```
>> a = v ** 2 / R # the acceleration in a circular motion
>> f = m * a # law of Newton
>> ```
>>
>> could be written as
>>
>> ```
>> f = m * (v ** 2 / R) # compute the force, trivial
>> ```
>>
>> But having temporary variables help a lot to understand the code,
>> otherwise why would we create temporary variables ?
>> I can give you an example where you do a process and each time the
>> variable is used only one.
>>
>> >> 8)
>> >>  (lambda y: [y, y])(x+1)
>> >> Vs
>> >> (lambda y: [y, y])(y=x+1)
>>
>> Ewww. Remind me what the benefit is of writing the variable name that
>> many times? "Explicit" doesn't mean "utterly verbose".
>>
>> Yep it's verbose, lambdas are verbose, that's why we created this PEP
>> isn't it :)
>>
>> > 10) Chaining, in the case of the "with =", in thektulu, parenthesis were
>> > mandatory:
>> >
>> > print((z+3 with z = y+2) with y = x+2)
>> >
>> > What happens when the parenthesis are dropped ?
>> >
>> > print(z+3 with y = x+2 with z = y+2)
>> >
>> > Vs
>> >
>> > print(z+3 with y = x+2 with z = y+2)
>> >
>> > I prefer the first one be cause it's in the same order as the "post for"
>> >
>> > [z + 3 for y in [ x+2 ] for z in [ y+2 ]]
>>
>> > With my proposal, the parens are simply mandatory. Extending this to
>> > make them optional can come later.
>>
>> Indeed, but that's still questions that can be asked.
>>
>> >> 11) Scoping, in the case of the "with =" syntax, I think the
>> parenthesis
>> >> introduce a scope :
>> >>
>> >> print(y + (y+1 where y = 2))
>> >>
>> >> Would raise a SyntaxError, it's probably better for the variable beeing
>> >> local and not in the current function 

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Matt Arcidy]

I appreciate that point as it is what I must be misunderstanding.

I believe the performance speed up of [((f(x) as h), g(h)) for x
range(10)] is that there are 10 calls to compute f, not 20.

You can do this with a dictionary right now, at least for the example
we're talking about:
[(d[x], g(d[x])) for x in range(10) if d.update({x:f(x)}) is None]

It's ugly but get's the job done.  The proposed syntax is leagues
better than that, but just to give my point a concrete example.

If f is memoized, isn't [( f(x), g(f(x)) ) for range(10)] the same?
You compute f 10 times, not 20.  You get the second f(x) as cache
retrieval instead of recomputing it, precisely because the argument x
is the same.

Here I can use 'd' later if needed, as opposed to with the proposal.
That's really my point about memoization (or cacheing).  If 'f' is
really expensive, I don't really see the point of using an ad-hoc
local caching of the value that lives just for one statement when I
could use it where-ever, even persist it if it makes sense.

I fully admit I'm at my depth here, so I can comfortably concede it's
better than memoization and I just don't understand!

On Wed, Feb 28, 2018 at 12:37 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Feb 28, 2018 at 6:46 PM, Matt Arcidy <marc...@gmail.com> wrote:
>> I have been struggling to justify the need based on what I have read.  I
>> hope this isn't a dupe, I only saw caching mentioned in passing.
>>
>> Also please excuse some of the naive generalizations below for illustrative
>> purposes.
>>
>> Is there a reason memoization doesn't work? If f is truly expensive, using
>> this syntax only makes sense if you have few comprehensions (as opposed to
>> many iterations) and few other calls to f. Calling f in 10 comprehensions
>> would (naively) benefit from memoization more than this.  It appears to me
>> to be ad-hoc memoization with limited scope.  is this a fair statement?
>
> Memoization is only an option if the expression in question is (a) a
> single cacheable function call, and (b) used twice without any
> variation. If it's any sort of more complicated expression, that
> concept doesn't work.
>
> 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] PEP 572: Statement-Local Name Bindings

[Matt Arcidy]

I have been struggling to justify the need based on what I have read.  I
hope this isn't a dupe, I only saw caching mentioned in passing.

Also please excuse some of the naive generalizations below for illustrative
purposes.

Is there a reason memoization doesn't work? If f is truly expensive, using
this syntax only makes sense if you have few comprehensions (as opposed to
many iterations) and few other calls to f. Calling f in 10 comprehensions
would (naively) benefit from memoization more than this.  It appears to me
to be ad-hoc memoization with limited scope.  is this a fair statement?

>From readability, the examples put forth have been to explain the
advantage, with which I agree.  However, i do not believe this scales well.

[(foo(x,y) as g)*(bar(y) as i) + g*foo(x,a) +baz(g,i) for x... for y...]

That's 3 functions, 2 iterators, 3 calls saved ('a' is some constant just
to trigger a new call on foo).  I'm not trying to show ugly statements can
be constructed, but show how quickly in _n iterators and _m functions
readability declines.

it's seems the utility is bounded by f being not complex/costly enough for
memoization, and ( _m, _n) being small enough to pass code review. The
syntax does not create a readability issue, but by adding symbols,
exacerbates an inherent issue with 'complex' comprehensions.

If I have understood, does this bounding on f, _m, and _n yield a tool with
sufficient applicability for a language change?   I know it's already
spoken about as an edge case, I'm just not clear on the bounds of that.  I
am not against it, I just haven't seen this addressed.

Thank you for putting the PEP together.  Again, I don't want to sound
negative on it, I may have misunderstood wildly.  I like the idea
conceptually, and I don't think it's anymore confusing to me than
comprehensions were when I first encountered them, and it will yield a
'cool!' statement much like they did when I learned them.


On Tue, Feb 27, 2018, 22:55 Gregory P. Smith  wrote:

>
> On Tue, Feb 27, 2018 at 2:35 PM Chris Angelico  wrote:
>
>> This is a suggestion that comes up periodically here or on python-dev.
>> This proposal introduces a way to bind a temporary name to the value
>> of an expression, which can then be used elsewhere in the current
>> statement.
>>
>> The nicely-rendered version will be visible here shortly:
>>
>> https://www.python.org/dev/peps/pep-0572/
>>
>> ChrisA
>>
>> PEP: 572
>> Title: Syntax for Statement-Local Name Bindings
>> Author: Chris Angelico 
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 28-Feb-2018
>> Python-Version: 3.8
>> Post-History: 28-Feb-2018
>>
>>
>> Abstract
>> 
>>
>> Programming is all about reusing code rather than duplicating it.  When
>> an expression needs to be used twice in quick succession but never again,
>> it is convenient to assign it to a temporary name with very small scope.
>> By permitting name bindings to exist within a single statement only, we
>> make this both convenient and safe against collisions.
>>
>>
>> Rationale
>> =
>>
>> When an expression is used multiple times in a list comprehension, there
>> are currently several suboptimal ways to spell this, and no truly good
>> ways. A statement-local name allows any expression to be temporarily
>> captured and then used multiple times.
>>
>>
>> Syntax and semantics
>> 
>>
>> In any context where arbitrary Python expressions can be used, a named
>> expression can appear. This must be parenthesized for clarity, and is of
>> the form `(expr as NAME)` where `expr` is any valid Python expression,
>> and `NAME` is a simple name.
>>
>> The value of such a named expression is the same as the incorporated
>> expression, with the additional side-effect that NAME is bound to that
>> value for the remainder of the current statement.
>>
>> Just as function-local names shadow global names for the scope of the
>> function, statement-local names shadow other names for that statement.
>> They can also shadow each other, though actually doing this should be
>> strongly discouraged in style guides.
>>
>>
>> Example usage
>> =
>>
>> These list comprehensions are all approximately equivalent::
>>
>> # Calling the function twice
>> stuff = [[f(x), f(x)] for x in range(5)]
>>
>> # Helper function
>> def pair(value): return [value, value]
>> stuff = [pair(f(x)) for x in range(5)]
>>
>> # Inline helper function
>> stuff = [(lambda v: [v,v])(f(x)) for x in range(5)]
>>
>> # Extra 'for' loop - see also Serhiy's optimization
>> stuff = [[y, y] for x in range(5) for y in [f(x)]]
>>
>> # Expanding the comprehension into a loop
>> stuff = []
>> for x in range(5):
>> y = f(x)
>> stuff.append([y, y])
>>
>> # Using a statement-local name
>> stuff = [[(f(x) as y), y] for x in range(5)]
>>
>> If calling `f(x)` is expensive or has side effects, the