[Python-Dev] Unicode Maintenance
Guido van Rossum
Thu, 28 Jun 2001 08:25:14 -0400
I'm dropping the i18n-sig from the distribution list.
I hear you:
> You didn't get my point. I feel responsable for the Unicode
> implementation design and would like to see it become a continued
I'm sure we all share this goal!
> In that sense and taking into account that I am the
> maintainer of all this stuff, I think it is very reasonable to
> ask me before making any significant changes to the implementation
> and also respect any comments I put forward.
I understand you feel that we've rushed this in without waiting for
Given how close your implementation was, I still feel that the changes
weren't that significant, but I understand that you get nervous. If
Christian were to check in his speed hack changes to the guts of
ceval.c I would be nervous too! (Heck, I got nervous when Eric
checked in his library-wide string method changes without asking.)
Next time I'll try to be more sensitive to situations that require
your review before going forward.
> Currently, I have to watch the checkins list very closely
> to find out who changed what in the implementation and then to
> take actions only after the fact. Since I'm not supporting Unicode
> as my full-time job this is simply impossible. We have the SF manager
> and there is really no need to rush anything around here.
Hm, apart from the fact that you ought to be left in charge, I think
that in this case the live checkins were a big win over the usual SF
process. At least two people were making changes, sometimes to each
other's code, and many others on at least three continents were
checking out the changes on many different platforms and immediately
reporting problems. We would definitely not have a patch as solid as
the code that's now checked in, after two days of using SF! (We
could've used a branch, but I've found that getting people to actually
check out the branch is not easy.)
So I think that the net result was favorable. Sometimes you just have
to let people work in the spur of the moment to get the results of
their best thinking, otherwise they lose interest or their train of
> If I am offline or too busy with other things for a day or two,
> then I want to see patches on SF and not find new versions of
> the implementation already checked in.
That's still the general rule, but in our enthousiasm (and mine was
definitely part of this!) we didn't want to wait. Also, I have to
admit that I mistook your silence for consent -- I didn't think the
main proposed changes (making the size of Py_UNICODE a config choice)
were controversial at all, so I didn't realize you would have a problem
> This has worked just fine during the last year, so I can only explain
> the latest actions in this direction with an urge to bypass my comments
> and any discussion this might cause.
I think you're projecting your own stuff here. I honestly didn't
think there was much disagreement on your part and thought we were
doing you a favor by implementing the consensus. IMO, Martin and and
Fredrik are familiar enough with both the code and the issues to do a
> Needless to say that
> quality control is not possible anymore.
Unclear. Lots of other people looked over the changes in your
absence. And CVS makes code review after it's checked in easy enough.
(Hey, in many other open source projects that's the normal procedure
once the rough characteristics of a feature have been agreed upon:
check in first and review later!)
> I am not going to continue this work if this does not change.
That would be sad, and I hope you will stay with us. We certainly
don't plan to ignore your comments!
> Another other problem for me is the continued hostility I feel on i18n
> against parts of the design and some of my decisions. I am
> not talking about your feedback and the feedback from many other
> people on the list which was excellent and to high standards.
> But reading the postings of the last few months you will
> find notices of what I am referring to here (no, I don't want
> to be specific).
I don't know what to say about this, and obviously nobody has the time
to go back and read the archives. I'm sure it's not you as a person
that was attacked. If the design isn't perfect -- and hey, since
Python is the 80 percent language, few things in it are quite perfect!
-- then (positive) criticism is an attempt to help, to move it closer
If people have at times said "the Unicode support sucks", well, that
may hurt. You can't always stay friends with everybody. I get flames
occasionally for features in Python that folks don't like. I get used
to them, and it doesn't affect my confidence any more. Be the same!
But sometimes, after saying "it sucks", people make specific
suggestions for improvements, and it's important to be open for those
even from sources that use offending language. (Within reason, of
course. I don't ask you to listen to somebody who is persistently
hostile to you as a person.)
> If people don't respect my comments or decision, then how can
> I defend the design and how can I stop endless discussions which
> simply don't lead anywhere ? So either I am missing something
> or there is a need for a clear statement from you about
> my status in all this.
Do you really *want* to be the Unicode BDFL? Being something's BDFL a
full-time job, and you've indicated you're too busy. (Or is that
I see you as the original coder, which means that you know that
section of the code better than anyone, and whenever there's a
question that others can't answer about its design, implementation, or
restrictions, I refer to you. But given that you've said you wouldn't
be able to work much on it, I welcome contributions by others as long
as they seem knowledgeable.
> If I don't have the right to comment on proposals and patches,
> possibly even rejecting them, then I simply don't see any
> ground for keeping the implementation in a state which I can
Nobody said you couldn't comment, and you know that.
When it comes to rejecting or accepting, I feel that I am still the
final arbiter, even for Unicode, until I get hit by a bus. Since I
don't always understand the implementation or the issues, I'll of
course defer to you in cases where I think I can't make the decision,
but I do reserve the right to be convinced by others to override your
judgement, occasionally, if there's a good reason. And when you're
not responsive, I may try to channel you. (I'll try to be more
explicit about that.)
> And last but not least: The fun-factor has faded which was
> the main motor driving my into working on Unicode in the first
> place. Nothing much you can do about this, though :-/
Yes, that happens to all of us at times. The fun factor goes up and
down, and sometimes we must look for fun elsewhere for a while. Then
the fun may come back where it appeared lost. Go on vacation, read a
book, tackle a new project in a totally different area! Then come
back and see if you can find some fun in the old stuff again.
> > Paul Prescod offered to write a PEP on this issue. My cynical half
> > believes that we'll never hear from him again, but my optimistic half
> > hopes that he'll actually write one, so that we'll be able to discuss
> > the various issues for the users with the users. I encourage you to
> > co-author the PEP, since you have a lot of background knowledge about
> > the issues.
> I guess your optimistic half won :-) I think Paul already did all the
> work, so I'll simply comment on what he wrote.
Your suggestions were very valuable. My opinion of Paul also went up
> > BTW, I think that Misc/unicode.txt should be converted to a PEP, for
> > the historic record. It was very much a PEP before the PEP process
> > was invented. Barry, how much work would this be? No editing needed,
> > just formatting, and assignment of a PEP number (the lower the better).
> Thanks for converting the text to PEP format, Barry.
> Thanks for reading this far,
You're welcome, and likewise.
Just one more thing, Marc-Andre. Please know that I respect your work
very much even if we don't always agree. We would get by without you,
but Python would be hurt if you turned your back on us.
--Guido van Rossum (home page: http://www.python.org/~guido/)