I want to implement a class that will wrap -- not subclass -- the python dict object, so that when a change is detected in a backing store I can re-create the delegated dict object. I intend to check for changes in the backing store each time the dict is accessed for a read.
Supposing I was to create an object to act like this; what methods would I need to implement?
You can subclass the ABC (abstract base class) collections.Mapping (or collections.MutableMapping if you also want to allow code using your instances to alter the simulated/wrapped dictionary, e.g. by indexed assignment, pop, etc).
If you do so, then, as the docs I pointed to imply somewhat indirectly, the methods you need to implement are
__len__
__iter__
__getitem__
(for a Mapping) -- you should also implement
__contains__
because by delegating to the dict you're wrapping it can be done much faster than the iterating approach the ABC would have to apply otherwise.
If you need to supply a MutableMapping then you also need to implement 2 more methods:
__setitem__
__delitem__
In addition to what's already been suggested, you might want to take a look at UserDict.
For an example of a dict like object, you can read through django's session implementation, specifically the SessionBase class.
I think it depends on which methods you use. Probably __getitem__, __setitem__, __iter__ and __len__ as most things can be implemented in terms of those. But you'll want to look at some use cases, particularly with __iter__. Something like this:
for key in wrapped_dictionary:
do_something(wrapped_dictionary[key])
...is going to be slow if you hit the data source on each iteration, not to mention that it might not even work if the data source is changing out from under you. So you'll want to maybe throw some sort of exception there and implement iteritems as an alternative, loading all the key-value pairs in one batch before you loop over them.
The Python docs have item listings where you can look for methods and use-cases.
Related
I am in doubt if a regular dict and an OrderedDict objects are truly interchangeable in a sense that the same function or method could return once a dict and other times an OrderedDict depending on the input arguments or for example in case of a class method depending on some other internal class instance attributes. If returning an OrderedDict would be significantly more costly than returning just a regular dict which should suffice as well why doing it the hard way? Would it be pythonic to create such a function or menthod? I use Python 2.7.
I have seen "Why should functions always return the same type?" and I felt my case is more special and less obvious to the unseasoned eye.
Python uses duck typing. as long as an object presents the necessary interface required for an action, the type of object is irrelevant. An OrderedDict will present all the interfaces a dict would, so what the function returns is irrelevant. It'll be up to whatever uses what was returned. You should figure out the implementation of the use not the returning function.
What's your use case? Detailing that would help in suggesting an answer or alternatives.
in NDB you have repeated properties, they behave just like a native python list but i want them to behave just like native sets.
i need to have a set of keys that is without duplicates.
in python you can remove duplicates like the_list = list(set(the_list)),
but how would you implement this so it is automatic and i don't to think about this ?
Three ways come to mind:
enforce the list (repeated property) is unique with a "setter" method that only inserts unique values;
likewise, enforce the list is unique with a _pre_put_hook() method;
use the key on each entity as your list, ndb will make sure they are unique.
Another option would be to subclass ndb.Property. Quite a few examples here:
https://cloud.google.com/appengine/docs/python/ndb/subclassprop
I believe the correct strategy would to build a custom SetProperty which subclasses the ListProperty, to enforce your requirements.
Have a read of up on Subclassing properties. https://cloud.google.com/appengine/docs/python/ndb/subclassprop
This I believe is the correct way for implementing this type of property, rather than _pre_put hooks. That is generally too late to perform appropriate validation and feedback.
You could write custom setters, however you setter can't be the name of the property, so this will look odd.
The other alternative would be to use a validator which is allowed to coerce the value. See https://cloud.google.com/appengine/docs/python/ndb/properties#options
Looks like there are multiple ways to do that but couldn't find the latest best method.
Subclass UserDict
Subclass DictMixin
Subclass dict
Subclass MutableMapping
What is the correct way to do? I want to abstract actual data which is in a database.
Since your dict-like class isn't in fact a dictionary, I'd go with MutableMapping. Subclassing dict implies dict-like characteristics, including performance characteristics, which won't be true if you're actually hitting a database.
If you are doing your own thing (e.g. inventing your own wheel) you might as well write the class from scratch (i.e. subclass from object), just providing the correct special members (e.g. __getitem__) and other such functions as described in the object data model, so that it quacks like a dict. Internally, you might even own a number of dicts (has-a) to help your implementation.
This way, you don't have to shoehorn your design to "fit" some existing implementation, and you aren't paying for some things you aren't necessarily using .This recommendation in part is because your DB-backed class will already be considerably more complex than a standard dict if you make it account for performance/caching/consistency/optimal querying etc.
Python supports a lot of magic methods for implementing custom functionality in objects, such as __lt__, __getattr__, etc. There are even magic methods that affect the way certain built-in functions perform, such as __len__ and __instancecheck__. But are there magic methods for all the built-in functions in python?
For example, if I wanted to change the way the any function would perform on a certain class, could I specify an __any__ magic method in that class? If that isn't an option, is there any way that I could specifically affect the way any applies to that class? (I realize that if I wanted special functionality for the way any receives the items from the iterable I could define __iter__, but that's not what I am looking to do)
Note that my desire to implement custom functionality for any is just an example, I don't explicitly want to define custom functionality for any.
The special method's let you hook into concepts, not so much built-in functions or other things.
__len__ is a container length, not specifically a hook for the len() function. It just happens that the len() function is the visible API for that functionality.
any() expects an iterable argument, the concept you are looking for here is the Iterator type methods; it's not the function that is hooked, it is that concept.
You may want to study the default type abstract base classes to see what methods Python types implement; here many special methods are grouped together in a readable overview.
No, only for lots of them, as practicality demands.
(Specifically for __any__, it has been discussed before, but ultimately, it wasn't considered to be needed.)
No. The list of special methods a class can implement are documented in section 3.3.
I have some Python code that creates a Calendar object based on parsed VEvent objects from and iCalendar file.
The calendar object just has a method that adds events as they get parsed.
Now I want to create a factory function that creates a calendar from a file object, path, or URL.
I've been using the iCalendar python module, which implements a factory function as a class method directly on the Class that it returns an instance of:
cal = icalendar.Calendar.from_string(data)
From what little I know about Java, this is a common pattern in Java code, though I seem to find more references to a factory method being on a different class than the class you actually want to instantiate instances from.
The question is, is this also considered Pythonic ? Or is it considered more pythonic to just create a module-level method as the factory function ?
[Note. Be very cautious about separating "Calendar" a collection of events, and "Event" - a single event on a calendar. In your question, it seems like there could be some confusion.]
There are many variations on the Factory design pattern.
A stand-alone convenience function (e.g., calendarMaker(data))
A separate class (e.g., CalendarParser) which builds your target class (Calendar).
A class-level method (e.g. Calendar.from_string) method.
These have different purposes. All are Pythonic, the questions are "what do you mean?" and "what's likely to change?" Meaning is everything; change is important.
Convenience functions are Pythonic. Languages like Java can't have free-floating functions; you must wrap a lonely function in a class. Python allows you to have a lonely function without the overhead of a class. A function is relevant when your constructor has no state changes or alternate strategies or any memory of previous actions.
Sometimes folks will define a class and then provide a convenience function that makes an instance of the class, sets the usual parameters for state and strategy and any other configuration, and then calls the single relevant method of the class. This gives you both the statefulness of class plus the flexibility of a stand-alone function.
The class-level method pattern is used, but it has limitations. One, it's forced to rely on class-level variables. Since these can be confusing, a complex constructor as a static method runs into problems when you need to add features (like statefulness or alternative strategies.) Be sure you're never going to expand the static method.
Two, it's more-or-less irrelevant to the rest of the class methods and attributes. This kind of from_string is just one of many alternative encodings for your Calendar objects. You might have a from_xml, from_JSON, from_YAML and on and on. None of this has the least relevance to what a Calendar IS or what it DOES. These methods are all about how a Calendar is encoded for transmission.
What you'll see in the mature Python libraries is that factories are separate from the things they create. Encoding (as strings, XML, JSON, YAML) is subject to a great deal of more-or-less random change. The essential thing, however, rarely changes.
Separate the two concerns. Keep encoding and representation as far away from state and behavior as you can.
It's pythonic not to think about esoteric difference in some pattern you read somewhere and now want to use everywhere, like the factory pattern.
Most of the time you would think of a #staticmethod as a solution it's probably better to use a module function, except when you stuff multiple classes in one module and each has a different implementation of the same interface, then it's better to use a #staticmethod
Ultimately weather you create your instances by a #staticmethod or by module function makes little difference.
I'd probably use the initializer ( __init__ ) of a class because one of the more accepted "patterns" in python is that the factory for a class is the class initialization.
IMHO a module-level method is a cleaner solution. It hides behind the Python module system that gives it a unique namespace prefix, something the "factory pattern" is commonly used for.
The factory pattern has its own strengths and weaknesses. However, choosing one way to create instances usually has little pragmatic effect on your code.
A staticmethod rarely has value, but a classmethod may be useful. It depends on what you want the class and the factory function to actually do.
A factory function in a module would always make an instance of the 'right' type (where 'right' in your case is the 'Calendar' class always, but you might also make it dependant on the contents of what it is creating the instance out of.)
Use a classmethod if you wish to make it dependant not on the data, but on the class you call it on. A classmethod is like a staticmethod in that you can call it on the class, without an instance, but it receives the class it was called on as first argument. This allows you to actually create an instance of that class, which may be a subclass of the original class. An example of a classmethod is dict.fromkeys(), which creates a dict from a list of keys and a single value (defaulting to None.) Because it's a classmethod, when you subclass dict you get the 'fromkeys' method entirely for free. Here's an example of how one could write dict.fromkeys() oneself:
class dict_with_fromkeys(dict):
#classmethod
def fromkeys(cls, keys, value=None):
self = cls()
for key in keys:
self[key] = value
return self