Josiah Carlson wrote:
For those features, the potential user community is *much* larger than for the feature under discussion, and I feel I would waste my time for adding a feature that only few users ever need.
And yet you continue the discussion?
This tends to get off-topic, but I typically respond when I'm asked a question. As you keep asking questions, I keep responding :-)
If every modification to Python required a community of people, who all joined together to advocate something, then nothing would ever get done.
No. Modifications to fix bugs don't need debating. Only new features do. I do wish that people would focus more on fixing bugs than on introducing new features.
People would be spending all their time trying to gather groups of people to agree with them that functionality K is necessary.
And that would be a good thing, atleast in the specific case. Even if it is undebated that the feature (convert numbers into odd-sized byte strings) is desirable, the specific API needs careful consideration, since it cannot be changed easily after it has been added. So all these new features are a serious legacy if they later turn out to be ill-designed.
I'm not even saying that we should add a new module. I'm not even saying we should add a new function to a module. Heck, I'm not even asking for a new argument to a function that previously existed. I am, quite literally, asking for the equivalent of less than one bit in a flag (there are currently 22 format/endian characters, which are all orthogonal, which would require 5 bits, if they were flags).
Correct. Yet I would feel more comfortable if you had proposed a new module, or a new function to an existing module. The former would allow distribution independent of Python, and the latter would not put a burden on users of the existing functions.
The API already exists. The framework already exists. I'm not asking for Python to interpret something that was valid before as something different now.
Yes. The extension you propose probably does not cause backward compatibility problems. Strictly speaking, there are programs that break under this extension, but this is the case for any extension, and such programs likely don't occur in real life.
Try to read the above paragraph outside of the context of struct and the RFE. Does it make sense to include the change now?
No. For such a change, we need to study whether there alternative APIs which achieve the same effect (which there are), and whether the new flag puts an additional learning burden on users of the existing API (which it does).
If every request to interpret a new flag required significant community involvement, goodness, would it take an act of Guido to get a commit done?
No, I have committed new features myself in the past. See the CVS log for details. It is this specific change I'm opposed to, at this point in time.