Python design strategy (was Python evolution: Unease)
Viile writes - >Type declarations are a feature that might benefit IronPython and >Jython more than they would CPython. How much is this part of Guido's decisionmaking process? Guido is , IMO, very much a strategist, as well as a language designer. That's good, I think. However it seems to me he is much more comfortable discussing language design with the community. then he is in discussing strategy. That, I think, is a strategic decision. Understandable, in fact. Nonetheless, I have been uncomfortable with this strategy in the past. For my own reasons. But had no good basis to question the strategy, as strategy.. With the language design issue now on the table, I think I can go further and question the strategy, as such. The question of *why* needs to be fully discussed with the community as part of this exercise, IMO. The "why" that does not give the BDFL's strategic thinking its due weight will not be a fully honest discussion. But what is the BDFL's strategic thinking. Will he stay vague? That it will help certain kinds of projects has been mentioned by Guido. Which specific projects now underway of which he is aware? Why is it important to accommodate those projects? What is Guido's motivation, at this level? Can we ask? Can he answer? In some specifics? To implictly direct the converstaion to the highly technical,. and implicitly assert community concensus should be reached strictly from a language design perspective on the merits, assures us more community damage then is necessary in sorting this one out. Because we won't be having the real conversation. IMO. Art -- http://mail.python.org/mailman/listinfo/python-list
Another scripting language implemented into Python itself?
Cameron writes: >Pronouns quickly overload me. On a reread of my post, me, we and they and I all sympathize. >f you're saying that there's hysteria >afoot, much of it about the harm that might come through use of >computers left unprotected from evildoers, well, yes, I'm with you. >Most people have far more important hazards in their lives and work >than "security violations" as we technologists generally conceive them. That is what I am saying, admitted not very well. As it happens, though, I don't particularly finger the technologists as the culprits. Strangely, much of it can be traced to the fallout of Enron, though of course Enron had nothing to do with this realm of evil in any way. Most particularly ironic is the fact that is the same strata of the business community (broadly speaking I am part of that community) that bears a good deal of responsibility for Enron that has jumped on the opportunity to cash in on its fallout. Lovely. Art -- http://mail.python.org/mailman/listinfo/python-list
re: Marketing reST (was Re: What YAML engine do you use
Aahz writes - >While I can see how you'd get that impression of reST, it's not true: >like Python, reST is intended to be simpl*er* and readable, but not >simple. Really? ;) Thanks for taking this one on. I was tempted. But scared ;) I find reST quite useful. Not a very sophisticated way to judge something designed to be useful. but the best I can do. Art -- http://mail.python.org/mailman/listinfo/python-list
re: variable declaration
MT writes - >In summary, again with all due respect and gratitude for the >spectacularly excellent product that Python is today, I wonder *why* >this strong aversion to declarative statements, and *whether* decorator >syntax constitutes a violation of it. I'd appreciate any responses or >links First be warned that I fit fairly well the profile Robert paints in the previous post on this thread - my life and livelihood do not depend on being a Python programmer. Though I would claim that my efforts to wrap my mind around it have enhanced both. Personal growth kind of thing. And I clutter this news group from time to time with observations which I admit are light on technical savy. I *can* tell you that some very bright, respected and technical members of the community argued *for* decorators on the exact grounds that Python needed to break away from its aversion to declarative statements. Someone like myself without a full grasp of the technical terminology and little grasp of the underlying structures, cannot tell you whether decorators are or are not declarative. I can observe that folks tend to get to where they want to get in these kinds of discussions by playing with the ambiguities in these kinds of words. >From an outside observer point of view, I seem to notice that in the world of programming, there seems to be more ambiguity in technical words than one would expect (or ideally like to see) in words that purport to be technical words. In short, I suspect there is a lot of semantics to be played with in answering your question. My own sense is that decorators do break a dam in Python, for better or for worse, and that it is OK to let folks provoke you into concluding for yourself what words best describe the specifics. But don't let the old hands convince you they represent business as usual. Though the authorative tone of your post indicates, I suspect, that this post was quite unnecessary. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: Introduction to 3D Graphics Programing
Xah Lee wrote: > Here's their license: > http://www.vpython.org/webdoc/visual/license.txt > > I read it wrong before. > Thanks for correction. > > This is superb! I'll be looking into vpython! > > Xah Of course it does what it does by resort to OpenGL and C++, so is part of the problem ;) I am looking forward to your tutorial efforts, and hoping those efforts can be accessed without exposure to too much polemics. Though if that is the price of admission, that is the price of admission. BTW, VPython is most of the way through a 4.xxx release which provides some nice additional functionality to the 3.xx series core - like transparency and texturing. Problem being the the lead developer has graduated and moved on, and the NSF funding that had supported the effort has run out. And the core folks around the project are either science educators or Python folks - there is little C++ expertise currently involved with the project. The project is looking for help. Anyone willing to jump in should perhaps reply here or at: [EMAIL PROTECTED] Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting line endings
Arthur wrote: > Arthur wrote: > Is my premise that tokenizer needs universal newline support to be > reliable correct? > > What else could put it out of sync with the complier? Anybody out there? Is my question, and the real world issue that provked it, unclear. Is the answer too obvious? Have I made *everybody's* kill list? Isn't it a prima facie issue if the tokenizer fails in ways incompatible with what the compiler is seeing? Is this just easy, and I am making it hard? As I apparently do with Python more generally. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: deriving from complex
Schüle Daniel wrote: > thank you > I will have to take a closer look on __new__ > > Regards, Daniel The pypy implementation of the complex builtin may give you some clues. I found it helpful. http://codespeak.net/svn/pypy/dist/pypy/lib/cmath.py Art -- http://mail.python.org/mailman/listinfo/python-list
Re: deriving from complex
Meant: http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/app_complex.py -- http://mail.python.org/mailman/listinfo/python-list
