Re: [Python-Dev] removing the new and types modules
Sorry if this is a dumb question, but are there actually good reasons to remove "types"? IMHO the types module helps keeping code readable. For example "if type(obj) == FloatType" is just more readable than "if type(obj) == type(1.0)". Luckily Python does not distinguish float and double like other languages - otherwise it wouldn't be clear for the average programmer if 1.0 is a float or a double constant. Henning
On Nov 28, 2007 2:23 PM, <henning.vonbargen@arcor.de> wrote:
Sorry if this is a dumb question, but are there actually good reasons to remove "types"? IMHO the types module helps keeping code readable. For example "if type(obj) == FloatType" is just more readable than "if type(obj) == type(1.0)".
But you should really be writing:: if isinstance(obj, float) for most situations, and:: if type(obj) == float if you really *have* to check the exact type. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy
henning.vonbargen@arcor.de wrote:
Sorry if this is a dumb question, but are there actually good reasons to remove "types"? IMHO the types module helps keeping code readable. For example "if type(obj) == FloatType" is just more readable than "if type(obj) == type(1.0)".
if isinstance(obj, float) or if type(obj) is float I often use FunctionType though.So long as it moves rather than vanishes... Michael http://www.manning.com/foord
Luckily Python does not distinguish float and double like other languages - otherwise it wouldn't be clear for the average programmer if 1.0 is a float or a double constant.
Henning
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
henning.vonbargen@arcor.de wrote:
Sorry if this is a dumb question, but are there actually good reasons to remove "types"?
Mainly because it is an unrelated grab bag of types that could be put in more topical locations - what they're for is more interesting than the mere fact that they happen to be types. As it turns out, the cleanup for Py3k (removing the members which are merely aliases for existing names) has already cut it down to only a few types which are closely related to the interpreter core. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
"Nick Coghlan" <ncoghlan@gmail.com> wrote in message news:474E995B.5050503@gmail.com... | henning.vonbargen@arcor.de wrote: | > Sorry if this is a dumb question, but are there actually good reasons to remove "types"? | | Mainly because it is an unrelated grab bag of types that could be put in | more topical locations - what they're for is more interesting than the | mere fact that they happen to be types. An additional answer is that a number of changes in the 2.x series have have the types modules more or less obsolete. 1. It was once intended, I believe,to be a more or less complete catalog of types. As the number of internal implementation types have increased (and changed from release to release), this goal has become more difficult and less sensible. 2. The type-class unification that started in 2.2 unified several type objects with their corresponding (builtin) constructors (which became the __call__ methods of the type objects). This mades the type objects that most people are most interested in directly accessible as builtins. "type(o) == str" did not work when 'str' was a just conversion function rather than the string type object! tjr
participants (5)
-
henning.vonbargenīŧ arcor.de -
Michael Foord -
Nick Coghlan -
Steven Bethard -
Terry Reedy