For those who don't know the name, Tim Peters is the author of "The Zen of Python". He is the one who uniquely captured was Python is all about with this inspirational little poem:
Also, he is the author of the famous TimSort algorithm: https://en.wikipedia.org/wiki/Timsort
Readit Newsraymondh commented on Tim Peters – Dispelling Information Asymmetry tim-one.github.io/psf/ban... · Posted by u/shazeline
raymondh commented on Lesser known parts of Python standard library trickster.dev/post/lesser... · Posted by u/rbanffy
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.
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.
Thank you AnandTech. Happy ride in to the sunset.
raymondh commented on Seven basic rules for causal inference pedermisager.org/blog/sev... · Posted by u/RafelMri
Is there a simple R example for Rule 4?
raymondh commented on Python extensions should be lazy gauge.sh/blog/python-exte... · Posted by u/0x63_Problems
re: 3, Python has a native numeric array type https://docs.python.org/3/library/array.html
We should probably get rid of that. It is old (predating numpy) and has limited functionality. In almost every case I can think of, you would be better off with numpy.
raymondh commented on Python extensions should be lazy gauge.sh/blog/python-exte... · Posted by u/0x63_Problems
This is an impressive post showing some nice investigative work that isolates a pain point and produces a performant work-around.
However, the conclusion is debatable. Not everyone has this problem. Not everyone would benefit from the same solution.
Sure, if your data can be loaded, manipulated, and summarized outside of Python land, then lazy object creation is a good way to go. But then you're giving up all of the Python tooling that likely drove you to Python in the first place.
Most of the Python ecosystem from sets and dicts to the standard library is focused on manipulating native Python objects. While the syntax supports method calls to data encapsulated elsewhere, it can be costly to constantly "box and unbox" data to move back and forth between the two worlds.
We've had to contact the IRS a number of times. It was always difficult to get through. However once we did get through, the representatives were polite, professional, and really seemed to care about achieving case resolution.
raymondh commented on Ask HN: What brought back the joy of programming for you? · Posted by u/endorphine
Programming Pearls, Thinking Forth, The Little Schemer, and SICP
> I disagree with the OP that OOP is entirely flawed. The core ideas of encapsulation and messaging are a really useful organizing principle. And polymorphism beats maintaining giant case-statements.
Does OOP actually do encapsulation, messaging or polymorphism better than other languages though?
As described by Alan Kay, what OOP means is encapsulation, messaging, and late-binding.
IIRC the inspiration came from multicellular organisms. A cell "encapsulates" complexity within a cell wall. The organism as a whole works by have the cells work together via "messaging". Any shared interfaces (e.g. oxygen transpiration and nutrient absorption) can be viewed as "polymorphism".
If you buy into the definition and biological analogy, then any language that implements "encapsulation, messaging or polymorphism" actually is OOP and your question is a tautology.
You can implement quite a lot of Python's itertools in Javascript without too much trouble. For instance, https://observablehq.com/@jrus/itertools
Disclaimer: this code was written several years ago with few downstream users, not all of these are super high performing, and they have not been super extensively tested.
Your nice work on the JS itertools port has a todo for a "better tee". This was my fault because the old "rough equivalent" code in the Python docs was too obscure and didn't provide a good emulation.
Here is an update that should be much easier to convert to JS:
def tee(iterable, n=2):
iterator = iter(iterable)
shared_link = [None, None]
return tuple(_tee(iterator, shared_link) for _ in range(n))
def _tee(iterator, link):
try:
while True:
if link[1] is None:
link[0] = next(iterator)
link[1] = [None, None]
value, link = link
yield value
except StopIteration:
return