Why not allow empty code blocks?

Chris Angelico rosuav at gmail.com
Sun Jul 24 09:38:36 EDT 2016


On Sun, Jul 24, 2016 at 11:11 PM, Marco Sulla
<mail.python.org at marco.sulla.e4ward.com> wrote:
> On 24 July 2016 at 14:48, Chris Angelico <rosuav at gmail.com> wrote:
>> Maybe the people who are most worried about this can enact a
>> simple rule: no dedent without a blank line? That can easily be
>> verified by a script, and it'd protect against most of the given
>> examples. It's not too much effort (after any reasonable-sized block
>> you'll probably have a blank anyway, so it's only the tiniest of loops
>> that would be affected). And no language changes are needed :)
>
> I'm incredibly in favor of such a modification, but maybe this is work
> for a linter.

Sorry if I wasn't clear, but I definitely did mean for this to be the
work of a linter ("verified by a script", and "no language changes are
needed").

> Honestly, I find the "pass" statement very clear and simple. There's
> more misleading problems in Python syntax, like this:
>
> someFunction(
>     "param1"
>     "param2"  # comma missed, there will be only one parameter "param1param2"
> )

That can also be caught by a linter; it can also be caught by a
standard habit of ALWAYS putting trailing commas on anything that gets
wrapped. It's not so common with function calls, but the equivalent
situation with list display is:

colors = [
    "red",
    "green"
    "blue",
    "yellow",
    "cyan",
    "magenta"
]

Same problem with the missed comma, but it's also common enough to put
one after "magenta" too, and it's a great protection. Again, you could
have your linter demand this, if you wanted to (and put the linter
into your pre-commit hook or equivalent), or you could just eyeball it
("nothing at the end of the line? really?").

> and this one too:
>
> class Parent(Base):
>     __tablename__ = 'parent'
>     id = Column(Integer, primary_key=True)
>     children = relationship("Child"),  # comma inserted by error.
> children will be a tuple and SQLAlchemy will fail with misleading
> errors

Hmm, that's a bit harder to pin down, but since *none* of the members
will have commas here, I'd be surprised to spot one there. Though part
of the problem here is that SQLAlchemy is such a gigantic package that
its error messages tend to be a bit confusing. But that said, here's
what happened when I tried it:

rosuav at sikorsky:~$ python3
Python 3.6.0a3+ (default:bff31254a0f0, Jul 17 2016, 17:39:49)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sqlalchemy.ext.declarative import declarative_base
>>> from sqlalchemy import Column, Integer
>>> from sqlalchemy.orm import relationship
>>> Base = declarative_base()
>>> class Parent(Base):
...     __tablename__ = 'parent'
...     id = Column(Integer, primary_key=True)
...     children = relationship("Child"),
...
/usr/local/lib/python3.6/site-packages/sqlalchemy/ext/declarative/base.py:297:
SAWarning: Ignoring declarative-like tuple value of attribute
children: possibly a copy-and-paste error with a comma left at the end
of the line?
  "left at the end of the line?" % k)
>>> Parent
<class '__main__.Parent'>
>>>
rosuav at sikorsky:~$ python3 -m pip freeze|grep -i alchemy
SQLAlchemy==1.0.11

Maybe enabling warnings is all you need, or maybe it depends on the
version of SQLAlchemy. In any case, nice spot, declarative-base!

ChrisA



More information about the Python-list mailing list