Guido van Rossum wrote: >>Very close is still not good enough :-) >> >>I can't really believe that you're designing protocols that have >>to call unknown factory functions to see whether they do something >>particular or not. >> >>If you really happen to have a need for this, why can't you >>introduce factory functions which take care of your particular >>use case ? I don't think it's common enough to risk accidental >>progamming errors in other user's code. > > Marc, you haven't shown why it's so bad either, so please shut up. I beg your pardon: Just look at the last sentence in my reply. It is you that hasn't shown a single qualified use case for this "feature". You also haven't shown why the defaults you have chosen were picked and what the reasoning was. On other occasions you have always been picking on the usefulness of raising excpetions instead of going with defaults. Here you are doing the exact opposite and the only argument I've heard so far is that you need to call constructors without argument in Zope3 for some reason which you also haven't explained. If there's no use case for this, then why add a case for possible programming errors ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jun 13 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 11 days left
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