On 13 October 2012 18:23, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Oct 14, 2012 at 3:38 AM, Joshua Landau
> <joshua.landau...@gmail.com> wrote:
> > This here isn't a flaw in Python, though. It's a flaw in the command-line
> > interpreter. By putting it all on one line, you are effectively saying:
> > "group these". Which is the same as an "if True:" block, and some things
> > like Reinteract even supply a grouping block like "build".
> >
> > That said, because some shells suck it would be nice if:
> >>
> >> python -c "a=1\nif a:print(a)"
> >
> > worked (just for -c).
>
> Yes, that'd be nice. But it still leaves the big question of why
> Python requires \n to separate one statement from another. It IS a
> flaw in Python that it requires one specific statement separator in
> this instance, even though it'll accept two in another instance.
>
Not really. The two things are fundamentally different. Yes, it's hard to
think of another example, but they aren't the same. ";" means "implicit
newline to the *same indentation*", whereas a newline does not.
> Here's a side challenge. In any shell you like, start with this
> failing statement, and then fix it without retyping anything:
>
> sikorsky@sikorsky:~$ python -c "a=1; if a: print(a)"
> File "<string>", line 1
> a=1; if a: print(a)
> ^
> SyntaxError: invalid syntax
>
> In bash, I was unable to insert a newline into the quoted string. My
> only option was to backspace everything after the point where I wanted
> the newline, then hit enter, then retype the if. I'm curious to know
> if that's simply because I didn't think of (some bash feature), or
> alternatively, if there's another shell that would have made this
> easy.
>
I have to thank Jussi Piitulainen for the command here, I'm likely gonna'
use that quite a bit.
> Back to the main point. In C-like languages, the newline is nothing
> special. (ECMAScript allows the omission of semicolons at end of line
> in many cases, but many style guides recommend using them anyway.) You
> can, if you so desire, put all your code into a single line. It's then
> up to the project's style guide to decide how things should be laid
> out. For instance, this is multiple statements in PHP, but I see it as
> one logical action:
>
> $bar=array(); for ($foo as $k=>$v) $bar[$k]="<p>".$v."</p>";
>
> It's one statement in Python:
>
> bar = ["<p>"+x+"</p>" for x in foo]
>
> It's one statement in Pike:
>
> array bar = map(foo,lambda(string x) {return "<p>"+x+"</p>";});
>
> So it should be allowed to be put on one line
Your argument goes:
FACT 1: You can do this in one statement, in one line.
FACT 2: In other languages you can do this in two statements, in one line
CONCULSION: You should be able to do this in two statements, in one line
Which I don't agree with. I understand that it is one *logical action*, but
so is multiplying a matrix. We have functions to *wrap* logical actions
that are composed of multiple logical actions.
The problem is that Python uses indentation. That's fundamentally the
problem.
> And in languages whose
> syntax derives from C, you almost certainly can. (I can't think of any
> counter-examples, though that certainly doesn't prove they don't
> exist.) But the same thing is forced onto two lines in Python, and not
> for syntactic reasons - at least, not that I can see. Perhaps someone
> can enlighten me.
>
> Is there any fundamental reason that the syntax couldn't be expanded
> to permit "statement; statement" for any two given statements?
>
Because Python uses indentation, what would "if A: print(1); if B:
print(2)" even do? It *has* to fail, because we have to assume consistent
indentation for ";"s*. With "\n" as I proposed, you still have to indent:
it is just a method to bypass lame shells [it would become "if A:
print(1)\nif B: print(2)"].
Blocks that avoid this have been done to death with multi-line lambdas, and
the majority of people don't like them. I'm sway-able, but it's not going
to happen because Guido and most of the peeps with power aren't. Anything
that challenges the standard now is dead from the start.
* You *could* have some rules that govern ambiguities well, but none that I
can think of would be *both* backward-compatible *and* complete. If it's
incomplete we've just moved the goalpost.
--
http://mail.python.org/mailman/listinfo/python-list
