Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
From: "Ivan Evstegneev" <webmailgroups@gmail.com>
To: <python-list@python.org>
References: <mailman.16949.1418574125.18130.python-list@python.org> <2082416.uXDKvNnAXg@PointedEars.de> <548e40de$0$12997$c3e8da3$5496439d@news.astraweb.com>
In-Reply-To: <548e40de$0$12997$c3e8da3$5496439d@news.astraweb.com>
Subject: RE: Classes - converting external function to class's method.
Date: Mon, 15 Dec 2014 21:13:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGY2IeHm8OMhX5VXg/rz/h3wqwMJwNSX7+7AV+TsUmc2fGRkA==
Content-Language: en-us
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.16986.1418670889.18130.python-list@python.org>
Lines: 217
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:82565

Again Thanks for your help.

I saw that there was a debate about  "namespace" nature.


That is what a book says about it(Learning Python 5 Ed. By Mark Lutz):

*********************************************
"Classes and Instances

Although they are technically two separate object types in the Python =
model, the classes
and instances we put in these trees are almost identical=E2=80=94each =
type=E2=80=99s main purpose is
to serve as another kind of namespace=E2=80=94a package of variables, =
and a place where we
can attach attributes. If classes and instances therefore sound like =
modules, they should;
however, the objects in class trees also have automatically searched =
links to other
namespace objects, and classes correspond to statements, not entire =
files."

"Customization via inheritance
....More generally, classes can build up namespace hierarchies, which
define names to be used by objects created from classes in the =
hierarchy. This
supports multiple customizable behaviors more directly than other =
tools."

"...classes live in modules and are namespaces as well, but they add an =
extra component to attribute
lookup called inheritance search."


"In fact, classes have just three primary distinctions. At a base level, =
they are mostly just
namespaces, much like the modules we studied in Part V. Unlike modules, =
though,
classes also have support for generating multiple objects, for namespace =
inheritance,
and for operator overloading."
*************************************************************************=
***

I'm not pretending to be a "smartass" here, but as I can understand from =
the context:

Classes are namespaces, but they also have an additional capabilities.


BR,

Ivan






> -----Original Message-----
> From: Python-list [mailto:python-list-
> bounces+webmailgroups=3Dgmail.com@python.org] On Behalf Of Steven
> D'Aprano
> Sent: Monday, December 15, 2014 04:01
> To: python-list@python.org
> Subject: Re: Classes - converting external function to class's method.
>=20
> Thomas 'PointedEars' Lahn wrote:
>=20
> > Ivan Evstegneev wrote:
> >
> >> I have stuck a bit with this example(took this one from the book).
> >>
> >> Here are a description steps of what I've done till now:
> >>
> >>
> >> Step 1 - creating an empty namespace:
> >>
> >>>>>class rec: pass
> >
> > IMHO that is not actually creating a namespace; it is just
> > declaring/defining an empty class.
>=20
> And classes are namespaces. As are instances.
>=20
> One clue is the fact that we use exactly the same syntax for accessing =
names in a
> namespace regardless of whether the namespace is a package, a module, =
a class
> or an instance:
>=20
> import collections.abc  # a package namespace math.sin  # a module =
namespace
> OrderedDict.fromkeys  # a class namespace mystring.upper  # an =
instance
> namespace
>=20
> I call it a "clue" rather than definitive proof because the syntax is =
not quite the
> same for all namespaces. Local and global variables also exist in =
namespaces, but
> you don't use dotted notation for them.
>=20
> Another clue is that most of these are implemented by using a __dict__ =
to store
> the name:value mapping. Again, that's not universal: instances can =
optionally
> use __slots__ instead of __dict__ and packages use the file system.
>=20
> Apart from packages, one can use getattr(), setattr() and delattr() on =
all of these
> objects (modules, classes and instances) to manipulate their =
attributes.
>=20
> Wikipedia says:
>=20
> "In general, a namespace is a container for a set of identifiers (also =
known as
> symbols, names)."
>=20
> https://en.wikipedia.org/wiki/Namespace
>=20
> and that applies to packages, modules, classes, and instances.
>=20
> Last but not least, another clue: in some languages, such as Java, =
what Python
> calls "attributes" are known as *variables*. So per-instance members =
are called
> "instance variables", per-class members are sometimes called "class =
variables"
> (although not in Java, where I believe they are known as static =
variables for
> technical reasons). Personally, I don't like that terminology, but I =
do recognise
> that it does reflect a certain connection between names in
> local/global/instance/class namespaces.
>=20
>=20
> > BTW, the recommended Python 3.x way is
> >
> > class Rec (object):
> >     pass
>=20
>=20
> I think you mean Python 2 rather than 3. In Python 2, we have legacy =
"old style"
> or "classic" classes, and "new style" classes which inherit from =
object. In Python
> 3, classic classes are gone, and inheriting from object is optional.
>=20
>=20
> > (whereas =E2=80=9Cpass=E2=80=9D is a placeholder statement, a bit =
like the yada-yada
> > operator of Python) and you should start class identifiers uppercase
> > (therefore, =E2=80=9CRec=E2=80=9D instead) in order to avoid name =
collisions with
> > built-in class identifiers (=E2=80=9Cstr=E2=80=9D, =
=E2=80=9Cint=E2=80=9D etc.) and make it easier to
> > tell apart instantiations from function/method calls.
>=20
> Agreed!
>=20
> It is good practice to name classes with initial capital letter, and =
instances in all
> lowercase.
>=20
>=20
> > If you call that method as the method of a class (object), you need =
to
> > pass an argument for the first parameter because you have made it
> > positional, not optional (it has no default value).  If you pass (a
> > reference to) the class as first argument of that method, the class =
is
> > the object whose attribute is accessed.  Classes are objects (this,
> > too, was probably derived from Java). (In fact, AFAIK almost
> > everything is an object in Python; there are no primitive data types
> > at all.)
>=20
> You are correct that "everything is an object" in Python, but wrong =
that this is
> derived from Java. As I understand it, Java classes are not values:
> you cannot assign a class to a variable, or create classes on the fly, =
or delete
> them, or stick them in lists, etc.
>=20
> Well, I say that you can't do it, but you actually can, using =
reflection and other
> tricks. But the important thing is that you need to use special =
techniques to work
> around the fact that classes aren't values and therefore not =
implemented as
> objects in Java. What is natural in Python is unnatural in Java.
>=20
> =
http://stackoverflow.com/questions/2320404/creating-classes-dynamically-
> with-java
>=20
>=20
> [...]
> > If you intend the function to be called as the method of an =
instance,
> > you would be well-advised to name the parameter =
=E2=80=9Cself=E2=80=9D, as recommended.
> > (Which is probably derived from Smalltalk-80 and Self, some of the
> > first
> > OOPLs.)
>=20
> Good advice.
>=20
>=20
> --
> Steven
>=20
> --
> https://mail.python.org/mailman/listinfo/python-list