Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
> Surely those are all very minor quibbles. I have one myself: at some > point it says: > > On Linux, it is possible to use > time.clock_gettime(CLOCK_THREAD_CPUTIME_ID). > > But the PEP doesn't define a function by that name. Is it an editing > glitch? (Some of the pseudo code also uses this.) It is this function: http://docs.python.org/dev/library/time.html#time.clock_gettime It's just a binding of the C function clock_gettime(). Should the PEP describe all functions used by the PEP? Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman wrote: > Here's a ponderable: In the long term, should the documentation be unified > for multiple implementations? Or should it be split into 4 pieces, so that > alternate implementations could swap in their own sections for > implementation dependent items? Probably not, because the boundary between language, standard library and implementation *is* blurry. The blurriness in the descriptions reflects the blurriness in reality. Anything that doesn't have dedicated syntax is, in a formal sense, part of the standard library rather than the core language definition. That includes the GC API, the weakref API, the sys module, the operator module, the builtins module, the types module, etc. The language specification itself just states that there *is* a builtin namespace and you *can* do imports. It is then up to the standard library specification to describe the *contents* of the builtin namespace, as well as state what other modules and packages can be imported by default. However, the various parts of the standard library differ can wildly in how *closely coupled* they are to a particular implementation. Some, such as builtins, gc, operator, weakref, types and sys are *very* tightly coupled with a specific implementation and always will be. If someone is writing a new implementation of Python, they're almost certainly going to have to write new version of these modules from scratch that interoperate correctly with their code generator and evaluation loop. Historically, the import machinery was similarly coupled to a specific implementation. The goal of bootstrapping importlib as the main import implementation is to change that so that most of the import machinery is decoupled from the implementation, with the bare minimum remaining as implementation specific code (specifically, the code needed to carry out the bootstrapping process, such as supporting frozen and builtin modules). Other modules may differ in performance characteristics between implementations, particular for older C modules in CPython which don't have a pure Python counterpart. So, yes, I agree the four categories you list are helpful in *thinking* about the questions involved, but, no, I don't think it's a good principle for organising the documentation (precisely because the categories are related to implementation details that shouldn't matter all that much to end users). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > I'm personally in favour of changing the insertion of '' to sys.path to > inserting the cwd when the interpreter is launched. I'm not, because it breaks importing from the interactive prompt if you change directory after starting the session. The existing workaround for applications is pretty trivial: # Somewhere in your initialisation code for i, entry in enumerate(sys.path): sys.path[i] = os.path.abspath(i) The fix for the import system is similarly trivial: call os.path.abspath when calculating __file__ (just as runpy now does and the import emulation in pkgutil always has). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
> 3) The dict returned by get_clock_info includes an optional key, > "is_adjusted". Why is it optional? More complete answer. Rules used to fill the is_adjusted flag: - System clock: is_adjusted=1 because the clock can be set manually by the system administrator, except on Windows: is_adjusted is 0 if GetSystemTimeAdjustment() returns isTimeAdjustmentDisabled=1 - Process time: is_adjusted=0 because I don't know an OS where the process time can be modified - Monotonic clocks: is_adjusted=0 on Windows, Mac OS X and Solaris, is_adjusted=1 on Linux, it is not set otherwise. We may also set is_adjusted to 0 on other OSes and so the key would not be optional anymore. Said differently, is_adjusted is only 1 for system clocks and for the monotonic clock on Linux. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #14448: mention pytz; patch by Andrew Svetlov
On Wed, Apr 25, 2012 at 20:40, Georg Brandl wrote: > BTW, the single backticks don't do anything usable; use *pytz* to make > something > emphasized. yep, done. On Thu, Apr 26, 2012 at 03:06, Nick Coghlan wrote: > On Thu, Apr 26, 2012 at 4:40 AM, Georg Brandl wrote: >> Maybe it's useful to mention that that database is the one used on Linux (is >> it on other Unices?) and Windows has its own? > > pytz always uses the Olson/IANA database. I don't think we need to > confuse matters further by mentioning the fact that Microsoft invented > their own system without worrying about what anyone else was doing. I agree with that, so i'm about to commit a very similar diff than the one posted here. Thanks for your suggestions! -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
2012/4/28 Nick Coghlan : > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: >> I'm personally in favour of changing the insertion of '' to sys.path to >> inserting the cwd when the interpreter is launched. > > I'm not, because it breaks importing from the interactive prompt if > you change directory after starting the session. > > The existing workaround for applications is pretty trivial: > > # Somewhere in your initialisation code > for i, entry in enumerate(sys.path): > sys.path[i] = os.path.abspath(i) > > The fix for the import system is similarly trivial: call > os.path.abspath when calculating __file__ (just as runpy now does and > the import emulation in pkgutil always has). I thought __file__ was required to be absolute in Python 3. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On Sat, Apr 28, 2012 at 12:40 AM, Victor Stinner wrote: >> Surely those are all very minor quibbles. I have one myself: at some >> point it says: >> >> On Linux, it is possible to use >> time.clock_gettime(CLOCK_THREAD_CPUTIME_ID). >> >> But the PEP doesn't define a function by that name. Is it an editing >> glitch? (Some of the pseudo code also uses this.) > > It is this function: > http://docs.python.org/dev/library/time.html#time.clock_gettime > > It's just a binding of the C function clock_gettime(). Should the PEP > describe all functions used by the PEP? Oh, now I'm confused. Se in 3.3 we're adding a bunch of other new functions to the time module that aren't described by the PEP? Aren't those functions redundant? Or did I miss some part of the conversation where this was discussed? What's *their* history? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On Sat, 28 Apr 2012 07:02:13 -0700
Guido van Rossum wrote:
> >
> > It is this function:
> > http://docs.python.org/dev/library/time.html#time.clock_gettime
> >
> > It's just a binding of the C function clock_gettime(). Should the PEP
> > describe all functions used by the PEP?
>
> Oh, now I'm confused. Se in 3.3 we're adding a bunch of other new
> functions to the time module that aren't described by the PEP? Aren't
> those functions redundant? Or did I miss some part of the conversation
> where this was discussed? What's *their* history?
time.clock_gettime() (and the related constants
CLOCK_{REALTIME,MONOTONIC, etc.}) is a thin wrapper around the
corresponding POSIX function, it's there for people who want low-level
control over their choice of APIs:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
As a thin wrapper, adding it to the time module was pretty much
uncontroversial, I think. The PEP proposes cross-platform
functions with consistent semantics, which is where a discussion was
needed.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On Sat, Apr 28, 2012 at 7:51 AM, Antoine Pitrou wrote:
> On Sat, 28 Apr 2012 07:02:13 -0700
> Guido van Rossum wrote:
>> >
>> > It is this function:
>> > http://docs.python.org/dev/library/time.html#time.clock_gettime
>> >
>> > It's just a binding of the C function clock_gettime(). Should the PEP
>> > describe all functions used by the PEP?
>>
>> Oh, now I'm confused. Se in 3.3 we're adding a bunch of other new
>> functions to the time module that aren't described by the PEP? Aren't
>> those functions redundant? Or did I miss some part of the conversation
>> where this was discussed? What's *their* history?
>
> time.clock_gettime() (and the related constants
> CLOCK_{REALTIME,MONOTONIC, etc.}) is a thin wrapper around the
> corresponding POSIX function, it's there for people who want low-level
> control over their choice of APIs:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
>
> As a thin wrapper, adding it to the time module was pretty much
> uncontroversial, I think. The PEP proposes cross-platform
> functions with consistent semantics, which is where a discussion was
> needed.
True, but does this mean clock_gettime and friends only exist on
POSIX? Shouldn't they be in the os or posix module then? I guess I'm
fine with either place but I don't know if enough thought was put into
the decision. Up until now the time module had only cross-platform
functions (even if clock()'s semantics vary widely).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, 28 Apr 2012 18:08:08 +1000, Nick Coghlan wrote: > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > > I'm personally in favour of changing the insertion of '' to sys.path to > > inserting the cwd when the interpreter is launched. > > I'm not, because it breaks importing from the interactive prompt if > you change directory after starting the session. Heh. I've never thought of doing that. I would not have expected it to work (change directory from the interactive prompt and be able to import something located in the new cwd). I don't know why I wouldn't have expected it to work, I just didn't. That said, could this insertion of '' only happen when the interactive prompt is actually posted, and otherwise use cwd? --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] questions about memory management
In Python-3.2.3/Python/import.c, in the function
_PyImport_FixupExtensionUnicode, is any call to PyDict_DelItemString
needed before the final failure returns?
modules = PyImport_GetModuleDict();
if (PyDict_SetItemString(modules, name, mod) < 0)
return -1;
if (_PyState_AddModule(mod, def) < 0) {
PyDict_DelItemString(modules, name);
return -1;
}
if (def->m_size == -1) {
if (def->m_base.m_copy) {
/* Somebody already imported the module,
likely under a different name.
XXX this should really not happen. */
Py_DECREF(def->m_base.m_copy);
def->m_base.m_copy = NULL;
}
dict = PyModule_GetDict(mod);
if (dict == NULL)
return -1;
def->m_base.m_copy = PyDict_Copy(dict);
if (def->m_base.m_copy == NULL)
return -1;
}
In Python-3.2.3/Modules/ossaudiodev.c, in the function build_namelists, is
it intentional that labels is not freed in the last failure case:
if (PyModule_AddObject(module, "control_labels", labels) == -1)
goto error2;
if (PyModule_AddObject(module, "control_names", names) == -1)
goto error1;
return 0;
error2:
Py_XDECREF(labels);
error1:
Py_XDECREF(names);
return -1;
thanks,
julia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] questions about memory management
Hello Julia, On Sat, 28 Apr 2012 10:06:52 +0200 (CEST) Julia Lawall wrote: > In Python-3.2.3/Python/import.c, in the function > _PyImport_FixupExtensionUnicode, is any call to PyDict_DelItemString > needed before the final failure returns? I would say it probably does, but it would need further examination. Some error-checking code paths in our C code base may lack proper cleanup, especially when an error is unlikely. Could you open an issue at http://bugs.python.org with this? > In Python-3.2.3/Modules/ossaudiodev.c, in the function build_namelists, is > it intentional that labels is not freed in the last failure case: The successful call to PyModule_AddObject() steals a reference to `labels`, so it doesn't need to be decrefed again (the reference is not owned by the init function anymore). Regards Antoine. > if (PyModule_AddObject(module, "control_labels", labels) == -1) > goto error2; > if (PyModule_AddObject(module, "control_names", names) == -1) > goto error1; > > return 0; > > error2: > Py_XDECREF(labels); > error1: > Py_XDECREF(names); > return -1; > > thanks, > julia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, Apr 28, 2012 at 04:08, Nick Coghlan wrote: > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > > I'm personally in favour of changing the insertion of '' to sys.path to > > inserting the cwd when the interpreter is launched. > > I'm not, because it breaks importing from the interactive prompt if > you change directory after starting the session. > > Who does that? I mean what possible need do you have to start the interpreter in one directory, but then need to chdir somewhere else where you are doing your actual importing from, and in a way where you can't simply attach the directory you want to use into sys.path? > The existing workaround for applications is pretty trivial: > > # Somewhere in your initialisation code > for i, entry in enumerate(sys.path): > sys.path[i] = os.path.abspath(i) > > The fix for the import system is similarly trivial: call > os.path.abspath when calculating __file__ (just as runpy now does and > the import emulation in pkgutil always has). > You say trivial, I say a pain as that means porting over os.path.abspath() into importlib._bootstrap that works for all platforms. -Brett > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, Apr 28, 2012 at 09:35, Benjamin Peterson wrote: > 2012/4/28 Nick Coghlan : > > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > >> I'm personally in favour of changing the insertion of '' to sys.path to > >> inserting the cwd when the interpreter is launched. > > > > I'm not, because it breaks importing from the interactive prompt if > > you change directory after starting the session. > > > > The existing workaround for applications is pretty trivial: > > > > # Somewhere in your initialisation code > > for i, entry in enumerate(sys.path): > > sys.path[i] = os.path.abspath(i) > > > > The fix for the import system is similarly trivial: call > > os.path.abspath when calculating __file__ (just as runpy now does and > > the import emulation in pkgutil always has). > > I thought __file__ was required to be absolute in Python 3. > Not that I'm specifically aware of. Since site makes all entries in sys.path absolute it is really only an issue if you launch without site or the '' entry in sys.path. -Brett > > > > -- > Regards, > Benjamin > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, Apr 28, 2012 at 12:16, R. David Murray wrote:
> On Sat, 28 Apr 2012 18:08:08 +1000, Nick Coghlan
> wrote:
> > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote:
> > > I'm personally in favour of changing the insertion of '' to sys.path to
> > > inserting the cwd when the interpreter is launched.
> >
> > I'm not, because it breaks importing from the interactive prompt if
> > you change directory after starting the session.
>
> Heh. I've never thought of doing that. I would not have expected it
> to work (change directory from the interactive prompt and be able to
> import something located in the new cwd). I don't know why I wouldn't
> have expected it to work, I just didn't.
>
> That said, could this insertion of '' only happen when the interactive
> prompt is actually posted, and otherwise use cwd?
If the decision to keep this entry around stands, can we consider changing
it to '.' instead of the empty string? It mucks up stuff if you are not
careful (e.g. ``os.listdir('')`` or ``"/".join(['', 'filename.py'])``).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
>> As a thin wrapper, adding it to the time module was pretty much >> uncontroversial, I think. The PEP proposes cross-platform >> functions with consistent semantics, which is where a discussion was >> needed. > > True, but does this mean clock_gettime and friends only exist on > POSIX? Shouldn't they be in the os or posix module then? I guess I'm > fine with either place but I don't know if enough thought was put into > the decision. Up until now the time module had only cross-platform > functions (even if clock()'s semantics vary widely). The os module is big enough. Low level networks functions are not in the os module, but in the socket module. Not all functions of the time module are always available. For example, time.tzset() is not available on all platforms. Another example, the new time.monotonic() is not available on all platforms ;-) Oh, I forgot to mention that time.clock_*() functions are not always available in the doc. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On 4/27/2012 11:40 PM, Guido van Rossum wrote: > On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano wrote: >> 2) get_clock_info returns a dict. Why not a namedtuple? > > Future flexibility. And there's no need for it to be a *tuple*. I haven't been paying attention to this discussion, so this isn't a comment on any time functions specifically. But we generally use a namedtuple (or structseq) for things like get_clock_info. For example, for sys.float_info there's no need for it to be a tuple, and it can be extended in the future, yet it's a structseq. Same for sys.flags, although it's its own type, not a structseq. It is also indexable, and we've added fields to it (hash_randomization was added in 2.7.3). So I think a structseq would work for get_clock_info as well. It's unfortunate we don't have a similar type which isn't a tuple, but the types we do have work well enough in practice. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
>>> 2) get_clock_info returns a dict. Why not a namedtuple? >> >> Future flexibility. And there's no need for it to be a *tuple*. > > I haven't been paying attention to this discussion, so this isn't a > comment on any time functions specifically. > > But we generally use a namedtuple (or structseq) for things like > get_clock_info. For example, for sys.float_info there's no need for it > to be a tuple, and it can be extended in the future, yet it's a structseq. Ok ok, I changed the is_adjusted flag to make it mandatory and I changed get_clock_info() to return a clock_info object. clock_info is a structseq. I didn't mention that clock_info can be read using an index because I really don't like the tuple-like API. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
Hi Guido, 2012/4/28 Guido van Rossum : > I read most of the PEP and I think it is ready for acceptance! Thanks > for your patience in shepherding this through such a difficult and > long discussion. You're welcome, but many developers helped me! > Also thanks to the many other contributors, > especially those who ended up as co-authors. We will have an awesome > new set of time APIs! Now let the implementation roll... The PEP is not accepted yet at: http://www.python.org/dev/peps/pep-0418/ Did you forget to update its status, or are you waiting for something? Anyway I commited the implementation of the PEP 418 (after the last change on the API of time.get_clock_info()). Let's see how buildbots feel with monotonic time. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On 4/28/2012 3:16 PM, Brett Cannon wrote: Who does that? I mean what possible need do you have to start the interpreter in one directory, but then need to chdir somewhere else where you are doing your actual importing from, and in a way where you can't simply attach the directory you want to use into sys.path? Idle, at least on Windows, when started from the installed icon, starts in the directory of the associated pythonw.exe. There is no choice. And that is a bad place to put user files for import. So anyone using Idle and importing user files does just what you think is strange. Windows ain't *nix. If one opens a file in another directory*, that becomes the new current directory and imports from that directory work. I would not want that to change. I presume that changing '' to '.' would not change that. *and the easiest way to do *that* is from the 'recent files' list. I almost never type a path on Windows. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
Brett Cannon wrote: On Sat, Apr 28, 2012 at 04:08, Nick Coghlan wrote: On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: I'm personally in favour of changing the insertion of '' to sys.path to inserting the cwd when the interpreter is launched. I'm not, because it breaks importing from the interactive prompt if you change directory after starting the session. Who does that? Me. You're asking this as if it were a bizarre and disturbing thing to do. It's not as if changing directory is an unsupported hack. When I use the Python interactive interpreter for interactive exploration or testing, sometimes I discover I'm in the wrong directory. If I've just started a fresh session, I'll probably just exit back to the shell, cd, then start Python again. But if there's significant history in the current session, I'll just change directories and continue on. I mean what possible need do you have to start the interpreter in one directory, but then need to chdir somewhere else where you are doing your actual importing from, and in a way where you can't simply attach the directory you want to use into sys.path? Of course I could manipulate sys.path. But chances are that I still have to change directory anyway, so that reading and writing data files go where I want without having to specify absolute paths. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sat, Apr 28, 2012 at 12:16 PM, R. David Murray wrote: > That said, could this insertion of '' only happen when the interactive > prompt is actually posted, and otherwise use cwd? > That's already the case. Actually, sys.path[0] is *always* the absolute path of the script directory -- regardless of whether you invoked the script by a relative path or an absolute one, and regardless of whether you're importing 'site' -- at least on Linux and Cygwin and WIndows, for all Python versions I've used regularly, and 3.2 besides. It isn't the value of cwd unless you happen to run a script from the same directory as the script itself. But even then, it's absolute, and not an empty string: the empty string is only present for interactive sessions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] package imports, sys.path and os.chdir()
On Sun, Apr 29, 2012 at 1:41 PM, PJ Eby wrote:
> That's already the case. Actually, sys.path[0] is *always* the absolute
> path of the script directory -- regardless of whether you invoked the script
> by a relative path or an absolute one, and regardless of whether you're
> importing 'site' -- at least on Linux and Cygwin and WIndows, for all Python
> versions I've used regularly, and 3.2 besides.
"-c" and "-m" also insert the empty string as sys.path[0] in order to
find local files. They could just as easily insert the full cwd
explicitly though, and, in fact, they arguably should. (I say
arguably, because changing this *would* be a backwards incompatible
change - there's no such issue with requiring __file__ to be
absolute).
If we fixed that, then you could only get relative filenames from the
interactive prompt.
There's another way we can go with this, though: something I'm working
on at the moment is having usage of the frozen importlib be
*temporary*, switching to the full Python source version as soon as
possible (i.e. as soon as the frozen version is able to retrieve the
full version from disk).
There's a trick that becomes possible if we go down that path: we can
have some elements of importlib._bootstrap that *don't run* during the
initial bootstrapping phase.
Specifically, we can have module level code that looks like this:
if __name__.startswith("importlib."):
# Import system has been bootstrapped with the frozen version,
we now have full stdlib access
# and other parts of the interpreter have also been fully initialised
from os.path import abspath as _abspath
_debug_msg = print
else:
# Running from the frozen copy, there's things we can't do yet
because the interpreter is not fully configured
def _abspath(entry):
# During the bootstrap process, we let relative paths
slide. It will only happen if someone shadows the stdlib in their
# current directory.
return entry
def _debug_msg(*args, **kwds):
# Standard streams are not initialised yet
pass
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
