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
>> > (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
>
> > (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
>> 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
>
> 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
> 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
>
> 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
> 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
> 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
> 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 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
> 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
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
> 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
> [...] `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
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
> 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
> 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
> 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
> 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'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
>
> > 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.
> >
> * 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
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
Hi all,
I've been working on improving docwriter's maintainability. These are
the changes made in the past few days:
* Docwriter now uses the standard logging library of python, instead
of printing directly to stderr. This gives greater control over
messages and their formatting.
* Docwriter can
25 matches
Mail list logo