On Tuesday, November 12, 2013 9:33:50 AM UTC-6, jongiddy wrote: > I'm not sure where you get the feeling you're accessing an > interface.
Because the constant PI should never change. Sure we can argue about granularity of PI, but that argument has no weight on the fact that PI should be a constant. By placing PI in the module "math", we are creating a pseudo interface. We (the creators) are "assuming" that PI will be a constant and never change, and the caller is assuming that pi will remain static, but not only can it be mutated, it can be mutated globally. math.pi is neither a constant nor a local module attribute, math.pi is really a global variable. This is true not only for math.pi, but ALL attributes of ALL python modules. > If I typed this, I would feel like I was trying > to change a fundamental constant. You have just > demonstrated that going into other modules and changing > their attributes (whether they are variables, functions or > classes) is generally a BAD idea, and I don't think I've > ever seen anyone recommend doing this, except possibly as > a workaround or for debugging purposes. On the other hand, > you initially suggested that modifying globals contained > within namespaces (i.e. modules) is a good way to > communicate between modules. You missed my point: only IF python modules were TRUE interfaces. It's not a good idea under python's current implementation of modules. My thread is intended to underscore this very design flaw. > This inconsistency There is no inconsistency in my logic, quite the contrary. I think you're having difficulty following along because you've been brainwashed by Python for too long. You've falsely believed that Python does not have globals, but it does! You just have to mutate then via a pseudo interface. > is why I was asking for a good example (i.e. > a realistic example where the use of global variables > provides the best solution). I gave a good example in my very first post: RR: "Globals are justified when they are used to [share] information between scopes that otherwise were meant to be mutually exclusive. One good example would be package sub-modules." > Just because a tool allows you to do something does not > make it a good idea. Try this paraphrase of your last > post: Ladder designers act like standing on the top rung > is SO evil, but then they give us ladders with a top rung, > Are they just trying to fool themselves, or fool us? EXACTLY. And whilst your comparison is both intelligent and funny, you're just re-iterating my point! We have all been brainwashed by authorities. First they give us rules, then they give us the power to break those rules. If standing on the top rung is SO dangerous, then don't manufacture your ladders with top rungs. Else, shut up about it! "THOU SHALT NOT KILL" Well i can't live WITH the B!@$%!!! "THOU SHALT NOT COMMIT ADULTERY" Then why create me with a unquenchable desire for sex? "THOU SHALT NOT TAKE THE LORDS NAME IN VAIN" GOD DAMMIT! Stop making all these opposing rules. So the designers detest globals huh? But python module attributes are really global because they can be accessed and mutated ANYWHERE!". This enigma leads to two logical design philosophies: (anything else is folly) 1. Accept that globals are useful, and make them available through a "real" global syntax, not some attribute of a module that "appears" to be local, but in reality is global. Then prevent external mutation of module attributes directly, and instead, require that mutation must follow a contract defined by internal module "setter" functions. 2. Remain convinced that global mutation is evil and prevent mutation of all python module attributes. You can import modules, but you can't mutate their contents. THIS IS HOW YOU DESIGN FOR CONSISTENCY, NOT HYPOCRISY! @LanguageDesigners: But whatever you do, don't hide globals behind pseudo interfaces, because then you have created something worse than a global; you've created a global in sheep's clothing. And you're a hypocrite. -- https://mail.python.org/mailman/listinfo/python-list