On Thu, May 3, 2012 at 12:21 PM, Garrett Cooper <yaneg...@gmail.com> wrote:
> On Thu, May 3, 2012 at 12:03 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > > On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper <yaneg...@gmail.com> > wrote: > >> I was wondering whether this was a parser bug or feature (seems > >> like a bug, in particular because it implicitly encourages bad syntax, > >> but I could be wrong). The grammar notes (for 2.7 at least [1]) don't > >> seem to explicitly require a space between 'in' and another parser > >> token (reserved work, expression, operand, etc), but I could be > >> misreading the documentation. > > > > The grammar doesn't require whitespace there. It tends to be flexible > > about whitespace wherever it's not necessary to resolve ambiguity. > > > >>>> x = [3, 2, 1] > >>>> x [0]if x [1]else x [2] > > 3 > >>>> 1 . real > > 1 > >>>> 1.5.real > > 1.5 > > Sure.. it's just somewhat inconsistent with other expectations in > other languages, and seems somewhat unpythonic. > Not really a big deal (if it was I would have filed a bug > instead), but this was definitely a bit confusing when I ran it > through the interpreter a couple of times... > Thanks! > -Garrett > -- > http://mail.python.org/mailman/listinfo/python-list > For the code prettiness police, check out pep8 and/or pylint. I highly value pylint for projects more than a couple hundred lines. For the whitespace matter that's been beaten to death: http://stromberg.dnsalias.org/~strombrg/significant-whitespace.html I'll include one issue about whitespace here. In FORTRAN 77, the following two statements look very similar, but have completely different meanings, because FORTRAN had too little significant whitespace: DO10I=1,10 DO10I=1.10 The first is the start of a loop, the second is an assignment statement.
-- http://mail.python.org/mailman/listinfo/python-list
