python3: 'where' keyword

[Bengt Richter]

So why shouldn't they get to?

I have a different suggestion for this.

'as' is used for renaming in import statements. 'as' will be used for exception
naming in Python 3k.

So let's use it for expression naming in 'if' statements, too.

if someregexp.match(s) as m:
# blah using m
elif someotherregexp.match(s) as m:
# blah using m

If 'where: ...' were an expression suite ISTM you could write

if m where: m = someregexp.match(s) # same-line format
blah(m)
elif m where:
m = someotherregexp(s) # indented suite format
blah(m) # dedent from where-suite starts elif-suite

Regards,
Bengt Richter

 

[Bengt Richter]

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.

+1 ;-)

Regards,
Bengt Richter

 

[Carl Banks]

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.

 

[Paul Rubin]

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?

 

[Duncan Booth]

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:

statement
with:
suite

e.g.

res = [ f(i) for i in objects ]
with:
def f(x):
pass

or

for i in objects:
f(i)
with:
def f(x):
pass

 

[Nick Coghlan]

Excuse me, these are supposed to be IMPROVEMENTS to Python?

I think it's more messing around before coming to the conclusion that, of the
many things that 'where' helps with, this sure as hell ain't one of them

Cheers,
Nick.

 

[Carl Banks]

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.

 

[Nick Coghlan]

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.

 

[Paul Rubin]

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?

 

[Carl Banks]

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.

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")

 

[Nick Coghlan]

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.

 

[Paul Rubin]

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?

 

[Nick Coghlan]

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.

 

[Jonas Galvez]

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

 

[Carl Banks]

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?

 

[Paul Rubin]

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.

 

[Carl Banks]

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.

 

[Anna]

+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

 

[Andrey Tatarinov]

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 =)

 

[Andrey Tatarinov]

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>

I think using 'with' keyword can cause some ambiguity. for example I
would surely try to write

and using with at the end of block brings more ambiguity:

compare to:

a way different semantics with just one word added/deleted.