Guido van Rossum wrote:
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 success.
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 your comments.
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.)
True, but I was thinking of the concept and design questions which should be resolved *before* taking the direct checkin approach.
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 thought.
Understood, but then I'd like to at least receive a summary of the changes in some way, so that I continue to understand how the implementation works after the checkins and which corners to keep in mind for future additions, changes, etc.
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 with it.
I don't have a problem with it; I was just seeing things slip my fingers and getting worried about this.
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.
Not really. I have processed many patches on SF, gave comments etc. and did the final checkin. This has worked great over the last months and I intend to keep working this way since it is by far the best way to both manage and document the issues and questions which arise during the process.
E.g. I'm currently processing a patch by Walter Dörwald which adds support for callback error handlers. He has done some great work there which was the result of many lively discussions. Working like this is fun while staying manageable at the same time... and again, there's really no need to rush things !
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 good job.
Well, the above was my interpretation of how things went. I may have been wrong (and honestly do hope that I am wrong), but my gutt feeling simply said: hey, what are these guys doing there... is this some kind of
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!)
That was not my point: quality control also includes checking the design approach. This is something which should normally be done in design/implementation/design/... phases -- just like I worked with you on the Unicode implementation late in 1999.
Conclusion: 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 to perfection.
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 temporary?)
I am currently doing a lot of consulting work, so things sometimes tighten up and are less work intense at other times. Given this setup, I think that I will be able to play the BD (without the FL) for Unicode for some time. I will certainly pass on the flag to someone else if I find myself not spending enough time on it.
The only thing I'm asking for, is some more professional work mentality at times. If people make it hard for me to follow the development, then I cannot manage this task in a satisfying way.
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 maintain.
Nobody said you couldn't comment, and you know that.
If I don't get a chance to comment on a summary of changes (be it before or after a batch of checkings), how am I supposed to follow up on them ? Keeping a close eye on the checkin mailing list doesn't help: it simply doesn't always give you the big picture.
We are all professional quality programmers and I respect Fredrik and Martin for their coding quality and ideas. What I am asking for is some more teamwork.
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.)
That's perfectly OK (and indeed can be very useful at times).
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.
I'll visit the Bordeaux Python conference later week. That should give me some time to breathe (and hopefully to write some more PEPs :=).
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 a notch!
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.
Thanks. Be assured that I'll stay around for quite some time -- you won't get by that easily ;-)