131–140 of 420 posts
> Brown called out the XML parser and tkinter in particular for making the standard library larger and harder to build, burdening all programmers for the sake of a few Tkinter needs to go...There is very little reason except for the legacy ones, why it needs to be there still...
> six is non-optional for writing code for Python 2 and 3 I maintain a Python 2 & 3 compatible project that has no external dependencies.
have you written your own 2/3 compatibility layer? I can't imagine writing anything large without six... fwiw, six can easily be vendored into a project to avoid the technical external dependency. that is how we manage it for kafka-python.
As the maintainer of WebOb/Pyramid/Waitress we have a compat module that contains all of the changes/renames/functions to help with the Python2/3 compatibility and all tests run across both platforms.
Are the functions borrowed heavily from six? Yes, but we don't need to vendor all of six.
If your project has any third-party dependencies, and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway, I can see that you're going to think things like "this XML parser in the standard library is just getting in the way; I can get a better one from PyPi". But I think a lot of the value of a large standard library is that it makes it possible to write more programs without need…
Earlier quoted context omitted.
> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole. Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you h…
Yes, my own employer is similar (you don't need permission, but production systems have no internet access and so you need to pre-download all your tarballs etc.), and cargo doesn't work right. But I think there is work on pointing cargo at an internal mirror. We do have an internal PyPI mirror (with devpi) and we point `pip` at that, and it works pretty well.
(Pointing at an internal mirror is now stable. Setting up that mirror is the hard part.)
The Python standard library has been a huge help for me. Evaluating which third party packages to trust and handling updates is a hassle. (Would love a solution for this. Does anyone have a curated version of PyPI?) I’m surprised that people want to slim it down other than for performance on a more constrained system. As an aside, why doesn’t the Python standard library extend/replace features with code from successf…
+100 > As an aside, why doesn’t the Python standard library extend/replace features with code from successful packages like Requests? It is possible (ie. asyncio was separate package). It is slow process though.
Why, time and time again, does Guido seem incapable of reasonable debate, or ideas that challenge his own? It's completely rude to interrupt a presenter with 'what is your point?' Years ago I was in contact with the author of Nuitka, who was very excited to share his work thus far. During his presentation, Guido kept huffing and making snide comments under his breath. All because he disagrees with the premise behind…
(Though in nothing on the level of some in open source).
Earlier quoted context omitted.
Oof, I wasted a good hour+ trying to convert from one to the other. Maybe there's an easy way to do this, but not many people on IRC knew (or were available at the time).
use std::iter::FromIterator; BTreeMap::from_iter(hash_map.into_iter())
Earlier quoted context omitted.
This isn't a paradox. once it's released it's not a bug anymore, it's just behaviour. document the behaviour, but breaking compatibility with previous versions is a bug. it doesn't matter how obviously wrong the previous behaviour is.
> but breaking compatibility with previous versions is a bug That's how you get an inconsistent mess that never evolves. There's something called semver , increase the version number and do the fix / refactors / radical redesign / whatever. People will see that you've went from version 1.0 to 87.3 in one year and they may choose not to use your thing because you're moving too fast for them, but that's life...
The Python standard library has been a huge help for me. Evaluating which third party packages to trust and handling updates is a hassle. (Would love a solution for this. Does anyone have a curated version of PyPI?) I’m surprised that people want to slim it down other than for performance on a more constrained system. As an aside, why doesn’t the Python standard library extend/replace features with code from successf…
That would be my guess. I would also add that getting through the process of adding a third-party set of modules to the standard library can take quite a while.
> six is non-optional for writing code for Python 2 and 3 I maintain a Python 2 & 3 compatible project that has no external dependencies.
I do similarly as you (maintain 2/3 code without dependencies) but every time I have to do string encoding/decoding it kills me to find a way that half works, and I don't have a ready solution in my mind for these that doesn't break half the time. How do you handle non-ASCII in a compatible manner? Like Unicode stdio? Unicode file paths? Unicode sys.argv? string_escape/unicode_escape? I feel like Python 3 completely…
In some cases of common OS-induced pain, I'd say "do whatever 3 does" in 2, since that'll make migration easier in the long run. (But I understand that can be hard, and I think my responses to your examples below even demonstrate that to be hard.)
To your specific pain points:
> Unicode stdio?
Mostly, `io` should handle this in both 3/2. You might need to help it get the right encoding in 2.
> Unicode file paths
This is going to be a mess in any language, because file paths really aren't text. On nix, they're byte strings that don't have nuls in them. Hopefully* they're encoded according to LANG, and hopefully LANG is a UTF-8 variant, but it isn't required, and it isn't required that two users on the same system use compatible LANGs, so you get a Tower of Babel. I really wish OSs would just start enforcing a. Unicode filenames, and b. no newlines in filenames; those two alone would make life so much easier.
Hopefully you've seen os.fsencode / fsdecode, but alas those aren't in 2, so I'm not sure they really help you. Often one is not really munging paths that much, and can just pass through whatever value/type you get, but it does happen, of course. (E.g., adding or removing extensions)
> Unicode sys.argv
This is also a pain point, since again, the underlying type in nix is a byte string without nuls. I'd hope it decodes w/ the LANG encoding, but since the user could easily tab-complete a filename, fsencode/decode might be more appropriate. I think I'd say "do whatever 3 does".
1 Jan 2020 is nearly here. Forget about 2 / assume UTF-8 in 2 and don't support anything else?
> I feel like Python 3 completely wrecked strings instead of making them better.*
A clear separation of text and binary is needed in the long run, and makes other operations much clearer and saner. The pain you're feeling is introduced from the OS not having the same clarity.