t: Tuesday, October 4, 2016 7:00:48 AM
To: python-list@python.org
Subject: Re: Is that forwards first or backwards first? (Re: unintuitive
for-loop behavior)
On Tuesday 04 October 2016 14:51, Michael Torrie wrote:
> On 10/03/2016 08:21 PM, Steve D'Aprano wrote:
>> On Tue, 4 Oct 2016
On Tuesday 04 October 2016 14:51, Michael Torrie wrote:
> On 10/03/2016 08:21 PM, Steve D'Aprano wrote:
>> On Tue, 4 Oct 2016 05:48 am, Michael Torrie wrote:
>>
>>> There is that old, but false, saying that the only intuitive interface
>>> is the nipple. Turns out everything, even that, is learn
On Mon, 3 Oct 2016 10:57:27 -0700 (PDT), sohcahto...@gmail.com declaimed
the following:
>
My car is similar, but the R is actually to the left of 1. It looks like this:
R 1 3 5
+-+-+-+
2 4 6
Mine is actually like that too, but it feels like you're
doing the same thing in both cases -- push l
On 10/03/2016 08:21 PM, Steve D'Aprano wrote:
> On Tue, 4 Oct 2016 05:48 am, Michael Torrie wrote:
>
>> There is that old, but false, saying that the only intuitive interface
>> is the nipple. Turns out everything, even that, is learned
>
> Citation required.
Sure, just ask a nursing woman.
>
On Tuesday, October 4, 2016 at 8:11:41 AM UTC+5:30, Steve D'Aprano wrote:
> On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
>
> > Steve D'Aprano writes:
> >> Why shouldn't people say that binding and assignment are the same
> >> thing in Python? What's the difference?
> >
> > Outside Python
On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
> Steve D'Aprano writes:
>> Why shouldn't people say that binding and assignment are the same
>> thing in Python? What's the difference?
>
> Outside Python, (lambda x : f(x)) is said to "bind" x. It's different
> from assigning a new value to
On Tue, 4 Oct 2016 05:48 am, Michael Torrie wrote:
> There is that old, but false, saying that the only intuitive interface
> is the nipple. Turns out everything, even that, is learned
Citation required.
Of course many things are intuitive/instinctive, e.g. breathing, but as far
as *interfaces*
BartC wrote:
On 03/10/2016 12:53, Marko Rauhamaa wrote:
Well, it could be worse. This layout is pretty traditional:
1 3 5
| | |
+--+--+
| | |
2 4 R
Yes, you get a funny grinding sound when attempting to change from 5th
to '6th' at 70mph/110kph. Fortunately it doe
On 10/03/2016 11:57 AM, sohcahto...@gmail.com wrote:
> Surprisingly, despite driving that previous car for 13 years, the switch was
> incredibly easy. I've never accidentally gone to sixth gear instead of
> reverse, or forgotten to shift into sixth on the highway. Also, accidentally
> going in
On 10/03/2016 03:10 AM, Gregory Ewing wrote:
> Rustom Mody wrote:
>> My new car goes in reverse when I put it in first gear but only on full-moon
>> nights with the tank on reserve when the left light is blinking
>
> OT aside: When I went to take my current car (a manual)
> for a test drive, I ha
On Monday, October 3, 2016 at 2:11:12 AM UTC-7, Gregory Ewing wrote:
> Rustom Mody wrote:
> > My new car goes in reverse when I put it in first gear but only on
> > full-moon
> > nights with the tank on reserve when the left light is blinking
>
> OT aside: When I went to take my current car (a m
On Monday, October 3, 2016 at 5:41:23 PM UTC+1, BartC wrote:
> On 03/10/2016 16:03, wrote:
> > On Monday, October 3, 2016 at 12:53:55 PM UTC+1, Marko Rauhamaa wrote:
> >> Gregory Ewing:
> >>
> >>> Turns out the only difference between first and reverse on that model
> >>> is whether you lift up a l
On 03/10/2016 16:03, breamore...@gmail.com wrote:
On Monday, October 3, 2016 at 12:53:55 PM UTC+1, Marko Rauhamaa wrote:
Gregory Ewing:
Turns out the only difference between first and reverse on that model
is whether you lift up a little ring on the shaft of the gear lever
prior to engagement.
On Monday, October 3, 2016 at 12:53:55 PM UTC+1, Marko Rauhamaa wrote:
> Gregory Ewing:
>
> > Turns out the only difference between first and reverse on that model
> > is whether you lift up a little ring on the shaft of the gear lever
> > prior to engagement.
> >
> > Who came up with *that* brill
On 03/10/2016 12:53, Marko Rauhamaa wrote:
Gregory Ewing :
Turns out the only difference between first and reverse on that model
is whether you lift up a little ring on the shaft of the gear lever
prior to engagement.
Who came up with *that* brilliant piece of user interface design I
don't kno
On Mon, 03 Oct 2016 22:10:52 +1300, Gregory Ewing wrote:
> Rustom Mody wrote:
>> My new car goes in reverse when I put it in first gear but only on
>> full-moon nights with the tank on reserve when the left light is
>> blinking
>
> OT aside: When I went to take my current car (a manual) for a tes
Gregory Ewing :
> Turns out the only difference between first and reverse on that model
> is whether you lift up a little ring on the shaft of the gear lever
> prior to engagement.
>
> Who came up with *that* brilliant piece of user interface design I
> don't know. It seems specifically designed t
Rustom Mody wrote:
My new car goes in reverse when I put it in first gear but only on full-moon
nights with the tank on reserve when the left light is blinking
OT aside: When I went to take my current car (a manual)
for a test drive, I had to stop and ask the dealer how
to put it into reverse.
Steve D'Aprano wrote:
x = str = 1
assert x == 1 and str == 1
del x, str
assert str # succeeds
assert x # NameError
x = str = 2 # create new bindings, or update existing ones?
Is it our conclusion that therefore Python creates a new binding for str
but not for x? Or that the evidence for x is
Antoon Pardon writes:
> Op 02-10-16 om 07:59 schreef Rustom Mody:
>>
>> You are explaining the mechanism behind the bug. Thanks. The bug
>> remains. My new car goes in reverse when I put it in first gear but
>> only on full-moon nights with the tank on reserve when the left light
>> is blinking T
Op 02-10-16 om 07:59 schreef Rustom Mody:
>
> You are explaining the mechanism behind the bug. Thanks. The bug remains.
> My new car goes in reverse when I put it in first gear but only on full-moon
> nights with the tank on reserve when the left light is blinking
> The engineer explains the inter
Chris Angelico wrote:
The only way to prove that something is a new binding is to
demonstrate that, when this binding is removed, a previous one becomes
visible.
Or capture them both with closures and show that each
closure sees a different version of the binding.
--
Greg
--
https://mail.pytho
Steve D'Aprano wrote:
No it doesn't mean that at all. The result you see is compatible with *both*
the "update existing slot" behaviour and "create a new slot" behavior.
We're getting sidetracked talking about slots here.
It's not really relevant. The point is that there is
only *one* binding f
Steve D'Aprano writes:
> On Sun, 2 Oct 2016 05:35 pm, Jussi Piitulainen wrote:
>
> [...]
>>> I'm sorry, I don't understand what you mean by "Python semantics" versus
>>> "a translation". A translation of what? In what way is it "magical
>>> semantics"? I see nothing magical in your code: it is Pyt
On Mon, Oct 3, 2016 at 3:09 PM, Steven D'Aprano
wrote:
> But if it did, then just as in the similar situation in IronPython and Jython,
> you would still need to convince the compiler to use LOAD_FAST or equivalent
> in
> order to see it. Hence:
>
>
> x = y = 'global'
> def example():
> local
On Monday 03 October 2016 12:42, Steve D'Aprano wrote:
> Yes the local would have been created, but you wouldn't see it from an
> ordinary lookup of name x. You would need to use
>
> locals()['x']
>
> to see that it exists. For x to return it, you have to convince the compiler
> to use LOAD_
On Sun, 2 Oct 2016 05:35 pm, Jussi Piitulainen wrote:
[...]
>> I'm sorry, I don't understand what you mean by "Python semantics" versus
>> "a translation". A translation of what? In what way is it "magical
>> semantics"? I see nothing magical in your code: it is Python code.
>
> "Python semantics
On Sun, 2 Oct 2016 09:41 pm, Chris Angelico wrote:
> The only way to prove that something is a new binding is to
> demonstrate that, when this binding is removed, a previous one becomes
> visible. In Python, that only ever happens across namespaces, and in
> CPython, the only way I can make it ha
On Sun, Oct 2, 2016 at 9:20 PM, Steve D'Aprano
wrote:
> On Sun, 2 Oct 2016 04:06 pm, Chris Angelico wrote:
>> Hmm, interesting. I don't have IronPython here, but maybe you can tell
>> me what this does:
>>
>> print(str)
>> str = "demo"
>> print(str)
>> del str
>> print(str)
>>
>> and the same insi
On Sun, 2 Oct 2016 04:06 pm, Chris Angelico wrote:
> On Sun, Oct 2, 2016 at 3:19 PM, Steve D'Aprano
> wrote:
>> In IronPython, you could have the following occur in a function locals,
>> just as it could happen CPython for globals:
>>
>> - delete the name binding "x"
>> - which triggers a diction
Marko Rauhamaa writes:
> Jussi Piitulainen wrote:
>> I could have just posted that yes, it *could* be done, there's
>> nothing so special about variables and scope in Python. But I pretty
>> much know that the response to *that* would have been yet another
>> round of "You don't understand that Py
Steve D'Aprano writes:
> On Sun, 2 Oct 2016 11:44 am, Gregory Ewing wrote:
>
>> Steve D'Aprano wrote:
>>
>>> Certainly when you call a function, the local bindings need to be
>>> created. Obviously they didn't exist prior to calling the function!
>>> I didn't think that was the difference you were
Jussi Piitulainen :
> I could have just posted that yes, it *could* be done, there's nothing
> so special about variables and scope in Python. But I pretty much know
> that the response to *that* would have been yet another round of "You
> don't understand that Python variables are different, they
Steve D'Aprano writes:
> On Sun, 2 Oct 2016 12:28 am, Jussi Piitulainen wrote:
>
>> I'm not sure any more to what message this should be a followup, but
>> here is a demonstration of two different semantics of the for-loop
>> variable scope/update, this time with nested loops using the same
>> loo
On Saturday, October 1, 2016 at 11:35:31 PM UTC+5:30, Steve D'Aprano wrote:
> On Sun, 2 Oct 2016 03:57 am, Rustom Mody wrote:
>
> > Hoo boy1
> > Thats some tour de force and makes my head spin
>
> I certainly agree with the second part of your sentence.
>
>
> > Point can be made more simply wit
On Sun, Oct 2, 2016 at 3:19 PM, Steve D'Aprano
wrote:
> In IronPython, you could have the following occur in a function locals, just
> as it could happen CPython for globals:
>
> - delete the name binding "x"
> - which triggers a dictionary resize
> - bind a value to x again
> - because the dictio
On Sun, 2 Oct 2016 11:44 am, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> When you say:
>>
>> x = 0
>> x = 1
>>
>> inside a function, and the interpreter does the name binding twice,
>> there's no way of telling whether it writes to the same cell each time or
>> not.
>
> Yes, there i
On Sun, 2 Oct 2016 12:28 am, Jussi Piitulainen wrote:
> I'm not sure any more to what message this should be a followup, but
> here is a demonstration of two different semantics of the for-loop
> variable scope/update, this time with nested loops using the same loop
> variable name. The first func
Steve D'Aprano wrote:
When you say:
x = 0
x = 1
inside a function, and the interpreter does the name binding twice, there's
no way of telling whether it writes to the same cell each time or not.
Yes, there is:
... x = 0
... f1 = lambda: x
... x = 1
... f2 = lambda: x
... print(f
On 10/1/2016 8:24 AM, Rustom Mody wrote:
Yeah by comprehension-variable I mean the one that sits left of the
‘in’ inside the conprehension.
In other words, a 'loop variable within a comprehension'. Keep in mind
that there may be multiple targets for the implicit (hidden) assignment,
so ther
On Sun, 2 Oct 2016 03:57 am, Rustom Mody wrote:
> Hoo boy1
> Thats some tour de force and makes my head spin
I certainly agree with the second part of your sentence.
> Point can be made more simply with map
> ie if we *define*
> [exp for cv in l]
> as
> map(lambda cv: exp, l)
>
> the problem v
On Saturday, October 1, 2016 at 7:02:58 PM UTC+5:30, Jussi Piitulainen wrote:
> Rustom Mody writes:
>
> > And then define comprehensions not as now done in terms of for loops
> > that mutatingly extend the list being built up but as recursive
> > functions that get (re)called for every new value o
I'm not sure any more to what message this should be a followup, but
here is a demonstration of two different semantics of the for-loop
variable scope/update, this time with nested loops using the same loop
variable name. The first function, tabulate, uses Python semantics ("t"
for true, if you lik
Rustom Mody writes:
> And then define comprehensions not as now done in terms of for loops
> that mutatingly extend the list being built up but as recursive
> functions that get (re)called for every new value of the comprehension
> variable passed and therefore fresh-bound as parameter
You'd get
than accessing uninitialised memory, as a naive implementation might
have done.
In any case, I think this is going off on a rather wide tangent -- how is
this specifically relevant to the "unintuitive for-loop behavior" the OP
was surprised by?
> When I said "creating a new bi
On Saturday, October 1, 2016 at 5:02:30 PM UTC+5:30, Steve D'Aprano wrote:
> On Sat, 1 Oct 2016 01:44 pm, Rustom Mody wrote:
>
> > Yes one basic problem with comprehensions in python is that they are
> > defined by assignment not binding to the comprehension variable
>
> ¿Que Mr Fawlty?
>
> I'm
Steve D'Aprano wrote:
# create a new binding
x: address 1234 > [ box contains 999 ]
x: address 5678 > [ a different box, containing 888 ]
In the context of CPython and nested functions, replace
"box" with "cell".
When I said "creating a new binding" I meant that the
name x refers to
On Sat, 1 Oct 2016 01:44 pm, Rustom Mody wrote:
> Yes one basic problem with comprehensions in python is that they are
> defined by assignment not binding to the comprehension variable
¿Que Mr Fawlty?
I'm sorry, I don't understand you.
In Python, all assignments are name bindings. So you seem t
Random832 wrote:
> for a in collection:
> b = some_calculation_of(a)
> final b: do_something_with(lambda: ... b ...)
I would prefer something like
for a in collection:
let b = some_calculation_of(a):
do_something_with(lambda: ... b ...)
--
Greg
--
https://mail.python.org/ma
On Sat, Oct 1, 2016 at 6:35 PM, Steve D'Aprano
wrote:
> On Sat, 1 Oct 2016 02:39 am, Chris Angelico wrote:
>
>> On Sat, Oct 1, 2016 at 12:36 AM, Grant Edwards
>> wrote:
>
>>> In C99 a for loop has its own namespac:
> [...]
>
>> I believe that's the same semantics as C++ uses, and I agree, it's
>>
Steve D'Aprano writes:
> In a language like Python, the only distinction we can make between
> name bindings is, which namespace is the binding in? In other words,
> what is the current block of code's scope?
Python already has nested scopes. A local scope for just those variables
introduced in f
On Sat, 1 Oct 2016 02:39 am, Chris Angelico wrote:
> On Sat, Oct 1, 2016 at 12:36 AM, Grant Edwards
> wrote:
>> In C99 a for loop has its own namespac:
[...]
> I believe that's the same semantics as C++ uses, and I agree, it's
> very convenient. Among other things, it means that nested loops be
On Sat, Oct 1, 2016 at 5:06 PM, Steve D'Aprano
wrote:
> Earlier, I wrote:
>
>> On Sat, 1 Oct 2016 10:46 am, Gregory Ewing wrote:
> [...]
>>> Whenever there's binding going on, it's necessary to decide
>>> whether it should be creating a new binding or updating an
>>> existing one.
>>
>> Right.
>
>
Earlier, I wrote:
> On Sat, 1 Oct 2016 10:46 am, Gregory Ewing wrote:
[...]
>> Whenever there's binding going on, it's necessary to decide
>> whether it should be creating a new binding or updating an
>> existing one.
>
> Right.
I changed my mind -- I don't think that's correct.
I think Greg's
On Saturday, October 1, 2016 at 8:55:19 AM UTC+5:30, Random832 wrote:
> On Fri, Sep 30, 2016, at 20:46, Gregory Ewing wrote:
> > What *is* necessary and sufficient is to make each iteration
> > of the for-loop create a new binding of the loop variable
> > (and not any other variable!).
>
> I don't
On Sat, 1 Oct 2016 10:46 am, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> Giving for-loops their own namespace is a grossly unintuitive and a very
>> weird thing to do.
>>
>> It would be terribly inconvenient and surprising for if...else blocks to
>> be separate namespaces:
>
> There's an imp
For the most part you've taken the words out of my mouth!
Some more details...
On Saturday, October 1, 2016 at 6:16:32 AM UTC+5:30, Gregory Ewing wrote:
> Steve D'Aprano wrote:
> > Giving for-loops their own namespace is a grossly unintuitive and a very
> > weird thing to do.
> >
> > It would be
On Fri, Sep 30, 2016, at 20:46, Gregory Ewing wrote:
> What *is* necessary and sufficient is to make each iteration
> of the for-loop create a new binding of the loop variable
> (and not any other variable!).
I don't think that's true. I think this is logic that is excessively
tied to the toy exam
Steve D'Aprano wrote:
What happens if it is *not* a misfeature? Gotchas are not always
misfeatures -- sometimes gotchas are gotchas because people's expectations
are simply wrong, and pandering to their confused expectations does not
actually help them.
I haven't made up my mind about *this* spe
Steve D'Aprano wrote:
Giving for-loops their own namespace is a grossly unintuitive and a very
weird thing to do.
It would be terribly inconvenient and surprising for if...else blocks to be
separate namespaces:
There's an important difference between a for-loop and an
if-statement that's relev
On Fri, 30 Sep 2016 11:43 pm, BartC wrote:
> It can make sense for 'x' to be local to this for-loop block (everything
> else is at it works now), and independent of any x's in outer blocks. It
> means being able to do stuff like this:
>
> for x in a:
> for x in b:
> pass
>
On Fri, 30 Sep 2016 03:06 pm, Rustom Mody wrote:
> On Friday, September 30, 2016 at 10:23:31 AM UTC+5:30, Gregory Ewing
> wrote:
>> namenobodywants wrote:
>> > can anyone help to reconcile me to this semantics?
>>
>> Not really. Most people agree that it's not desirable
>> behaviour, but we've e
On Sat, Oct 1, 2016 at 3:03 AM, Brendan Abel <007bren...@gmail.com> wrote:
>> a = 1
> if condition:
> print(a) # UnboundLocalError: local 'a' referenced before assignment
> a += 1
>
>
> For-loops are no different. Making them their own namespace is a very
> strange thing to do, it would me
> a = 1
if condition:
print(a) # UnboundLocalError: local 'a' referenced before assignment
a += 1
For-loops are no different. Making them their own namespace is a very
strange thing to do, it would mean you couldn't re-bind a value inside a
for-loop:
count = 0
for x in sequence:
cou
On 2016-09-30, Grant Edwards wrote:
> On 2016-09-30, Steve D'Aprano wrote:
>
>> To me, "make for-loops be their own scope" sounds like a joke
>> feature out of joke languages like INTERCAL. I'm not aware of any
>> sensible language that does anything like this.
>
> In C99 a for loop has its own n
On Sat, Oct 1, 2016 at 12:36 AM, Grant Edwards
wrote:
> On 2016-09-30, Steve D'Aprano wrote:
>
>> To me, "make for-loops be their own scope" sounds like a joke feature out of
>> joke languages like INTERCAL. I'm not aware of any sensible language that
>> does anything like this.
>
> In C99 a for
On 30/09/2016 15:01, Chris Angelico wrote:
On Fri, Sep 30, 2016 at 10:33 PM, Steve D'Aprano
wrote:
To me, "make for-loops be their own scope" sounds like a joke feature out of
joke languages like INTERCAL. I'm not aware of any sensible language that
does anything like this.
No, wait a minute,
On 2016-09-30, Steve D'Aprano wrote:
> To me, "make for-loops be their own scope" sounds like a joke feature out of
> joke languages like INTERCAL. I'm not aware of any sensible language that
> does anything like this.
In C99 a for loop has its own namespac:
int main(void)
{
for (int i=
On Fri, Sep 30, 2016 at 10:33 PM, Steve D'Aprano
wrote:
> To me, "make for-loops be their own scope" sounds like a joke feature out of
> joke languages like INTERCAL. I'm not aware of any sensible language that
> does anything like this.
>
> No, wait a minute, I tell a lie, I recall Chris Angelico
On 30/09/2016 13:33, Steve D'Aprano wrote:
On Fri, 30 Sep 2016 05:29 am, namenobodywa...@gmail.com wrote:
i've had a nodding acquaintance with python for some time, and all along i
assumed that for-loops got a namespace of their own;
It would be terribly inconvenient and surprising for if..
On Fri, 30 Sep 2016 05:29 am, namenobodywa...@gmail.com wrote:
> hello pythonistas
>
> i've had a nodding acquaintance with python for some time, and all along i
> assumed that for-loops got a namespace of their own;
Giving for-loops their own namespace is a grossly unintuitive and a very
weird
On Friday, September 30, 2016 at 10:23:31 AM UTC+5:30, Gregory Ewing wrote:
> namenobodywants wrote:
> > can anyone help to reconcile me to this semantics?
>
> Not really. Most people agree that it's not desirable
> behaviour, but we've ended up here due to a convoluted
> history, and there doesn
namenobodywa...@gmail.com wrote:
> can anyone help to reconcile me to this semantics?
Not really. Most people agree that it's not desirable
behaviour, but we've ended up here due to a convoluted
history, and there doesn't seem to be a good way to
fix it without breaking a lot of existing code.
C
On Fri, Sep 30, 2016 at 5:29 AM, wrote:
> i've had a nodding acquaintance with python for some time, and all along i
> assumed that for-loops got a namespace of their own; now i'm reading up on
> the language and i find out that's not the case: the loop variable gets put
> into the enclosing n
Yes, loops don't have their own scope. Indeed, very few flow elements in
python -- if, with, try/except -- create a new scope. In that sense, it's
fairly consistent, but can be unexpected for people that have used
languages with many nested scopes.
The lambda behavior is a common gotcha - there
hello pythonistas
i've had a nodding acquaintance with python for some time, and all along i
assumed that for-loops got a namespace of their own; now i'm reading up on the
language and i find out that's not the case: the loop variable gets put into
the enclosing namespace, overwriting any forme
76 matches
Mail list logo
