Re: [Python-ideas] Does jargon make learning more difficult?

[Stephen J. Turnbull]

Rhodri James writes:
 > On 18/08/18 01:59, Abe Dillon wrote:
 > > The argument I tried to make is, "yes I believe there are cases where a
 > > less jargon identifier is preferable and that I believe 'lambda' is an
 > > example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
 > > better word here?), more descriptive name."
 > 
 > While I don't entirely disagree with you, if I had been responsible for 
 > inventing that bit of Python I would probably have gone with "lambda" 
 > too.  It had been part of my vocabulary as a computer scientist long 
 > before I met it in a programming language.

I was an economist then, and I'm an economist still, but I met lambda
in 1977.  Surely lambda has had that role in computer languages since
shortly before I was born.  I would guess anybody above a certain age
would reach for "lambda" first for a keyword to denote or define an
anonymous function.  Not because of the lambda calculus, but because
of Lisp.  (OK, that's indirectly because of the lambda calculus.)

Had Guido decided to change it to "def", I suspect he'd be regretting
it slightly today, for reasons similar to the regrets about "range":
we normally only allow omitting positional arguments at the end of the
list.  Maybe there's a better word than "regret".  After all, It's
hard to see how you could prototype range better than "range([START,]
END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
...):".

___
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] Off topic: 'strike a balance' - second language English

[Terry Reedy]

On 8/20/2018 5:13 PM, Barry Scott wrote:



On 20 Aug 2018, at 17:07, Chris Barker via Python-ideas 
> wrote:


> Summary: I look at the phrase 'strike a balance' in different languages, 


It is interesting that you picked up on "strike a balance" which has
been a standard English phrase for a very long time rather than
the much
more resent, (and itself a form of jargon), "dumbing down".

The other point is that the use of Jargon is often as a form of
shorthand so as to avoid excessive verbosity, (or long windedness).


We are (maybe) mingling two issues here --  there is an important 
distinction between idiomatic expressions ("striking a balance", 
"dumbing down") and technical terms (jargon).


If you want to make it easier for non-native english speakers to 
understand -- minimal use of idiomatic expressions is a good idea. 
They really don't serve much real purpose, other than making the prose 
more colorful and friendly (to those that understand it). Sometimes a 
bit of brevity is gained, but not much.


The technical writing course I went on as an engineer years ago 
recommenced "Controlled English" in documentation.
Its good for none english speakers and the lack of colloquial expression 
means English speaks are not miss lead.


As you say this is nothing to do with jargon.



Technical jargon, on the other hand, can be very helpful for precision 
and compactness. 


It also means you will understand other people doing the same activity. 
Be they musicians or programmers.




(side note -- are all domain-specific technical term "jargon"? I tend 
to see "jargon" as having a negative connotation -- specifically that 
it isn't required for technical specificity. That is, "jargon" is 
language that is unnecessarily domain specific)


I found this definition:

"J/argon/. A special language belonging exclusively to a group, often a 
profession. Engineers, lawyers, doctors, tax analysts, and the like all 
use /jargon/ to exchange complex information efficiently.

/Jargon/ is often unintelligible to those outside the group that uses it."


To me, 'jargon' refers more to in-group replacements for common words 
(slang) than to technical terms.  'Hack the bug' for 'Fix the program 
error' is an example of the former.  'Use a coroutine' uses a technical 
term that needs several sentences and some preliminary knowledge about 
functions to explain.


In any case, docs should avoid slangy jargon and explain technical terms.


Not all group members remember to avoid jargon > when talking to people
outside the group.
If you are on the outside looking in at the people that will not explain 
in plain english you could well consider jargon as a bad thing.




I think it's pretty important to use the common domain specific terms 
in introductory texts -- how else will folks learn them? So I make a 
distinction between *using* a technical term, and *introducing* a 
technical term.


Yes.


--
Terry Jan Reedy


___
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] Asynchronous friendly iterables

[Terry Reedy]

On 8/20/2018 3:19 AM, Simon De Greve wrote:

Hello everyone,

I'm quite new working with asyncio and thus maybe missing some things 
about it, but wouldn't it be quite easier to have some iterables to 
support async for loops "natively", since asyncio is now part of the 
Stdlib?


One purpose of asynchronous programming is to pause a task that is 
waiting for input from an external system, so as to not waste CPU time. 
As other noted, this is not an issue with iterating through in-memory 
collections.


It is worth noting that 'async' and 'await' are syntax keywords for 
working with coroutines (how is underdocumented) and that the asyncio 
module is just one event-loop system that can drive coroutines.  The 
tkinter module, over 20 years old, can also.


I've tried to work with asyncio while using discord.py, and has some 
struggle with an "async for" loop on a dictionary, so I had to implement 
a new dict subclass that would just reimplement items(), keys() and 
values() functions.


Another purpose of asynchonous programming is to keep a system 
responsive, for instance, to user input by not letting a compute-bound 
task tie-up a cpu indefinitely.  This issue *can* apply to iterating 
through sufficiently large collection in, for instance, a tkinter gui 
program.  But pausing iteration after *each* iteration is usually a 
terrible waste of overhead.  So one wants to do some number of 
iterations at full speed and then pause to allow other events to be handled.


I think that it would be a cool improvement to implement some of those 
in some standard way. 
Occasionally pausing iteration should not be a method of the iterable or 
iterator.  We need instead wrapper functions.  One idea is to pause 
every k iterations.  For user responsiveness, we want to pause for event 
handling after a certain time has elapsed, say 50 milliseconds.  I think 
it should be possible to do this directly instead of pre-testing how 
long it takes to do 1 interation.


I know how to do the above with tkinter callback loops, but I have not 
yet worked out how to do so with async def coroutines.


--
Terry Jan Reedy

___
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] Pre-conditions and post-conditions

[Wes Turner]

pycontracts may be worth a look.

https://andreacensi.github.io/contracts/

- @contract decorator, annotations, docstrings

IDK if pycontracts supports runtime parameter validations that involve more
than one parameter.

Inheritance does appear to be supported,
as are numpy array dimension constraints.

I can't recall whether the pycontracts expression language precedes MyPy
compile-time annotations; both with one syntax really would be great.

On Monday, August 20, 2018, Daniel Moisset  wrote:

> I think that annotations were suggested because you could write an
> expression there without getting evaluated.
>
> I've thought about this problem many times in the past (as a Python dev
> with a long history working in Eiffel too) For me one of the crucial
> issue that is hard to translate into the python model is that the
> assertions (say, a function precondition) are not conceptually part of the
> function itself, but the interface of the class. The "natural" python ways
> of attaching these assertions somehow to the function object do not work
> when you also use inheritance, because when you override a method the new
> function object clobbers the previous one. I've experimented at some point
> on how to put them in classes (and doing metaclass or __getattribute__
> tricks) but nothing convinced me). In general, the way that python puts
> method call and inheritance semantic in a specific layout of runtime
> objects (which in general is really clever) seems to be a bit alien to the
> DbC idea where the asbtraction/interface of the class is conceptually
> separate and has independent information wrt to the runtime objects.
>
>
> On 16 August 2018 at 18:49, Marko Ristin-Kaufmann 
> wrote:
>
>> Hi Jonathan and Paul,
>> Thank you very much for your suggestions! I will try to contact the
>> author of the PEP.
>>
>> Let me clarify a bit a potential misunderstanding. Please mind that
>> contracts are not tied to individual variables, but to expressions. Think
>> of it as defining a lambda which takes as input all the arguments of the
>> function (and a result variable in case of post-conditions) which always
>> needs to evaluate to True.
>>
>> Cheers,
>> Marko
>>
>> Le jeu. 16 août 2018 à 12:24, Paul Moore  a écrit :
>>
>>> On Thu, 16 Aug 2018 at 10:41, Jonathan Fine  wrote:
>>> >
>>> > Hi Marko
>>> >
>>> > Thank you for introducing yourself, and clearly stating your question.
>>> > That helps us all. You asked:
>>> >
>>> > > Could somebody update me on the state of the discussion on this
>>> matter?
>>> >
>>> > I think bring the existing PEP up to date would be a good starting
>>> > point. Its content hasn't been changed since 2003 (except for PEP-wide
>>> > admin changes. (Recall that Python 3.0 was released in 2008.)
>>> >
>>> > https://www.python.org/dev/peps/pep-0316/
>>> > https://github.com/python/peps/commits/master/pep-0316.txt
>>> >
>>> > In fact, revising the PEP might be enough to answer your question.
>>> > What do you think, Marko?
>>> >
>>> > Experts: is there a process for revising old PEPs, such as this one?
>>> > Or at least a precedent we could follow (or adapt)?
>>>
>>> I'm not aware of a formal process, but I'd have thought the following
>>> steps would be a reasonable approach:
>>>
>>> 1. Review the PEP, and research the discussions that happened at the
>>> time, particularly of interest is why the PEP was deferred.
>>> 2. Consider what (if anything) has changed since the original deferral
>>> (which could simply be "time has moved on, people's views may have
>>> changed" but ideally would include a bit more in the way of concrete
>>> motivation).
>>> 3. Contact the original PEP author and ask if he is interested in
>>> reopening the discussion, collaborating on a revision, or handing the
>>> PEP over.
>>> 4. Start up a discussion here, pointing out the original PEP and
>>> summarising the previous debate and why you want to restart the
>>> discussion. If you're hoping to change the details of the original
>>> PEP, summarise your changes and why you feel they are an improvement
>>> over the original.
>>>
>>> To answer the OP's question more directly:
>>>
>>> > Could somebody update me on the state of the discussion on this matter?
>>>
>>> As far as I am aware, there has been no discussion on this subject
>>> since the PEP 316 discussions which ended up in its deferral. Elazar
>>> mentioned PEP 563, and there *may* have been mention of design by
>>> contract uses in the discussions on that PEP, but you'd have to search
>>> the mailing list archives to confirm that one way or another.
>>>
>>> Hence the suggestions that if you want to restart discussion, reviving
>>> PEP 316 is likely the best approach.
>>>
>>> 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/
>>>
>>
>> 

Re: [Python-ideas] Off topic: 'strike a balance' - second language English

[Steven D'Aprano]

On Mon, Aug 20, 2018 at 09:07:20AM -0700, Chris Barker via Python-ideas wrote:

> (side note -- are all domain-specific technical term "jargon"?

Yes. But not all jargon is a domain-specific technical term.

https://en.wiktionary.org/wiki/jargon




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

Re: [Python-ideas] Off topic: 'strike a balance' - second language English

[Barry Scott]

> On 20 Aug 2018, at 17:07, Chris Barker via Python-ideas 
>  wrote:
> 
> > Summary: I look at the phrase 'strike a balance' in different languages, 
> 
> It is interesting that you picked up on "strike a balance" which has 
> been a standard English phrase for a very long time rather than the much 
> more resent, (and itself a form of jargon), "dumbing down".
> 
> The other point is that the use of Jargon is often as a form of 
> shorthand so as to avoid excessive verbosity, (or long windedness).
> 
> We are (maybe) mingling two issues here --  there is an important distinction 
> between idiomatic expressions ("striking a balance", "dumbing down") and 
> technical terms (jargon).
> 
> If you want to make it easier for non-native english speakers to understand 
> -- minimal use of idiomatic expressions is a good idea. They really don't 
> serve much real purpose, other than making the prose more colorful and 
> friendly (to those that understand it). Sometimes a bit of brevity is gained, 
> but not much.

The technical writing course I went on as an engineer years ago recommenced 
"Controlled English" in documentation.
Its good for none english speakers and the lack of colloquial expression means 
English speaks are not miss lead.

As you say this is nothing to do with jargon.

> 
> Technical jargon, on the other hand, can be very helpful for precision and 
> compactness. 

It also means you will understand other people doing the same activity. Be they 
musicians or programmers.

> 
> (side note -- are all domain-specific technical term "jargon"? I tend to see 
> "jargon" as having a negative connotation -- specifically that it isn't 
> required for technical specificity. That is, "jargon" is language that is 
> unnecessarily domain specific)

I found this definition:

"Jargon. A special language belonging exclusively to a group, often a 
profession. Engineers, lawyers, doctors, tax analysts, and the like all use 
jargon to exchange complex information efficiently.
Jargon is often unintelligible to those outside the group that uses it."

Not all group members remember to avoid jargon when talking to people outside 
the group.
If you are on the outside looking in at the people that will not explain in 
plain english you could well consider jargon as a bad thing.

> 
> I think it's pretty important to use the common domain specific terms in 
> introductory texts -- how else will folks learn them? So I make a distinction 
> between *using* a technical term, and *introducing* a technical term.

Yes.

> 
> In fact, in my PR on Jonathan's doc on None, I deliberately introduced the 
> term "Singleton" -- not because it was necessary to understand the idea at 
> hand, but because people are likely to encounter the term elsewhere.


Barry

> 
> -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] Off topic: 'strike a balance' - second language English

[Barry]

> On 20 Aug 2018, at 07:35, Jacco van Dorp  wrote:
> 
> I would consider conciseness and accuracy most important. Using jargon but 
> linking to accurate explanations would, in my not exactly humble opinion, be 
> the best way to go about it.

+1 my thoughts exactly.


> ___
> 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] Jump to function as an an alternative to call function

[Rhodri James]

On 20/08/18 17:16, Chris Barker via Python-ideas wrote:

On Mon, Aug 20, 2018 at 7:21 AM, Steven D'Aprano
wrote:


* Introducing a warning makes it clear that this is not a de facto
   language standard, but a mere implementation detail subject to
   change if somebody comes up with a better optimization for locals.


defacto standards are sub-optimum -- the docs say "may not" -- that seems
really sketchy to me.


On the contrary, it is well defined in international standards usage. 
"May" and "may not" indicate that behaviour is optional, so shouldn't be 
relied on.


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

Re: [Python-ideas] Jump to function as an an alternative to call function

[Chris Angelico]

On Tue, Aug 21, 2018 at 2:16 AM, Chris Barker via Python-ideas
 wrote:
> On Mon, Aug 20, 2018 at 7:21 AM, Steven D'Aprano 
> wrote:
>>
>> * Introducing a warning makes it clear that this is not a de facto
>>   language standard, but a mere implementation detail subject to
>>   change if somebody comes up with a better optimization for locals.
>
>
> defacto standards are sub-optimum -- the docs say "may not" -- that seems
> really sketchy to me.
>
> Even if there is no change to the implementation of cPython, I'd like to see
> the behavior clearly defined -- if I pass a object returned by "locals()" to
> a function, and that function modifies that object -- will, or will not, the
> local namespace be altered? Saying it "may" be altered is kind of crazy!
> Does that mean the same code will have a different effect if run in two
> different (compliant) implementations of Python? That sure seems like a bad
> idea...

If you do the wrong thing, a compliant Python is allowed to do one of
two things. It's no different from anything else that's been defined
as the wrong thing - opening a file and then dropping it on the floor
(might close it promptly, might not), testing integers by identity ("x
is 5"), etc, etc. The language is well-enough-defined that you can be
confident that locals()["x"]=1 will EITHER change x to 1 OR have no
significant effect.

If you truly want to mandate that every Python implementation
absolutely perfectly imitate CPython, what is the point of other
implementations? Or a language spec? They'd just be refactorings of
CPython.

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/

Re: [Python-ideas] Does jargon make learning more difficult?

[Abe Dillon]

Responding out of order.

[Rhodri James]

> > For instance: when the iPhone was introduced, a lot of people praised
> > it's subjectively "slick" user interface. I believe that perception of
> > slickness is partly because the iPhone emulated physical interfaces
> > very well so it leveraged people's intuition about the physical world.
> > It was delightfully intuitive.
> One of the things Apple have always been very good at is thinking hard
> about user interfaces.  What made the iPhone so good was that they emulated
> the right physical interfaces, so flipping a page when you're reading
> rather than pressing a button.


Yes, that's exactly what I was trying to say. An important point that I
think keeps getting lost in this conversation is that Python's grammar,
syntax, and standard lib are it's user interface. There are very different
constraints on Python's UI than there are when humans have to communicate
directly with other humans. I have no problem using words like "closure" or
"lambda expression" or "ternary expression" when communicating with other
humans about programming language features, but jargon doesn't often make
sense as part of Python's UI itself. Again, we don't use the word "ternary"
in Python's ternary expressions.

[Rhodri James]

> Jargon becomes jargon because it's useful to enough people, for
> occasionally rather odd definitions of "useful".  In the case of lambda,
> it's shorter than "inline function definition"


Yes, again: I understand the utility of jargon. I don't think "anonymous
function" would be an improvement over "lambda" because, while it is fairly
descriptive, it sacrifices too much brevity. However; the word "anonymous"
is redundant. You can tell the function is anonymous by virtue of the fact
that it doesn't have a name. "function" is only two characters longer than
"lambda" and is actually descriptive, but it probably would have caused
backwards compatibility issues (same with "func" or "fun"). "def" would
have been even shorter than "lambda".

[Rhodri James]

> and lambda calculus at least shows up on most CompSci courses.


I suppose if by "courses" you mean "course plans", I highly doubt that the
majority of CS classes cover lambda calc, though; I couldn't say for sure
because I, like many programmers, didn't take CS in college. There are many
disciplines that get by on basic algorithms, data-structures, and a pinch
of theory.

[Rhodri James]

> Once it settles into a group, you use it because other members of the
> group will understand what you mean and might not understand if you
> rephrase it.


If the group you're referring to are Computer Scientists, then I don't see
why they would be confused by a syntax that omits the word "lambda" since very
few languages use the word "lambda" to denote a lambda expression.

[Rhodri James]

> While I don't entirely disagree with you, if I had been responsible for
> inventing that bit of Python I would probably have gone with "lambda" too.
> It had been part of my vocabulary as a computer scientist long before I met
> it in a programming language.  Whether it's a *good* choice or not...
> possibly reusing "def" would fit people's expectations better, or perhaps
> it would have caused more confusion.  Who can tell?


I don't see how "def" could cause more confusion than "lambda". Those who
don't know what "lambda" refers to would at least have some notion of what
"def" means, and those who have studied and know what lambda calculus is
should also have very little trouble. I don't expect it would confuse
someone well versed in computer science any more than a check-engine light
would throw off an expert mechanic. They can at least google "python
anonymous function" or "python lambda expression" and get results that tell
you how to write a lambda expression in Python.
___
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] Jump to function as an an alternative to call function

[Chris Barker via Python-ideas]

On Mon, Aug 20, 2018 at 7:21 AM, Steven D'Aprano 
wrote:

> * Introducing a warning makes it clear that this is not a de facto
>   language standard, but a mere implementation detail subject to
>   change if somebody comes up with a better optimization for locals.
>

defacto standards are sub-optimum -- the docs say "may not" -- that seems
really sketchy to me.

Even if there is no change to the implementation of cPython, I'd like to
see the behavior clearly defined -- if I pass a object returned by
"locals()" to a function, and that function modifies that object -- will,
or will not, the local namespace be altered? Saying it "may" be altered is
kind of crazy! Does that mean the same code will have a different effect if
run in two different (compliant) implementations of Python? That sure seems
like a bad idea...


> more so, I do not believe that anyone will rely or use such a feature.
>

well, this thread exists because someone wanted to do something like that
-- i.e. manipulate the calling namespace from within a function. I
suggested that passing locals() in might work -- it didn't work (in
cPython), but if it HAD worked in whatever implementation the OP is using,
then, yes, someone would now be relying on that feature.

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

Re: [Python-ideas] Off topic: 'strike a balance' - second language English

[Chris Barker via Python-ideas]

>
> > Summary: I look at the phrase 'strike a balance' in different languages,
>
> It is interesting that you picked up on "strike a balance" which has
> been a standard English phrase for a very long time rather than the much
> more resent, (and itself a form of jargon), "dumbing down".
>
> The other point is that the use of Jargon is often as a form of
> shorthand so as to avoid excessive verbosity, (or long windedness).
>

We are (maybe) mingling two issues here --  there is an important
distinction between idiomatic expressions ("striking a balance", "dumbing
down") and technical terms (jargon).

If you want to make it easier for non-native english speakers to understand
-- minimal use of idiomatic expressions is a good idea. They really don't
serve much real purpose, other than making the prose more colorful and
friendly (to those that understand it). Sometimes a bit of brevity is
gained, but not much.

Technical jargon, on the other hand, can be very helpful for precision and
compactness.

(side note -- are all domain-specific technical term "jargon"? I tend to
see "jargon" as having a negative connotation -- specifically that it isn't
required for technical specificity. That is, "jargon" is language that is
unnecessarily domain specific)

I think it's pretty important to use the common domain specific terms in
introductory texts -- how else will folks learn them? So I make a
distinction between *using* a technical term, and *introducing* a technical
term.

In fact, in my PR on Jonathan's doc on None, I deliberately introduced the
term "Singleton" -- not because it was necessary to understand the idea at
hand, but because people are likely to encounter the term elsewhere.

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

Re: [Python-ideas] Asynchronous friendly iterables

[Simon De Greve]

Ok, as I thought I was missing something quite important in the process.

Thanks to everybody in here.

Le lun. 20 août 2018 à 15:53, Joao S. O. Bueno  a
écrit :

> On Mon, 20 Aug 2018 at 04:49, Chris Angelico  wrote:
> >
> > On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve 
> wrote:
> > > Do you mean that for loops inside an "async def" statements are always
> > > executed as 'async for' loops? That's what I wanted to acheive by
> writing
> > > the AsyncDict class (c.f. the CodeReview link).
> >
> > The point of an 'async for' loop is that grabbing the next value can
> > block the async function - it's a yield point. If you don't need that,
> > you can use a regular 'for' loop.
>
> Maybe it is worth to further clarify that iterating on dicts and lists
> is _not_ blocking at all.
> That would only be the case if to retrieve its own keys the dictionary
> would have
> to perform some I/O access or heavy computation - which, besides been of
> very
> little value in practice, would only be possible in a specialized class
> anyway.
>
>
> >
> > 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/
>
___
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] Jump to function as an an alternative to call function

[Jonathan Fine]

Hi

I've created new thread
===
Documentation of locals()
https://mail.python.org/pipermail/python-ideas/2018-August/052843.html

Summary: There's prior art in bug.python.org relating to off-thread
topic discussion of locals(). Suggest work on closing open
documentation issues relating to locals().

[...]

I suggest that those that have time, energy and interest focus on
closing the open locals() documentation issues. Such documentation
would, I think, provide an excellent starting point for any proposals
to change behaviour. There are 13 open issues with 'locals' in the
title.
===

Perhaps the discussion of locals() here could be moved to the new thread.

-- 
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] Documentation of locals()

[Jonathan Fine]

Summary: There's prior art in bug.python.org relating to off-thread
topic discussion of locals(). Suggest work on closing open
documentation issues relating to locals().

In the thread
===
Jump to function as an an alternative to call function
https://mail.python.org/pipermail/python-ideas/2018-August/052761.html
===
there was post
===
https://mail.python.org/pipermail/python-ideas/2018-August/052807.html
I wonder why locals doesn't return a Mapping Proxy, or other read-only
mapping object?
===
and a discussion resulted.

There's prior art on bugs.python.org, which can be found by searching
for 'locals()' in the issue title. (Search for 'locals' gives more
results.) One of the items is (created 2013 and still open):
===
Documentation of globals() and locals() should be improved
https://bugs.python.org/issue19737
===

In this issue Terry Read writes
===
https://bugs.python.org/msg204769
In my opinion, vague ideas like this one should go to python-ideas first.
===

I suggest that those that have time, energy and interest focus on
closing the open locals() documentation issues. Such documentation
would, I think, provide an excellent starting point for any proposals
to change behaviour. There are 13 open issues with 'locals' in the
title.

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

Re: [Python-ideas] Jump to function as an an alternative to call function

[Chris Angelico]

On Tue, Aug 21, 2018 at 12:21 AM, Steven D'Aprano  wrote:
> On Sun, Aug 19, 2018 at 06:18:56PM +0300, Kirill Balunov wrote:
>
> [...]
>> > > e) It leaves a room for a future changes (In fact, in some situations I
>> > > would like to have this possibility).
>
> [Chris]
>> > Related to (e) is that there is room for other implementations to
>> > permit changes to locals(), and furthermore, a fully-compliant Python
>> > implementation may use an actual dictionary for locals, and simply
>> > return that. (That CPython doesn't is an implementation detail for the
>> > sake of performance.) Requiring that it be a proxy would impose
>> > unnecessary cost on the implementation, without benefiting any
>> > compliant use.
>
> I would like to see CPython locals() return a mapping object which
> raises a warning when you mutate it.

That, I can get behind. Requiring it to be a proxy would IMO be a bad
idea; but the warning here would be a CPython implementation detail.
OTOH, warnings are easy to miss. But on the gripping hand, if more of
Python and CPython raised warnings when odd things or
implementation-specific things were done, it would encourage people to
develop with warnings active.

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/

Re: [Python-ideas] Jump to function as an an alternative to call function

[Steven D'Aprano]

On Sun, Aug 19, 2018 at 06:18:56PM +0300, Kirill Balunov wrote:

[...]
> > > e) It leaves a room for a future changes (In fact, in some situations I
> > > would like to have this possibility).

[Chris]
> > Related to (e) is that there is room for other implementations to
> > permit changes to locals(), and furthermore, a fully-compliant Python
> > implementation may use an actual dictionary for locals, and simply
> > return that. (That CPython doesn't is an implementation detail for the
> > sake of performance.) Requiring that it be a proxy would impose
> > unnecessary cost on the implementation, without benefiting any
> > compliant use.

I would like to see CPython locals() return a mapping object which 
raises a warning when you mutate it.

* Currently, assignments to locals() simply do the wrong thing (modify
  the dict but fail to modify the local namespace) silently; such errors 
  should never pass silently.

* It should be a warning, not an error, since there are use-cases for
  modifying the local dict without caring about the namespace; in those
  cases we can simply silence the warning or ignore it.

* Introducing a warning makes it clear that this is not a de facto 
  language standard, but a mere implementation detail subject to
  change if somebody comes up with a better optimization for locals.

- Other implementations should be permitted to use local namespaces
  which are read/write (that's a Quality Of Implementation issue).

- Given that uses of locals() inside a function are already restricted
  and presumably uncommon, the extra cost of a warning is unlikely
  to be meaningful.


[Kirill]
> Let me disagree with you. While CPython is only one of the implementations
> of the Python language, it is the most common one and defacto is considered
> as a standard.

Not in this case. If CPython intended this to be the language behaviour, 
it should specify that limitation instead of merely giving a doc warning 
that changes "may not" affect the local variables.

In fact, the warning in the docs is too strong. Modifying locals() 
inside a class or module scope is allowed, and works fine. It is only 
functions which is problematic.


> Therefore, all the others, to be compliant, try to replicate
> all subtleties and features of the basic implementation - CPython.

Implementations are expected to obey the documented behaviour (unless 
given special dispensation to break the rules, which I think has 
happened once or twice with MicroPython). For behaviour which isn't 
dpcumented, it is true that implementations *often* try to copy CPython, 
but that's not mandatory and there are exceptions.

PyPy is probably the alternate implementation which tries the hardest to 
duplicate CPython, but even PyPy has differences:

http://doc.pypy.org/en/latest/cpython_differences.html

including a few things which the PyPy developers believe is a bug in 
CPython.

This list of differences between Jython and CPython is terribly out of 
date, but I haven't found anything more recent:

http://www.jython.org/archive/21/docs/differences.html


> And even
> more so, I do not believe that anyone will rely or use such a feature.

Users of CPython frequently rely on CPython implementation details. Why 
do you think Jython and IronPython users will be different?



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

Re: [Python-ideas] Pre-conditions and post-conditions

[Daniel Moisset]

I think that annotations were suggested because you could write an
expression there without getting evaluated.

I've thought about this problem many times in the past (as a Python dev
with a long history working in Eiffel too) For me one of the crucial
issue that is hard to translate into the python model is that the
assertions (say, a function precondition) are not conceptually part of the
function itself, but the interface of the class. The "natural" python ways
of attaching these assertions somehow to the function object do not work
when you also use inheritance, because when you override a method the new
function object clobbers the previous one. I've experimented at some point
on how to put them in classes (and doing metaclass or __getattribute__
tricks) but nothing convinced me). In general, the way that python puts
method call and inheritance semantic in a specific layout of runtime
objects (which in general is really clever) seems to be a bit alien to the
DbC idea where the asbtraction/interface of the class is conceptually
separate and has independent information wrt to the runtime objects.


On 16 August 2018 at 18:49, Marko Ristin-Kaufmann 
wrote:

> Hi Jonathan and Paul,
> Thank you very much for your suggestions! I will try to contact the author
> of the PEP.
>
> Let me clarify a bit a potential misunderstanding. Please mind that
> contracts are not tied to individual variables, but to expressions. Think
> of it as defining a lambda which takes as input all the arguments of the
> function (and a result variable in case of post-conditions) which always
> needs to evaluate to True.
>
> Cheers,
> Marko
>
> Le jeu. 16 août 2018 à 12:24, Paul Moore  a écrit :
>
>> On Thu, 16 Aug 2018 at 10:41, Jonathan Fine  wrote:
>> >
>> > Hi Marko
>> >
>> > Thank you for introducing yourself, and clearly stating your question.
>> > That helps us all. You asked:
>> >
>> > > Could somebody update me on the state of the discussion on this
>> matter?
>> >
>> > I think bring the existing PEP up to date would be a good starting
>> > point. Its content hasn't been changed since 2003 (except for PEP-wide
>> > admin changes. (Recall that Python 3.0 was released in 2008.)
>> >
>> > https://www.python.org/dev/peps/pep-0316/
>> > https://github.com/python/peps/commits/master/pep-0316.txt
>> >
>> > In fact, revising the PEP might be enough to answer your question.
>> > What do you think, Marko?
>> >
>> > Experts: is there a process for revising old PEPs, such as this one?
>> > Or at least a precedent we could follow (or adapt)?
>>
>> I'm not aware of a formal process, but I'd have thought the following
>> steps would be a reasonable approach:
>>
>> 1. Review the PEP, and research the discussions that happened at the
>> time, particularly of interest is why the PEP was deferred.
>> 2. Consider what (if anything) has changed since the original deferral
>> (which could simply be "time has moved on, people's views may have
>> changed" but ideally would include a bit more in the way of concrete
>> motivation).
>> 3. Contact the original PEP author and ask if he is interested in
>> reopening the discussion, collaborating on a revision, or handing the
>> PEP over.
>> 4. Start up a discussion here, pointing out the original PEP and
>> summarising the previous debate and why you want to restart the
>> discussion. If you're hoping to change the details of the original
>> PEP, summarise your changes and why you feel they are an improvement
>> over the original.
>>
>> To answer the OP's question more directly:
>>
>> > Could somebody update me on the state of the discussion on this matter?
>>
>> As far as I am aware, there has been no discussion on this subject
>> since the PEP 316 discussions which ended up in its deferral. Elazar
>> mentioned PEP 563, and there *may* have been mention of design by
>> contract uses in the discussions on that PEP, but you'd have to search
>> the mailing list archives to confirm that one way or another.
>>
>> Hence the suggestions that if you want to restart discussion, reviving
>> PEP 316 is likely the best approach.
>>
>> 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/
>
>


-- 

Daniel Moisset
Technical Leader

A:   1 Fore St, EC2Y 9DT London 
P:   +44 7398 827139 <+44+7398+827139>
M:   dmois...@machinalis.com   |   S:   dmoisset

  

___

Re: [Python-ideas] Asynchronous friendly iterables

[Joao S. O. Bueno]

On Mon, 20 Aug 2018 at 04:49, Chris Angelico  wrote:
>
> On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve  wrote:
> > Do you mean that for loops inside an "async def" statements are always
> > executed as 'async for' loops? That's what I wanted to acheive by writing
> > the AsyncDict class (c.f. the CodeReview link).
>
> The point of an 'async for' loop is that grabbing the next value can
> block the async function - it's a yield point. If you don't need that,
> you can use a regular 'for' loop.

Maybe it is worth to further clarify that iterating on dicts and lists
is _not_ blocking at all.
That would only be the case if to retrieve its own keys the dictionary
would have
to perform some I/O access or heavy computation - which, besides been of very
little value in practice, would only be possible in a specialized class anyway.


>
> 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] Does jargon make learning more difficult?

[Rhodri James]

On 18/08/18 01:59, Abe Dillon wrote:

The argument I tried to make is, "yes I believe there are cases where a
less jargon identifier is preferable and that I believe 'lambda' is an
example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
better word here?), more descriptive name."


While I don't entirely disagree with you, if I had been responsible for 
inventing that bit of Python I would probably have gone with "lambda" 
too.  It had been part of my vocabulary as a computer scientist long 
before I met it in a programming language.  Whether it's a *good* choice 
or not... possibly reusing "def" would fit people's expectations better, 
or perhaps it would have caused more confusion.  Who can tell?


Jargon becomes jargon because it's useful to enough people, for 
occasionally rather odd definitions of "useful".  In the case of lambda, 
it's shorter than "inline function definition" and lambda calculus at 
least shows up on most CompSci courses.  Once it settles into a group, 
you use it because other members of the group will understand what you 
mean and might not understand if you rephrase it.


> For instance: when the iPhone was introduced, a lot of people praised
> it's subjectively "slick" user interface. I believe that perception of
> slickness is partly because the iPhone emulated physical interfaces
> very well so it leveraged people's intuition about the physical world.
> It was delightfully intuitive.

One of the things Apple have always been very good at is thinking hard 
about user interfaces.  What made the iPhone so good was that they 
emulated the right physical interfaces, so flipping a page when you're 
reading rather than pressing a button.


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

Re: [Python-ideas] Redefining method

[Jamesie Pic]

Sorry if my message offended anyone (noted that the "Toxic Forum" post came
not long after mine).

What I meant is that I cannot defend such an idea before extensively using
it. I just don't know how to do it this way.

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/

Re: [Python-ideas] Does jargon make learning more difficult?

[Stephen J. Turnbull]

Jonathan Fine writes:

 > I very much more prefer Victor's suggestion [of providing
 > translations in the distribution and giving translators commit
 > bits, AIUI].

I think we can do both.  My suggestion is very cheap, and requires no
change to release management, or even action by release managers and
committers: the PSF board could announce the policy tomorrow and start
cutting checks next Monday, and python-dev wouldn't notice.  (I'm not
suggesting overnight rollout is a good idea, and practically speaking
the board can't act that fast, of course.  The point is that there's
potential encouragement for translators, improved documentation for
users, at zero cost to the code developers and release managers.)

The suggestion of providing official translations in the distribution
has been made before, and resisted by the maintainers and committers.
I don't oppose the idea myself, I simply observe that resistance and
the explanations offered, and assume there is good reason for it.

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/

Re: [Python-ideas] Does jargon make learning more difficult?

[Stephen J. Turnbull]

Jonathan Fine writes:

 > One of the alternatives in PEP 545 is
 > ===
 > Simplified English
 > It would be possible to introduce a "simplified English" version like
 > wikipedia did, as discussed on python-dev, targeting English learners
 > and children.
 > ===

As a *translation*, it's a very worthwhile experiment, if someone
wants to do 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] Asynchronous friendly iterables

[Chris Angelico]

On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve  wrote:
> Do you mean that for loops inside an "async def" statements are always
> executed as 'async for' loops? That's what I wanted to acheive by writing
> the AsyncDict class (c.f. the CodeReview link).

The point of an 'async for' loop is that grabbing the next value can
block the async function - it's a yield point. If you don't need that,
you can use a regular 'for' loop.

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/

Re: [Python-ideas] Asynchronous friendly iterables

[Nathaniel Smith]

On Mon, Aug 20, 2018 at 12:34 AM, Simon De Greve  wrote:
> Do you mean that for loops inside an "async def" statements are always
> executed as 'async for' loops? That's what I wanted to acheive by writing
> the AsyncDict class (c.f. the CodeReview link).

The only difference between an 'async for' and a regular 'for' is that
the former works on async iterables, and the latter works on regular
iterables. So "executed as 'async for'" doesn't really mean anything,
I think? If you have an async iterable, use 'async for', and if you
have a regular iterable, use 'for'.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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] Asynchronous friendly iterables

[Simon De Greve]

Do you mean that for loops inside an "async def" statements are always
executed as 'async for' loops? That's what I wanted to acheive by writing
the AsyncDict class (c.f. the CodeReview link).

As I said, I'm pretty new to Asyncio and thus may be missing some
immportant feature of the lib (which is apparently the case here).

Le lun. 20 août 2018 à 09:29, Nathaniel Smith  a écrit :

> On Mon, Aug 20, 2018 at 12:19 AM, Simon De Greve 
> wrote:
> > Hello everyone,
> >
> > I'm quite new working with asyncio and thus maybe missing some things
> about
> > it, but wouldn't it be quite easier to have some iterables to support
> async
> > for loops "natively", since asyncio is now part of the Stdlib?
> >
> > I've tried to work with asyncio while using discord.py, and has some
> > struggle with an "async for" loop on a dictionary, so I had to implement
> a
> > new dict subclass that would just reimplement items(), keys() and
> values()
> > functions.
> >
> > I think that it would be a cool improvement to implement some of those in
> > some standard way. There's some code I wrote on a CodeReview thread but I
> > still haven't got any feedback on it.
> >
> > Here's the link of the thread :
> >
> https://codereview.stackexchange.com/questions/197551/asynchronous-dictionary-in-python
>
> You can do this, but I don't see what it accomplishes...
>
> Are you aware that you can use regular 'for' loops inside 'async def'
> functions?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
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] Asynchronous friendly iterables

[Nathaniel Smith]

On Mon, Aug 20, 2018 at 12:19 AM, Simon De Greve  wrote:
> Hello everyone,
>
> I'm quite new working with asyncio and thus maybe missing some things about
> it, but wouldn't it be quite easier to have some iterables to support async
> for loops "natively", since asyncio is now part of the Stdlib?
>
> I've tried to work with asyncio while using discord.py, and has some
> struggle with an "async for" loop on a dictionary, so I had to implement a
> new dict subclass that would just reimplement items(), keys() and values()
> functions.
>
> I think that it would be a cool improvement to implement some of those in
> some standard way. There's some code I wrote on a CodeReview thread but I
> still haven't got any feedback on it.
>
> Here's the link of the thread :
> https://codereview.stackexchange.com/questions/197551/asynchronous-dictionary-in-python

You can do this, but I don't see what it accomplishes...

Are you aware that you can use regular 'for' loops inside 'async def' functions?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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] Off topic: 'strike a balance' - second language English

[Jacco van Dorp]

I would consider conciseness and accuracy most important. Using jargon but
linking to accurate explanations would, in my not exactly humble opinion,
be the best way to go about 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/