[Python-Dev] Re: test_ssl.py hangs with SSL 1.1 built with no threads
On 27/04/2020 19.27, mig28sua...@hotmail.com wrote:
> Hello!
>
> This is my first time posting to the group.
>
> I've been running builds of Python 3.7.x on CentOS Linux release 7.7
> (64bit/Intel Core 2 Duo)
> and I ran into hangs with test_ssl.py when using latest SSL 1.1.1d sources.
>
> I've done a full compilation from source for Python 3.7.7 and SSL 1.1 in my
> workspaces.
>
> From what I can tell the problem is when SSL 1.1 is built with no threading
> there is no locking enabled by python.
>
> This one line change will make the hangs in test_ssl.py go away:
>
> Index: Modules/_ssl.c
> ===
> --- Modules/_ssl.c (revision 70)
> +++ Modules/_ssl.c (working copy)
> @@ -5875,7 +5875,7 @@
> if (!_setup_ssl_threads()) {
> return NULL;
> }
> -#elif OPENSSL_VERSION_1_1 && defined(OPENSSL_THREADS)
> +#elif OPENSSL_VERSION_1_1
> /* OpenSSL 1.1.0 builtin thread support is enabled */
> _ssl_locks_count++;
> #endif
>
>
> There appears to be an assumption in _ssl.c and test_ssl.y that SSL 1.1 will
> be threaded
> but this may not be true (as in my case).
Python requires a thread-safe OpenSSL build. I have pushed PR
https://github.com/python/cpython/pull/19953 to 3.7, 3.8, and master.
The hashlib and ssl module will now fail when OpenSSL is not thread-safe.
Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ZEKUSVZVCGPXEZJCLRQ2FPNYQ5O7KHCM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Voting conventions [was: PEP 618: Add Optional Length-Checking To zip]
These negative votes surprise me.
Given that it's clear that a generic strict-mode zip is non-trivial to
write, and that there is significant demand for it, are people saying
"+0 Python would not be a better programming environment if
itertools.zip_strict() were adopted," and "-1 Python would be a worse
programming environment if zip.strict() were adopted"?
I can see why folks would say the latter about zip.strict(), but even
though I really dislike the mode switches, I'm still positive about
adding them if one of them ranks highest among those who care. I'm
not going to give them negative votes, they don't make Python worse.
I don't mind hyperbole ("I'm +1000 on this feature!" or "-10 on the
worst proposal I've seen since !") But I would like it if "0" meant "indifferent", "+1"
meant "no-brainer, add it", and "-1" meant "no-brainer, just don't".
FWIW,
+1 itertools.zip_strict(*iterables)
+0.5 zip(*iterables, mode)# mode is 3-way, default "shortest"
+0.4 zip(*iterables, strict) # strict is boolean, default False
+0 zip.strict(*iterables)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DLHIE5DOI5G3IH7OEK7RDW2K37DEQ7VB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
Gregory P. Smith writes: > Agreed. The best way to reduce accidental incorrect use of the > builtin is to make the builtin capable of doing what a people want > directly without having to go discover something in a module > somewhere. Executive summary: My argument (and one of Steven d'Aprano's) against a "strict" mode to zip is precisely that it's *extremely* likely that if I use a facility that zips together things I provide, the last thing I want it is for it to choose "strict" for me, because that *would likely be incorrect*. I do not want people using strict *for any facility I might use* "because it's there." I'm not saying strict mode is useless. I am saying the "encourage use by making it easier to use" argument cuts both ways: it can create problems as well as solve them. A couple of concrete examples: 1. In activities like constructing data arrays, which we expect to be rectangular, I'm still likely to use sequences of unequal length, including infinite sequences. As an economist, I often use lagged data, which can easily be constructed for an equation like y[t] = a + b x[t] + c x[t-1] with zip(y[1:], const(), x[1:], x[0:]) where def const(): while True: yield 1 (Here I'm using zip() as a proxy for somebody's generic facility such as a function to compute OLS estimates given a sequence of data series. Obviously for zip itself, I would just not use strict mode.) Note that y[0], not y[-1], needs to be left out. This is the critical point that I need to concentrate on when constructing this data frame. If I have to "even out" the columns, though, I need *also* to think about the lengths, a distraction which for me makes this more bug-prone. Ie, I might accidentally write zip(y[:-1], const(len(x) - 1), x[:-1], x[1:]) where def const(n): return (1 for _ in range(n)) which is not only asymmetric but wrong, as the regressor x[1:] is "future x"! More opportunities for bugs arise in the replacement for const(). Even if you don't agree about the bugs (and there is a weak argument that some fraction of the potential bugs will be caught by strict-mode zip, such as a wrong argument to const()), it's pretty clear which style is more readable. 2. My programming style is such that if I want couples that are related to each other, I will almost certainly generate those couples, not generate them separately in the right orders and then zip as needed. For example, in one of the test suites two lists are generated something like this: c_int_types = [...]# list display c_int_type_ranges = [construct_range(t) for t in c_int_types] and in many tests the two lists are zipped to produce appropriately matched couple. But I would certainly do c_int_types = [...]# as above c_int_types_with_ranges = [(t, construct_range(t)) for t in c_int_types] Of course I understand that sometimes you might very well care about the space cost of doing this, but I suspect that if I cared about the 2X cost of c_int_types_with_ranges, I wouldn't pregenerate a list of ranges at all. My point is that given my style, this particular use case will *almost never* occur, so is unlikely to provide an excuse for strict mode if I'm providing the data. I suspect this applies to a lot of claimed use cases. Of course if I only provide c_int_types, and your function constructs c_int_type_ranges and zips them, it's fine if you use strict mode -- that doesn't impact me at all. You probably *should* use strict mode. But if you claim to be providing a general facility, I think it's on you to think about whether I might want to feed sequences of unequal length to the function, even though you never would. That's quite a burden to assume, though, unless you simply provide a strict mode flag in your functions (which you can default to strict!) and let me choose. Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BT4PFQVPHERDJCGDUD5RZDLFYWPIP6DH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Voting conventions [was: PEP 618: Add Optional Length-Checking To zip]
I used the same convention as you, and my vote was thus as the record will
show (note the negatives):
zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1
And I stand by that: I think Python would be better off without the 3rd and
4th option, even if no alternative was implemented. To go to one of the
examples (not exactly, you'll understand why...) was given in the other
thread: if we suggested
asdfasfa.kjllasdfa.asdf()
as the name(space) for the zip(strict=True) functionality, I would:
- vote -1 (or hyperbole -10^googol)
- still use the feature when I wanted to use 'zip(strict=True)'
- think Python would be a worse programming environment for allowing this
to be introduced
Obviously the 3rd and 4th option are not as insane/illogical as the above
example (apologies, I would attribute, but the nature of this example makes
it hard for me to search for it!) but I do not like functionality exposed
in this way and I think the lack of this functionality in the stdlib does
not weigh up against the precedent/bad example this would set.
You, and anyone else, can and some definitely will disagree with me but
it's my vote, and I don't think it matters that much anyway:
There has been a lot of discussion, and these straw polls, from my limited
understanding, are often taken to see whether there is a clear consensus to
short-circuit/end the discussion, I would say in this case it has shown
inconclusiveness, which is fine, the final decision on this PEP will
(fortunately) not be decided by our votes.
I understand your 'pain' Stephen: I still think it is weird that people on
these lists don't want "for x in some_iterable if x is not None:" as valid
syntax, but I have, almost, made my peace with it.
On Sun, 17 May 2020 at 18:42, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> These negative votes surprise me.
>
> Given that it's clear that a generic strict-mode zip is non-trivial to
> write, and that there is significant demand for it, are people saying
> "+0 Python would not be a better programming environment if
> itertools.zip_strict() were adopted," and "-1 Python would be a worse
> programming environment if zip.strict() were adopted"?
>
> I can see why folks would say the latter about zip.strict(), but even
> though I really dislike the mode switches, I'm still positive about
> adding them if one of them ranks highest among those who care. I'm
> not going to give them negative votes, they don't make Python worse.
>
> I don't mind hyperbole ("I'm +1000 on this feature!" or "-10 on the
> worst proposal I've seen since removed>!") But I would like it if "0" meant "indifferent", "+1"
> meant "no-brainer, add it", and "-1" meant "no-brainer, just don't".
>
>
> FWIW,
>
> +1 itertools.zip_strict(*iterables)
> +0.5 zip(*iterables, mode)# mode is 3-way, default
> "shortest"
> +0.4 zip(*iterables, strict) # strict is boolean, default
> False
> +0 zip.strict(*iterables)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DLHIE5DOI5G3IH7OEK7RDW2K37DEQ7VB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/IXCPI6VHT3DLQKESDJ5KAV372J4PE7ZW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Best API to preserve mode/time/owner of extracted files with ZipFile
Hi! tldr; I'm interested in having ZipFile's extract() method inverse to add() where possible. I'm not sure about which API would be best to choose. Firstly some context Zip files created by ZipFile (from zipfile module) already store last modification time and date and unix file mode of files. When files are extracted, files and directories are always created with default permissions and no other state of files is restored. Permission behavior is not documented yet [1] and an enhancement request exists for some time [2]. There have been couple of questions on StackOverflow [3], [4], [5] with various level of robustness. There is even a pull request [6] but it changes current behavior. What others do? Info-Zip's unzip[7] by default restores only "safe" permissions - SUID/SGID/Sticky bits are cleared out. Unless explicitly requested with -K option. Permissions of stored directories are not restored except under Unix. PKZIP's PKZIP[8] allows specification of a mask: [...] mask for files to be added or extracted. The mask specifies permissions which should not be archived or restored on extraction. [...] The setuid, setgid, and sticky bits are set on extracted files only if the permission option is used. And in non-zip world - GNU tar preserves permissions when -p is specified (default for superuser). Python's tarfile - extractall() always preserves ownership, date, time and permissions. Method extract() by default preserves the same but has attribute set_attr to skip all of those. Finally about ZipFile's interface enhancement I *guess* it might not be good idea to change behaviour there was for couple of releases/years now [9]. In zip world SUID/SGID/Sticky bits seems to treated specially so I guess it might be good idea to stick with that instead of imitating python's tar. Patch [10] attached to one of the issue uses various constants. Is this a good, pythonic, interface? I'm rather thinking of adding new attributes to ZipFile class, extract() and extractall() methods: - set_mode = False (sets only regular modes) - set_special_mode = False (sets only special permissions) and later to be extended with: - set_timestamp = False (sets modified time) - set_owner = False (sets owner and group) Pavol -- [1] https://bugs.python.org/issue18262 [2] https://bugs.python.org/issue15795 [3] https://stackoverflow.com/q/434641/83400 [4] https://stackoverflow.com/q/3007233/83400 [5] https://stackoverflow.com/q/42326428/83400 [6] https://github.com/python/cpython/pull/17790 [7] See man unzip(1) [8] https://support.pkware.com/home/pkzip/pkzip-securezip-for-unix-linux/pkzip_securezip-for-unix_linux-users-guide/adding-files-to-an-archive-in-unix [9] https://www.python.org/dev/peps/pep-0387/ [10] https://bugs.python.org/file34893/issue15795_test_and_doc_fixes.patch ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TVAGGJGADBYBUJOCRU3ZLI555POY4VUA/ Code of Conduct: http://python.org/psf/codeofconduct/
