Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Jeroen Ruigrok van der Werven wrote: > -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: >> Python's _winreg module and pywin32 expose several functions to get the >> paths from the registry but I don't think it has a simple function like >> get_mydocuments(). > > Careful with the name though. Microsoft Windows Vista did away with 'My > Documents & Settings'. It is now C:\Users. > > So you get: > > C:\Users\\AppData\Local\(former Local Settings\Application Data) > C:\Users\\AppData\Roaming\ (former Application Data) > C:\Users\\Documents (former My Documents) > C:\Users\\Music (former My Music) > C:\Users\\Pictures (former My Pictures) > C:\Users\\Videos(former My Videos) > Somewhat off topic, but hooray, it looks like someone at MS rediscovered the command line and why "Long and Wordy Names with lots of spaces" are really annoying. Easier access to the application data directory is a good thing too. I guess moving to Vista wouldn't be all bad then ;) To get marginally back on topic, I would actually prefer to have a function like os.gethomedir() that takes on optional user name. (I don't want it enough to write a patch to make it happen though) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Nick Coghlan wrote:
> Jeroen Ruigrok van der Werven wrote:
>
>> -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
>>
>>> Python's _winreg module and pywin32 expose several functions to get the
>>> paths from the registry but I don't think it has a simple function like
>>> get_mydocuments().
>>>
>> Careful with the name though. Microsoft Windows Vista did away with 'My
>> Documents & Settings'. It is now C:\Users.
>>
>> So you get:
>>
>> C:\Users\\AppData\Local\(former Local Settings\Application Data)
>> C:\Users\\AppData\Roaming\ (former Application Data)
>> C:\Users\\Documents (former My Documents)
>> C:\Users\\Music (former My Music)
>> C:\Users\\Pictures (former My Pictures)
>> C:\Users\\Videos(former My Videos)
>>
>>
>
>
Note today's Coding Horror blog entry: "Don't Pollute User Space"
http://www.codinghorror.com/blog/archives/001032.html
Keep your dirty, filthy paws out of my personal user space!
Take a look in your Documents folder right now. Go ahead. Look. Do you
see any files or folders in there that you personally did not create? If
so, you've been victimized. Applications should never create or modify
anything in your documents folder without your permission.
{snip...]
If applications need to store shared files, that's what the \AppData and
\Application Data folders are for.
Sentiments I agree with...
Michael
http://www.manning.com/foord
> Somewhat off topic, but hooray, it looks like someone at MS rediscovered
> the command line and why "Long and Wordy Names with lots of spaces" are
> really annoying. Easier access to the application data directory is a
> good thing too.
>
> I guess moving to Vista wouldn't be all bad then ;)
>
> To get marginally back on topic, I would actually prefer to have a
> function like os.gethomedir() that takes on optional user name. (I don't
> want it enough to write a patch to make it happen though)
>
> Cheers,
> Nick.
>
>
___
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] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Michael Foord <[EMAIL PROTECTED]> wrote: > Note today's Coding Horror blog entry: "Don't Pollute User Space" > > http://www.codinghorror.com/blog/archives/001032.html > > Keep your dirty, filthy paws out of my personal user space! :-) Absolutely [...] > If applications need to store shared files, that's what the \AppData and > \Application Data folders are for. > > Sentiments I agree with... Yes, with the one proviso that Windows (XP, at least, maybe Vista is actually better in this regard) makes it extremely difficult for the user to manually do anything in these directories, so that I'd say this is only appropriate for fully application-maintained files. As far as I know, Windows lacks any really sensible place to store application configuration data which is meant to be user edited on occasion (e.g. rc/ini files, startup scripts, etc). That's often what I see ending up in %USERPROFILE% - even though as Christian points out, it's "officially" wrong. Paul. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote: > -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: >> Python's _winreg module and pywin32 expose several functions to >> get the >> paths from the registry but I don't think it has a simple function >> like >> get_mydocuments(). > > Careful with the name though. Microsoft Windows Vista did away with > 'My > Documents & Settings'. It is now C:\Users. > > So you get: > > C:\Users\\AppData\Local\(former Local Settings > \Application Data) > C:\Users\\AppData\Roaming\ (former Application Data) > C:\Users\\Documents (former My Documents) > C:\Users\\Music (former My Music) > C:\Users\\Pictures (former My Pictures) > C:\Users\\Videos(former My Videos) > yay, next up posix support *dreams* ~ro > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ > Vae victis! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/reed% > 40reedobrien.com ___ 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] PEP: Lazy module imports and post import hook
Christian Heimes <[EMAIL PROTECTED]> wrote: > I've attached the first public draft of my first PEP. Some brief thoughts from me on the PEP... Post import hooks sound great and a good idea. Lazy importing sounds like a recipe for hard to find bugs and rather too magic for my taste. Perhaps you should separate these two things into two PEPs and implementations? -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: > On 09/01/2008, Michael Foord <[EMAIL PROTECTED]> wrote: > >> Note today's Coding Horror blog entry: "Don't Pollute User Space" >> >> http://www.codinghorror.com/blog/archives/001032.html >> >> Keep your dirty, filthy paws out of my personal user space! >> > > :-) Absolutely > > [...] > >> If applications need to store shared files, that's what the \AppData and >> \Application Data folders are for. >> >> Sentiments I agree with... >> > > Yes, with the one proviso that Windows (XP, at least, maybe Vista is > actually better in this regard) makes it extremely difficult for the > user to manually do anything in these directories, Only because Windows XP uses a stupidly long path with spaces in it. It's not actually *hard* to navigate manually to these directories. If the windows installers created by the 'bdist' commands allow you to automatically put stuff there then it shouldn't be too much of a problem. > so that I'd say > this is only appropriate for fully application-maintained files. As > far as I know, Windows lacks any really sensible place to store > application configuration data which is meant to be user edited on > occasion (e.g. rc/ini files, startup scripts, etc). > What user editing is *meant* to be done with extension modules installed into a site directory. Programmer editing maybe... :-) Michael Foord > That's often what I see ending up in %USERPROFILE% - even though as > Christian points out, it's "officially" wrong. > > Paul. > > ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Michael Foord <[EMAIL PROTECTED]> wrote: > Only because Windows XP uses a stupidly long path with spaces in it. > It's not actually *hard* to navigate manually to these directories. The directories are also hidden. That does make it hard to navigate there. I know you can un-hide hidden files, but I view the hidden attribute as useful - just badly misused in this case, unless you assume that these directories are intended to be left alone by the user. > What user editing is *meant* to be done with extension modules installed > into a site directory. Programmer editing maybe... :-) Sorry, I had drifted slightly off topic here. I don't have a problem with user-specific extensions going in appdata, on the presumption that we're talking code only (and excluding something obscure like distutils' distutils.cfg file). Paul. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Jeroen Ruigrok van der Werven wrote: > Careful with the name though. Microsoft Windows Vista did away with 'My > Documents & Settings'. It is now C:\Users. > > So you get: > > C:\Users\\AppData\Local\(former Local Settings\Application Data) > C:\Users\\AppData\Roaming\ (former Application Data) > C:\Users\\Documents (former My Documents) > C:\Users\\Music (former My Music) > C:\Users\\Pictures (former My Pictures) > C:\Users\\Videos(former My Videos) My latest version uses the SHGetFolderPathW() function from ShlObj.h. It's the preferred way to get shell folder paths like CLSID_PERSONAL (my documents). It's compatible with 2000 and newer (maybe even older, but we don't support ME, NT4 or older) and works on Vista, too. Christian ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: > The directories are also hidden. That does make it hard to navigate > there. I know you can un-hide hidden files, but I view the hidden > attribute as useful - just badly misused in this case, unless you > assume that these directories are intended to be left alone by the > user. It's not an issue for experienced users. For the rest we can put a link in the start menu under Python 2.5 which opens a new explorer with the user package directory. Christian ___ 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] Coverity Scan, Python upgraded to rung 2
I read the announcement of the Python Users list and figured out that some of the other core developers might be interested in the news, too. Among other projects Python was upgraded to Rung 2 on the Coverity Scan list: http://scan.coverity.com/ Christian ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Christian Heimes <[EMAIL PROTECTED]> wrote: > It's not an issue for experienced users. For the rest we can put a link > in the start menu under Python 2.5 which opens a new explorer with the > user package directory. Um, I'm an experienced user and it's an issue for me... The problem isn't so much knowing where the directory is, as that tools (quite rightly) ignore (ie, hide!) hidden directories. For example, 4NT (my command shell) doesn't auto-complete hidden directory names by default, many tools' wildcard matching ignores them (always, not just by default). Blast, I said I wasn't going to start a big flamewar over Windows behaviour. I haven't seen anyone propose that something intended to be edited by a user be stored in a hidden directory (appdata) on Windows. As long as that is the case, I don't care. If you are suggesting that a file intended to be viewed/edited by a user manually should go in AppData, then please be explicit. We can then argue the concrete issues, rather than just theoretical principles. Paul. ___ 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] Coverity Scan, Python upgraded to rung 2
Joseph Armbruster wrote: > Christian, > > Is there any way you (or someone else) could post up the results? It > looks like you need a log in to check them out. I haven't figured out how to access the results. Who has a login and access to the site? Christian ___ 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] PEP: Lazy module imports and post import hook
Nick Craig-Wood wrote: > Christian Heimes <[EMAIL PROTECTED]> wrote: >> I've attached the first public draft of my first PEP. > > Some brief thoughts from me on the PEP... > > Post import hooks sound great and a good idea. > > Lazy importing sounds like a recipe for hard to find bugs and rather > too magic for my taste. > > Perhaps you should separate these two things into two PEPs and > implementations? > And now that I think about it some more, so long as the post-import hook implementation recognises that lazy import libraries *exist*, all it really needs to do is provide a way for the externally implemented lazy import to trigger whatever import hooks have been registered when the module is finally loaded. So count me in with the people that think it is worth separating the two ideas - just focus in the PEP on the API needed to make it possible for 3rd party implementation of lazy imports to interoperate correctly with the post-import hooks, without proposing to add such an implementation directly to the standard library. In the hands of power users lazy imports can definitely be a useful trick to speed up script start times. Those kinds of users will know where to find one of the existing solutions, or will write their own (as the responses to this thread seem to suggest). But I still have deep reservations about making them available as a standard library feature. My main concern is that the import lock is something Python users typically don't have to worry about (aside from the 'don't spawn a thread as a side effect of importing' guideline), but making the acquisition of the import lock implicit in accessing a module attribute is going to lead to some very nasty surprises for users that aren't as intimately familiar with the underlying mechanics of the import system. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Coverity Scan, Python upgraded to rung 2
Christian Heimes wrote: > Joseph Armbruster wrote: >> Christian, >> >> Is there any way you (or someone else) could post up the results? It >> looks like you need a log in to check them out. > > I haven't figured out how to access the results. > > Who has a login and access to the site? I know Neal has access (if I'm recalling the various checkin message correctly, he did the lion's share of the work in addressing the problems Coverity reported). I think some of the other folks on the security list may have one also. Searching the SVN version history for references to Coverity may provide an interesting list. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Changing PyAPI_DATA(type) into PyAPI_DATA(type, variablename)?
Hello, python-dev!
One-liner summary: Would it be possible to change PyAPI_DATA(type) into
PyAPI_DATA(type, variablename) to help portability to funny platforms?
We've been working on porting the Python 2.5.1 core to the Symbian S60
smartphone platform. Unlike the previous 2.2.2 port, this time we're
trying really hard to keep our changes clean so that they could some day
be accepted into the main Python codebase. One problem we've encountered
is that Symbian doesn't properly support exporting data from a DLL, and
instead we must export a function that returns a pointer to the variable
in question, and hide this from client applications using a macro:
In a generated header, dataexports.h:
#define Py_Verbose (*__DATAEXPORT_Py_Verbose())
extern __declspec(dllimport) int *__DATAEXPORT_Py_Verbose();
In a generated C file, dataexport.c:
__declspec(dllexport) int *__DATAEXPORT_Py_Verbose() { return
&Py_Verbose; }
dataexports.h is included into Python.h when Py_BUILD_CORE isn't
defined.
Now, the problem is that we haven't figured out any way to define the
PyAPI_DATA macro in its one-argument form so that this scheme would
work, since when compiling client applications we'd like all the
PyAPI_DATA declarations to expand to nothing, and get the declarations
from dataexport.h instead. The best solution we've come up with is to
change PyAPI_DATA into a two-argument form and change all declarations
accordingly. Whether to export data with this mechanism or directly
could be a pyconfig.h option, DATA_EXPORT_AS_FUNCTIONS (or
HAVE_DATA_EXPORT?). Briefly the changes would touch:
pyport.h:
#ifdef Py_BUILD_CORE
#define PyAPI_DATA(RTYPE,NAME) extern RTYPE NAME // data item
not exported from the Python DLL
#else
#define PyAPI_DATA(RTYPE,NAME) // PyAPI_DATA can be blank since
then the real declarations come from dataexports.h
#endif
pydebug.h and all other files that declare exported data:
PyAPI_DATA(int) Py_VerboseFlag;
-->
PyAPI_DATA(int, Py_VerboseFlag)
In addition, complex types such as function pointers and arrays would
need to be typedef'ed, e.g.:
PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE
*, char *);
-->
typedef char *(*t_PyOS_ReadlineFunctionPointer)(FILE *, FILE *,
char *);
PyAPI_DATA(t_PyOS_ReadlineFunctionPointer,
PyOS_ReadlineFunctionPointer)
and multiple PyAPI_DATA declarations on a line would need to be split to
several PyAPI_DATA declarations.
If this change isn't acceptable then we'd pretty much have to fork this
aspect of the interpreter - either by just maintaining a patch that's
applied to the headers or by making a preprocessor that fixes the
headers on the fly.
Does this sound reasonable? Any better ideas?
-Jukka
___
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] Coverity Scan, Python upgraded to rung 2
Christian> I read the announcement of the Python Users list and figured Christian> out that some of the other core developers might be Christian> interested in the news, too. Christian> Among other projects Python was upgraded to Rung 2 on the Christian> Coverity Scan list: http://scan.coverity.com/ I went to the run2 page: http://scan.coverity.com/rung2.html I shows 6 uninspected defects for Python. How do we see what they are? What is an uninspected defect? Any idea how the Coverity folks compute Defects/KLOC? For example, how does tcl manage to get a 0.0 score? Skip ___ 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] PEP: Lazy module imports and post import hook
Aside: Nick Coghlan wrote: > My main concern is that the import lock is something Python users > typically don't have to worry about (aside from the 'don't spawn a > thread as a side effect of importing' guideline)... I've never heard of this and I can't get Google to find it. Is it a deadlock problem? Neil ___ 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] PEP: Lazy module imports and post import hook
Neil Toronto wrote: > Aside: > > Nick Coghlan wrote: >> My main concern is that the import lock is something Python users >> typically don't have to worry about (aside from the 'don't spawn a >> thread as a side effect of importing' guideline)... > > I've never heard of this and I can't get Google to find it. Is it a > deadlock problem? Here's one reference: http://mail.python.org/pipermail/python-list/2004-December/295970.html TJG ___ 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] Coverity Scan, Python upgraded to rung 2
[EMAIL PROTECTED] wrote: I shows 6 uninspected defects for Python. How do we see what they are? > What is an uninspected defect? Any idea how the Coverity folks compute > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? I can't answer your question. I don't have access to the Python project on their site and the project is currently under maintenance. Maybe Neal can sheds some light on the Coverity Scan project. Christian ___ 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] Changing PyAPI_DATA(type) into PyAPI_DATA(type, variablename)?
> One-liner summary: Would it be possible to change PyAPI_DATA(type) into > PyAPI_DATA(type, variablename) to help portability to funny platforms? Quick response: this sounds fine to me. Of course, changing it in 2.5.x is not possible, but making the change in 2.6 should be possible. I would like to see some explicit rationale being recorded in the source so that people know what this was meant for and won't change it back. Regards, Martin ___ 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] Coverity Scan, Python upgraded to rung 2
On Jan 9, 2008 9:47 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > I shows 6 uninspected defects for Python. How do we see what they are? > > What is an uninspected defect? Any idea how the Coverity folks compute > > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? > > I can't answer your question. I don't have access to the Python project > on their site and the project is currently under maintenance. Maybe Neal > can sheds some light on the Coverity Scan project. I'm pretty sure I have an account and I can't get in either. I have contacted coverity asking if they can give accounts to other core developers besides Neal and myself. -- --Guido van Rossum (home page: http://www.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] PEP: Lazy module imports and post import hook
On Jan 9, 2008 7:38 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > > Christian Heimes <[EMAIL PROTECTED]> wrote: > >> I've attached the first public draft of my first PEP. > > > > Some brief thoughts from me on the PEP... > > > > Post import hooks sound great and a good idea. > > > > Lazy importing sounds like a recipe for hard to find bugs and rather > > too magic for my taste. > > > > Perhaps you should separate these two things into two PEPs and > > implementations? > > > > And now that I think about it some more, so long as the post-import hook > implementation recognises that lazy import libraries *exist*, all it > really needs to do is provide a way for the externally implemented lazy > import to trigger whatever import hooks have been registered when the > module is finally loaded. > > So count me in with the people that think it is worth separating the two > ideas - just focus in the PEP on the API needed to make it possible for > 3rd party implementation of lazy imports to interoperate correctly with > the post-import hooks, without proposing to add such an implementation > directly to the standard library. > I agree with Nick and Nick. This should really be two separate PEPs. -Brett ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: > If you are suggesting that a file intended to be viewed/edited by a > user manually should go in AppData, then please be explicit. We can > then argue the concrete issues, rather than just theoretical > principles. I'm frustrated as well. Neither AppData nor MyDocuments fulfill our requirements. I don't argue for AppData, I only argue against UserProfile as the base directory for a user package directory. I'm open for any suggestion which doesn't violate MS' style guides. (I don't want to imply that I like the style guide but we don't make the rules :( ) Christian ___ 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] Coverity Scan, Python upgraded to rung 2
[EMAIL PROTECTED] schrieb: > Christian> I read the announcement of the Python Users list and figured > Christian> out that some of the other core developers might be > Christian> interested in the news, too. > > Christian> Among other projects Python was upgraded to Rung 2 on the > Christian> Coverity Scan list: http://scan.coverity.com/ > > I went to the run2 page: > > http://scan.coverity.com/rung2.html On this page, when I click the 'sign in' link, I see the page http://scan.coverity.com/maintenance.html which says: """ Scan administrators are performing maintenance on the selected project. Normally, project members will have received notification in advance of any lengthy unavailability of their project. Please try again later, or contact [EMAIL PROTECTED] with any questions. Return to Main Page """ Could it be that they were a little bit early with the press release, and the rung2 scanner is not yet active? > I shows 6 uninspected defects for Python. How do we see what they are? > What is an uninspected defect? Any idea how the Coverity folks compute > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? Seems they are referring to the results of the rung 1 run (what ever 'rung' means ;-). With the account Neal made me some months ago, I can login on this page: http://scan.coverity.com:7475/ and see the scan results for Python. Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked "uninspected", 3 marked "pending", and 2 marked "bug". Thomas ___ 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] Coverity Scan, Python upgraded to rung 2
Guido van Rossum schrieb: > On Jan 9, 2008 9:47 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >> I shows 6 uninspected defects for Python. How do we see what they are? >> > What is an uninspected defect? Any idea how the Coverity folks compute >> > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? >> >> I can't answer your question. I don't have access to the Python project >> on their site and the project is currently under maintenance. Maybe Neal >> can sheds some light on the Coverity Scan project. > > I'm pretty sure I have an account and I can't get in either. I have > contacted coverity asking if they can give accounts to other core > developers besides Neal and myself. > As I said in the other reply, I can still login on this page: http://scan.coverity.com:7475/ It looks like about 20 users are registered; if wanted I can post the list here. Thomas ___ 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] PEP: Lazy module imports and post import hook
Brett Cannon wrote: > I agree with Nick and Nick. This should really be two separate PEPs. I'm fine with the proposal and I'm going to chop the PEP in two parts tonight. Somehow I suspect that the lazy import PEP will be postponed or reject. Christian ___ 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] Coverity Scan, Python upgraded to rung 2
Thomas Heller wrote: > Seems they are referring to the results of the rung 1 run (what ever 'rung' > means ;-). > With the account Neal made me some months ago, I can login on this page: > >http://scan.coverity.com:7475/ > > and see the scan results for Python. > > Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked > "uninspected", > 3 marked "pending", and 2 marked "bug". My dict says: rung (of a ladder)- Leitersprossen Python has climbed up one step (or rung) of the ladder. Do you have the required permission to add more users to the site? Christian ___ 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] Coverity Scan, Python upgraded to rung 2
Christian Heimes schrieb: > Thomas Heller wrote: >> Seems they are referring to the results of the rung 1 run (what ever 'rung' >> means ;-). >> With the account Neal made me some months ago, I can login on this page: >> >>http://scan.coverity.com:7475/ >> >> and see the scan results for Python. >> >> Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked >> "uninspected", >> 3 marked "pending", and 2 marked "bug". > > My dict says: rung (of a ladder)- Leitersprossen > > Python has climbed up one step (or rung) of the ladder. Thanks. I was too lazy to fire up dict.leo.org ;-) > Do you have the required permission to add more users to the site? No, I can only view the results (and add comments or so...). Thomas ___ 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] PEP: Lazy module imports and post import hook
At 09:20 PM 1/9/2008 +0100, Christian Heimes wrote: >Brett Cannon wrote: > > I agree with Nick and Nick. This should really be two separate PEPs. > >I'm fine with the proposal and I'm going to chop the PEP in two parts >tonight. > >Somehow I suspect that the lazy import PEP will be postponed or reject. Probably. After the split, I'll review things again, with a closer eye on the initialization order issues, especially with respect to ensuring that lazy imports set the corresponding attribute in the parent package at the right point in time. (It should happen *before* the submodule can actually be imported.) The big advantage to a stdlib implementation of lazy modules would be that it could be more vetted and "blessed" -- the downside is that it's a new and nontrivial implementation. :( ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Christian Heimes <[EMAIL PROTECTED]> wrote: > Paul Moore wrote: > > If you are suggesting that a file intended to be viewed/edited by a > > user manually should go in AppData, then please be explicit. We can > > then argue the concrete issues, rather than just theoretical > > principles. > > I'm frustrated as well. Neither AppData nor MyDocuments fulfill our > requirements. For what? If you're talking about a per-user site-packages directory, I have no problem with AppData (as Michael said, there's no intention that users be able to edit the files). Of course, modules/packages/extensions don't really qualify as application *data*, so it is a somewhat odd usage certainly, but it's not disastrous. Windows doesn't really have a concept of a per-user application code directory. Come to that, if I use a bdist_wininst installer to install a package in my personal site packages, then I log off and you log on, would you expect to see my package when you look in add/remove programs? Would you expect to be able to uninstall it? Would you expect to be able to install a personal copy of your own? What would we see in add/remove programs *then*?? No matter how you cut it, Windows isn't designed for per-user installable programs. Maybe a per-user site-packages just isn't appropriate on Windows. Paul. PS This is mostly theoretical for me, as I don't have a personal need for a per-user site packages directory on any of the machines I use. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: [...] > No matter how you cut it, Windows isn't designed for per-user > installable programs. Maybe a per-user site-packages just isn't > appropriate on Windows. > This reminds me of the early days of Microsoft Terminal Service (read: "X Window done wrong fifteen years later"), when various applications had to be modified to stop saving per-user data in global locations. It underlines the fact that essentially Windows is still betrayed by its original conception as a single-user system. The idea that users would /program their own computers/ was totally alien to the Windows mindset. looking-at-Vista-and-thinking-very-hard-ly y'rs - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 5:49 PM, Tristan Seligmann wrote: > > In that case how about: > > ~/.local/lib/pythonX.Y/site-packages > > or: > > ~/local/lib/pythonX.Y/site-packages > > I believe both of these locations are already in use by various > systems > / people, so it would fit in better with existing practice. I like the former path. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4VoJ3EjvBPtnXfVAQK9zQP/dup8RHQha0v9ZkYee+L5/8/fhvIHBEoP MGkBxZUv79SmtnY4WWovS66NYAuKHlChFN0VSZCUO8o7WE8b52lXhgeG2xGX/pU/ MZ6D6zjxZmFhQjLLNf5gRcvchYHM+18AYQFapnuCpV048cgmJ7DQcGqznpyYRhnm SvqTeBtstNw= =HYwR -END PGP SIGNATURE- ___ 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] some bugs that need attention
Hi, I've taken a look at some bugs in the bugtracker. I think these should be closed: http://bugs.python.org/issue1720992 is about automatic imports. http://bugs.python.org/issue1448325 and http://bugs.python.org/issue1566086 is about the regular expression engine "hanging". These are duplicates of http://bugs.python.org/issue1662581 and should be closed. Regards, - Ralf ___ 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] PEP: Post import hooks
I've parted the former PEP as promised. Here is the post import hook.
I'll tackle the other half of the PEP later.
PEP: 369
Title: Post import hooks
Version: $Revision$
Last-Modified: $Date$
Author: Christian Heimes
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 02-Jan-2008
Python-Version: 2.6, 3.0
Post-History:
Abstract
This PEP proposes enhancements for the import machinery to add
post import hooks. It is intended primarily to support the wider
use of abstract base classes that is expected in Python 3.0.
The PEP originally started as a combined PEP for lazy imports and
post import hooks. After some discussion on the python-dev mailing
list the PEP was parted in two separate PEPs. [1]_
Rationale
=
Python has no API to hook into the import machinery and execute code
*after* a module is successfully loaded. The import hooks of PEP 302 are
about finding modules and loading modules but they were not designed to
as post import hooks.
Use cases
=
A use case for a post import hook is mentioned in Nick Coghlan's initial
posting [2]_. about callbacks on module import. It was found during the
development of Python 3.0 and its ABCs. We wanted to register classes
like decimal.Decimal with an ABC but the module should not be imported
on every interpreter startup. Nick came up with this example::
@imp.when_imported('decimal')
def register(decimal):
Inexact.register(decimal.Decimal)
The function ``register`` is registered as callback for the module named
'decimal'. When decimal is imported the function is called with the
module object as argument.
While this particular example isn't necessary in practice, (as
decimal.Decimal will inherit from the appropriate abstract Number base
class in 2.6 and 3.0), it still illustrates the principle.
Existing implementations
PJE's peak.util.imports [3]_ implements post load hooks. My
implementation shares a lot with his and it's partly based on his ideas.
Post import hook implementation
===
Post import hooks are called after a module has been loaded. The hooks
are callable which take one argument, the module instance. They are
registered by the dotted name of the module, e.g. 'os' or 'os.path'.
The callable are stored in the dict ``sys.post_import_hooks`` which
is a mapping from names (as string) to a list of callables or None.
States
--
No hook was registered
''
sys.post_import_hooks contains no entry for the module
A hook is registered and the module is not loaded yet
'
The import hook registry contains an entry
sys.post_import_hooks["name"] = [hook1]
A module is successfully loaded
'''
The import machinery checks if sys.post_import_hooks contains post import
hooks for the newly loaded module. If hooks are found then the hooks are
called in the order they were registered with the module instance as first
argument. The processing of the hooks is stopped when a method raises an
exception. At the end the entry for the module name is removed from
sys.post_import_hooks, even when an error has occured.
A module can't be loaded
The import hooks are neither called nor removed from the registry. It
may be possible to load the module later.
A hook is registered but the module is already loaded
'
The hook is fired immediately.
C API
-
New PyImport_* API functions
PyObject* PyImport_GetPostImportHooks(void)
Returns the dict sys.post_import_hooks or NULL
PyObject* PyImport_NotifyModuleLoaded(PyObject *module)
Notify the post import system that a module was requested. Returns the
module or NULL if an error has occured.
PyObject* PyImport_RegisterPostImportHook(PyObject *callable, PyObject
*mod_name)
Register a new hook ``callable`` for the module ``mod_name``
The PyImport_PostImportNotify() method is called by
PyImport_ImportModuleLevel()::
PyImport_ImportModuleLevel(...)
{
...
result = import_module_level(name, globals, locals, fromlist,
level);
result = PyImport_PostImportNotify(result);
...
}
Python API
--
The import hook registry and two new API methods are exposed through the
``sys`` and ``imp`` module.
sys.post_import_hooks
The dict contains the post import hooks: {"name" : [hook1, hook2], ...}
imp.register_post_import_hook(hook: "callable", name: str)
Register a new hook *hook* for the module *name*
imp.notify_module_loaded(module: "module instance") -> module
Notify the system that a module has been loaded. The method is provided
for compatibility with existing lazy / deferred import extensions.
The when_imported function decorator is also in the imp module,
which is equivalent to:
def when_imported(name):
def register(hook):
reg
Re: [Python-Dev] PEP: Post import hooks
At 03:20 AM 1/10/2008 +0100, Christian Heimes wrote: >PyObject* PyImport_NotifyModuleLoaded(PyObject *module) >Notify the post import system that a module was requested. Returns the >module or NULL if an error has occured. The big problem here is that the interaction with laziness is actually pretty complex, when it comes to re-entrancy and initialization order. A package can actually import a submodule, and not yet be finished importing, for example. So you can actually have child hooks executing before parent hooks in this case. The "Importing" package prevents this by not registering child hooks until a parent is actually imported, thus guaranteeing a sane hook execution order. Relative order for hooks targeting the same module is maintained, but parent module hooks are guaranteed to execute before child hooks, even if the child finishes importing before the parent. This would be a bit trickier to implement with your C API, since "Importing" does this by registering a lot of lambdas. But, now that I've reviewed my own code and pieced back together the rationale for it doing things in this seemingly-odd way, it makes sense. There's also one twist that I haven't sorted out yet: "Importing" guarantees that a parent module 'foo' will have a 'bar' attribute for the 'foo.bar' module, if 'foo.bar' is lazy. It does this by registering a callback, ideally *before* any other callback is registered for 'foo' or 'foo.bar' that would look at 'foo.bar'. I don't see how to maintain this condition in a world where import callbacks can be registered independently. Bleah. All of the above isn't really a good explanation of the problem. Let me try to simplify it: * Lazy importing needs to guarantee that foo.bar = sys.modules['foo.bar'], when callbacks for 'foo.bar' execute (in case they refer to foo.bar) * To do this, it registers a callback that sets foo.bar = sys.modules['foo.bar'], and does not actually register any foo.bar callbacks until 'foo' is really imported (and thus foo.bar gets set by that callback) In the case of the PEP, it's harder for me to figure out what happens, because you might not have any lazy modules around, and the foo.bar issue would then not come up. You also have the possibility of a problem where a lazy import callback occurs in 3rd party code, while callbacks are occurring from the import machinery. (Which means that the notification API should probably set the hooks entry to None while it's running, so that if it's called from inside a hook, it will not double-run the hooks, and new hooks registered while hooks are running will get run immediately as they are encountered, instead of getting added to the list.) ___ 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] Coverity Scan, Python upgraded to rung 2
On Jan 9, 2008 1:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Thomas Heller wrote: > > Seems they are referring to the results of the rung 1 run (what ever 'rung' > > means ;-). > > With the account Neal made me some months ago, I can login on this page: > > > >http://scan.coverity.com:7475/ > > > > and see the scan results for Python. > > > > Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked > > "uninspected", > > 3 marked "pending", and 2 marked "bug". > > My dict says: rung (of a ladder)- Leitersprossen > > Python has climbed up one step (or rung) of the ladder. They botched the link where it says Sign in. Use the link Thomas posted, ie: http://scan.coverity.com:7475/ That will show you the results from the latest coverity checker. > Do you have the required permission to add more users to the site? I think only Coverity can add people. You can send them a message if you would like to be added: [EMAIL PROTECTED] Or you can send mail to me and I can forward along all the people that would like to be added. I'll wait a few days to collect names so I can batch up the request. n ___ 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] Coverity Scan, Python upgraded to rung 2
On Jan 9, 2008 9:08 AM, <[EMAIL PROTECTED]> wrote: > > Christian> I read the announcement of the Python Users list and figured > Christian> out that some of the other core developers might be > Christian> interested in the news, too. > > Christian> Among other projects Python was upgraded to Rung 2 on the > Christian> Coverity Scan list: http://scan.coverity.com/ > > I went to the run2 page: > > http://scan.coverity.com/rung2.html > > I shows 6 uninspected defects for Python. How do we see what they are? > What is an uninspected defect? Any idea how the Coverity folks compute > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? The 6 have been inspected by me and I never came to a conclusion of whether they were a problem or not. There are 3 things which should be fixed and I haven't gotten around to them. They are not a big deal: Python/traceback.c line 177 Objects/codeobject.cline 322 Modules/mmapmodule.cline 1080 For traceback.c, namebuf defined on line 155 should be moved out one block since filename is an alias to namebuf and it is used outside the current scope. I think this is unlikely to be a problem in practice, but is technically wrong and should be fixed. For codeobject.c, line 327 should not be reachable. I kinda like the code as it is even though it is currently dead. I never decided if I wanted to change that or suppress the warning. For mmapmodule.c, fd should be checked for -1 before calling stat on line 1064. The rest were not obvious problems to me, and I never returned to them. n ___ 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] Coverity Scan, Python upgraded to rung 2
On Jan 9, 2008 9:08 AM, <[EMAIL PROTECTED]> wrote: > > I went to the run2 page: > > http://scan.coverity.com/rung2.html > > I shows 6 uninspected defects for Python. How do we see what they are? > What is an uninspected defect? Any idea how the Coverity folks compute > Defects/KLOC? For example, how does tcl manage to get a 0.0 score? Sorry, I forgot to answer the second part of your question. I have no idea how they compute Defects/KLOC. But the data is very old so I wouldn't worry about what that says. The most recent run has 286622 lines in 602 files. I already mentioned the 3 defects that should be fixed. Not sure what to do about the rest. n ___ 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
