#stdlib — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #stdlib, aggregated by home.social.
-
Now this is an interesting #Python problem. I don't know if it's a #bug, but it's a change in behaviour that I don't see documented.
I upgraded from #Debian 12/Bookworm to 13/Trixie, so the default Python3 changed from 3.11 to 3.13. A script of mine broke, because `pathlib.Path.is_mount()` changed behaviour when the path is a symlink (at least to a directory).
i.e. I'm testing a path that is a symlink. The symlink points to a directory. That directory *is* a mountpoint. The `.is_mount()` test in 3.11 returned True, while in 3.13 it returns False.
This seems wrong to me. Most path-manipulation functions transparently treat symlinks as if they were the pointed-to object unless you pass an option/flag specifically to say you want the symlink itself.
Gonna have to dig to see what else I can find.
#pathlib #path #is_mount #stdlib #behaviour #symlink #filesystem #mountpoint #mount
-
Now this is an interesting #Python problem. I don't know if it's a #bug, but it's a change in behaviour that I don't see documented.
I upgraded from #Debian 12/Bookworm to 13/Trixie, so the default Python3 changed from 3.11 to 3.13. A script of mine broke, because `pathlib.Path.is_mount()` changed behaviour when the path is a symlink (at least to a directory).
i.e. I'm testing a path that is a symlink. The symlink points to a directory. That directory *is* a mountpoint. The `.is_mount()` test in 3.11 returned True, while in 3.13 it returns False.
This seems wrong to me. Most path-manipulation functions transparently treat symlinks as if they were the pointed-to object unless you pass an option/flag specifically to say you want the symlink itself.
Gonna have to dig to see what else I can find.
#pathlib #path #is_mount #stdlib #behaviour #symlink #filesystem #mountpoint #mount
-
Now this is an interesting #Python problem. I don't know if it's a #bug, but it's a change in behaviour that I don't see documented.
I upgraded from #Debian 12/Bookworm to 13/Trixie, so the default Python3 changed from 3.11 to 3.13. A script of mine broke, because `pathlib.Path.is_mount()` changed behaviour when the path is a symlink (at least to a directory).
i.e. I'm testing a path that is a symlink. The symlink points to a directory. That directory *is* a mountpoint. The `.is_mount()` test in 3.11 returned True, while in 3.13 it returns False.
This seems wrong to me. Most path-manipulation functions transparently treat symlinks as if they were the pointed-to object unless you pass an option/flag specifically to say you want the symlink itself.
Gonna have to dig to see what else I can find.
#pathlib #path #is_mount #stdlib #behaviour #symlink #filesystem #mountpoint #mount
-
Now this is an interesting #Python problem. I don't know if it's a #bug, but it's a change in behaviour that I don't see documented.
I upgraded from #Debian 12/Bookworm to 13/Trixie, so the default Python3 changed from 3.11 to 3.13. A script of mine broke, because `pathlib.Path.is_mount()` changed behaviour when the path is a symlink (at least to a directory).
i.e. I'm testing a path that is a symlink. The symlink points to a directory. That directory *is* a mountpoint. The `.is_mount()` test in 3.11 returned True, while in 3.13 it returns False.
This seems wrong to me. Most path-manipulation functions transparently treat symlinks as if they were the pointed-to object unless you pass an option/flag specifically to say you want the symlink itself.
Gonna have to dig to see what else I can find.
#pathlib #path #is_mount #stdlib #behaviour #symlink #filesystem #mountpoint #mount
-
Now this is an interesting #Python problem. I don't know if it's a #bug, but it's a change in behaviour that I don't see documented.
I upgraded from #Debian 12/Bookworm to 13/Trixie, so the default Python3 changed from 3.11 to 3.13. A script of mine broke, because `pathlib.Path.is_mount()` changed behaviour when the path is a symlink (at least to a directory).
i.e. I'm testing a path that is a symlink. The symlink points to a directory. That directory *is* a mountpoint. The `.is_mount()` test in 3.11 returned True, while in 3.13 it returns False.
This seems wrong to me. Most path-manipulation functions transparently treat symlinks as if they were the pointed-to object unless you pass an option/flag specifically to say you want the symlink itself.
Gonna have to dig to see what else I can find.
#pathlib #path #is_mount #stdlib #behaviour #symlink #filesystem #mountpoint #mount
-
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#ycombinator #technical_leadership #engineering_management #stdlib #leadership_resources #management_templates #engineering_frameworks #team_building #software_architecture #debugging_leadership -
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#ycombinator #technical_leadership #engineering_management #stdlib #leadership_resources #management_templates #engineering_frameworks #team_building #software_architecture #debugging_leadership -
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#ycombinator #technical_leadership #engineering_management #stdlib #leadership_resources #management_templates #engineering_frameworks #team_building #software_architecture #debugging_leadership -
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#ycombinator #technical_leadership #engineering_management #stdlib #leadership_resources #management_templates #engineering_frameworks #team_building #software_architecture #debugging_leadership -
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#HackerNews #Stdlib #TechnicalLeadership #Frameworks #Templates #Guides
-
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#HackerNews #Stdlib #TechnicalLeadership #Frameworks #Templates #Guides
-
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#HackerNews #Stdlib #TechnicalLeadership #Frameworks #Templates #Guides
-
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#HackerNews #Stdlib #TechnicalLeadership #Frameworks #Templates #Guides
-
Stdlib: A library of frameworks, templates, and guides for technical leadership
https://debuggingleadership.com/stdlib
#HackerNews #Stdlib #TechnicalLeadership #Frameworks #Templates #Guides
-
Brand new PEP by @emmatyping to add Zstandard to the standard library:
https://peps.python.org/pep-0784/Will it make it in to 3.14 before the feature freeze on 2025-05-06? It'll be close but it's possible!
The PEP also suggests namespacing the other compression libraries lzma, bz2 and zlib, with a 10-year deprecation for the old names.
Join the discussion to give your support, suggestions or feedback:
https://discuss.python.org/t/pep-784-adding-zstandard-to-the-standard-library/87377
-
Brand new PEP by @emmatyping to add Zstandard to the standard library:
https://peps.python.org/pep-0784/Will it make it in to 3.14 before the feature freeze on 2025-05-06? It'll be close but it's possible!
The PEP also suggests namespacing the other compression libraries lzma, bz2 and zlib, with a 10-year deprecation for the old names.
Join the discussion to give your support, suggestions or feedback:
https://discuss.python.org/t/pep-784-adding-zstandard-to-the-standard-library/87377
-
Brand new PEP by @emmatyping to add Zstandard to the standard library:
https://peps.python.org/pep-0784/Will it make it in to 3.14 before the feature freeze on 2025-05-06? It'll be close but it's possible!
The PEP also suggests namespacing the other compression libraries lzma, bz2 and zlib, with a 10-year deprecation for the old names.
Join the discussion to give your support, suggestions or feedback:
https://discuss.python.org/t/pep-784-adding-zstandard-to-the-standard-library/87377
-
Brand new PEP by @emmatyping to add Zstandard to the standard library:
https://peps.python.org/pep-0784/Will it make it in to 3.14 before the feature freeze on 2025-05-06? It'll be close but it's possible!
The PEP also suggests namespacing the other compression libraries lzma, bz2 and zlib, with a 10-year deprecation for the old names.
Join the discussion to give your support, suggestions or feedback:
https://discuss.python.org/t/pep-784-adding-zstandard-to-the-standard-library/87377
-
Brand new PEP by @emmatyping to add Zstandard to the standard library:
https://peps.python.org/pep-0784/Will it make it in to 3.14 before the feature freeze on 2025-05-06? It'll be close but it's possible!
The PEP also suggests namespacing the other compression libraries lzma, bz2 and zlib, with a 10-year deprecation for the old names.
Join the discussion to give your support, suggestions or feedback:
https://discuss.python.org/t/pep-784-adding-zstandard-to-the-standard-library/87377
-
Unix buffering: The clearest explanation I've ever seen about line buffering, block buffering, and tty output vs simple file / pipe
https://jvns.ca/blog/2024/11/29/why-pipes-get-stuck-buffering/
#buffering #stdlib #linux #shell #unix #cli #+ -
Unix buffering: The clearest explanation I've ever seen about line buffering, block buffering, and tty output vs simple file / pipe
https://jvns.ca/blog/2024/11/29/why-pipes-get-stuck-buffering/
#buffering #stdlib #linux #shell #unix #cli #+ -
Unix buffering: The clearest explanation I've ever seen about line buffering, block buffering, and tty output vs simple file / pipe
https://jvns.ca/blog/2024/11/29/why-pipes-get-stuck-buffering/
#buffering #stdlib #linux #shell #unix #cli #+ -
Unix buffering: The clearest explanation I've ever seen about line buffering, block buffering, and tty output vs simple file / pipe
https://jvns.ca/blog/2024/11/29/why-pipes-get-stuck-buffering/
#buffering #stdlib #linux #shell #unix #cli #+ -
Unix buffering: The clearest explanation I've ever seen about line buffering, block buffering, and tty output vs simple file / pipe
https://jvns.ca/blog/2024/11/29/why-pipes-get-stuck-buffering/
#buffering #stdlib #linux #shell #unix #cli #+ -
It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
-
It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
-
It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
-
It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
-
It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
-
2) Python Standard Library: #Python #stdlib comes with batteries included, that means even though there are several ways to do something, in specific cases using a certain stdlib function like `chain()` will be the fastest. Or not, like when cloning a 2d list it's faster to `copy()` manually in a loop than to pickle-unpickle
-
2) Python Standard Library: #Python #stdlib comes with batteries included, that means even though there are several ways to do something, in specific cases using a certain stdlib function like `chain()` will be the fastest. Or not, like when cloning a 2d list it's faster to `copy()` manually in a loop than to pickle-unpickle
-
2) Python Standard Library: #Python #stdlib comes with batteries included, that means even though there are several ways to do something, in specific cases using a certain stdlib function like `chain()` will be the fastest. Or not, like when cloning a 2d list it's faster to `copy()` manually in a loop than to pickle-unpickle
-
2) Python Standard Library: #Python #stdlib comes with batteries included, that means even though there are several ways to do something, in specific cases using a certain stdlib function like `chain()` will be the fastest. Or not, like when cloning a 2d list it's faster to `copy()` manually in a loop than to pickle-unpickle
-
2) Python Standard Library: #Python #stdlib comes with batteries included, that means even though there are several ways to do something, in specific cases using a certain stdlib function like `chain()` will be the fastest. Or not, like when cloning a 2d list it's faster to `copy()` manually in a loop than to pickle-unpickle
-
Well done, but ...
>>> import fractions
>>> fractions.Fraction(0.125)
Fraction(1, 8)
>>> fractions.Fraction(0.3333)
Fraction(6004199023210345, 18014398509481984)
>>> fractions.Fraction(0.3333).limit_denominator(1000)
Fraction(1, 3)A lesser-known part of the #stdlib
😂
-
Well done, but ...
>>> import fractions
>>> fractions.Fraction(0.125)
Fraction(1, 8)
>>> fractions.Fraction(0.3333)
Fraction(6004199023210345, 18014398509481984)
>>> fractions.Fraction(0.3333).limit_denominator(1000)
Fraction(1, 3)A lesser-known part of the #stdlib
😂
-
Well done, but ...
>>> import fractions
>>> fractions.Fraction(0.125)
Fraction(1, 8)
>>> fractions.Fraction(0.3333)
Fraction(6004199023210345, 18014398509481984)
>>> fractions.Fraction(0.3333).limit_denominator(1000)
Fraction(1, 3)A lesser-known part of the #stdlib
😂
-
Well done, but ...
>>> import fractions
>>> fractions.Fraction(0.125)
Fraction(1, 8)
>>> fractions.Fraction(0.3333)
Fraction(6004199023210345, 18014398509481984)
>>> fractions.Fraction(0.3333).limit_denominator(1000)
Fraction(1, 3)A lesser-known part of the #stdlib
😂
-
Well done, but ...
>>> import fractions
>>> fractions.Fraction(0.125)
Fraction(1, 8)
>>> fractions.Fraction(0.3333)
Fraction(6004199023210345, 18014398509481984)
>>> fractions.Fraction(0.3333).limit_denominator(1000)
Fraction(1, 3)A lesser-known part of the #stdlib
😂
-
I need a dummy #RubyLang #IMAP server that can support #STARTTLS but otherwise treats most commands as no-ops. I couldn't find anything well-maintained via GitHub or Ruby Toolbox other than the gem from Ruby's #stdlib at:
https://ruby-doc.org/3.2.2/gems/net-imap/Net/IMAP.html
Rather than gutting Net::IMAP, is there already a gem out there that can be used to support fetch-before-send clients like Apple's Mail that won't send email before completing POP3 or IMAP4 authentication?
-
Python libs you're using (stdlib and not) that have better alternatives.
- `dataclasses` -> `attrs`
- `json` -> `orjson`
- `requests` -> `httpx`
- `pyoidc` -> `authlib`
- `pytest-freezegun` -> `time-machine`
- `aioredis` -> `redis`Have I missed anything?
-
Python libs you're using (stdlib and not) that have better alternatives.
- `dataclasses` -> `attrs`
- `json` -> `orjson`
- `requests` -> `httpx`
- `pyoidc` -> `authlib`
- `pytest-freezegun` -> `time-machine`
- `aioredis` -> `redis`Have I missed anything?
-
Python libs you're using (stdlib and not) that have better alternatives.
- `dataclasses` -> `attrs`
- `json` -> `orjson`
- `requests` -> `httpx`
- `pyoidc` -> `authlib`
- `pytest-freezegun` -> `time-machine`
- `aioredis` -> `redis`Have I missed anything?
-
Python libs you're using (stdlib and not) that have better alternatives.
- `dataclasses` -> `attrs`
- `json` -> `orjson`
- `requests` -> `httpx`
- `pyoidc` -> `authlib`
- `pytest-freezegun` -> `time-machine`
- `aioredis` -> `redis`Have I missed anything?
-
