Skip Montanaro wrote: > > mal> Why not have both whrandom and random around ? ... with whrandom > mal> using the tools from random ? > > If I understood Tim correctly yesterday, whrandom's seed method was pretty > bad. There's nothing bad in the .seed() method. You just have to pass it some sane values (rather than relying on the defaults). > Migrating the whrandom algorithms to the random module made sense, and > having a seed method made sense, but it had to be an improved seed method. > If you're going to create a semantically different seed method, you might as > well deprecate whrandom altogether. Allowing people to continue using > whrandom with the old seed method gives them a false sense of security that > they have a good random number generator at their disposal. Using it with a > new and improved seed method may allow their code to break in subtle ways. > To make matters worse, most people don't even realize they are calling seed > in the first place. The best course is simply to deprecate whrandom so > people have to explicitly address the issue. Explicit is better than > implicit. > > That said, when I mapped "whrandom" to "random" in my own code, I completely > ignored this issue with no problems. Of course, my use of random numbers is > not all that demanding. When I multi-threaded my XML-RPC server I had to > address locking issues though. Most people will probably be able to execute > > s/whrandom/random/g > > and be done with it. Those people who aren't able to make that simple > translation are probably rare and know what the issues are. You won't have much luck in doing s/whrandom/random/g on a hard-copy Python text book and this is what Python newbies read. I'm not even talking about potential Python users who haven't gotten the slightest idea what sed is... :-) Note that the key point is a different one: every single deprecation causes work (convincing management, code changes, tests, deployment of the new code, training application developers, writing/buying new books). Work costs money. Money causes all sorts of problems. If not absolutely needed in order to make way for new techniques or features, we should leave the old established code in place rather than causing endless support sessions with customers who fear that the code you've written for them 6 months ago starts making not so funny noises or that drag you to update the code on a warranty basis. What's worse, is that management will not be delighted to see that this "new technology we use, called Python" causes quality assurance and training costs every 8-12 months. I wouldn't want Python to go down that road, now that the ball is starting to roll. > mal> I don't see the value of deprecating a stone-old module > mal> just because there's a new flashy module with a different > mal> name around. If it's possible to maintain backward > mal> compatibility then it should be maintained. Period. > > It's not just a different name. It's subtly different semantics. It should be no problem emulating the old behaviour using the new code or simply leaving the old code in place (it's not broken in any way). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4