[EMAIL PROTECTED] wrote: > Simon Forman: > > It's unlikely to > > be deprecated since it doesn't make much sense to make it an attribute > > of the str type. > > Why? > > Thank you, > bearophile
Let me toss the question back at you: Does it make sense to you that str should have this attribute? Why? I'm not advocating for or against one thing or another, and I'm certainly not in a position to influence the future development of Python (anymore than any of us, that is :-) ) but FWIW, here's my $0.02: My "feeling" is that since str is a Type, and not a data store, it doesn't make much sense to me to tack on a bunch of read-only data attributes that aren't involved in it's role as a string data type just to have a slightly more convenient way of accessing them. There are twelve "constants" defined in the string module. If they were all attributes of the str type it would, for me, conceptually "clutter up" my mental model of str, string, and python itself. I like "from string import digits" well enough, and, as a test of my mental model, I just used IDLE's "open module" command to find and open string.py and discovered: # Some strings for ctype-style character classification whitespace = ' \t\n\r\v\f' lowercase = 'abcdefghijklmnopqrstuvwxyz' uppercase = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' letters = lowercase + uppercase ascii_lowercase = lowercase ascii_uppercase = uppercase ascii_letters = ascii_lowercase + ascii_uppercase digits = '0123456789' hexdigits = digits + 'abcdef' + 'ABCDEF' octdigits = '01234567' punctuation = """!"#$%&'()*+,-./:;<=>[EMAIL PROTECTED]|}~""" printable = digits + letters + punctuation + whitespace Exactly what I expected to find! Really, I wouldn't be too badly shocked to discover the above string "constants" in dir(str), so it's kind of "six of one, a half dozen of the other". But on the same token, "if it's not broken, don't fix it." Further, to make these "constants" into attributes of str, someone would have to modify the str type at the C level to put these strings "on" it. Since they are str's themselves, it seems to me (having done only trivial work with the C API of python) that that someone would have to A) create a "first" str type, B) create these 12 strings using that first type, C) attach them to the str type to create a "final" str type. And all this would have to be done at startup, I think, even if my code didn't use these attributes. It seems messy to me. So to sum up, IMO, a module (rather than a type) is a good place for these things, a module with some variable assignments is completely within my mental model of python (i.e. no special case (of strings being attributes of their own type (!?))), and no one has to do anything special to make the current set up work. By the way, I read your post a few days ago concerning adding similar data attributes to ints and floats and found it very interesting but not compelling. While I would love to have the kind information you mentioned available, I've never needed it in practice (I've only ever used sys.maxint maybe a dozen times) and I wouldn't mind accessing it from a module (perhaps math.. math.infinity, math.epsilon, etc., just like math.pi and math.e.) I look forward to hearing your thoughts an the subject. I hope mine haven't been too silly.. :-) Regards, ~Simon -- http://mail.python.org/mailman/listinfo/python-list
