|
From: SourceForge.net <no...@so...> - 2007-07-18 14:12:33
|
Feature Requests item #1755527, was opened at 2007-07-17 10:33 Message generated for change (Comment added) made by kchmbrln You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ken (kchmbrln) Assigned to: Nobody/Anonymous (nobody) Summary: Default to buffer for win32ts.WTSQuerySessionInformation Initial Comment: Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided. It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it. Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed. Something like (untested): switch (WTSInfoClass){ ... default: void *newbuf ret=PyBuffer_New(bufsize); ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf); memcpy(newbuf, buf, bufsize); } ---------------------------------------------------------------------- >Comment By: ken (kchmbrln) Date: 2007-07-18 09:12 Message: Logged In: YES user_id=1847088 Originator: YES I guess if Roger is going to implement the last two cases here that kinda makes the question moot. Philosophically speaking, though, it seems to me that getting data that may contain bad pointers is still preferable to not being able to get any data at all, and having fragile code that may break with an upgrade is still preferable to not having any way to code it at all. Maybe another alternative would be to continue to raise the exception, but to provide the buffer contents along with it. At least then the user should not be surprised by an upgrade breaking the workaround. As for Mark's idea of adding an extra parameter to ask for the raw buffer -- I can imagine that could be useful if, for example, you wanted to serialize some complex structure in its already packed form without having it unpacked for you and then having to repack it. I don't, however, see much potential for that with WTSQuerySessionInformation. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-07-18 00:25 Message: Logged In: YES user_id=771074 Originator: NO Another issue with copying the buffer is that the buffer could contain pointers to addresses inside the original buffer, which would become invalid after copying and freeing the original buffer. There are only 2 classes of information not supported yet (WTSClientAddress and WTSClientDisplay), so I'll go ahead and implement them. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-07-17 16:46 Message: Logged In: YES user_id=14198 Originator: NO If we do that, it would prevent us upgrading the code in the future (as it would then break code which assumed the buffer). An alternative might be an extra param to indicate if a buffer is wanted or not, which would then be used in all cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&group_id=78018 |
