[issue22444] Floor divide should return int
Raymond Hettinger added the comment: I think you're misreading the PEP. Floor division is defined to return a value *equal* to floor(x/y) but the type is unrestricted. That let's us correctly implement floor division for a variety of types including ints, floats, decimals, and fractions. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22443] read(1) blocks on unflushed output
eryksun added the comment: unbuffer works for me. It fakes a tty, so apt-get doesn't automatically enter quiet mode. import io import subprocess args = ['unbuffer', 'apt-get', 'download', 'firefox'] p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) out = io.TextIOWrapper(p.stdout, newline='') while True: c = out.read(1) if c == '': break print(c, end='', flush=True) p.wait() unbuffer isn't required if you disable quiet mode as follows: args = ['apt-get', '-q=0', 'download', 'firefox'] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22443 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg227146 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22442] subprocess.check_call hangs on large PIPEd data.
juj added the comment: Very good question akira. In one codebase where I have fixed this kind of bug, see https://github.com/kripken/emscripten/commit/1b2badd84bc6f54a3125a494fa38a51f9dbb5877 https://github.com/kripken/emscripten/commit/2f048a4e452f5bacdb8fa31481c55487fd64d92a the intended usage by the original author had certainly been to throw in a PIPE just to mute both stdout and stderr output, and there was no intent to capture the results or anything. I think passing PIPE to those is meaningless, since they effectively behave as throw the results away, since they are not returned. Throwing an exception might be nice, but perhaps that would break existing codebases and therefore is not good to add(?). Therefore I think the best course of action would be to do what is behaviorally as developer intends: please treat as if stdout and stderr had been captured to a pipe, and throw those pipes away, since they aren't returned., so your third option, while inconsistent with direct Popen(), sounds most correct in practice. What do you think? I am not currently aware of other such cases, although it would be useful to go through the docs and recheck the commit history of when that documentation note was added in to see if there was more related discussions that occurred. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22442 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Antoine Pitrou added the comment: Is this change compelling enough to break compatibility, or is it just a matter of purity? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22449] SSLContext.load_verify_locations behavior on Windows and OSX
New submission from Christian Heimes: The behavior of SSLContext.load_verify_locations is rather inconsistent across platforms: On most POSIX platforms (Linux, BSD, non-Apple builds of OpenSSL) it loads certificates from predefined locations. The locations are defined during compile time and usually differ between vendors and platforms. My WiP Improve TLS/SSL support PEP lists all common locations and the packages that offer the certs. On these platforms SSL_CERT_DIR and SSL_CERT_FILE overwrite the location. On Windows SSL_CERT_DIR and SSL_CERT_FILE are never taken into account by SSLContext.load_verify_locations because it doesn't call SSLContext.set_default_verify_paths(). The attached patch is a semi-fix for the problem. With the patch certs from SSL_CERT_DIR and SSL_CERT_FILE are only *added* to trusted root CA certs. The certs from Windows' cert store 'CA' and 'ROOT' are still loaded. On OSX with Apple's custom build of OpenSSL SSL_CERT_DIR and SSL_CERT_FILE take effect. But there is a twist! In case a root CA cert is not found Apple's Trust Evaluation Agent (TEA) kicks in and looks up certs from Apple's keychain. It's almost the same situation as on Windows but more magical. In order to disable TEA one has to set the env var OPENSSL_X509_TEA_DISABLE=1 *before* the first cert is validated. After that the env var has no effect as the value is cached. Hynek has documted it in his blog: https://hynek.me/articles/apple-openssl-verification-surprises/ -- components: Extension Modules, Library (Lib) files: win32_load_SSL_CERT_env.patch keywords: patch messages: 227150 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, hynek, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: SSLContext.load_verify_locations behavior on Windows and OSX type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36668/win32_load_SSL_CERT_env.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22449 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Stefan Krah added the comment: Perhaps it's worth mentioning that several people on Python-ideas took the opposite view: math.floor() should return a float. PEP-3141 does not mention Infinities and NaNs: The Real ABC indicates that the value is on the real line, and supports the operations of the float builtin. Real numbers are totally ordered except for NaNs (which this PEP basically ignores). Floats, however, are on the extended real number line, so we have a problem. :) Other languages === The PEP says that inspiration came from Scheme and Haskell. However, Scheme returns floats: --- https://mail.python.org/pipermail/python-ideas/2014-September/029432.html Haskell seems to return the highest representable integer: -- Prelude floor (1/0) 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 However, Haskell float support looks sketchy: - Prelude floor (0/0) -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 Prelude let x = 1 / 0 Prelude x Infinity Prelude x / 0 Infinity Considering the last two examples, I think Haskell should not provide any guidance here. ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Stefan Krah added the comment: Argh, forget the second Haskell example: inf / 0 is fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22445] Memoryviews require more strict contiguous checks then necessary
Stefan Krah added the comment: Ok, so it is a debug thing in the current NumPy sources. IMO ultimately the getbufferproc needs to return valid strides, even if the first value isn't used. For that matter, the getbufferproc is free to translate the multi- dimensional corner case array to a one-dimensional array that is automatically C and F-contiguous. Does it matter if you lose some (irrelevant?) information about the original array structure? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature
Ned Deily added the comment: After a fair amount of research, trial-and-error, and testing on all of the OS X platforms we support, I think we're now ready to switch to signed flat packages for the OS X installers and thereby greatly improve the user installation experience on current systems. I've found that it *is* possible to produce signed installers that work as expected on the same set of o/s releases and platforms as the current legacy installers (i386/ppc for 10.5+ and x86_64/i386 for 10.6+), with the same set of user installation options, although there were a number of gotchas along the way. One unexpected issue was that our Python frameworks are not immutable - since they include install paths such as the site-packages and scripts directories - and the current Apple packaging tools aren't designed to support a configuration like that. On newer releases where codesigning is fully supported, the installer wants to treat framework bundles as atomic elements which, I discovered, can result in the user' s site-installed packages being deleted during an maintenance release upgrade. I was able to work around that in a way that works across all supported releases but it does point out that we should consider modifying our framework deployments to move to read-only bundles if possible. We produce the two installer variants by running build-installer.py on two different OS X systems (10.5 and 10.6) and then move the resultant bundle installers encapsulated in OS X disk image files (.dmg) to a third current (10.9) system for pgp signing, archiving, and uploading. The new process, beginning with the upcoming 3.4.2, remains the same except that the build artifacts from the two builds are now post-processed on the 10.9 system using the current Apple packaging tools to produce the flat package installer files and to do the Gatekeeper signings. For 3.4.2rc1, the configuration files for the packaging tools have been manually generated. The next step, probably post-3.4.2, will be for build-installer.py to auto-generate the config files. Another advantage of flat-format installers is that they are a compressed single file and don't need to be wrapped in another container like the legacy bundle installers do. So, starting with 3.4.2, the installer file (.pkg) will be downloaded directly rather than within a .dmg file. This simplifies the user installation process: double-clicking on the downloaded .pkg file will start the installer directly rather than having to click on the downloaded dmg, waiting for it to mount, double-clicking on the installer file in the window that opens, and remembering to dismount the volume when the install is complete. And, in some browser configurations, the installer will be launched automatically, although in all cases, user action is still required to complete the install. One possible downside to eliminating the dmg (or similar) container is that there will no longer be a redundant readme file outside of the installer. The installer presents the package's welcome, readme, and licens e files and the opportunity for the user to save and/or print each, but previously we also made a copy of the readme file available in the dmg directory next to the installer file. The primary case where that could be useful is if the user cannot launch the installer for some reason and the readme provides a workaround. But that unusual case is the one we are fixing by moving to signed packages. Not surprisingly, many users do not read readmes anyway: the previous readme files did include instructions on how to workaround the Gatekeeper issue yet many users still had problems. In the unlikely event that a similar problem arises, we still have the option to revert to a zip or a dmg if just providing info on the python.org download pages proves insufficient. To address the points in the original issue: (1) I think the risk has been minimized as there are no changes to the actual installer builds and the user experience in the installer is virtually unchanged; what we have changed is removing obstacles to getting to the installer. (2) While I still think in the long run it would be best to have a PSF-owned Apple developer company account for signing (and I still intend to pursue that with the board at some point after coming up with a concrete proposal), I don't think it is a particularly pressing issue. Initially, the installers are being signed with my personal developer id, just as other release files are signed by the personal pgp keys of the release team members who produce them. Unlike the Windows installer, the OS X installer does not display information about the signing key unsolicited other than an indication that one is present if you know where to look. There's a small icon indicating a signed installer in the upper-right corner of the installer window; clicking it causes the certificate info to be displayed.
[issue22445] Memoryviews require more strict contiguous checks then necessary
Sebastian Berg added the comment: An extra dimension is certainly not irrelevant! The strides *are* valid and numpy currently actually commonly creates such arrays when slicing. The question is whether or not we want to ignore them for contiguity checks even if they have no effect on the memory layout. So there are three options I currently see: 1. Python also generalizes like I would like numpy to end up in the future (the current patch should do that) and just don't care about such strides, because the actual memory layout is what matters. 2. We say it is either too dangerous (which may very well be) or you want to preserve Fortran/C-order information even when it does not matter to the memory layout. This leads to this maybe: 2a) we just keep it as it is and live with minor inconsistencies (or never do the relaxed strides in numpy) 2b) We let these buffers return False on checking for contiguity but *allow* allow fetching a buffer when C-/F-contiguous is explicitly asked for when getting the buffer. Which is a weird middle way, but it might actually be a pretty sane solution (have to think about it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Alexander Belopolsky added the comment: Is this change compelling enough to break compatibility, or is it just a matter of purity? According to the PEP 3141, Integer is a subtype of Real, so one should be able to substitute an Integer whenever Real is expected. The reverse is not true, for example [1,2][1.0] Traceback (most recent call last): File stdin, line 1, in module TypeError: list indices must be integers, not float This is one of the common uses of floor division - to find an index of a cell in a regular grid: (x - start) // step. In this situation, it is convenient to have the result ready to be used as an index without a cast. The substitution principle also suggests that compatibility issues are likely to be small: in most contexts integers behave the same as floats or better. Here is an example of a better behavior: x = 1 + 10**50 x * 1 == x True x * 1.0 == x False The only case I can think of where float result may be preferable is inf // 1 because integers cannot represent infinity. However, this case is arguably already broken. What are the use-cases for float // float where integer result is not acceptable? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Joshua Moore-Oliva added the comment: You can contribute upstream to the Tulip project first. Will I be writing a patch and tests for tulip, and then separate a patch and tests for python 3.4? Or will I submit to tulip, and then the changes will get merged from tulip into python by some other process? If possible, I would like to get this into python 3.4.2 (assuming all goes well). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Alexander Belopolsky added the comment: However, Scheme returns floats Does Scheme's default integer type support arbitrarily large values? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment: Does Scheme's default integer type support arbitrarily large values? Yes, at least is does on the version I tested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Guido van Rossum added the comment: We can merge the changes into 3.4 and 3.5 for you, it's just a simple copy (the codebases are identical). However, the 3.4.2 release candidate is apparently in 2 days, so I think you've missed that train already. On Sat, Sep 20, 2014 at 9:02 AM, Joshua Moore-Oliva rep...@bugs.python.org wrote: Joshua Moore-Oliva added the comment: You can contribute upstream to the Tulip project first. Will I be writing a patch and tests for tulip, and then separate a patch and tests for python 3.4? Or will I submit to tulip, and then the changes will get merged from tulip into python by some other process? If possible, I would like to get this into python 3.4.2 (assuming all goes well). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Alexander Belopolsky added the comment:
Perhaps it's worth mentioning that several people on Python-ideas
took the opposite view: math.floor() should return a float.
I sympathize with the idea that math module functions should return floats. I
find it unfortunate that math.floor delegates to the __floor__ dunder on
non-floats instead of doing math.floor(x.__float__()). It would be more
natural to have a floor builtin that *always* delegates to __floor__ and keep
math a pure float library.
Note that math module provides the means to compute C-style floor:
x = float('inf')
math.modf(x)[1]
inf
x = -3.4
math.modf(x)[1]
-3.0
Maybe we should add floorf, ceilf, etc. as well. This, however, is a different
issue from the one at hand here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
What are the use-cases for float // float where integer result is not
acceptable?
It can lead to unexpected memory consumption when dealing with
arbitrary precision values. What should Decimal('1e123456')//1 return?
The result is exactly equal to Decimal('1e123456') but the
corresponding Python integer will consume ~55KB of RAM.
I'm also concerned that returning a very large integer will lead users
to assume that the result is more precise than it really is. Assuming
standard 64-bit double format, only the first 53 bits are significant.
All the remaining bits are 0.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Alexander Belopolsky added the comment:
What should Decimal('1e123456')//1 return?
I think Decimal case should be considered separately. Note that unlike float,
they are not part of the numerical tower, so PEP 3141 arguments don't apply:
isinstance(1.0, numbers.Real)
True
isinstance(decimal.Decimal(1), numbers.Real)
False
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
On Sat, Sep 20, 2014 at 9:38 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
Alexander Belopolsky added the comment:
Perhaps it's worth mentioning that several people on Python-ideas
took the opposite view: math.floor() should return a float.
I sympathize with the idea that math module functions should return floats.
I find it unfortunate that math.floor delegates to the __floor__ dunder on
non-floats instead of doing math.floor(x.__float__()). It would be more
natural to have a floor builtin that *always* delegates to __floor__ and keep
math a pure float library.
+1
Note that math module provides the means to compute C-style floor:
x = float('inf')
math.modf(x)[1]
inf
x = -3.4
math.modf(x)[1]
-3.0
That's not immediately obvious...
Maybe we should add floorf, ceilf, etc. as well. This, however, is a
different issue from the one at hand here.
i think the issues are related. PEP-3141 defines x//y as
int(floor(x/y)). It also defines divmod(x, y) as (x//y, x % y). These
definitions cannot all be satisfied at the same Python's divmod
function takes extra effort to calculate x//y precisely. Those
corrections are not possible via floor().
I maintain gmpy2 which wraps the GMP, MPFR, and MPC arbitrary
precision libraries. I originally implemented x//y as floor(x/y). That
choice lead to errors in divmod() that I've fixed in the development
version. I still need to fix floor division: do I make it compatible
with divmod() or floor()?
My preference would be to define floor division and divmod in terms of
each other and allow math.ceil()/floor()/trunc() to return floating
point values. The current definitions are impossible to satisfy.
I mentioned my concerns about memory growth in another comment. I'm
not as concerned about the unexpected memory growth in floor division
as I am in floor() etc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
What should Decimal('1e123456')//1 return?
I think Decimal case should be considered separately. Note that unlike
float, they are not part of the numerical tower, so PEP 3141 arguments don't
apply:
isinstance(1.0, numbers.Real)
True
isinstance(decimal.Decimal(1), numbers.Real)
False
I maintain gmpy2 and I've had requests to support the numeric tower.
gmpy2 has integral, rational, real, and complex types so I should be
able to.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Antoine Pitrou added the comment: What are the use-cases for float // float where integer result is not acceptable? I can't think of any. I was mostly making the case for conservatism here. The indexing use case is interesting, although I suppose enumerate() should eliminate most instances of it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19776] Provide expanduser() on Path objects
Antoine Pitrou added the comment: Serhiy, would you like to update your patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22445] Memoryviews require more strict contiguous checks then necessary
Stefan Krah added the comment: I think it would help discussing your options if the patch passes test_buffer first. Currently it segfaults because shape can be NULL. Also, code in memoryobject.c relies on the fact that ndim==0 means contiguous. Then, it would help enormously if you give Python function definitions of the revised C and F-contiguity. I mean something like verify_structure() from Lib/test/test_buffer.py -- that function definition was largely supplied by Pauli Virtanen, but I may have added the check for strides-is-multiple-of-itemsize (which 2**63-1 usually isn't, so the new debug numpy strides don't pass that test). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification
Christian Heimes added the comment: Alex's analysis is correct. Starting with 3.4 the SSLSocket object can perform a hostname check during the handshake. More recent versions of OpenSSL or a custom verify callback could do the check even earlier during the handshake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22440 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification
Alex Gaynor added the comment: This can be closed then I think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22440 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification
Christian Heimes added the comment: Yeah. -- resolution: - not a bug stage: - resolved status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22440 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Raymond Hettinger added the comment:
Is this change compelling enough to break compatibility,
or is it just a matter of purity?
I agree with Antoine that making this change is a really bad idea.
1) The current behavior has been around for a long time and is implemented in
several modules including decimal and fractions. As core devs, we need to
keep focused on a priority of making the language stable (not making changes
that truly necessary and invalidating all previously published material) and
more importantly not adding yet more obstacles to converting from Python 2 to
Python 3 (which Guido has called death by a thousand cuts).
2) The current behavior can be useful it that it allows floor division
operations without unexpected type conversions occurring in the middle of an
expression. We really don't want to break those use cases.
# Here is a simple example of a chain of calculations
# where preserving the type matters
from __future__ import print_function
from fractions import Fraction
from decimal import Decimal
def f(x, y):
return x // 3 * 5 / 7 + y
def g(x, y):
return int(x // 3) * 5 / 7 + y
for x, y in [
(Fraction(85, 7), Fraction(2, 3)),
(Decimal('12.143'), Decimal('0.667')),
(12.143, 0.667),
]:
print(f(x, y), g(x, y))
In Python 2:
8/3 8/3
3.524142857142857142857142857 2.667
3.52414285714 2.667
In Python 3:
3.5238095238095237 3.5238095238095237
Traceback (most recent call last):
...
return int(x // 3) * 5 / 7 + y
TypeError: unsupported operand type(s) for +: 'float' and 'decimal.Decimal'
I am a strong -1 against breaking code that relies on the floor division being
type preserving.
The PEP should be revised to say that floor division is defined to return a
value that is *equal* to an Integral but not place any restriction on the
return type.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19776] Provide expanduser() on Path objects
Serhiy Storchaka added the comment: Sorry. Here is updated patch. -- Added file: http://bugs.python.org/file36669/pathlib_expanduser_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio doesn't warn if a task is destroyed during its execution
Marco Paolini added the comment: Sorry for keeping this alive. Take a look at the `wait_for.py` just submitted in the unrelated #22448: no strong refs to the tasks are kept. Tasks remain alive only because they are timers and the event loop keeps strong ref. Do you think my proposed patch is OK? Sould I open a new issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21091] EmailMessage.is_attachment should be a method
R. David Murray added the comment: Here is a patch. Sorry for leaving it until the last minute...maybe someone can review it, but it is simple enough I'll commit it soon regardless. -- Added file: http://bugs.python.org/file36670/is_attachment_as_method.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio doesn't warn if a task is destroyed during its execution
Guido van Rossum added the comment: I'm not sure how that wait_for.py example from issue2116 relates to this issue -- it seems to demonstrate the opposite problem (tasks are kept alive even though they are cancelled). Then again I admit I haven't looked deeply into the example (though I am sympathetic with the issue it purports to demonstrate). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio doesn't warn if a task is destroyed during its execution
Guido van Rossum added the comment: (Whoops meant to link to issue22448.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Guido van Rossum added the comment: By the way I just looked at wait_for.py; it has a bug where do_work() isn't using yield-from with the sleep() call. But that may well be the issue you were trying to debug, and this does not change my opinion about the issue -- I am still looking forward to your patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14293] Message methods delegated via __getattr__ inaccessible using super().method
R. David Murray added the comment: _Headerlist never made it into the committed code. Subclassing Message works fine in both the mainline email code and the provisional extensions. -- resolution: - out of date stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21083] Add get_content_disposition() to email.message.Message
Changes by R. David Murray rdmur...@bitdance.com: -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21083 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Tim Peters added the comment: Floor division on floats is an unattractive nuisance and should be removed, period - so there ;-) But short of that, I favor leaving it alone. Whose life would be improved by changing it to return an int? Not mine - and doing so anyway is bound to break existing code. +1 on changing the PEP instead (as Raymond suggested). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21079] EmailMessage.is_attachment == False if filename is present
Roundup Robot added the comment: New changeset 0044ed0af96f by R David Murray in branch '3.4': #21079: is_attachment now looks only at the value, ignoring parameters. https://hg.python.org/cpython/rev/0044ed0af96f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21079] EmailMessage.is_attachment == False if filename is present
Roundup Robot added the comment: New changeset 54392c4a8880 by R David Murray in branch 'default': Merge: #21079: is_attachment now looks only at the value, ignoring parameters. https://hg.python.org/cpython/rev/54392c4a8880 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21079] EmailMessage.is_attachment == False if filename is present
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - fixed stage: - resolved status: open - closed versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22449] SSLContext.load_verify_locations behavior on Windows and OSX
Changes by Ned Deily n...@acm.org: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22449 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Alex Gaynor added the comment: I can't say that I've ever used // on floats, but it seems to me anyone doing so (as opposed to normal division + explicit rounding) *intentionally* might be broken by this change, but anyone doing this incidentally is not really in a gotcha situation. Since this is a type-specific behavior, and not a value-specific one, I don't really think there's a win in changing the behavior, and staying backwards compatible is much better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21091] EmailMessage.is_attachment should be a method
Roundup Robot added the comment: New changeset a3df1c24d586 by R David Murray in branch '3.4': #21091: make is_attachment a method. https://hg.python.org/cpython/rev/a3df1c24d586 New changeset f7aff40609e7 by R David Murray in branch 'default': Merge: #21091: make is_attachment a method. https://hg.python.org/cpython/rev/f7aff40609e7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21091] EmailMessage.is_attachment should be a method
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - fixed stage: needs patch - resolved status: open - closed type: - behavior versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Joshua Moore-Oliva added the comment: My patch is ready for review, if I followed the process correctly I think you should have received an email https://codereview.appspot.com/145220043 By the way I just looked at wait_for.py; it has a bug where do_work() isn't using yield-from with the sleep() call. But that may well be the issue you were trying to debug, and this does not change my opinion about the issue That was not intended, it was just a mistake. (A quick aside on yield from, feel free to ignore, I don't expect to change anyone's opinion on this) I don't use yield from much - my first use of asyncio was porting an application from gevent (I made a small custom wrapper with fibers (https://pypi.python.org/pypi/fibers) that can internally yield on coroutines). I have read https://glyph.twistedmatrix.com/2014/02/unyielding.html but in my cases, I tend to write my code with the thought that any non standard library function can yield (I initially tried porting to vanilla asyncio, but I ended up having yield from almost everywhere). In the rare cases I want to ensure no yielding takes place across function calls, I like the way gruvi (https://github.com/geertj/gruvi) handles it with a construct to assert no yielding takes place. with assert_no_switchpoints(): do_something() do_something_else() I also find that it is less error prone (missing a yield from), but that is a minor point as I could write a static analyzer (on top of test cases ofc) to check for that. But that's just my opinion and opinion's evolve :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Roundup Robot added the comment: New changeset c2a53aa27cad by Antoine Pitrou in branch 'default': Issue #22359: Remove incorrect uses of recursive make. Patch by Jonas Wagner. https://hg.python.org/cpython/rev/c2a53aa27cad -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5309] distutils doesn't parallelize extension module compilation
Antoine Pitrou added the comment: Updated patch raising DistutilsOptionError. I couldn't find any docs so I didn't update them :-) -- Added file: http://bugs.python.org/file36671/build_ext_parallel6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5309 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Antoine Pitrou added the comment: Ok, I've pushed the patch. Let's see if anyone complains. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Guido van Rossum added the comment: I will try to review later tonight. One thing though: I tend to write my code with the thought that any non standard library function can yield That makes sense when using geven, but not when using asyncio or Trollius. Nothing will make events run if you don't use yield [from]. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Joshua Moore-Oliva added the comment: I will try to review later tonight. Thanks! That makes sense when using gevent, but not when using asyncio or Trollius. Nothing will make events run if you don't use yield [from]. Yes, I am aware of that. I have written a small custom library using fibers (a greenlet-like library) on top of asyncio so that I don't need to use yield from in my application(s). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Larry Hastings added the comment: This is still not fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Georg Brandl added the comment: Sorry for the mismanagement, I probably didn't check again after the final resolution. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument
paul j3 added the comment: Your patch fails: python3 -m unittest test_argparse.TestEmptyAndSpaceContainingArguments specifically these 2 subcases: (['-a badger'], NS(x='-a badger', y=None)), (['-y', '-a badger'], NS(x=None, y='-a badger')), At issue is the ambiguity when the user gives you a string that looks like an optionals flag, but doesn't match one of the defined arguments. When should it be treated as a positional, and when should it be treated as an unknown? The code, and test says - if it has the space, treat it like a positional. You are trying to reverse that choice - if it has the prefix, treat it like an unknown optional. At the point where you apply the patch, we already know that the string has a prefixchar. So you are, effectively, eliminating the 'space' test. I've added a simpler example of where the presence of the space flips that choice. -- nosy: +paul.j3 Added file: http://bugs.python.org/file36672/example.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22433 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Changes by paul j3 ajipa...@gmail.com: -- nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Changes by Joshua Moore-Oliva chatg...@gmail.com: -- nosy: +chatgris ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22450] urllib doesn't put Accept: */* in the headers
New submission from Raymond Hettinger:
The use of urllib for REST APIs is impaired in the absence of a Accept: */*
header such as that added automatically by the requests package or by the CURL
command-line tool.
# Example that gets an incorrect result due to the missing header
import urllib
print
urllib.urlopen('http://graph.facebook.com/raymondh').headers['Content-Type']
# Equivalent call using CURL
$ curl -v http://graph.facebook.com/raymondh
...
* Connected to graph.facebook.com (31.13.75.1) port 80 (#0)
GET /raymondh HTTP/1.1
User-Agent: curl/7.30.0
Host: graph.facebook.com
Accept: */*
--
files: accept.diff
keywords: patch
messages: 227194
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: urllib doesn't put Accept: */* in the headers
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36673/accept.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22450
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22450] urllib doesn't put Accept: */* in the headers
Antoine Pitrou added the comment:
Can you explain how the result is incorrect?
f = urllib.request.urlopen('http://graph.facebook.com/raymondh')
json.loads(f.read().decode())
{'link': 'https://www.facebook.com/raymondh', 'id': '562805507', 'last_name':
'Hettinger', 'gender': 'male', 'first_name': 'Raymond', 'name': 'Raymond
Hettinger', 'locale': 'en_US', 'username': 'raymondh'}
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22450
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22450] urllib doesn't put Accept: */* in the headers
Senthil Kumaran added the comment: Patch looks good. Will need similar addition in urllib2 and inclusion of tests. -- nosy: +orsenthil versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22450 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22450] urllib doesn't put Accept: */* in the headers
Senthil Kumaran added the comment: Well, the result with loading using json will be same. but without sending Accept */*. The content-type returned is text/javascript; charset=UTF-8 and with sending of Accept */* the content-type is set to application/json; charset=UTF-8 (which is more desirable). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22450 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22450] urllib doesn't put Accept: */* in the headers
Antoine Pitrou added the comment: The content-type returned is text/javascript; charset=UTF-8 and with sending of Accept */* the content-type is set to application/json; charset=UTF-8 (which is more desirable). Is that a bug in urllib, or in Facebook's HTTP implementation? Frankly, we shouldn't jump to conclusions just because one specific use case is made better by this. Forcing an accept header may totally change the output of other servers and break existing uses. (and besides, the content-type header is unimportant when you know what to expect, which is normally the case when calling an API) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22450 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type
New submission from Joshua Landau: All code referred to is from bltinmodule.c, Python 2.7.8: https://github.com/python/cpython/blob/2.7/Python/bltinmodule.c filter implements and optimization for PyBool_Type, making it equivalent to PyNone: # Line 303 if (func == (PyObject *)PyBool_Type || func == Py_None) The specializations for tuples, byte strings and unicode don't have this: # Lines 2776, 2827, 2956, 2976 if (func == Py_None) This is a damper against recommending `filter(bool, ...)`. --- Python 3 of course does not have these specializations, so has no bug. -- components: Library (Lib) messages: 227199 nosy: Joshua.Landau priority: normal severity: normal status: open title: filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type type: performance versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument
Changes by paul j3 ajipa...@gmail.com: Added file: http://bugs.python.org/file36674/example.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22433 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument
Changes by paul j3 ajipa...@gmail.com: Removed file: http://bugs.python.org/file36672/example.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22433 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage.
Guido van Rossum added the comment: On Sat, Sep 20, 2014 at 3:38 PM, Joshua Moore-Oliva rep...@bugs.python.org wrote: Joshua Moore-Oliva added the comment: I will try to review later tonight. Thanks! That makes sense when using gevent, but not when using asyncio or Trollius. Nothing will make events run if you don't use yield [from]. Yes, I am aware of that. I have written a small custom library using fibers (a greenlet-like library) on top of asyncio so that I don't need to use yield from in my application(s). Hm. That sounds like you won't actually be interoperable with other asyncio-using code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type
Raymond Hettinger added the comment: Is there code that isn't working as documented or are you asking for additional optimizations to make the other cases run a bit faster when 'bool' is passed in as the filter function? -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type
Joshua Landau added the comment: It's solely a speed thing. I think it was an oversight that the optimisation was only applied to lists. I didn't expect the optimisation to break when applied to tuples. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22449] SSLContext.load_verify_locations behavior on Windows and OSX
Alex Gaynor added the comment: Does this effect anything besides causing SSL_CERT_DIR and SSL_CERT_FILE to be respected? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22449 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
