[Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Stephan Houben]

Hi Michel,

> Now OPP is already hard to teach to my students, but if I have to add
> this to the mix, I will just have to tell them to copy / paste it
> blindly for a long time before I can get to the point they can
> understand what it does.

About the teachability, some remarks:
1. You can still just skip it. I presume you don't teach all the
advanced metaclass
   stuff right away either, even though it is part of core Python.

2. Is it really that complicated? attr.s is just a normal Python
function, which adds some members to a class.
  You don't even have to use the decorator @ syntax, that is just a convenience.
 To me this seems easier to teach than yet another dedicated syntax.

Stephan

2017-05-17 10:15 GMT+02:00 Michel Desmoulin <desmoulinmichel at gmail.com>:
>
>
> Le 17/05/2017 à 07:22, Guido van Rossum a écrit :
>> On Tue, May 16, 2017 at 8:14 PM, Juancarlo Añez <apalala at gmail.com
>> <mailto:apalala at gmail.com>> wrote:
>>
>>     What I like about attrs is:
>>
>>       * The class level declaration of instance attributes
>>       * That the reasonable *init*, *repr*, and *eq* are generated
>>
>> OK, the former should be doable using PEP 526 (the type is stored in
>> __annotations__ and the default in the class dict given to the
>> metaclass), while the latter should be doable using a standard metaclass
>> -- assuming we can agree on what the "reasonable" __init__, __repr__ and
>> __eq__ should do.
>>
>>
>>     I don’t like the excessive wordiness in attrs,
>>
>> Really? @attr.s is wordy? :-) I think it's deadly cute. (The only
>> library I've ever seen that did something worse was "monocle" which used
>> @_o.)
>
>>>> import attr
>>>> @attr.s
> ... class Point:
> ...     x = attr.ib(default=42)
> ...     y = attr.ib(default=attr.Factory(list))
>
>
> Is pretty wordy compared to something like another language would do
> such as:
>
> class Point:
>    int x = 42
>    list y = []
>
> Now I get that:
>
> - Python already has a similar syntax creating class attributes.
> - You can't put mutable objects here.
> - attr does more since it generates dunder methods.
>
> But having an import, a decorator and verbose calls to attr.ib does not
> feel like idiomatic Python at all. Python is an elegant and expressive
> language. This is none of the above. Also Python is beginner friendly.
> Now OPP is already hard to teach to my students, but if I have to add
> this to the mix, I will just have to tell them to copy / paste it
> blindly for a long time before I can get to the point they can
> understand what it does.
>
> We should be able to find a middle ground.
>
> First, if we have something LIKE attr, should it need an import? Basic
> data structures may not require an import to work. async/await are way
> better than import @asyncio.coroutine.
>
> Secondly, while I really, really, really want this feature, I think we
> should not rush it.
>
> Some ideas have to be explored.
>
> E.G:
>
> Adding keywords for it ? I know adding a keyword is the worst thing one
> can suggest on this list ever. But it has to be mentioned because most
> other languages do it this way.
>
> class Point:
>     instancevar x = 42
>     instancevar y = lazy [] # we add a debate about this a few months ago
>
>
> Adding a special syntax for it ? ruby has something similar.
>
> class Point:
>     @x = 42
>     @@y = list
>
> Upgrading the class constructor? It does not address the mutablility
> issue though.
>
> class Point(x=42, y=[])
>
> Mixing concepts?
>
>
> class Point(metaclass=autoclass(x=42, y=lazy [])):
>     pass
>
> @args(x=42)
> @factory_args(y=list)
> @autodunder()
> class Point:
>     pass
>
> @autoclass(
>     x=42
>     y=autoclass.lazy(list)
> )
> class Point:
>     pass
>
>
> Just adding attrs, which is a workaround to a missing feature in Python,
> as a boiler plate and calling it a day seems unwise.
>
> Don't get me wrong, I like attrs, I like asyncio and I like the whole
> battery included concept. But we lived without it until now, so let's
> not go too fast on this.
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/