Re: What is the semantics meaning of 'object'?
> * property only works in "new-style" classes that inherit from object; > > * likewise for super; Another question raised here is that what is the proper way to refer to parent class? For example, class A(object): def __init__(self, arg): print "A" class B(A): def __init__(self, arg): super(B, self).__init__(arg) Is this correct? As the result, whenever you wanted to refer to a method in parent class, super() functions has to be called. This seems inefficient. How to refer to a field defined in parent class? Thanks, /Adam >On Sun, Jun 23, 2013 at 03:20:02AM +, Steven D'Aprano wrote: > On Sat, 22 Jun 2013 19:58:38 -0700, Adam wrote: > > > class FooBar(object): > > def __init__(self): > > ... > > > > Inheritance usually takes a class name to indicate which class is the > > 'parent' class. However, in the previous example, from a django book, > > the class actually takes an 'object' like parameter, doesn't it? What is > > the semantics meaning of such kind of notation? > > It's not merely notation, "object" is the name of a class. If you type it > (without quotes) at the interactive interpreter, you will see it is a > built-in class: > > py> object > > > > In Python 3, the use of object as base class is optional, but in Python 2 > there is a subtle difference between classes that inherit from object and > those that don't. The reason for this difference is buried in the mists > of time, going back to Python 2.2. If you are interested, google on > "Python unifying types and classes": > > https://duckduckgo.com/html/?q=Python+unifying+types+and+classes > > > As a general rule, unless you actually want "old-style class" behaviour, > you should always inherit from object (or some other built-in type) in > Python 2. In Python 3, it doesn't matter. > > The differences include: > > * property only works in "new-style" classes that inherit from object; > > * likewise for super; > > * multiple inheritance with old-style classes can be buggy; > > * new-style classes may be slightly faster in general; > > * on the down side, automatic delegation of special double-underscore > methods like __getitem__ and __str__ doesn't work with new-style classes. > > > If none of this means anything to you, be glad, and just inherit from > object or some other built-in type in all your classes, and all will be > good. > > > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
How to avoid PEP8 'imported but unused'
I am new to python. Now, I am woring on an application within Django
framework. When I checked my code with pep8 and pyflakes, some warning
messages show up-'Foobar imported but unused'. Obviously, it indicates
that some modules are imprted to current module but never get
references. However, it seems the message is wrong in this case:
# file: urls.py
urlpattens = patterns(
'',
url('^signup/$', 'signup')
}
# file: register.py
def signup(request):
return ...
# file: views.py
import signup from register
The warning message is shown in file views.py. It seems to me that the
code is okay because Django requires all functions serve as 'view' is
typically go into views.py. 'import' is about get 'signup' function
into module 'views.py'. Or, I am totally wrong? Is there a proper way
to avoid this warnning?
Best regards,
/Adam
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to avoid PEP8 'imported but unused'
Thanks. It works very well.
One more question. In this particular case it seems 'assert' should be
safe as a workaround, doesn't it? 'assert' will check if the symbol
is imported and not NULL. Is there side effect if I just applied this
rule as a generic one.
/Adam
On Sun, May 05, 2013 at 05:18:40PM +0100, Fábio Santos wrote:
> I usually do this on pyflakes:
>
> import whatever
> assert whatever # silence pyflakes
>
> Pyflakes and pep8 have no way of knowing django will import and use your
> module, or whether you are just importing a module for the side effects, so
> they issue a warning anyway. Assert'ing counts as using the module, so it
> counts as an used import.
>
> On 5 May 2013 17:05, "Adam Jiang" wrote:
> >
> > I am new to python. Now, I am woring on an application within Django
> > framework. When I checked my code with pep8 and pyflakes, some warning
> > messages show up-'Foobar imported but unused'. Obviously, it indicates
> > that some modules are imprted to current module but never get
> > references. However, it seems the message is wrong in this case:
> >
> > # file: urls.py
> > urlpattens = patterns(
> > '',
> > url('^signup/$', 'signup')
> > }
> >
> > # file: register.py
> > def signup(request):
> > return ...
> >
> > # file: views.py
> > import signup from register
> >
> > The warning message is shown in file views.py. It seems to me that the
> > code is okay because Django requires all functions serve as 'view' is
> > typically go into views.py. 'import' is about get 'signup' function
> > into module 'views.py'. Or, I am totally wrong? Is there a proper way
> > to avoid this warnning?
> >
> > Best regards,
> > /Adam
> > --
> > http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to avoid PEP8 'imported but unused'
Thank you. Problem solved. /Adam On Sun, May 05, 2013 at 06:27:44PM +0100, Fábio Santos wrote: > That assert will never fail. If the symbol is not imported, the import > statement raises ImportError. And actually "assert" makes sure that > the value is not false-ish, not None/Null. And AFAIK a module object > is *always* true. > > > One more question. In this particular case it seems 'assert' should be > > safe as a workaround, doesn't it? 'assert' will check if the symbol > > is imported and not NULL. Is there side effect if I just applied this > > rule as a generic one. > > > > -- > Fábio Santos -- http://mail.python.org/mailman/listinfo/python-list
