On 10:06 am, g.brandl at gmx.net wrote: >> What a successor to os.path needs is not security, it's a better (more pythonic, >> if you like) interface to the old functionality. Glyph: > Why? > Rushing ... could exacerbate a very real problem, e.g. > the security and data-integrity implications of idiomatic usage. The proposed Path object (or new path module) is intended to replace os.path. If it can't do the equivalent of "cd ..", then it isn't a replacement; it is just another similar alternative to confuse beginners. If you're saying that a webserver should use a more restricted subclass (or even the existing FilePath alternative), then I agree. I'll even agree that a restricted version would ideally be available out of the box. I don't think it should be the only option. -jJ
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