On Sunday, March 13, 2016 at 6:35:40 PM UTC-5, Gregory Ewing wrote: > Unless the module is doing something obscure, you can > still find [it's source file] by following the chain of > imports. [...] True, it's not *always* that easy, but in > the vast majority of cases it is.
I agree you have a valid point, but i'll maintain that in no way, does this help to relieve the confining nature of these tightly wrapped "python module diapers", that we are all forced to wear. If our "Python motto" is to be, that we're "all adults", and we can trust our "siblings", and hopefully, *ourselves*, not to fiddle with aspects of our interfaces that are considered private, and, private by nothing more, mind you, than mere *convention*, then why do we take the opposite approach for modules, and force *ALL* code into a mandatory "one-size fits all" source file? Our ideology seems to be inconsistent here. Either we are adults capable of defining our own code, or we are immature babies who need mommy Python to protect us from every evil. But we cannot claim to be both. And don't misunderstand me, neither form of convention is "wrong". For instance, Java adopts a strict convention for writing code, but Java never claimed that it was a language that promoted "freedom". However, here in the Python community, we are constantly blabbing about how free we are, when in fact, our freedom is mostly a delusion. We need to stop making these false "claims of freedom". Heck, the only group of people more deluded about their own freedom, are my fellow Americans (Sometimes i really hate this country!) Python does not encourage freedom. Sure, we enjoy more "degrees of freedom" than say, your average Java programmer, but we must still submit to the many inconsistent whims of the Python interpreter. Outside of indention, we can't define how our code blocks will be structured. And, outside of nasty hacks, we can't decide how our module source files will reflect run-time module namespace. But most disturbing of all, there is no way possible, to protect the internals of our interfaces from public meddling. Many programmers don't understand *WHY* internals need to be protected. They will scoff at the idea, and they will claim that, by limiting *THEIR* ability to meddle with internals, *YOU* are robbing *THEM* of *THEIR* freedom. But what they don't realize, is that, the only crime worse than failing to create a proper interface, is to attempt to repair that failure *EXTERNALLY*. *ALL* repairs and *ALL* new features must be designed from *WITHIN* the object that exposes the interface, and from a strict internal perspective *ONLY*. Whether or not your language allows it, the following contractual obligations must *NEVER*, *EVER* be broken: (1) Callers can freely make requests to fetch or mutate a value, but they are forbidden from fetching and/or mutating the value directly. Only the object exposing the interface is capable of knowing how best to execute the request. If the caller finds that an accessor is missing, then the caller should beseech the source code maintainer to add the feature, or, they should add the feature themselves. But whoever adds the feature, they *MUST* do so in a manner that will not violate the basic contract between "callers" and "objects exposing an interface". (2) How a request is fulfilled, should be of no concern to an external caller. The only obligation the caller should expect of an interface, is that, when a formal request is sent, that a concerted attempt to fulfill the request will be made, and, if the request cannot be fulfilled, then a suitable explanation must be offered explaining why the request could not be fulfilled. You see, the object exposing the interface is *ALWAYS* submissive to the requests of any caller, but, if the caller attempts to break the "accessor contract", by entering the domain of the object exposing the interface, the object must block the invader by any means necessary, up to, and including, the fatal exception. Basically, the object exposing the interface adopts an attitude of: "Look, i'll do anything you ask me, so long as you ask me one of the questions posted on the door, but you have to make a formal request, you *CANNOT* just enter this sacred place at will, and start meddling with my levels and knobs, because if you do, you could cause a chain reaction that will destroy the delicate balance of our universe. I've had the unfortunate experience of maintaining code that did not utilize "strict interfacing contracts". Heck, for a good example of what *NOT* to do, have a look at the idlelib. (1) BAD STRUCTURE: A clear hierarchical structure is missing. It's spaghetti code, plain and simple. (2) COMPONENT COUPLING: Components are too tightly coupled, preventing easy plug-in and/or removal. (3) EVENT BINDINGS FIASCO: Instead of creating a "central interface" for which *ALL* event bindings would route on their way to the main editor widget, the author simply applied the bindings "in the shadows", from within various modules throughout the libray. Not only is this sort of design intuitive, it obfuscates important structural details, and it's one of the many reasons why this library has rotted for the last 20 or so years! (4): EXPORTABLE WIDGETS: Many of the widgets that were created for this library would have been useful to Python Tkinter GUI programmers over the years, however, they are missing much needed documentation, and some are written too specifically to be of use outside of IDLE (without heavy modifications). Granted, many of these widgets, like the Notebook and Balloon, have been offered by TIX for sometime, but Tix does not offer anything like Calltips, GrepDialog, ReplaceDialog, ClassBrowser., etc... But the most important is the Interactive Shell, which, if properly componentized, could be utilized to inspect code at run-time. It already has syntax coloring, calltips, code completion, and what have you. Heck, just the other day on Python-list, someone was opining for exactly that! (5): GENERAL TOOLS: A few general tools exist that could be used in other project.. That's all i can think of at the moment, but it hardly scratches the surface of what ailes this horrible stdlib module. Heck, i forgotten more sins of idlelib, than most people know about it. IDLE is a major failure, and i am saddened that it has existed in this state for such a long time. -- https://mail.python.org/mailman/listinfo/python-list
