[Python-Dev] Struct module format code addition (previously was in the subprocess thread)

"Martin v. Löwis" martin at v.loewis.de
Wed Oct 13 20:51:46 CEST 2004

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.


More information about the Python-Dev mailing list