Re: [Python-Dev] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)
Noam, There's a simple solution to all this - write a competing PEP. One of the two competing PEPs may be accepted. FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed. PEP 351 is simple to explain, simple to implement and leaves things under the control of the developer. I think there are still some issues to be resolved, but the basic premise is exactly what I would want of a freeze protocol. Tim Delaney
On 11/1/05, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
I will. It may take some time, though.
It is true that PEP 351 is simpler. The problem is, that thanks to PEP 351 I have found a fundamental place in which the current Python design is not optimal. It is not easy to fix it, because 1) it would require a significant change to the current implementation, and 2) people are so used to the current design that it is hard to convince them that it's flawed. The fact that discussing the design is long doesn't mean that the result, for the Python programmer, would be complicated. They won't - my suggestion will cause almost no backward-compatibility problems. Think about it - it clearly means that my suggestion simply can't make Python programming *more* complicated. Please consider new-style classes. I'm sure they required a great deal of discussion, but they are simple to use -- and they are a good thing. And I think that my suggestion would make things easier, more than the new-style-classes change did. Features of new-style classes are an advanced topic. The questions, "why can't I change my strings?" "why do you need both a tuple and a list?" and maybe "why can't I add my list to a set", are fundamental ones, which would all not be asked at all if my suggestion is accepted. Noam
On 11/1/05, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
I will. It may take some time, though.
It is true that PEP 351 is simpler. The problem is, that thanks to PEP 351 I have found a fundamental place in which the current Python design is not optimal. It is not easy to fix it, because 1) it would require a significant change to the current implementation, and 2) people are so used to the current design that it is hard to convince them that it's flawed. The fact that discussing the design is long doesn't mean that the result, for the Python programmer, would be complicated. They won't - my suggestion will cause almost no backward-compatibility problems. Think about it - it clearly means that my suggestion simply can't make Python programming *more* complicated. Please consider new-style classes. I'm sure they required a great deal of discussion, but they are simple to use -- and they are a good thing. And I think that my suggestion would make things easier, more than the new-style-classes change did. Features of new-style classes are an advanced topic. The questions, "why can't I change my strings?" "why do you need both a tuple and a list?" and maybe "why can't I add my list to a set", are fundamental ones, which would all not be asked at all if my suggestion is accepted. Noam
participants (2)
-
Delaney, Timothy (Tim) -
Noam Raphael