Re: [Python-Dev] Organization of ABC modules
If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention,
Essentially, that's all I was asking for. It doesn't really matter to me whether numbers.py gets called abc_numbers or abc.numbers. Either one would be an improvement. Raymond
Raymond Hettinger wrote:
abstract_numbers would seem to express the essence without focusing on the mechanism unduly. Of course no sane person would suggest using a keyword, like import abstract numbers Wouldn't want to let reader know what was going on ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
Raymond Hettinger wrote:
I think the module level is the wrong granularity to be thinking about this - look at a module like collections, which contains not only ABC's related to containers, but also some useful concrete containers like deque and namedtuple. Any naming convention would have to be at the class level. For example: class NumberABC(metaclass=ABCMeta): ... class ComplexABC(NumberABC): ... class RealABC(ComplexABC): ... class RationalABC(NumberABC): ... class IntegralABC(RationalABC): ... I think adopting such a convention (at least for the standard library) would actually be useful. Normally, finding isinstance() type checks in code bothers me severely as it usually indicates that duck-typing has been broken. On the other hand, if I find a check in code that does something like: if not isinstance(x, NumberABC): raise TypeError("Not a number!") it would clearly still be extensible, as I would know just from the naming convention that a third party can register their type with NumberABC to make it usable with this function. Without a naming convention, I would always have to go check the definition of the type in the isinstance() call to see if the code was legitimate. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Jan 25, 2008 9:31 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That's a good point. Someone already convinced me to name the test for numbers.py, test_abstract_numbers.py, so renaming the module makes sense too, although I agree that collections, which contains some concrete classes, should keep its current name. If others agree, want to send a patch? -- Namasté, Jeffrey Yasskin
Jeffrey Yasskin wrote:
I'm not so worried about the name of the numbers module, but if Guido likes the idea of a standard naming convention (such as the ABC suffix) for classes that use the ABCMeta metaclass, I'd certainly be happy to go through and update the affected classes and the code which refers to them. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Raymond Hettinger wrote:
I initially thought that, but found the suffix to be the least annoying of the ideas I had for denoting abstract base classes. To try and give some idea of how I came to that conclusion I've listed some of the other ideas I had below (again using the numeric stack as an example). INumber IComplex IReal IRational IIntegral Using a simple 'I' prefix annoys me for cases like the last one where the class name actually starts with an I, and 'interface' is a bit of a misnomer for abstract base classes anyway - they have a lot in common, but they're not the same thing. This is also an existing convention for things like zope.interface, so probably not a good idea to adopt to mean something else. ABCNumber ABCComplex ABCReal ABCRational ABCIntegral I find using the ABC acronym as a prefix ends up with too many capitals together at the start of the word and it becomes far more obtrusive than it needs to be. The main thing about these classes is what they represent - the fact that they're ABC's, while still significant enough to indicate somewhere in the name, should be of secondary importance. AbcNumber AbcComplex AbcReal AbcRational AbcIntegral This one bugs me mainly because I don't like lowercasing letters in acronyms just to try and fit in with a camel-casing scheme. It's just ugly. After those 3, I couldn't think of any other prefixes that were both short and likely to be an effective mnemonic for identifying ABC's - Abstract is too long, Abs is far too easy to associated with 'absolute' instead of "Abstract base class", etc. Which lead me to the idea I actually used in my earlier post: NumberABC ComplexABC RealABC RationalABC IntegralABC That way the normal class names are still front and centre, with a short annotation tacked on to the end to say "oh, by the way, this happens to be an abstract base class". I'm not sure any more discussion will be particularly useful though - any convention that gets adopted is going to be by Guido's fiat and will need to suit his aesthetic sense rather than mine :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
"Nick Coghlan" <ncoghlan@gmail.com> wrote in message news:479B4B52.1060301@gmail.com... | Raymond Hettinger wrote: | > A prefix would be better. | | I initially thought that, but found the suffix to be the least annoying | of the ideas I had for denoting abstract base classes. To try and give || INumber || ABCNumber | AbcNumber | [etc] | After those 3, I couldn't think of any other prefixes that were both | short and likely to be an effective mnemonic for identifying ABC's - | instead of "Abstract base class", etc. ... | NumberABC I *think* I would prefer to any of these either ANumber or aNumber, which one can read as either an abbreviation of Abstract Number or simply a contraction of 'a Number' (a Real, an Integral, etc) taken to mean the abstraction. | any convention that gets adopted is going to be by Guido's fiat and will | need to suit his aesthetic sense rather than mine :) One more possibility for him to consider. tjr
-On [20080127 03:25], Terry Reedy (tjreedy@udel.edu) wrote:
This will be a bikeshed argument until Guido speaks out his preference/decision I guess. But isn't it a more common solution to name the base class just Number and derive from it by means of using Base.Number or something similar? Looks cleaner to me rather than all these odd looking pre- or suffixes. (I am not charmed about ABC in the name at all to be honest, doesn't really give me a Python feeling.) -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours...
On Jan 27, 2008 12:29 AM, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:
My preference is still *not* to use a naming convention. I just suggested it as a lesser evil compared to segregating all abstract base classes in an "abc" package ghetto. I really don't see why names like "Number" or "MutableSequence" would need any additional help to make the reader see they are abstract. I note that at least for built-in types there will be the naming convention that concrete implementation classes are all lowercase, like int, float, list, namedtuple, defaultdict, and so on, while the ABCs all have a Capitalized[Words] name: Hashable, Number, Real, MutableMapping, etc. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
That's a very good point. I also suspect that for any actual 2.6/3.0 code base I end up working with there will only be a very limited number of abstract base classes that get tested for via isinstance - so the red flag for isinstance checks would be types I didn't already recognise as being abstract base classes. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Raymond Hettinger wrote:
abstract_numbers would seem to express the essence without focusing on the mechanism unduly. Of course no sane person would suggest using a keyword, like import abstract numbers Wouldn't want to let reader know what was going on ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
Raymond Hettinger wrote:
I think the module level is the wrong granularity to be thinking about this - look at a module like collections, which contains not only ABC's related to containers, but also some useful concrete containers like deque and namedtuple. Any naming convention would have to be at the class level. For example: class NumberABC(metaclass=ABCMeta): ... class ComplexABC(NumberABC): ... class RealABC(ComplexABC): ... class RationalABC(NumberABC): ... class IntegralABC(RationalABC): ... I think adopting such a convention (at least for the standard library) would actually be useful. Normally, finding isinstance() type checks in code bothers me severely as it usually indicates that duck-typing has been broken. On the other hand, if I find a check in code that does something like: if not isinstance(x, NumberABC): raise TypeError("Not a number!") it would clearly still be extensible, as I would know just from the naming convention that a third party can register their type with NumberABC to make it usable with this function. Without a naming convention, I would always have to go check the definition of the type in the isinstance() call to see if the code was legitimate. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Jan 25, 2008 9:31 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That's a good point. Someone already convinced me to name the test for numbers.py, test_abstract_numbers.py, so renaming the module makes sense too, although I agree that collections, which contains some concrete classes, should keep its current name. If others agree, want to send a patch? -- Namasté, Jeffrey Yasskin
Jeffrey Yasskin wrote:
I'm not so worried about the name of the numbers module, but if Guido likes the idea of a standard naming convention (such as the ABC suffix) for classes that use the ABCMeta metaclass, I'd certainly be happy to go through and update the affected classes and the code which refers to them. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Raymond Hettinger wrote:
I initially thought that, but found the suffix to be the least annoying of the ideas I had for denoting abstract base classes. To try and give some idea of how I came to that conclusion I've listed some of the other ideas I had below (again using the numeric stack as an example). INumber IComplex IReal IRational IIntegral Using a simple 'I' prefix annoys me for cases like the last one where the class name actually starts with an I, and 'interface' is a bit of a misnomer for abstract base classes anyway - they have a lot in common, but they're not the same thing. This is also an existing convention for things like zope.interface, so probably not a good idea to adopt to mean something else. ABCNumber ABCComplex ABCReal ABCRational ABCIntegral I find using the ABC acronym as a prefix ends up with too many capitals together at the start of the word and it becomes far more obtrusive than it needs to be. The main thing about these classes is what they represent - the fact that they're ABC's, while still significant enough to indicate somewhere in the name, should be of secondary importance. AbcNumber AbcComplex AbcReal AbcRational AbcIntegral This one bugs me mainly because I don't like lowercasing letters in acronyms just to try and fit in with a camel-casing scheme. It's just ugly. After those 3, I couldn't think of any other prefixes that were both short and likely to be an effective mnemonic for identifying ABC's - Abstract is too long, Abs is far too easy to associated with 'absolute' instead of "Abstract base class", etc. Which lead me to the idea I actually used in my earlier post: NumberABC ComplexABC RealABC RationalABC IntegralABC That way the normal class names are still front and centre, with a short annotation tacked on to the end to say "oh, by the way, this happens to be an abstract base class". I'm not sure any more discussion will be particularly useful though - any convention that gets adopted is going to be by Guido's fiat and will need to suit his aesthetic sense rather than mine :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
"Nick Coghlan" <ncoghlan@gmail.com> wrote in message news:479B4B52.1060301@gmail.com... | Raymond Hettinger wrote: | > A prefix would be better. | | I initially thought that, but found the suffix to be the least annoying | of the ideas I had for denoting abstract base classes. To try and give || INumber || ABCNumber | AbcNumber | [etc] | After those 3, I couldn't think of any other prefixes that were both | short and likely to be an effective mnemonic for identifying ABC's - | instead of "Abstract base class", etc. ... | NumberABC I *think* I would prefer to any of these either ANumber or aNumber, which one can read as either an abbreviation of Abstract Number or simply a contraction of 'a Number' (a Real, an Integral, etc) taken to mean the abstraction. | any convention that gets adopted is going to be by Guido's fiat and will | need to suit his aesthetic sense rather than mine :) One more possibility for him to consider. tjr
-On [20080127 03:25], Terry Reedy (tjreedy@udel.edu) wrote:
This will be a bikeshed argument until Guido speaks out his preference/decision I guess. But isn't it a more common solution to name the base class just Number and derive from it by means of using Base.Number or something similar? Looks cleaner to me rather than all these odd looking pre- or suffixes. (I am not charmed about ABC in the name at all to be honest, doesn't really give me a Python feeling.) -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours...
On Jan 27, 2008 12:29 AM, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:
My preference is still *not* to use a naming convention. I just suggested it as a lesser evil compared to segregating all abstract base classes in an "abc" package ghetto. I really don't see why names like "Number" or "MutableSequence" would need any additional help to make the reader see they are abstract. I note that at least for built-in types there will be the naming convention that concrete implementation classes are all lowercase, like int, float, list, namedtuple, defaultdict, and so on, while the ABCs all have a Capitalized[Words] name: Hashable, Number, Real, MutableMapping, etc. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
That's a very good point. I also suspect that for any actual 2.6/3.0 code base I end up working with there will only be a very limited number of abstract base classes that get tested for via isinstance - so the red flag for isinstance checks would be types I didn't already recognise as being abstract base classes. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
participants (7)
-
Guido van Rossum -
Jeffrey Yasskin -
Jeroen Ruigrok van der Werven -
Nick Coghlan -
Raymond Hettinger -
Steve Holden -
Terry Reedy