I wonder if it's similar to embedded software development (which also requires "rigorous working methods"). Salaries for embedded are generally lower than for web development because there's much less demand for embedded skills.
Embedded software development has improved over the past years reasons being more silicon/asics in vehicles and other places, autonomous driving needs, robotics in supply chain, IOT, smart home. There are lot of opportunities for embedded sw these days.
Spot on. Static typing has benefits, but it also has a cost. Python's optional type hints have all the complexity but only some of the benefits - in my experience, runtime type errors are still common.
> To me it feels like python is running as far away from simplicity as fast as possible.
Despite its reputation, Python hasn't been a simple language for a long time.
There really is a cost, in the form of having to rerun code a dozen more times to catch unresolved type errors. But AFAIK, that's it. Can I ask what I'm missing? What cost of this (optional) static typing are folks talking about?
IMO this is worth it, since the goal is less about eliminating runtime errors or other errors, and more about encouraging documentation in code rather than in comments/docstrings. This makes reading code simpler, not less so.
In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2].
Thanks for the links! Those fully specified frankentypes are indeed atrocious, and no sane person should ever need to read them. That being said, isn't "Any" meant to act as a wildcard, used precisely for ignoring the unimportant parts of the type? Specifying huge and rigorously correct types just seem like an eager misuse of type hints to me.
At the same time, adding the capabilility for complexity the language does encourage complexity, doesn't it? (Rust comes to mind.) So I admit what I just said isn't much of an argument -- frankentype hints _will_ be written, and therefore we _will_ have to suffer them someday...
[2] is (1) horrifying, and (2) descriptive of something Python is really good at (handling complexly-typed input datasets without requiring complex declarations).
The solution to that code is to remove the type hint, because you don't need it, because it simply describes the type of the input data.
edit: Several far better Python developers than I also said as much in the tweet replies.
Does anyone think it is a good idea to accept anything with a __str__ in requests.get? That seems like an awful idea. I am more of a dynamically but strict kind of guy, and this seems like a good way to get weird behaviour.
> the actual creator of the language was so against the addition of this operator that he saw the community’s insistence on it as reason to step down as BDFL.
That's backwards. The community was generally opposed to the walrus operator, and Guido stepped down because of (among other things) the community's reaction when he insisted on adding it.
I'm on Guidos side. When it's well used, it's a good thing -- problem is getting people to use it right. But the fact that many people didn't consider the use cases that were being proposed, immediately took strong and toxic positions about it, and were more interested in calling names rather than having a civilized discussion is what wore down the (then) BDFL and caused him to step down.
I think Python’s direction changed when Guido moved to Dropbox. Suddenly he was working on a million-line Python codebase, and started working to make the language more suitable for programming in the large.
Python's principle is not an has never been "one way to do it". Python's principle is:
> There should be one — and preferably only one — obvious way to do it.
Which is a very, very different assertion. And there remains one — and exactly only one — obvious way to do an assignment, because the walrus operator is literally invalid syntax as a statement:
That principle was bullshit anyway. There have always been multiple ways to do things, the one way was just whatever the elder Pythonista deemed to be pythonic that day.
Not true. The language optimizes for the way it is intended to be used, and changes remain sensitive to those optimizations.
"Pythonic" means intended usage, and "unPythonic" is shorthand for "you found another way to do it that kinda does what you want but (is ten times as slow/takes up ten times as much memory/doesn't work for edge-cases/has more unintentional side-effects) because it wasn't the intended usage, which is fine for your own personal projects, but please don't bring that into my code base, and pretty please don't teach other people to do it that way..."
In my work we have code in many places along the lines of:
data = expensive_function(blah, blah_blah)
if data:
# many lines of processing
data = expensive_function(blah, blah_bah)
And seen a lot of times where newcomers forget the assingment at the end that makes everything move. So yeah, the walrus version would be a lot simpler:
while data := expensive_function(blah, blah_blah):
# process data
This is just one of the "edge cases" where the walrus makes sense.
Braces in Python would have issues, e.g. ambiguity with set/dict literals. Most similar languages (except JavaScript) seem to use begin/end instead. Would that be more acceptable than significant indentation?
"Effect and exception" is bad, but its a special case of a more general bad design - the fact that `a += b` is sometimes equivalent to `a = a + b` and sometimes changes in-place.
I came across this recently, when writing a blog post about a puzzle I solved. I wasn't sure whether to structure the post "chronologically", telling a story:
1. Here's an interesting puzzle.
2, 3, 4, 5. These are the steps I took to solve it.
6. Hence the solution is X.
or using BLUF:
1. Here's an interesting puzzle.
2. I found the solution is X.
3, 4, 5, 6. These are the steps I took to find that solution.
I'm still not sure which structure would be the best choice in which situation. Are there any guidelines?
0. Statement of fact that constitutes the solution.
1. Here's the issue
2. The solution is X because (preview of analysis.)
3, 4, 5, 6. This is how we determined that.
Imagine that your BLUF is a tweet announcing your findings and linking to a PDF of the rest of your e-mail.
Example:
BLUF: CONCUR, WITH CONDITIONS- The civilians may participate in the breacher training, but there are requirements to meet.
You asked whether civilian law enforcement agencies (CLEAs) may participate in breacher training on a space- and time-available basis. I have no legal objection, provided the CLEAs certify that receiving the training from commercial or other non-DoD sources would be impractical due to cost or time, and provided the request is routed for concurrence through the chain of command for approval by ASN(M&RA). Additionally, anything beyond marginal costs must be paid by the CLEAs.
Ref: (a) 10 U.S.C. § 273
(b) DoDI 1325.21
(c) SECNAVINST 5820.7C
(d) DEPSECDEF Memo of 29 Jun 96, DoD Training Support to U.S. Civilian Law Enforcement Agencies
(e) 10 U.S.C. § 2012
Authority. Reference (a) grants authority to SECDEF “to train . . . civilian law enforcement officials in the operation and maintenance of equipment.” In paragraphs 1.f and 5.c of enclosure (3) to reference (b), SECDEF granted approval authority to the service Secretaries. SECNAV issued guidance in reference (c), including the requirement for cost reimbursement beyond marginal costs. Under references (b) and (c), ASN(M&RA) – in consultation with ASD(HD&GS) – may authorize the use of up to 49 DoD personnel for training; installation commanders or commanders of unit training centers may authorize the use of DoD equipment and facilities.
Analysis. CLEAs may participate in training if all of the following criteria are met:
- Extent. The training cannot be large-scale, elaborate, or advanced military training. Advanced military training, defined in reference (d), is “high intensity training” pertaining to interactions with a “criminal suspect” or “when the potential for a violent confrontation exists.” The breacher training will satisfy this requirement.
- Resources. Non-DoD training must be unfeasible or impractical due to cost or time, and the training cannot compromise military preparedness. You indicated that we have sufficient “depth” to accommodate the CLEAs without compromising preparedness, but the CLEAs must show that non-DoD options are unfeasible or impractical.
- Role Limitations. DoD personnel must not directly participate in fundamentally civilian law enforcement operations, and there must be no reasonable likelihood of confrontation between law enforcement and civilians during the training. This is standard military training, not fundamentally civilian law enforcement-related in nature. Additionally, it is unlikely that unaffiliated civilians will be present.
Alternatives. Reference (e) authorizes “Innovative Readiness Training”; however, subsection (i) of reference (e) precludes using that authority for “civilian law enforcement purposes.” There is very little guidance as to whether that might apply for a mere training program; however, the legally safer course of action is to avoid using this authority.
Conclusion. References (a) through (d) authorize us to permit civilian law enforcement participation in our breacher training, but we must first receive a request from the civilian law enforcement participants explaining why alternatives are not feasible or practical. Additionally, the request for authorization for the training must be routed to ASN(M&RA).
