[Python-ideas] Fwd: Make parenthesis optional in parameterless functions definitions

[Paul Moore]

On 1 April 2016 at 12:49, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
> Is there really a strong case against it than just "it's not pure" ?
> I've seen of lot of this argument on the list lately and I find it
> counter productive.
>
> There are dozen of good way to oppose an idea, just saying "we got a
> moral stand to not do it" is not convincing. Espacially in a language
> with so many compromised like len(foo) instead of foo.len, functional
> paradigme and Poo and immutability and mutability, etc.

You seem to have missed the argument that's been made a couple of
times, which is that you would then have two ways of doing the same
thing (empty parentheses would need to still be allowed for backward
compatibility) and Python has a strong tradition of "there should only
be one way of doing things". (Yes, it's not always followed 100%, as
with any real life situation not everything is perfect). You may
prefer to allow people to choose their own style and have options. But
as a maintainer, I can confirm that I personally prefer code that I
have to maintain to have a consistent style, and Python's lack of
multiple ways to say the same thing is a benefit in ensuring that
happens. So for me, your proposal would result in extra work, and no
benefit (I would continue adding "()" as I find that style more
readable and consistent).

This is not a "moral stand". The "one way to do things" principle is a
highly practical decision based on experience of different programming
environments - Perl in particular allowed many ways of doing the same
thing ("there's more than one way to do it" was a catch phrase in the
Perl community) and it's an acknowledged fact that Perl code is hard
to maintain as a consequence (unless strict style guidelines are
imposed).

As someone proposing a change to the Python language, the onus is on
you to argue the benefits of your change, not on others to argue
against it. If no-one does anything, Python won't change so you have
to convince people. At the moment your argument is little more than
"it looks neater", and opinions on that are clearly divided. As
there's a *huge* amount of material that would need changing as a
result of the change (documentation, training courses, style guides,
IDEs, ...) you need a much better argument - and complaining that the
people pointing out that your argument isn't strong enough are being
"counter productive" is not helpful.

If we're discussing "I've seen a lot of it on this list lately", then
I would argue that there has been an awful lot of ideas proposed here
recently which don't take into account the significant and genuine
costs involved in *any* change to Python, and as a result don't even
try to offer a justification for the proposal that is in proportion to
the impact of the change. It's perfectly possible to propose a change
here, have it supported, and get it implemented - but it needs *work*,
and a lot of the discussions here are pointless because no-one is
willing to do any work (not even the amount of work needed to convince
the core developers that their proposal is worthwhile). It's very easy
to accuse people of not being willing to listen to your proposals -
but I challenge you to try to get a change like this included into C++
or Java, if you think that about Python!

Paul