[HN Gopher] Uncommon Uses of Python in Commonly Used Libraries (...
       ___________________________________________________________________
        
       Uncommon Uses of Python in Commonly Used Libraries (2022)
        
       Author : sebg
       Score  : 79 points
       Date   : 2025-07-03 23:12 UTC (3 days ago)
        
 (HTM) web link (eugeneyan.com)
 (TXT) w3m dump (eugeneyan.com)
        
       | iamevn wrote:
       | Seems fairly standard stuff for libraries to consider. I was
       | really hoping for some weird stuff like patching bytecode or
       | implementing entire different languages as a python library.
        
         | Pinegulf wrote:
         | Sure, but "Do not deprive people the joy of discovery."
         | -Someone, not me.
        
         | ethan_smith wrote:
         | Check out Coconut (https://github.com/evhub/coconut), which
         | implements an entire functional programming language as a
         | Python superset that compiles to Python bytecode.
        
       | froh wrote:
       | thanks for resharing, interesting well written read
       | 
       | previous: https://news.ycombinator.com/item?id=32528919
        
       | pjc50 wrote:
       | I briefly thought "oh yeah, mixins, shame we can't do that in C#
       | with single inheritance" and then realized that's what extension
       | methods are for (and slightly more general).
       | 
       | I have some C# code which relies on calling an extension method
       | on a null instance, which is mildly naughty but saves a lot of
       | refactoring.
        
         | Xss3 wrote:
         | You can call methods on null instances?
        
           | pjc50 wrote:
           | You can call an extension method, because it's just fancy
           | syntax for calling a non member method with the thing before
           | the . as the first argument. If you then don't reference it
           | at all, it doesn't matter that it's null.
        
       | stephenlf wrote:
       | What a fantastic read. It's nothing groundbreaking, but it's a
       | perfect model of how to learn good patterns.
        
       | silvester23 wrote:
       | If you want to combine a mixin with a base class you have no
       | control over, just put the base class last in the inheritance
       | chain. Then it does not matter if it calls its super __init__.
        
         | Y_Y wrote:
         | And if there are two such base classes?
        
       | CmdrKrool wrote:
       | In the case of multiple base classes wouldn't it be more sensible
       | for the derived class to forego the lexical convenience of
       | super() and simply call each base explicitly? i.e.
       | BaseEstimator.__init__(self, **kwargs)
       | ServingMixin.__init__(self, **kwargs)
       | 
       | If one wants to inherit from multiple classes then they should be
       | responsible for specifying the details of how that happens. Why
       | should a base class be expected to add boilerplate just in case
       | some external consumer comes along and wants to use it in some
       | unforeseeable context?
       | 
       | That super() has a "method resolution order" seems like a fudge.
       | Now 'super' doesn't necessarily mean 'superclass' anymore at the
       | point of use. Am I missing some other hypothetical situation in
       | which super()'s MRO brings more value for the price of having to
       | know about this extra, implicit behaviour?
       | 
       | And what's funny is that in the example given, the first base
       | class not calling super() leads to the bad consequence that the
       | other base class doesn't get to set some internal state
       | (self.mode). Yet in the next section, "When to use a Mixin", it
       | advises: "A mixin is a class that [...] does not contain state"
        
         | DHRicoF wrote:
         | I could try to answer myself, but this will be far better that
         | I could express in english:
         | 
         | https://www.youtube.com/watch?v=EiOglTERPEo
        
       ___________________________________________________________________
       (page generated 2025-07-07 23:02 UTC)