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

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

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

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

Re: [Python-ideas] Asynchronous friendly iterables

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 a

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

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 constrai

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

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 ___

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

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

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

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

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

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 optim

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

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 co

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

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

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

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

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

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

Re: [Python-ideas] Asynchronous friendly iterables

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 me

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

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().

[Python-ideas] Documentation of locals()

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

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

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 t

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

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 local

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

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 p

Re: [Python-ideas] Asynchronous friendly iterables

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

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

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

Re: [Python-ideas] Redefining method

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 m

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

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 manage

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

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 wor

Re: [Python-ideas] Asynchronous friendly iterables

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 gr

Re: [Python-ideas] Asynchronous friendly iterables

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'

Re: [Python-ideas] Asynchronous friendly iterables

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

Re: [Python-ideas] Asynchronous friendly iterables

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

[Python-ideas] Asynchronous friendly iterables

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 so