I have been trying to find a way to moderate items going into the database so that a super user must approve before things are displayed. I found that Django-monitor manages to do pretty much all of that, I have been reading and following the documentation (here) and whenever I call django_monitor.nq(model_name) I get an error saying:
get_model takes at most 3 arguments (4 given)
I don't understand what is causing this problem and have been unable to find anything to help solve it.
That looks like a lib problem. if you are certain that it is caused on that line, then the lib's work is getting the error. I doubt that it's a lib error, so a full traceback would help a lot, and the models declaration as well.
Also, see if your django version is supported by the lib.
By the way, that error is caused when you call a function with too many arguments.
imagine that you have a class
class Foo(object):
def __init__(self, other):
self.other=other
calling:
>>> Foo(1)
<Foo object at 0x7f27566f90d0>
>>> Foo(1,2)
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: __init__() takes exactly 2 arguments (3 given)
Foo(1) works because the class's init takes 2 arguments(self and other)
It seems like it's incompatible with your django version. Looking at the repo source it seems like it was fixed:
try:
registered_model = get_model(
model._meta.app_label, model._meta.object_name, False, False
)
except TypeError:
# Django versions prior to 1.4 accept 3 params to get_model.
registered_model = get_model(
model._meta.app_label, model._meta.object_name, False
)
Unless the error raised now is not a TypeError.
get_model() was changed in 1.7 as explained in the release notes:
The app registry has preserved some features of the old app cache.
Even though the app cache was a private API, obsolete methods and
arguments will be removed through a standard deprecation path, with
the exception of the following changes that take effect immediately:
[...]
The only_installed argument of get_model and get_models no longer exists, nor does the seed_cache argument of get_model.
Since django-monitor tries to pass at least one of these arguments to get_model(), it is incompatible with Django 1.7+. It only accepts the app_label and model_name arguments.
Related
If your question was closed as a duplicate of this, it is because you had a code sample including something along the lines of either:
class Example:
def __int__(self, parameter):
self.attribute = parameter
or:
class Example:
def _init_(self, parameter):
self.attribute = parameter
When you subsequently attempt to create an instance of the class, an error occurs:
>>> Example("an argument")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Example() takes no arguments
Alternately, instances of the class seem to be missing attributes:
>>> class Example:
... def __int__(self): # or _init_
... self.attribute = 'value'
>>> Example().attribute
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'Example' object has no attribute 'attribute'
You might also wonder: what do these exception messages mean, and how do they relate to the problem? Why didn't a problem occur earlier, for example, with the class definition itself? How else might the problem manifest? How can I guard against this problem in the future?
This is an artificial canonical duplicate created specifically to head off two of the most common typographical errors in code written by new Python programmers. While questions caused by a typo are normally closed for that reason, there are some useful things to explain in this case, and having a duplicate target allows for closing questions faster. I have tried to design the question to be easy to search for.
This is because the code has a simple typographical error: the method should instead be named __init__ - note the spelling, and note that there are two underscores on each side.
What do the exception messages mean, and how do they relate to the problem?
As one might guess, a TypeError is an Error that has to do with the Type of something. In this case, the meaning is a bit strained: Python also uses this error type for function calls where the arguments (the things you put in between () in order to call a function, class constructor or other "callable") cannot be properly assigned to the parameters (the things you put between () when writing a function using the def syntax).
In the examples where a TypeError occurs, the class constructor for Example does not take arguments. Why? Because it is using the base object constructor, which does not take arguments. That is just following the normal rules of inheritance: there is no __init__ defined locally, so the one from the superclass - in this case, object - is used.
Similarly, an AttributeError is an Error that has to do with the Attributes of something. This is quite straightforward: the instance of Example doesn't have any .attribute attribute, because the constructor (which, again, comes from object due to the typo) did not set one.
Why didn't a problem occur earlier, for example, with the class definition itself?
Because the method with a wrongly typed name is still syntactically valid. Only syntax errors (reported as SyntaxError; yes, it's an exception, and yes, there are valid uses for it in real programs) can be caught before the code runs. Python does not assign any special meaning to methods named _init_ (with one underscore on each side), so it does not care what the parameters are. While __int__ is used for converting instances of the class to integer, and shouldn't have any parameters besides self, it is still syntactically valid.
Your IDE might be able to warn you about an __int__ method that takes suspicious parameters (i.e., anything besides self). However, a) that doesn't completely solve the problem (see below), and b) the IDE might have helped you get it wrong in the first place (by making a bad autocomplete suggestion).
The _init_ typo seems to be much less common nowadays. My guess is that people used to do this after reading example code out of books with poor typesetting.
How else might the problem manifest?
In the case where an instance is successfully created (but not properly initialized), any kind of problem could potentially happen later (depending on why proper initialization was needed). For example:
BOMB_IS_SET = True
class DefusalExpert():
def __int__(self):
global BOMB_IS_SET
BOMB_IS_SET = False
def congratulate(self):
global BOMB_IS_SET
if BOMB_IS_SET:
raise RuntimeError("everything blew up, gg")
else:
print("hooray!")
If you intend for the class to be convertible to integer and also wrote __int__ deliberately, the last one will take precedence:
class LoneliestNumber:
def __int__(self):
return 1
def __int__(self): # was supposed to be __init__
self.two = "can be as bad"
>>> int(LoneliestNumber())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __int__ returned non-int (type NoneType)
(Note that __int__ will not be used implicitly to convert instances of the class to an index for a list or tuple. That's done by __index__.)
How might I guard against the problem in the future?
There is no magic bullet. I find it helps a little to have the convention of always putting __init__ (and/or __new__) as the first method in a class, if the class needs one. However, there is no substitute for proofreading, or for training.
If your question was closed as a duplicate of this, it is because you had a code sample including something along the lines of either:
class Example:
def __int__(self, parameter):
self.attribute = parameter
or:
class Example:
def _init_(self, parameter):
self.attribute = parameter
When you subsequently attempt to create an instance of the class, an error occurs:
>>> Example("an argument")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Example() takes no arguments
Alternately, instances of the class seem to be missing attributes:
>>> class Example:
... def __int__(self): # or _init_
... self.attribute = 'value'
>>> Example().attribute
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'Example' object has no attribute 'attribute'
You might also wonder: what do these exception messages mean, and how do they relate to the problem? Why didn't a problem occur earlier, for example, with the class definition itself? How else might the problem manifest? How can I guard against this problem in the future?
This is an artificial canonical duplicate created specifically to head off two of the most common typographical errors in code written by new Python programmers. While questions caused by a typo are normally closed for that reason, there are some useful things to explain in this case, and having a duplicate target allows for closing questions faster. I have tried to design the question to be easy to search for.
This is because the code has a simple typographical error: the method should instead be named __init__ - note the spelling, and note that there are two underscores on each side.
What do the exception messages mean, and how do they relate to the problem?
As one might guess, a TypeError is an Error that has to do with the Type of something. In this case, the meaning is a bit strained: Python also uses this error type for function calls where the arguments (the things you put in between () in order to call a function, class constructor or other "callable") cannot be properly assigned to the parameters (the things you put between () when writing a function using the def syntax).
In the examples where a TypeError occurs, the class constructor for Example does not take arguments. Why? Because it is using the base object constructor, which does not take arguments. That is just following the normal rules of inheritance: there is no __init__ defined locally, so the one from the superclass - in this case, object - is used.
Similarly, an AttributeError is an Error that has to do with the Attributes of something. This is quite straightforward: the instance of Example doesn't have any .attribute attribute, because the constructor (which, again, comes from object due to the typo) did not set one.
Why didn't a problem occur earlier, for example, with the class definition itself?
Because the method with a wrongly typed name is still syntactically valid. Only syntax errors (reported as SyntaxError; yes, it's an exception, and yes, there are valid uses for it in real programs) can be caught before the code runs. Python does not assign any special meaning to methods named _init_ (with one underscore on each side), so it does not care what the parameters are. While __int__ is used for converting instances of the class to integer, and shouldn't have any parameters besides self, it is still syntactically valid.
Your IDE might be able to warn you about an __int__ method that takes suspicious parameters (i.e., anything besides self). However, a) that doesn't completely solve the problem (see below), and b) the IDE might have helped you get it wrong in the first place (by making a bad autocomplete suggestion).
The _init_ typo seems to be much less common nowadays. My guess is that people used to do this after reading example code out of books with poor typesetting.
How else might the problem manifest?
In the case where an instance is successfully created (but not properly initialized), any kind of problem could potentially happen later (depending on why proper initialization was needed). For example:
BOMB_IS_SET = True
class DefusalExpert():
def __int__(self):
global BOMB_IS_SET
BOMB_IS_SET = False
def congratulate(self):
global BOMB_IS_SET
if BOMB_IS_SET:
raise RuntimeError("everything blew up, gg")
else:
print("hooray!")
If you intend for the class to be convertible to integer and also wrote __int__ deliberately, the last one will take precedence:
class LoneliestNumber:
def __int__(self):
return 1
def __int__(self): # was supposed to be __init__
self.two = "can be as bad"
>>> int(LoneliestNumber())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __int__ returned non-int (type NoneType)
(Note that __int__ will not be used implicitly to convert instances of the class to an index for a list or tuple. That's done by __index__.)
How might I guard against the problem in the future?
There is no magic bullet. I find it helps a little to have the convention of always putting __init__ (and/or __new__) as the first method in a class, if the class needs one. However, there is no substitute for proofreading, or for training.
Django==3.2.5
django-haystack==3.0
pysolr==3.9.0
Solr = 8.9.0
I am following the tutorial as in
https://django-haystack.readthedocs.io/en/master/tutorial.html to create an Django application with Solr.
While executing ./manage.py rebuild_index, I am getting an error like:
**File "/..../tele_env/lib/python3.8/site-packages/haystack/indexes.py",
line 202, in build_queryset
index_qs = self.index_queryset(using=using)
TypeError: index_queryset() got an unexpected keyword argument 'using'**
I am stuck up since 3 days solving this error. Tried to downgrade each of
the packages (Django, pysolr, haystack with solr 6.6, but didn't help me.
Please help me to get out of this circle of upgrading and downgrading...
Thanks in advance
So I've just read the sources from django-haystack 3.0 and there are several weird things.
First thing is that the using parameter is never used in the function definition (maybe its for subclasses, I didnt dig that far):
def index_queryset(self, using=None):
"""
Get the default QuerySet to index when doing a full update.
Subclasses can override this method to avoid indexing certain objects.
"""
return self.get_model()._default_manager.all()
Back to your error, in the build_queryset method, the parameter using is passed to the function index_queryset not the queryset itself, so I can't see why it would raise an error.
Last thing is, I tested with both Django 2 and 3 projets, and using is always a method of queryset, not an argument, so I'm quite confused. Is your traceback from Django 3.2 and haystack 3.0 ?
This question already has answers here:
Decorators with parameters?
(23 answers)
Closed 3 years ago.
I am going to write a function decorator that takes an argument and returns a decorator that can be used to control the type of the argument to a one-argument function. I expect a raising error happens in case the passed argument be in a wrong type.
def typecontrol(num_type):
def wrapper_function(num):
if isinstance(num, num_type):
return num
else:
raise TypeError
return wrapper_function
#typecontrol(float)
def myfunc(num):
print(num)
I expect for example, myfunc(9.123) should print 9.123 and myfunc(9) should raise an error. But it always raises type error.
typecontrol will be a function that returns the decorator, not the decorator itself. You need an extra nested function:
def typecontrol(num_type):
def decorator(f):
def wrapper_function(num):
if isinstance(num, num_type):
f(num)
else:
raise TypeError
return wrapper_function
return decorator
#typecontrol(float)
def myfunc(num):
print(num)
The wrapper function will take care of calling the wrapped function if the typecheck passes, rather than returning the typechecked argument.
In your code as written, num is actually the function you are decorating, so you are checking if a function is an instance of (in this case), float.
Some examples:
>>> myfunc(3.0)
3.0
>>> myfunc("foo")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "tmp.py", line 7, in wrapper_function
raise TypeError
TypeError
As others have commented, a good explanation on writing decorators with arguments is found here.
However, it seems like you want to enforce types (I've gone down a similar rabbit hole before in Python) so depending on your use case would I possibly recommend two options:
If you want to make sure that your program is typed correctly prior to runtime, use the mypy static type checker.
If you need to parse/validate input values at runtime, I would highly suggest the pydantic package. It allows you to create "struct-like" objects (similar to a NamedTuple, or a dataclass) that will enforce runtime type checks and will appropriately coerce the input at runtime using Python 3.6+ type hints. Documentation and some helpful examples can be found here.
Depending on your use case, I hope either of these two help!
I'm getting this error since this morning, passed days the same code worked. I'm working with the pythonforfacebook API.
This is my code:
graph = facebook.GraphAPI(accesstoken)
graph.put_object(page_id, 'feed', message="Just posting something on my wall")
If I use 'me' instead of the page_id it works. But I need it posted on my fanpage, not my profile page. I already checked the page_id via the Graph API explorer and that is correct.
This is the error:
Traceback (most recent call last):
File "C:/Users/kyra/PycharmProjects/MyProject/com/facebook/Working_FB.py", line 68, in <module>
graph.put_object(page_id, 'feed', message="Just posting something on my wall")
File "C:/Users/kyra/PycharmProjects/MyProject/com/facebook/Working_FB.py", line 64, in graph.put_object
raise facebook.GraphAPIError
TypeError: __init__() takes exactly 2 arguments (1 given)
It looks like this happens during the creation of the exception object in
raise facebook.GraphAPIError
Obviously, GraphAPIError requires at least one argument.
Either provide a readily built exception object such as
raise facebook.GraphAPIError(whatever)
or give raise the requires argument in order to let it build that object:
raise facebook.GraphAPIError, whatever
This will, at least, remove the TypeError when trying to raise the exception. But why the exception raises at the first place is subject to a more concrete search in the lines above the one with raise.