151–160 of 183 posts
Earlier quoted context omitted.
I was merely giving an example that strong typing has nothing to do with having to write the types. (and, obviously, the inferred type (int -> int) is correct. )
Only if reveal_type only accepts an int. Just because the default value of i is 0 doesn't mean anything about what could be passed in.
Good list, its one of these things you either never heard of, or used for years and think everyone knew that. I'll add a few: * did you know __init__.py is optional nowadays? * you can do relative imports with things like "from ..other import foo" * since 3.13 there is a @deprecated decorator that does what you think it does * the new generics syntax also works on methods/functions: "def method[T](...)" very cool * y…
It's not optional. Omitting it gets you a namespace package, which is probably not what you want.
> TypeVar supports binding to enforce subtypes: "TypeVar['T', bound=X]",
Using the new generics syntax you mentioned above you can now do:
def method[T: X](...)Working in the ML field, I can't hate Python. But the type system (pre-3.12, of course) cost me a lot of nerves. Hoping for a better post-3.12 experience once all libraries are usable in 3.12+. After that experience, I’ve come to truly appreciate TypeScript’s type system. Never thought I’d say that.
Hey kiddo… did you ever try something nastier? I’ve got something that will blow your mind and you’ll keep coming back You don’t know but you are addicted to types Come to the light - Haskell!
My own opinion is that Python shall remain Python, and golang, Rust and Typescript each should be whichever they are with their unique philosophy and design. I am coding in all 4, with some roughly 28 years now, and I don't like what is becoming of Python There is a reason why python become that popular and widely adapted and used, and it is not the extra layers of type checking, annotations and the likes. this looks…
Earlier quoted context omitted.
This kind of search can be done a variety of different ways, and is worth abstracting, e.g.: def first(candidates, predicate, default): try: return next(c for c in candidates if predicate(c)) except StopIteration: return default deploy_application(first(servers, Server.check_availability, backup_server))
Instead of catching the `StopIteration` exception, you can simply provide a default case to `next` : next((c for c in candidates if predicate(c)), default)
Earlier quoted context omitted.
Yeah, everybody uses it. That's partly how it ends up causing so many bugs - e.g. some user puts 0 in a text box and instead of the program reacting as if you put 0 in it reacts the same way as if no value was supplied. Then everybody loses their minds because the system suddenly started doing something it was never supposed to.
I've never had this behavior cause a bug.
Earlier quoted context omitted.
I do like the else clause with for loops. However most people are not familiar with it, and also `else:` as a keyword is confusing. I always remember it as `no break:`.
I think of it as "otherwise:"
IMO a better design would be to have a block that always executes at the end of the loop - there's even a reasonable keyword for it, `finally` - but gets a boolean flag indicating whether there was a break or not:
for server in servers:
if server.check_availability():
primary_server = server
break
finally did_break:
if not did_break:
primary_server = backup_server
for server in servers:
if server.check_availability():
break server
finally server:
primary_server = server if server is not None else backup_serverEarlier quoted context omitted.
no need to explicitly write the type if you have type inference: > # fun x -> x + 1;; > - : int -> int = >
1) the code you wrote isn’t Python. 2) inferring the type is int isn’t guaranteed to be correct in this case
That's the downside of operator overloading - since it relies on types to resolve, they need to be known and can't be inferred.
Earlier quoted context omitted.
This kind of search can be done a variety of different ways, and is worth abstracting, e.g.: def first(candidates, predicate, default): try: return next(c for c in candidates if predicate(c)) except StopIteration: return default deploy_application(first(servers, Server.check_availability, backup_server))
Great, first() comes part of more_itertools !
And yet somehow I keep forgetting about it in the exact moments when it would probably make my life easier.