On Fri, 4 Aug 2006, Oren Tirosh wrote:
> Compatibility with Windows "GUIDs" may be one of the most important
> use cases for the UUID module. It's important to resolve this or users
> will have unpleasant surprises. I did.
[...]
> alternatives:
>
> 1. Default is big endian byte order. Little endia
On 04/08/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Aug 2006, Oren Tirosh wrote:
> > The UUID module uses network byte order, regardless of the platform
> > byte order. On little-endian platforms like Windows the ".bytes"
> > property of UUID objects is not compatible with the memory la
On Thu, 3 Aug 2006, Oren Tirosh wrote:
> The UUID module uses network byte order, regardless of the platform
> byte order. On little-endian platforms like Windows the ".bytes"
> property of UUID objects is not compatible with the memory layout
RFC 4122 says:
In the absence of explicit applica
The UUID module uses network byte order, regardless of the platform
byte order. On little-endian platforms like Windows the ".bytes"
property of UUID objects is not compatible with the memory layout of
UUIDs:
>>> import uuid
>>> import pywintypes
>>> s = '{00112233-4455-6677-8899-aabbccddeeff}'
>>
On Mon, 12 Jun 2006, Giovanni Bajo wrote:
> GetSystemDirectory() is the official way to find the system directory.
You're right. I've added a call to GetSystemDirectory, with a fallback
to the usual locations if it doesn't work.
> Another thing that you might do is to drop those absolute system
Ka-Ping Yee wrote:
> I'd like to, but i don't want to use a method for finding the system
> directory that depends on ctypes. Is there a more general way?
I think
os.path.join(os.environ["SystemRoot"], "system32")
should be fairly reliable. If people are worried that the directory
might not be
At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
>Thomas Heller wrote:
> > I don't know if this is the uuidgen you're talking about, but
> > on linux there is libuuid:
>
>Thanks!
>
>Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py .
>
>Phillip J. Eby wrote:
> > By the way, I
On 6/12/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> > Some comments on the code:
> >
> > > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
> >
> > Can we get rid of these absolute paths? Something like this should suffice:
> >
> > >>> from
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>>> for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>>
>> Can we get rid of these absolute paths? Something like this should
>> suffice:
>>
> from ctypes import *
> buf = create_string_buffer(4096)
> windll.kernel32.GetSystemDirecto
On Sun, 11 Jun 2006, Phillip J. Eby wrote:
> At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
> >I've added code to make uuid1() use uuid_generate_time() if available
> >and uuid4() use uuid_generate_random() if available. These functions
> >are provided on Mac OS X (in libc) and on Linux (in libuu
On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> Some comments on the code:
>
> > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>
> Can we get rid of these absolute paths? Something like this should suffice:
>
> >>> from ctypes import *
> >>> buf = create_string_buffer(4096)
> >>> windl
Thomas Heller wrote:
> I don't know if this is the uuidgen you're talking about, but
> on linux there is libuuid:
Thanks!
Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py .
Phillip J. Eby wrote:
> By the way, I'd love to see a uuid.uuid() constructor that simply calls th
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Quite a few people have expressed interest in having UUID
> functionality in the standard library, and previously on this
> list some suggested possibly using the uuid.py module i wrote:
>
> http://zesty.ca/python/uuid.py
Some comments on the code:
>
Thomas> On OS X, this call is not available, but /usr/lib/libc.dylib has
Thomas> a uuid_generate function which is apparently compatible to the
Thomas> linux example I posted above.
Confirmed:
% python
Python 2.5a2 (trunk:46644M, Jun 4 2006, 10:58:16)
[GCC 4.0.0 (Apple
Paul Moore wrote:
> On 6/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> ...so i looked at PEAK's getnodeid48() routine and borrowed the
>> Win32 calls from there, with a comment giving attribution to PEAK.
>
> Instead of using pywin32, could you use ctypes, as that's part of core
> Python? It lo
Phillip J. Eby wrote:
> At 06:39 PM 6/10/2006 +0200, Thomas Heller wrote:
>>I don't know if this is the uuidgen you're talking about, but on linux there
>>is libuuid:
>>
>> >>> from ctypes import *
>> >>> lib = CDLL("libuuid.so.1")
>> >>> uuid = create_string_buffer(16)
>> >>> lib.uuid_generate(byr
At 06:39 PM 6/10/2006 +0200, Thomas Heller wrote:
>I don't know if this is the uuidgen you're talking about, but on linux there
>is libuuid:
>
> >>> from ctypes import *
> >>> lib = CDLL("libuuid.so.1")
> >>> uuid = create_string_buffer(16)
> >>> lib.uuid_generate(byref(uuid))
>2131088494
> >>> fro
At 11:16 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
>On Sat, 10 Jun 2006, Thomas Heller wrote:
> > [some nice ctypes code]
>
>Done. Works like a charm. Thanks for providing the code!
>
>On Sat, 10 Jun 2006, Phillip J. Eby wrote:
> > Also, for Python 2.5, these imports could probably be replaced with
Phillip J. Eby wrote:
> At 08:22 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
>>Finally, Phillip brought up PEAK:
>> > PEAK's uuid module does this such that if win32all is present,
>> > you get a Windows GUID, or if you have a FreeBSD 5+ or
>> > NetBSD 2+ kernel you use the local platform uuidgen API.
On Sat, 10 Jun 2006, Thomas Heller wrote:
> [some nice ctypes code]
Done. Works like a charm. Thanks for providing the code!
On Sat, 10 Jun 2006, Phillip J. Eby wrote:
> Also, for Python 2.5, these imports could probably be replaced with a
> ctypes call, though I'm not experienced enough w/ctyp
At 08:22 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
>Finally, Phillip brought up PEAK:
> > PEAK's uuid module does this such that if win32all is present,
> > you get a Windows GUID, or if you have a FreeBSD 5+ or
> > NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.:
>
>...so i looked
On Sat, 10 Jun 2006, Thomas Heller wrote:
> I have not tested the speed, but extending my snippet to also work
> on 98 should be nearly trivial:
>
> try:
> _func = windll.rpcrt4.UuidCreateSequential
> except AttributeError:
> _func = windll.rpcrt4.UuidCreate
>
> def CreateGuid():
> uuid
Ka-Ping Yee wrote:
> Hi Thomas,
>
>> This does not work, for several reasons.
>>
>> 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you
>> cannot slice:
>
> You're right. The PEAK code must have been based on an earlier
> version of the CreateGuid() routine.
>
> I've fixe
Hi Thomas,
> This does not work, for several reasons.
>
> 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you
> cannot slice:
You're right. The PEAK code must have been based on an earlier
version of the CreateGuid() routine.
I've fixed this, and added detection of the UU
On 6/10/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 6/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > ...so i looked at PEAK's getnodeid48() routine and borrowed the
> > Win32 calls from there, with a comment giving attribution to PEAK.
>
> Instead of using pywin32, could you use ctypes, as th
Ka-Ping Yee wrote:
> Finally, Phillip brought up PEAK:
>> PEAK's uuid module does this such that if win32all is present,
>> you get a Windows GUID, or if you have a FreeBSD 5+ or
>> NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.:
>
> ...so i looked at PEAK's getnodeid48() routi
On 6/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> ...so i looked at PEAK's getnodeid48() routine and borrowed the
> Win32 calls from there, with a comment giving attribution to PEAK.
Instead of using pywin32, could you use ctypes, as that's part of core
Python? It looks like the only Win32 API
On Sat, 10 Jun 2006, Mike Brown wrote:
> I have a couple of suggestions for improving that implementation:
>
> 1. You're currently using os.urandom, which can raise a NotImplementedError.
> You should be prepared to fall back on a different PRNG...
The latest version (http://zesty.ca/python/uuid.p
Okay. I have done as Fredrik suggested:
> 6. Combine 2 and 3: require the user to pass in a MAC argument
> to uuid1, but provide a SlowGetMacAddress helper that wraps
> the existing code.
I agree with Thomas Wouters:
> That sounds like the right thing to do, although I wou
Fredrik Lundh wrote:
> Ka-Ping Yee wrote:
>
> > Quite a few people have expressed interest in having UUID
> > functionality in the standard library, and previously on this
> > list some suggested possibly using the uuid.py module i wrote:
> >
> > http://zesty.ca/python/uuid.py
>
> +1!
+1 as
On 6/9/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
6. Combine 2 and 3: require the user to pass in a MAC argument to uuid1, but provide a SlowGetMacAddress helper that wraps the existing code.That sounds like the right thing to do, although I wouldn't call it "slow"; ju
Fredrik> the reason for making it a required argument is to make it
Fredrik> clear that the code is using a "suboptimal" way to get at the
Fredrik> MAC value.
Fredrik> explicit is better than implicit etc etc.
Can't we expect there will be a faster way to get at the MAC address a
[EMAIL PROTECTED] wrote:
> Fredrik> 6. Combine 2 and 3: require the user to pass in a MAC argument
> Fredrik> to uuid1, but provide a SlowGetMacAddress helper that wraps
> Fredrik> the existing code.
>
> Or make the MAC address an optional arg to uuid1. If given, use it.
Fredrik> 6. Combine 2 and 3: require the user to pass in a MAC argument
Fredrik> to uuid1, but provide a SlowGetMacAddress helper that wraps
Fredrik> the existing code.
Or make the MAC address an optional arg to uuid1. If given, use it. If
not, use the slow lookup (then
Ka-Ping Yee wrote:
> Quite a few people have expressed interest in having UUID
> functionality in the standard library, and previously on this
> list some suggested possibly using the uuid.py module i wrote:
>
> http://zesty.ca/python/uuid.py
+1!
> This module provides a UUID class, functio
Quite a few people have expressed interest in having UUID
functionality in the standard library, and previously on this
list some suggested possibly using the uuid.py module i wrote:
http://zesty.ca/python/uuid.py
This module provides a UUID class, functions for generating
version 1, 3, 4, an
36 matches
Mail list logo
