Re: [Python-Dev] Organization of ABC modules

2008-01-27 Thread Nick Coghlan
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

2008-01-27 Thread Guido van Rossum
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

2008-01-27 Thread Jeroen Ruigrok van der Werven
-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
イェルーン ラウフロック ヴァン デル ウェルヴェン
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

2008-01-26 Thread Terry Reedy

"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

2008-01-26 Thread Nick Coghlan
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

2008-01-25 Thread Raymond Hettinger
> 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

2008-01-25 Thread Nick Coghlan
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

2008-01-25 Thread Jeffrey Yasskin
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

2008-01-25 Thread Nick Coghlan
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

2008-01-25 Thread Steve Holden
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

2008-01-25 Thread Raymond Hettinger
> 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

2008-01-25 Thread Guido van Rossum
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