code cleanup again
Tarek Ziadé
we are going to cleanup packaging as follow:
1 - run pep8 and flakes. I've done it already on the root package
(push in progress), and command/ needs a pass
2 - look for all APIs that are only used within a module and is not
useful as a public API. This is very important because once 3.3 is
out, we will be stuck with them
3 - try to simplify when possible the code
4 - kill all old-style code => add (object) for classes etc.
for 1- 3- you can install my tool "flake8", which does pyflake+flake8+
the mccabe cyclomatic complexity
Next, we need to list all the things we need to do for 3.3, and make
sure they are listed in the tracker. If you have anything in mind,
it's time to say it
Any volunteers for 1-2-3-4 ? :)
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
Éric Araujo
> 1 - run pep8 and flakes. I've done it already on the root package
> (push in progress), and command/ needs a pass
Some of the whitespace changes are strange.
> 2 - look for all APIs that are only used within a module and is not
> useful as a public API. This is very important because once 3.3 is
> out, we will be stuck with them
Yes! I wonder about methods in command classes: should they all be public?
> 4 - kill all old-style code => add (object) for classes etc.
What the? All classes are new-style in 3.x, adding object is unneeded
noise.
> for 1- 3- you can install my tool "flake8", which does pyflake+flake8+
> the mccabe cyclomatic complexity
I‘ve used the 3.x port of pyflakes. It crashes sometimes but mostly
works. I’m curious about your tool; I see linting and style checking as
very different things (and I don’t know about the mccabe thing), and as
a UNIX guy I wonder why you merged them.
Regards
Tarek Ziadé
> Hi,
>
>> 1 - run pep8 and flakes. I've done it already on the root package
>> (push in progress), and command/ needs a pass
> Some of the whitespace changes are strange.
Please be more precise.
>
>> 2 - look for all APIs that are only used within a module and is not
>> useful as a public API. This is very important because once 3.3 is
>> out, we will be stuck with them
> Yes! I wonder about methods in command classes: should they all be public?
I think the base class should determine all public methods, for most cases
>
>> 4 - kill all old-style code => add (object) for classes etc.
> What the? All classes are new-style in 3.x, adding object is unneeded
> noise.
most of the classes are with (object), and this will help us when we
do the 3to2 transition because I doubt the conversion tool adds that
>
>> for 1- 3- you can install my tool "flake8", which does pyflake+flake8+
>> the mccabe cyclomatic complexity
> I‘ve used the 3.x port of pyflakes. It crashes sometimes but mostly
> works. I’m curious about your tool; I see linting and style checking as
> very different things (and I don’t know about the mccabe thing), and as
> a UNIX guy I wonder why you merged them.
Because pep8 + pyflakes is the minimal set of tools to run on a
codebase, so having a single script is very handy,
mccabe points the code that has more than 10 levels of imbrication.
>
> Regards
Éric Araujo
> Please be more precise.
unnecessary backslashes; arguments of functions or split strings that
are not indented to align after the opening paren; spaces that distract
visual grouping in function calls (like range(x - 1, 1, 1) instead of
x-1, which is not as terrible as pep8 wants us to believe).
>>> 2 - look for all APIs that are only used within a module and is not
>>> useful as a public API. This is very important because once 3.3 is
>>> out, we will be stuck with them
>> Yes! I wonder about methods in command classes: should they all be public?
> I think the base class should determine all public methods, for most cases
Can you rephrase? I don’t get what base class you’re talking about.
Are you saying that all command classes should have all-public methods?
>>> 4 - kill all old-style code => add (object) for classes etc.
>> What the? All classes are new-style in 3.x, adding object is unneeded
>> noise.
> most of the classes are with (object),
They’re not.
> and this will help us when we do the 3to2 transition
It will not: fix_newstyle in 3to2 will add (object).
>> I’m curious about your tool; I see linting and style checking as
>> very different things (and I don’t know about the mccabe thing), and as
>> a UNIX guy I wonder why you merged them.
> Because pep8 + pyflakes is the minimal set of tools to run on a
> codebase, so having a single script is very handy,
I see. I personally have no problems running two scripts (and tests,
and compilation, and doc build :)
> mccabe points the code that has more than 10 levels of imbrication.
Ah, nice. “cyclomatic complexity” is a grand name for that :)
Regards
Tarek Ziadé
>>> Some of the whitespace changes are strange.
>> Please be more precise.
> The one in _trove;
What's wrong about them ?
> two blank lines added in command.cmd;
yeah that could be reduced to one.
> the use of unnecessary backslashes;
> arguments of functions or split strings that are not indented to align after the opening paren;
That's fine by me. It passes pep8.
Oh my god, what a bikeshedder you are :)
> spaces that distract
> visual grouping in function calls (like range(x - 1, 1, 1) instead of
> x-1, which is not as terrible as pep8 wants us to believe).
We're following pep8 style, not Araujo style :)
So feel free to argue on this on Python-ideas, and if pep8 is changed,
we can change packaging. But for the time being, pep8 is the rule in
packaging.
>>>> 2 - look for all APIs that are only used within a module and is not
>>>> useful as a public API. This is very important because once 3.3 is
>>>> out, we will be stuck with them
>>> Yes! I wonder about methods in command classes: should they all be public?
>> I think the base class should determine all public methods, for most cases
> Can you rephrase? I don’t get what base class you’re talking about.
packaging.commands.cmd.Command that's the base class
> Are you saying that all command classes should have all-public methods?
I am saying that commands should only have as public methods the ones
defined in the base class.
>>>> 4 - kill all old-style code => add (object) for classes etc.
>>> What the? All classes are new-style in 3.x, adding object is unneeded
>>> noise.
>> most of the classes are with (object),
> They’re not.
>
>> and this will help us when we do the 3to2 transition
> It will not: fix_newstyle in 3to2 will add (object).
Grrr, I thought I have changed them all at some point. They're not.
Ok, cool then.
>
>>> I’m curious about your tool; I see linting and style checking as
>>> very different things (and I don’t know about the mccabe thing), and as
>>> a UNIX guy I wonder why you merged them.
>> Because pep8 + pyflakes is the minimal set of tools to run on a
>> codebase, so having a single script is very handy,
> I see. I personally have no problems running two scripts (and tests,
> and compilation, and doc build :)
Good for you. I like the merged report on my side.
>
>> mccabe points the code that has more than 10 levels of imbrication.
> Ah, nice. “cyclomatic complexity” is a grand name for that :)
That's how it's called. http://en.wikipedia.org/wiki/Cyclomatic_complexity
I doubt you can troll McCabbe on this one. That was in 1976, I am not
sure he's still around.