Sounds fine, they’re both immutable which helps.
Sounds fine, they’re both immutable which helps.
UTF-8 is an encoding for unicode, that means it’s a way of representing a unicode string as actual bytes on a computer.
It is variable length and works by using the first bits of each byte to indicate how many bytes are are needed to represent the current character.
Python also uses an encoding, as you describe in the article, but it’s different to UTF-8. Unlike unicode, all characters in Python’s representation of the unicode string use the same number of bytes, which is the maximum that any individual unicode character in the string needs.
I’d probably mess up a more detailed explanation of UTF-8 or Python’s representation, so I’ll let you look into how they work in more detail if you’re interested.
The article says that CPython represents strings as UTF-8 encoded, which is not correct. The details about how it works are correct, just that’s not UTF-8.
That’s just a minor point though, nice article.
It’d be nice to have a rule specifically for the use of f-strings and template formatting in the same call, since that can easily be a security vulnerability.
I’m pretty sure most type checkers recognise both forms.
It probably really depends on the project, though I’d probably try and start with the tests that are easiest/nicest to write and those which will be most useful. Look for complex logic that is also quite self-contained.
That will probably help to convince others of the value of tests if they aren’t onboard already.
Yeah they’ve put them in a couple places, It’s pretty bad. Had to work out how to create a custom uBlock Origin rule to block them.
If you use poetry add
it should only update what is necessary, and you can use poetry lock --no-update
to lock without updating everything.
And whether PEP 703 is accepted will probably depend quite a lot on the result of this poll: https://discuss.python.org/t/poll-feedback-to-the-sc-on-making-cpython-free-threaded-and-pep-703/28540
Yeah, my experience with docker on windows has been pretty bad, uses high CPU and RAM at the best of times, at the worst completely hangs my computer on 100% CPU usage forcing a restart as the only fix.
I really don’t understand why people are overcomplicating this. You can install multiple Python versions at once on Windows and it just works fine (you can use the py
command to select the one you want).
Virtual environments are designed exactly for this use case. They’ve got integrations for pretty much everything, they’re easy to delete/recreate, they’re really simple to use, they’re fast, and they just work.
If virtual environments alone aren’t quite enough you can use something like poetry or pipenv or the many other package management options, but in many cases even that is overkill.
I don’t see why you need a singleton, just use use a global variable if you really need one. A singleton has all the same downsides but just hides them by not looking like a global.
https://nedbatchelder.com/blog/202204/singleton_is_a_bad_idea.html
Great TIL, I hate it.
Excellent how the page alludes to other horrible things to imagine, like “don’t pour hot oil into your ear”, and “don’t pour it in if there’s a hole in your eardrum”
My general opinion for libraries is that it’s fair to stop supporting Python versions as soon as they’re EOL. It’s unfair to ask maintaners to have to juggle supporting 6 or more Python versions at once, mostly for the benefit of a few companies who haven’t updated yet.
I think it’s also fair here, you’ll still be able to use older versions, you just won’t get the newest features, which clearly isn’t your number 1 priority if you’re still using Python 3.7.
Ah yeah, I see what you meant.
Yeah, can use httpx or aiohttp for sending requests.
Same, I think it’s more common only to use when necessary.
The main case I can think of to use it more is for performance to save an import at runtime, but I don’t think that’s really valid, especially since the fact you’re using the type annotation suggest the module would have been used elsewhere anyway so the import would be cached.
The argument against using anywhere is that it could be misleading as your editor may indicate that the import is definited even if it wouldn’t be at runtime. Not sure if things like pylance have special handling to avoid this, would have to check…
You still need to import the type before using it in a stringified type annotation for it to be valid though, so you’d need the import in an if TYPE_CHECKING:
block either way, no?
“Python crash course” sounds good - I haven’t read it personally but my experience with no starch press books is that they’re pretty good.
Other options are “A byte of Python” and “Automate the boring stuff with Python”.
I am also someone who prefers physical books. When I was learning I went to my local library and took out pretty much their entire section of Python books (not that big) and read through them.
Most important is to find out what works for you!
The full changelog for this release is here https://docs.python.org/release/3.11.7/whatsnew/changelog.html#python-3-11-7-final
Surprisingly not shown that obviously in the release announcements, but I guess that’s fair since most of the changes will have no effect on 99.9999% of people.