The forced indentation of 3000

It's pretty neat. Thread over?

print "string" = invalid code, now.

enjoy your print("string")

This is voluntary spaces!
Voluntary spaces?
THIS IS FORCED INDENTATION

>>3
Thank you. I was sure there was a 300 joke hiding somewhere.

>>2
They finally made print a function. Yay, now we don't have to put up with the nonsense inability to put print inside a lambda.

>>2
Statements are my main gripe with Python. It's good at least some of them (print, exec) are going away. Now you can do f(print). You couldn't before. Statements are Fortran-derived dinosaurs that come with a huge cost and no real benefits, so they need to be killed with fire.

>>5
In Python 2.x, I *always* define In, Out and Err. If running on Windows, they'll be defined to raw_input(), print and sys.stderr.write, but I'll load my Unicode layer so I get a full Unicode console. On Linux, they're defined to sys.std* operations, but always encoding/decoding UTF-8. The idea is that I get a full, true, real Unicode terminal or console, the way it should have been done. I only read and write unicode objects. In fact I have killed str legacy gaystrings with fire.

>>6
Statements can be very useful as syntactical sugar or linguistic abstractions.
print turned out to be a mistake, but stuff like if and function definition should never need to be redefined or passed, and having them as statements makes the syntax a lot cleaner, and the code more readable.

>>7
lambda x, y, z: y if x or z looks like a function I might need to pass one day, but whether you can think of a case where you'd need to pass something or not is not valid justification for making a separate poor brother of expressions with a separate, incompatible syntax (one more thing to learn). Readability counts, but statements shouldn't be necessary to make the syntax clearer; the expression syntax should be clear already, and if it's not, we have a problem for which statements are a nigger rig of a solution that will only make things worse.

The unnecessary, arbitrary, prejudicial separation between expressions and these "statements" artifacts is what gave Python most of the few problems it has. For example, lambda's limited usefulness, the difference between lambda and def (which was certainly uncalled for), the need for the and-or hack and now the ugly if-else hack, the misuse of list comprehensions (they are great! But sometimes people use them instead of fors and ifs because they are expressions), the inability to create yourself a do..while loop that's missing in the language...

>>8
What is that supposed to return if not x and not z? Or is y supposed to be a statement?
Anyway, you can pass functions of course, you just can't pass def itself, which wouldn't make much sense in Python anyway, and alternatives like (disregarding the = statement):

f = function((x, y),
    ...
    )
Requires its own set of 'nigger rigs', like the ability to give code as arguments.
Which differences between lambda and def are you talking about? Lambdas have limitations, but they're hardly arbitrary. I'm not sure what and-or and if-else hacks you are referring to.

How would you have things like if, def and lambda look?

>>9
z

>>9
Some operator should allow you to pass code as arguments. But let's suppose Python doesn't want to get into this. I'm fairly neutral to having this feature or not. At least, if, for, etc. should be expressions; not first-class data, but expressions that can appear in expression context. In fact, I don't see the need to differentiate "expression context" from "statement context".

Which differences between lambda and def are you talking about? Lambdas have limitations, but they're hardly arbitrary.
lambda and def essentially serve the same purpose (wasn't TOOWTDI a good thing?), yet they have different syntax which you have to learn, and you can't use these statements inside lambda, which is an arbitrary limitation coming from the arbitrary separation between some things that work like expressions, such as list comprehensions, and some things that do not, like if or for.

I'm not sure what and-or and if-else hacks you are referring to.
People wouldn't be doing dangerous and-or hacks (a and b or c works like C-like a ? b : c as long as b is true), or requesting the ?: conditional operator, which finally made it into Python but under an ugly syntax (b if a or c, WTF), if if were an expression. They wouldn't have needed to use and-or that way, or to introduce if-else, if the language's comparison feature worked everywhere. The difference between the if statement and the if-else expression in Python 2.5 is like the difference between a hammer and a hammer for left-handed people.

How would you have things like if, def and lambda look?
I like the forced indentation of code. We don't have to give up on it. I'd propose that if, def, etc. become operators that work in expression context using a least-surprise syntax:


x = 1 + 2 + if a:
    #Begin the forced indentation of code
    y = 0
    for i in xrange(...):
        #Nested forced indentation of code
        y = ...
    y #This makes the "if" evaluate to y
#Now we can go back to the first indentation level, closing the if.
#As you would expect, an if without else returns None if false.
#And we could even define an else:
else:
    c #Return c

So basically, this:

x = t if c else f

could be done as either:


x = if c:
    t
else:
    f

or also the more compact:


x = if c: t; else f

Everything would become expressions; semicolons or EOLs would be used as expression separators, and a block of code inside if, while, for or def should evaluate to the last expression evaluated inside.

As for lambda, I'd make it disappear and turn def into a better lambda. Example of previous usage:


fa = lambda x: x + 1

def fb(x):
    while something:
        ...
    return x + whatever

def _temp(x):
    ...statements...
    return x + whatever
higher_order_function(1, 2, _temp, 3, 4)

My idea:


fa = def x: x + 1

#No need for parens
fb = def x:
    while something:
        ...
    x + whatever

#No need for _temp
higher_order_function(1, 2, def x:
    ...statements...
    x + whatever
, 3, 4)

Of course, assignment statements should also become expressions. As in C.

>>11
They could name it Cobra, because it burns my eyes like poison.

The basic techniques and   no libraries besides   Schools had by   that time long   since popularized the   idea of Pascal   were you talking   about come over   here Python NO   other language comes!

15 Name: Anonymous 2011-02-04 16:55

---

Don't change these.

Name:		Email:
Entire Thread Thread List