The problem is this reduces usability for others. Yes, there are many local to a country sites, but there are also large scale global ones. In both cases, you're not really gaining anything other than some clever autocomplete that could be far more precise if the site offered the correct fields so that whatever autocomplete tooling I use can put the data in for me.
The page itself specifically says "and country", however that too doesn't work. Other non us countries may have the same postal codes, or in my case mine is 4 digits, and I had to figure out that "oh, this is us only and it doesn't work at all for me", which was just entirely a waste of time.
Pulling exact quotes out, SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item" while MAY means "an item is truly optional."
I don't think this can be interpreted as simply "should is optional".
Well… yes… no… SHOULD means that you must either do the thing or understand the consequences of not doing it. That's not simply optional, the two options are to ① spend time on writing code and ② spend time on learning the consequences. Either way you need to think hard and spend time. And that's why the definition of SHOULD includes the word "must".
> but the full implications must be understood and carefully weighed before choosing a different course.
In other words, you better have a damn good reason for deciding not to do it.
And (possibly even more to the point), you must decide not to do it, rather than simply throwing code at the wall until most emails make it through unscathed.
I think that is a bit to easy. MAY is described ar optional.
SHOULD - Should really be there. It's not MUST, you can ignore it but do not come crying if your email is not delivered to some of your customers !
you should have though about that before.
Thanks for the that bit of info! I was surprised by the speed difference. I have always assumed that most variations of basic string formatting would compile to the same bytecode.
I usually prefer classic %-formatting for readability when the arguments are longer and f-strings when the arguments are shorter. Knowing there is a material performance difference at scale, might shift the balance in favour of f-strings for some situations.
Working on some tailored to my needs tax reporting software. I submit claims to my workplace in batches under a number of different categories. Using this as an excuse to get better at some bits of SQL, leaning Textual as well, which I'm hoping to use in other things. Other than that I'm cooking a few IRC bots that I swap to when the other code becomes a bit too boring
For "applications" (which are distributed on PyPI but include specified entry points for command-line use), yes. For development — installing libraries that your own code will use — you'll still generally need something else (although the restriction is really quite arbitrary).
Agreed! Sorry my read was for apps. You can use --user with pip to install into the user site rather than the system site, however it still causes overlap which can be problematic
Without significant language changes, this is not possible. While your code may be typed as an int, I can simply redefine what int means. I can also modify the code in your method.
I guess it would work with the ongoing jit work, which (as far as I understood..) run the code "as usual", then notice that a specific variable is always a dict (or whatever). Then it patches the code to run the dict-optimized code by default (and fallback to the generic code if, somehow, the variable is no longer a dict).
With typing, the generic code could be avoided altogether. The algorithm would be:
- notice that some variable can be processed by a dict-optimized code (because its typing is a dict, or something that looks like a dict etc)
- when processing, check that the variable is indeed a "dict", raise an exception if not
- run the optimized code
- if the typing information changes (because the class has been redefined and the variable is no longer a "dict"), then go to step 1 and either stick with the current optimized code, use another one, or use the generic one
This would:
- enforce types (you said that variable is a Thing but a Thing was not given: exception)
- improve the jit by removing the bootstrap phase (where the jit watches and then try to guess what could be improved)
(or perhaps this is a stupid idea that cannot work :) )
On shared branches I prefer to send pull requests, that way I can rework my draft and respond to review comments until it's ready, without pushing undercooked commits directly on the shared area
What lands on the shared branch has a meaningful history, that has helped me more than once to understand the context in which an old change was made, when running git blame many months later.
I feel like it should be as easy to review the history as it is to review a PR. Squashing makes this a bit harder for me. Especially when autosquash loses long commit messages.
But I like to use git-absorb to automatically create fixup commits, it generally works pretty well and saves me a little bit of tedium each time!
The page itself specifically says "and country", however that too doesn't work. Other non us countries may have the same postal codes, or in my case mine is 4 digits, and I had to figure out that "oh, this is us only and it doesn't work at all for me", which was just entirely a waste of time.