I may be misunderstanding it, but the examples shown don't seem to be illustrative? It seems reasonably obvious that the prints will happen in this order in any language, because in example 1 we are explicitly (a)waiting for the child to finish, and in example 2 both of the parent prints are above the await. So I don't feel like either of these makes the point the author is trying to get across?
I agree. If you strictly follow the syntax of "Example 1" in JavaScript (calling and awaiting on the same line), the observable output is identical to Python.
I suppose the author meant to say that if you first called your async function and then later did `await` you would have different behavior.
In every language having any kind of asynchronous features you should get exactly same result. Other comments already mentioned how the example should look and how it differs.
In short: having other coroutine working and awaiting e.g. on sleep() you can get anything between „parent before” and „child start”. In Python is impossible, because child is not run as new task.
I've always found the weather argument somewhat unconvincing, because 0°C being the freezing point of water is very much a useful point of reference in weather contexts - it's roughly where one may expect iced-over pavements and rain to turn to snow! And then the higher temperatures are a question of getting used to it - 40°C instead of 100°F is very very warm, 30 is pretty hot, 20 is reasonably warm, etc.
But then I grew up with Celsius, so no wonder I'm used to it!
Yeah, frankly Celsius is very easy for weather temperatures in temperate environments. Snow and ice is approx 0, room temperature approx 20, a hot summer's day approx 30 and it won't reach 40 unless you go on holiday in a desert region. Easy to approximate on a small range (and the nominal extra precision of Fahrenheit is illusory for talking about weather anyway because you care far more about humidity and wind than sub 1 Celsius differences)
> But then I grew up with Celsius, so no wonder I'm used to it!
People confuse familiarity with intuitiveness all the damn time. It's a recurring theme in OS "ease of use" superiority debates as well as metric vs imperial. And date, time or number formats. And road signs.
But I'm never at exactly 1 atm plus the government dumps copious amounts of salt so water never actually freezes at 0°C plus so long as I memorize that 32°F is freezing it's exactly the same as memorizing 0°C is freezing.
I would say the nice thing about the metric system is as long as you convert into a base unit (i.e. Meters, Seconds, etc) then you can easily convert stuff around. But you can't! Metric uses Kilograms not Grams all the time for things like Force (Kg *m/s^2). So I still have the same problem as imperial units ...
If you can't multiple 231 by 5280 what are you going to do when you measure a length of 23.1 cm and need to multiple it by the height of 52.80 cm?
> Are you serious when you say you can't easily multiply or divide by 1000?
You have missed the point. Force is a mass * distance / time. So, if I have a 1 g weight I want to move 1 meter in 1 second then it takes 1 Newton of force. Except it doesn't because Force is actually kilo-mass * distance / time. If I need to look up (or memorize) stuff like this then the entire advantage of metric goes away because I can just memorize the imperial way as well.
It just comes down to what you're familiar with. There's certainly a benefit to everybody using Metric in the same reasoning as there's a benefit to everybody using Mandarin.
> If I need to look up (or memorize) stuff like this then the entire advantage of metric goes away
Hmmm... no?
With metric, once you know what a "meter" is, you have the distances. <milli>meter, <centi>meter, <deci>meter, ... It's one unit: the meter. And fractions of it that require trivial conversions.
With imperial, you have multiple units of distance: inches, feet, yards, football fields, miles.
The benefit of metric is that you have to memorise fewer units, period. Your example is a formula in physics. There you have to memorise F = m * a AND in which units those are (bonus if they are consistent between the formulas, of course). That's strictly equivalent between imperial and metric there.
> It just comes down to what you're familiar with.
Of course, if you're familiar with imperial and not metric, then you're better off with imperial!
> There's certainly a benefit to everybody using Metric in the same reasoning as there's a benefit to everybody using Mandarin.
That's an interesting example: Mandarin is known for being a lot harder than English. Obviously, if you grew up with Mandarin and no English, you will be more comfortable with Mandarin. But people speaking Mandarin don't insist on saying that Mandarin is not harder than English, in my experience :-).
I think in your first point the difference is between "calculation" and "conversion". For calculations, it's generally accepted that arbitrary numbers are possible and a calculator may have to come out. For conversions, it's nice to be able to say that 1250m is 1.250km - I bump into conversions much more commonly than having to do calculations, and it's nice to be able to do them in my head.
I don't think the second point is particularly valid. The SI unit is a kg - which is weird, but always consistent. All Physics units in metric involve kilograms. I will grant that it's unusual that it has a prefix, but still - if you know the 7 base SI units (including the kg), the rest follows reasonably, and conversions are trivial compared to Imperial (orders of magnitude vs arbitrary multipliers).
Fundamentally yeah, what one's familiar with is the system that feels most intuitive, but I don't think these specific arguments against metric work super well
I agree that having a reliable main environment for quick experiments is great! On Windows I just use the main Python installation as a global environment, since no system stuff depends on it, on Linux I tend to create a "main" environment in the home directory. Then I can still have per-project environments as needed (say with uv), for example for stuff that I need to deploy to the VPS.
Note that I'm mostly in the research/hobby environments - I think this approach (and Python in general, re: some other discussions here about the language) works really well, especially for the latter, but the closer you get to "serious" work, the more sense the project environment approach makes of course
https://caption.plus/ does excellent work for a couple YouTube/Nebula channels - not as exciting as the above, but they do coloured speakers, positioning to avoid in-video text, and an occasional animation to punch up a joke! I'm most familiar with their work for Tom Scott (+ the Technical Difficulties) and Jet Lag: The Game.
I was rather confused by the dictionary comprehension syntax used there, because I wasn't aware that you could write one without the ":" to delineate the key: value pair. Turns out you can, but it just creates a dict with no values stored, just the keys! This works here because the returned dict is an iterable that returns the keys on iteration, and "update" accepts an iterable of (key, value) tuples - and the keys are just that in this case. So the effect is the same as if it was a list comprehension! Just slightly more confusing
Ah, my bad! I did not know these were a thing, but that makes more sense! Teaches me a thing about only quickly trying things in an online REPL on mobile and jumping to conclusions - I forgot curly braces were also a way to denote a set
A very cool project, and a great resource for people with reduced mobility - I semi-regularly use Transport for London's station drawings (linked on this website) over the official accessibility map, which doesn't differentiate between stairs and escalators for example.
I've taken to writing complex comprehensions like this over multiple lines (which I initially thought wasn't possible!). It's still a bit awkward, but the order of "fors" is the same as if one was writing nested for loops, which makes reasoning about it easier for me.
Allowing mass machine translation of Wikipedia articles into other languages is a problem, because it floods smaller language wikis with low quality text. If a user wants machine translated pages, they can machine translate them themselves.
Interesting that the description mentions a year of training! Not something I immediately think of when I see one of these daredevil stunts, but it makes sense that he'd spend a while making sure he can reliably go through an opening of relevant dimensions
reply