Talk:Cheryl's birthday: Difference between revisions
m
Thundergnat moved page Talk:Cheryl's Birthday to Talk:Cheryl's birthday: Follow normal task title capitalization policy
Thundergnat (talk | contribs) m (Thundergnat moved page Talk:Cheryl's Birthday to Talk:Cheryl's birthday: Follow normal task title capitalization policy) |
|||
| (27 intermediate revisions by 4 users not shown) | |||
Line 1:
__TOC__
==Improve tag on Python entry==
I added an improve tag on the Python entry as it does not look or read like idiomatic Python. To avoid an edit war I will state my reasons:
Line 52 ⟶ 54:
, '__str__', '__subclasshook__']
</pre><br>or The Python Data Analysis Library with which after establishing dates as a data frame you could write something like dates.groupby('month').count()--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 13:39, 26 October 2018 (UTC)
: Thanks Nigel – I'll take a look. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:57, 26 October 2018 (UTC)
Hi Hout: You obviousely don't like the way Python evolved under Guido's leadership. That is plain. If you you don't like the PEP-8 guidelines then I suggest you get them changed to your liking , in the proper forums. If enough of the community under the new GUIDO are convinced then you will get your way.
One could take your criticism/diatribe on the support for functional programming and substitute another programming style; and no doubt there will be OO programmers lamenting the "broken" support for OO in Python with similar righteous indignation.
Python is what it is. RC isn't the place to change it. One could try to write Haskell in Python, but that would not make it idiomatic Python. Yet? :-)
:[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 15:19, 26 October 2018 (UTC)
:: The way to handle the 'idiomatic' issue is with tooling – all of the code I have published here is checked with AutoPep8 and Linter-flake8. Feel free to suggest any further linters which you think might be helpful.
:: I am not trying to change anything – you are the one attempting to censor the code of others.
:: The 'Pythonic/imperative' coding style which you like was a particular optimisation for (1.) Easily accessible Python (imperative coding creates more run-time complexity and costs more debugging time, but it has a lower entry level, requiring a grasp only of sequence branching and iteration.) and (2.) Some very private (anti 'lemon-juice', 'things that interest me') aesthetics (and one formal misapprehension) of Guido, for which he failed to establish sufficient consensus to get his own way, and which eventually contributed more to problems than to solutions, making his BDFL role unsustainable, and bringing it to an end.
:: Python is now much larger than the initial 'easy-coding-for-all' personal project, and while the simple 'Pythonic' verities are still a useful source of consistency in some contexts, they are deliberately dysfunctional, by specific design, in others. They can usefully standardise imperative and impure code, but can only lead to intentionally bad functional code.
:: Functional composition is, in fact, and fortunately, simply one of the ways in which Python interpreters are actually used. That is why '''map''', '''filter''' and '''reduce''' entered the language, and that is why Guido simply failed, in the end, to expunge them, despite his strongest and most truculent efforts. Composition of pure functions has a higher entry barrier – it requires more concepts – but it yields more reliability, reduced debugging time, and greater code reuse. It is absolutely the right way to write good Python for some contexts, and for some users, and there is no value whatsoever in trying to shoe-horn real Python code (officiously, and frankly, somewhat ignorantly) into the residual shackles and deficiencies which Guido rather perversely and self-absorbedly sought to put in the way of composing pure functions, against the grain of the needs and better judgement of the Python community as a whole. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:56, 26 October 2018 (UTC)
==Type hints for the compiler are not an alternative to semantic type comments for the reader==
Paddy's addition of type hints is a very constructive and interesting idea, and useful spur to experimenting with the mypy type checker, which I have been wanting to do. His deletion of the informal Hindley-Milner style type comments from Python draft, however, probably arises from a misunderstanding, and simply deprives the reader of clarity about the semantics denoted by the function.
For example, it doesn't help the reader at all to replace:
'''uniquePairing :: DatePart -> [(Month, Day)] -> [(Month, Day)]''' with a bald '''(int -> Callable)'''
The type hints for the compiler, and the informal Hindley Milner type signature comments for the human reader serve two entirely different purposes, and are not at all in tension with each other. As the useful notes on this JS project point out https://github.com/ramda/ramda/wiki/Type-Signatures comments/annotation of this kind have become a kind of language-independent standard in functional programming generally. In some projects, like Purescript, they do have a role in compilation as well as providing clarity for the reader, but in other projects, like Ramda, they are entirely for the reader, and simply serve to summarise the semantics of the function in a brief and relatively standardized way. No need to deprive the reader of them simply on grounds of tribal shibboleth zealotry, border patrolling, or heresiology. A comment is just a comment. :-) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 23:05, 26 October 2018 (UTC)
: Python type hints are also more than those I auto-generated; as is the use of docstrings. Try writing something like idiomatic Functional Python; with its none-Haskell peculiarities rather than believing such things are beneath you. Python has an existing set of functions that the community has expended the effort to learn and/or expect to learn. If you convert and create your own set of functions then readers cannot use that Python knowledge they have. Just as I don't see you using Lisps car and cadr you've probably decided to use your own names for things that were named before. It reads as if you have your own set of functions and know how to use them to solve problems; as well as how to define them in terms of Pythons functions - a translation of sorts. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 17:33, 28 October 2018 (UTC)
:: Paddy or Donald, the only intervention I have ever made in your code is to point out that your pythonic example for a new task that you were offering (Cosine laws, I think) generated the wrong result. Even then, I aimed for extreme tact and discretion, and simply offered an alternative draft in functional Python which produced the correct result – politely (I hope) drawing your attention, without comment, to the 'mystery' of the divergence.
:: I have no interest '''at all''' in changing your style of Python – please now desist from trying to change mine.
:: The Python community is large and diverse, does not always agree, and does not need to.
:: I respectfully suggest that if we do differ, we express those differences by submitting alternative solutions, with differing approaches, to the same problem, thereby enriching Rosetta Code rather than simply making making it noisier and more acrimonious.
:: That is more than enough now. Your persistent and unremitting attentions and intrusions now feel persecutory. Please move on. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 18:11, 28 October 2018 (UTC)
== Can we turn down the heat somewhat? ==
I would prefer if discussions here would focus on the programming issues instead of on tangential issues such as the people expressing the viewpoints.
We all have different viewpoints - this is a necessary condition of life - but I think (on rosettacode) we'd all be better served if we could focus on the code itself.
Mind you, I also understand that coding standards can achieve religious significance for some people. But, there, it's probably better to link to relevant documentation of the standards than it is to try to recap those standards here.
We're not going to achieve perfection here. But we've got bigger problems to be dealing with than differing perspectives. (For example: all too often, code from here doesn't work, either because of copy/paste issues, version drift, unexplained and unknown assumptions or other similar details which might have escaped the author's notice).
(Hopefully the way I've said this here isn't too terse or too off-base to express the concept?)
Thanks. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 23:08, 26 October 2018 (UTC)
:: Absolutely agree. Code that actually works, and has been through standard linters, seems more than enough. I can find no value in insisting that it is also optimised exclusively for narrowly defined contexts or cultural currents. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 23:12, 26 October 2018 (UTC)
:: Oh dear – deletionary zeal is back again this morning ... See under mcNuggets Talk. Sigh ... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:19, 27 October 2018 (UTC)
:: Good heavens ... the appetite for attrition seems strong ... further notices, and now a whole discussion added to my talk page. I suggest that we just (1) agree that PEP8 linters are a good idea (I have used them throughout) (2) accept that functional Python, about which there are least two books (Merz – O'Reilly Press, and Lott), several book chapters, and plenty of on-line use and discussion, is distinct from the excellent (but deliberately imperative) 'pythonic' subset of the language. Let's just divide the Python contributions into 'Pythonic' and 'Functional' subheadings. The spirit of Rosetta is to be inspired more by what is shared than by what is different. Let's just move on [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:18, 28 October 2018 (UTC)
:: To be honest, I begin to feel a little harassed. Surely that can't be the intention ? I am not ''quite'' sure what is going on ... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:40, 28 October 2018 (UTC)
| |||