Re: python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin wrote: Huh? Expressions are not statements except when they're expression statements? What kind of expression is not an expression statement? any expression that is used in a content that is not an expression statement, of course. Come on, that is vacuous. The claim was expressions are not statements. But it turns out that expressions ARE statements. no, expressions CAN BE USED as statements. that doesn't mean that they ARE statements, unless you're applying belgian logic. (if you have a problem figuring this out, try substituting other things for expressions and statements, and see if you still think that can be used as and are are always the same thing. try fish and pillow, for example). It's just an artifact. Whether the artifact is a desirable one is a matter of discussion. no, it's Python, and it's designed this way on purpose. go read the language reference. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-13, Terry Reedy schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Op 2005-01-13, Fredrik Lundh schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. And what else is an expression statement but an expression (list) used as a statement. Whereas an expression used within a statement is not a statement, and that is the difference. And of course, statements, in general, are not expressions and are not used within statements (except within compound statements). Here you are stating the opposite of what Guido is supposed to have said. IMO we have a: dogs are mamals kind of relationship in Python. Every expression can be used where a statement is expected. (And this can be worded as: every expression is a statement.) Not every statement can be used where an expression is expected. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-14, Fredrik Lundh schreef [EMAIL PROTECTED]: Paul Rubin wrote: Huh? Expressions are not statements except when they're expression statements? What kind of expression is not an expression statement? any expression that is used in a content that is not an expression statement, of course. Come on, that is vacuous. The claim was expressions are not statements. But it turns out that expressions ARE statements. no, expressions CAN BE USED as statements. that doesn't mean that they ARE statements, unless you're applying belgian logic. No I am applying set logic. Any string that is in the set of valid expressions is also in the set of valid statements. Like any animal that is in the set of dogs is also in the set of mamals. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Antoon Pardon wrote: no, expressions CAN BE USED as statements. that doesn't mean that they ARE statements, unless you're applying belgian logic. No I am applying set logic. Any string that is in the set of valid expressions is also in the set of valid statements. since you're arguing that one concept is identical to another concept, that operation has to work in both directions. Like any animal that is in the set of dogs is also in the set of mamals. and all mammals are dogs? it this a language problem? do you have problems parsing the statements you reply to? even when someone explictly says Given that we are having this discussion in the context of, you chose to ignore that context. what's wrong with you? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-14, Nick Coghlan schreef [EMAIL PROTECTED]: Antoon Pardon wrote: No I am applying set logic. Any string that is in the set of valid expressions is also in the set of valid statements. According to Python's grammar, this is not the case. It requires a NEWLINE or ; token on the end to turn the expression into a statement. Actually appending either of those tokens means the string is no longer an expression. Well you are correct, but by the same logic an expression_stmt isn't a statement either. In point of fact none of the specifics_stmt is a statement including an assignment. But changing statements to simple statements seems to make the assertion correct. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Fredrik no, expressions CAN BE USED as statements. that doesn't mean Fredrik that they ARE statements, unless you're applying belgian logic. Hmmm... I'd never heard the term belgian logic before. Googling provided a few uses, but no formal definition (maybe it's a European phrase so searching for it in English is futile). The closest thing I found was Or is it another case of Belgian logic, where you believe it because theres no evidence or motive whatsoever? Fredrik no, it's Python, and it's designed this way on purpose. go Fredrik read the language reference. What he said... While Python borrows stuff from other languages where they fit, it has a few core syntactic features that taken together distinguish it from other languages. Not allowing any statements to be used as expressions is one of them. Note that both expression and statement are context-sensitive terms. Fredrik applied them in their Python sense (go read the language reference), while Paul (perhaps naively, perhaps provocatively) seems bent on forcing a more general definition of the two words on the thread. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-14, Fredrik Lundh schreef [EMAIL PROTECTED]: Antoon Pardon wrote: no, expressions CAN BE USED as statements. that doesn't mean that they ARE statements, unless you're applying belgian logic. No I am applying set logic. Any string that is in the set of valid expressions is also in the set of valid statements. since you're arguing that one concept is identical to another concept, that operation has to work in both directions. No I'm not. is doesn't mean the concepts are the same. Like any animal that is in the set of dogs is also in the set of mamals. and all mammals are dogs? No but every dog is a mammal, and saying that doesn't imply dog and mammal are identical concepts it this a language problem? do you have problems parsing the statements you reply to? even when someone explictly says Given that we are having this discussion in the context of, you chose to ignore that context. what's wrong with you? Well IMO I have explained clearly that I understood this in a set logical sense in my first response. It seems you chose to ignore that context. So what's wrong with you? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Skip Montanaro wrote: Fredrik no, expressions CAN BE USED as statements. that doesn't mean Fredrik that they ARE statements, unless you're applying belgian logic. Hmmm... I'd never heard the term belgian logic before. Googling provided a few uses, but no formal definition (maybe it's a European phrase so searching for it in English is futile). The closest thing I found was Or is it another case of Belgian logic, where you believe it because theres no evidence or motive whatsoever? Maybe it's Belgain logic, as opposed to Dutch logic. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Craig Ringer schrieb:
And then we have iteration
(generator expressions, list comprehensions, for loops, ...?) over
(sequences, iterators, generators)
Just sequences and iterators. Generators are functions which return
iterators. Sequences and iterators provide two ways to build
containers.
My use cases:
finite, can be defined by enumeration: use sequence
infinite, must be defined algorithmically: use iterator
generator: neat way to produce an iterator, can also be viewed as
a persistent function call (better than static local variables).
Once defined, sequences and iterators have nearly the same interface.
To have list comprehensions but no equivalent for iterators would
be strange.
I happen to be extremely fond of the flexibility this provides, but one
obvious way to do it there is not.
Development of the language, backward compatibility and obviousness
are diverging goals. You can't satisfy them all at the same time.
And goals provide a direction but are rarely reached. :)
--
---
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Skip Montanaro wrote: Fredrik no, expressions CAN BE USED as statements. that doesn't mean Fredrik that they ARE statements, unless you're applying belgian logic. Hmmm... I'd never heard the term belgian logic before. Googling provided a few uses, but no formal definition (maybe it's a European phrase so searching for it in English is futile). The closest thing I found was Or is it another case of Belgian logic, where you believe it because theres no evidence or motive whatsoever? Fredrik no, it's Python, and it's designed this way on purpose. go Fredrik read the language reference. snip IANA French person, but I believe that Belgians are traditionally regarded as stupid in French culture, so Belgian logic would be similar to Irish logic for an English person. (Feel free to insert your own cultural stereotypes as required. :) -- Website: www DOT jarmania FULLSTOP com -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Skip Montanaro wrote: Fredrik no, expressions CAN BE USED as statements. that doesn't mean Fredrik that they ARE statements, unless you're applying belgian logic. Hmmm... I'd never heard the term belgian logic before. Googling provided a few uses, but no formal definition (maybe it's a European phrase so searching for it in English is futile). I'm from Belgium, and I've never heard it before either. Probably a public secret, very carefully being kept hidden from us Belgians ;) -- Codito ergo sum Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Antoon Pardon wrote: IMO we have a: dogs are mamals kind of relationship in Python. I see what you mean, but I don't think it's true. Every expression can be used where a statement is expected. (And this can be worded as: every expression is a statement.) Not really. An expression statement is a statement that looks like an expression, but actually it's more than that: not only does it calculate the value of the expression, it also prints the value. Note that it would be perfectly possible to modify the syntax into expression_stmt ::= exprstmt expression_list so that you would have to write exprstmt 6*9 instead of just 6*9 That makes it clearer to see the distinction: 6*9 is an expression, exprstmt 6*9 is a statement. An expression statement, more precisely. Not every statement can be used where an expression is expected. AFAIK *no* statement can be used where an expression is expected. -- Codito ergo sum Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-14, Roel Schroeven schreef [EMAIL PROTECTED]: Antoon Pardon wrote: IMO we have a: dogs are mamals kind of relationship in Python. I see what you mean, but I don't think it's true. Every expression can be used where a statement is expected. (And this can be worded as: every expression is a statement.) Not really. An expression statement is a statement that looks like an expression, but actually it's more than that: not only does it calculate the value of the expression, it also prints the value. 1) Only in an interactive environment. 2) That the semantics differ according to where the expression is used doesn't make a difference. That an expression decides which branch of an if statement is executed or what object is pass as an argument in a call are also semantic difference, yet we still have an expression in both cases. Note that it would be perfectly possible to modify the syntax into expression_stmt ::= exprstmt expression_list so that you would have to write exprstmt 6*9 instead of just 6*9 That makes it clearer to see the distinction: 6*9 is an expression, exprstmt 6*9 is a statement. An expression statement, more precisely. If you change the syntax, of course you will change the strings that will be accepted. I could change the syntax to: if_stmt ::= if ifexpr expression ... Have I now proved that expressions after an if are not normal expressions? Not every statement can be used where an expression is expected. AFAIK *no* statement can be used where an expression is expected. But that was not the implication of what Guido supposedly had said. So that this is not the case doesn't counter what I said. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Antoon Pardon wrote: Well IMO I have explained clearly that I understood this in a set logical sense in my first response. what does first mean on your planet? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-12, Steve Holden schreef [EMAIL PROTECTED]: Given that Guido is on record as saying that expressions aren't statements because he wants those things to be separate, I don't really see why there's this consistent pressure to reverse that decision. Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. More specifically, everywhere you can use a statement, you can simply use an expression according to the python syntax. That makes the set of expressions a subset of the set of statements and thus makes an expression a statement. Which would be a worthier goal than trying to graft macros on to Python. You responded that macros would be difficult to implement in m4 because (in essence) of the indented structure of Python. I'm not convinced they'd be any easier in Python, and I'm *certainly* not convinced that their addition would improve Python's readability. At best it would offer new paradigms for existing constructs (violating the there should be one obvious way to do it zen); at worst it would obfuscate the whole language. That zen is already broken. Look at the number of answers one gets if a newbee askes for a ternary operator. I think that a simple ternary operator or macro's with an official supported macro that implemented the ternary operator would have been far closer to the spirit of only having one obvious way than what we have now. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Antoon Pardon wrote: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Op 2005-01-13, Fredrik Lundh schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. And what else is an expression statement but an expression (list) used as a statement. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Fredrik Lundh wrote: Antoon Pardon wrote: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. OK then, The documentation clearly states that not all statements can be expressions. Specifically Guido has justified the fact that an assignment does not return any value, and therefore cannot be used as a component of an expression. Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be listening to me :-) regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
On Thu, 2005-01-13 at 08:39 +, Antoon Pardon wrote: At best it would offer new paradigms for existing constructs (violating the there should be one obvious way to do it zen); at worst it would obfuscate the whole language. That zen is already broken. Look at the number of answers one gets if a newbee askes for a ternary operator. I think that a simple ternary operator or macro's with an official supported macro that implemented the ternary operator would have been far closer to the spirit of only having one obvious way than what we have now. And then we have iteration (generator expressions, list comprehensions, for loops, ...?) over (sequences, iterators, generators) I happen to be extremely fond of the flexibility this provides, but one obvious way to do it there is not. -- Craig Ringer -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Terry Reedy [EMAIL PROTECTED] writes: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. And what else is an expression statement but an expression (list) used as a statement. Whereas an expression used within a statement is not a statement, and that is the difference. Huh? Expressions are not statements except when they're expression statements? What kind of expression is not an expression statement? And logic would indicate that if we can separate statements from expressions and still have expression statements, nothing stops us from also being able to have statement expressions. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
On Thu, 13 Jan 2005 09:29:49 -0500, Steve Holden [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: Antoon Pardon wrote: Well, it seems that Guido is wrong then. The documentation clearly states that an expression is a statement. no, it says that an expression statement is a statement. if you don't understand the difference, please *plonk* yourself. OK then, The documentation clearly states that not all statements can be expressions. Specifically Guido has justified the fact that an assignment does not return any value, and therefore cannot be used as a component of an expression. Hm, that makes me wonder, is there an intermediate returning of value in x = y = z = 123 ? Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be listening to me :-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Fredrik Lundh [EMAIL PROTECTED] writes: Huh? Expressions are not statements except when they're expression statements? What kind of expression is not an expression statement? any expression that is used in a content that is not an expression statement, of course. Come on, that is vacuous. The claim was expressions are not statements. But it turns out that expressions ARE statements. The explanation is well, that's because they're expression statements. And there is no obvious case of an expression that can't be used as a statement. So it's not inherently obvious that there needs to be any kind of statement that can't be used as an expression. It's just an artifact. Whether the artifact is a desirable one is a matter of discussion. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin wrote: Come on, that is vacuous. The claim was expressions are not statements. But it turns out that expressions ARE statements. The explanation is well, that's because they're expression statements. And there is no obvious case of an expression that can't be used as a statement. So it's not inherently obvious that there needs to be any kind of statement that can't be used as an expression. It's just an artifact. Whether the artifact is a desirable one is a matter of discussion. No, it's entirely to do with building a readable language that uses significant whitespace to delineate scope. Simple statements are not allowed to contain other statements, but they are allowed to contain expressions. In their most degenerate form, ALL they contain is a *single* expression (e.g. a function call). That expression itself is still not a statement, though. Think of it as the difference between value and [value]. Suites are sequences of statements. Compound statements are statements which incorporate a suite as part of their syntax. Python allows statements inside suites and suites inside compound statements. It also allows expressions inside statements and expressions inside expressions. The one thing it never ever does is allow a suite or a statement inside an expression, because doing so would utterly destroy the handling of significant white space. And that's why expressions are special in Python - they demarcate the boundary of the significance of whitespace. Within an expression, whitespace is insignificant. At the level of statements and suites, whitespace is extremely significant. So, precisely how should one go about cleanly embedding something that cares about whitespace into a context which doesn't care in the slightest? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Nick Coghlan [EMAIL PROTECTED] writes: So, precisely how should one go about cleanly embedding something that cares about whitespace into a context which doesn't care in the slightest? Treat the macro like a function call whose arguments are thunks made from the macro arguments, or something like that. There's been some discussions about it on clpy in the past, by people more into this stuff than I am. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
[EMAIL PROTECTED] writes: I can't imagine how it could be worse than the learning curve of __metaclass__, which we already have. To me, learning macros *and their subtilities* was much more difficult than learning metaclasses. I guess I've only used Lisp macros in pretty straightforward ways, that weren't hard to understand. That's enough for anything I've needed. But we don't hear much about __metaclass__ because almost nobody understands it. Go to comp.lang.scheme and google for macros and module system; you will get everything you want to know and much more! OK, I might do this. Well, I see this as a positive fact. If a syntax is contrived (such as a ternary operator, for instance) it is better *not* to have it than to have one hundred custom made syntaxes. At the end, we are just talking about syntax sugar here, not about lack of functionality. I think the idea is there would be some experimentation and then one of the versions would make it into the standard library. [compiling Lisp to Python bytecode] This is a bizarre idea if you want to make Python run faster. It is not so bizarre if what you want is to have access to Python from Lisp/Scheme in the same sense Jython has access to Java. Why not just use a foreign function interface? -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin wrote: [EMAIL PROTECTED] writes: 2. One could proposed hygienic pattern-matching macros in Python, similar to Scheme syntax-rules macros. Again, it is not obvious how to implement pattern-matching in Python in a non-butt-ugly way. Plus, I feel hygienic macros quite limited and not worth the effort. It wasn't obvious how to do it in Scheme either. There was quite a bit of head scratching and experimental implementation before there was consensus. 3. We would add to Python the learning curve of macros and their subtilities and we do not want it. I can't imagine how it could be worse than the learning curve of __metaclass__, which we already have. If it was done in a way that most of us would just rely on a few standard ones, that would be fine. Well the necessity to understand metaclasses could in some ways be regarded as the push for the summit, and therefore isn't something that would trouble newbies. Given that we are having this discussion in the context of a posited where clause intended to allow multi-statement expressions (whatever they turn out to be) I would still argue you are discussing the totally unnecessary. Given that Guido is on record as saying that expressions aren't statements because he wants those things to be separate, I don't really see why there's this consistent pressure to reverse that decision. 4. Macros would complicate a lot Python module system. I don't see how, but maybe I'm missing something. 5. We have Guido providing a good syntax for us all, why we should be fiddling with it? More seriously, if some verbosity is recognized in the language (think to the raison d'etre of decorators, for instance) I very much prefer to wait for Guido to take care of that, once and for all, than having 100 different custom made solutions based on macros. Every time some newbie asks an innocent how do I ... question, we see unbelievably horrid answers from gurus. Just check the FAQ about conditional expressions, etc. I just don't see Python syntax changes as forthcoming. There's a reason for this ... What I would be interested in is a Lisp/Scheme implementation compiling to Python bytecode, but I am not aware of any project in that direction. But that sounds like a bizarre idea. Python bytecode is just a CPython artifact, not part of the language. And it's not even that good an artifact. Good Lisp/Scheme implementations compile to native code that beats the pants off of CPython bytecode. It would make much more sense to have a Python implementation that compiles Python to S-expressions and then lets a high performance Lisp or Scheme system take care of the rest. Which would be a worthier goal than trying to graft macros on to Python. You responded that macros would be difficult to implement in m4 because (in essence) of the indented structure of Python. I'm not convinced they'd be any easier in Python, and I'm *certainly* not convinced that their addition would improve Python's readability. At best it would offer new paradigms for existing constructs (violating the there should be one obvious way to do it zen); at worst it would obfuscate the whole language. If you really see the need for Python macros then a preprocessor would surely be the best way to prove the validity of such ideas? regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin wrote: [EMAIL PROTECTED] writes: I can't imagine how it could be worse than the learning curve of __metaclass__, which we already have. To me, learning macros *and their subtilities* was much more difficult than learning metaclasses. I guess I've only used Lisp macros in pretty straightforward ways, that weren't hard to understand. That's enough for anything I've needed. But we don't hear much about __metaclass__ because almost nobody understands it. Paraphrasing Tim Peters, if you don't definitely know that you need metaclasses then you almost certainly don't. The primary reason for the existence of metaclasses is as an implementation detail that allows basic Python types to be base classes for inheritance. Python could have hidden this mechanism, but the generally introspective nature of the language makes it sensible to expose the mechanism for (ab)use by knowledgeable users. Go to comp.lang.scheme and google for macros and module system; you will get everything you want to know and much more! OK, I might do this. Well I'd be interested to know what you find out, not being a Lisper myself. Well, I see this as a positive fact. If a syntax is contrived (such as a ternary operator, for instance) it is better *not* to have it than to have one hundred custom made syntaxes. At the end, we are just talking about syntax sugar here, not about lack of functionality. I think the idea is there would be some experimentation and then one of the versions would make it into the standard library. Erm, you'd put syntax into a library module? That would be in __future__, I take it? [compiling Lisp to Python bytecode] This is a bizarre idea if you want to make Python run faster. It is not so bizarre if what you want is to have access to Python from Lisp/Scheme in the same sense Jython has access to Java. Why not just use a foreign function interface? regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
[EMAIL PROTECTED] writes: 2. One could proposed hygienic pattern-matching macros in Python, similar to Scheme syntax-rules macros. Again, it is not obvious how to implement pattern-matching in Python in a non-butt-ugly way. Plus, I feel hygienic macros quite limited and not worth the effort. It wasn't obvious how to do it in Scheme either. There was quite a bit of head scratching and experimental implementation before there was consensus. 3. We would add to Python the learning curve of macros and their subtilities and we do not want it. I can't imagine how it could be worse than the learning curve of __metaclass__, which we already have. If it was done in a way that most of us would just rely on a few standard ones, that would be fine. 4. Macros would complicate a lot Python module system. I don't see how, but maybe I'm missing something. 5. We have Guido providing a good syntax for us all, why we should be fiddling with it? More seriously, if some verbosity is recognized in the language (think to the raison d'etre of decorators, for instance) I very much prefer to wait for Guido to take care of that, once and for all, than having 100 different custom made solutions based on macros. Every time some newbie asks an innocent how do I ... question, we see unbelievably horrid answers from gurus. Just check the FAQ about conditional expressions, etc. I just don't see Python syntax changes as forthcoming. What I would be interested in is a Lisp/Scheme implementation compiling to Python bytecode, but I am not aware of any project in that direction. But that sounds like a bizarre idea. Python bytecode is just a CPython artifact, not part of the language. And it's not even that good an artifact. Good Lisp/Scheme implementations compile to native code that beats the pants off of CPython bytecode. It would make much more sense to have a Python implementation that compiles Python to S-expressions and then lets a high performance Lisp or Scheme system take care of the rest. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin: [EMAIL PROTECTED] writes: about Scheme macros It wasn't obvious how to do it in Scheme either. There was quite a bit of head scratching and experimental implementation before there was consensus. Actually I am not convinced there is consensus yet, i.e. there is a non-negligible minority of schemers convinced that original Lisp macros where better, not to talk of common lispers ;) 3. We would add to Python the learning curve of macros and their subtilities and we do not want it. I can't imagine how it could be worse than the learning curve of __metaclass__, which we already have. To me, learning macros *and their subtilities* was much more difficult than learning metaclasses. 4. Macros would complicate a lot Python module system. I don't see how, but maybe I'm missing something. Go to comp.lang.scheme and google for macros and module system; you will get everything you want to know and much more! 5. We have Guido providing a good syntax for us all, why we should be fiddling with it? More seriously, if some verbosity is recognized in the language (think to the raison d'etre of decorators, for instance) I very much prefer to wait for Guido to take care of that, once and for all, than having 100 different custom made solutions based on macros. Every time some newbie asks an innocent how do I ... question, we see unbelievably horrid answers from gurus. Just check the FAQ about conditional expressions, etc. I just don't see Python syntax changes as forthcoming. Well, I see this as a positive fact. If a syntax is contrived (such as a ternary operator, for instance) it is better *not* to have it than to have one hundred custom made syntaxes. At the end, we are just talking about syntax sugar here, not about lack of functionality. What I would be interested in is a Lisp/Scheme implementation compiling to Python bytecode, but I am not aware of any project in that direction. But that sounds like a bizarre idea. Python bytecode is just a CPython artifact, not part of the language. And it's not even that good an artifact. Good Lisp/Scheme implementations compile to native code that beats the pants off of CPython bytecode. It would make much more sense to have a Python implementation that compiles Python to S-expressions and then lets a high performance Lisp or Scheme system take care of the rest. This is a bizarre idea if you want to make Python run faster. It is not so bizarre if what you want is to have access to Python from Lisp/Scheme in the same sense Jython has access to Java. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
