CONSTRUCT - New/Old Style Classes, build-in/extension types

[Ilias Lazaridis]

Another topic [1] has raised the need of a deeper teach-in.

Where can I find _compact_ documentation about

* Differece between New Style / Old Style Classes

Are there any documents available (again: compact ones) which describe
unification attemps subjecting

* New Style Classes
* Old Style Classes
* Build In Types
* Extension Types

(note: I am aware about search engines. I ask for documentation which
other developers have found useful)

..

[1]
CONSTRUCT - Adding Functionality to the Overall System
http://groups.google.com/group/comp.lang.python/browse_thread/thread/4618ccef252c82cd

 

[Fredrik Lundh]

note: I am aware about search engines.

but you're incapable of using them, or ?

I ask for documentation which other developers have found useful

most recent Python books contains good discussions of the things you're
asking for. maybe you should buy a book ?

</F>

 

[Ben Finney]

Where can I find _compact_ documentation about

Can you tell us what is lacking about the documentation at
<URL:http://www.python.org/doc/> ? Specifically, what problems have
you found in understanding these topics from the documentation
available at that site?

 

[Ilias Lazaridis]

Can you tell us what is lacking about the documentation at
<URL:http://www.python.org/doc/> ? Specifically, what problems have
you found in understanding these topics from the documentation
available at that site?

Of course:

"
Unifying types and classes in Python 2.2

Python Version: 2.2.3

Guido van Rossum

This paper is an incomplete draft. I am soliciting feedback. If you find
any problems, please write me at (e-mail address removed).
"
http://www.python.org/download/releases/2.2.3/descrintro/

-

Weaknesses:

* draft version
* written by the system designer
* size
* code examples uncolored
* code examples missaligned

-

I've looking for a _compact_ analysis of this topic, prefered in
standard OO jargon. Around 100 lines and 1 diagramm (or 500 lines and 3
diagramms, but not more).

..

 

[Ilias Lazaridis]

but you're incapable of using them, or ?
-


most recent Python books contains good discussions of the things you're
asking for. maybe you should buy a book ?

I'm interested in online resources, experiences etc..

Maybe you can clarify some things (for me and for readers):

Do I need old style classes?

Does the python standard library use old style classes?

Have those old style classes any benefits?

..

 

[Steve Holden]

I'm interested in online resources, experiences etc..

Maybe you can clarify some things (for me and for readers):

Do I need old style classes?

No, not for new code.

Does the python standard library use old style classes?

Yes, because it was easier to leave them as they were than risk
introducing incompatibilities.

Have those old style classes any benefits?

..

No.

regards
Steve

 

[Paul Boddie]

Well, "Python new-style old-style classes" in Google gives a range of
discussions, but an old version of the definitive guide [1] is found
via one of the later results on the first page (which is some section
of the reference manual). According to that and the newer guide [2],
the official documentation still isn't updated, despite it having been
a good three years since new-style classes first arrived in a real
Python release.

Of course, the lengthening paper trail shouldn't be a surprise to you
or I, but with more "exciting" additions to the language in 2.5, it is
somewhat unnerving that the last major changes still sit partially
documented in "additional documentation" that a beginner wouldn't be
inclined to read through.

I'm interested in online resources, experiences etc..

And I don't see what's wrong with that.

Maybe you can clarify some things (for me and for readers):

Do I need old style classes?

No, but you can still use them. I use them a lot.

Does the python standard library use old style classes?

Yes, I'd imagine, since it would otherwise have needed someone to go
through the library and change everything, and I doubt that anyone is
that interested to do so.

Have those old style classes any benefits?

That you don't have to write the bizarre conceptual accident that is
"(object)" when declaring a "top-level" class?

Paul

[1] http://www.python.org/doc/newstyle.html
[2] http://www.python.org/doc/newstyle/

 

[Steve Holden]

Ilias Lazaridis wrote: [...]

Have those old style classes any benefits?

That you don't have to write the bizarre conceptual accident that is
"(object)" when declaring a "top-level" class?

Though of course the easiest way to enforce your classes to new style is
to begin each module with

__metaclass__ = type

regards
Steve

 

[Ilias Lazaridis]

Ilias Lazaridis wrote: [...]

Have those old style classes any benefits?

That you don't have to write the bizarre conceptual accident that is
"(object)" when declaring a "top-level" class?

Though of course the easiest way to enforce your classes to new style is
to begin each module with

__metaclass__ = type

I assume placing this in the central site import (e.g.
sitecustomize.py) would collapse python? (I don't want to try it, maybe
someone has an isolated instance available for trials).

 

[Ilias Lazaridis]

Ilias Lazaridis wrote:

.... (helpful comments)

That you don't have to write the bizarre conceptual accident that is
"(object)" when declaring a "top-level" class?

This was most possibly done for back-compatibility reasons.

Although introducing a change like this:

def MyOldClass(oldstyle)
def MyNewClass()

an giving lazy developers the search&replace patterns to migrate the
code would have been of benefit.

Possibly something for Python 2.6.

Paul

[1] http://www.python.org/doc/newstyle.html
[2] http://www.python.org/doc/newstyle/

this page points to nice documentation (which I would place in top of
the list!!!):

http://www.cafepy.com/article/python_types_and_objects/ch03.html#id833463

-

"Guido's essay on new-style classes and should be your starting point."

This article should _not_ be suggested as a starting point.

..

 

[Steve Holden]

Ilias Lazaridis wrote:
[...]

Have those old style classes any benefits?


That you don't have to write the bizarre conceptual accident that is
"(object)" when declaring a "top-level" class?

Though of course the easiest way to enforce your classes to new style is
to begin each module with

__metaclass__ = type

I assume placing this in the central site import (e.g.
sitecustomize.py) would collapse python? (I don't want to try it, maybe
someone has an isolated instance available for trials).

I don't think it would "collapse Python", but since each module requires
its own __metaclass__ setting it certainly wouldn't change much.

regards
Steve

 

[Ilias Lazaridis]

I don't think it would "collapse Python", but since each module requires
its own __metaclass__ setting it certainly wouldn't change much.

I understand.

Thus I cannot set "__metaclass__ = object" on e.g. project-level or
site-level, but only module-level.

..

 

[Aahz]

Have those old style classes any benefits?

Yes, if you want your code to run on Python 2.1 and earlier.