Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>: > I'm not sure if there will be any side affects to modifying > sys.executable though. Should this be the official way of supporting > embedded interpreters or should there be a > multiprocessing.setExecutable() method? +1 for setExecutable (I'd prefer set_executable, to be PEP 8 compliant). Make it explicit, rather than fiddling with stuff in sys manually. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
Steven D'Aprano schrieb: but also does it provide a very cool way to get custom sets or lists going with few extra work. Subclassing builtins was always very painful in the past "Always" very painful? class ListWithClear(list): def clear(self): self[:] = self.__class__() Not so very painful to me. Maybe I just have more pain-tolerance than some people. Sure, nobody said that adding another method is a problem. But overriding methods like __getitem__() and having them used in other methods that derive from it (like get()) is impossible without resorting to UserDict, which in turn doesn't inherit from dict. ABCs unify these possibilities. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
ISTM, the whole reason people are asking for a String ABC is so you can write isinstance(obj, String) and allow registered
string-like objects to be accepted.
The downside is that everytime you want this for a concrete class or type, it is necessary to write a whole new ABC listing all of
the required methods. Also, you have to change all of the client code's isinstance tests from concrete to abstract.
I propose a simpler approach. Provide an alternative registration function that overrides isinstance() so that objects can
explicitly fake any concrete type:
s = UserString('whiffleball')
print isinstance(s, str)--> False
register_lookalike(UserString, str)
print isinstance(s, str)--> True
Besides saving us from writing tons of new ABCs, the approach works with existing code that already uses isinstance() with concrete
types.
The ABCs that would remain are ones that are truly abstract, that define a generic interface (like mappings and sequences) and ones
that offer some useful mixin behavior. The remaining ABCs are ones where you have a fighting chance of actually being able to
implement the interface (unlike String where it would be darned tricky to fully emulate encode(), split(), etc.)
This would completely eliminate the need for numbers.Integral for example. AFAICT, its sole use case is to provide a way for
numeric's integral types (like int8, int32) to pass themselves off as having the same API as regular ints. Unfortunately, the
current approach requires all consumer code to switch from isinstance(x,int) to isinstance(x,Integral). It would be more useful if
we could simply write register_lookalike(x,int) and be done with it (no need for numbers.py and its attendant abc machinery).
If we don't do this, then String won't be the last request. People will want Datetime for example. Pretty much any concrete type
could have a look-a-like that wanted its own ABC and for all client code to switch from testing concrete types.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finishing up PEP 3108
Georg Brandl wrote:
Brett Cannon schrieb:
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then
again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Fred had the interesting suggestion of removing pydoc in Py3K based on
the thinking that documentation tools like pydoc should be external to
Python. With the docs now so easy to generate directly, should pydoc
perhaps just be gutted to only what is needed for help() to work?
pydoc is fine for displaying docstring help, and interactive help.
This should stay.
Of course, it would also be nice for ``help("if")`` to work effortlessly,
which it currently only does if the generated HTML documentation is
available somewhere, which it typically isn't -- on Unix most distributions
put it in a separate package (from which pydoc won't always find it
of its own), on Windows only the CHM file is distributed and must be
decompiled to get single HTML files.
Now that the docs are reST, the source is almost pretty enough to display
it raw, but I could also imagine a "text" writer that removes the more
obscure markup to present a casual-reader-friendly text version.
The needed sources could then be distributed with Python -- it shouldn't
be more than about 200 kb.
The versioned documentation will sometimes be available from the
Internet if you want to think about using that as a fallback source. It
*would* be nice if help("if") worked.
It would be even handier if help(if) worked, but that's a syntax
problem, and it would be a horrendous one to overcome, I suspect.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Finishing up PEP 3108
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Now that the docs are reST, the source is almost pretty enough to display > it raw, but I could also imagine a "text" writer that removes the more > obscure markup to present a casual-reader-friendly text version. > > The needed sources could then be distributed with Python -- it shouldn't > be more than about 200 kb. > +1 from me. Would this mean that htmllib and sgmllib could be removed without further ado. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
I'm willing to meet you halfway. I really don't want isinstance(x,
str) to return True for something that doesn't inherit from the
concrete str type; this is bound to lead to too much confusion and
breakage. But I'm fine with a String ABC (or any other ABC, e.g.
Atomic?) that doesn't define any methods but can be used for type
testing. How about that?
--Guido
On Sat, May 31, 2008 at 5:25 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> ISTM, the whole reason people are asking for a String ABC is so you can
> write isinstance(obj, String) and allow registered string-like objects to be
> accepted.
>
> The downside is that everytime you want this for a concrete class or type,
> it is necessary to write a whole new ABC listing all of the required
> methods. Also, you have to change all of the client code's isinstance tests
> from concrete to abstract.
>
> I propose a simpler approach. Provide an alternative registration function
> that overrides isinstance() so that objects can explicitly fake any concrete
> type:
>
> s = UserString('whiffleball')
> print isinstance(s, str)--> False
> register_lookalike(UserString, str)
> print isinstance(s, str)--> True
>
> Besides saving us from writing tons of new ABCs, the approach works with
> existing code that already uses isinstance() with concrete types.
>
> The ABCs that would remain are ones that are truly abstract, that define a
> generic interface (like mappings and sequences) and ones that offer some
> useful mixin behavior. The remaining ABCs are ones where you have a
> fighting chance of actually being able to implement the interface (unlike
> String where it would be darned tricky to fully emulate encode(), split(),
> etc.)
>
> This would completely eliminate the need for numbers.Integral for example.
> AFAICT, its sole use case is to provide a way for numeric's integral types
> (like int8, int32) to pass themselves off as having the same API as regular
> ints. Unfortunately, the current approach requires all consumer code to
> switch from isinstance(x,int) to isinstance(x,Integral). It would be more
> useful if we could simply write register_lookalike(x,int) and be done with
> it (no need for numbers.py and its attendant abc machinery).
>
> If we don't do this, then String won't be the last request. People will
> want Datetime for example. Pretty much any concrete type could have a
> look-a-like that wanted its own ABC and for all client code to switch from
> testing concrete types.
>
>
> Raymond
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
On 31/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote: > 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>: >> I'm not sure if there will be any side affects to modifying >> sys.executable though. Should this be the official way of supporting >> embedded interpreters or should there be a >> multiprocessing.setExecutable() method? > > +1 for setExecutable (I'd prefer set_executable, to be PEP 8 > compliant). Make it explicit, rather than fiddling with stuff in sys > manually. That is easy to do. An issue not mentioned in the PEP is naming conventions. In recent versions I have tried to consistently use mixedCase for functions and methods (other than factory functions) because that is what threading does (give or take settrace(), setprofile(), stack_size().) I am certainly open to using lowercase/lower_case_with_underscores for all functions/methods except for Process's methods and possibly currentProcess(), but I would like some feed back on that. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] optimization required: .format() i s much slower than %
Simon Cross gmail.com> writes:
> My tests show that the old-style % formatting is much faster when the
> final string is 20 characters or less:
>
> $ ./python -m timeit "'|||...%s' % '12'"
> 1000 loops, best of 3: 0.0764 usec per loop
You are the victim of a constant-folding optimization:
$ ./python -m timeit "'|||...%s' % '12'"
1000 loops, best of 3: 0.0926 usec per loop
$ ./python -m timeit -s "s='12'" "'|||...%s' % s"
100 loops, best of 3: 0.525 usec per loop
>>> def f(): return '|||...%s' % '12'
...
>>> dis.dis(f)
1 0 LOAD_CONST 3 ('|||...12')
3 RETURN_VALUE
cheers
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
Raymond Hettinger wrote: If we don't do this, then String won't be the last request. People will want Datetime for example. Pretty much any concrete type could have a look-a-like that wanted its own ABC and for all client code to switch from testing concrete types. If I remember rightly, the machinery in the ABC's to support registration slows down some other operations with the types - do we want to pay that price all the time? If we do, then it may be a matter of moving some of the registration machinery from ABCMeta up into type itself. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>: > > I'm not sure if there will be any side affects to modifying > > sys.executable though. Should this be the official way of supporting > > embedded interpreters or should there be a > > multiprocessing.setExecutable() method? > > +1 for setExecutable (I'd prefer set_executable, to be PEP 8 > compliant). Make it explicit, rather than fiddling with stuff in sys > manually. sys.executable typically means the "current" executable, and py2exe etc already fiddles with that. The question in such a context seems to be "what executable should I use for this processing functionality?". In a py2exe like environment, it might not be unreasonable to assume that if a custom executable is to be used, that custom executable may have a different command-line or other special requirements. Further, I could imagine a system that uses an alternative way of starting processes (eg, 'distributed COM') where the concept of 'executable' (or even 'command-line') don't make much sense. So it seems that maybe simply "setExecutable()" isn't the correct abstraction here, but maybe a "factory" approach, so the entire process creation mechanism can be replaced rather than just the name of the executable to spawn? Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
On Sat, May 31, 2008 at 6:41 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> >> I'm willing to meet you halfway. I really don't want isinstance(x, >> str) to return True for something that doesn't inherit from the >> concrete str type; this is bound to lead to too much confusion and >> breakage. > > Probably true. It was an attractive idea though. Unless all client > code converts all its isinstance() tests from concrete to abstract, > life is going to be tough for people writing look-alike classes > which will have limited applicability. I'd rather require that people rewrite their code to benefit from some new piece of functionality than foisting it upon them regardless, breaking some perfectly fine working in the process. This is how we've always done it. >> But I'm fine with a String ABC (or any other ABC, e.g. >> Atomic?) that doesn't define any methods but can be used for type >> testing. How about that? > > That's progress! It makes abstract substitution possible while > still saving us a lot of code and avoiding over-specification. > I propose the following empty abstract classes: String, Datetime, Deque, > and Socket. 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. > -1 on Atomic though. Earlier in the thread it was made clear that > that atomicity is not an intrinsic property of a type; instead it varies > across applications (when flattening email folders, a multi-part mime > message is atomic, but when flattening individual messages, a > multi-part mime message is just another nested container, part > of the tree, not one of the leaves). Fine, it was just an idle thought. > 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. Where did you see __long__? That seems a mistake (at least in 3.0). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
From: "Guido van Rossum" <[EMAIL PROTECTED]> I'm willing to meet you halfway. I really don't want isinstance(x, str) to return True for something that doesn't inherit from the concrete str type; this is bound to lead to too much confusion and breakage. Probably true. It was an attractive idea though. Unless all client code converts all its isinstance() tests from concrete to abstract, life is going to be tough for people writing look-alike classes which will have limited applicability. But I'm fine with a String ABC (or any other ABC, e.g. Atomic?) that doesn't define any methods but can be used for type testing. How about that? That's progress! It makes abstract substitution possible while still saving us a lot of code and avoiding over-specification. I propose the following empty abstract classes: String, Datetime, Deque, and Socket. -1 on Atomic though. Earlier in the thread it was made clear that that atomicity is not an intrinsic property of a type; instead it varies across applications (when flattening email folders, a multi-part mime message is atomic, but when flattening individual messages, a multi-part mime message is just another nested container, part of the tree, not one of the leaves). 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__. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
[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. Since the new classes are very lightweight (completely empty), these probably only need minimal justification. The case for String has already been made. And the concept of a Socket is already fully abstract. 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. 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. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)
On Sat, May 31, 2008 at 8:09 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API for gc.enable() and gc.disable()
On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > Would anyone mind if I did add a public C API for gc.disable() and > gc.enable()? I would like to use it as an optimization for the pickle > module (I found out that I get a good 2x speedup just by disabling the > GC while loading large pickles). Of course, I could simply import the > gc module and call the functions there, but that seems overkill to me. > I included the patch below for review. I'd rather see it fixed. It behaves quadratically if you load enough to trigger full collection a few times. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C API for gc.enable() and gc.disable()
Would anyone mind if I did add a public C API for gc.disable() and
gc.enable()? I would like to use it as an optimization for the pickle
module (I found out that I get a good 2x speedup just by disabling the
GC while loading large pickles). Of course, I could simply import the
gc module and call the functions there, but that seems overkill to me.
I included the patch below for review.
-- Alexandre
Index: Include/objimpl.h
===
--- Include/objimpl.h (revision 63766)
+++ Include/objimpl.h (working copy)
@@ -221,8 +221,10 @@
* ==
*/
-/* C equivalent of gc.collect(). */
+/* C equivalent of gc.collect(), gc.enable() and gc.disable(). */
PyAPI_FUNC(Py_ssize_t) PyGC_Collect(void);
+PyAPI_FUNC(void) PyGC_Enable(void);
+PyAPI_FUNC(void) PyGC_Disable(void);
/* Test if a type has a GC head */
#define PyType_IS_GC(t) PyType_HasFeature((t), Py_TPFLAGS_HAVE_GC)
Index: Modules/gcmodule.c
===
--- Modules/gcmodule.c (revision 63766)
+++ Modules/gcmodule.c (working copy)
@@ -1252,6 +1252,18 @@
return n;
}
+void
+PyGC_Disable(void)
+{
+enabled = 0;
+}
+
+void
+PyGC_Enable(void)
+{
+enabled = 1;
+}
+
/* for debugging */
void
_PyGC_Dump(PyGC_Head *g)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mini-Pep: Simplifying the Integral ABC
Target: Py2.6 and Py3.0 Author: Raymond Hettinger Date: May 31, 2008 Motivation -- The principal purpose of an abstract base class is to support multiple implementations of an API; thereby allowing one concrete class to be substitutable for another. This purpose is defeated when useful substitutions are precluded because the ABC is too aggressive in its behavioral requirements -- mandating too many methods, mandating methods that are difficult to implement, or too closely following the full API of a single concrete type. The Integral ABC is somewhat extensive and requires essentially every behavior exhibited by the int concrete class. Usefully, it provides for basic integer behaviors like simple arithmetic and ordering relations. However, the current ABC goes beyond that and requires bit-flipping and other operations that are not fundamental to the notion of being an integer. That makes it challenging to define a new Integral class that isn't already an int. Proposal Remove non-essential abstract methods like __index__, three argument __pow__, __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__, __xor__, __rxor__, __or__, __ror__, and __invert__, numerator, and denominator. Discussion -- The only known use cases for variants of int are types that limit the range of values to those that fit in a fixed storage width. One existing implementation is in numpy which has types like int0, int8, int16, int32, and int16. The numpy integral types implement all the methods present in Integral except for the new methods like __trunc__, __index__, real, imag, conjugate, numerator, and denominator. For the most part, they are fully substitutable into code that expects regular ints; however, they do have wrap-around behaviors such as int8(200)+int8(100) --> int8(44). The wrap-around behaviors make the numpy types totally unsuitable for some applications of Integral such as the fractions module which accepts any integral numerator and denominator. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mini-Pep: An Empty String ABC
Mini-Pep: An Empty String ABC Target: Py2.6 and Py3.0 Author: Raymond Hettinger Proposal Add a new collections ABC specified as: class String(Sequence): pass Motivation -- Having an ABC for strings allows string look-alike classes to declare themselves as sequences that contain text. Client code (such as a flatten operation or tree searching tool) may use that ABC to usefully differentiate strings from other sequences (i.e. containers vs containees). And in code that only relies on sequence behavior, isinstance(x,str) may be usefully replaced by isinstance(x,String) so that look-alikes can be substituted in calling code. A natural temptation is add other methods to the String ABC, but strings are a tough case. Beyond simple sequence manipulation, the string methods get very complex. An ABC that included those methods would make it tough to write a compliant class that could be registered as a String. The split(), rsplit(), partition(), and rpartition() methods are examples of methods that would be difficult to emulate correctly. Also, starting with Py3.0, strings are essentially abstract sequences of code points, meaning that an encode() method is essential to being able to usefully transform them back into concrete data. Unfortunately, the encode method is so complex that it cannot be readily emulated by an aspiring string look-alike. Besides complexity, another problem with the concrete str API is the extensive number of methods. If string look-alikes were required to emulate the likes of zfill(), ljust(), title(), translate(), join(), etc., it would significantly add to the burden of writing a class complying with the String ABC. The fundamental problem is that of balancing a client function's desire to rely on a broad number of behaviors against the difficulty of writing a compliant look-alike class. For other ABCs, the balance is more easily struck because the behaviors are fewer in number, because they are easier to implement correctly, and because some methods can be provided as mixins. For a String ABC, the balance should lean toward minimalism due to the large number of methods and how difficult it is to implement some of the correctly. A last reason to avoid expanding the String API is that almost none of the candidate methods characterize the notion of "stringiness". With something calling itself an integer, an __add__() method would be expected as it is fundamental to the notion of "integeriness". In contrast, methods like startswith() and title() are non-essential extras -- we would not discount something as being not stringlike if those methods were not present. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
