Python handles globals badly.

[Ian Kelly]

On Thu, Sep 10, 2015 at 4:25 PM,  <tdev at freenet.de> wrote:
> with following proofs uncommented:

None of these are "proofs".

> Each sample provided would work without global
> (or you get runtime failure while try to write a global).

What samples? It would be easier to follow your messages if you would
include quotes from previous messages as context.

> 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.
4) Otherwise, it's local.

If you take out step 2, then the compiler has no way of distinguishing
whether a variable that is assigned to is local or global.

> Another proof about identation:
> The parser can recognise identation with tabs and spaces.

You can use tabs *or* spaces. If you want to mix the two, then there
would need to be some official decision made about how many spaces
compose a tab, and then everybody who wants to use tabs would have to
configure their editors to conform to that decision, or risk breaking
their code. Some people like to indent two spaces. Some people like to
indent four spaces. On the other hand, the de facto standard for
terminal tab width is eight spaces. However, virtually nobody prefers
eight spaces of indentation. So the question is which standard are you
going to adopt, and which groups are you going to upset?

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.

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

> But all proposals are more or less fully denied - for more or less no reasons.

You've been given reasons. You seem unwilling to accept them.

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

Ad hominem.

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

This is not a Google Group. This is the comp.lang.python newsgroup,
which is mirrored bidirectionally to the python.org python-list
mailing list. Google Groups provides another portal to the newsgroup.
There is no way to measure how many users have been reading this
thread in the newsgroup or the mailing list.

> So, is this really the place where a PEP can be started?

No, this list is for general Python discussion. The place to present a
PEP is the python-dev mailing list. It is generally considered
advisable to post the idea to the python-ideas mailing list first, to
find support for the idea and to hone it before going to the trouble
of writing a PEP.

If you do get to the point of writing a PEP, you will also need to
have a clear picture of how you plan to actually implement the idea.
It's not enough to just propose that "the global keyword should be
optional". Precisely how would scopes be determined? How would you
ensure backward compatibility? These are questions that would need
answers before anything could be implemented.

> When has a proposal to be accepted? If ten-thousands say yes?
> Which ten-thousands? Who decides it?

That's up to the BDFL.