2009/12/14 Dino Viehland <di...@microsoft.com>: [..] > Not mentioned here are the user schemes. Looking at the code it seems that > _getuserbase is adding "Python" to the path on nt. Isn't that redundant? > The paths in _INSTALL_SCHEMES already include "Python". >
Right that's a small bug in the refactoring (there's an extra /) but there will be a bit of redundancy on "Python", at the end nevertheless: The base directory in win32 for the user scheme in is : APPDATA *or* ~/Python (under linux it's ~/.local) then various subdirectories are added in that directory, and some of them starts with "PythonXY", like: ~/Python/Python26/.. See http://www.python.org/dev/peps/pep-0370/#specification > Also w/ user dirs in general - I think there should be some implementation > specific portion of the path as well. Right now I think IronPython and > CPython will end up with the same user paths for the same versions which > could cause problems if someone releases separate modules for IronPython > and CPython for some reason (or if users just want different sets of > things installed for different interpreters). Yes that's one point someone raised (can't recall who) and the idea was to have a separate top directory for user dirs, that would start with the name of the implementation: so for Windows: ~/Python/Python26/.. ~/IronPython/../ ~/Jython/../ and for Linux and al, I am not sure but maybe a prefix for Jython/etc.. could be used for all paths. ~/.locale/lib/python/2.6/site-packages/... ~/.locale/jython/lib/python/2.6/site-packages/... (I didn't digg on how Jython organizes things yet, any hint would be appreciated) > >> * get_platform(): Return a string that identifies the current >> platform. (this one is used by site.py for example) > > I wonder if this would make more sense a built-in. Ultimately it seems > like the interpreter implementation knows best about what aspects of > it's underlying platform would require different libraries. > > With the existing code I think IronPython would return "cli" everywhere > (because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but > we still don't have uname). I think Jython will return something like > java1.6.0_17 because it's os.name is java - which might be more specific > than is necessary. Ok so it sounds like it would be easier to cook that value in a built-in in each implementation, > > Also if the purpose of this is for platform specific build directories > it might be interesting to have multiple return values. For example in > IronPython the minimal thing we'd want I think is a "cli" directory for > .NET assemblies. But there could also be native extensions which are > platform specific so we'd want "cli-x86" and "cli-x64" depending upon > the platform. Jython might want the same thing as they add ctypes > support. So like, having an architecture marker, that defaults to the current ? get_platform(architecture=platform.architecture) Regards Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ 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
