so putting batteries in the fridge wasn’t useful after all, we should put them in the oven

spreading like cancer

did someone just explain to this guy the half a century old tech scanning tunneling microscope that uses quantum tunneling for imaging

“We will have AI agents that run the network with no manual intervention.”

Sounds hard to believe.

billionaires are a systematic risk to the tech industry.

FFY

good point I try to initialize None collections to empty collections in the beginning but not always guaranteed and len would catch it

this screenshot looks more like the beginning of something else. I wonder where they trained their AI model on hmm…

It is not “assume” as in a conscious “this is probably a bool I will assume so” but more like a slip of attention by someone who is more used to the bool context of not. Is “not integer” or “not list” really that commonly used that it is even comparable to its usage in bool context?

If there is an alternative through which I can achieve the same intended effect and is a bit more safer (because it will verify that it has len implemented) I would prefer that to commenting. Also if I have to comment every len use of not that sounds quite redundant as len checks are very common

I feel like that only serves the purpose up to the point that methods are not over reaching otherwise then it turns into remembering what a method does for a bunch of unrelated objects.

seems like they are running out of funny things to say

I don’t know, it throws me off but perhaps because I always use len in this context. Is there any generally applicable practical reason why one would prefer “not” over len? Is it just compactness and being pythonic?

isn’t the expected behaviour exactly identical on any object that has len defined:

“By default, an object is considered true unless its class defines either a bool() method that returns False or a len() method that returns zero, when called with the object.”

ps: well your objection is I guess that we cant know in advance if that said object has len defined such as being a collection so this question does not really apply to your post I guess.

Well fair enough but I still like the fact that len makes the aim and the object more transparent on a quick look through the code which is what I am trying to get at. The supporting argument on bools wasn’t’t very to the point I agree.

That being said is there an application of “not” on other classes which cannot be replaced by some other more transparent operator (I confess I only know the bool and length context)? I would rather have transparently named operators rather than having to remember what “not” does on ten different types. I like duck typing as much as the next person, but when it is so opaque (name-wise) as in the case of “not”, I prefer alternatives.

For instance having open or read on different objects which does really read or open some data vs not some object god knows what it does I should memorise each case.

If anything len tells you that it is a sequence or a collection, “not” does not tell you that. That I feel like is the main point of my objection.

well it does not imply directly per se since you can “not” many things but I feel like my first assumption would be it is used in a bool context

Yea and then you use “not” with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. Moreover “not” will not throw an error if you don’t use an sequence/collection there as you should but len will.

You should not sacrifice code readability and safety for over optimization, this is phyton after all I don’t think list lengths will be your bottle neck.

since at least 10 years by now

well because when you say things like “it plans ahead” or “our method is inspired by brain scanners” etc it makes a connection between AI and real thinking and generates hype.