On 25/03/2012 09:12, Albert-Jan Roskam wrote:
Thank you so much for this! I think this would also be a valuable
addition to os.path (where I'd expect it to be).
You call WNetGetConnection twice: one time with a 'dummy' string
buffer, and one time with a buffer of the exact required length. If
I'd run a function getUncPath() on a gazillion paths, wouldn't it be
more effcient to hard-code the length to 2048 as you suggest in your
comment?
The fail-and-resize-the-buffer dance is fairly common on
Windows. The advantage of the technique is that
it will cope with any path length. If you hardcode to 2048
(or whatever length) then the time will come when you'll
encounter a longer path and then you'll have to rewrite your
code with 4096 or 8192 etc. Obviously, if you have control
over all the paths you're interested in, and you know that
they can't grow beyond MAXLEN characters, then by all means
use MAXLEN as the buffer size and shorten your code.
In terms of efficiency, I imagine you'd have to run the function
on an unusually high number of paths -- and you've only got
26 possible drive letters in the first place -- so it looks
to me like a premature optimisation!
TJG
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
