Author jjinux
Date 2007-02-08.19:09:31
SpamBayes Score
Marked as misclassified
> What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well?

Perhaps, but it's probably not as critical.  I.e. if the code gets duplicated to deal with eggs, it's not as big a loss.  I really wish the distutils guys would weigh in on this one.

> Also, what about os.path.join?

I think it's relatively harmless.  One can work around that.  One can't work around os.path.exists.

> In principle, I'm willing to fix this. I just want to avoid adding a hack.

I agree.  The patch isn't smelling too pretty.  Neither of us wants to commit to a virtual filesystem layer which is how I've handled problems like this in the past.  However, doing nothing results in a ton of code being duplicated in any project that uses gettext and zipped eggs.  Should we see if Phillip Eby has any ideas since he's Mr. Eggs?

> For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to the
.open method, which would take something that .join returned and returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory name),
or a MOOpener object.

That's a light virtual filesystem layer ;)  If you want that, I have code for that.

> In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6.

True.  Alas, this may be a moot point.

Thanks for your time.
Date User Action Args
2007-08-23 16:12:31adminlinkissue1649329 messages
2007-08-23 16:12:31admincreate