2009/7/5 Tarek Ziadé <ziade.ta...@gmail.com>: > 2009/7/5 Paul Moore <p.f.mo...@gmail.com>: >> The PEP says: >> >> """ >> get_egginfo_files(local=False) -> iterator of paths >> >> Iterates over the RECORD entries and return paths for each line if the >> path is pointing a file located in the .egg-info directory or one of >> its subdirectory. >> """ >> >> Should this method really only return filenames noted in the RECORD >> file? Would it not be better for it to iterate over *all* files in the >> .egg-info directory? >> I understand that there shouldn't, in practice, >> be any files in that directory *not* mentioned in the RECORD file, but >> given that we already have get_installed_files to read the RECORD >> file, I would imagine it's better for this file to so something more >> than filter the return values from get_installed_files. > > I don't see a use case for having more out of get_egginfo_files. > I still find it useful because to iterate over metadata files. > > Maybe we could remove it and add a filter option for get_installed_files. > A callable that gets each visited file and returns True or False to > filter them out: > > get_installed_files(path, filter=callable) > > And then provide a "egginfo_files" callable to get what we have with > get_egginfo_files : > > get_installed_files(path, filter=egginfo_files)
-1. Unnecessary generalisation. Let's stick with the 2 functions as documented. [...] >> Similarly, how valuable is Distribution.name, given that it's the same >> as Distribution.metadata.name? I'm probably just going to make it a >> property - > > It's just for conveniency, since this metadata field is also the > identifier of the distribution. > >> >> @property >> def name(self): >> return self.metadata.name > > I don't think this adds any value, since self.metadata is a read-only > instance, > that gets loaded once when the Distribution object is created. ... not any more :-) Your zipfile handling was horribly broken on Windows, thanks to the usual slash/backslash confusion. The sanest way to fix it seemed to me to be to load the metadata lazily, rather than in the __init__ (as otherwise, zipfile and filesystem implementation end up not being able to share any code). Once that's done, the name attribute has to *also* handle lazy-loading of the metadata, and the above property is the easiest way to do this. Actually, my implementation is looking less and less like yours, and ultimately any implementation questions are irrelevant until you see my code and spot all the errors :-) I'm trying to get it into a postable state as fast as I can. (At last count, I've replaced about 140 lines of code with 70, and it now includes PEP 302 support all the (non-internal) tests still pass. So it's looking OK...) Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
