search

ionelmc / python-fields

A totally different take on container boilerplate.
BSD 2-Clause "Simplified" License
138 stars 8 forks source link

Can't add required fields after fields with defaults #5

Closed wimglenn closed 7 years ago

wimglenn commented 7 years ago

I want to disable filling of fields positional and require them to be specified by name, and enable defaults anywhere in the construction. Something like this:

class Player(Fields.name.hitpoints[100].damage.armour):
    ...

Is it possible with fields?

ionelmc commented 7 years ago

It's a limitation "by design" to avoid issues with default arguments.

For class Player(Fields.name.hitpoints[100].damage.armour) we can't really have an def __init__(self, name, hitpoints=100, damage, armour) since it's invalid syntax (you can't have positionals after kwargs).

Sure, fields could in theory be changed to allow class Player(Fields.name.hitpoints[100].damage.armour) but then you'll need to supply your own class factory (the so called "sealer"). What would be the point of the library then?

Why do you need this anyway?

wimglenn commented 7 years ago

Hi Ionel, thanks for the prompt response! It seems a leaky abstraction that class A(Fields.x.y[0].z) should be prohibited solely for the reason that __init__(self, x, y=0, z) would be an invalid argspec. That's an artificial restriction of the interface, unless I'm missing something? There are ways to make it work in the absence of this limitation, while preserving all the cases where it currently works.

It can fill in variables in the correct places, preserve ordering of the dir, and generate useful error messages if an attempt to initialise with incorrect args is made. You have to make a decision about what A(1,2,3) would return (or should it raise?), and document that, but it can be done without ambiguity.

ionelmc commented 7 years ago

I'm not willing to support that sort of usecase with the builtin sealers for the simple reason that python itself don't support it "naturally". IOW it's a too uncommon usecase.

I could make the check lazy (not pretty but doable) but that would mean I have to change the sealer api and you have to implement your own sealer. Do you really think this is worthwhile? Or satisfactory for that matter ...

You can always fork this project, chop off the stuff you don't need and remove the check completely. I'll even review your changes if you need help. I think that's better for both of us.

wimglenn commented 7 years ago

OK, "uncommon use case" is a perfectly acceptable answer. I was mostly just wondering if there was existing support for that without needing to dive to far into the sources. I'll close this issue.