Re: [Python-Dev] Organization of ABC modules
-On [20080127 03:25], Terry Reedy ([EMAIL PROTECTED]) wrote: 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. 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... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
On Jan 27, 2008 12:29 AM, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] 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.) 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/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Guido van Rossum wrote: 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. 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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Raymond Hettinger wrote: 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. 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 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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Jeffrey Yasskin 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? 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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
On Jan 25, 2008 9:31 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Raymond Hettinger wrote: 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. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Raymond Hettinger wrote: 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. 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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Raymond Hettinger wrote: 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. 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/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
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. A prefix would be better. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
On Jan 25, 2008 3:15 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: All of the abstract base classes should be collected in one place. I propose that the modules be collected into a package so that we can write: import abc.numbers import abc.collections . . . Besides collecting all the relevant code in one place, it has a nice additional benefit of clearly designating when you're working with one of the provided abstract base classes. When I see import numbers, I don't immediately recognize this as being somehow different from import math or some other concrete implementation. IMO. the emerging practice of spreading modules these across the library isn't serving us well. I don't think so. Things should be grouped by application area, not by some property like uses metaclasses or defines abstract base classes or overrides operators. The old types module collected all built-in types and it was a mistake. You might as well propose that all decorators should live in the same package, or all generic functions (if we ever have them). There's a lot more synergy between the collection ABCs and other collections than between collection ABCs and number ABCs. Another angle: the io.py module also uses ABCs. Should it therefore be a subpackage of ABC? No way! If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, though personally I think we don't need that either -- the generic names like Sequence or Real are enough of a tip-off that these are type categories and not implementation types. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
