| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
this makes sure that the child does not continue
testing.
|
| |
|
|
|
|
|
|
|
|
| |
OSX 10.6 in that after os.fork() the parent and
child generate the same sequence of UUIDs.
This patch falls back to the the Python implementation
on OSX 10.6 or later.
Fixes issue #8621.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. The assumptions in check_node() were too restrictive:
- Hardware addresses with universal_local_bit=1 are valid
(locally administered).
- Many of the tested functions (including uuid.getnode())
may return valid RFC 4122 random node IDs. These are pretty
much random 48-bit values with the multicast bit set to 1.
2. _unixdll_getnode() calls _uuid_generate_time(), which may be None
on some platforms. The resulting TypeError is now caught.
|
| | |
|
| |
|
|
|
| |
implementation of either function depends on ctypes but uuid as a whole does
not.
|
| |
|
|
| |
on systems with low clock resolution.
|
| |
|
|
|
|
|
| |
little-endian byte order on Windows), and to work around clocks
with low resolution yielding duplicate UUIDs.
Anthony Baxter has approved this change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These problems may mask more important, real problems.
One or both methods are known to fail on: Solaris, OpenBSD, Debian, Ubuntu.
They pass on Windows and some Linux boxes.
|
| |
|
|
|
|
|
| |
concept, and that different ways of trying to find "the
hardware address" may return different results. Certainly
true on both of my Windows boxes, and in different ways
(see whining on python-dev).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a node number disagrees, keep track of all sources & the
node numbers they reported, and stick all that in the error message.
Changed all callers to supply a non-empty "source" argument; made
the "source" argument non-optional.
On my box, test_uuid still fails, but with the less confusing output:
AssertionError: different sources disagree on node:
from source 'getnode1', node was 00038a000015
from source 'getnode2', node was 00038a000015
from source 'ipconfig', node was 001111b2b7bf
Only the last one appears to be correct; e.g.,
C:\Code\python\PCbuild>getmac
Physical Address Transport Name
=================== ==========================================================
00-11-11-B2-B7-BF \Device\Tcpip_{190FB163-5AFD-4483-86A1-2FE16AC61FF1}
62-A1-AC-6C-FD-BE \Device\Tcpip_{8F77DF5A-EA3D-4F1D-975E-D472CEE6438A}
E2-1F-01-C6-5D-88 \Device\Tcpip_{CD18F76B-2EF3-409F-9B8A-6481EE70A1E4}
I can't find anything on my box with MAC 00-03-8a-00-00-15, and am
not clear on where that comes from.
|
| | |
|
| |
|
|
|
|
| |
by regrtest.py.
We really need a simpler testing framework.
|
| | |
|
| | |
|
|
|
This module has been tested so far on Windows XP (Python 2.4 and 2.5a2),
Mac OS X (Python 2.3, 2.4, and 2.5a2), and Linux (Python 2.4 and 2.5a2).
|
