Steven D'Aprano wrote:
Pascal, for example, had lexical scoping back in the 1970s, but
no closures.
Well, it kind of had a limited form of closure. You could pass
a procedure or function *in* to another procedure or function
as a parameter, but there was no way to return one or pass it
out in a
Tim Peters wrote:
I expected the following would work, but it doesn't :-)
iseven = lambda n: (
lambda n=n, \
even = (lambda n: n == 0 or odd(n-1)), \
odd = (lambda n: False if n == 0 else even(n-1)):
even(n))()
Ug
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 j
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 results, note the negat
[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 (whi
[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
problem(s) you're trying to solve.
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
https://mail.python.org/mailman/listinfo/p
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 corresponding byte-cod
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 respect
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 and the other side
"wins" by
[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 ;-)
> The purpose of 'local'
[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 runtime
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 u
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:
a = 43
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
> > le
[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 = (l
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 alternative which is harder an
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 bound.
ChrisA
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
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 I agree with them. Backwards compatiblity
20 matches
Mail list logo
