Coding conventions for class names

[Kay Schluehr]

set, int, float, list, object,...

Don't see any of the basic types following the capitalized word
convention for classes covered by PEP 08. This does not hold only for
__builtins__ in the strict sense but also for types defined in builtin
modules like datetime.

My question is: does anyone actually follow guidelines here and if yes
which ones and are they resonable ( e.g. stable with regard to
refactoring etc. )?

 

[Marc 'BlackJack' Rintsch]

set, int, float, list, object,...

Don't see any of the basic types following the capitalized word
convention for classes covered by PEP 08. This does not hold only for
__builtins__ in the strict sense but also for types defined in builtin
modules like datetime.

Most built-ins are easy to explain: They were functions long before it
was possible to use them as base classes and stayed lowercase for
backwards compatibility. Don't know about `set` and `object`. I guess
it's foolish consistency!?

My question is: does anyone actually follow guidelines here and if yes
which ones and are they resonable ( e.g. stable with regard to
refactoring etc. )?

I follow PEP 8 in my (mostly unpublished) code if that does matter to you.

Ciao,
Marc 'BlackJack' Rintsch

 

[Michael Hoffman]

My question is: does anyone actually follow guidelines here
Yes.

and if yes
which ones and are they resonable ( e.g. stable with regard to
refactoring etc. )?

All of them that I know of. What does it mean to be "stable with regard
to refactoring etc."?

 

[Michael Hoffman]

Most built-ins are easy to explain: They were functions long before it
was possible to use them as base classes and stayed lowercase for
backwards compatibility. Don't know about `set` and `object`. I guess
it's foolish consistency!?

Well originally there was sets.Set (uppercase). It became set when it
went to being a built-in.

 

[Kay Schluehr]

All of them that I know of. What does it mean to be "stable with regard
to refactoring etc."?

What happens when an enthusiast re-implements a stdlib module e.g.
decimal s.t. it becomes a builtin module? Will the stdlib module serve
as a wrapper to conform the current API or will the builtin module
conform to the current interface. BTW the distinction between builtins
and non-builtins seems to be an artifact of the particular runtime
implementation. Application level / interpreter level becomes pretty
fluent with regard to PyPy for example. Not sure about these
distinctions in Jython and IronPython. Note that I do like all these
lower case builtin classes, so it is not about my personal taste, but
making coding conventions depended on how something is right now
implemented seems to miss the point.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

set, int, float, list, object,...

Don't see any of the basic types following the capitalized word
convention for classes covered by PEP 08.

These aren't classes, they are types. PEP 8 doesn't specify any
convention for types; it is common to either apply the conventions
for functions to them, or the conventions for classes.

Regards,
Martin

 

[Michael Hoffman]

What happens when an enthusiast re-implements a stdlib module e.g.
decimal s.t. it becomes a builtin module? Will the stdlib module serve
as a wrapper to conform the current API or will the builtin module
conform to the current interface.

Well, the best example is probably the transition from sets.Set to
__builtin__.set. The API changed but only slightly. So far sets.Set
retains the old implementation--it is not a wrapper for __builtin__.set.

Future modules may be implemented differently.