31–40 of 42 posts
def __init__(self, x, y):
self.x = x
self.y = y
I prefer the simpler: class A(object): def __init__(self, x, y): self.__dict__.update((k,v) for k,v in locals().items() if k != 'self')
I prefer the simpler: class A(object): def __init__(self, x, y): self.__dict__.update((k,v) for k,v in locals().items() if k != 'self')
Earlier quoted context omitted.
In Python you have a "real" constructor you can use: __new__. So I think it's good not to call __init__ a constructor. Unless of course you differ in my opinion that __new__ is a constructor?
I do. __new__ is effectively an allocator, or an interface to it. It allocates an unconstructed object. Then the constructor, __init__ is called on that. Edited to add: Reading around, it appears that smalltalk has no separation between allocation and construction, having only the equivalent to `operator new`/`Class#new`/`obj.__new`, with initialization also happening in overloads of that. So some confusion may stem…
I prefer the simpler: class A(object): def __init__(self, x, y): self.__dict__.update((k,v) for k,v in locals().items() if k != 'self')
Seriously, I couldn't finish the article once I saw he wasn't using locals. Is there some hidden gotcha that we are missing here that he's taking care of with his more complicated approach?
Earlier quoted context omitted.
I'll have to check my terminology to understand this better. But I can assure you that most of the programmers who take my Python classes (who tend to come from Java, C#, and C++) are rather surprised that the constructor modifies an existing object, and doesn't actually create the object. That said, I'm totally willing to believe that neither they nor I understood the difference between an "allocator" and a "constru…
Well, they have a poor understanding[1] of the sequence of events in C++ if they think that the constructor allocates the object there (I won't speak too strongly to Java or C#, since I don't work in them if I don't have to, but I believe that they both work in a very similar way). This would in fact be impossible, since many constructors are usually called for any given object (and all constructors in the object's g…
Earlier quoted context omitted.
nice but it doesn't work if not all kwargs are passed..
Here is another version implemented as a decorator. Actually I’d also like not to use inspect, but didn’t find any nice way to get the kwargs default values without it, any suggestion? import inspect def autoinit(decorated_init): def _wrap(*args, **kwargs): obj, nargs= args[0], args[1:] names = decorated_init.func_code.co_varnames[1:len(nargs)+1] nargs = {k: nargs[names.index(k)] for k in names} kwa_keys = decorated_…
This kind of complexity and the esoterica involved is exactly what terrifies me about Python.
This kind of complexity and the esoterica involved is exactly what terrifies me about Python.
The thing with Python is that you don't need to know this stuff to use the language effectively. Yes, after a while, you'll want to dive into the innards -- but they're optional for most people during their initial time learning Python.