Re: [Python-ideas] A "local" pseudo-function

[MRAB ] > I think it should be lexically scoped. That's certainly arguable, but that's why I like real-code driven design: abstract arguments never end, and often yield a dubious in-real-life outcome after one side is worn out and the other side "wins" by attrition

Re: [Python-ideas] A "local" pseudo-function

[MRAB ] > ... > The intention is that only the specified names are local. > > After all, what's the point of specifying names after the 'local' if _any_ > binding in the local scope was local? Don't look at me ;-) In the absence of use cases, I don't know which

Re: [Python-ideas] A "local" pseudo-function

Tim Peters writes: > Meaning "wonderfully clear" to the compiler, not necessarily to you > ;-) Is the compiler African or European (perhaps even Dutch)? ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] A "local" pseudo-function

[MRAB] >> Any binding that's not specified as local is bound in the parent scope: [Tim] > Reverse-engineering the example following, is this a fair way of > making that more precise? > > Given a binding-target name N in scope S, N is bound in scope T, where > T is the closest-containing scope

Re: [Python-ideas] Objectively Quantifying Readability

On Tue, May 1, 2018 at 10:42 AM, Steven D'Aprano wrote: > The conclusion here is that if you want readable source code, you should > remove the source code. *wink* That's more true than your winky implies. Which is more readable: a Python function, or the disassembly of its

Re: [Python-ideas] A "local" pseudo-function

On 2018-04-30 21:41, Tim Peters wrote: [MRAB ] > I think it should be lexically scoped. That's certainly arguable, but that's why I like real-code driven design: abstract arguments never end, and often yield a dubious in-real-life outcome after one side is worn out

Re: [Python-ideas] Objectively Quantifying Readability

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

Re: [Python-ideas] Objectively Quantifying Readability

On Tue, 01 May 2018 10:42:53 +1000, Steven D'Aprano wrote: > - people are not good judges of readability; WTF? By definition, people are the *only* judge of readability.¹ I happen to be an excellent judge of whether a given block of code is readable to me. OTOH, if you mean is that I'm a bad

Re: [Python-ideas] Objectively Quantifying Readability

On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano 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

Re: [Python-ideas] A "local" pseudo-function

I really liked the syntax that mimicked lambda even if I find it verbose : a = local x=1, y=2: x + y + 3 Even if I still prefer the postfix syntax : a = x + 3 where x = 2 About scheme "let" vs "let*", the paralel in Python is : a, b, c = 5, a+1, 2 # let syntax a = 5; b = a+1; c = 2 # let*

Re: [Python-ideas] Change magic strings to enums

2018-04-26 15:26 GMT+02:00 Nick Coghlan : > On 26 April 2018 at 19:37, Jacco van Dorp wrote: >> I'm kind of curious why everyone here seems to want to use IntFlags >> and other mixins. The docs themselves say that their use should be >> minimized, and tbh

Re: [Python-ideas] A "local" pseudo-function

On Sat, Apr 28, 2018 at 11:20:52PM -0500, Tim Peters wrote: > [Tim] > >> Enormously harder to implement than binding expressions, and the > >> latter (to my eyes) capture many high-value use cases "good enough". > > [Steven D'Aprano ] > > And yet you're suggesting an

[Python-ideas] Objectively Quantifying Readability

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

Re: [Python-ideas] Sublocal scoping at its simplest

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

Re: [Python-ideas] A "local" pseudo-function

On Sun, Apr 29, 2018 at 01:36:31PM +1000, Chris Angelico wrote: [...] > > While I started off with Python 1.5, I wasn't part of the discussions > > about nested scopes. But I'm astonished that you say that nested scopes > > were controversial. *Closures* I would completely believe, but mere > >

Re: [Python-ideas] A "local" pseudo-function

[Tim, on differences among Scheme-ish `let`, `let*`, `letrec` binding] > ... > > You can play, if you like, with trying to define the `iseven` lambda > here in one line by nesting lambdas to define `even` and `odd` as > default arguments: > > even = (lambda n: n == 0 or odd(n-1)) > odd =

Re: [Python-ideas] A "local" pseudo-function

On 2018-04-30 03:49, Tim Peters wrote: [Soni L. ] That ain't shadow. That is dynamic scoping. I don't believe either term is technically accurate, but don't really care. Shadowing is something different: def f(): a = 42 def g(): print(a) local a:

Re: [Python-ideas] A "local" pseudo-function

[Tim, still trying to define `iseven` in one statement] > even = (lambda n: n == 0 or odd(n-1)) > odd = (lambda n: False if n == 0 else even(n-1)) > iseven = lambda n: even(n) ... > [and the last attempt failed because a LOAD_GLOBAL was generated >instead of a more-general

Re: [Python-ideas] Sublocal scoping at its simplest

On Mon, Apr 30, 2018 at 6:20 PM, Matt Arcidy wrote: > Does this mean indentation is now a scope, or colons are a scope, or is that > over simplifying? No, no, and yes. This is JUST about the 'except' statement, which currently has the weird effect of unbinding the name it just