raymondh

Joined 16 years ago

Karma

2,430

Submissions

381

Member since

Feb 9

Highlights:

  * CEO of Mutable Minds, Inc. (a training and consulting company)
  * Python Distinguished Service Award
  * Past Python Software Foundation (PSF) board member
  * Private pilot (single engine land and sailplanes)
  * Certified Public Accountant
  * Certified Internal Auditor
  * Python Core Developer
  * Husband to Rachel
  * Father to Matthew

Python training video series, "Modern Python: Big Ideas, Little Code" available for free to Safari On-line subscribers: https://www.oreilly.com/library/view/modern-python-livelessons/9780134743400/

Videos for conference presentations and keynotes can be found at: https://www.youtube.com/playlist?list=PLRVdut2KPAguz3xcd22i_o_onnmDKj3MA

Contributions to Python:

  * any()
  * all()
  * enumerate()
  * local mapping argument to exec() can be any mapping
  * filter() -- originally itertools.ifilter
  * frozenset()
  * map() -- originally itertools.imap
  * reversed()
  * sum() -- optimized and made more accurate
  * zip() -- originally itertools.izip
  * sorted()
  * set()
  * dict.fromkeys
  * dict.pop
  * float.as_integer_ratio
  * str.format_map
  * str.partition
  * str.rpartition
  * tuple.count
  * tuple.index
  * abc.ABC
  * antigravity.geohash 
  * bisect module -- key function support
  * calendar module -- various fixups
  * collections.ChainMap
  * collections.Counter
  * collections.OrderedDict
  * collections.deque
  * collections.namedtuple
  * contextlib.redirect_stderr
  * contextlib.redirect_stdout
  * contextlib.suppress
  * decimal module
  * difflib.context_diff
  * difflib.unified_diff
  * fractions.limit_denominator -- with Mark Dickinson
  * functools.cache
  * functools.cmp_to_key
  * functools.lru_cache
  * functools.total_ordering
  * heapq.heappushpop
  * heapq.merge
  * heapq.nlargest
  * heapq.nsmallest
  * itertools.accumulate
  * itertools.chain
  * itertools.chain.from_iterable
  * itertools.combinations
  * itertools.combinations_with_replacement
  * itertools.compress
  * itertools.count
  * itertools.cycle
  * itertools.dropwhile
  * itertools.filterfalse
  * itertools.groupby
  * itertools.islice
  * itertools.pairwise
  * itertools.permutations
  * itertools.product
  * itertools.repeat
  * itertools.starmap
  * itertools.takewhile
  * itertools.tee
  * itertools.zip_longest
  * json.AttrDict (later removed)
  * math.dist
  * math.fsum -- with Mark Dickinson
  * math.hypot -- improve algorithm and expanded to n-dimensional case
  * math.log -- added the "base" optional argument
  * math.prod -- implemented by Pablo Galindo
  * operator.attrgetter
  * operator.itemgetter
  * queue.LifoQueue
  * queue.PriorityQueue
  * queue.join
  * queue.task_done
  * random's MersenneTwister
  * random.SystemRandom
  * random._randbelow
  * random.binomialvariate
  * random.choices
  * random.sample
  * random.triangular
  * statistics.correlation -- added spearman rank correlation coefficient
  * statistics.fmean
  * statistics.geometric_mean
  * statistics.harmonic_mean -- added weights parameter
  * statistics.kde
  * statistics.kde_random
  * statistics.linear_regression -- added direct proportion option
  * statistics.mode -- fixed api
  * statistics.multimode
  * statistics.NormalDist
  * statistics.quantiles
  * statistics.variance/pvariance/stdev/pstdev -- correctly ounded
  * tokenize.untokenize
  * userdict.DictMixin -- eventually became ollections.MutableMapping
  * __slots__ can be a dictionary

Designer of:

  * key-functions
  * generator expressions
  * compact and ordered dictionaries
  * the peephole optimizer
  * __length_hint__ optimization
  * the thousands separator in string formatting
  * original proponent of exception chaining
  * original proponent of sending data and exceptions into enerators
  * eval-loop opcode prediction

Maintainer of:

  * the argparse module (successor to Steven Bethard)
  * the bisect module
  * the collections module
  * the collections.abc module
  * the decimal module
  * the heapq module
  * the itertools module
  * the queue module
  * the random module
  * the statistics module (with Steven D'Aprano)

Author of:

  * Python How-to: Descriptor Guide
  * Python How-to: Sorting Techniques
  * Python tutorial: Looping Techniques
  * Python tutorial: Tour of the standard library
  * Python tutorial: Floating Point Arithmetic
  * Blog post: Super Considered Super
  * Whatsnew 3.1
  * Whatsnew 3.2
  * Whatsnew 3.8

Social media:

  * https://twitter.com/raymondh
  * https://rhettinger.wordpress.com/
  * https://www.facebook.com/raymondh
  * https://www.linkedin.com/in/raymondhettinger/
  * https://stackoverflow.com/users/1001643/raymond-hettinger

View on Hacker News

Recent submissions

Comment · 5 months ago

In the 1990s, I briefly met Cleve while taking a two-week Matlab course in Natick. During that course that a classmate introduced me to Python, a language where I later became a core developer.

Cleve's papers were an inspiration. I soon published my own matrix package called matfunc. That work was heavily influenced by Cleve Moler and by algorithms in Golub and Van Loan. Even my more recent Python contributions, like the super accurate math.fsum(), math.hypot(), and math.sumprod() functions, have their roots in that fertile time in the Matlab ecosystem. In particular, it newsgroups and lists of papers taught me Cleve's never ending quest to create clean front-ends for numerically sophisticated code.

Thank you Cleve. Your legacy will live forever.

Comment · 2 years ago

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:

    The Zen of Python, by Tim Peters

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

Also, he is the author of the famous TimSort algorithm: https://en.wikipedia.org/wiki/Timsort

Comment · 2 years ago

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.

Comment · 2 years ago

Thank you AnandTech. Happy ride in to the sunset.

Comment · 2 years ago

Is there a simple R example for Rule 4?

Comment · 2 years ago

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.

Comment · 2 years ago

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.

Comment · 2 years ago

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.

Comment · 2 years ago

Programming Pearls, Thinking Forth, The Little Schemer, and SICP

Comment · 2 years ago

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.

Comment · 2 years ago

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

Comment · 2 years ago

Perhaps Google's AI included TheOnion in its training data:

https://www.theonion.com/geologists-recommend-eating-at-leas...

Comment · 2 years ago

Numeric towers are indeed a sore point.

* There are more 64-bit integers than C floats/doubles. But in math, reals are a superset of the integers.

* Because floats are rounded, `x < x + 1`, is not an invariant.

* The possibility of a `NaN` value means that the assignment `y = x` does not guarantee that x and y are equal.

* Floats are implemented as binary fractions, so they are actually rationals.

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.

Only when inheritance is added to the mix does it get dicey. As a tool for code reuse, it is not a bad idea. I think the central problem is that people want more from inheritance that it has to give (especially if you expect that children are always substitutable for their parents).