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 lon
> 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
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
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
> > 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 st
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
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
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 t
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 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
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
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 the
>
> 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 si
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
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 be
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 c
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 Pyth
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 cons
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 exist
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 Vall
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 onl
> 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
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 sta
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 a
29 matches
Mail list logo
