Million-inhabitants city nearby: burns to the ground due to garbage guidance
President: …dig out the plan for world war 3, I guess.
There were mobile phones before the iphone. Like a whole ecosystem even! They even had screens! and browsers! and internet!
the major innovation the iphone brought was a touch screen (and a decent camera), which sort of existed, but nothing as smooth and crisp as the iphone. please i really hope people out there dont think the iphone was the invention of the cell phone.
Until people decide that reality is better than the unreality of phones, this kind of willful ignorance will continue.
So I uninstalled it and now my wsl prompt starts with (base) and I don't know how to disable it and all my python scripts are broken because they can't find all the libraries I've installed from pip throughout the years.
0/10 would not recommend.
Also, in case of pathlib, it adds no value on top of os.path of which it is a wrapper. Instead, it made the original library it wraps worse, because now os.path also needs to know about pathlib to be able to handle path fragments represented as pathlib instances.
All in all, it offers very little utility (a handful of shortcuts) vs increasing the size and memory footprint of "standard" library, complicating dispatch and therefore debugging... it's a bad trade.
Just not to get you confused. It's not an awful trade. It's not like the sky will fall down on you if you use it. It's just mostly worthless, with negligible downsides.
Windows' APIs use UTF-16 and most file name encodings on Linux are UTF-8. How should Python handle this better?
> Also, in case of pathlib, it adds no value on top of os.path of which it is a wrapper.
Completely disagree. os.path is annoying to use. Treating paths as objects with methods and joining them with / makes my life much easier.
> increasing the size and memory footprint of "standard" library
By a ridiculous amount. pathlib is just another pure Python module with a bunch of simple functions and classes. [1]
> complicating dispatch and therefore debugging
You can simply declare and accept `Union[str, os.PathLike]` and convert the paths to whatever you want at the entrypoints, then use that in your own project. Where is the complexity? I've never seen this make debugging harder, it's just an additional type.
[1] https://github.com/python/cpython/blob/d9fc15222e96942e30ea8...
I don't see it. I think all the other browsers just had to become light and fast too. Even Microsoft was forced to say goodbye to IE, and instead based Edge on Chromium. And tech people were eventually able to switch back to Firefox because it got much faster too.
Google wanted a world where all browsers were light and fast in order to efficiently run complex webapps -- and they achieved that. Kudos.
The original Chrome just felt like a barebones window to the Internet. Though I agree that Firefox et al. became much less sluggish over time. (Is that only their performance improvements or did hardware get better faster than they grew?)
Also maybe "light" and "fast" shouldn't be lumped together. Chrome can definitely be fast when it has enough resources. That and sandboxing seem to make it much _heavier_ in RAM.
Simple example: a function has a parameter whose type is "variable-length tuple of int". You can pass any tuple in that is known to have 0..n elements, all of type int. What would you have me call that, other than the name I've seen used in discussions on this feature?
> "Arbitrary" doesn't really help because it could refer to the elements' values, to their types, or to the tuple's length.
Read it as (arbitary (fixed-size tuples)). It was meant to forgo answers describing functions with known tuple sizes.
And n is fixed at the calling site, right? I wonder if something like "TypeVar, but for a list of type arguments" could solve your problem.
What's funny is that this is already kind of implemented in `typing.Concatenate`, but only for function parameters [1], not for type hint parameters.
Anyway, I would have written "a well-typed function that concatenates two arbitrary tuples whose size is statically known at the call site". Can't really remove "at the call site" or "statically known" without being ambiguous.
Edit: just found out about `TypeVarTuple`. So really we're only missing `concatenate`.
[1] https://docs.python.org/3/library/typing.html#typing.Concate...
I am a fullstack developer living in Norway. Last year I registered the Norwegian branch of the Architectural Uproar as a not for profit organization. With the support from paying members, I have been able to go on tour to most of the major cities in Norway. We organize large meetings were we discuss architecture and city planning with politicians, architects and property developers on stage.
I am strongly inspired by Create Streets in UK and Strong Towns in the US. I want to improve people’s quality of life, help saving the planet and make Norway beautiful again while doing it.
https://arkitekturopproret.no edit: typos