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

[Michel Desmoulin]

Le 01/04/2016 14:37, Paul Moore a écrit :
> 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
> 

This is actually a very convincing one :)