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.

    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!

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.

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.

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.

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

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

* 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).

https://happyhollyproject.com/2014/04/27/flowcharts-and-song...

Comments URL: https://news.ycombinator.com/item?id=38971731

Points: 2

# Comments: 0

For example, it is a simple matter for a language to provide a list or array API that will perform bounds checking for indexed access. This simple measure would have prevented something like the HeartBleed security bug.

Comments URL: https://news.ycombinator.com/item?id=38643560

Points: 2

# Comments: 0

    from random import Random
    from math import ldexp

    class FullRandom(Random):

        def random(self):
            mantissa = 0x10_0000_0000_0000 | self.getrandbits(52)
            exponent = -53
            x = 0
            while not x:
                x = self.getrandbits(32)
                exponent += x.bit_length() - 32
            return ldexp(mantissa, exponent)