Lesser known parts of Python standard library – Trickster Dev
https://www.trickster.dev/post/lesser-known-parts-of-python-standard-library/- I find defaultdict, OrderedDict, namedtuple among other data structures/classes in the collections module to be incredibly useful.
Another module that's packaged with the stdlib that's immensely useful is itertools. I especially find takewhile, cycle, and chain to be incredibly useful building blocks for list-related functions. I highly recommend a quick read.
EDIT: functools is also great! Fantastic module for higher-order functions on callable objects.
https://docs.python.org/3/library/itertools.html
-- judicious Reply - ChainMap might be the most underrated bit in the standard library.
-- BerislavLopac Reply - Why do you use OrderedDict for now that regular dicts are ordered by default?
-- padthai Reply - It may be more explicit: OrderedDict has move_to_end() which may be useful e.g., for implementing lru_cache-like functionality (like deque.rotate but with arbitrary keys).
-- d0mine Reply - OTOH that’s a lot less useful now that functools.lru_cache exists: it’s more specialised so it’s lighter, more efficient, and thread-safe. So unless you have extended flexibility requirements around your LRU, OD loses a lot there.
And if you’re using a FIFO cache, threading a regular dict through a separate fifo (whether linked list or deque) is more efficient in my experience of implementing both S3 and Sieve.
-- masklinn Reply - OrderedDicts have some convenience methods and features that ordinary dicts don't have.
-- heavyset_go Reply - Also, dicts can become unordered at any time in the future. Right now the OrderedDict implementation is a thin layer over dict, but there are no guarantees it’ll always be that.
-- rbanffy Reply - Not true as of 3.7[0]
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
[0] https://docs.python.org/3.7/whatsnew/3.7.html
-- 3eb7988a1663 Reply - dict are ordered to keep argument order when using named arguments in function calling. So it would be a non-trivial breaking change to revert this now.
I would argue that OrderedDict have more chances to be depreciated than dict becoming unordered again, since there is now little value to keep OrderedDict around now (and the methods currently specific to UnorderedDict could be added to dict).
-- SuchAnonMuchWow Reply - They can, but ordered dict can also become unordered in the future, should the steering committee decide.
But seriously: It’s no longer an implementation detail that dictionaries are ordered in Python. It’s a specification of how Python works.
-- wodenokoto Reply - There in lies another reason why OrderedDicts are still useful even in 3.12
-- judicious Reply - Do you have any examples?
-- wodenokoto Reply - Check out the docs: https://docs.python.org/3/library/collections.html#collectio...
-- heavyset_go Reply - I work with different versions of Python3 (and 2 unfortunately) and some code is still in 3.6, hence I used OrderedDicts.
-- judicious Reply - 3.6 was the first with the new ordered by default dicts, even though wasn't specc'd until 3.7.
-- mixmastamyk Reply - It worked as an accidental implementation detail in CPython from some other optimization, but it wasn't intentional at the time. Because it wasn't intentional and wasn't part of the spec, that code could be incompatible with other interpreters like pypy or jython.
-- Izkata Reply - pypy implemented naturally ordered dict before cpython did.
jython never released a P3 version so is irrelevant, ironpython has yet to progress beyond 3.4 so is also irrelevant.
-- masklinn Reply - See my comment and the linked email at https://github.com/ericvsmith/dataclasses?tab=readme-ov-file... for dataclasses and 3.6. I think it's still true.
-- ericvsmith Reply - The reason Guido didn't want 3.6 to guarantee dict ordering was to protect 3.5 projects from mysteriously failing when using code that implicitly relied on 3.6 behaviors (for example, cutting and pasting a snippet from StackOverflow).
He thought that one cycle of "no ordering assumptions" would give a smoother transition. All 3.6 implementations would have dict ordering, but it was safer to not have people rely on it right away.
-- raymondh Reply - My faves are the lru_cache, namedtuples, deques, chainmap, and all of the itertools.
-- mont_tag Reply - The following are identical
fractions.Fraction(numerator=1, denominator=3)
fractions.Fraction(1) / 3
ChainMap is maybe better described/used as inheritance for dicts, where something likesettings = ChainMap(instance_settings, region_settings, global_settings)
would give you one object to look in.
-- nick238 Reply - If you liked this blog post, I can’t recommend PyMOTW[0] highly enough. It’s my goto for a concise introduction whenever I need to pick up a new Python stdlib module.
[0]: https://pymotw.com/3/
-- brianyu8 Reply - MappingProxyType is another handy one. It wraps a regular dict/Mapping to create a read-only live view of the underlying dict. You can use it to expose a dict that can't be modified, but doesn't need copying.
https://docs.python.org/3/library/types.html#types.MappingPr...
-- h4l Reply - > For people eager to join the AI/ML revolution it provides Naive Bayes classifier - an algorithm that can be considered a minimum viable example of machine learning.
I don't think this is true. It allows you to specify and calculate parameters for normal distributions, what allows you to jury rig a naive bayes classifier, what is shown as a doc example. This is not the same as providing a built in classifier.
-- Qem Reply - I just discovered graphlib.TopologicalSorter the other day.
Nice! When you need it, you need it. It's nice not to have to implement it oneself.
-- dairiki Reply - > file_url = 'file://' + os.path.realpath('test.html')
You have to encode the file name!
file_url = 'file://' + urllib.parse.quote(os.path.realpath('test.html'))
-- teddyh Reply - Some modules are essential additions while others are handy so as not to have to manage dependencies.
Good example of the latter use case is the statistics module.
There is a price to pay though: its performance is 10x slower than numpy. So its mostly useful when the required calculation is not a bottleneck.
The benefit is you are good to go (batteries included) without any virtual environmemts, pip's etc.
-- openrisk Reply - Throwing frozensets out, too. If regular sets aren't obscure enough, frozensets might be your thing. It looks like a set, it acts like a set, but its... hashable (for indexing) and (immutable.) Why use this? For algorithms that rely on combinations (not permutations), frozensets can be very useful. E.g. NOT this -- (0, 1) (1, 0) (both distinct using tuples) vs frozenset([0, 1]) ([1, 0] or [0, 1] have the same identity / frozenset.) You can use this for indexing algorithms and things like that. Sometimes, sets are very convenient because they naturally 'normalise' entries into a fixed order. This can simply a lot of code.
-- Uptrenda Reply