Neil Girdhar wrote:
> The proposal to change list and str is way too ambitious.
Maybe the uppercase versions of dict, list and tuple in the typing
module could be turned into direct aliases of the built-in types?
With Python 3.9, there is no real distinction anyway between
builtins.list and
I like this comment.
The proposal to change list and str is way too ambitious. But some minor
cleanup might not be so pernicious?
On Saturday, November 13, 2021 at 5:31:49 PM UTC-5 Mike Miller wrote:
>
> I like this idea and disappointed it always gets a negative reaction. One
> of my
>
I like this idea and disappointed it always gets a negative reaction. One of my
biggest peeves is this:
import datetime # or
from datetime import datetime
Which is often confusing... is that the datetime module or the class someone
chose at random in this module? A minor thorn
On 11/13/21 9:59 AM, Stephen J. Turnbull wrote:
Mark Mollineaux writes:
> I'll simply say that while I am disappointed that there are so many
> frictions here for whatever reason,
For your personal use, you can create a module that just does
import nonPEP8module
pep8name =
Mark Mollineaux writes:
> I'll simply say that while I am disappointed that there are so many
> frictions here for whatever reason,
For your personal use, you can create a module that just does
import nonPEP8module
pep8name = nonPEP8module.nonpep8name
...
I'll simply say that while I am disappointed that there are so many
frictions here for whatever reason, I *strongly* appreciate the work done
to update threading, I get a deep sense of satisfaction using *correct*
naming conventions whenever using this library, and am glad that it got
through
On Fri, 12 Nov 2021 at 03:46, 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
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
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
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
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
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
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
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
>
> 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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:
28 matches
Mail list logo
