Guido wrote: > > but what if I *want* to do fruity things? that's the whole point = here: > > if the framework delegates imports to objects in the sys.path list, = it's > > dead simple to experiment. >=20 > That's a good point. The question then is, if you want to use some > 3rd party code that assumes strings, and it breaks as a result, what > is broken? Your code or the 3rd party code? PIL used to assume strings, and there are a few bug reports on this topic in the PIL issue database. they're all very polite, so I think the answer might be "I did something fruity, so it's probably my fault, and I'm prepared to work around the problem, but it would be nice if the 3rd party library was fixed too". or in other words, we should warn application developers that explicitly adding non-string objects to the path may cause existing code (including 3rd party libraries) to break, and encourage 3rd party developers to = write robust code. </F>
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