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

Sven R. Kunze srkunze at mail.de
Tue May 23 12:08:38 EDT 2017


On 20.05.2017 18:06, Nick Coghlan wrote:
> That's fine for someone that's already comfortable writing those
> behaviours by hand and just wants to automate the boilerplate away
> (which is exactly the problem that attrs was written to solve), but
> it's significantly more problematic once we assume people will be
> using a feature like this *before* learning how to write out all the
> corresponding boilerplate themselves (which is the key additional
> complication that a language level version of this will have to
> account for).

That's a good point. At least, Python does a very good job at reducing 
boilerplate in many cases in the first case.

One usually starts small instead of big.

> [API sketch]
>
> In this particular API sketch, data_record is just a class decorator
> factory, and data_field is a declarative helper type for use with that
> factory, so if you wanted to factor out particular combinations, you'd
> just write ordinary helper functions.

I might weigh in that decorating classes seems to be a bit awkward. 
Especially because I know that there are many people and frameworks out 
there telling you to decorate your classes with their decorators.

If you don't pay enough attention, you end up having something like this:

@nice_decoration(para1, para2)
@decorate_somehow
@important_decoration(para3)
@please_use_me()
class MyClass(Mixin2, Mixin1, BaseClass):
     para4 = 'foo'
     para5 = 'bar'
     para6 = 'boo'
     para7 = 'baz'


So, there's a region with decorations (decorators + params) OUTSIDE the 
class and there's a region with declarations (mixins + params) INSIDE 
the class; BOTH doing some sort of configuration of the class.

I honestly cannot tell which API style would be better but it seems we 
(at least internally) decided for the latter version: "If it belongs to 
the class, it should be inside the class."

Maybe, Python standard declarative class construction could be an 
exception because it's the default. But I am not sure. Technically, I 
think, both approaches can achieve the same result.

> Database object-relational-mapping layers like those in SQL Alchemy
> and Django would be the most famous precursors for this, but there are
> also things like Django Form definitions, and APIs like JSL (which
> uses Python classes to declaratively define JSON Schema documents).
>
> For folks already familiar with ORMs, declarative classes are just a
> matter of making in memory data structures as easy to work with as
> database backed ones. For folks that *aren't* familiar with ORMs yet,
> then declarative classes provide a potentially smoother learning
> curve, since the "declarative class" aspects can be better separated
> from the "object-relational mapping" aspects.

Well said.

Regards,
Sven



More information about the Python-ideas mailing list