Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #96305 > unrolled thread

Re: Python handles globals badly.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-10 15:25 -0700
    Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-10 15:40 -0700
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-10 18:35 -0600
      Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 07:34 +0300
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 14:59 +1000
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 08:15 +0300
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 15:25 +1000
            Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:43 +0100
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-10 23:07 -0600
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 08:27 +0300
        Re: Python handles globals badly. Rustom Mody <rustompmody@gmail.com> - 2015-09-11 00:39 -0700
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 18:42 +1000
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 19:16 +1000
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 09:03 -0600
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-12 17:00 +1000
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 01:15 +1000
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 09:27 -0600
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 01:44 +1000
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 09:49 -0600
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 01:55 +1000
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 11:57 -0400
          Re: Python handles globals badly. Rustom Mody <rustompmody@gmail.com> - 2015-09-11 09:08 -0700
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 02:04 +1000
        Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 10:27 -0600
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:51 +0100
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-11 02:17 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:27 +0100

Page 2 of 2 — ← Prev page 1 [2]

#96353

On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> > Ah, that makes sense. It's writing into the dict that is created and
> > returned by locals(), but not actually updating the frame locals which
> > are the source of truth.
> 
> Yeah... but it only makes sense to people who understand the
> implementation. It's certainly not a logical and sane behaviour that
> would be worth documenting and using.

What else would you document? Reading from them is a reasonable thing to
do, and works. Writing to them is a reasonable thing to want to do, but
won't work, so you need to document that it doesn't work.

[toc] | [prev] | [next] | [standalone]

#96355

On Friday, September 11, 2015 at 9:27:46 PM UTC+5:30, rand...@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> > On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
> > > Ah, that makes sense. It's writing into the dict that is created and
> > > returned by locals(), but not actually updating the frame locals which
> > > are the source of truth.
> > 
> > Yeah... but it only makes sense to people who understand the
> > implementation. It's certainly not a logical and sane behaviour that
> > would be worth documenting and using.
> 
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

This is actually an old elusive holy grail -- first class environments.
In denotational semantics the two tools used to model variables and control-flow
respectively are environments and continuations.
The Scheme inventors were brave enough to mandate first-class continuations
but could not make the courage for first-class environments.
So every Scheme dialect introduces 1½ class envs in a ½-assed inconsistent way

Likewise python's locals-dicts and (I am guessing) most languages with some
commitment to first-classness

[toc] | [prev] | [next] | [standalone]

#96354

On Sat, Sep 12, 2015 at 1:57 AM,  <random832@fastmail.us> wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> > Ah, that makes sense. It's writing into the dict that is created and
>> > returned by locals(), but not actually updating the frame locals which
>> > are the source of truth.
>>
>> Yeah... but it only makes sense to people who understand the
>> implementation. It's certainly not a logical and sane behaviour that
>> would be worth documenting and using.
>
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

Documenting that "it doesn't work" seems fine. Documenting the
specific behaviour (that it gives you a sort of "shadow" locals, into
which you can write, but which won't persist past the execution of
that block of code) seems pointless. Especially since this behaviour
is implementation-dependent anyway.

ChrisA

[toc] | [prev] | [next] | [standalone]

#96356

On Fri, Sep 11, 2015 at 10:04 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Sep 12, 2015 at 1:57 AM,  <random832@fastmail.us> wrote:
>> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> > Ah, that makes sense. It's writing into the dict that is created and
>>> > returned by locals(), but not actually updating the frame locals which
>>> > are the source of truth.
>>>
>>> Yeah... but it only makes sense to people who understand the
>>> implementation. It's certainly not a logical and sane behaviour that
>>> would be worth documenting and using.
>>
>> What else would you document? Reading from them is a reasonable thing to
>> do, and works. Writing to them is a reasonable thing to want to do, but
>> won't work, so you need to document that it doesn't work.
>
> Documenting that "it doesn't work" seems fine. Documenting the
> specific behaviour (that it gives you a sort of "shadow" locals, into
> which you can write, but which won't persist past the execution of
> that block of code) seems pointless. Especially since this behaviour
> is implementation-dependent anyway.

It's documented in the standard library docs:
https://docs.python.org/3.4/library/functions.html#exec

I think that's probably sufficient.

[toc] | [prev] | [next] | [standalone]

#96385

On 11/09/2015 09:42, Steven D'Aprano wrote:
> On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:
>
>> On Thu, Sep 10, 2015 at 4:25 PM,  <tdev@freenet.de> wrote:
> [...]
>>> So the compiler knows the distiction between global and local already.
>>
>> As we've said before, it doesn't. The compiler's current rules are
>> fairly simple:
>>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>
> Almost. If it's never assigned within the function, then it is looked up
> according to the non-local scoping rules:
>
> - closures and enclosing functions (if any);
> - globals;
> - builtins;
>
> in that order.
>
>
>> 4) Otherwise, it's local.
>
> "Otherwise" meaning "if it is assigned to", except that "del" counts as an
> assignment. That is:
>
> def spam():
>      del x
>
> makes x a local variable inside the function spam.
>
>
> There's also a bunch of specialised and complicated rules for what happens
> if you make a star import ("from module import *") inside a function, or
> call eval or exec without specifying a namespace. Both of these things are
> now illegal in Python 3.
>
> And lastly, in Python 3 only, there is also a nonlocal declaration which
> works like global except it applies only to closures and enclosing
> functions.
>
>
>>> Another proof about identation:
>>> The parser can recognise identation with tabs and spaces.
>>
>> You can use tabs *or* spaces.
>
> In Python 3.
>
> In Python 2, you can mix tabs *and* spaces, and Python will try to guess
> what you mean. This causes more trouble than it is worth, and is removed in
> Python 3.
>
>
> [...]
>> I really doubt that you're going to gain any traction with this one,
>> because the decision that was made with Python 3 was to make the
>> compiler *more* rigid about not mixing tabs and spaces, not less.
>
> Correct.
>
> [...]
>>> Who is responding or has responded?
>>> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
>>> Presumably no core Python Programmers (wrting compiler and standard
>>> library stuff)
>>
>> Ad hominem.
>
> For the record, I am the author of the statistics module in Python 3.4, and
> Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
> my apologies. So, yes, there are core developers here.
>
> (Although not any of the senior core devs, as far as I know.)
>

IIRC Serhiy Storchaka pops in occasionally, as on the one genuine report 
from the RUE about the FSR.  Slight aside, I swear blind that Serhiy 
never sleeps as he always seems to be doing something on the bug tracker.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#96311

On 2015-09-11 01:35, Ian Kelly wrote:
> On Thu, Sep 10, 2015 at 4:25 PM,  <tdev@freenet.de> wrote:
[snip]
>> It is correct that there have to be a decision for spaces or tabs.
>> But sure not necessarily the exact same indentation to the right for each block.
>> Jus more same inserter to the right and the context is clear.
>
> I don't understand what you're trying to say here.
>
[snip]
I don't understand either, but perhaps he means that as long as the
lines of a suite are indented more than their introductory line, the
meaning should be clear (although "sibling" lines of the introductory
line should still be indented the same as the introductory line, e.g.
"elif" lines should still be indented the same amount as their "if"
line).

It would look untidy though! :-)

[toc] | [prev] | [next] | [standalone]

#96381

On 10/09/2015 23:25, tdev@freenet.de wrote:
> Some notes to the "global"-keyword and the other proposals.
>
> It has been proposed to have these six enhancements
>
> 1. optional keyword "global"

Won't happen.

> 2. switch statement

Won't happen.

> 3. less restrictive indentation

Won't happen.

> 4. universal scope

No idea what you mean by this.

> 5. goto label

Won't happen.

> 6- "include" script statement

No idea what you mean by this.

>
> with following proofs uncommented:
>

Your "proofs" hold about as much water as a bottomless bucket.

> There is the big question:
>
> Who is responding or has responded?
> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
> Presumably no core Python Programmers (wrting compiler and standard library stuff)

Core Python Programmers have better things to do than waste their time 
on rubbish like this.  Examples include writing code and fixing bugs.  I 
understand that some of them are actually really weird and do other 
things like paid jobs, see their families, take holidays and worst of 
all, have other hobbies.

>
> On Google groups you can currently read for this thread:
> 37 Authors. 152 posts. 443 views.
>
> That is not that much for views (probably mostly from the writer's itself)
>
> So, is this really the place where a PEP can be started?
> When has a proposal to be accepted? If ten-thousands say yes?
> Which ten-thousands? Who decides it?
>

The BDFL or his delegate decides, not that a PEP like this should be 
written.  If you want to waste your time please feel free to go ahead, I 
won't stop you.  However I do feel you should put this on python-ideas 
where it will be shot to pieces and then with any luck we'll get some 
peace and quiet.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web