(original) (raw)

​I make this suggestion in trepidation, given that Guido called a halt on the Great Naming Debate, but it seems that a short, neutral name with data connotations previously not a part of many popular subsystems is required.

I therefore propose "row", which is sufficiently neutral to avoid most current opposition and yet a common field-oriented mechanism for accessing units of retrieved data by name.

regards
Steve​

Steve Holden

On Sat, Sep 16, 2017 at 3:44 PM, Sven R. Kunze <srkunze@mail.de> wrote:
Thanks for the PEP! :)

I like the naming. ;) Though, I would like to add to Michel's argument in favor of a base class.


On 11.09.2017 08:38, Michel Desmoulin wrote:
\- I read Guido talking about some base class as alternative to the
generator version, but don't see it in the PEP. Is it still considered ?
I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?
Not preferring, but having it as an alternative. Mainly for 2 reasons:

1 - data classes allow one to type in classes very quickly, let's
harvest the benefit from that.

Typing a decorator in a shell is much less comfortable than using
inheritance. Same thing about IDE: all current ones have snippet with
auto-switch to the class parents on tab.

All in all, if you are doing exploratory programming, and thus
disposable code, which data classes are fantastic for, inheritance will
keep you in the flow.

2 - it will help sell the data classes

I train a lot of people to Python each year. I never have to explain
classes to people with any kind of programming background. I \_always\_
have to explain decorators.

People are not used to it, and even kind fear it for quite some time.

Inheritance however, is familiar, and will not only push people to use
data classes more, but also will let them do less mistakes: they know
the danger of parent ordering, but not the ones of decorators ordering.

3) - the order of base classes can arranged appropriately

In our day-to-day work, we use mixins and cooperative multiple inheritance a lot.
So, having dataclasses as a base class or a mixin would be great! :)

Combined with 1) and 2), I am much in favor of having dataclasses as base class/mixin than as a decorator.
What are the benefits of the decorator? Maybe both is possible?

Cheers,
Sven


PS: @Michel good observation 1). Typing decorators in shell is annoying.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com