On 29 March 2016 at 09:44, Sven R. Kunze firstname.lastname@example.org wrote:
I don't think we (as the Python community) can allow ourselves to stand still. We need to have tools that are simple and available. If YAML is the new standard for everything, Python should move. If $ before variable names are the new standard (I hope they never will again), Python should move.
I understand that there are preservers who don't want anything to change. So, compromises will be necessary.
I agree 100% that Python should not stand still. However, every addition to the core language involves a backward compatibility cost that must be very carefully weighed. If we built XML into the language back when that was the standard, then we'd now be looking at adding YAML, but we wouldn't be able to remove XML without significant pain.
So a conservative approach *to core language syntax* is entirely reasonable.
Having said that, Python has a very good means of adding new *functionality* in the form of modules, and an very good path for gradually standardising modules in the form of personal library -> PyPI package -> stdlib package.
I'm much more in favour of discussions on how to address the perceived shortcomings of pathlib over alternatives like path.py and pylib's path object. If it's all about subclassing str, then let's by all means reopen that debate - making Path a str subclass is something that could be done as a stdlib change if the decision made in the original PEP was agreed to be flawed (I'm not sure it was, personally, but I'm open to a discussion on that, as the need to convert to and from strings certainly is a nuisance).
To be honest, I do think it feels like URL:s are becoming (or have become) just as important as paths, and that pathlib.Path should in the future work with URLs just like it now works with windows and posix paths. The difference between "http://domain.xyz/" and "C:\" is not huge. I also think there should be a Python type (stdlib or builtin), which handles JSON objects nicer than dicts do and has its own literal
So again, if you have personal code you find cleaner and more usable for this job, publish it on PyPI, publicise it and gain support for it, and then propose it for stdlib inclusion. This also has the advantage of being useful for Python 3.4/3.5 users (and you can even support Python 2.7 if you wish).
I've no idea how we would ensure that a built in syntax for URLs was correctly designed without having got design experience with the feature as a library module.