Yeah, I don’t think I’ve seen them at restaurants, but I have seen them at convenience stores a ton. Why they didn’t have the flavor shots has always confused me, because that has been the difference between me getting a soda and not.

you’d have to know the ideal ratio of syrup to base soda

One pump or two, depending on preference.

We also have some built in to the machine, and I’ve seen it right next to the machine as well as a separate pump.

I mention ebikes because if we’re in an apocalypse situation, your solar panels may not be very efficient. There are a ton of electric motors out there, so generating power is totally feasible in a prepper situation even if the sky is torched Matrix style, just attach any electric motor to a bicycle and you’re good to go (or water or wind turbine, etc).

Ah, lol. 🤦

You forgot “taxes.”

That doesn’t take much power, a solar panel or two should be more than sufficient, or you can rig something up w/ a defunct ebike (just run the motor backwards to generate electricity).

Eh, that’s just called getting old. Sorry for your loss.

No, and soda isn’t tea anyway. Not sure what you’re getting at.

you necessarily provide the reader with fewer hints as to what is actually in that variable

Then make it explicit. I much prefer this:

def do_foo(bar: list | None):
    if not bar:
        return
    ...

This one communicates to me that the function only makes sense with a non-empty list.

To this:

def do_foo(bar):
    if len(bar) == 0:
        return

This just tells me bar is something that has a length (list, dict, str, etc).

And this is way worse:

def do_foo(bar: list | None):
    if len(bar) == 0:
        return

This tells me we want an exception if bar is None, which I think is bad style, given that we’re explicitly allowing None here. If we remove the | None and get an exception, than the code is broken because I shouldn’t be able to get that value in that context.

If I care about the difference between None and empty, then I’ll make that explicit:

if bar is None:
    ...
if not bar:
    ...

In any case, I just do not like if len(bar) == 0 because that looks like a mistake (i.e. did the dev know it could throw an error if it’s not a list? Was that intentional?).

Same with dictionaries, iterators (will consume the iterator!), and anything else that has a length.

I’ve actually had the string instead of list issue a number of times, because sometimes things get off and it’s hard to track down where things went wrong.

For this reason, I think type hints are the way to go. Use them consistently w/ a static analysis tool like pyright and you’ll catch a lot of these issues before running into cryptic error messages.

Do you not have those syrup things? Pretty much every gas station has one.

Nah, that’s different. Water man is the grown up version of the water boy.

Almost any gas station has those syrup pumps, and here in Utah, we have a soda shop (like Swig) on almost every corner.

It’s only vague if coming from a language where it’s invalid or vague semantically. For example:

• Javascript - [] is truthy for whatever reason
• C - int x[] = {}; evaluates to true because it’s a pointer; C only evaluates to false if something is 0
• Rust - invalid because you cannot convert a vec -> bool directly, and there’s no concept of null (same w/ Go, but Go has nil, but requires explicit checks)
• Lua - empty tables, zero, and empty strings are truthy; basically, it’s truthy unless it’s nil or false

The only surprising one here is Javascript. I argue Lua and Python make sense for the same reason, Lua just decided to evaluate truthiness based on whether the variable is set, whereas Python decided to evaluate it based on the contents of the variable. I prefer the Python approach here, but I prefer Lua as a language generally (love the simplicity).

You’d need some kind of account system, but you could probably get away with just signing your edits. If the same key is used to sign an edit, then it can be considered the same “user” even if there’s no persistent account associated w/ it. You’d need to register a public key, but that’s about it.

It’s probably different for lawyers since they tend to work in firms and work as peers (partners) instead of just being regular employees. Even so, I would assume a “thank you” email would still not be expected, but perhaps a follow-up to ask about the status if there’s no response after a couple days.

Exactly. Uncertainty leads to higher prices, because businesses need to weather potential higher costs to them. Protectionism leads to higher prices, because it cuts out foreign competition, and competition is what leads to lower prices.

Louis Rossmann is 100% correct here IMO.

They’re really not. They’re completely unrelated.

The notion of truthiness is defined by the language.

Here are most of the built-in objects considered false:

• constants defined to be false: None and False
• zero of any numeric type: 0, 0.0, 0j, Decimal(0), Fraction(0, 1)
• empty sequences and collections: ‘’, (), [], {}, set(), range(0)

It’s not something that happens to work, it’s literally defined that way.

if not x is the common way to tell if you have data or not, and in most cases, the difference between None and empty data ([], {}, etc) isn’t important.

len(x) == 0 will raise an exception if you give it None, and that’s usually not what you want. So I guess the verbose way to do that is if x is None or len(x) == 0:, but that’s exactly equivalent to if not x, with the small caveat that it doesn’t check if the value has __len__ implemented. If you’re getting wonky types thrown around (i.e. getting a class instance when expecting a list), you have bigger problems.

I use type hinting on pretty much all “public” methods and functions, and many of my “private” methods and functions as well. As such, sending the wrong types is incredibly unlikely, so not x is more than sufficient and clearly indicates intent (do I have data?).

len(mylist) tells me it’s definitely a list and not null or whatever

Do you know what else can tell you it’s a list? Type hinting.

If I care about the distinction between None and an empty list, I’ll make separate checks. len(None) raises an exception, and most of the time that’s not what I want when checking whether there’s something in the list, so not x is generally preferred, especially when type hinting is used consistently enough to be reasonably sure I’m actually getting a list or None. If I get something else, that means things got really broken and they’ll likely get an exception alter (i.e. when doing anything list-like).

For sequence type objects, such as lists, their truth value is False if they are empty.

That’s generally exactly what I want. len(x) == 0 doesn’t tell you it’s a list, it just tells you it has __len__. So that could be a dict, list, or a number of other types that have a length, but aren’t lists.

Don’t rely on checks like that to tell you what type a thing is.