On Thu, Sep 10, 2015 at 4:25 PM, <t...@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. -- https://mail.python.org/mailman/listinfo/python-list
