Martin v. L=F6wis wrote: > It is very hard to read, as a patch, yes, and it does a lot of things > that aren't clearly needed. >=20 > However, in all cases I've investigated, the resulting import.c works > just as fine as the original one. Don't read the patch, read the > resulting code instead. And then it still does many things that "aren't clearly needed". > I don't like to reject the patch on grounds of "it is too > complicated". Perhaps the complexity is inherent, and it can't be done > trivially. The complexity is inherent *because* there's no import hook mechanism tha= t's even remotely usable from C. My patch changes that. > In that case, it would be a pity since it means that we can > never get zipfile imports. No it doesn't. It just means that a little more work is needed. > The feature that this patch provides is well-defined. If somebody > volunteers to cleanup the implementation later - this would be > definitely appreciated. It doesn't *belong* in import.c. It's bloat. > > > In what time frame would you expect to implement the zipfile import > > > patch using your framework? > >=20 > > Don't know, I can't do it by myself. Shouldn't be too hard, though. >=20 > That, of course, speaks against the framework, or atleast against > rejecting the zipfile patch. I rather meant "I prefer not to do it by myself". > It seems that the likeliness is high that we get a new framework, and > no application for it. If we require zipfile importing to use the new > framework, we will never get zipfile importing. Bull. > This doesn't sound very promising, so I'd mandate that any new > framework demonstrates its usefulness in a non-trivial case, which is > best done by implementing (or re-implementing) zipfile import. ... Just
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4