LWN: Comments on "Not coalescing around None-aware"

Not coalescing around None-aware

Wol — Sat, 25 Feb 2023 12:14:18 +0000

> decent tool in the hands of competent tool

Whoops ...

decent tool in the hands of a competent expert

Cheers,
Wol

Not coalescing around None-aware

Wol — Sat, 25 Feb 2023 11:18:41 +0000

Was the guy who ported it a Fortran programmer?

Written by a guy who understood programming, that sheet was probably a well designed database with a programming language. Everything needed to do a good job.

There are far better tools out there, but a decent tool in the hands of competent tool can get you far ...

The right tool in the hands of an expert, well that's another kettle of fish!

Cheers,
Wol

Not coalescing around None-aware

donald.buczek — Sat, 25 Feb 2023 07:42:47 +0000

> The lack of major fires, explosions, and large-scale power cuts in the 1990s suggests that this crazy lash-up did in fact work.

This is a single example and it is diffucult to research how many (if any) problems were caused by this choice.

See https://thenextweb.com/news/excel-autocorrect-errors-plag... down to "Spreadsheet catastrophes" for some counter-examples.

Not coalescing around None-aware

nix — Sat, 25 Feb 2023 00:17:42 +0000

I am reliably informed that for a number of years in the 1990s the system that decided how to route high-voltage power across the UK was... an Excel spreadsheet (translated from creaky old Fortran by a friend of mine).

The lack of major fires, explosions, and large-scale power cuts in the 1990s suggests that this crazy lash-up did in fact work.

Not coalescing around None-aware

sammythesnake — Sun, 15 Jan 2023 18:08:11 +0000

You'd probably like Julia [0], then, it allows Unicode in identifiers and lets you do things like

> for x ∈ Y

(which you can also spell "for x in Y" if you prefer)

and groks "≠" & "≥" as alternate spellings of "!=" & ">=" and so on. ("🫖≠☕" might be perfectly valid code :-P)

The REPL, Jupyter notebooks, and IDEs with support all expand LaTeX escapes for you (e.g. "\in[tab]" becomes "∈" and similarly for all the fun Greek letters / logic symbols / alchemical symbols / emojis etc.) so you don't need a fancy million-key keyboard :-D (Or you can map right-Alt to the compose key if you like)

Personally, I don't have a mathematics background and find many of these symbols somewhat opaque - it doesn't help that they're difficult to Google (but then so are all the punctuation marks that get so much use in programming language syntax!)

It's also an interesting language in its own right that I'm toying around with...

[0] https://julialang.org/

Not coalescing around None-aware

flussence — Thu, 05 Jan 2023 23:08:27 +0000

".?" would be yet more self-evident than "?.", because it reuses the existing PCRE "none or one" construct.

Anyway it's a bit absurd to reject these proposals on the basis of "too Perlish". Being like Perl would entail doing almost nothing for 20 years and then devolving into bikeshedding chaos in a rushed attempt to catch up with languages that left them behind.

Not coalescing around None-aware

azz — Thu, 05 Jan 2023 15:45:32 +0000

That'd be FORTRAN IV, released in 1962...

Not coalescing around None-aware

kpfleming — Thu, 05 Jan 2023 15:33:47 +0000

You read my mind :-)

The example in the post you referred to may be the 'normal form', but remove the 'not' from it and the meaning changes significantly but a 'quick read' to look for patterns might overlook the change. I can't imagine an actual use for that expression, but I'd hate to misunderstand it because my brain assumed it was just the same as all the others it had seen.

Not coalescing around None-aware

smurf — Thu, 05 Jan 2023 14:39:53 +0000

Don't forget the dictionary type that affords attribute-style access to its content.

Not coalescing around None-aware

kleptog — Thu, 05 Jan 2023 11:10:24 +0000

I believe any sufficiently advanced Python program eventually evolves a poorly tested, half-baked version of such a getpath() method.

Not coalescing around None-aware

Karellen — Thu, 05 Jan 2023 09:43:41 +0000

Wouldn't it be easier to use an API that takes an XPath-style selector (or similar), where you can ask for a nested element and just get a single result (or None) at the end? e.g:

a.getpath('foo/bar/baz')

Not coalescing around None-aware

salimma — Fri, 30 Dec 2022 20:54:57 +0000

No need for an IDE, even, just a terminal / graphical framework that supports font ligatures and a programmer-oriented font like Fira Code.

Not coalescing around None-aware

ssmith32 — Fri, 30 Dec 2022 17:30:43 +0000

Python is old enough now, that even if it just gets a small buzz, there will probably be a hangover later.. ;)

Not coalescing around None-aware

mathstuf — Thu, 29 Dec 2022 21:56:54 +0000

> Even though C++ doesn't "Have" duck typing in this respect in practice that's what it does.

The mechanism of templating in C++ basically feels like it (since it feels a lot like "structured preprocessor" more than "provides interface"). Concepts should help, but standard library usage remains to be seen.

Not coalescing around None-aware

tialaramex — Thu, 29 Dec 2022 20:42:59 +0000

Duck typing is perhaps an appropriate convenience for Python, a language for non-programmers, but what happens is we're polluting a namespace. Having a bark() method does *not* mean you bark "like a dog" but once this unstated assumption takes hold everybody is stuck with it.

This pollution has become pretty bad in C++ where on top of about 100 reserved words like "for" and "reinterpret_cast" and "co_await" there are a vast number of in practice unavailable identifier names which, if you make the mistake of using them, implicitly mark the affected type as having specific properties associated with that word e.g. cbegin() means you're able to provide a constant iterator, size() means you're some container with things inside it. Even though C++ doesn't "Have" duck typing in this respect in practice that's what it does.

Better, I am confident, to be able to state explicitly what you mean, if this Lyre Bird can in fact smurf::animal-noises::Dog::bark that's fine, but it shouldn't be confused with my tialaramex::army::DrillSergeant::bark which is provided neither by Lyre Birds nor Dogs. We need to be clear what is meant.

core::cmp::Ordering and core::sync::atomic::Ordering are both really, really important, but in their own context. Just because my sort method needs an Ordering and your spinlock code has an Ordering doesn't mean they're concerned with the same thing. If the two are in adjacent code, that code needs to spell out what's going on. In unrelated code, the expectation can be stated just once and then context is clear afterwards.

Not coalescing around None-aware

NRArnot — Thu, 29 Dec 2022 16:01:53 +0000

In almost all contexts you can do
x = x or default
the exception being where x may have a falsy value which is not None and which you do not want to replace.

In all contexts you can do
( default if x is None else x)

I for one don't find the case for a slew of new operators overwhelming. I'm not sure they enhance code readability, and the above are not particularly verbose.

Not coalescing around None-aware

mathstuf — Thu, 29 Dec 2022 13:12:28 +0000

I feel like this greatly depends on the kind of software you're writing. I tend to write "libraries" where reliability is higher on the list than applications which can be more of "we're all good fellas around here *nudge* *wink*" with respect to what you can be given as an argument. Given the kinds of craziness Python ducks can contain, I find it much easier to have that "I only accept types which explicitly claim to support interface X" hurdle. Of course, some languages make it a PITA (C++ and Java require inheritance, but Rust and Haskell can get these tacked on later with `impl Trait`-like blocks), but not every feature comes with every creature either.

Not coalescing around None-aware

smurf — Thu, 29 Dec 2022 08:20:48 +0000

Python explicitly supports duck-typing. If your non-Dog-derived object barks like a dog, then "dog.bark()" works even if it's a lyrebird. The song-and-dance you need to go through in C++ or Java to achieve that kind of flexibility (among many other common patterns that tend to take one line in Python, a new class in C++, and two source files in Java) is exactly why I'm using Python.

There are ways to declare interfaces for that kind of code; however, if you want to find typing problems statically instead of crashing on them, Python wants you to use a separate checker (like mypy).

Not coalescing around None-aware

tialaramex — Thu, 29 Dec 2022 02:21:09 +0000

I guess that yeah, maybe the problem is the dynamism. If I have a Dog type then I can intentionally narrow from Dog | None to just Dog and then write code which knows it's a Dog, not a None. Python doesn't want that, it reminds me of the .NET CLR. Modern CLR languages tend to have explicit nullability, so we can say this is a Dog, and really mean that - it isn't a null Dog, it's definitely a Dog. But the CLR itself doesn't admit this idea, and so all .NET programs must defend against APIs receiving a null even where they explicitly said it wasn't welcome. Your function which takes an integer definitely doesn't get floating point parameters, but your function which takes a (non-null) Dog, can still get fed a null Dog by an older or malevolent program.

Not coalescing around None-aware

NYKevin — Wed, 28 Dec 2022 21:55:13 +0000

Python does support Sum types. In fact, the only (static) type in the language is PyObject*, which is just a Sum over all possible types.

The real problem is that Python is dynamic, and "supporting Sum types" doesn't mean anything in the context of dynamic languages. Well, not unless you want to build some kind of wrapper object that really exists at runtime and can't be monomorphized away. But you don't need language-level support for that, you can Just Do It.

Not coalescing around None-aware

Wol — Wed, 28 Dec 2022 16:33:23 +0000

Functional? Just barely!!!

The problem basically is that any use of a spreadsheet beyond the elementary is probably using it as a database - a role for which it is particularly badly suited. (You know my views on relational :-) also equally badly suited for database TECHNOLOGY :-)

Throw into the mix people who don't know how to program, and the result is a complete mess. Even if they do know how to program, you know the saying ... "if all you have is a hammer, every problem looks like a nail ..."

Cheers,
Wol

Not coalescing around None-aware

marcH — Wed, 28 Dec 2022 15:14:50 +0000

> The "??" operator, while initially not expressive, will become more expressive as you get familiar with that construct.
> Familiarity will make things more readable in all cases,...

Except for people who have to make a small change to a Python script rarely, only a couple times a months. I have and always had teammates in that case and that's where Python really shines compares to shell scripts or Perl or others. While the verbose " if None" variations annoy me every time, I totally understand the "Perlification" fear of "??".

Isn't there some middle ground alternative?

Not coalescing around None-aware

MrWim — Wed, 28 Dec 2022 14:44:40 +0000

I wasn’t really thinking about VBA - I was referring to the spreadsheet itself as a functional programming environment.

Not coalescing around None-aware

Wol — Wed, 28 Dec 2022 10:07:45 +0000

As an experienced database guy now responsible for Excel as our departmental database , I would beg to differ ...

I'm a novice at VBA and the number of landmines is atrocious. Excel is not a database.

Our whole system is a mess, and I doubt it's any worse than any other big corp out there ...

A lot of my work is finding and fixing design and data errors ...

Cheers,
Wol

Not coalescing around None-aware

kleptog — Wed, 28 Dec 2022 09:52:59 +0000

Same here, I'd use them all the time. The current:

a.get('foo', {}).get('bar', {}).get('baz')

gets tedious after a while. And there's no easy equivalent for array indexes so you always have to handle them separately. Something like:

a?['foo']?['bar']?['baz']

is a win in every sense.

Not coalescing around None-aware

tialaramex — Wed, 28 Dec 2022 09:22:38 +0000

I have been convinced for some time that languages without Sum types end up with these workarounds and the price of one such workaround is attractive, but there are a lot of useful Sum types, and it becomes unwieldy to implement a workaround for each.

"None-aware operators" are a workaround for lacking Option / Maybe / the "... | None" ad hoc type.

Exceptions are a workaround for lacking Result / Expect

Languages should bite the bullet and provide Sum types even though that's a lot of work.

Not coalescing around None-aware

MrWim — Wed, 28 Dec 2022 01:16:18 +0000

Spreadsheets are a counterexample. People who wouldn’t consider themselves programmers program with them every day - and don’t think of themselves as programming while they do it.

Not coalescing around None-aware

smurf — Tue, 27 Dec 2022 10:08:05 +0000

If you can write a syntax module that translates ?? into if-None-else conditionals (and which you apparently can do; see the PEP), then writing one that replaces ∈ with "in " and ≤ with "<=" should be child's play.

Not coalescing around None-aware

LtWorf — Tue, 27 Dec 2022 00:20:28 +0000

Yes but I can't do

if x ∈ X ∨ y ≤ z: ...

Not coalescing around None-aware

pm215 — Mon, 26 Dec 2022 23:56:44 +0000

I think one key set of users for whom "not too much clever shorthand syntax" is useful is the programmers who have to dabble in python as a secondary language that *isn't* the one they program in most of the time. Small scripts, interpreters embedded into other programs, that sort of thing -- at the moment Python is pretty good for this because (among other things) if you know programming-in-general then what a lump of Python does is mostly fairly self-explanatory.

Not coalescing around None-aware

mathstuf — Mon, 26 Dec 2022 23:11:38 +0000

> Should Python follow the buzz?

Only if it wants to fizz out :) .

Not coalescing around None-aware

NYKevin — Mon, 26 Dec 2022 17:38:02 +0000

I was primarily thinking of [1], but having briefly worked a consulting gig, I can assure you that systems like that one are actually deployed in the wild (but I can't give any details, for obvious reasons). Alex didn't just make it up from whole cloth or something (a frequent accusation people level against that site).

[1]: https://thedailywtf.com/articles/The_Customer-Friendly_Sy...

Not coalescing around None-aware

smurf — Mon, 26 Dec 2022 10:36:38 +0000

Well, if you want to do that, please use "from math import pi as π".

Not coalescing around None-aware

caliloo — Mon, 26 Dec 2022 10:19:12 +0000

Lol the description you make in point 2 sounds too much like magic the ide/programming env for comfort

Not coalescing around None-aware

Wol — Mon, 26 Dec 2022 09:26:09 +0000

> * "Real" = "not just an educational toy like Scratch, but a proper language you might try to use for serious purposes."

I can name one (of course). DataBASIC. There are plenty of systems that were written in that. Pretty much the entire travel industry. HOLMES. A bit of digging could find plenty more. And there are plenty of horror stories about the disasters as people tried to migrate away from this "niche" system that was embedded everywhere that nobody knew about ...

But the problem was Dick Pick spent his money on lawyers, not marketeers, and SQL took over :-(

Cheers,
Wol

Not coalescing around None-aware

anselm — Mon, 26 Dec 2022 03:09:12 +0000

In Python 3, there's nothing preventing you from saying

$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> π = 3.1415
>>> print(π)
3.1415

Not coalescing around None-aware

NYKevin — Mon, 26 Dec 2022 02:04:39 +0000

We've been trying to build real* programming languages for non-programmers since the days of COBOL. Every single one of those languages, without exception, has eventually evolved in one of two directions:

1. Programmers use it, business analysts don't, it starts being treated like a "real" programming language, and eventually everyone forgets that it was a "for non-programmers" language in the first place. At most, it will retain some funny-looking syntax or quirks of semantics. E.g. PHP, SQL, COBOL, BASIC.
2. Programmers use it, business analysts don't, but everyone pretends otherwise and insists on keeping it "friendly" to non-programmers, to the detriment of the system's usability. At best it becomes a niche system used by one or two very large organizations for some highly specialized purpose. Regardless, nobody else will touch it with a ten foot pole. I don't have examples, because these things are usually proprietary and nearly always NDA'd out the wazoo. GUI interfaces are common. Branching may be represented using flow charts. You may have to construct individual lines of code by picking instructions and operands out of drop-down boxes. Etc.

Learning to code is challenging for many people. But it is not "the hard part" of programming. The hard part is learning to reason about the logical implications of code. Learning to boil down a user story (or whatever they're calling them these days) into a logically rigorous set of functional and non-functional requirements, and ensuring that each module of the larger whole upholds its end of the bargain. No amount of hand waving will convince the computer that it should "just do what I want." Even with AI, there will always be a conceptual gap between what you want, and what you ask for. AI is not magic. It cannot read your mind. And neither can "friendly" user interfaces.

* "Real" = "not just an educational toy like Scratch, but a proper language you might try to use for serious purposes."

Not coalescing around None-aware

mtaht — Sun, 25 Dec 2022 22:34:54 +0000

I got plenty of function keys left, and an APL keyboard still in storage. Bring it on!

I'm not kidding btw. I'd really like it if more code looked like the math, and an IDE would make it as easy as α, β, Γ. The Δ between well known symbols and their overly verbose english equivalents would increase visual density.

Not coalescing around None-aware

Wol — Sun, 25 Dec 2022 22:33:58 +0000

> I’d be curious though to see if the balance of users keeps shifting towards full time programmers as it has for the past decade or more. This would reshuffle the cards on how to make that choice in my opinion.

The problem with that, is that it makes programmers an elite. Which actually leads to bad systems! We have programmers who don't know what the program is for, we have users who can't program, and we have business analysts - sorry chinese whisperers - who are trying to square the circle.

Cue a big disastrous mess ...

Cheers,
Wol

Not coalescing around None-aware

caliloo — Sun, 25 Dec 2022 17:50:24 +0000

One funny thing I note is that
If x is none:
x=42

Is actually less characters than
x = 42 if x is none else x

x=?? 42
Is of course shorter, but readability will depend on your proficiency in python operators, which implies a greater prerequisite on your knowledge of python.

Besides, having condition and assignment on 2 different lines fits more with the rhythm of python overall, I think.(I know, list comprehensions, lambdas…)

I often find that full time somewhat experienced programmers enter a race in the least number of lines/chars at the expense of everything else (functional form in Java for example, or Perl, or user defined ops in cpp) When you start wielding this hammer you tend to find nails naturally, because you re at a level of knowledge where typing less advantages you. But this vantage point from which the balance advantages/inconvenients is measured is not the only one. One of the strength of python is that people can be onboarded easily, or not make programming their full time job. From these other pov I’d say that the most advantageous form if the first one.

I wonder if there wouldn’t also be an advantage to explicitly make a subset of python “advanced features” enableable with a flag or some such thing. But I don’t have any personal experience in such way of doing things personally.

I’d be curious though to see if the balance of users keeps shifting towards full time programmers as it has for the past decade or more. This would reshuffle the cards on how to make that choice in my opinion.