[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging
On Fri, Nov 12, 2021, 1:39 AM Christopher Barker wrote: > > unittest is the first (and only) testing framework I have ever used, so >> any info is appreciated. > > > Yes, I like Pytest a lot more. > > I should really write this up someday, and I did write a bit about it on > this list not too long ago. > > So the really short version is: > > Unittest requires a fair bit of boilerplate that adds no real > functionality. > > The assert* methods are only there to provide error reporting that can be > done by introspection by the test runner (e.g. pytest) > > It’s missing some really key features like paramatrized tests. > > Give Pytest a try — I suspect you’ll like it. > > Note that a LOT of major projects dumped unittest years ago— first for > nose and now usually pytest. No one uses a third party library for no > reason :-) > > -CHB > In my humble opinion, the only two valid reasons to use unittest are if you are writing tests for Python itself, or if you are operating in a locked down enterprise environment where PyPI is off-limits and you have to rely on the stdlib. All other cases should use pytest or something similar (or in a security-conscious environment, petition the appropriate people to evaluate and approve pytest). > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5MWKWL7XHA34RLSVXBVMQALTWCRGQJGP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging
> unittest is the first (and only) testing framework I have ever used, so > any info is appreciated. Yes, I like Pytest a lot more. I should really write this up someday, and I did write a bit about it on this list not too long ago. So the really short version is: Unittest requires a fair bit of boilerplate that adds no real functionality. The assert* methods are only there to provide error reporting that can be done by introspection by the test runner (e.g. pytest) It’s missing some really key features like paramatrized tests. Give Pytest a try — I suspect you’ll like it. Note that a LOT of major projects dumped unittest years ago— first for nose and now usually pytest. No one uses a third party library for no reason :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E4F6ATUGD3TLBULMBXSIKRDXX65KCMR6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging
On 11/11/21 9:35 PM, Christopher Barker wrote: > Matt del Valle wrote: >> So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and >> unittest modules [...] > > The reason those are spelled that way is because they are ported from Java. > > And IMHO that “Java flavor” is a bigger issue than just the names. It’s the whole structure. So if we’re > going to touch those, let’s make a Pythonic API, with PEP 8 compliant names, instead :-) Besides the names, what are the issues? And are those issues covered by pytest, etc? unittest is the first (and only) testing framework I have ever used, so any info is appreciated. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5SX3FO4OVPWGOH6C2E32PNX5YOBAAXMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On 2021-11-12 at 14:43:07 +1100, Steven D'Aprano wrote: > On Thu, Nov 11, 2021 at 10:06:45PM -0500, Ricky Teachey wrote: > > > Is there a standard idiom-- perhaps using a type-hint-- to signal to the > > IDE/linter that my user-defined class is intended to be used as a > > function/factory, and not as a type (even though it is in fact a type)? > > Not really. I don't think there is even a standard idiom for the human > reader to decide whether something is used as a "function" or a "class". > It is subjective, based on usage and convention. As others have pointed > out, many functions in Python can be considered as class constructor: Isn't that why we like duck typing? I don't care what something is, I just care what it does. So when I call zip(x, y) and get an iterable, what's the difference (to me, as the user) whether zip is a class or a function or some arbitraru callable, let alone what the implementation of the resulting iterable is? If I want Java, I know where to find it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SLYABYDVTYDVY3WNEMAUKPCM6NRU7QNZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Adding pep-8-casing-compliant aliases for unittest and logging
> > So perhaps we could narrow the scope of this down to just adding > snake_case aliases to the logging and > > unittest modules [...] The reason those are spelled that way is because they are ported from Java. And IMHO that “Java flavor” is a bigger issue than just the names. It’s the whole structure. So if we’re going to touch those, let’s make a Pythonic API, with PEP 8 compliant names, instead :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EUUCMWTMTAK2AWWDHYRNBBHEDOQIP63Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Thu, Nov 11, 2021 at 10:06:45PM -0500, Ricky Teachey wrote: > Is there a standard idiom-- perhaps using a type-hint-- to signal to the > IDE/linter that my user-defined class is intended to be used as a > function/factory, and not as a type (even though it is in fact a type)? Not really. I don't think there is even a standard idiom for the human reader to decide whether something is used as a "function" or a "class". It is subjective, based on usage and convention. As others have pointed out, many functions in Python can be considered as class constructor: ord(number) # constructs a string even traditional functional programming, er, functions like map: map(func, iterable) # returns a map object I think that the best I can come up with is that if your class has a constructor that attaches input arguments (with or without additional processing) as attributes, then it might be considered "class-like". Something like this: class C: def __new__(cls, arg): obj = super().__new__(cls) obj.attribute = arg return obj or equivalently: class C: def __init__(self, arg): self.attribute = arg But if it looks like more this: class C: def __new__(cls, arg): obj = _convert(arg) # possibly call a dunder method? return obj then it is probably "function-like". But honestly, it's subjective. Some things feel like a transformation, conversion or cast using a function, and some things feel like constructing an object, even if it is impossible to find a hard, objective, bullet-proof distinction. > Seems like if there were a standard idiom for telling the linter "this > class is really just kind of a factory, don't complain about the > lowercase", it might be kind of nice. Any decent linter should have a switch to turn off a specific check for a line of code. For example, in flake8 the error code for class names is N801, so you should be able to disable that using: # noqa: N801 https://flake8.pycqa.org/en/3.1.1/user/ignoring-errors.html https://github.com/PyCQA/pep8-naming -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EOEJVSMTCI6TO5Q5LBTIGSYAGTJ773LN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Thu, Nov 11, 2021 at 9:33 PM Ethan Furman wrote: > I think what Paul is referring to is that according to PEP 8: > > - functions: Function names should be lowercase, with words separated by > underscores as necessary >to improve readability. > > - types: Class names should normally use the CapWords convention. > > And, of course: > > - Names that are visible to the user as public parts of the API should > follow conventions that >reflect usage rather than implementation. > > > So, given those three items, should `str` be `str` because it is used > often as a function, or should it be `Str` because > it is often subclassed? > > -- > ~Ethan~ I understand why this idea got shut down faster than centrifuge-launched satellite, but I enjoyed reading the resulting thread and I learned a lot. Especially this idea which I have previously missed: - Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation. Is there a standard idiom-- perhaps using a type-hint-- to signal to the IDE/linter that my user-defined class is intended to be used as a function/factory, and not as a type (even though it is in fact a type)? Unaware of the "reflected usage" guidelines, I have done this in the past: class _Spam: ... # todo def spam(*args): return _Spam(*args) I haven't done this often; usually it hasn't made much sense to bury the implementation into a private class like this. Most often it has been because I don't want to commit a class interface as the long term API; want to leave room to change my mind later. Seems like if there were a standard idiom for telling the linter "this class is really just kind of a factory, don't complain about the lowercase", it might be kind of nice. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2POVEQWMHPWYVPXOYU4LN3P26ON5DBNA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] [Python-Dev] Adding pep-8-casing-compliant aliases for unittest and logging
On 11/11/21 11:53 AM, Matt del Valle wrote: Okay, so from the replies so far it looks like this is very quickly going into the 'never gonna happen' dumpster, so in the interests of salvaging *something* out of it: [...] I just dislike having to settle for 'it's what we've got'. With these two modules in particular, a lot of the arguments that have been made so far either don't apply or are not as strong (such as the confusion of having builtins.list, builtins.List and typing.List). Additionally, these are significantly more ancillary portions of the stdlib than the builtins, much less likely to cause as severe of a disruption (I personally don't believe a backward-compatible change like this which only adds aliases would be as disruptive as many people claim, but concede that that's subjective), and much less likely to have the implementation change so drastically as to want to change out types for factory functions or vice-versa. So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and unittest modules [...] +1 I would happily change all my unittest and logging usage to snake case if those aliases existed. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JZVMZDG4NBUWLMFHHV3DBTTVDSSLWBYT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
I think what Paul is referring to is that according to PEP 8: - functions: Function names should be lowercase, with words separated by underscores as necessary to improve readability. - types: Class names should normally use the CapWords convention. And, of course: - Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation. So, given those three items, should `str` be `str` because it is used often as a function, or should it be `Str` because it is often subclassed? -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PD5FIL4UM7MYASYMG6DD6BKONBFDZDGV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python history [was Re: Re: Adding pep8-casing-compliant aliases for the entire stdlib]
On Fri, Nov 12, 2021 at 11:47 AM Steven D'Aprano wrote: > > I know this suggestion is withdrawn and the thread all but finished, but > for completion, I'd like to answer one of Chris' questions: > > On Fri, Nov 12, 2021 at 04:48:58AM +1100, Chris Angelico wrote: > > > I'll have to get someone else to confirm, but I believe that str, int, > > etc were functions for a lot of Python's history. > > I don't know if the first eleven years counts as "a lot" of Python's > history (it's about 1/3rd of Python's existence at this point), but in > Python 1.x and some of 2.x, str, int, float, list etc were all actual > functions and couldn't be subclassed: > > It wasn't until Python 2.2 that builtin types and classes were unified, > becoming the same thing; the functions str, int, etc became classes; and > every object in Python was consolidated into a single heirarchy with > `object` as the root. > > https://www.python.org/download/releases/2.2.3/descrintro/ > Thanks, that's what I was thinking of. Most notably, we have several independent occasions when a builtin function was replaced with a class that could be used in all the same ways: Python 2.2 for str/int etc, Python 3.0 for range/map/zip, and I can't recall others right now, but there probably have been. BTW, when I said "someone else" there, I was thinking of you and your history lessons, so, thank you :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XBHKWBWTZT2OQXFQVLX7YUN67JP466FZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python history [was Re: Re: Adding pep8-casing-compliant aliases for the entire stdlib]
I know this suggestion is withdrawn and the thread all but finished, but
for completion, I'd like to answer one of Chris' questions:
On Fri, Nov 12, 2021 at 04:48:58AM +1100, Chris Angelico wrote:
> I'll have to get someone else to confirm, but I believe that str, int,
> etc were functions for a lot of Python's history.
I don't know if the first eleven years counts as "a lot" of Python's
history (it's about 1/3rd of Python's existence at this point), but in
Python 1.x and some of 2.x, str, int, float, list etc were all actual
functions and couldn't be subclassed:
[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704 (Red
Hat 4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>
>>> class MyString(str): pass
...
Traceback (innermost last):
File "", line 1, in ?
TypeError: base is not a class object
>>>
>>> type(str)
There were two distinct object heirarchies. Builtin *types* str, int ...
were different kinds of objects to the classes and instances you created
with the `class` keyword.
>>> type(type('a'))
>>>
>>> class C: pass
...
>>> type(C)
It wasn't until Python 2.2 that builtin types and classes were unified,
becoming the same thing; the functions str, int, etc became classes; and
every object in Python was consolidated into a single heirarchy with
`object` as the root.
https://www.python.org/download/releases/2.2.3/descrintro/
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/G2TYMDMIKVOZG2355OAFCTMK5AXGAIQN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On 2021-11-11 09:48, Chris Angelico wrote: This isn't the first time someone has had false expectations about PEP 8 and the standard library. I'm seriously wondering if flake8 does more harm than good by being so strict. I think this is a big part of the problem. There are various tools out there (flake8 being one of them) that purport to "improve" or "fix" your code (or warn you to do it yourself), and various companies and organizations that adopt policies tied to those tools (e.g., "your pull request must pass this PEP 8 linter to be accepted"). It's a big problem. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MG5BRM3K7GSLP2ZC6JXM2HLIBP5S4API/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Thu, 11 Nov 2021 at 22:22, Brendan Barnwell wrote: > > On 2021-11-11 09:33, Paul Moore wrote: > > I understand that. However, PEP 8 states "Names that are visible to > > the user as public parts of the API should > > follow conventions that reflect*usage* rather than*implementation*." > > (My emphasis) I quoted this, but you cut that part of my post. > > I'm not the one who previously replied to your earlier post, but I > still don't really understand what the relevance of this is. EVERY > class can be used like a function (barring perhaps a few oddities like > None). So the fact that you see a name used like `str(this)` or > `list(that)` or `some_name(a, b, c)` doesn't tell you anything about > "usage". That syntax is completely consistent with usage as a class and > as a function. Chris Angelico made the point far better than I've managed to, and in any case the thread is basically finished at this point, so I won't say anything more other than to quote Chris and say "this is what I was trying to say": > The distinction between "this is a type" and "this is a function" is > often relatively insignificant. The crux of your proposal is that it > should be more significant, and that the fundamental APIs of various > core Python callables should reflect this distinction. This is a lot > of churn and only a philosophical advantage, not a practical one. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X7AV7WMDISAZSADHQT7XJ3AFYIMGD5TE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On 2021-11-11 09:33, Paul Moore wrote: I understand that. However, PEP 8 states "Names that are visible to the user as public parts of the API should follow conventions that reflect*usage* rather than*implementation*." (My emphasis) I quoted this, but you cut that part of my post. I'm not the one who previously replied to your earlier post, but I still don't really understand what the relevance of this is. EVERY class can be used like a function (barring perhaps a few oddities like None). So the fact that you see a name used like `str(this)` or `list(that)` or `some_name(a, b, c)` doesn't tell you anything about "usage". That syntax is completely consistent with usage as a class and as a function. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6GIJE5NJ2PRALNGS2TZIBUEYGMBZKT2D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
> > One thought: No. > I was still typing out my last reply when you wrote this Guido. With that I think I will officially retract the entire suggestion. Though I'm disappointed because casing-consistency is one of those things I care about far more than I probably should (I couldn't explain the why, I just do), I respect your opinion massively as I'm sure most of our community does, so I don't see any benefit in continuing the discussion if you're soundly against it. Thanks to everyone who chimed in with their opinions, have a good rest of your day :) On Thu, Nov 11, 2021 at 7:53 PM Guido van Rossum wrote: > One thought: No. > > On Thu, Nov 11, 2021 at 05:41 Matt del Valle wrote: > >> So I was reading the docs for the `threading` module and I stumbled upon >> this little note: >> >> Note: >> >> In the Python 2.x series, this module contained camelCase names for some >> methods and functions. These are deprecated as of Python 3.10, but they are >> still supported for compatibility with Python 2.5 and lower. >> >> >> And it got me thinking. >> >> Given that there is some precedent, would it be feasible to make a >> concerted effort to add aliases across the board for all public-facing >> stdlib types and functions that don't follow pep8-recommended casing? >> >> I realize that large chunks of the stdlib predates pep8 and therefore use >> various non-uniform conventions. For example, the logging module is fully >> camelCased, and many core types like `str` and `list` don't use PascalCase >> as pep8 recommends. The `collections` module is a veritable mosaic of >> casing conventions, with some types like `deque` and `namedtuple` being >> fully lowercased while others like `Counter` and `ChainMap` are PascalCased. >> >> >> My motivation for this twofold: >> >> 1) I'll confess that this has just always been a wart that has bothered >> me way more than it has any right to. I just *hate* it. Somewhere deep >> inside my lizard-brain it makes me unhappy to have disparate naming >> conventions in my code. I realize this isn't a good reason in and of itself >> but I wonder if this might not be the case for others as well. While I've >> come to accept it because that's just how it is, maybe it doesn't have to >> be this way? >> >> 2) It's always been an extra thing to explain when teaching python to >> someone. I always try to cover pep8 very early to discourage people I'm >> training from internalizing bad habits, and it means you have to explain >> that the very standard library itself contains style violations that would >> get flagged in most modern code reviews, and that they just have to keep in >> mind that despite the fact that the core language does it, they should not. >> >> >> So the scope of my suggestion is as follows: >> >> - lowercase types become PascalCase (e.g., `str` -> `Str`, >> `collections.defaultdict` -> `collections.DefaultDict`) >> >> - lowercase attributes/functions/methods become snake_case (no changes >> for names that only contain a single word, so `str.lower()` would be >> unaffected, but `str.removeprefix()` would get the alias >> `str.remove_prefix()`) >> >> - pep8 and the python docs are updated to state that the pep8-compliant >> forms of stdlib names should be strongly preferred over the legacy names, >> and that IDEs and linters should include (configurable?) weak warnings to >> discourage the use of legacy-cased stdlib names >> >> - `help()` would be special-cased for builtin types to no longer display >> any current non-pep8-compliant names, and the python docs would also no >> longer show them, instead only making a note at the top of the page as with >> the `threading` module. >> >> >> Given the horrors of the python 2.7 schism I don't think there's any rush >> to officially deprecate or remove the current non-pep8 names at all. I >> think that's the sort of thing that can happily and fully be kicked down >> the road. >> >> If we add aliases and they see widespread adoption to the point where the >> non-pep8 forms are barely ever even seen out in the wild then maybe in 10 >> or 20 years time when the steering council is deliberating on a new major >> python version they can consider rolling the removal of legacy badly-cased >> names into it. And if not then no big deal. >> >> So yeah, thoughts? >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
Okay, so from the replies so far it looks like this is very quickly going into the 'never gonna happen' dumpster, so in the interests of salvaging *something* out of it: > I'm a -1 on this proposal, as I don't see any way of doing it that > wouldn't cause a huge amount of disruption. Yes, the situation — especially > with regard to unittest and logging — is far from ideal. But, it's what > we've got. See, I just dislike having to settle for 'it's what we've got'. With these two modules in particular, a lot of the arguments that have been made so far either don't apply or are not as strong (such as the confusion of having builtins.list, builtins.List and typing.List). Additionally, these are significantly more ancillary portions of the stdlib than the builtins, much less likely to cause as severe of a disruption (I personally don't believe a backward-compatible change like this which only adds aliases would be as disruptive as many people claim, but concede that that's subjective), and much less likely to have the implementation change so drastically as to want to change out types for factory functions or vice-versa. So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and unittest modules (and any other places in the stdlib where camelCase names still exist), and leave the lowercase names alone. I'm realizing that I actually just plain forgot to list converting camelCase modules to snake_case as one of the bullet-points in the original post. That was an oversight, I did fully intend that to also be in scope. I'm very much of the philosophy of not letting perfect be the enemy of good (and yes, I know that my 'good' might be your 'evil', that's life), so if we can at least get modules like logging and unittest offering snake_case aliases for all their names I would call that at least a moderate win. With that out of the way, I'll just address a few other points: Yes, it IS an argument against any change, and the question is: how > strong are the arguments in favour of the change? With new syntax or > APIs, the advantage is the increased expressiveness; with this, it's > the exact same thing, but spelled differently. So your choices are (a) > the thing that works all the way back to Python 2.x and will continue > to work in the future; or (b) the otherwise-identical thing that only > works from version X onwards. There's no incentive to move, so people > won't move, so the bulk of code out there will continue to use the > existing names. > I think saying there's no advantage is definitely a bit uncharitable. There's a gain in consistency and clarity, less surprises, and a lower cognitive load (that's the entire point of casing conventions, just by looking at a name you can glean some information about what sort of thing it references). And I think you're 100% wrong about people not switching to new names over time, especially if linters started flagging the old names as warnings and the 'best-practices' recommendation became using the new names. Someone mentioned a 20-year-old codebase too large to ever refactor, because the clients would be unwilling to pay for refactors that add no functionality. This is the exception, not the rule. I doubt even 5% of applications written in python are run for 20 years, and long-lived libraries usually have at least one or two major versions with large internal refactors over timescales that large. But that's all irrelevant anyway, because I'm not proposing removing the existing names. No backwards-compatibility will be harmed, and such projects will be able to happily go on using legacy names forever if they choose. Since most code is a lot more short-lived than that we would likely be in a position where a majority of code being actively *run* in the wild would use the new names within 15-20 years, and the vast majority of *new code* being written would be using them. They're not the strongest argument. The strongest argument is churn - > lots and lots of changes for zero benefit. > I must not be understanding what you mean by churn in this context, because to me this seems quite minor in terms of changes. >From the implementation side: - A one-time addition of aliases to the stdlib - If something is deprecated/removed/renamed in the future it's alias would also have to be removed - That's it, there wouldn't be any maintenance needed beyond that, new additions would just use pep8-compliant casing >From the usage side: - When writing new code, prefer the new names. You'll even be helpfully nudged along by your IDE - *If* you choose to do so, optionally do a refactor pass to change existing names in your current projects/codebases. If you choose not to, just relax your linter's legacy-name check so it doesn't bother you. The last bullet-point is the big one where I can see the argument that there would be a lot of churn. But the key thing is it's fully optional. As long as *new code* tends to use the aliases
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
One thought: No. On Thu, Nov 11, 2021 at 05:41 Matt del Valle wrote: > So I was reading the docs for the `threading` module and I stumbled upon > this little note: > > Note: > > In the Python 2.x series, this module contained camelCase names for some > methods and functions. These are deprecated as of Python 3.10, but they are > still supported for compatibility with Python 2.5 and lower. > > > And it got me thinking. > > Given that there is some precedent, would it be feasible to make a > concerted effort to add aliases across the board for all public-facing > stdlib types and functions that don't follow pep8-recommended casing? > > I realize that large chunks of the stdlib predates pep8 and therefore use > various non-uniform conventions. For example, the logging module is fully > camelCased, and many core types like `str` and `list` don't use PascalCase > as pep8 recommends. The `collections` module is a veritable mosaic of > casing conventions, with some types like `deque` and `namedtuple` being > fully lowercased while others like `Counter` and `ChainMap` are PascalCased. > > > My motivation for this twofold: > > 1) I'll confess that this has just always been a wart that has bothered me > way more than it has any right to. I just *hate* it. Somewhere deep > inside my lizard-brain it makes me unhappy to have disparate naming > conventions in my code. I realize this isn't a good reason in and of itself > but I wonder if this might not be the case for others as well. While I've > come to accept it because that's just how it is, maybe it doesn't have to > be this way? > > 2) It's always been an extra thing to explain when teaching python to > someone. I always try to cover pep8 very early to discourage people I'm > training from internalizing bad habits, and it means you have to explain > that the very standard library itself contains style violations that would > get flagged in most modern code reviews, and that they just have to keep in > mind that despite the fact that the core language does it, they should not. > > > So the scope of my suggestion is as follows: > > - lowercase types become PascalCase (e.g., `str` -> `Str`, > `collections.defaultdict` -> `collections.DefaultDict`) > > - lowercase attributes/functions/methods become snake_case (no changes for > names that only contain a single word, so `str.lower()` would be > unaffected, but `str.removeprefix()` would get the alias > `str.remove_prefix()`) > > - pep8 and the python docs are updated to state that the pep8-compliant > forms of stdlib names should be strongly preferred over the legacy names, > and that IDEs and linters should include (configurable?) weak warnings to > discourage the use of legacy-cased stdlib names > > - `help()` would be special-cased for builtin types to no longer display > any current non-pep8-compliant names, and the python docs would also no > longer show them, instead only making a note at the top of the page as with > the `threading` module. > > > Given the horrors of the python 2.7 schism I don't think there's any rush > to officially deprecate or remove the current non-pep8 names at all. I > think that's the sort of thing that can happily and fully be kicked down > the road. > > If we add aliases and they see widespread adoption to the point where the > non-pep8 forms are barely ever even seen out in the wild then maybe in 10 > or 20 years time when the steering council is deliberating on a new major > python version they can consider rolling the removal of legacy badly-cased > names into it. And if not then no big deal. > > So yeah, thoughts? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M2H6J7ABPKJNQGJBEDI4M5PLMRJ6EHXY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Fri, Nov 12, 2021 at 2:22 AM Matt del Valle wrote: >> >> ISTM that this indicates that you're putting too much focus on PEP 8 >> too early. At no time does the document ever state that all Python >> code ever written must comply with it. New Python programmers should >> not feel like they're being forced into a naming convention. > > > That's fair enough for people learning python as a hobby or in a context > that's a bit more casual than agile. I generally find myself training > junior/graduate people with OOP backgrounds other than Python (Java, C#, > etc.) for my data engineering team and pep8-compliance is quite important, > because they won't even be able to successfully make commits unless they can > pass the flake8 pre-commit hook, let alone get as far as a merge review. So > I'd say that pep8 is quite important from the get-go. > To clarify: Your pre-commit hook is what is mandating this. Not Python. If your organization has this requirement, then it is your organization's decision how to do things. I suspect that the vast majority of Python programmers do not have pre-commit hooks that run flake8 (though I don't have stats). PEP 8 is incredibly important precisely because your organization has made it so. >> Pop quiz: Which of these are types and which are functions (or something >> else)? >> >> bool, classmethod, divmod, enumerate, globals, map, property, sorted, super, >> zip >> collections.deque, collections.namedtuple >> >> Does it even matter? Especially: does it matter enough to force a name >> change if a function is replaced with a type, or vice versa? > > > I'd argue this is actually a point *in favor* of the proposal rather than > against. In going through your list I actually discovered lots of things I > found extremely surprising (collections.deque is a type as I expected whereas > collections.namedtuple is actually a factory function). > Not all of those have been the same at all times. For instance, range is a function in Python 2, but a class in 3. Should it be renamed? And I'll have to get someone else to confirm, but I believe that str, int, etc were functions for a lot of Python's history. > If pep8 had been introduced at the dawn of (python-)time and the stdlib had > been designed with pep8-compliance in mind, there would be no surprise at all > on the day that I think to myself: 'Hmm, I want to subclass namedtuple, let's > try:' > > class MyNamedTuple(collections.namedtuple): > ... > > and discover that it doesn't work. A lot of people want this (or the similar concept "isinstance(x, collections.namedtuple)"), and it doesn't work because namedtuple is a category of classes, rather than a class itself. But suppose that were to change in the future - if namedtuple becomes a superclass or metaclass, and is then a type instead of a function. Does it immediately have to be renamed NamedTuple, or should it remain as it is? The churn has no value. >> Wait, are you deprecating them or not? I'm confused. Earlier you were >> saying that you clearly wanted to stop people from using the old >> names, but now you're saying there's no rush to deprecate them. > > > This is a semantic misunderstanding, I should have been clearer. In my head, > 'officially deprecating' something means saying that it will *definitely* be > removed in the future, and optionally specifying the precise date at which it > will be removed. Since my suggestion doesn't necessarily involve ever > actually removing the current names from the language (only potentially, if a > future steering council decides to as part of a future proposal), I didn't > consider this to be deprecating them, exactly. Hopefully that's cleared up. > Sorry for the confusing wording. > Understood. In this case, it sounds like you ARE deprecating them, but without a specific removal date. >> Suppose that these aliases were added in Python 3.11. Anyone who wants >> to write code compatible with 3.10 would want to continue using the >> existing names, and since the existing names would keep on being >> supported for the foreseeable future, there would be little incentive >> to change until several versions have passed. At that point, both >> names might start being used in parallel (we're talking probably 2025 >> or thereabouts, although it might start sooner if people are also >> using syntactic features from 3.11+), but it would take a VERY long >> time for adoption to the level that the older names are "barely ever >> even seen". Probably never. > > > This is an argument that can be made for any change ever made to python, and > consequently I think it's an extremely weak argument. Why change anything if > people won't be confident using it for at least 5 years because of > compatibility concerns with current language versions? Well, as it turns out > time passes and eventually that distant 5-year mark is in the past. I just > checked and... wow yeah f-strings were introduced in 2016! Feels like only
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Thu, 11 Nov 2021 at 17:13, Carl Meyer wrote: > > I'm also -1 on churning the stdlib in search of a global consistency > that PEP 8 itself disavows, but this particular argument against it > doesn't make sense: > > On Thu, Nov 11, 2021 at 9:14 AM Paul Moore wrote: > > To examine some specific cases, lists are a type, but list(...) is a > > function for constructing lists. The function-style usage is far more > > common than the use of list as a type name (possibly depending on how > > much of a static typing advocate you are...). So "list" should be > > lower case by that logic, and therefore according to PEP 8. And str() > > is a function for getting the string representation of an object as > > well as being a type - so should it be "str" or "Str"? That's at best > > a judgement call (usage is probably more evenly divided in this case), > > but PEP 8 supports both choices. Or to put it another way, "uniform" > > casing is a myth, if you read PEP 8 properly. > > Any type can be called to construct an instance of that type. If I > define a class Foo, I create an instance of Foo by calling `Foo(...)`. > `list` and `str` are no different; I can create an instance of the > type by calling it. This doesn't mean they are "both a type and a > function" in some unusual way, it just means that we always call types > in order to construct instances of them. I understand that. However, PEP 8 states "Names that are visible to the user as public parts of the API should follow conventions that reflect *usage* rather than *implementation*." (My emphasis) I quoted this, but you cut that part of my post. My point here is that how you interpret "usage" is far from clear - I'm sure that a lot of people would teach str(...) as a function that creates a string representation of an object, deferring the detail that it's actually a type, and you can call a type to create objects of that type until later. So would a newcomer necessarily know (or even need to know) that str is a type, not a function? There's also the case of changing implementation between a class and a factory function - surely that should not require a compatibility-breaking name change? The key is that it's fairly easy to argue "reasonable doubt" here - PEP 8 is intended to be applied with a certain level of judgement, not as a set of absolute rules. But yes, I didn't make my point particularly clearly, I apologise. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2A5OB3Q7GRRPZD2BKBGF2EMAPPJIKBJ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
El jue, 11 nov 2021 a las 5:41, Matt del Valle () escribió: > So I was reading the docs for the `threading` module and I stumbled upon > this little note: > > Note: > > In the Python 2.x series, this module contained camelCase names for some > methods and functions. These are deprecated as of Python 3.10, but they are > still supported for compatibility with Python 2.5 and lower. > > > And it got me thinking. > > Given that there is some precedent, would it be feasible to make a > concerted effort to add aliases across the board for all public-facing > stdlib types and functions that don't follow pep8-recommended casing? > > > Like most people commenting here, I'm not excited about this proposal. I have some concrete experience to add: In the threading module, we did rename a number of methods to snake_case for Python 3, but kept the old camelCase names around. I worked on explicitly deprecating some of those names (https://bugs.python.org/issue43723), because the documentation already claimed they were going to be deprecated, and in retrospect I don't feel like that was a very useful contribution. It just introduces churn to a bunch of codebases and makes it harder to write multiversion code. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MMODNBXXVPGISCID2LND32B6TO6ZRK6B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
I'm also -1 on churning the stdlib in search of a global consistency that PEP 8 itself disavows, but this particular argument against it doesn't make sense: On Thu, Nov 11, 2021 at 9:14 AM Paul Moore wrote: > To examine some specific cases, lists are a type, but list(...) is a > function for constructing lists. The function-style usage is far more > common than the use of list as a type name (possibly depending on how > much of a static typing advocate you are...). So "list" should be > lower case by that logic, and therefore according to PEP 8. And str() > is a function for getting the string representation of an object as > well as being a type - so should it be "str" or "Str"? That's at best > a judgement call (usage is probably more evenly divided in this case), > but PEP 8 supports both choices. Or to put it another way, "uniform" > casing is a myth, if you read PEP 8 properly. Any type can be called to construct an instance of that type. If I define a class Foo, I create an instance of Foo by calling `Foo(...)`. `list` and `str` are no different; I can create an instance of the type by calling it. This doesn't mean they are "both a type and a function" in some unusual way, it just means that we always call types in order to construct instances of them. Carl ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ISP5JXS4EPI4HV4GDZXKYBIPURJAZIGR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
The cost of having two ways to name things for the indefinite future is too high. Not only would you have to maintain it in the various Python implementations, you'd have to explain why code uses "str" or "Str", or both. The costs of migration are also too high. I personally work on a 20 year old proprietary python code base that would never be updated for a change like this. Unless you plan on breaking it in another 20 years (and I do expect it to still be running then), the old names can never go away. Maybe if there was an automated tool, the migration to the new names would be possible. You'd need a tool that's smarter than 2to3 in order to update code like: "str = 'foo'". But even if a perfect tool existed, it would take man-months and many tens of thousands of dollars to test such a large code base. My clients are understandably unwilling to do that for no functional gain. So, like many things in Python[0], the various naming conventions across modules and time is just something we're going to have to live with. Eric [0]: One tiny example of many: I wish I hadn't added dataclasses.asdict and .astuple, but now I've got to live with it. On 11/11/2021 8:41 AM, Matt del Valle wrote: So I was reading the docs for the `threading` module and I stumbled upon this little note: Note: In the Python 2.x series, this module contained |camelCase| names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 and lower. And it got me thinking. Given that there is some precedent, would it be feasible to make a concerted effort to add aliases across the board for all public-facing stdlib types and functions that don't follow pep8-recommended casing? I realize that large chunks of the stdlib predates pep8 and therefore use various non-uniform conventions. For example, the logging module is fully camelCased, and many core types like `str` and `list` don't use PascalCase as pep8 recommends. The `collections` module is a veritable mosaic of casing conventions, with some types like `deque` and `namedtuple` being fully lowercased while others like `Counter` and `ChainMap` are PascalCased. My motivation for this twofold: 1) I'll confess that this has just always been a wart that has bothered me way more than it has any right to. I just /hate/ it. Somewhere deep inside my lizard-brain it makes me unhappy to have disparate naming conventions in my code. I realize this isn't a good reason in and of itself but I wonder if this might not be the case for others as well. While I've come to accept it because that's just how it is, maybe it doesn't have to be this way? 2) It's always been an extra thing to explain when teaching python to someone. I always try to cover pep8 very early to discourage people I'm training from internalizing bad habits, and it means you have to explain that the very standard library itself contains style violations that would get flagged in most modern code reviews, and that they just have to keep in mind that despite the fact that the core language does it, they should not. So the scope of my suggestion is as follows: - lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`) - lowercase attributes/functions/methods become snake_case (no changes for names that only contain a single word, so `str.lower()` would be unaffected, but `str.removeprefix()` would get the alias `str.remove_prefix()`) - pep8 and the python docs are updated to state that the pep8-compliant forms of stdlib names should be strongly preferred over the legacy names, and that IDEs and linters should include (configurable?) weak warnings to discourage the use of legacy-cased stdlib names - `help()` would be special-cased for builtin types to no longer display any current non-pep8-compliant names, and the python docs would also no longer show them, instead only making a note at the top of the page as with the `threading` module. Given the horrors of the python 2.7 schism I don't think there's any rush to officially deprecate or remove the current non-pep8 names at all. I think that's the sort of thing that can happily and fully be kicked down the road. If we add aliases and they see widespread adoption to the point where the non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or 20 years time when the steering council is deliberating on a new major python version they can consider rolling the removal of legacy badly-cased names into it. And if not then no big deal. So yeah, thoughts? ___ Python-ideas mailing list --python-ideas@python.org To unsubscribe send an email topython-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
I'm a -1 on this proposal, as I don't see any way of doing it that wouldn't cause a huge amount of disruption. Yes, the situation — especially with regard to unittest and logging — is far from ideal. But, it's what we've got.However I'm -100 on doing something like this while there already exist a large number of camelcase typing-module aliases for classes found elsewhere in the stdlib. It's already confusing enough to have `builtins.list` and `typing.List` be different objects. Under this proposal, we'd have `builtins.list`, `builtins.List`, and `typing.List`. Two of these objects would have the same identity, but it wouldn't be the two that are spelt the same. To my mind, this would be appalling.Yes, the aliases in the typing module are all deprecated, but they're still very widely used.Best, Alex Original message From: Matt del Valle Date: 11/11/2021 13:44 (GMT+00:00) To: Python-Ideas Subject: [Python-ideas] Adding pep8-casing-compliant aliases for the entire stdlib So I was reading the docs for the `threading` module and I stumbled upon this little note: Note: In the Python 2.x series, this module contained camelCase names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 and lower.And it got me thinking.Given that there is some precedent, would it be feasible to make a concerted effort to add aliases across the board for all public-facing stdlib types and functions that don't follow pep8-recommended casing?I realize that large chunks of the stdlib predates pep8 and therefore use various non-uniform conventions. For example, the logging module is fully camelCased, and many core types like `str` and `list` don't use PascalCase as pep8 recommends. The `collections` module is a veritable mosaic of casing conventions, with some types like `deque` and `namedtuple` being fully lowercased while others like `Counter` and `ChainMap` are PascalCased.My motivation for this twofold:1) I'll confess that this has just always been a wart that has bothered me way more than it has any right to. I just hate it. Somewhere deep inside my lizard-brain it makes me unhappy to have disparate naming conventions in my code. I realize this isn't a good reason in and of itself but I wonder if this might not be the case for others as well. While I've come to accept it because that's just how it is, maybe it doesn't have to be this way?2) It's always been an extra thing to explain when teaching python to someone. I always try to cover pep8 very early to discourage people I'm training from internalizing bad habits, and it means you have to explain that the very standard library itself contains style violations that would get flagged in most modern code reviews, and that they just have to keep in mind that despite the fact that the core language does it, they should not.So the scope of my suggestion is as follows:- lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`)- lowercase attributes/functions/methods become snake_case (no changes for names that only contain a single word, so `str.lower()` would be unaffected, but `str.removeprefix()` would get the alias `str.remove_prefix()`)- pep8 and the python docs are updated to state that the pep8-compliant forms of stdlib names should be strongly preferred over the legacy names, and that IDEs and linters should include (configurable?) weak warnings to discourage the use of legacy-cased stdlib names- `help()` would be special-cased for builtin types to no longer display any current non-pep8-compliant names, and the python docs would also no longer show them, instead only making a note at the top of the page as with the `threading` module.Given the horrors of the python 2.7 schism I don't think there's any rush to officially deprecate or remove the current non-pep8 names at all. I think that's the sort of thing that can happily and fully be kicked down the road. If we add aliases and they see widespread adoption to the point where the non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or 20 years time when the steering council is deliberating on a new major python version they can consider rolling the removal of legacy badly-cased names into it. And if not then no big deal.So yeah, thoughts? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6667GUFX36JTGD433KPPOPWVQV444GNW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
Let's just say up front that I'm a strong -1 on this proposal, as I think it is needless churn, and while it may be *technically* backward compatible, in reality it will be immensely disruptive. There's one particular point I want to pick up on, though. On Thu, 11 Nov 2021 at 15:25, Matt del Valle wrote: > If we went to a disconnected alternate universe where python had never been > invented and introduced it today, in 2021, would we introduce it with a > uniform naming convention, or the historical backwards-supporting mishmash of > casing we've ended up with? Since I think the answer is pretty clear, I'm > strongly in favor of making this minimally-invasive change that at least > works towards uniform casing, even if that dizzying utopia is far beyond the > horizon. Our grandchildren might thank us :p Certainly, there's a lot of inconsistency that can only be justified as historical baggage. There have been a number of proposals to "tidy up" such cases, but even when focused on specific instances, the general conclusion has been that this would be too disruptive. But let's put that aside and address the broader question here. Yes, if we'd been designing everything now, we quite probably would have adopted a more consistent approach. But I think it's foolish to assume that whatever convention we defined for names would be strictly based on the type of the value. After all, even if you adopt a no-compromises stance on PEP 8 (a stance that the PEP itself rejects, by the way!) the first part of the "Naming Conventions" section says """ Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation. """ To examine some specific cases, lists are a type, but list(...) is a function for constructing lists. The function-style usage is far more common than the use of list as a type name (possibly depending on how much of a static typing advocate you are...). So "list" should be lower case by that logic, and therefore according to PEP 8. And str() is a function for getting the string representation of an object as well as being a type - so should it be "str" or "Str"? That's at best a judgement call (usage is probably more evenly divided in this case), but PEP 8 supports both choices. Or to put it another way, "uniform" casing is a myth, if you read PEP 8 properly. What you actually seem to be arguing for is a renaming based on a hypothetical version of PEP 8 that is far stricter than the actual document, and which doesn't take into account the messiness of real-world APIs and applications. That's a very common, and in my opinion misguided, stance. For me, one of the best things about PEP 8 is its repeated assertions that the "rules" it defines are only guidelines and that they should not be imposed blindly, but programmer judgement should always take precedence. I find it very frustrating that people making a fuss about "following PEP 8" seem completely blind to the whole of the section "A Foolish Consistency is the Hobgoblin of Little Minds" (one part of which explicitly says that the PEP does not justify adding or changing code just to follow guidelines that were created after the code was written), and the *many* places where the PEP offers two (or sometimes even more) alternatives, without preferring one over the other. As I said, I'm -1 on this proposal. Paul PS If you are really committed to an alternative naming convention, you can always write a module that adds all of the aliases you might want. That way, you can follow your own preferences without imposing them on everyone else... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/D56P72COERVXLYWADMM76JYI4EFSC27T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On 11/11/2021 14.41, Matt del Valle wrote: So the scope of my suggestion is as follows: - lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`) - lowercase attributes/functions/methods become snake_case (no changes for names that only contain a single word, so `str.lower()` would be unaffected, but `str.removeprefix()` would get the alias `str.remove_prefix()`) - pep8 and the python docs are updated to state that the pep8-compliant forms of stdlib names should be strongly preferred over the legacy names, and that IDEs and linters should include (configurable?) weak warnings to discourage the use of legacy-cased stdlib names - `help()` would be special-cased for builtin types to no longer display any current non-pep8-compliant names, and the python docs would also no longer show them, instead only making a note at the top of the page as with the `threading` module. Given the horrors of the python 2.7 schism I don't think there's any rush to officially deprecate or remove the current non-pep8 names at all. I think that's the sort of thing that can happily and fully be kicked down the road. If we add aliases and they see widespread adoption to the point where the non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or 20 years time when the steering council is deliberating on a new major python version they can consider rolling the removal of legacy badly-cased names into it. And if not then no big deal. Adding new APIs or replacing existing APIs for PEP 8 style-compliance would be a violation of PEP 8. The PEP 8 document states that consistency, readability, and backwards compatibility are more important than naming and style conventions. By **not** applying PEP 8 style to existing code, CPython stays PEP 8 compliant. https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QBNMSU6AI2UUZ5ZEFDM7SD5VOGZSZ27B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
> ISTM that this indicates that you're putting too much focus on PEP 8 > too early. At no time does the document ever state that all Python > code ever written must comply with it. New Python programmers should > not feel like they're being forced into a naming convention. > That's fair enough for people learning python as a hobby or in a context that's a bit more casual than agile. I generally find myself training junior/graduate people with OOP backgrounds other than Python (Java, C#, etc.) for my data engineering team and pep8-compliance is quite important, because they won't even be able to successfully make commits unless they can pass the flake8 pre-commit hook, let alone get as far as a merge review. So I'd say that pep8 is quite important from the get-go. Pop quiz: Which of these are types and which are functions (or something > else)? > > bool, classmethod, divmod, enumerate, globals, map, property, sorted, > super, zip > collections.deque, collections.namedtuple > > Does it even matter? Especially: does it matter enough to force a name > change if a function is replaced with a type, or vice versa? > I'd argue this is actually a point *in favor* of the proposal rather than against. In going through your list I actually discovered lots of things I found extremely surprising (collections.deque is a type as I expected whereas collections.namedtuple is actually a factory function). If pep8 had been introduced at the dawn of (python-)time and the stdlib had been designed with pep8-compliance in mind, there would be no surprise at all on the day that I think to myself: 'Hmm, I want to subclass namedtuple, let's try:' class MyNamedTuple(collections.namedtuple): ... and discover that it doesn't work. Are you aware that removeprefix is very new, and that the alternate > name remove_prefix was rejected? > I was aware of that, yes. The rationale was precisely to introduce it as `str.removeprefix` for consistency with alllowercase (<- which all other considerations aside can be very unreadable sometimes, that's, I assume, why pep8 prefers snake_case) which is itself in contravention of python's official style guide. This is irrelevant in the event that this proposal is accepted. Wait, are you deprecating them or not? I'm confused. Earlier you were > saying that you clearly wanted to stop people from using the old > names, but now you're saying there's no rush to deprecate them. > This is a semantic misunderstanding, I should have been clearer. In my head, 'officially deprecating' something means saying that it will *definitely* be removed in the future, and optionally specifying the precise date at which it will be removed. Since my suggestion doesn't necessarily involve ever actually removing the current names from the language (only potentially, if a future steering council decides to as part of a future proposal), I didn't consider this to be deprecating them, exactly. Hopefully that's cleared up. Sorry for the confusing wording. Suppose that these aliases were added in Python 3.11. Anyone who wants > to write code compatible with 3.10 would want to continue using the > existing names, and since the existing names would keep on being > supported for the foreseeable future, there would be little incentive > to change until several versions have passed. At that point, both > names might start being used in parallel (we're talking probably 2025 > or thereabouts, although it might start sooner if people are also > using syntactic features from 3.11+), but it would take a VERY long > time for adoption to the level that the older names are "barely ever > even seen". Probably never. > This is an argument that can be made for any change ever made to python, and consequently I think it's an extremely weak argument. Why change anything if people won't be confident using it for at least 5 years because of compatibility concerns with current language versions? Well, as it turns out time passes and eventually that distant 5-year mark is in the past. I just checked and... wow yeah f-strings were introduced in 2016! Feels like only yesterday :) Absolutely no value in adding aliases for everything, especially > things that can be shadowed. It's not hugely common, but suppose that > you deliberately shadow the name "list" in your project - now the List > alias has become disconnected from it, unless you explicitly shadow > that one as well. Conversely, a much more common practice is to > actually use the capitalized version as a variant: > > class List(list): > ... > > This would now be shadowing just one, but not the other, of the > built-ins. Confusion would abound. > I think this is a fair point, but the same can be said of people accidentally shadowing any number of other builtins (it's probably most common with builtins like `type` or `max`). Fortunately every linter/IDE I've used has had warnings for this so it should be something that happens rarely, if ever. I'd also say that subclassing list
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On Fri, Nov 12, 2021 at 12:41 AM Matt del Valle wrote: > 2) It's always been an extra thing to explain when teaching python to > someone. I always try to cover pep8 very early to discourage people I'm > training from internalizing bad habits, and it means you have to explain that > the very standard library itself contains style violations that would get > flagged in most modern code reviews, and that they just have to keep in mind > that despite the fact that the core language does it, they should not. > ISTM that this indicates that you're putting too much focus on PEP 8 too early. At no time does the document ever state that all Python code ever written must comply with it. New Python programmers should not feel like they're being forced into a naming convention. > So the scope of my suggestion is as follows: > > - lowercase types become PascalCase (e.g., `str` -> `Str`, > `collections.defaultdict` -> `collections.DefaultDict`) > Pop quiz: Which of these are types and which are functions (or something else)? bool, classmethod, divmod, enumerate, globals, map, property, sorted, super, zip collections.deque, collections.namedtuple Does it even matter? Especially: does it matter enough to force a name change if a function is replaced with a type, or vice versa? > - lowercase attributes/functions/methods become snake_case (no changes for > names that only contain a single word, so `str.lower()` would be unaffected, > but `str.removeprefix()` would get the alias `str.remove_prefix()`) > Are you aware that removeprefix is very new, and that the alternate name remove_prefix was rejected? https://www.python.org/dev/peps/pep-0616/#alternative-method-names > Given the horrors of the python 2.7 schism I don't think there's any rush to > officially deprecate or remove the current non-pep8 names at all. I think > that's the sort of thing that can happily and fully be kicked down the road. > Wait, are you deprecating them or not? I'm confused. Earlier you were saying that you clearly wanted to stop people from using the old names, but now you're saying there's no rush to deprecate them. > If we add aliases and they see widespread adoption to the point where the > non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or > 20 years time when the steering council is deliberating on a new major python > version they can consider rolling the removal of legacy badly-cased names > into it. And if not then no big deal. > That will never happen. It's still possible today to find code written for older 2.x versions, including some quite popular answers on places like Stack Overflow. Suppose that these aliases were added in Python 3.11. Anyone who wants to write code compatible with 3.10 would want to continue using the existing names, and since the existing names would keep on being supported for the foreseeable future, there would be little incentive to change until several versions have passed. At that point, both names might start being used in parallel (we're talking probably 2025 or thereabouts, although it might start sooner if people are also using syntactic features from 3.11+), but it would take a VERY long time for adoption to the level that the older names are "barely ever even seen". Probably never. > So yeah, thoughts? > Absolutely no value in adding aliases for everything, especially things that can be shadowed. It's not hugely common, but suppose that you deliberately shadow the name "list" in your project - now the List alias has become disconnected from it, unless you explicitly shadow that one as well. Conversely, a much more common practice is to actually use the capitalized version as a variant: class List(list): ... This would now be shadowing just one, but not the other, of the built-ins. Confusion would abound. In closing, I'd just like to highlight one very important section of PEP 8: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds When a style guide becomes a boat anchor, it's not doing its job. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GCYM5VYS3DFTMHQE3FKKW4KLSUUKF43B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
You're not alone—it bothers me too! I try to use them as an example of why I shouldn't obsess over all the details (a certain "hobgoblin" quote always comes to mind), but I would *always* use the more consistent version if it were to exist... On Thu, Nov 11, 2021 at 8:42 AM Matt del Valle wrote: > So I was reading the docs for the `threading` module and I stumbled upon > this little note: > > Note: > > In the Python 2.x series, this module contained camelCase names for some > methods and functions. These are deprecated as of Python 3.10, but they are > still supported for compatibility with Python 2.5 and lower. > > > And it got me thinking. > > Given that there is some precedent, would it be feasible to make a > concerted effort to add aliases across the board for all public-facing > stdlib types and functions that don't follow pep8-recommended casing? > > I realize that large chunks of the stdlib predates pep8 and therefore use > various non-uniform conventions. For example, the logging module is fully > camelCased, and many core types like `str` and `list` don't use PascalCase > as pep8 recommends. The `collections` module is a veritable mosaic of > casing conventions, with some types like `deque` and `namedtuple` being > fully lowercased while others like `Counter` and `ChainMap` are PascalCased. > > > My motivation for this twofold: > > 1) I'll confess that this has just always been a wart that has bothered me > way more than it has any right to. I just *hate* it. Somewhere deep > inside my lizard-brain it makes me unhappy to have disparate naming > conventions in my code. I realize this isn't a good reason in and of itself > but I wonder if this might not be the case for others as well. While I've > come to accept it because that's just how it is, maybe it doesn't have to > be this way? > > 2) It's always been an extra thing to explain when teaching python to > someone. I always try to cover pep8 very early to discourage people I'm > training from internalizing bad habits, and it means you have to explain > that the very standard library itself contains style violations that would > get flagged in most modern code reviews, and that they just have to keep in > mind that despite the fact that the core language does it, they should not. > > > So the scope of my suggestion is as follows: > > - lowercase types become PascalCase (e.g., `str` -> `Str`, > `collections.defaultdict` -> `collections.DefaultDict`) > > - lowercase attributes/functions/methods become snake_case (no changes for > names that only contain a single word, so `str.lower()` would be > unaffected, but `str.removeprefix()` would get the alias > `str.remove_prefix()`) > > - pep8 and the python docs are updated to state that the pep8-compliant > forms of stdlib names should be strongly preferred over the legacy names, > and that IDEs and linters should include (configurable?) weak warnings to > discourage the use of legacy-cased stdlib names > > - `help()` would be special-cased for builtin types to no longer display > any current non-pep8-compliant names, and the python docs would also no > longer show them, instead only making a note at the top of the page as with > the `threading` module. > > > Given the horrors of the python 2.7 schism I don't think there's any rush > to officially deprecate or remove the current non-pep8 names at all. I > think that's the sort of thing that can happily and fully be kicked down > the road. > > If we add aliases and they see widespread adoption to the point where the > non-pep8 forms are barely ever even seen out in the wild then maybe in 10 > or 20 years time when the steering council is deliberating on a new major > python version they can consider rolling the removal of legacy badly-cased > names into it. And if not then no big deal. > > So yeah, thoughts? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PQJNLB7UAFMWMPKJF6QLR6QLS5QF4F3Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Adding pep8-casing-compliant aliases for the entire stdlib
So I was reading the docs for the `threading` module and I stumbled upon this little note: Note: In the Python 2.x series, this module contained camelCase names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 and lower. And it got me thinking. Given that there is some precedent, would it be feasible to make a concerted effort to add aliases across the board for all public-facing stdlib types and functions that don't follow pep8-recommended casing? I realize that large chunks of the stdlib predates pep8 and therefore use various non-uniform conventions. For example, the logging module is fully camelCased, and many core types like `str` and `list` don't use PascalCase as pep8 recommends. The `collections` module is a veritable mosaic of casing conventions, with some types like `deque` and `namedtuple` being fully lowercased while others like `Counter` and `ChainMap` are PascalCased. My motivation for this twofold: 1) I'll confess that this has just always been a wart that has bothered me way more than it has any right to. I just *hate* it. Somewhere deep inside my lizard-brain it makes me unhappy to have disparate naming conventions in my code. I realize this isn't a good reason in and of itself but I wonder if this might not be the case for others as well. While I've come to accept it because that's just how it is, maybe it doesn't have to be this way? 2) It's always been an extra thing to explain when teaching python to someone. I always try to cover pep8 very early to discourage people I'm training from internalizing bad habits, and it means you have to explain that the very standard library itself contains style violations that would get flagged in most modern code reviews, and that they just have to keep in mind that despite the fact that the core language does it, they should not. So the scope of my suggestion is as follows: - lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`) - lowercase attributes/functions/methods become snake_case (no changes for names that only contain a single word, so `str.lower()` would be unaffected, but `str.removeprefix()` would get the alias `str.remove_prefix()`) - pep8 and the python docs are updated to state that the pep8-compliant forms of stdlib names should be strongly preferred over the legacy names, and that IDEs and linters should include (configurable?) weak warnings to discourage the use of legacy-cased stdlib names - `help()` would be special-cased for builtin types to no longer display any current non-pep8-compliant names, and the python docs would also no longer show them, instead only making a note at the top of the page as with the `threading` module. Given the horrors of the python 2.7 schism I don't think there's any rush to officially deprecate or remove the current non-pep8 names at all. I think that's the sort of thing that can happily and fully be kicked down the road. If we add aliases and they see widespread adoption to the point where the non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or 20 years time when the steering council is deliberating on a new major python version they can consider rolling the removal of legacy badly-cased names into it. And if not then no big deal. So yeah, thoughts? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ Code of Conduct: http://python.org/psf/codeofconduct/
