Re: [Python-checkins] CVS: python/dist/src/Mac/scripts gensuitemodule.py,1.18,1.19
The keyword module has an undocumented data object kwlist which is a list of keywords. Perhaps this should be documented and made part of the public API? I'd want to change the list to a tuple, but that seems harmless since it isn't already part of the API.
Why make it a tuple? Out of fear someone changes it? Let them change it, and learn about sharing of object references! Agree it should be documented of course. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
Why make it a tuple? Out of fear someone changes it? Let them change it, and learn about sharing of object references!
Partly, and partly because it's something that should be changed anyway. Do you seriously object to changing it to a tuple???
Agree it should be documented of course.
OK. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
Do you seriously object to changing it to a tuple???
Yes, I don't want to create any more show code examples that use tuples for (conceptually) arbitrary-length arrays of homogeneous data. The data type to use for those is lists. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Fred:
Do you seriously object to changing it to a tuple???
Yes, I don't want to create any more show code examples that use tuples for (conceptually) arbitrary-length arrays of homogeneous data. The data type to use for those is lists.
Hrm. Even when it's something that's supposed to be immutable? I'm asking because I'm currently using a tuple for the digit list in my BCD module, and I'd like a clearer explanation of why you think that it should be a list (assuming you do).
Hrm. Even when it's something that's supposed to be immutable? I'm asking because I'm currently using a tuple for the digit list in my BCD module, and I'd like a clearer explanation of why you think that it should be a list (assuming you do).
From my viewpoint, the BCD digit string should be handled like a string; I'm only using a tuple for efficiency of storing numbers instead of characters.
Can't you trust your users not to change it? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Aahz:
Hrm. Even when it's something that's supposed to be immutable? I'm asking because I'm currently using a tuple for the digit list in my BCD module, and I'd like a clearer explanation of why you think that it should be a list (assuming you do).
From my viewpoint, the BCD digit string should be handled like a string; I'm only using a tuple for efficiency of storing numbers instead of characters.
Can't you trust your users not to change it?
Sure, but then I can't just copy references to the tuple when creating a copy of an instance, I'd have to copy the entire list. That's what I meant by efficiency. There are important semantic differences coming from the fact that tuples are immutable and lists are mutable, and I think that a strict heterogeneous/homogenous distinction loses that. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Sure, but then I can't just copy references to the tuple when creating a copy of an instance, I'd have to copy the entire list. That's what I meant by efficiency. There are important semantic differences coming from the fact that tuples are immutable and lists are mutable, and I think that a strict heterogeneous/homogenous distinction loses that.
Well, as long as you promise not to change it, you *can* copy a reference, right? I guess I don't understand your application enough -- do you intend this to be a starting point that is modified during the program's execution, or is this a constant array? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Aahz:
Sure, but then I can't just copy references to the tuple when creating a copy of an instance, I'd have to copy the entire list. That's what I meant by efficiency. There are important semantic differences coming from the fact that tuples are immutable and lists are mutable, and I think that a strict heterogeneous/homogenous distinction loses that.
Well, as long as you promise not to change it, you *can* copy a reference, right? I guess I don't understand your application enough -- do you intend this to be a starting point that is modified during the program's execution, or is this a constant array?
It's a constant. The BCD module is Binary Coded Decimal; instances are intended to be as immutable as strings and numbers (well, it *is* a number type). Modifying an instance is guaranteed to produce a new instance. To a large extent, I guess I feel that if a class is intended to be immutable, each of its underlying data attributes should also be immutable. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
It's a constant. The BCD module is Binary Coded Decimal; instances are intended to be as immutable as strings and numbers (well, it *is* a number type). Modifying an instance is guaranteed to produce a new instance. To a large extent, I guess I feel that if a class is intended to be immutable, each of its underlying data attributes should also be immutable.
Or you could assign it to a private variable. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Aahz:
It's a constant. The BCD module is Binary Coded Decimal; instances are intended to be as immutable as strings and numbers (well, it *is* a number type). Modifying an instance is guaranteed to produce a new instance. To a large extent, I guess I feel that if a class is intended to be immutable, each of its underlying data attributes should also be immutable.
Or you could assign it to a private variable.
And in private e-mail, Guido writes:
I hate to continue harping on this tiny item in public, but what woud you do if you needed a constant dictionary?
<grin> <throw up hands> All right, I guess it's time for me to just follow the Python motto: "There's only one way, and that way is Guido's." -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
[Guido]
I hate to continue harping on this tiny item in public, but what woud you do if you needed a constant dictionary?
[Aahz]
<grin> <throw up hands> All right, I guess it's time for me to just follow the Python motto: "There's only one way, and that way is Guido's."
Well, the other one way is to agitate for, e.g., accepting the new digraphs {? ?} as delimiting a constant dict <wink>. If I were Aahz, I'd keep using tuples: a serious BCD user can have gazillions of these objects sitting around, and tuples also allow significant memory savings over lists. If you have to, think of the digits '3' and '7' of being different types, so that you can fool Guido into believing it's not a homogeneous collection (he doesn't read the fine print in math-related code <wink>). practicality-beats-purity-ly y'rs - tim
Hey, should I change all the tuples in code objects to be lists, too? A code object has got things like co_names and co_consts. They're currently implemented as tuples, but they're just homogenous, variable-length sequences. <wink> 'course if people modified the lists, they'd caused Python to dump core. Jeremy
I haven't really followed this thread, but what's all this talk about lists vs. tuples about ? Tuples have a smaller memory footprint, provide faster element access, can be cached and are generally a good data type for constant data structures. Lists, OTOH, provide more flexibility when the size of the object isn't known in advance. They use up more memory, are not cacheable and slower on access. For the BCD stuff Aahz was talking about, I'd suggest to have a look at either arrays or cStringIO buffers. Jeremy Hylton wrote:
Hey, should I change all the tuples in code objects to be lists, too? A code object has got things like co_names and co_consts. They're currently implemented as tuples, but they're just homogenous, variable-length sequences. <wink>
'course if people modified the lists, they'd caused Python to dump core.
I hope I read the <wink> correctly :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
For the BCD stuff Aahz was talking about, I'd suggest to have a look at either arrays or cStringIO buffers.
cStringIO wouldn't work because I want to store ints. Arrays might work, but I think I'll stick with tuples because they're a bit more familiar to most Pythonistas. I'm not too concerned with raw speed and efficiency before I convert the code to C; remember Knuth. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Aahz Maruch wrote:
M.-A. Lemburg wrote:
For the BCD stuff Aahz was talking about, I'd suggest to have a look at either arrays or cStringIO buffers.
cStringIO wouldn't work because I want to store ints.
I was thinking of storing integers as chr(value) in these.
Arrays might work, but I think I'll stick with tuples because they're a bit more familiar to most Pythonistas. I'm not too concerned with raw speed and efficiency before I convert the code to C; remember Knuth.
If you plan to convert this to C, why not have a look at mxNumber first ? It's a wrapper around GMP and provides high performance implementations for many numeric operations, e.g. it should be easy to create a BCD type using the GMP (arbitrary length) longs and an additional C long for the decimal point position. In fact, there's a GMP extension MPFR which tries to do just this. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Aahz Maruch wrote:
M.-A. Lemburg wrote:
For the BCD stuff Aahz was talking about, I'd suggest to have a look at either arrays or cStringIO buffers.
cStringIO wouldn't work because I want to store ints.
I was thinking of storing integers as chr(value) in these.
Why spend the conversion time?
Arrays might work, but I think I'll stick with tuples because they're a bit more familiar to most Pythonistas. I'm not too concerned with raw speed and efficiency before I convert the code to C; remember Knuth.
If you plan to convert this to C, why not have a look at mxNumber first ? It's a wrapper around GMP and provides high performance implementations for many numeric operations, e.g. it should be easy to create a BCD type using the GMP (arbitrary length) longs and an additional C long for the decimal point position. In fact, there's a GMP extension MPFR which tries to do just this.
I'm specifically implementing the ANSI BCD spec. If you want to argue the theory of this, poke the Timbot; I think it's simpler to ensure that I'm following the spec if I implement everything by hand. Once I really understand what I'm doing, *then* it's time to optimize. Note that one reason for using BCD over GMP longs (which are presumably similar to Python longs) is speed of I/O conversion. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Aahz Maruch wrote:
Arrays might work, but I think I'll stick with tuples because they're a bit more familiar to most Pythonistas. I'm not too concerned with raw speed and efficiency before I convert the code to C; remember Knuth.
If you plan to convert this to C, why not have a look at mxNumber first ? It's a wrapper around GMP and provides high performance implementations for many numeric operations, e.g. it should be easy to create a BCD type using the GMP (arbitrary length) longs and an additional C long for the decimal point position. In fact, there's a GMP extension MPFR which tries to do just this.
I'm specifically implementing the ANSI BCD spec. If you want to argue the theory of this, poke the Timbot; I think it's simpler to ensure that I'm following the spec if I implement everything by hand. Once I really understand what I'm doing, *then* it's time to optimize.
Just thought you might want to take a look at what other people have done in this area. MPFR is specifically aimed at dealing with the problems of rounding; MPFI which implements interval arithmetics based on MPFR takes a slightly different approach: rounding issues are handled using intervals (these are also very handy in optimization). Pointers: http://www.loria.fr/projets/mpfr/ http://www.ens-lyon.fr/~nrevol/nr_software.html
Note that one reason for using BCD over GMP longs (which are presumably similar to Python longs) is speed of I/O conversion.
Depends on which base you use for that conversion ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (6)
-
aahz＠rahul.net -
Fred L. Drake, Jr. -
Guido van Rossum -
Jeremy Hylton -
M.-A. Lemburg -
Tim Peters