Re: Python extension commands in git - request for policy change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx>:
> > I'd be happy to help you out by auditing them for version dependencies.
> 
> Be my guest:
> http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205
> 
> Some patches might be missing, so:
> https://github.com/felipec/git/tree/fc/remote/hg

OK, here's what I look for:  use of argparse, use of unittest, use
of Collections.counters, use or ordered dictionaries, use of set literals,
use of multiple context managers in one "with", use of memoryview, use of
the comma format specifier.  I'm not worried about the changes in repr()
for floating point; I'd be astonished if they mattered in code like this.
Likewise for PyCapsule and importlib.

I don't see obvious problems in that code.  Looks pretty vanilla, actually;
the latest version-related blocker I can see is the import of json,
which would have been a problem before 2.5.

You wrote the code.  Do you *know* of 2.7-specific constructions in
there that I've missed?  If you do, and think of this as a way to
catch me in a mistake and dance triumphantly, you lose - our goal
should be to cooperate to improve the auditing process, not score
silly points.

> > One way is by having clear guidelines for good practice that *include*
> > Python, and tell people exactly what the requirements are.
> 
> The key word being guideline, which is different from a strict rule.

Agreed. It's a matter for the dev group to decide when we need rules
and when we need guidelines.  I think we need a rule about Python version
conformance that protects older systems, but other things can be guidelines.

> According to the results of the last survey, our users do care about
> performance, so I don't think there's anything excessive about it. Are
> there any hidden costs in maintenance problems? I don't think so.

Then you're either pretending or very naive. Three decades of
experience as a C programmer tells me that C code at any volume is a
*serious* maintainance problem relative to almost any language with
GC.  Prudent architects confine it is much as possible.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]