Martin v. L=F6wis wrote: > > And then it still does many things that "aren't clearly needed". >=20 > Yes, but these are mostly reorganizations of stuff, eg. pieces of a > function moved into functions of their own. This is, in general, a good > thing, as it improves readability of the resulting code (not of the > patch, though). Besides bloat, my main objection to the patch is that it refactors import= .c in a way that's not general enough and actually make import.c more complex tha= n needed. This is IMO a bad thing. > > The complexity is inherent *because* there's no import hook mechanism > > that's even remotely usable from C. My patch changes that. >=20 > I would expect that the complexity is inherent in "we implement our own > file system" (i.e. zipfiles). So I don't trust promises that a great ne= w > framework will make things simpler, unless proven wrong, by seeing > actual things that become actually simpler. True. See below. > > No it doesn't. It just means that a little more work is needed. >=20 > The current patch was sitting on SF for almost a year, and nobody even > looked at it. How many more years do you want to wait for somebody > finding time for "a little more work"? It's been sitting there for so long *because* it's such a hairy patch. I'= ve just started writing a new madule called "zipimport" which will show what I me= an. The rest of today will be very busy here, so you _might_ have to wait until t= omorrow for working code. 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