>But libraries can act as embeded languages too. Of course. For example, it would be quite possible for me to create code like this in Stackless Python, if I desired: import JoesEvilPackage label = JoesEvilPackage.CreateLabel() print "looping infinitely..." JoesEvilPackage.GotoLabel (label) At a guess, I could do this without Stackless on Unix systems with blatant abuses of setjmp() and longjmp(). Easy access to C-language primitives (read: "extending and embedding") are one of Python's fortes, veritably one of the prime reasons PER SE which lead to the birth of the language. >"Extending" a language does not imply changing the semantics of the >language that is already there -- Quite correct. >I know one thing for sure: I know more about programming languages and >programming language design than you do or ever will ... Well, perhaps you're a bit of a prima donna, but you may very well be right; I've observed over the years that the more exposure to various languages one has, the less dogmatic one tends to be. I hope you're not mistaking you interaction with this one person as some kind of indication of the character of the Python community, by the way: Pythoners tend to be fairly open minded, in general, even if we do value simplicity to the point of being rather rabid about it. Mr. Peters was quite right: the correct thing to do is submit a PEP. Major bonus points if you grab the Python source and create a patch which allows hygienic procedural macros for those who would like to add this patch to their installation. C//
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4