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: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote:
as equivalent to:
def __use_stmt():
use-suite
def _in_clause():
in-suite
return names
return _in_clause()
__use_stmt_args = {}
names = __use_stmt()
del __use_stmt
The more I think about this return-based approach, the less I like it. It could
probably be made to work, but it just feels like a kludge to work around the
fact that the only mechanisms available for altering the bindings of local names
are assignment and definition statements.
For class namespaces, getattr(), setattr() and delattr() work a treat, and
globals() works fine for module level name binding.
locals() is an unfortunate second class citizen, since it writes to it aren't
propagated back to the executing frame. Programmatic interrogation of locals is
fine, but update is impossible.
What would be interesting is if locals() returned a dictionary whose __setitem__
method invoked PyFrame_LocalsToFast on the relevant frame, instead of a vanilla
dictionary as it does now.
Then locals()[x] = foo would actually work properly.
Notice that you can get this effect today, by using exec to force invocation of
PyFrame_LocalsToFast:
Py def f():
... n = 1
... def g(outer=locals()):
...outer[n] += 1
... g() # Does not affect n
... print n
... exec g() # DOES affect n
... print n
...
Py f()
1
2
(The call to g() has to be inside the exec statement, since the exec statement
evaluation starts with a call to PyFrame_FastToLocals).
Assuming a writeable locals(), the semantics for the normal case are given by:
def __use_stmt(__outer):
use-suite
in-suite
__inner = locals()
for name in names:
__outer[name] = __inner[name]
__use_stmt(locals())
del __use_stmt
And for the 'delayed execution' case:
def __named_use_stmt(__outer):
use-suite
def __delayed_block():
in-suite
__inner = locals()
for name in names:
__outer[name] = __inner[name]
return __delayed_block
in-name = __named_use_stmt(locals())
del __named_use_stmt
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]
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: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
I've come to the conclusion that these semantics aren't what I would expect from
the construct. Exactly what I would expect can't really be expressed in current
Python due to the way local name bindings work. The main thing to consider is
what one would expect the following to print:
def f():
a = 1
b = 2
print 1, locals()
print 3, locals() using:
a = 2
c = 3
print 2, locals()
print 4, locals()
I think the least suprising result would be:
1 {'a': 1, 'b': 2} # Outer scope
2 {'a': 2, 'c': 3} # Inner scope
3 {'a': 2, 'b': 2, 'c': 3} # Bridging scope
4 {'a': 1, 'b': 2} # Outer scope
In that arrangement, the statement with a using clause is executed normally in
the outer scope, but with the ability to see additional names in its local
namespace. If this can be arranged, then name binding in the statement with the
using clause will work as we want it to.
Anyway, I think further investigation of the idea is dependent on a closer look
at the feasibility of actually implementing it. Given that it isn't as
compatible with the existing nested scope structure as I first thought, I
suspect it will be both tricky to implement, and hard to sell to the BDFL
afterwards :(
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote:
def f():
a = 1
b = 2
print 1, locals()
print 3, locals() using:
a = 2
c = 3
print 2, locals()
print 4, locals()
I think the least suprising result would be:
1 {'a': 1, 'b': 2} # Outer scope
2 {'a': 2, 'c': 3} # Inner scope
3 {'a': 2, 'b': 2, 'c': 3} # Bridging scope
4 {'a': 1, 'b': 2} # Outer scope
Personally, I think that the fact that the bridging statement is
executed *after* the inner code block guarantees that results will be
surprising. The fact that it effectively introduces *two* new scopes
just makes matters worse.
It also seems to me that one could do this using a nested function def
with about the same results. You wouldn't have a bridging scope with
both sets of names as locals, but your nested function would have
access to the outer namespace via normal nested scopes, so I'm really
not seeing what the gain is...
(Then again, I haven't been following the whole using/where thread,
because I don't have that much free time and the initial postings
failed to convince me that there was any real point...)
Jeff Shannon
Technician/Programmer
Credit International
In that arrangement, the statement with a using clause is executed
normally in the outer scope, but with the ability to see additional
names in its local namespace. If this can be arranged, then name binding
in the statement with the using clause will work as we want it to.
Anyway, I think further investigation of the idea is dependent on a
closer look at the feasibility of actually implementing it. Given that
it isn't as compatible with the existing nested scope structure as I
first thought, I suspect it will be both tricky to implement, and hard
to sell to the BDFL afterwards :(
Cheers,
Nick.
--
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: Statement local namespaces summary (was Re: python3: 'where' keyword)
On Fri, 14 Jan 2005 01:48:48 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Semantics
-
The code::
statement with:
suite
translates to::
def unique_name():
suite
statement
unique_name()
I've come to the conclusion that these semantics aren't what I would expect
from
the construct. Exactly what I would expect can't really be expressed in
current
Python due to the way local name bindings work. The main thing to consider is
what one would expect the following to print:
def f():
a = 1
b = 2
print 1, locals()
print 3, locals() using:
a = 2
c = 3
print 2, locals()
print 4, locals()
I think the least suprising result would be:
1 {'a': 1, 'b': 2} # Outer scope
2 {'a': 2, 'c': 3} # Inner scope
3 {'a': 2, 'b': 2, 'c': 3} # Bridging scope
4 {'a': 1, 'b': 2} # Outer scope
In that arrangement, the statement with a using clause is executed normally in
the outer scope, but with the ability to see additional names in its local
namespace. If this can be arranged, then name binding in the statement with
the
using clause will work as we want it to.
Anyway, I think further investigation of the idea is dependent on a closer
look
at the feasibility of actually implementing it. Given that it isn't as
compatible with the existing nested scope structure as I first thought, I
suspect it will be both tricky to implement, and hard to sell to the BDFL
afterwards :(
In the timbot's let/in format:
def f():
a = 1
b = 2
print 1, locals()
let:
a = 2
c = 3
print 2, locals()
in:
print 3, locals()
print 4, locals()
I think the effect would be as if
def f():
... a = 1
... b = 2
... print 1, locals()
... def __unique_temp():
... a = 2
... c = 3
... print 2, locals()
... def __unique_too():
... print 3, locals()
... __unique_too()
... __unique_temp()
... del __unique_temp
... print 4, locals()
...
f()
1 {'a': 1, 'b': 2}
2 {'a': 2, 'c': 3}
3 {}
4 {'a': 1, 'b': 2}
print 3, locals() doesn't show a,b,c in locals() unless you use them
somehow in that scope, e.g.,
def f():
... a = 1
... b = 2
... print 1, locals()
... def __unique_temp():
... a = 2
... c = 3
... print 2, locals()
... def __unique_too():
... print 3, locals(), (a,b,c) # force references for locals()
... __unique_too()
... __unique_temp()
... del __unique_temp
... print 4, locals()
...
f()
1 {'a': 1, 'b': 2}
2 {'a': 2, 'c': 3, 'b': 2}
3 {'a': 2, 'c': 3, 'b': 2} (2, 2, 3)
4 {'a': 1, 'b': 2}
Of course, locals() does not include globals, even though they're
referenced and visible:
b
'global b'
def bar():
... print locals(), b
...
bar()
{} global b
The trouble with this is that bindings created in __unique_too all get thrown
away,
and you wouldn't want that limitation. So I proposed specifying the
(re)bindable names
in a parenthesized list with the let, like let(k, q, w): ... so that those
names
would be (re)bindable in the same scope as the let(...): statement.
As an extension, I also proposed optionally binding __unique_temp to a
specified name
and not calling it automatically, instead of the automatic call and del.
That provides new ways to factor updates to local namespaces into local
functions
with selective write-through (bind/rebind) to local names. E.g.,
# define case blocks for switch
# better sugar later, this is to demo functinality ;-)
#a
let(x):
k = 123
in foo:
x = k
#b
let(x, y):
q = 456
from math import pi as r
in bar:
x = q
y=r # extra binding created if bar is called
#c
let(x):in baz:x=789 # most compact form, where nothing in the let clause
switch = dict(a=foo, b=bar, c=baz)
Now you can update local bindings with a case switch:
x = 0
case = 'b'
print x # = 0
switch[case]() # executes bar() in this example, which assigns local x=456
and y=pi
print x # = 456
This spare example is easy to dismiss, but think of foo, bar, and baz as
arbitrary sequences of statements
in the local namespace, except you can factor them out as a single named group
and invoke them
safely by name(), and have them affect only the local names you specify in the
group's let(x, y, ...): spec.
It provides a new way of factoring. As well as things no one has thought of yet
;-)
The other thing to think about is that the let suite could be strictly
def-time, which would
provide the opportunity to avoid re-calculating things in functions without
abusing default args,
and using the easy closure-variable creation instead. E.g.,
let(foo):
preset = big_calc()
in:
def foo(x):
return x * preset
(This in: has no in xxx: name, so the effect is immediate execution of the
anonymously
defined function, which
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: Statement local namespaces summary (was Re: python3: 'where' keyword)
Bengt Richter wrote:
Problems? (Besides NIH, which I struggle with regularly, and had to overcome to
accept Tim's
starting point in this ;-)
The ideas regarding creating blocks whose name bindings affect a different scope
are certainly interesting (and relevant to the 'using' out-of-order execution
syntax as well).
Out-of-order execution appeals to me, but the ability to flag 'hey, this is just
setup for something I'm doing later' might be a reasonable alternative
(particularly with the affected names highlighted on the first line). As Jeff
pointed out, it would be significantly less surprising for those encountering
the construct for the first time. Folding code editors would be able to keep the
setup clause out of the way if you really wanted to hide it.
On the other hand, it might be feasible to construct a virtually identical
out-of-order two suite syntax, similar to the mathematical phrasing let f =
c/lambda where f is the frequency, c is the speed of light and lambda is the
wavelength. Either way, you've convinced me that two suites (and a new compound
statement), as well as specifying which names can be rebound in the containing
scope, is a better way to go than trying to mess with the definition of Python
statements.
On keywords, while 'let' is nice for assignments, I find it just doesn't parse
properly when I put function or class definitions in the clause. So, I'll swap
it for 'use' in the examples below. The statement could then be read use these
outer bindable names, and this additional code, in this suite. YMMV, naturally.
Let's consider some of the examples given for 'where' using an in-order let/in
type syntax (the examples only bind one name at a time, but would allow multiple
names):
# Anonymous functions
use res:
def f(x):
d = {}
exec x in d
return d
in:
res = [f(i) for i in executable]
# Declaring properties
class C(object):
use x:
def get(self):
print Demo default
def set(self, value):
print Demo default set
in:
x = property(get, set)
# Design by contract
use foo:
def pre():
pass
def post():
pass
in:
@dbc(pre, post)
def foo():
pass
# Singleton classes
use C:
class _C:
pass
in:
C = _C()
# Complex default values
use f:
def default():
return Demo default
in:
def f(x=default()):
pass
They actually read better than I expected. Nicely, the semantics of this form of
the syntax *can* be articulated cleanly with current Python:
use names: use-suite
in: in-suite
as equivalent to:
def __use_stmt():
use-suite
def _in_clause():
in-suite
return names
return _in_clause()
__use_stmt_args = {}
names = __use_stmt()
del __use_stmt
Those semantics don't allow your switch statement example, though, since it
doesn't use any magic to write to the outer scope - it's just a normal return
and assign.
However, I don't think starting with these semantics would *preclude* adding the
ability to name the second block at a later date, and make the name rebinding
part of executing that block - the standard usage doesn't really care *how* the
names in the outer scope get bound, just so long as they do. Whether I think
that's a good idea or not is an entirely different question :)
Another aspect to consider is whether augmented assignment operations in the
inner-scopes should work normally - if so, it would be possible to alter the
semantics to include passing the existing values as arguments to the inner scopes.
Moving on to considering a two-suite out-of-order syntax, this would have
identical semantics to the above, but a syntax that might look something like:
as names: in-suite
using: use-suite
# Anonymous functions
as res:
res = [f(i) for i in executable]
using:
def f(x):
d = {}
exec x in d
return d
# Declaring properties
class C(object):
as x:
x = property(get, set)
using:
def get(self):
print Demo default
def set(self, value):
print Demo default set
# Design by contract
as foo:
@dbc(pre, post)
def foo():
pass
using:
def pre():
pass
def post():
pass
# Singleton classes
as C:
C = _C()
using:
class _C:
pass
# Complex default values
as f:
def f(x=default()):
pass
using:
def default():
return Demo default
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]
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: python3: 'where' keyword
Op 2005-01-11, Jeff Shannon schreef [EMAIL PROTECTED]: Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: [...] and if you think that newbies will have their lives made easier by the addition of ad hoc syntax extensions then you and I come from a different world (and I suspect the walls might be considerably harder in mine than in yours). I'm saying that many proposals for ad hoc extensions could instead be taken care of with macros. Newbies come to clpy all the time asking how to do assignment expressions, or conditional expressions, or call-by-reference. Sometimes new syntax results. Lots of times, macros could take care of it. Personally, given the requests in question, I'm extremely thankful that I don't have to worry about reading Python code that uses them. I don't *want* people to be able to make up their own control-structure syntax, because that means I need to be able to decipher the code of someone who wants to write Visual Basic as filtered through Java and Perl... No you don't. You could just as well claim that you don't want people to write code in other languages because you then would need to be able to decipher code written in that language. If I want mental gymnastics when reading code, I'd use Lisp (or Forth). (These are both great languages, and mental gymnastics would probably do me good, but I wouldn't want it as part of my day-to-day requirements...) Your day-to-day requirements are a contract between you and your employer or between you and your clients. That you don't want mental gymnastics as part of that, shouldn't be a concern for how the language develops. -- Antoon Pardon -- 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: python3: 'where' keyword
Steve Holden [EMAIL PROTECTED] writes: Well I for one disagreed with many of your estimates of the zen's applicability to macros, but I just couldn't be arsed saying so. Well, I was being somewhat flip with them, as I felt Carl was being snotty in referring me to the Zen list. The point there is that one can interpret each of the Zen points in many ways regarding macros. I don't feel there's a conflict between macros and the Zen list. Macros in Python are a deep subject and gurus have been discussing them for a long time. I think that with PyPy it will become easier to experiment with possible approaches. In other posts I've suggested a moratorium on new Python syntax until after PyPy is deployed. An amazing amount of the headaches that both newbies and experienced users have with Python, could be solved by macros It's not clear what the best way to do design them is, but their existence can have a profound effect on how best to do these ad-hoc syntax extensions like where. This is not a justifiable assertion, IMHO, and if you think that newbies will have their lives made easier by the addition of ad hoc syntax extensions then you and I come from a different world (and I suspect the walls might be considerably harder in mine than in yours). I'm saying that many proposals for ad hoc extensions could instead be taken care of with macros. Newbies come to clpy all the time asking how to do assignment expressions, or conditional expressions, or call-by-reference. Sometimes new syntax results. Lots of times, macros could take care of it. I don't really understand why, if macros are so great (and you are reading the words of one who was using macros back in the days of Strachey's GPM) why somebody doesn't produce a really useful set of (say) M4 macros to prove how much they'd improve Python. You can't really do Python macros with something like M4. How would M4 even generate multi-line output that's indented to the right depth for the place where the macro was called? How would you write an m4 macro like cond(x,y,z) that does the equivalent of (x ? y : z)? Even if you could, it doesn't begin to address the hassle of running Python scripts through m4 before you can execute the scripts, especially in an interactive environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote: Semantics - The code:: statement with: suite translates to:: def unique_name(): suite statement unique_name() Bleh. Not only was my proposed grammar change wrong, my suggested semantics are wrong, too. Raise your hand if you can see the problem with applying the above semantics to the property descriptor example. So I think the semantics will need to be more along the lines of pollute the namespace but mangle the names so they're unique, and the programmer can *act* like the names are statement local. This will be much nicer in terms of run-time performance, but getting the locals() builtin to behave sensibly may be a challenge. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote: Semantics - The code:: statement with: suite translates to:: def unique_name(): suite statement unique_name() Bleh. Not only was my proposed grammar change wrong, my suggested semantics are wrong, too. Raise your hand if you can see the problem with applying the above semantics to the property descriptor example. So I think the semantics will need to be more along the lines of pollute the namespace but mangle the names so they're unique, and the programmer can *act* like the names are statement local. This will be much nicer in terms of run-time performance, but getting the locals() builtin to behave sensibly may be a challenge. afair you told yourself that var = statement where: suite translates to: def unique_name(): suite return statement var = unique_name() in this case class gets unique_name() function? is it that bad? anyway I'd prefer to change semantics deeper. adding new statement-only scope and adding our suite-definitions there. -- http://mail.python.org/mailman/listinfo/python-list
python and macros (again) [Was: python3: 'where' keyword]
Paul Rubin wrote: How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? Movement seems quite an exaggeration. Maybe 2-3 people made some experiments, but nobody within the core Python developers seems to be willing to advocate the introduction of macros. Why should you care whether the output of a macro is ugly or not, if no human is ever going to look at it? But at least some human eye have to look at it! rethorical-question Did you ever debug a macro? /rethorical-question More seriuosly, I have given some thought to the issue, and I am very much against the introduction of macros in Python. Here are a few reasons: 1. I like defmacro in Lisp. Problem is, Lisp is an s-expression based language, Python is not. We cannot implement defmacro in Python and even if we could, if would be too ugly to be used (at least, IMHO). 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. 3. We would add to Python the learning curve of macros and their subtilities and we do not want it. 4. Macros would complicate a lot Python module system. 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. I am sure I could find other reasons if I think a bit more, but these should suffice for the moment ;) 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. Michele Simionato P.S. some pointers for people interested on the topic: http://logix.livelogix.com/ (a Python-like language with macros) https://sourceforge.net/projects/pymac/ (an experimental Dylan-inspired macro system for Python) -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote: Nick Coghlan wrote: Semantics - The code:: statement with: suite translates to:: def unique_name(): suite statement unique_name() Bleh. Not only was my proposed grammar change wrong, my suggested semantics are wrong, too. Raise your hand if you can see the problem with applying the above semantics to the property descriptor example. Eh, never mind. The following works today, so the semantics I proposed are actually fine. (This is exactly the semantics proposed for the property example) Py class C(object): ... def _x(): ... def get(self): ... print Hi! ... def set(self, value): ... print Hi again! ... def delete(self): ... print Bye ... return property(get, set, delete) ... x = _x() ... Py C.x property object at 0x009E6738 Py C().x Hi! Py C().x = 1 Hi again! Py del C().x Bye Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Andrey Tatarinov wrote: afair you told yourself that var = statement where: suite translates to: def unique_name(): suite return statement var = unique_name() in this case class gets unique_name() function? is it that bad? No, I wasn't thinking clearly and saw problems that weren't there. However, you're right that the semantic definition should include unbinding the unique name after the statement finishes. E.g. for assignments: def unique_name(): suite return expr target = unique_name() del unique_name anyway I'd prefer to change semantics deeper. adding new statement-only scope and adding our suite-definitions there. A new scope essentially *is* a nested function :) My main purpose with the nested function equivalent is just to make the intended semantics clear - whether an implementation actually _does_ things that way is immaterial. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Andrey Tatarinov wrote:
I think using 'with' keyword can cause some ambiguity. for example I
would surely try to write
x = a+b with self:
b = member
and using with at the end of block brings more ambiguity:
stmt1()
stmt2()
with self:
member = stmt3()
compare to:
stmt1()
stmt2()
with:
variable = stmt3()
a way different semantics with just one word added/deleted.
Except that for a with expr: block, attributes of the expression must be
preceded by a dot:
Py stmt1()
Py stmt2()
Py with self:
....member = stmt3()
The advantages of the 'with' block are that 'self' is only looked up once, and
you only need to type it once. The leading dot is still required to disambiguate
attribute references from standard name references.
Despite that, I think you are right that the ambiguity is greater than I first
thought. Correct code is reasonably easy to distinguish, but in the presence of
errors it is likely to be unclear what was intended, which would make life more
difficult than it needs to be.
However, I still agree with Alex that the dual life of where outside of Python
(as an 'additional definitions' clause, as in mathematics, and as a
'conditional' clause, as in SQL), and the varied background of budding
Pythoneers is a cause for concern.
'in' is worth considering, as it is already used by Python at least once for
declaring use of a namespace (in the 'exec' statement). However, I suspect it
would suffer from ambiguity problems similar to those of 'with' (consider
expr in expr and expr in: expr). There's also the fact that the
statement isn't *really* executed in the inner namespace - any name binding
effects are seen in the outer scope, whereas 'exec x in dict' explicitly
protects the containing namespace from alteration.
So of the four keywords suggested so far ('where', 'with', 'in', 'using'), I'd
currently vote for 'using' with 'where' a fairly close second. My vote goes to
'using' because it has a fairly clear meaning ('execute the statement using this
extra information'), and doesn't have the conflicting external baggage that
'where' does.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
So of the four keywords suggested so far ('where', 'with', 'in',
'using'), I'd currently vote for 'using' with 'where' a fairly close
second. My vote goes to 'using' because it has a fairly clear meaning
('execute the statement using this extra information'), and doesn't have
the conflicting external baggage that 'where' does.
I should agree with you =)
Though I love with for historical reasons and addiction to functional
languages using is not that bad and I do not mind using it. =)
--
http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: [...] and if you think that newbies will have their lives made easier by the addition of ad hoc syntax extensions then you and I come from a different world (and I suspect the walls might be considerably harder in mine than in yours). I'm saying that many proposals for ad hoc extensions could instead be taken care of with macros. Newbies come to clpy all the time asking how to do assignment expressions, or conditional expressions, or call-by-reference. Sometimes new syntax results. Lots of times, macros could take care of it. Personally, given the requests in question, I'm extremely thankful that I don't have to worry about reading Python code that uses them. I don't *want* people to be able to make up their own control-structure syntax, because that means I need to be able to decipher the code of someone who wants to write Visual Basic as filtered through Java and Perl... If I want mental gymnastics when reading code, I'd use Lisp (or Forth). (These are both great languages, and mental gymnastics would probably do me good, but I wouldn't want it as part of my day-to-day requirements...) Jeff Shannon Technician/Programmer Credit International -- 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
Re: python3: 'where' keyword
Andrey Tatarinov wrote: And about examples for usage where keyword reading http://manatee.mojam.com/~skip/python/fastpython.html I understand that almost every example should use that keyword =) I suspect polluting the outer namespace would still be faster, since Python wouldn't have to create the extra level of scoping all the time. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: And a suite, be it a def statement, a where block, or whatever, belongs in a statement, not an expression. So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. So I don't know what point you're trying to make. But to answer your question, I would prefer a Python without a print statement, since a print method could do anything the print statement could. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? So I don't know what point you're trying to make. Why should you care whether the output of a macro is ugly or not, if no human is ever going to look at it? But to answer your question, I would prefer a Python without a print statement, since a print method could do anything the print statement could. A print -method-?!! You /really/ want to say your_name = Carl your_favorite_cereal = cornflakes (Hi, your_name, how about a nice bowl of, your_favorite_cereal).print() instead of your_name = Carl your_favorite_cereal = cornflakes print Hi, your_name, how about a nice bowl of, your_favorite_cereal I've heard of people wanting to replace print with a function, but hadn't heard of replacing it with a method. Are you trying to turn Python into Ruby? -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Duncan Booth wrote: Nick Coghlan wrote: Grammar Change -- Current:: statement ::=stmt_list NEWLINE | compound_stmt New:: statement ::=(stmt_list NEWLINE | compound_stmt) [local_namespace] local_namespace ::= with : suite Semantics - The code:: statement with: suite translates to:: def unique_name(): suite statement unique_name() Your proposed grammar change says that you need a newline after the statement: True, and not really what I intended. However, it does highlight the fact that statement lists haven't been considered in the discussion so far. If statement lists are permitted, getting the right targets bound in the containing scope is going to be fun for things like this: a = b = 2; c = 3; print a + b with: pass (Probably not impossible though - e.g. it may be feasible to figure out all the bindings that have to happen and return an appropriate tuple from the inner scope for binding in the outer scope) It might also be somewhat confusing as to exactly which statements are covered by the local scoping. (All of them would be, but you could be forgiven for assuming it was just the last one) I think the following would work as a version of the grammar which permits local namespaces for statement lists: statement ::= (stmt_list (NEWLINE | local_namespace)) | (compound_stmt [local_namespace]) local_namespace ::= with : suite Disallowing local namespaces for statement lists would suggest something like this: statement ::= (simple_stmt (NEWLINE | ; stmt_list NEWLINE | local_namespace) ) | (compound_stmt [local_namespace]) local_namespace ::= with : suite I'm pretty sure the permissive version is legal for the CPython parser, and I think the somewhat baroque structure I've used for the restrictive version makes it legal, too. Disallowing local namespaces for statement lists might be a good place to start, since it gives an easier target for a first implementation. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? How about this: Why don't you go to a Python prompt, type import this, and read the Zen of Python. Consider each line, and whether adding macros to the language would be going against that line or for it. After you've done that, make an educated guess of what you think I'd think about macros, citing various Zens to support your guess. Then I'll tell you what my my thoughts about it are. So I don't know what point you're trying to make. Why should you care whether the output of a macro is ugly or not, if no human is ever going to look at it? I don't. But to answer your question, I would prefer a Python without a print statement, since a print method could do anything the print statement could. A print -method-?!! [snip example] I've heard of people wanting to replace print with a function, but hadn't heard of replacing it with a method. Are you trying to turn Python into Ruby? I'll give you the benefit of the doubt that you just didn't think it over thoroughly. I was thinkging would be a method of file like objects. stdout.print(hello) -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? How about this: Why don't you go to a Python prompt, type import this, and read the Zen of Python. Consider each line, and whether adding macros to the language would be going against that line or for it. After you've done that, make an educated guess of what you think I'd think about macros, citing various Zens to support your guess. Then I'll tell you what my my thoughts about it are. The Zen of Python, by Tim Peters Beautiful is better than ugly. = +1 macros Explicit is better than implicit. = +1 macros Simple is better than complex. = +1 macros Complex is better than complicated. = I don't understand this, +0 Flat is better than nested. = not sure, +0 Sparse is better than dense. = +1 macros Readability counts. = +1 macros Special cases aren't special enough to break the rules. = +1 macros Although practicality beats purity. = +1 macros Errors should never pass silently. = +1 macros Unless explicitly silenced. = +1 macros In the face of ambiguity, refuse the temptation to guess. = +1 macros There should be one-- and preferably only one --obvious way to do it. = -1 Although that way may not be obvious at first unless you're Dutch. = ??? Now is better than never. = +1 macros, let's do it Although never is often better than *right* now. = +1 If the implementation is hard to explain, it's a bad idea. = unknown, +0 If the implementation is easy to explain, it may be a good idea. = +0 Namespaces are one honking great idea -- let's do more of those! = +1 I'm -1 on doing stuff by received dogma, but in this particular case it looks to me like the dogma is +12 for macros. What are your thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
Nick Coghlan wrote: Disallowing local namespaces for statement lists would suggest something like this: statement ::= (simple_stmt (NEWLINE | ; stmt_list NEWLINE | local_namespace) ) | (compound_stmt [local_namespace]) local_namespace ::= with : suite Corrected version of the above to avoid an unintended syntax change: statement ::= (simple_stmt (NEWLINE | ; [stmt_list] NEWLINE | local_namespace) ) | (compound_stmt [local_namespace]) local_namespace ::= with : suite (The original version incorrectly prohibited a trailing semi-colon for a single statement) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Hi folks, I really like this idea. But I couldn't help but think of a few alternative ways. I'm no language design expert by any means, but I'm a little concerned with the idea of an 'expression' preceding a 'block'. Maybe I'm naive (actually, I'm pretty sure I am), but I think a decorator-like syntax would be a little more Pythonic. Here's a small example: def where(closure=None, *v): if not False in v: closure(*v) def foo(a, b): @where(a: int, b: int): return str(a) + str(b) raise TypeMismatch The (variable : type) could be turned into a syntact sugar for (type(variable) is type). Basically, this would be a simple implementation of the so called closures, where a decorator is able to 'receive' a code block, which would be passed as a function as the first argument of the decorator. (Is this clear?) As I said, I'm no language design expert and I'm sure I'm breaking a few important rules here heh. But I find it cool. This is not a proposal. I'm just thinking out loud :) Jonas -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: The Zen of Python, by Tim Peters Beautiful is better than ugly. = +1 macros Explicit is better than implicit. = +1 macros Simple is better than complex. = +1 macros Complex is better than complicated. = I don't understand this, +0 Flat is better than nested. = not sure, +0 Sparse is better than dense. = +1 macros Readability counts. = +1 macros Special cases aren't special enough to break the rules. = +1 macros Although practicality beats purity. = +1 macros Errors should never pass silently. = +1 macros Unless explicitly silenced. = +1 macros In the face of ambiguity, refuse the temptation to guess. = +1 macros There should be one-- and preferably only one --obvious way to do it. = -1 Although that way may not be obvious at first unless you're Dutch. = ??? Now is better than never. = +1 macros, let's do it Although never is often better than *right* now. = +1 If the implementation is hard to explain, it's a bad idea. = unknown, +0 If the implementation is easy to explain, it may be a good idea. = +0 Namespaces are one honking great idea -- let's do more of those! = +1 I'm -1 on doing stuff by received dogma, but in this particular case it looks to me like the dogma is +12 for macros. What are your thoughts? Paul, When I asked you to do this, it was just a rhetorical way to tell you that I didn't intend to play this game. It's plain as day you're trying to get me to admit something. I'm not falling for it. If you have a point to make, why don't you just make it? -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: When I asked you to do this, it was just a rhetorical way to tell you that I didn't intend to play this game. It's plain as day you're trying to get me to admit something. I'm not falling for it. If you have a point to make, why don't you just make it? You asked me to compare the notion of macros with the Zen list. I did so. I didn't see any serious conflict, and reported that finding. Now you've changed your mind and you say you didn't really want me to make that comparison after all. An amazing amount of the headaches that both newbies and experienced users have with Python, could be solved by macros. That's why there's been an active interest in macros for quite a while. It's not clear what the best way to do design them is, but their existence can have a profound effect on how best to do these ad-hoc syntax extensions like where. Arbitrary limitations that are fairly harmless without macros become a more serious pain in the neck if we have macros. So, we shouldn't consider these topics separately from each other. They are likely to end up being deeply related. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: When I asked you to do this, it was just a rhetorical way to tell you that I didn't intend to play this game. It's plain as day you're trying to get me to admit something. I'm not falling for it. If you have a point to make, why don't you just make it? You asked me to compare the notion of macros with the Zen list. I did so. I didn't see any serious conflict, and reported that finding. Now you've changed your mind and you say you didn't really want me to make that comparison after all. I asked you to make an educated guess about what I would think of them, which you didn't do. I wanted you to apply the Zen to macros so that you could justify the guess. I wasn't interested in your thoughts. An amazing amount of the headaches that both newbies and experienced users have with Python, could be solved by macros. That's why there's been an active interest in macros for quite a while. It's not clear what the best way to do design them is, but their existence can have a profound effect on how best to do these ad-hoc syntax extensions like where. Arbitrary limitations that are fairly harmless without macros become a more serious pain in the neck if we have macros. What good are macros going to do when they entail (according to you) saddling the language with all this unreadable crap? You may say macros are not against the Zen of Python, but for their sake, you will add a million things that are. Net effect is, you've taken away everything that makes Python great. But here's the best part: all of this is to avoid a serious pain in the neck. Get real, Paul. Here's a thought: if macros are so great, it should be pretty easy for you to create a halfway syntax with none of these pesky so-called arbitrary limitations and have macros automatically turn it into legal Python. Don't you think that's maybe better than turning the language into an unreadable blob? No, of course you don't, because an unreadable blob is the LISP way. So, we shouldn't consider these topics separately from each other. They are likely to end up being deeply related. No, Paul, they're likely never to be related because Python is never going to have macros. Or, at least not the general sort that you want. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: Statement local namespaces summary (was Re: python3: 'where' keyword)
+1 I really like the idea of this. It removes all my objections to lambdas, and replaces it with something clear and readable. I look forward to seeing what comes of it. Anna -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan wrote: And about examples for usage where keyword reading http://manatee.mojam.com/~skip/python/fastpython.html I understand that almost every example should use that keyword =) I suspect polluting the outer namespace would still be faster, since Python wouldn't have to create the extra level of scoping all the time. sure, but just a little bit slower =) -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
On Sun, 09 Jan 2005 15:54:08 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Here's another nice one if 'where' is added to compound statements as well: @dbc(pre, post) def foo(): pass where: def pre(): pass def post(): pass Interesting. It solves some of the issues with chosing a clear syntax for design by contract and other similar features that were being debated lately. I also thought about his one: ! def foo(x=calculate_default_value()): ! pass ! where: ! def calculate_default_value(): ! ... ! return something -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Peter Hansen wrote: print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression Then your example above doesn't work... print takes a sequence of expressions, not a tuple as you seem to think. sorry, I used expression carelessly. I mean that print words[3], words[5] is a single expression (and that would be in Python 3, when print would be subtituted with write()/writeln()). -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
AdSR [EMAIL PROTECTED] wrote: I don't know haskell, but it looks SQL-ish to me (only by loose Indeed, the fact that many MANY more people are familiar with SQL than with Haskell may be the strongest practical objection to this choice of syntax sugar; the WHERE clause in an SQL SELECT has such wildly different semantics from Haskell's where that it might engender huge amounts of confusion. I.e., reasoning by analogy with SQL only, one might reasonably expect that minor syntax variations on: print a, b where a = b could mean roughly the same as if a==b: print a, b, rather than roughly the same as: a = b print a, b I wonder if 'with', which GvR is already on record as wanting to introduce in 3.0, might not be overloaded instead. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: You mean I can't say # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. No, I'd prefer to not embed 'where' into expression. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: Trying to push it a level further (down to expressions) would, IMO, be a lot of effort for something which would hurt readability a lot. I think we should just try to do things in a simple and general way and not try to enforce readability. For example, the slightly-overcomplex code that I proposed might have been generated by a macro, or even by a compiler from some other language. No human would ever have to look at it, so it doesn't matter whether it's easily readable. There's no reason to add needless constraints on the language just to make writing ugly code difficult. The main goal should be to make writing clear code easy, not to worry about whether someone might also write ugly code. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Alex Martelli wrote: I wonder if 'with', which GvR is already on record as wanting to introduce in 3.0, might not be overloaded instead. Perhaps we could steal 'using' from the rejected decorator syntax. x = [f(x) for x in seq] using: def f(x): return x * x Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan wrote: sorry, I used expression carelessly. I mean that print words[3], words[5] is a single expression (and that would be in Python 3, when print would be subtituted with write()/writeln()). 'statement' is the appropriate word in Python's grammar. thanks ) And I don't think we'd actually have to wait for Python 3 for this, we'd just have to do the __future__ dance in order to introduce the new keyword. resonable, I mentioned Python3 as something in not that near future, that'd be great to think of it earlier -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] wrote: Alex Martelli wrote: I wonder if 'with', which GvR is already on record as wanting to introduce in 3.0, might not be overloaded instead. Perhaps we could steal 'using' from the rejected decorator syntax. x = [f(x) for x in seq] using: def f(x): return x * x If 'with' is going to become a keyword anyway, I suspect that many, Guido included, would see giving 'with' two distinct syntax roles as a lower 'price' than introducing yet another keyword, as long of course as no ambiguity results. 'import', for example, is happily reused for both 'import foo' and 'from foo import bar'. In terms of readability I see nothing in it, either way, between 'with' and 'using' (and 'where', were it not for the wildly different semantics it has in SQL) -- e.g. your example seems to read just fine with any of these keywords. If the use Guido intends for 'with' is something like: with aname: .x = .y meaning aname.x = aname.y then there would be no ambiguity between this use of with as a leading keyword in the new statement, always followed by a name; and its use in the with clause, where it always comes after an expression and is immediately followed by a colon. I mean, no ambiguity for either the parser or a human reader, I believe. Once the AST-branch is folded back into the CVS head, playing around with syntax should be much easier than today... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: sorry, I used expression carelessly. I mean that print words[3], words[5] is a single expression (and that would be in Python 3, when print would be subtituted with write()/writeln()). 'statement' is the appropriate word in Python's grammar. And I don't think we'd actually have to wait for Python 3 for this, we'd just have to do the __future__ dance in order to introduce the new keyword. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Trying to push it a level further (down to expressions) would, IMO, be a lot of effort for something which would hurt readability a lot. I think we should just try to do things in a simple and general way and not try to enforce readability. Trying to embed a suite in a Python expression is anything but simple, though :) Attaching an optional local suite to every statement can actually be done quite cleanly (so long as the parser is up to the job). Doing the substitutions on the whole statement using distinct names will work just as well as doing the substitutions directly on the subexpressions using duplicate names, and moves the 'unimportant' bits after the whole thing, instead of sprinkling them throughout the statement. It seems a statement based approach would be: 1. Easier to read 2. Less work to implement 3. Consistent with the rest of the language 4. Works for any statements, including compound statements The only disadvantage relative to expression local namespaces would be that you would still have to watch for namespace conflicts within the statement - and I have grave doubts about the structure of any statement which has that problem. If statement local namespaces were pursued, I would see expression local namespaces as something which hurt readability a lot without providing any new functionality. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: What would be the advantage of that over this? . x = sqrt(a) + sqrt(b) where: . a = 2.0 . b = 3.0 The idea of where is to allow re-using variable names instead of having to keep track of which ones are in use. I just tried to give a very simple example of how you might do that more than once in a statement. then I'd write something like this: x = a + b where: a = sqrt(n) where: n = 2. b = sqrt(n) where: n = 3. -- http://mail.python.org/mailman/listinfo/python-list
Statement local namespaces summary (was Re: python3: 'where' keyword)
Andrey Tatarinov wrote: So it seems that people loved the idea of 'where' keyword, may be it's time to think about PEP draft? I appreciate any help (cause my english is not that good =)). There's certainly a PEP in the idea. Here's a summary of what we have so far in this thread in a PEPish format. Any reference implementation should definitely wait for the compiler upgrade to hit the main development branch in CVS though (or be based on ast-branch if someone gets inspired in the interim). Cheers, Nick. Abstract The proposal is to add the capacity for statement local namespaces to Python. This allows a statement to be placed at the current scope, while the statement's 'setup code' is indented after the statement:: statement with: suite The main benefit is the avoidance of namespace pollution in the outer scope. Sections of the statement can be extracted and named in the statement's local namespace without any inadvertent side effects due to name conflicts. The second benefit is that it can improve readability by allow easy grouping of the setup code for a given expression (see the examples section) Thirdly, it provides full-fledged effectively anonymous functions (just define them in the statement's local namespace). The idea is inspired by Haskell's where clause, as posted to python-list by Andrey Tatarinov. Alex Martelli suggested using the 'with' keyword. Grammar Change -- Current:: statement ::=stmt_list NEWLINE | compound_stmt New:: statement ::=(stmt_list NEWLINE | compound_stmt) [local_namespace] local_namespace ::= with : suite Semantics - The code:: statement with: suite translates to:: def unique_name(): suite statement unique_name() Assignment statements (including augmented assignment) require special handling. The original assignment statement is translated to a return statement in the inner scope:: target assign-op expr with: suite translates to:: def unique_name(): suite return expr target assign-op unique_name() Function and class definitions will also require special casing, so that the created function or class is returned from the inner-scope and the name bound correctly in the outer scope. Note that calling locals() inside a statement with a local namespace will refer to the statement's locals, rather than those of the containing function. Keyword Choice -- The original suggestion on python-list used the 'where' keyword. Alex Martelli pointed out that this could be misleading for anyone with expectations based on SQL's WHERE clause. He suggested 'with' as an alternative spelling, as 'with' is already planned as a keyword for Python3k. Even for with clauses associated with compound statements, there should be no ambiguity, given that the with statement will have an expression between it and the colon, while the with clause does not. Open Issues --- Is it actually possible to make it work? Keyword choice Should the clause be allowed on any statement (as described), or restricted to ones where it makes sense? Examples # Statement local functions (from Andrey Tatarinov) # aka How to cope if lambda goes away :) res = [ f(i) for i in objects ] with: def f(x): #do something # Declaring properties (from Nick Coghlan) class C(object): x = property(get, set) with: def get(self): pass def set(self, value): pass # Design by contract (from Nick Coghlan) @dbc(pre, post) def foo(): pass with: def pre(): pass def post(): pass # Singleton classes (from Paul Rubin) C = C() with: class C: pass # Complex default values (from Carlos Ribeiro) def f(x=default()): pass with: def default(): pass -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Alex Martelli wrote: Indeed, the fact that many MANY more people are familiar with SQL than with Haskell may be the strongest practical objection to this choice of syntax sugar; the WHERE clause in an SQL SELECT has such wildly different semantics from Haskell's where that it might engender huge amounts of confusion. I.e., reasoning by analogy with SQL only, one might reasonably expect that minor syntax variations on: print a, b where a = b could mean roughly the same as if a==b: print a, b, rather than hmm... SQL-ish associations are good too, if you think a little deeper then common post-effect of using SQL where keyword. print a, b where a = b means a==b in statement print a, b roughly the same as: a = b print a, b I wonder if 'with', which GvR is already on record as wanting to introduce in 3.0, might not be overloaded instead. using 'with', is some way unnatural for my point of view (may be because translations of 'with' and 'where' into russian, are way different and 'where' translation reads as natural language while 'with' does not). I'd like to keep 'where' keyword for proposal, but semantics are more important, so in case I do not mind for other keyword. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
And about examples for usage where keyword reading http://manatee.mojam.com/~skip/python/fastpython.html I understand that almost every example should use that keyword =) -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Alex Martelli wrote: AdSR [EMAIL PROTECTED] wrote: I don't know haskell, but it looks SQL-ish to me (only by loose Indeed, the fact that many MANY more people are familiar with SQL than with Haskell may be the strongest practical objection to this choice of syntax sugar; the WHERE clause in an SQL SELECT has such wildly different semantics from Haskell's where that it might engender huge amounts of confusion. I.e., reasoning by analogy with SQL only, one might reasonably expect that minor syntax variations on: print a, b where a = b could mean roughly the same as if a==b: print a, b, rather than roughly the same as: a = b print a, b I wonder if 'with', which GvR is already on record as wanting to introduce in 3.0, might not be overloaded instead. IIRC the proposed meaning seems to be most closely related (in my own experience, annyway) to the use of where in BCPL (heavens, *that* was a long time ago). I never found that entirely natural either. 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: python3: 'where' keyword
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Trying to push it a level further (down to expressions) would, IMO, be a lot of effort for something which would hurt readability a lot. I think we should just try to do things in a simple and general way and not try to enforce readability. For example, the slightly-overcomplex code that I proposed might have been generated by a macro, or even by a compiler from some other language. No human would ever have to look at it, so it doesn't matter whether it's easily readable. There's no reason to add needless constraints on the language just to make writing ugly code difficult. The main goal should be to make writing clear code easy, not to worry about whether someone might also write ugly code. I couldn't disagree more. I belive in the Zen of Python. I believe the Zen of Python is the major factor responsible for Python's success. I believe that moving away from the Zen of Python will only diminish the language. And I think allowing a where statement inside in expression goes against the Zen in so many ways it isn't even funny. Beautiful is better than ugly. Simple is better than complex. (Note that simple means different things to different people: for me, and I believe, for the Zen of Python, it means simple for a human to understand.) Flat is better than nested. (Seems to be the official Zen if effect here.) Readability counts. (Yes, if something's unreadable enough, I hope it's not in the language, not merely that no one uses it.) Special cases aren't special enough to break the rules. (Heretofore, Python has never had a nested block inside an expression; doing that would make it a special case.) I don't want Python to be LISP. I don't think it's an admirable goal for Python to strive to be like LISP for the sake of being like LISP, or for the sake of being general or pure. If Python borrows something from LISP, it should be because that aspect of LISP supports the Zen of Python. If I wanted to use LISP, I'd be using LISP. But I like my statements and expressions distinct. I like things that belong in statements to stay in statements, and things that belong in expressions to stay in expressions. And a suite, be it a def statement, a where block, or whatever, belongs in a statement, not an expression. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan wrote: Andrey Tatarinov wrote: Hi. It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something [snip] For compound statements, a where clause probably isn't appropriate, as it would be rather unclear what the where clause applied to. Right. But you know that as soon as you add this to simple expressions, a bunch of people are going to come here whining about how they don't get to use where with if-expressions. Frankly, they might have a point here. Although we have replacing lambda expressions on our minds, I have in mind a different problem that a where-statement would solve perfectly. But it would have to be used with an if-expression. However, I think it might not be so hard. Let's take Paul Rubin's advice and precede the if statement with where. Let's also allow elif clauses to be replaced with else where ... if clauses. That which is bound in the while-block would be visible in both the if-expression and if-block. Then we could do this: . where: . m = someregexp.match(somestring) . if m: . blah blah blah . else where: . m = someotherregexp.match(somestring) . if m: . blah blah blah We might want to spell else where instead as elwhere, to match elif, but that's not important now. This would take away one of the major minor annoyances of Python. (In fact, I've suggested something like this as a solution to the set-and-test idiom, which Python makes difficult, only I used the keyword suppose instead of where.) Ok, but if you do that, now you have people whining that where comes after some expressions, and before others. (This would not bother me one bit, BTW, but I'm pretty sure I'd lose the popular vote on this one.) So, let's go all out and say that while could precede any statement. We now have consistency. Well, that really wouldn't work for the if-statement, though, because then how could we apply a different while-block to an else clause? We'd have to treat if-statements specially anyways. So we don't have consistency. My solution would be to propose two different where statements: a where...do statement, and a separate where...if statement. The where...do statement would look like this: . where: . def whatever(): pass . do: . blah blah use whatever blah It has the advantage of being able to apply the where bindings to several statements, and is, IMO, much cleaner looking than simply applying where's bindings to the single following unindented statement. I would recommend against where...while and where...for statements. They can't accomplish anything you couldn't do with a break statement inside the block, and it's not obvious whether the where clause gets executed once or for each loop (since it's physically outside the loop part). One question: what do you do with a variable bound inside a while-block that has the same name as a local variable? (Or, horrors, a surrounding while-block?) I'm inclined to think it should be illegal, but maybe it would be too restrictive. Anyways, I like this idea a lot. +1 -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan wrote: Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly Hey, this is super-elegant! AdSR -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
AdSR [EMAIL PROTECTED] writes: Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly Hey, this is super-elegant! Heh, even further: z = C() where: class C(object): ... Lets you make anonymous classes and singleton objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Bengt Richter wrote: It also allows the necessary but uninteresting setup for an expression to be moved out of the way, bringing the expression that does the real work to prominence. Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly Yes, that is cool and it _is_ an interesting idea. Are suites nestable? E.g., is this legal? ... And, is the whole thing after the '=' an expression? E.g., x = ( foo(x) where: x = math.pi/4.0 ) where: def foo(x): print 'just for illustration', x or is this legal? for y in ([foo(x) for x in bar] where: bar = xrange(5) ): baz(y) where: def baz(arg): return arg*2 Not trying to sabotage the idea, really, just looking for clarification ;-) yes, all your examples are correct. And that's the way I'd like to use this feature. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan wrote: It also allows the necessary but uninteresting setup for an expression to be moved out of the way, bringing the expression that does the real work to prominence. Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly oh, that's great! I can't imagine prettier example -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
At the risk of generating controversy, here's another type of example: def gcd(a, b): where: a: int, b: int return c where: c: int while a: a, b = b%a, a return b More can be found at http://aroberge.blogspot.com Andre -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Darn space-eater google groups :-( Here is it again, at teh risk of generating controversy .def gcd(a, b): .where: .a: int, b: int .return c where: .c: int .while a: .a, b = b%a, a .return b more examples can be found at aroberge.blogspot.com André -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
When I first saw this I thought: hmmm... this seems as redundant as adding a repeat/until loop to Python; there's no chance in hell it will ever be accepted by the community or Guido, but I actually kinda like it. It's nice to see mostly positive reactions to this idea so far. I think it's a really ingenious solution to the the anonymous function problem - don't make it anonymous! A short, throwaway name with a very localized scope is as good as a truly anonymous function and feels more Pythonic to me. We thought we wanted a better syntax than lambda for anonymous functions but Andrey shows that perhaps it wasn't what we really need. What we need is a solution to quickly and cleanly generate bits of callable code without polluting the containing namespace, without having to think too hard about unique names and while making their temporary and local nature clear from the context. Anonymity isn't one of the requirements. I really liked Nick Coghlan's property example. The names 'get' and 'set' are too short and generic to be used without a proper scope but with this syntax they are just perfect. Here's another example: w = Widget(color=Red, onClick=onClick, onMouseOver=onMouseOver) where: . def onClick(event): do_this(event.x, event.y, foo) . def onMouseOver(event): someotherwidget.do_that() The onClick=onClick part seems a bit redundant, right? So how about this: w = Widget(**kw) where: . color = Red . def onClick(event): do_this(event.x, event.y, blabla) . def onMouseOver(event): someotherwidget.do_that() . x, y = 100, 200 . kw = locals() I'm not really sure myself how much I like this. It has a certain charm but also feels like abuse of the feature. Note that w = Widget(**locals()) where: would produce the wrong result as it will include all the values in the containing scope, not just those defined in the where block. Oren -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression Then your example above doesn't work... print takes a sequence of expressions, not a tuple as you seem to think. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
On Sat, 08 Jan 2005 12:53:05 -0500, Peter Hansen [EMAIL PROTECTED] wrote: Andrey Tatarinov wrote: print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression Then your example above doesn't work... print takes a sequence of expressions, not a tuple as you seem to think. I found it strange that he had chosen to make the example with print, that is a statement. I'm not sure how could it be made to work with both expressions and statements, it just seems strange... Overall, I found the idea interesting. It seems like a obvious counterpart to with, in the sense that both act as modifiers to the scoping rules. I think it can be made to work, and that it would lead to elegant readable code, but there are still lots of things to consider: exception handling, fast name lookup in the where block, access to symbols outside the where block, just to name a few. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Peter Hansen wrote: Andrey Tatarinov wrote: print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression Then your example above doesn't work... print takes a sequence of expressions, not a tuple as you seem to think. You misunderstand. There where is not part of the expression but the statement. The above example would be a modified print statement, a print...where statement, if you will. Under this suggestion, there would be modified versions of various simple statements. This wouldn't be a problem parsing, of course, because where would be a keyword. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: You misunderstand. There where is not part of the expression but the statement. The above example would be a modified print statement, a print...where statement, if you will. Under this suggestion, there would be modified versions of various simple statements. You mean I can't say # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. Hmmm. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: You misunderstand. BTW, Peter, I guess I should have said I misunderstand, but it can be legal if you consider it part of the statements, since it appears the author did intend it to be part of an expression. There where is not part of the expression but the statement. The above example would be a modified print statement, a print...where statement, if you will. Under this suggestion, there would be modified versions of various simple statements. You mean I can't say # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. Hmmm. What would be the advantage of that over this? . x = sqrt(a) + sqrt(b) where: . a = 2.0 . b = 3.0 Where would making where part of an expression rather than part of the statement help? Can you think of a place? (That it makes Python more like LISP is not a good enough answer for me, BTW. But feel free to try. :) -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. Hmmm. What would be the advantage of that over this? . x = sqrt(a) + sqrt(b) where: . a = 2.0 . b = 3.0 The idea of where is to allow re-using variable names instead of having to keep track of which ones are in use. I just tried to give a very simple example of how you might do that more than once in a statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
On 8 Jan 2005 16:13:39 -0800, Carl Banks [EMAIL PROTECTED] wrote: Bengt Richter wrote: And, is the whole thing after the '=' an expression? E.g., x = ( foo(x) where: x = math.pi/4.0 ) where: def foo(x): print 'just for illustration', x How would that be any improvement over this? Not in any way except that the idea was not to show the best code, but to show an illustration of possible rules of parsing ;-) . x = foo(x) where: . x = math.pi/4.0 . def foo(x): print 'just for illustration', x Can anyone think of a use case for embedding where inside an expression as opposed to making it part of a simple statement? And, if so, is the benefit of it worth the massive hit in readability. I guess that might depend on the local-scope effects of 'where:' -- I think it is too early to jump to conclusions one way or the other. At this point I just wanted to clarify what the proposal really was, by asking questions about silly code snippets. or is this legal? for y in ([foo(x) for x in bar] where: bar = xrange(5) ): baz(y) where: def baz(arg): return arg*2 Here, I can only hope not. One reason I proposed a where...do syntax is so that, if you wanted to localize a variable to a for loop or some other compound statement, you could do it with a minimum of fuss. Just because something contorted is _possible_ is not a good reason for limiting a general capability IMO. Why not say instead, I can only hope no one uses it that way.? . where: . bar = xrange(5) . def baz(arg): return arg*2 . do: . for y in [foo(x) for x in bar]: . baz(y) Not trying to sabotage the idea, really, just looking for clarification ;-) That's ok. For it fly, it's got to be able to withstand the flak. I actually like it quite a bit, in spite of the NIH ego thing ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: What would be the advantage of that over this? . x = sqrt(a) + sqrt(b) where: . a = 2.0 . b = 3.0 The idea of where is to allow re-using variable names instead of having to keep track of which ones are in use. I just tried to give a very simple example of how you might do that more than once in a statement. I think having to keep the names unique within the statement you are currently writing is a reasonable request :) Cheers, Nick -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: I think having to keep the names unique within the statement you are currently writing is a reasonable request :) Um, you could say the same thing about the function, the module, etc. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: AdSR [EMAIL PROTECTED] writes: Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly Hey, this is super-elegant! Heh, even further: z = C() where: class C(object): ... Lets you make anonymous classes and singleton objects. Here's another nice one if 'where' is added to compound statements as well: @dbc(pre, post) def foo(): pass where: def pre(): pass def post(): pass Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: I think having to keep the names unique within the statement you are currently writing is a reasonable request :) Um, you could say the same thing about the function, the module, etc. ;) And, indeed, that is what Python currently says. When writing code, the relevant namespaces are the builtins, the module, any containing functions and the current function. Inadvertent conflicts with any of those can have surprising side effects. The idea of 'where' is to push that down one level, and allow a namespace to be associated with a single statement. Trying to push it a level further (down to expressions) would, IMO, be a lot of effort for something which would hurt readability a lot. Compare: x = sqrt(a) + sqrt(b) where: a = 2.0 b = 3.0 This brings the operation we care about (add the sqrt's of 2 and 3) right up front. A folding code editor could actually hide the details quite easily. We can look inside the statement if we want to know what x y actually are. Versus: x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. We haven't gotten rid of anything here - all the stuff we're interested in clearing out of the way is still embedded in the middle of our statement. Also not insignificantly, we're trying to put a suite inside an expression, which will be rejected for all the reasons that have kept lambda restricted to a single expression despite numerous complaints over time. Now, nothing in the idea of a statement local namespace actually *rules out* the prospect of an expression local namespace, so it could be added at a later date. However, doing so would require some actual use cases, and an expression-friendly syntax. Perhaps something that involves providing the namespace directly, like: x = (sqrt(a) where (a=2.0)) + (sqrt(b) where (a=3.0)) It seems to make more sense to try for statement local namespaces *first*, and then see if expression local namespaces are worth it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: x = (sqrt(a) where (a=2.0)) + (sqrt(b) where (a=3.0)) Hmm, I like that too. -- http://mail.python.org/mailman/listinfo/python-list
python3: 'where' keyword
Hi. It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something or print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression - it's more easy to read sources when you know which part you can skip, compare to def f(x): #do something res = [ f(i) for i in objects ] in this case you read definition of f before you know something about it usage. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: Hi. It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something or print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression How often is this really necessary? Could you describe some benefits of this? I think the only time I've ever run into scoping problems is with lambda, e.g. [lambda x: f(x) for x, f in lst] instead of [lambda x, f=f: for x, f in lst] Are there other situations where you run into these kinds of problems? - it's more easy to read sources when you know which part you can skip, compare to def f(x): #do something res = [ f(i) for i in objects ] in this case you read definition of f before you know something about it usage. Hmm... This seems very heavily a matter of personal preference. I find that your where clause makes me skip the 'res' assignment to read what the 'res' block contains. I had to read it twice before I actually looked at the list comprehension. Of course, I'm sure I could be retrained to read it the right way, but until I see some real benefit from it, I'd rather not have to. TOOWTDI-ily-yrs, Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Steven Bethard wrote: How often is this really necessary? Could you describe some benefits of this? I think the only time I've ever run into scoping problems is with lambda, e.g. [lambda x: f(x) for x, f in lst] instead of [lambda x, f=f: for x, f in lst] Sorry, bad example, this should have looked something more like: [lambda y: f(x, y) for x, f in lst] ... [lambda y, x=x, f=f: f(x, y) for x, f in lst] where you actually need the lambda. Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
In article [EMAIL PROTECTED], Steven Bethard [EMAIL PROTECTED] wrote: Andrey Tatarinov wrote: It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something or print words[3], words[5] where: words = input.split() - defining variables in where block would restrict their visibility to one expression How often is this really necessary? Could you describe some benefits of this? I think the only time I've ever run into scoping problems is with lambda, e.g. [lambda x: f(x) for x, f in lst] instead of [lambda x, f=f: for x, f in lst] Are there other situations where you run into these kinds of problems? Note that he says would be extremely useful for creating readable sources, so the these kinds of problems he would have been thinking of would be where source was not as readable as it could be. You seem to be concerned about something else. I don't by any means agree that this notation is worth adopting, and in general I think this kind of readability issue is more or less a lost cause for a language with Python's scoping rules, but the motive makes sense to me. One way to look at it might be, if I observe that words is assigned to in a where clause, then I know it will not be used elsewhere in the surrounding scope so I can forget about it right away. If the name does occur elsewhere, it evidently refers to something else. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: Hi. It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something I don't know haskell, but it looks SQL-ish to me (only by loose association). And it's not that unpythonic - it resembles res = [x for x in sequence if x.isOk()] or print words[3], words[5] where: words = input.split() Here's a shorter version: print input.split()[3:5:2] (Does it qualify as obfuscated Python code? :) ) - defining variables in where block would restrict their visibility to one expression - it's more easy to read sources when you know which part you can skip, Yes, I like the readability of it, too. compare to def f(x): #do something res = [ f(i) for i in objects ] in this case you read definition of f before you know something about it usage. When I first read your post, I thought Well, just one more of those Py3k ideas that appear on c.l.py every day. But as I look at the latter example, I think you have just scratched my itch. The same thing has bugged me more than once in my code. I think this idea is of the same kind as the @decorator syntax. Guido moved an operation to a point in the code where it was more visible. You moved an operation to a more local context where (pun not intended) it really belongs. I'm usually rather conservative about Python syntax (@decorators, absolute/relative imports, if-else operator), but this one could appear in Python tomorrow and that would be too far in the future for me ;) Cheers, AdSR -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Donn Cave [EMAIL PROTECTED] writes: I don't by any means agree that this notation is worth adopting, and in general I think this kind of readability issue is more or less a lost cause for a language with Python's scoping rules, but the motive makes sense to me. But we're talking about the mythical/hypothetical Python 3, so maybe there's a chance of fixing the scoping rules, which it seems to me are currently pretty badly broken. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Andrey Tatarinov wrote: Hi. It would be great to be able to reverse usage/definition parts in haskell-way with where keyword. Since Python 3 would miss lambda, that would be extremly useful for creating readable sources. Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something Hmm, this is actually a really interesting idea. Avoiding accidental namespace conflicts is certainly one of the advantages of using lambdas. This idea has the virtue of being able to do the same thing, but have full access to Python's function syntax and assignment statements in the 'expression local' suite. In fact, any subexpressions in a complicated expression can be extracted and named for clarity without fear of screwing up the containing namespace, which would be an enormous boon for software maintainers. It also allows the necessary but uninteresting setup for an expression to be moved out of the way, bringing the expression that does the real work to prominence. From the interpreter's point of view, the meaning would probably be something like: namespace = locals() exec where_suite in globals(), namespace exec statement in globals(), namespace res = namespace[res] del namespace Making the 'where' clause part of the grammar for the assignment statement should be enough to make the above example parseable, too. The clause might actually make sense for all of the simple statement forms in the grammar which contain an expression: expression statement assignment statement augmented assignment statement del statement print statement return statement yield statement raise statement exec statement The clause really isn't appropriate for break, continue, import or global statements, as they don't contain any expressions :) For compound statements, a where clause probably isn't appropriate, as it would be rather unclear what the where clause applied to. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
