Talk:Practical numbers

Haskell type hints are not valid Python

Hout, I have shown below that, contrary to your statement, you have used, and want to continue to use Haskell typing in a Python example. I have replaced the Haskell with Python typing. Please don't add Haskell typing to a Python example.

No, I don't want to use typing at all in small projects. Type comments, however, are essential for clarity, during drafting, and also during refactoring. They serve a very different purpose from compiler hints, and they need to be much more human legible. Hout (talk) 21:10, 31 March 2021 (UTC)

Hout, Your arguments contradict yourself. You in one place state its not typing - then in another argue that your version is better than Python typing. You state that its not Haskell typing, and yet you use the same syntax in typing Haskell code as well as Python. You are dishonest! --Paddy3118 (talk) 19:27, 31 March 2021 (UTC)

Silly comment Paddy3118, I can't even follow it – no idea what you mean. Don't you think the Python linters and interpreters might notice if the syntax used was from another language ? You are worried that Bool is different from bool, and Int from int ? In a comment ?

I find it very useful to think in terms of a more general type semantics, and a clean notation for comments.

As we've seen, the Python type hints for the compiler, which you have insisted on (deleting my clearer comments) make the type of the key Python function there much harder to read. In fact, they are actually misleading, and make no contribution to the code ... The "Any" type symbol leads us to believe that any type will do in those positions, where as in fact any divergence from what my comments clearly show would simply cause the code to fail ... Is that what you are really hoping for ?

Would you prefer that I write my type comments in English ? They might be a bit verbose – MH is much quicker to read at a glance ...

I find it works very well for informal notes to the reader ...

I do understand that you take a different approach, but why delete ? Does it really feel so threatening to have two different approaches side by side ?

After all, that is what Rosetta Code is for ... and PEP8 does caution us against forms of compliance which diminish clarity without adding value. Compliance can be left to the linters, and doesn't protect us from writing code which is unreliable, hard to refactor, or simply slow. Very bad code and very unreliable solutions can easily be written in superbly "compliant" code. Compliance is not enough – its only purpose (read PEP8 again) is to serve clarity, in a given context, and contexts vary. Hout (talk) 21:05, 31 March 2021 (UTC)

Hout: So your response is that the comments are not typing, and that you cannot understand when I point to Padovan n-step number sequences and the Haskell typing you added in the Haskell example being the same as the Python comments you added to your Python version? I use that as evidence of your comments being Haskell. Intentionally Haskell. You contradictory counter-claims are just that - You cannot prove my claim false.

I have updated and improved, (and certainly not deleted), your code to use Python typing and removed the Haskell typing as it is inappropriate to a Python example. Don't add it back. --Paddy3118 (talk) 08:35, 1 April 2021 (UTC)

Comments are for readers, Donald, type hints are for compilers. Different goals.

You have repeatedly deleted my original version completely, each time I restored it for display in parallel to your formally typed version

I am very pleased, however, to see that you have now improved that typing to the point where it is no longer misleading and obscuring.

Very helpful to have both versions in parallel, in the proper Rosetta manner, for comparison. They aim for different things. Clarity for the reader in one case, formal type checking in the other. Thank you for putting in the effort to learn the type-hint notation and to debug that example. Enjoy !! I look forward to seeing you use more pure value-returning functions :-) Hout (talk) 09:58, 1 April 2021 (UTC)

In fact it looks like you've debugged all those compiler type hints – wonderful !! I hope that didn't take too long :-( Hout (talk) 10:05, 1 April 2021 (UTC)

The Padovan example shows that you add Haskell typing to Python examples. Your snide and inaccurate comments above show that you know Python typing and choose to ignore them in favour of adding Haskell typing information. I called you on it and you try misdirection and name calling. --Paddy3118 (talk) 11:20, 1 April 2021 (UTC)

Take the olive branch when you get it :-)

We take different approaches, and the value and goal of Rosetta Code is to be able to look at differing languages and approaches (for example functional vs imperative, curried vs uncurried etc etc) side by side.

When projects are large, I do find that Python type hints are worth the extra work and testing.

When projects are small, the approach that works well for me is to emphasize clarity, and save time, by just writing type comments

Its absolutely true that I could use the compiler hint notation in those comments,

but formal compiler hint notation is noisier – less clear at a glance. Not intended for comments.

I find that the simpler language-independent MH notation does work very well for comments,

and sometimes, if a project grows, or its context changes, I then translate to,

and debug, the more complex compiler type annotations.

I do understand that the sight of MH (you call it "Haskell") alarms your immune system, and looks like a foreign language to you.

(you have made that very clear, again and again. It's heard.)

but no language constrains the contents of comments – they are entirely up to the user –

and that notation, not least because it is brief, and language-independent,

is one which works well for me, and indeed, for many others.

We don't have to persuade each other.

If we did, Rosetta Code would have no content at all – it would first collapse to a single language, and then vanish entirely in a sulphurous puff of the One Truth and the One Way, for want of motivation.

One Rosetta Code we show different approaches. We don't need to tell them.

And we certainly don't need to "encourage" or "discourage".

We come here to share and learn, and think. Hout (talk) 12:05, 1 April 2021 (UTC)

A long time ago when this started I read the PEP on Python typing. The document was the result of collaboration between a Python project and Cython. In order to compile their project with Cython, for efficiency they had to make changes to the Python such that it no longer ran in Python which they wanted to use for development (more fool them). The result is a type scheme which is written by humans, ignored by Python but read by Cython to produce efficient code (could be called C typing rather than Python typing!!!). Them what be at Python encourage developers of official projects to use Python typing. Them what be at Python complain regularly that most submissions just use Any everywhere. Rosettacode is not Python and I don't care what them what be at Python think or want to achieve. Rosettacode is not the place for a self appointed spokesperson for them what be at Python to continually vandalize well produced and suitable Rosettacode submissions. The MH typing is meant to be deduced from the code by the compiler (good luck with that with a language like Python) and read by humans to explain functionality. The MH is richer than the Python typing and obviously is better as a comment (though I think it is an attempt to make a silk purse from a pig's ear), the Python typing would be needed if the object was to compile the code using Cython for efficiency.--Nigel Galloway (talk) 14:28, 1 April 2021 (UTC)

Python: Comment on type hints for the functional example

− Hout Wrote:

−

Clarity about the return type semantics, is however, very useful when reasoning about pure functions, and my personal approach is to add light informal comments about the type, in a Hindley Milner idiom, which lends itself well to brief and clean notes on the type of curried functions, which are more easily composable, especially with higher order functions, and which I generally prefer to use.

−

I've been asked (always by the same person :-) why I don't find the idiom of Python compiler type-hints a good match for my semantic type comments, and the answer is essentially that the compiler type hints are not a clear or helpful notation for this purpose – not just because they generally involve more typing and visual noise, but also, and in particular, because with curried functions the compiler hint notation becomes swamped by use of the cognitively redundant `Callable` keyword, which degrades clarity, and imposes burden, for the human reader.

I replaced misleading Haskell-language type comments by Python typing checked with MyPy. Python can add typing in comments as part of the language and that too is not the Haskell that was replaced.
--Paddy3118 (talk) 09:17, 31 March 2021 (UTC)

Comments are for the reader not the compiler. My comments provide the reader with information which is both less noisy, and more specific, than the uses of the Callable and Any keywords in the compiler hints.

I quite understand that our approaches differ, and the contrast adds to the value of Rosetta code, as defined on the landing page

Deleting informative comments is gratuitous, and inconsistent with the goals of Rosetta code, and removes value without adding any. There is a name for this. Hout (talk) 09:36, 31 March 2021 (UTC)

Python although a language spec. is commonly referred to as being an interpreter as its overwhelming implementaton, CPython is an interpreter. Python does allow types as comments in its format. Haskell typing is not Python typing. Your Haskell comments are at odds with the typing of Python, as you do not defend. --Paddy3118 (talk) 10:09, 31 March 2021 (UTC)

Oh dear ... what is this addiction to angry vandalism ?

Comments for the human serve a different purpose to syntactic hints for the compiler, and carry different type of information. There is no need to confuse them, and their notational requirements differ.

The content of a comment is not part of the syntax of a language. Hence your attempt to fudge the language with talk of "python format" (sic). (I think you may find that that is what a layout program contributes).

Hindley Milner notation is not "Haskell". It is a language-independent representation of the semantics of types in general, which proves clean and expressive in a variety of contexts. I find these comments very helpful to my clarity as I sketch and compose my functions.

Let us consider an example:

You have angrily deleted, with intemperate submission tags, what seems to me a clear and informative comment:

# sumOfAnySubset :: [Int] -> Int -> Bool

and replaced that comment (in a short script which probably doesn't benefit much from compiler type hints anyway) with a formal type hint which, for the human reader, is noisier and less informative:

sumOfAnySubset(xs: List[int]) -> Callable[[Any], Any]

I rest my case. "Callable" is not needed by the human reader, who is simply aiming for mental clarity, and "Any" provides less information than Int. It is, in fact, misleading. A [String] or String for example, in either of those positions, would cause the code to fail.

The comment is more legible and helpful for the human, the type hint is more helpful (we hope) to the compiler.

It would be entirely possible, depending on what we are optimising for, to have both.

We can disagree on this – that's fine – but when our approaches differ, we contribute alternative versions. This enriches Rosetta Code.

Vandalistic attempts to prune Rosetta back to one Truth and one Way, overwriting and deleting with shouty comments, are gratuitous, and very damaging not only to Rosetta Code, but frankly, also to you.

I'm afraid that this addiction to intemperate deletion and vandalism is again approaching the point where it will merit active disciplinary attention. Try to get some help outside Rosetta Code. It is clearly not the fount or origin of your difficulties. Hout (talk) 10:18, 31 March 2021 (UTC)

You chose not defend your insistence on using Haskell typing in a Python example. Rosetta code readers expect Python in the Python section. Adding Haskell type comments detracts from this, (Oh quick call them a vandal as my case is too weak). --Paddy3118 (talk) 10:44, 31 March 2021 (UTC)

"your insistence on using Haskell typing "

No. I'm not using typing at all. I don't find it helpful in small Python scripts.

I do find type comments helpful. They are not "Haskell" – they are in a language-independent format (MH) which I find clean and informative.

My comments are not your business.

Deletion is not the Rosetta way. The Rosetta way is the addition and comparison of alternative approaches. Hout (talk)

You are being disingenuous in your comment on your typing. In Padovan n-step number sequences for example, your Haskell typing is the same as your Python comments. It is not Python, which has its own typing, both as out of comment syntax and as in-comment syntax. You want to add Haskell typing to Python. You complain that Pythons typing is inferior but don't know it enough to use it?

I get that you think Haskell typing is superior, but Python typing is available and should be used in preference for a Python program.

--Paddy3118 (talk) 16:05, 31 March 2021 (UTC)

This is not sane. I am not using typing of any kind. I don't find typing useful in small scripts. Comments are not code.

Our approaches differ.

What makes you see a different approach as a license to put on a plastic policeman's helmet and simply delete expressions of approaches which differ from your own ?

I do not vandalise your code on the grounds that I disapprove of it, and that it "should not be encouraged" as you put it.

You should not obsessively vandalise Rosetta Code by doing that to mine, or to anybody else's.

Put the plastic helmet and truncheon back in the children's dressing up box. Get yourself some help. Hout (talk) 16:15, 31 March 2021 (UTC)

I suggest you learn more about Python then to understand your problem. No, your insistance that you are not adding Haskell typing to a Python program given the examples mentioned above, put you beyond reason. You systematically, and repeatedly add Haskell type annotations to your Python examples ignoring the Pythons typing wwhich includes Pythons type annotations as comments. --Paddy3118 (talk) 16:26, 31 March 2021 (UTC)

Kick

Paddy3118, on your user page, you write: (Kick-me if I seem impolite) --Chunes (talk) 10:26, 31 March 2021 (UTC)

Repeated attempts to pass of Haskell as Python should not be encouraged. Hout has had many polite explanations that he chooses to ignore. I have translated his Haskell to Python type annotations in this case. Hout prefers the Haskell. This is a Python example. Your kick is misplaced. --Paddy3118 (talk) 10:36, 31 March 2021 (UTC)

"should not be encouraged" is a strange but illuminating phrase (I ignore your silly, tiresome and obdurate characterisation of my Python comments as "Haskell" :-)

May I ask, where exactly in Rosetta Code's landing-page statement of its goals do you read an incitement to "encourage" or "discourage" particular styles of coding ?

That would seem an oddly aggressive and fruitless attack on the intention to "aid a person with a grounding in one approach to a problem in learning another".

Are you hoping to change the goals of Rosetta Code ? Do you disapprove of them ? It's getting harder and harder to avoid that impression.Hout (talk) 10:47, 31 March 2021 (UTC)

If code doesn't run, or solve the task, or contains problems flagged up by a widely used linter, then let's point that out to each other, and perhaps suggest solutions.

Any other divergences are opportunities, not threats.

Where approaches differ, we learn. I already notice that you have learned some things from my code. Things which you would have missed if you had succeeded in stamping it out at the beginning, as you were clearly (though a little puzzlingly) hell-bent on doing. Hout (talk) 10:54, 31 March 2021 (UTC)

You said you were not using Haskell typing in a Python program. I exposed your lie in the section above by pointing out in a previous task your Haskell typing is the same as the Python comments.

I don't expect, given your exposed lie, that you will agree, but Rosetta code is about language comparison, which is not advanced when you try and pass-off Haskell typing as part of Python and then lie about it. --Paddy3118 (talk) 16:17, 31 March 2021 (UTC)

You know perfectly well that I am not "doing typing", and that I choose not to use compiler type hints on small Python projects

What I definitely am doing is providing type comments in an MH format that is language-independent, and which I find clear and helpful, on language-independent type semantics.

As we have seen in concrete examples that is much clearer, and much more Pythonically consistent with PEP8, than the misleading type hints which you installed after deleting my comments.

If you wish to show a version of my code with type hints, that's up to you – their lack of clarity for the reader, in the context of curried functions, is instructive.

You must not, however persistently delete my version, and then childishly scream "deletion" when I restore.

You also know perfectly well that:

I have *never* deleted any of your code and would not be remotely interested in doing so
You have been consistently harassing and attempting to delete my code, on endlessly shifting grounds, for years now, despite other members of the community repeatedly calling you out for bullying. Hout (talk) 09:04, 1 April 2021 (UTC)

Hout: You add Haskell typing to Python code, repeatedly. You seek to obscure this as an argument to use Language X's typing in language Y when language Y has typing of its own is untenable.

Your code is improved Python when Pythoneers can read Python typing information instead of being confused and having to learn Haskell to follow your original. --Paddy3118 (talk) 11:09, 1 April 2021 (UTC)

We clearly mean different things by typing, but we don't need to discuss that here :-) Comments are just comments, the compiler ignores them, the coder and other users can find them useful.

You say "Your code is improved when XYZ ..."

I wonder if there is actually any meaning to words like "improved" if we extract them from particular contexts ?

Even within a particular language, the balance of what we are aiming to optimise at any given moment, any particular piece of code, or any particular office, is hugely variable:

Reliability ?
Speed of writing under pressure ?
Levels of code reuse ?
Ease of refactoring later ? Possibly by others ?
Speed of execution ?

It seems unlikely that "improved" can ever have discernible meaning (beyond attempts at rhetoric :-) on its own.

It begins to have meaning when paired with things like "... in terms of X" or "... for the purposes of Y"

The trick is just be clear about what we are optimising for at any given point.

Formal type-checking hints, for example, require additional work and debugging, as you've just seen. Get them wrong, and compilation chokes, that costs real human time, the cost of which may be unrewarded.

Simple comments take almost no work, but provide no real type-checking.

Which works best ? We need to know the context.

The additional work will be worthwhile in some contexts.

The faster coding will be worthwhile in others.

Anyway, good work on those compiler annotations ! I appreciate the effort. Hout (talk) 11:33, 1 April 2021 (UTC)

Create a new language code (my awkward attempt at a bit of diplomacy)

Can I just ask, would you (Hout) be opposed to creating a new language code? Call it anything you like: Python (Functional), Functional Python, Python-H, Phython, and explain on that new Category page it is just standard Python [3] written with Haskell/MH type annotation comments (or however you want to phrase it), and perhaps add a link on the existing Python Category page to it. In fairness I have to ask whether you (Paddy) would object to such a link/category. It seems to me that could resolve this clash of styles and be independently useful anyway. (My apologies if that's all just crazy talk.)

Just so you both know, I have actually learnt a few things from these arguments, not that I'm suggesting they should continue. --Pete Lomax (talk) 13:06, 31 March 2021 (UTC)

Thanks – a new language code is an interesting and constructive thought, though it might also risk the fundamental health of Rosetta Code, by working around, and implicitly normalizing, this slightly dangerous and exogenous conception of "Encouraging" and "Discouraging" particular approaches, rather than simply displaying divergent approaches side by side, so that those familiar with one approach can learn about another.

See https://www.rosettacode.org/wiki/Rosetta_Code:Village_Pump/Discouraging_approaches

Can you advise me one how one adds such topics to the main listing of the Village Pump page ?

More generally, if all we are talking about is comments, the creation of a separate category might just feel a little extreme, and might lose the principle of placing things next to each other for contrastive insight.

My own approach happens to differ from (Paddy)'s but I have no interest whatsoever in intervening in his code, or even in commenting on it, unless, as has occasionally been the case, it actually produces the wrong result, or triggers something at the warning level from a widely used linter.

I would certainly never presume to edit it directly :-)

(I am more than content to do the proper Rosetta thing, and just submit a constrasting variant, illustrating the possibility of another approach). Hout (talk) 13:21, 31 March 2021 (UTC)

Would the deletionary campaign continue if my type comments were in English ?

You appear to believe that Rosetta Code is a vehicle for "encouraging" some approaches and "discouraging" others.

"Discouragement" in your sense appears to require active harassment and unilateral deletion and over-writing.

Your current animus and deletionary excitement has now latched onto my comments on the type of particular pure curried functions. Three points. One question.

I find the composition of pure curried functions works well in contexts in which I need to emphasise reliability, fast coding and refactoring and high levels of code reuse. Curried functions are particularly flexible when composing with higher-order functions, such as those which the Python itertools module documentation attributes to the SML / Haskell languages, and adopts gratefully, and with no hint of nativist resistance.

Working with pure curried functions requires clarity about types, both in drafting compositions, and in refactoring them later.
The Python type-hint idiom happens, alas, to be poorly optimised for clarifying the type of curried functions. It is designed to solve a different kind of problem (for the compiler, rather than the reader) particularly in much larger projects.

For example, my central function for this task was represented, in my Hindley-Milner type commments as:

# sumOfAnySubset :: [Int] -> Int -> Bool

which shows at a glance (precisely what we need) that it returns a boolean value, and that its second argument is an integer value.

You keep unilaterally deleting this rather clear and simple comment, and replacing it with something quite different – a formal type hint for the Python compiler which, alas, is much less clear, and in practice, misleading.

In your angry and repeated edit, which fiercely insists on confusing comments with compiler hints, we can no longer see the return type, or the type of the second argument, and are now forced to waste time retrieving these types inductively by interpreting the code:

Here is what you keep writing (though the value of formal type hints for short Python scripts is known to be uncertain at best, and probably a waste of time):

sumOfAnySubset(xs: List[int]) -> Callable[[Any], Any]

Your own (slightly sheepish?) meta-comment above this is now "Note: Although mypy compliant, type Any below could be improved."

In other words, you are well aware that you have unilaterally made my code less clear, and you indicate that in your view, that clarity is less important than a certain conception of "compliance".

You are, in short, launching a direct attack on Rosetta Code (which aims to show varying approaches) and does not aim to eliminate them.

You are also launching a direct attack on PEP8, which centrally reminds us that the goal should be to increase readability., and that "foolish consistency" is dangerously counter-productive and not at all "Pythonic".

https://www.python.org/dev/peps/pep-0008/#:~:text=for%20that%20project.-,A%20Foolish%20Consistency%20is%20the%20Hobgoblin%20of%20Little%20Minds,says%2C%20%22Readability%20counts%22.

Let me ask you two questions:

if my type comments were in English, would you still be repeatedly deleting them ?
what exactly do you fear will happen if my comments are allowed to remain in their existing MH format ?

I am far from being the first to find MH-style comments useful for clarifying and recording types in Python code. Python does nevertheless appear to have survived ...

The Pythonic thing is to optimise for clarity, the Rosetta thing is to show differing approaches side by side. Angry unilateral deletion, and the enforced reduction of clarity in the name of "compliance" is not just sad and foolish – it constitutes direct and disgraceful attack on the health and wealth of Rosetta Code, and on the principles of PEP8 itself. Hout (talk) 20:01, 31 March 2021 (UTC)