Forums
New posts
Search forums
Members
Current visitors
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Archive
Archive
Python
Variable arguments (*args, **kwargs): seeking elegance
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
[QUOTE="Steven D'Aprano, post: 5119552"] It's really hard to make definitive judgements without actually seeing your code and understanding your use-case. I can only suggest that, you *may* be complicating things unnecessarily. On the other hand, there's always the chance that your requirements are sufficiently unusual that you have done exactly what needs to be done. But I suspect even in this case, there may be a more elegant way to solve the problem of "I'm finding it to be a bit clunky", to quote your original post. Clunky code can sometimes be smoothed out by refactoring the complexity by use of decorators. Can you post an example of your code? One thought -- often, people turn to subclassing as the only tool in their toolbox. Have you considered that it may be easier/better to work with delegation and composition instead? Don't forget ndarray.__array_finalize__, __array_wrap__ and __array_prepare__. I am not an expert on numpy, but reading that page just makes me think they're doing it all wrong, adding far too much complication. (I've written code like that myself, but thank goodness I've had the sense to throw it away and start again...). I'm trying to give them the benefit of the doubt, but I've never liked the amount of DWIM cleverness in numpy, and I think they would have been *much* better off having a clean separation between the three ways of creating an array: - the normal Python __new__ and __init__ mechanism - creating a view into an array - templating instead of conflating the three into a single mechanism. I suspect that the fundamental confusion comes about because numpy doesn't have a clean distinction between views into an array, and actual arrays. Although I must admit I've not done more than dip my toe into numpy, so you should take my criticisms with a generous pinch of salt. The usual way of doing this is to accept only keyword arguments for any additional args: class Base: def __new__(cls, doc, grumpy, happy, sleepy, bashful, sneezy, dopey): ... class Subclass(Base): def __new__(cls, *args, **kwargs): # grab the additional arguments sneaky = kwargs.pop('sneaky', True) # optional grabby = kwargs.pop('grabby') # mandatory touchy = kwargs.pop('touchy') feely = kwargs.pop('feely') instance = super(Subclass, cls).__new__(cls, *args, **kwargs) # process additional arguments instance.apply_extras(sneaky, grabby, touchy, feely) return instance # In Python 3, I can do this to make it even cleaner: class Subclass(Base): def __new__(cls, *args, sneaky=True, grabby, touchy, feely, **kwargs): instance = super(Subclass, cls).__new__(cls, *args, **kwargs) # process additional arguments instance.apply_extras(sneaky, grabby, touchy, feely) return instance In general, you should aim to use either __new__ or __init__ but not both, although that's not a hard law, just a guideline. Can you adapt this pattern to ndarray? [/QUOTE]
Verification
Post reply
Forums
Archive
Archive
Python
Variable arguments (*args, **kwargs): seeking elegance
Top