[Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC) (original) (raw)
Guido van Rossum guido at python.org
Sun Jun 1 05:46:15 CEST 2008
- Previous message: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
- Next message: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, May 31, 2008 at 8:09 PM, Raymond Hettinger <python at rcn.com> wrote:
[Raymond]
I propose the following empty abstract classes: String, Datetime, Deque, and Socket. [GvR] Sounds like a mini-PEP is in place. It should focus on the code to actually define these and the intended ways to use them. Okay, will run a Google code search to see if real code exists that runs isinstance tests on the concrete types.
I wasn't asking for existing code -- I was asking for the code you propose to add to abc.py (or wherever).
Since the new classes are very lightweight (completely empty), these probably only need minimal justification.
Again, in a mini-PEP I'm not so much looking for justification but for a precise spec.
The case for String has already been made.
Actually I'm not sure. One you know that isinstance(x, String) is true, what can you assume you can do with x?
And the concept of a Socket is already fully abstract.
Can you elaborate? There's a very specific API that is assumed of sockets. The code that creates sockets is usually pretty close to the code that consumes it. There are some major classes that cut right through the APIs though: connection or listening (the latter being something on which you call accept()), stream or datagram, and as a special case of stream SSL and the like.
Not sure I really care about Deque. The Datetime.class is tricky. The existence of many implementations of date/time routines indicates that there is a need; however, they don't share the API so they likely won't fit under a common umbrella.
Right. I'm now beginning to wonder what exactly you're after here -- saying that something is an "X" without saying anything about an API isn't very useful. You need to have at least some API to be able to do anything with that knowledge.
Are you open to considering numbers.Integral to be one of the new empty abstract classes? That would make it much easier for objects wanting to pass themselves as integers. As it stands now, an aspiring Integral class is required to implement a number of arcana including: rxor, rrshift, pow, invert, index, and long.
I don't think Integer should be completely abstract (what good is an int you can't add 1 to?) but I could be amenable to reducing the set of required operations (which could then resurface as a separate ABC). Please write another mini-PEP. Okay. Will propose to remove the bit flipping methods and anything else that doesn't seem essential to integeriness. Will take a look at the integral types in numeric to see what that actually implement.
Where did you see long? That seems a mistake (at least in 3.0). It's the first listed abstract method in the Py2.6 code.
That actually makes sense -- correct interoperability with longs probably requires that.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
- Next message: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]