Hi Nikhil,
I had a superficial look:
* I still recommend an autoformatter because it eliminates a certain class of
error: the formatting nit before merging a PR. Otherwise, you end up
micromanaging e.g. spaced ()
(https://github.com/nikramakrishnan/freetype-docwriter/blob/master/content.py#L113
> * Any reason for the "# eof“ comments at the bottom?
I want that; I consider it good practice to mark the intended end of
file.
> As a very general aside, I suggest you avoid doing anything other
> than assigning arguments in __init__ and instead use @classmethod
> constructors for initializi
>
> > As a very general aside, I suggest you avoid doing anything other
> > than assigning arguments in __init__ and instead use @classmethod
> > constructors for initializing everything you need for a class. See
> > e.g.
> http://as.ynchrono.us/2014/12/asynchronous-object-initialization.html.
> >
> I've been working on improving docwriter's maintainability. These
> are the changes made in the past few days: [...]
Thanks for working on that. It looks very clean!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://li
> Hi Nikhil,
> I had a superficial look:
>
> * I still recommend an autoformatter because it eliminates a certain class
> of error: the formatting nit before merging a PR. Otherwise, you end up
> micromanaging e.g. spaced () (
> https://github.com/nikramakrishnan/freetype-docwriter/blob/master/cont
> I would really like to use a formatting tool like yapf, but the only problem
> is that it doesn't have a configuration/option for the foo( bar ) format
> (space in brackets). I checked options from
> https://github.com/google/yapf/blob/master/README.rst#knobs. Am I missing
> something?
There
> There likely isn’t one because `foo( bar )` is discouraged in Python-land:
> https://www.python.org/dev/peps/pep-0008/#pet-peeves. If it’s okay with
> Werner, I strongly suggest going with idiomatic Python style instead of
> carrying over the C style. The formatter Black will do everything you ne
> You could also run it via tox on Travis:
> https://github.com/fonttools/ufoLib2/blob/master/tox.ini
>
> Tox seemed too much for this module, and Travis does the multi-version checks
> anyway. but I'll consider adding it.
The prime advantage of using tox is that you can just type `tox` on yo
Hello Nikhil!
> I would really like to use a formatting tool like yapf, but the only
> problem is that it doesn't have a configuration/option for the
>
> foo( bar )
>
> format (space in brackets).
No need to retain that. You are going to completely rewrite the tool,
so I don't mind if you c
> [...] `foo( bar )` is discouraged in Python-land:
> https://www.python.org/dev/peps/pep-0008/#pet-peeves.
:-)
> If it’s okay with Werner, I strongly suggest going with idiomatic
> Python style instead of carrying over the C style. The formatter
> Black will do everything you need for that.
B
> I've applied black to docwriter.py in the latest commit where I
> implement cli using argparse. It looks quite readable, IMHO.
Indeed!
> https://github.com/nikramakrishnan/freetype-docwriter/blob/f6f9dd07d89fa72bb5f17d563011e0790f2324a1/docwriter.py
Minor nit:
s/Setup the logger./Set up
Uh oh. Black enforces 4 spaces for indentation. Black is the formatter with
the most momentum right now. Yapf is more configurable but according to the
black author not as consistent, which is why he wrote black in the first
place. Good luck 😮
___
Freetyp
> Uh oh. Black enforces 4 spaces for indentation.
Honestly spoken, this would be an immediate reason for me to not use
this tool, were I a Python programmer.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.o
I love it. Configurability is the enemy of consistency. I get bouts of
"E" when I have to look at other people's formatting preferences.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> I love it. Configurability is the enemy of consistency.
I strongly disagree. Within a project everything must be consistent,
no question. However, I don't see any reason that *all* projects must
look the same, with a single person (or a small team) being the
formatting dictator.
Werne
> I strongly disagree. Within a project everything must be consistent,
> no question. However, I don't see any reason that *all* projects must
> look the same, with a single person (or a small team) being the
> formatting dictator.
There is no harm in everything looking the same; on the contrary
> There is no harm in everything looking the same; on the contrary,
> new people familiar with other codebases can contribute more easily
> because stuff looks the same — and since it’s automated, no PR ever
> gets round-tripped because of some formatting nitpick.
This is a very simplistic approa
>
> The auto formatters (both yapf and black), however, perform somewhat
> undesirable changes at places. See 'regex_indent_old' and
> 'regex_indent_new'
> as an example.
>
Try dedenting the string and make the closing """ match up. I'd say the
formatting is okay, things that don't fit a line get
> See the attached images. 'indent_4' is the current formatting, and
> 'indent_2' is formatting done using 'yapf' with chromium style (2
> spaces) and column limit 78.
Thanks. I still prefer 2-space indentation; for deeper nesting levels
it is easier to stay within the 78 (or 79) character-per-l
>
> Thanks. I still prefer 2-space indentation; for deeper nesting levels
> it is easier to stay within the 78 (or 79) character-per-line limit...
>
(Try to refactor code instead when you reach deeper levels)
> I'll wait before applying a formatter till there is a consensus
> > here :-)
>
> Inde
>> Thanks. I still prefer 2-space indentation; for deeper nesting
>> levels it is easier to stay within the 78 (or 79)
>> character-per-line limit...
>
> (Try to refactor code instead when you reach deeper levels)
Which is not always a good idea; sometimes it is necessary to avoid
subroutines
>
> > (Try to refactor code instead when you reach deeper levels)
>
> Which is not always a good idea; sometimes it is necessary to avoid
> subroutines for performance reasons, for example.
>
You mean in Python? 😁 SCNR
>
___
Freetype-devel mailing list
>> > (Try to refactor code instead when you reach deeper levels)
>>
>> Which is not always a good idea; sometimes it is necessary to avoid
>> subroutines for performance reasons, for example.
>
> You mean in Python? 😁 SCNR
Yes. No idea how subroutines are officially called.
And no idea why this
It's funny Python often trades performance for elegance 😁
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
24 matches
Mail list logo
