msg127442 - (view) |
Author: Keith Dart (Keith.Dart) |
Date: 2011-01-29 17:10 |
When the uuid.py module is simply imported it has the side effect of forking a subprocess (/sbin/ldconfig) and doing a lot of stuff find a uuid implementation by ctypes. This is undesirable in many contexts. It would be better to perform those tasks on demand, when the first UUID is actually requested. In general, imports should avoid unnecessary system call side effects. This also makes testing easier.
|
msg127989 - (view) |
Author: Vetoshkin Nikita (nvetoshkin) |
Date: 2011-02-05 14:05 |
I think launching external tools like ifconfig and ipconfig can be avoided pretty easily. There are many recipes around the net how to use native API's.
About ctypes' horrible logic during find_library call - don't know yet.
|
msg127998 - (view) |
Author: Kenny Meyer (knny-myer) |
Date: 2011-02-05 15:55 |
With the attached patch the "heavy work" will be done on request, when calling uuid1() or uuid4() not on import.
I am working off from the py3k svn branch. Is it necessary to submit a separate patch for py2 branch?
|
msg128001 - (view) |
Author: Senthil Kumaran (orsenthil) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 17:10 |
Kenny, I don't see a problem with uuid is *imported*, it just creates a couple of STANDARD UUID class objects for use later. And this seems to just set the number and validates it. I don't see any subprocess calls performed. Perhaps you were referring to scenarios of using uuid1/uuid5 methods in mac and suggesting improvements to it by your patch?
|
msg128008 - (view) |
Author: R. David Murray (r.david.murray) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 18:30 |
If you do 'python -c "import uuid" under strace, _posixsubprocess is definitely loaded, and a pipe2 call is made.
Take a look at the code starting at (py3k trunk) line 418 (try:). That's where the weird stuff happens, which is what the patch is addressing.
Ken: thanks for working on this.
|
msg128010 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 18:44 |
Thanks for posting a patch! I have two comments:
- Have you run test_uuid? When I run it, it seems to go into an infinite loop somewhere and I need to kill the process.
- uuid should work even when ctypes is not available, so you can't just put an import statement at the top-level without a fallback
|
msg128012 - (view) |
Author: Vetoshkin Nikita (nvetoshkin) |
Date: 2011-02-05 19:01 |
>uuid should work even when ctypes is not available
A bit of offtopic: why can't we assume that ctypes is available?
|
msg128013 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 19:04 |
> A bit of offtopic: why can't we assume that ctypes is available?
Because ctypes (or, actually, the libffi it relies on) needs specific low-level code for each platform it runs on, and not all platforms have such code.
Another reason is that ctypes is dangerous and some administrators might prefer to disable it (especially on shared hosting ala Google App Engine).
|
msg128015 - (view) |
Author: Kenny Meyer (knny-myer) |
Date: 2011-02-05 19:14 |
Thanks for pointing that out! I guess that is the reason you did the import
in a try block.
|
msg128016 - (view) |
Author: Vetoshkin Nikita (nvetoshkin) |
Date: 2011-02-05 19:14 |
Maybe I understood and ctypes ImportError simply must be handled and fallbacked to something else. But there are only 3 ways of getting MAC address:
1. using popen
2. using ctypes and native calls
3. using C API and performing native calls in extension
And ctypes seems to be the best choice: it's portable across Python VMs (better that 3) and faster (better than 1).
|
msg128017 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 19:17 |
> Maybe I understood and ctypes ImportError simply must be handled and
> fallbacked to something else.
Indeed.
> But there are only 3 ways of getting MAC address:
> 1. using popen
> 2. using ctypes and native calls
> 3. using C API and performing native calls in extension
>
> And ctypes seems to be the best choice: it's portable across Python
> VMs (better that 3) and faster (better than 1).
Perhaps, but doing without ctypes should still be possible, otherwise
it's a regression.
|
msg128018 - (view) |
Author: Keith Dart (kdart) |
Date: 2011-02-05 19:23 |
It's also possible using existing wrapped os system calls. One exaple is here: http://code.google.com/p/pycopia/source/browse/trunk/aid/pycopia/ifconfig.py
Although that one doesn't current support MAC addresses, but it could. The socket module also now support the netlink socket on Linux, so it shouldbe possible to use that for getting MAC address on Linux.
|
msg128019 - (view) |
Author: Vetoshkin Nikita (nvetoshkin) |
Date: 2011-02-05 19:27 |
>It's also possible using existing wrapped os system calls.
That's right, on linux we can use ioctls but windows would require win api calls like this one: http://stackoverflow.com/questions/166506/finding-local-ip-addresses-in-python/166992#166992
|
msg128020 - (view) |
Author: Keith Dart (kdart) |
Date: 2011-02-05 19:41 |
I'm thinking Python could use a general purpose ifconfig/mac-layer module that uuid.py could then just use.
|
msg128021 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-02-05 19:42 |
> I'm thinking Python could use a general purpose ifconfig/mac-layer
> module that uuid.py could then just use.
Perhaps, but that's really out of scope for this issue. Feel free to
open another issue.
|
msg178293 - (view) |
Author: Hynek Schlawack (hynek) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2012-12-27 10:47 |
The patch hasn’t incorporated Antoine’s comments AFAICT.
Also I don’t see this fit for back porting to bug fix releases. Correct me if I’m wrong.
|
msg178297 - (view) |
Author: Christian Heimes (christian.heimes) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2012-12-27 12:31 |
Hynek, you are right.
|
msg182778 - (view) |
Author: Jyrki Pulliainen (nailor) * |
Date: 2013-02-23 17:38 |
The implementation does not actually end up in infinite loop, just repeating the loading of the CDLL is slow.
I added caching to that and fixed the ctypes imports too.
|
msg182873 - (view) |
Author: Hynek Schlawack (hynek) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2013-02-24 12:40 |
Jyrki, roundup doesn’t seem to recognize you patch so we can’t review it in Rietveld. Could you re-try, maybe using hg?
|
msg182875 - (view) |
Author: Jyrki Pulliainen (nailor) * |
Date: 2013-02-24 13:17 |
Here's a second take on the patch
|
msg264151 - (view) |
Author: Martin Panter (martin.panter) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2016-04-25 03:51 |
One thing I am wondering about is why we have to use find_library() at all. Wouldn’t it be more robust, and more efficient, to call CDLL() directly? We just have to know the exactly library version we are expecting. On Linux, the full soname is libuuid.so.1. It seems on OS X it is called libc.dylib (but it would be good for someone else to confirm).
# The uuid_generate_* routines are provided by libuuid on at least
# Linux and FreeBSD, and provided by libc on Mac OS X.
if sys.platform == "darwin":
libname = "libc.dylib"
else:
libname = "libuuid.so.1"
_ctypes_lib = ctypes.CDLL(libname)
|
msg264998 - (view) |
Author: Michael Felt (Michael.Felt) * |
Date: 2016-05-06 17:10 |
I cannot comment on uuid directly, but for me, this is yet another example of how assumptions can break things.
imho - if you know the exact version of s shared library that you want, calling cdll directly should be find. Maybe find_library is historic.
However, an advantage to calling find_library is that it should lead to an OSError if it cannot be loaded. But trapping OSError on a call to ctypes.cdll or testing for None (NULL) from find_library() is the option of a developer using the ctypes interface.
As far as libFOO.so.N - do you always want to assume it is going to be version N, or are you expecting to be able to work work version N+X?
Again, find_library() can give you the library name it would load - but a programmer must be aware of the platform differences (e.g., AIX returns not a filename, but a libFOO.a(libFOO.so.N) - as just one example.
p.s. as far as ldconfig being part of the problem on AIX (as it does not exist and can lead to OSError or just long delays, I have worked out a (pending) patch for ctypes/util (and ctypes/cdll) that may address the issues with uuid import on AIX. (see issue26439 for the patch)
|
msg265109 - (view) |
Author: Martin Panter (martin.panter) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2016-05-08 03:24 |
The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My point about robustness is that if a version 2 is invented, it might have different semantics or function signatures, and Python would then be assuming the wrong semantics.
|
msg265122 - (view) |
Author: Christian Heimes (christian.heimes) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2016-05-08 10:34 |
It sounds like ctypes is causing you some headache. How about we get rid of ctypes for uuid and replace it with a simple implementation in C instead? Autoconf (configure) can take care of the library detection easily.
|
msg265126 - (view) |
Author: Martin Panter (martin.panter) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2016-05-08 10:58 |
There is already Issue 20519 for that, although it looks like the proposed patch keeps ctypes as a fall-back. (My interest here is only theoretical.)
|
msg265449 - (view) |
Author: Michael Felt (aixtools@gmail.com) |
Date: 2016-05-13 06:20 |
The way I have seen that resolved - in many locations, is to have the
option to specify a specific version, e.g., libFOO.so.1 and then as long
as that version remains available, perhaps as read-only for running with
existing programs,they continue to work even when libFOO.so.2. However,
for some who believes, or expects, to be able to deal with potential ABI
changes - they can specify simply libFOO.so and let the loader decide
(what I see is that libFOO.so is a symbolic link to, or a copy of the
latest version.)
So, I agree wholeheartedly, if a versioned number is requested, that, or
nothing, should be returned. However, if it is generic - try to find a
generic named library (and get the link or copy), and when that is not
available either, take the latest versioned number.
It has been over two months, and I may have read it wrong - but that
appears to be what the current "ldconfig -p" solution implements. (in
ctypes, not uuid, so perhaps this is not the correct place to be
responding. If so, my apologies).
On 08-May-16 05:24, Martin Panter wrote:
> Martin Panter added the comment:
>
> The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My point about robustness is that if a version 2 is invented, it might have different semantics or function signatures, and Python would then be assuming the wrong semantics.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11063>
> _______________________________________
|
msg303202 - (view) |
Author: Inada Naoki (methane) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 09:27 |
How often uuid1 is used?
I never use it and it looks uuid1 makes uuid.py complicated.
How about split it to _uuid1.py (or uuid/__init__.py and uuid/_uuid1.py)?
I hope PEP 562 is accepted.
It ease splitting out (heavy and slow and dirty) part into submodule without breaking backward compatibility.
Without PEP 562, easy way is making proxy function.
# uuid/__init__.py
def uuid1(node=None, clock_seq=None):
"""Generate a UUID from a host ID, sequence number, and the current time.
If 'node' is not given, getnode() is used to obtain the hardware
address. If 'clock_seq' is given, it is used as the sequence number;
otherwise a random 14-bit sequence number is chosen."""
from . import _uuid1
return _uuid1.uuid1()
|
msg303205 - (view) |
Author: Inada Naoki (methane) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 09:56 |
Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge.
|
msg303208 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:30 |
> It ease splitting out (heavy and slow and dirty) part into submodule without breaking backward compatibility.
Right. I created attached PR #3795 to implement this idea.
> I hope PEP 562 is accepted.
I don't think that this PEP is needed here. IMHO a new _uuid1 module is enoguh to avoid "side effects" on "import uuid".
> Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge.
Can you please elaborate? Do you think that my PR is wrong?
|
msg303209 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:40 |
uuid code contains 4 bare "except:" blocks which should be replaced with appropriate exceptions, or at least "except Exception:" to not catch KeyboardInterrupt. But this should be modified in a second time.
|
msg303210 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:41 |
I think https://github.com/python/cpython/pull/3796 is a better resolution. It creates an optional _uuid C extension to avoid ctypes if possible *and* also loads system functions lazily.
|
msg303211 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:43 |
> I think launching external tools like ifconfig and ipconfig can be avoided pretty easily. There are many recipes around the net how to use native API's.
That's right, but I would prefer to enhance uuid to use native API's in a different issue and focus on avoiding "side effects" on "import uuid" in this issue.
Do you know a native APIs for Windows and Linux? I don't. Do you have links to these "recipes"? If yes, please open a new issue.
|
msg303212 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:44 |
> Do you know a native APIs for Windows and Linux?
On Linux, we already use uuid_generate_time(). See _unixdll_get_node().
|
msg303213 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:44 |
And on Windows, _windll_getnode() calls into _UuidCreate().
|
msg303214 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:50 |
Antoine: "I think https://github.com/python/cpython/pull/3796 is a better resolution. It creates an optional _uuid C extension to avoid ctypes if possible *and* also loads system functions lazily."
Implementing bpo-20519 is a very good idea. But I still like the idea of putting all these ugly functions to get the node and geneate a UUID1 object in a different module, since most of these code is not used on most platforms.
Antoine: Would you mind to modify your PR 3796 to only implement bpo-20519? I would prefer to reorganize uuid.py in a second step. It will be easy to review and easy to discuss what is the best option.
|
msg303215 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 10:51 |
It's nice to see things moving in this 6 years old issue :-)
|
msg303218 - (view) |
Author: Inada Naoki (methane) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 11:13 |
>> Sorry, I reject my idea. It clearly overdone. uuid.py is not so huge.
> Can you please elaborate? Do you think that my PR is wrong?
I looked https://github.com/python/cpython/pull/3684 and
I wonder if I should recommend to split module before review.
So I meant "I stop requesting split module and I'll review the PR3684."
Now I see your PR and it looks more clean.
|
msg303220 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 11:20 |
> I would prefer to reorganize uuid.py in a second step
I am not reorganizing uuid.py, just making initialization lazy.
|
msg303228 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 13:21 |
Oh. I was told that the PR 3684 of bpo-5885 in another fix for this issue.
|
msg303230 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 13:27 |
PR 3684 seems mostly a subset of what I'm proposing.
|
msg303231 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 13:27 |
I marked bpo-5885 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension, as bpo-20519.
+static PyObject *
+uuid_uuid1(PyObject *self, PyObject *args)
+{
+ uuid_t out;
+ uuid_generate_time(out);
+ return PyByteArray_FromStringAndSize((const char *) out,sizeof(out));
+}
+static PyObject *
+uuid_uuid4(PyObject *self, PyObject *args)
+{
+ uuid_t out;
+ uuid_generate_random(out);
+ return PyByteArray_FromStringAndSize(out,sizeof(out));
+}
|
msg303234 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 13:29 |
I marked bpo-20519 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension:
+static PyObject *
+_uuid_generate_random(void)
+{
+ uuid_t out;
+ uuid_generate_random(out);
+ return PyBytes_FromStringAndSize((const char *) out, sizeof(out));
+}
+static PyObject *
+_uuid_generate_time(void)
+{
+ uuid_t out;
+ uuid_generate_time(out);
+ return PyBytes_FromStringAndSize((const char *) out, sizeof(out));
+}
|
msg303238 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 14:00 |
I abandonned my PR and started to review Antoine's PR 3796 which basically combines all previous patches proposed last 6 years :-)
|
msg303281 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 21:03 |
New changeset a106aec2ed6ba171838ca7e6ba43c4e722bbecd1 by Antoine Pitrou in branch 'master':
bpo-11063, bpo-20519: avoid ctypes and improve import time for uuid (#3796)
https://github.com/python/cpython/commit/a106aec2ed6ba171838ca7e6ba43c4e722bbecd1
|
msg303284 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 22:04 |
I ran two benchmarks on my Fedora 26.
* new = master (commit a106aec2ed6ba171838ca7e6ba43c4e722bbecd1)
* ref = commit 8d59aca4a953b097a9b02b0ecafef840e4ac5855
git co master
./python -m perf timeit -s 'import sys, uuid' "del sys.modules['uuid']; import uuid; uuid = None" --inherit=PYTHONPATH -v -o import_new.json
./python -m perf timeit -s 'import uuid; u=uuid.uuid1' "u()" --inherit=PYTHONPATH -v -o uuid1_new.json
git co 8d59aca4a953b097a9b02b0ecafef840e4ac5855
./python -m perf timeit -s 'import uuid; u=uuid.uuid1' "u()" --inherit=PYTHONPATH -v -o uuid1_ref.json
./python -m perf timeit -s 'import sys, uuid' "del sys.modules['uuid']; import uuid; uuid = None" --inherit=PYTHONPATH -v -o import_ref.json
Import:
haypo@selma$ ./python -m perf compare_to import_ref.json import_new.json --table
+-----------+------------+-----------------------------+
| Benchmark | import_ref | import_new |
+===========+============+=============================+
| timeit | 4.04 ms | 430 us: 9.39x faster (-89%) |
+-----------+------------+-----------------------------+
uuid.uuid1():
haypo@selma$ ./python -m perf compare_to uuid1_ref.json uuid1_new.json --table
+-----------+-----------+------------------------------+
| Benchmark | uuid1_ref | uuid1_new |
+===========+===========+==============================+
| timeit | 18.9 us | 15.2 us: 1.24x faster (-20%) |
+-----------+-----------+------------------------------+
Everything is faster. The import time is 9.4x faster, nice!
In practice, the import time is probably even better. My benchmark uses repeated import, it doesn't measure the "first time" import which was more expensive because of the "import ctypes".
|
msg303288 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-28 23:07 |
Crude import benchmark (Ubuntu):
* before:
$ time ./python -c "import uuid"
real 0m0.074s
user 0m0.056s
sys 0m0.012s
* after:
$ time ./python -c "import uuid"
real 0m0.030s
user 0m0.028s
sys 0m0.000s
* baseline:
$ time ./python -c pass
real 0m0.027s
user 0m0.024s
sys 0m0.000s
|
msg303365 - (view) |
Author: Łukasz Langa (lukasz.langa) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-29 22:33 |
uuid fails to build for me on master since that change landed:
cpython/Modules/_uuidmodule.c:13:11: error: implicit declaration of function 'uuid_generate_time_safe' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
res = uuid_generate_time_safe(out);
^
cpython/Modules/_uuidmodule.c:13:11: note: did you mean 'py_uuid_generate_time_safe'?
cpython/Modules/_uuidmodule.c:8:1: note: 'py_uuid_generate_time_safe' declared here
py_uuid_generate_time_safe(void)
^
cpython/Modules/_uuidmodule.c:13:11: warning: this function declaration is not a prototype [-Wstrict-prototypes]
res = uuid_generate_time_safe(out);
^
1 warning and 1 error generated.
This is on macOS Sierra.
|
msg303406 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-09-30 10:12 |
It's expected if uuid_generate_time_safe() isn't available on your platform. But test_uuid still passes?
|
msg303525 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 10:02 |
> It's expected if uuid_generate_time_safe() isn't available on your platform. But test_uuid still passes?
I would prefer to avoid compilation errors on a popular platforms like macOS. Would it possible to check if uuid_generate_time_safe() is available, maybe in configure? Or we can "simply" skip _uuid compilation on macOS?
|
msg303531 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 12:24 |
> Would it possible to check if uuid_generate_time_safe() is available, maybe in configure?
That's probably possible.
|
msg303532 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 12:31 |
Though I don't know how to reuse the find_file() logic in configure...
|
msg303533 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 13:15 |
> Though I don't know how to reuse the find_file() logic in configure...
Maybe we could use pkg-config instead?
haypo@selma$ pkg-config uuid --cflags
-I/usr/include/uuid
haypo@selma$ pkg-config uuid --libs
-luuid
|
msg303534 - (view) |
Author: Antoine Pitrou (pitrou) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 13:43 |
pkg-config is a Linux-ism. But Linux already works fine...
$ uname
Darwin
$ pkg-config
-bash: pkg-config: command not found
|
msg303539 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 14:49 |
I proposed PR 3855 to add macOS support to _uuid (and fix the compilation error).
|
msg303540 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 14:58 |
New changeset 4337a0d9955f0855ba38ef30feec3858d304abf0 by Victor Stinner in branch 'master':
bpo-11063: Fix _uuid module on macOS (#3855)
https://github.com/python/cpython/commit/4337a0d9955f0855ba38ef30feec3858d304abf0
|
msg303552 - (view) |
Author: Ned Deily (ned.deily) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 17:12 |
I agree with Barry's comment on PR 3855: "I'd rather see a configure check for the existence of uuid_generate_time_safe() rather than hard coding it to platforms !APPLE for two reasons. 1) If macOS ever adds this API in some future release, this ifndef will be incorrect, and 2) if some other platform comes along that doesn't have this API, it will still use the incorrect function." It's exactly for situations like this that autoconf tests exist; we should not be hardwiring assumptions about the lack of particular platform APIs.
|
msg303555 - (view) |
Author: Stefan Krah (skrah) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-10-02 17:41 |
I think the configure check should be this (sets HAVE_LIBUUID in pyconfig.h):
diff --git a/configure.ac b/configure.ac
index 41bd9effbf..90d53c1b7d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2657,6 +2657,7 @@ AC_MSG_RESULT($SHLIBS)
AC_CHECK_LIB(sendfile, sendfile)
AC_CHECK_LIB(dl, dlopen) # Dynamic linking for SunOS/Solaris and SYSV
AC_CHECK_LIB(dld, shl_load) # Dynamic linking for HP-UX
+AC_CHECK_LIB(uuid, uuid_generate_time_safe)
# only check for sem_init if thread support is requested
if test "$with_threads" = "yes" -o -z "$with_threads"; then
|
msg305587 - (view) |
Author: Berker Peksag (berker.peksag) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-05 08:12 |
I've followed Stefan's suggestion and opened PR 4287 (tested on 10.10.5)
|
msg305589 - (view) |
Author: Stefan Krah (skrah) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-05 10:25 |
Berker's latest patch looks good to me.
Unrelated to the patch (same before and after), this looks odd to me:
>>> import uuid
>>> uuid._has_uuid_generate_time_safe is None
True
>>>
>>> import _uuid
>>> _uuid.has_uuid_generate_time_safe
1
[Also, I thought we weren't supposed to use ctypes in the stdlib.]
|
msg305635 - (view) |
Author: STINNER Victor (vstinner) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-06 11:27 |
"""
Unrelated to the patch (same before and after), this looks odd to me:
>>> import uuid
>>> uuid._has_uuid_generate_time_safe is None
True
>>>
>>> import _uuid
>>> _uuid.has_uuid_generate_time_safe
1
"""
None means "not initialized yet". It's initialized on demand, at the first call of uuid1() or get_node():
$ python3
Python 3.7.0a2+ (heads/master:a5293b4ff2, Nov 6 2017, 12:22:04)
>>> import uuid
>>> uuid._has_uuid_generate_time_safe # == None
>>> uuid.uuid1()
UUID('3e5a7628-c2e5-11e7-adc1-3ca9f4650c0c')
>>> uuid._has_uuid_generate_time_safe
1
> [Also, I thought we weren't supposed to use ctypes in the stdlib.]
Antoine's commit a106aec2ed6ba171838ca7e6ba43c4e722bbecd1 avoids ctypes when libuuid is available.
For the other systems without libuuid, well, it was probably simpler to use ctypes. ctypes was more popular a few years ago. The code "just works" and I guess that nobody wants to touch it :-)
|
msg305897 - (view) |
Author: Berker Peksag (berker.peksag) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-08 20:09 |
New changeset 9a10ff4deb2494e22bc0dbea3e3a6f9e8354d995 by Berker Peksag in branch 'master':
bpo-11063: Add a configure check for uuid_generate_time_safe (GH-4287)
https://github.com/python/cpython/commit/9a10ff4deb2494e22bc0dbea3e3a6f9e8354d995
|
msg305900 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-08 20:28 |
Does this check work? I tried similar checks with other functions and they were falsely passed because calling an undeclared function is not an error in C.
The reliable check of the existence of the uuid_generate_time_safe function is:
void *x = uuid_generate_time_safe
|
msg305904 - (view) |
Author: Stefan Krah (skrah) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-08 20:48 |
On Wed, Nov 08, 2017 at 08:28:10PM +0000, Serhiy Storchaka wrote:
> Does this check work? I tried similar checks with other functions and they were falsely passed because calling an undeclared function is not an error in C.
Not here. If I replace uuid_generate_time_safe with a non-existing function
name, it is still found:
checking for uuid_generate_time_unsafe... yes
The originally suggested AC_CHECK_LIB macro however works here in both cases. :)
|
msg305909 - (view) |
Author: Berker Peksag (berker.peksag) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-08 21:22 |
It worked for me on OS X (returns no) and Linux (returns yes after I installed uuid-dev) but I didn't test it on both systems at the same. Travis CI also returned 'no': https://travis-ci.org/python/cpython/jobs/299285001
In any case, Serhiy's suggestion is better than mine so I've opened PR 4343.
And yes, I'm beginning to regret my decision on not using AC_CHECK_LIB :)
|
msg305911 - (view) |
Author: Berker Peksag (berker.peksag) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-08 21:43 |
New changeset 0e163d2ced28ade8ff526e8c663faf03c2c0b168 by Berker Peksag in branch 'master':
bpo-11063: Use more reliable way to check if uuid function exists (GH-4343)
https://github.com/python/cpython/commit/0e163d2ced28ade8ff526e8c663faf03c2c0b168
|
msg306984 - (view) |
Author: Nick Coghlan (ncoghlan) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-26 02:50 |
The header file check in setup.py incorrectly reported "not found" if `uuid.h` was in one of the standard include directories, so I've submitted a tweak to fix that: https://github.com/python/cpython/pull/4565
|
msg306985 - (view) |
Author: Nick Coghlan (ncoghlan) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2017-11-26 03:04 |
New changeset 53efbf3977a44e382397e7994a2524b4f8c9d053 by Nick Coghlan in branch 'master':
bpo-11063: Handle uuid.h being in default include path (GH-4565)
https://github.com/python/cpython/commit/53efbf3977a44e382397e7994a2524b4f8c9d053
|
|
Date |
User |
Action |
Args |
2022-04-11 14:57:12 | admin | set | github: 55272 |
2017-11-26 03:04:48 | ncoghlan | set | messages:
+ msg306985 |
2017-11-26 02:50:35 | ncoghlan | set | nosy:
+ ncoghlan messages:
+ msg306984
|
2017-11-26 02:48:49 | ncoghlan | set | pull_requests:
+ pull_request4493 |
2017-11-08 21:43:16 | berker.peksag | set | messages:
+ msg305911 |
2017-11-08 21:22:51 | berker.peksag | set | messages:
+ msg305909 |
2017-11-08 21:18:05 | berker.peksag | set | pull_requests:
+ pull_request4301 |
2017-11-08 20:48:16 | skrah | set | messages:
+ msg305904 |
2017-11-08 20:28:10 | serhiy.storchaka | set | messages:
+ msg305900 |
2017-11-08 20:10:08 | berker.peksag | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
2017-11-08 20:09:22 | berker.peksag | set | messages:
+ msg305897 |
2017-11-06 11:27:44 | vstinner | set | messages:
+ msg305635 |
2017-11-05 10:25:08 | skrah | set | messages:
+ msg305589 |
2017-11-05 08:12:48 | berker.peksag | set | nosy:
+ berker.peksag messages:
+ msg305587
|
2017-11-05 08:09:46 | berker.peksag | set | pull_requests:
+ pull_request4250 |
2017-10-02 17:41:28 | skrah | set | nosy:
+ skrah messages:
+ msg303555
|
2017-10-02 17:12:09 | ned.deily | set | nosy:
+ ned.deily messages:
+ msg303552
|
2017-10-02 14:58:02 | vstinner | set | messages:
+ msg303540 |
2017-10-02 14:49:48 | vstinner | set | messages:
+ msg303539 |
2017-10-02 14:04:22 | vstinner | set | stage: resolved -> patch review pull_requests:
+ pull_request3835 |
2017-10-02 13:43:28 | pitrou | set | messages:
+ msg303534 |
2017-10-02 13:15:23 | vstinner | set | messages:
+ msg303533 |
2017-10-02 12:31:15 | pitrou | set | messages:
+ msg303532 |
2017-10-02 12:24:19 | pitrou | set | messages:
+ msg303531 |
2017-10-02 10:02:07 | vstinner | set | status: closed -> open resolution: fixed -> (no value) messages:
+ msg303525
|
2017-09-30 10:12:14 | pitrou | set | messages:
+ msg303406 |
2017-09-29 22:33:20 | lukasz.langa | set | nosy:
+ lukasz.langa messages:
+ msg303365
|
2017-09-28 23:07:57 | pitrou | set | messages:
+ msg303288 |
2017-09-28 22:04:49 | vstinner | set | messages:
+ msg303284 |
2017-09-28 21:03:32 | pitrou | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
2017-09-28 21:03:08 | pitrou | set | messages:
+ msg303281 |
2017-09-28 14:00:53 | vstinner | set | messages:
+ msg303238 |
2017-09-28 13:45:33 | vstinner | set | pull_requests:
+ pull_request3784 |
2017-09-28 13:30:21 | vstinner | set | title: uuid.py module import has heavy side effects -> Rework uuid module: lazy initialization and add a new C extension |
2017-09-28 13:29:56 | vstinner | set | messages:
+ msg303234 |
2017-09-28 13:29:10 | vstinner | link | issue20519 superseder |
2017-09-28 13:27:49 | vstinner | set | messages:
+ msg303231 |
2017-09-28 13:27:12 | pitrou | set | messages:
+ msg303230 |
2017-09-28 13:26:05 | vstinner | link | issue5885 superseder |
2017-09-28 13:21:36 | vstinner | set | messages:
+ msg303228 |
2017-09-28 11:20:02 | pitrou | set | messages:
+ msg303220 |
2017-09-28 11:13:20 | methane | set | messages:
+ msg303218 |
2017-09-28 10:51:10 | vstinner | set | messages:
+ msg303215 |
2017-09-28 10:50:48 | vstinner | set | messages:
+ msg303214 |
2017-09-28 10:44:50 | pitrou | set | messages:
+ msg303213 |
2017-09-28 10:44:08 | pitrou | set | messages:
+ msg303212 |
2017-09-28 10:43:06 | vstinner | set | messages:
+ msg303211 |
2017-09-28 10:41:40 | pitrou | set | messages:
+ msg303210 versions:
- Python 3.8 |
2017-09-28 10:40:49 | vstinner | set | messages:
+ msg303209 |
2017-09-28 10:37:56 | pitrou | set | pull_requests:
+ pull_request3780 |
2017-09-28 10:30:42 | vstinner | set | nosy:
+ vstinner messages:
+ msg303208
|
2017-09-28 10:21:33 | vstinner | set | pull_requests:
+ pull_request3779 |
2017-09-28 09:58:48 | christian.heimes | set | versions:
+ Python 3.7, Python 3.8, - Python 3.5 |
2017-09-28 09:56:47 | methane | set | messages:
+ msg303205 versions:
+ Python 3.5, - Python 3.7 |
2017-09-28 09:35:26 | pitrou | set | versions:
+ Python 3.7, - Python 3.5 |
2017-09-28 09:27:25 | methane | set | nosy:
+ methane messages:
+ msg303202
|
2016-05-13 06:20:46 | aixtools@gmail.com | set | nosy:
+ aixtools@gmail.com messages:
+ msg265449
|
2016-05-08 10:58:37 | martin.panter | set | messages:
+ msg265126 |
2016-05-08 10:34:40 | christian.heimes | set | messages:
+ msg265122 |
2016-05-08 03:24:54 | martin.panter | set | messages:
+ msg265109 |
2016-05-06 17:10:37 | Michael.Felt | set | nosy:
+ Michael.Felt messages:
+ msg264998
|
2016-04-25 03:51:23 | martin.panter | set | nosy:
+ martin.panter messages:
+ msg264151
|
2014-10-04 23:44:23 | pitrou | set | nosy:
+ serhiy.storchaka stage: needs patch -> patch review
versions:
+ Python 3.5, - Python 3.4 |
2013-02-24 13:17:12 | nailor | set | files:
+ issue11063_2.patch
messages:
+ msg182875 |
2013-02-24 13:16:36 | nailor | set | files:
- issue11063_2.patch |
2013-02-24 12:40:24 | hynek | set | messages:
+ msg182873 |
2013-02-23 17:38:33 | nailor | set | files:
+ issue11063_2.patch nosy:
+ nailor messages:
+ msg182778
|
2012-12-27 12:31:04 | christian.heimes | set | nosy:
+ christian.heimes messages:
+ msg178297
|
2012-12-27 10:47:49 | hynek | set | versions:
+ Python 3.4, - Python 2.7, Python 3.2, Python 3.3 nosy:
+ hynek
messages:
+ msg178293
stage: patch review -> needs patch |
2011-02-05 19:42:46 | pitrou | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128021 |
2011-02-05 19:41:24 | kdart | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128020 |
2011-02-05 19:31:36 | knny-myer | set | files:
- unnamed nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart |
2011-02-05 19:27:39 | nvetoshkin | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128019 |
2011-02-05 19:23:22 | kdart | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128018 |
2011-02-05 19:17:42 | pitrou | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128017 |
2011-02-05 19:14:59 | nvetoshkin | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128016 |
2011-02-05 19:14:39 | knny-myer | set | files:
+ unnamed
messages:
+ msg128015 nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart |
2011-02-05 19:04:58 | pitrou | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128013 |
2011-02-05 19:01:56 | nvetoshkin | set | nosy:
orsenthil, kdart, pitrou, eric.araujo, Arfrever, r.david.murray, nvetoshkin, knny-myer, Keith.Dart messages:
+ msg128012 |
2011-02-05 18:44:32 | pitrou | set | nosy:
+ pitrou
messages:
+ msg128010 stage: needs patch -> patch review |
2011-02-05 18:30:55 | r.david.murray | set | nosy:
+ r.david.murray messages:
+ msg128008
|
2011-02-05 17:10:36 | orsenthil | set | nosy:
+ orsenthil messages:
+ msg128001
|
2011-02-05 15:55:51 | knny-myer | set | files:
+ issue11063.patch
nosy:
+ knny-myer messages:
+ msg127998
keywords:
+ patch |
2011-02-05 14:05:25 | nvetoshkin | set | nosy:
+ nvetoshkin messages:
+ msg127989
|
2011-02-04 19:38:20 | eric.araujo | set | nosy:
+ eric.araujo
|
2011-01-29 23:26:59 | pitrou | set | keywords:
+ easy nosy:
kdart, Arfrever, Keith.Dart stage: needs patch versions:
+ Python 3.2, Python 3.3 |
2011-01-29 18:31:53 | Keith.Dart | set | nosy:
+ kdart
|
2011-01-29 17:53:07 | Arfrever | set | nosy:
+ Arfrever
|
2011-01-29 17:10:59 | Keith.Dart | create | |