I like programming and anime.

I manage the bot /u/mahoro@lemmy.ml

  • 14 Posts
  • 51 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • The first way to use it is with any type annotation: you just use it for documentation.

    # int annotation
    def add_1_to_number(x: int) -> int:
        return x + 1
    
    # callable annotation
    def printer(x: int, func: Callable[[int], int]) -> None:
        results = func(x)
        print(f"Your results: {results}")
    

    These type annotations can help document and make editors parse your code to make suggestions/auto-complete work better.

    The second way to use it is by creating a callable. A callable is an abstract base class that requires you to implement the __call__ method. Your new callable can be called like any function.

    class Greeter(Callable):
    
        def __init__(self, greeting: str):
            self.greeting = greeting
    
        def __call__(self, name: str):
            print(f"{self.greeting}, {name}")
    
    
    say_hello = Greeter("Hello") # say_hello looks like a function
    say_hello("jim")  # Hello, jim
    








  • This doesn’t help for Gmail. I moved to a different part of the country and I have a spam email account that isn’t connected to a phone or second email. Even with the right password, it wouldn’t let me log in because I was trying to sign in from a different location and no secondary way to authenticate.

    Luckily it was a spam email so it was just annoying to recreate some accounts I used for that email, but yeah ve warned.








  • Most of us have bad memories of over-complex hierarchies we regret seeing, but this is probably due to the dominance of OOP in recent decades.

    This sentence here is why inheritance gets a bad reputation, rightly or wrongly. Inheritance sounds intuitive when you’re inheriting Vehicle in your Bicycle class, but it falls apart when dealing with more abstract ideas. Thus, it’s not immediately clear when and why you should use inheritance, and it soon becomes a tangled mess.

    Thus, OO programs can easily fall into a trap of organizing code into false hierarchies. And those hierarchies may not make sense from developer to developer who is reading the code.

    I’m not a fan of OO programming, but I do think it can occasionally be a useful tool.



  • If the work I’m doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.

    Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I’d much rather create feature branches that merge into main.