What's so funny? WAS Re: rotor replacement

["Martin v. Löwis"]

phr at localhost.localdomain wrote:
> That it's not appropriate for the
> distro maintainers to look at the spec and the reference (pure Python)
> implementatation and say "yes, we want this, go write the C version
> and we'll include it after it's had some testing".  

I know that I'm not going to give a blanket promise to include some
code in the future. I can give blanket promises to *review* such
code. Actually, assuming I find the time, I will review *any*
code that is contributed.

> When the inestimable Alexbot went to O'Reilly to pitch "Python in a
> Nutshell", I'm sure they didn't tell him "go write the whole book from
> cover to cover, circulate it for at least a year and get it thoroughly
> reviewed, and if enough people recommend it, then and only then will
> we begin to think about distributing it ourselves".

Sure. That is because O'Reilly is willing to take a financial risk
of failure of a book product. I'm not willing to take similar risks
for Python code (risk of having to redesign the interface, fix bugs
in the implementation, or have the submitter run away after the
contribution).

> Similarly, look at how the whole PEP process works.  There are lots of
> times when a PEP has been accepted before any working code is
> distributed.

Indeed. For new language features, it is more difficult to try them out
in advance than for new library API. As a result, flaws of the new 
feature are often only fully understood years after the new feature
first gets released. For an example, consider the buffer interface.

> To take your view to an extreme, no project should even have a task
> list of desired features that people are invited to implement.

Taking it to the extreme misses the point. I'm asking for field testing
for new modules - not for all changes.

> That's bizarre and abnormal as a development process.  What kind of
> development process in industry doesn't decide whether to include a
> feature, until after the feature is completely implemented at a
> production scale?

Any high-quality standardization process. Standards in IETF and OMG
are only accepted after implementations have been available.

> You seem to have the attitude that since volunteer development effort
> doesn't consume actual PSF funds, the volunteer effort is worth
> nothing and can be expended arbitrarily.  The volunteers may not feel
> that way.

The volunteers are free to work on whatever they please. If you chose
not to write an AES module - that's fine with me. Still, people do
contribute to Python, and they do so without asking for permission
first. Typically, they develop the code because it solves their own
needs - then it doesn't really matter whether it also solves the
needs of others.

>>In either case, the user would best use the pre-compiled binary that
>>somebody else provided for the platform. 
> 
> 
> Who's the "somebody else"?

Some user. I find that users contribute binaries for all kinds of
platforms for the code I publish. This is how open source works.

> Do you do that
> with your own modules, and still say that it's easy?

I publish or link to binaries of my code that others have created,
and find no problems in doing so.

> Unless your requirement is different than what you say it is, I do see
> what it is, and I'm saying it's better to do what normal projects do
> and what Python has done in the past.  That is, it's perfectly ok to
> decide to do something and then do it, rather than insisting,
> bizarrely, that it always be the other way around.

No, it's three steps
1. decide that you want to do it
2. do it
3. decide whether you are pleased with the result, and only
    use it if you are

IOW, there should not be a blanket guarantee to use it after
step 1.

> I think that question isn't the right one.  We need to ask how many
> users the sha module was required to have, before Greg and Andrew
> could have reasonable confidence that the sha module would go into the
> core once it was tested enough and shown to be reliable.

They did not have *any* guarantee until they asked. I guess when they
asked it was accepted immediately.

> I suspect
> they were able to have that confidence long before testing was
> complete, and maybe before implementation even started.

I'm pretty certain that you are wrong with that assumption.
Again, we would have to ask - but I would not be surprised if
AMK started implementing the module without even *considering*
a later inclusion in the Python core at that time. He has done
so on many occasions (include PyXML, which I inherited from
him).

Regards,
Martin