[Python-checkins] r53280 - sandbox/trunk/import_in_py/importer.py sandbox/trunk/import_in_py/mock_importer.py sandbox/trunk/import_in_py/test_importer.py

Mon Jan 8 23:36:48 CET 2007

On 1/8/07, Jim Jewett <jimjjewett at gmail.com> wrote:
>> Comments inline... my apologies for not finding a better way to reduce
> the context
>> On 1/5/07, brett.cannon <python-checkins at python.org> wrote:
> > Author: brett.cannon
> > Date: Fri Jan 5 22:59:39 2007
> > New Revision: 53280
>> > Log:
> > Tighten up API to just what needs to be publicly exposed by adding
> underscores
> > to various functions and methods.
>> > Modified: sandbox/trunk/import_in_py/importer.py
>> ==============================================================================
> > --- sandbox/trunk/import_in_py/importer.py (original)
> > +++ sandbox/trunk/import_in_py/importer.py Fri Jan 5 22:59:39 2007
> > @@ -30,38 +28,39 @@
> ...
> > * warnings and stack level.
> ...
> > + 'warnings' assumes that the import code does not show up in the
> call
> > stack.
> > - + Because import now in Python, import does show up in the call
> stack.
> > - + Trick of specifying that going back two levels will cause the
> warning
> > - to be raised in the caller for an import statement no longer
> holds true.
> > + + Because import now implemented in Python, import does show up in
> the
> > + call stack.
> > + + Trick of specifying going back in the call stack two levels so
> warning
> > + shows up in the caller will cause the warning no longer holds
> true.
> > + Possible fixes
> > - Special module deprecation function.
> > - - Code in warnings.warn to handle import case.
> > + - Code in warnings.warn to handle special import case.
>> Note that this is similar to what the logging module does.

Ah, OK. Wasn't aware of that.
It might make sense to just skip anything registered as "internal" or
> "part of debugging", so the wheel wouldn't have to be reinvented each
> time.

Probably.
> @@ -101,7 +100,7 @@
> ...
>> > -def case_ok(directory, file_name):
> > +def _case_ok(directory, file_name):
> > """Verify that file_name (as found in 'directory') has the proper
> case.
>> Why is this internal? Because other code should use os.path.normcase?

No, os.path.normcase doesn't do what this function does as I need a way to
verify that a path, with a specific case exists. I made it internal since I
don't see an initial need to expose it and I have not worried about its
interface. Plus I am hoping to expose imp's C function case_ok to take over
since that will have much better performance.
> @@ -114,8 +113,6 @@
> > """
> > if sys.platform not in ('win32', 'mac', 'riscos', 'darwin',
> 'cygwin',
> > 'os2emx') or os.environ.get('PYTHONCASEOK'):
> > - # Platform is case-sensitive so existence check already handle
> > - # case-sensitivity.
>> And why is this comment removed? There may be other case-insensitive
> platforms in the future.

Right. The comment was removed because it didn't directly apply with the
PYTHONCASEOK check.
> @@ -551,7 +548,7 @@
> ...
> > - def search_meta_path(self, name, path=None):
> > + def _search_meta_path(self, name, path=None):
> > """Check the importers on sys.meta_path for a loader along with
> the
> > extended meta path sequence stored within this instance.
>> And why is this internal? Unless the context that didn't get touched
> by the patch makes it obvious, this seems like the sort of thing other
> importers might want to do.
>> Same questions for sys_path_importer,
> import_module,
> import_full_module,
> resolve_name, and class_resolve_name

Just trying to keep the initial API small. They can be exposed at a later
date if it turns out people want the methods exposed. But I don't want to
start off with a large API that will need to be continually supported in the
future, especially if the code gets tweaked.
> Modified: sandbox/trunk/import_in_py/mock_importer.py
>> ==============================================================================
> > --- sandbox/trunk/import_in_py/mock_importer.py (original)
> > +++ sandbox/trunk/import_in_py/mock_importer.py Fri Jan 5 22:59:39 2007
> > @@ -2,8 +2,7 @@
> > import marshal
> > import imp
>> Should that become _imp, as your code takes over the import job?
>
Possibly, but let's get the code into the stdlib first. =)
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-checkins/attachments/20070108/a659c5c6/attachment.htm