[issue12029] Catching virtual subclasses in except clauses

[R. David Murray]

R. David Murray added the comment:

Note from discussion on duplicate issue 25448: when this is fixed, the 
try/except documentation should be updated to indicate that the except clause 
test is equivalent to 'issubclass', so that the handling of virtual subclasses 
are implied by the doc.  (The current proposed patch contains no doc changes.)

Apparently this also affects pypy.

--
nosy: +alex, fijal, r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Steven D'Aprano]

Steven D'Aprano added the comment:

I'm not entirely satisfied that the way it is calculated by C++11/C99 is 
correct. (Although I can see the appeal of the C version.) Mathematically, 
complex multiplication (a+bj)*x should be identical to (a+bj)*(x+0j), but 
obviously in the presence of NANs that is no longer the case. So it isn't clear 
to me that Python is wrong to allow NANs to "infect" the real part after 
multiplication.

Before changing the behaviour, I'd like to hear from someone who might be able 
to comment on what the IEEE-754 standard may have to say about this.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Francesco Biscani]

Francesco Biscani added the comment:

The best reference I could find so far is in the C99 standard:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Annex G is titled "IEC 60559-compatible complex arithmetic". In G.3.1 it is 
written:

"""
A complex or imaginary value with at least one infinite part is regarded as an 
infinity (even if its other part is a NaN).
"""

Later on, in G.5.1.4, it is stated:

"""
The * and / operators satisfy the following infinity properties for all real, 
imaginary, and complex operands:

- if one operand is an infinity and the other operand is a nonzero finite 
number or an infinity, then the result of the * operator is an infinity;
- if the first operand is an infinity and the second operand is a finite 
number, then the result of the / operator is an infinity;
- if the first operand is a finite number and the second operand is an 
infinity, then the result of the / operator is a zero;
"""

So to recap, according to these definitions:

- inf + nanj is a complex infinity,
- (inf + nanj) * (2 + 0j) should give a complex infinity (i.e., a complex 
number in which at least one component is inf).

I am not saying that these rules are necessarily "mathematically correct". I am 
aware that floating point is always a quagmire to get into, and the situation 
here is even more complex (eh!) than usual.

But it seems to me that Python, or CPython at least, follows a pattern of 
copying (or relying on) the behaviour of C for floating-point operations, and 
it seems like in the case of complex numbers this "rule" is broken. It 
certainly caught me by surprise anyway :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] operator.subscript

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority: normal -> high

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25210] Special-case NoneType() in do_richcompare()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5c7dd88cd0c5 by Berker Peksag in branch 'default':
Issue #25210: Add some basic tests for the new exception message
https://hg.python.org/cpython/rev/5c7dd88cd0c5

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Eric V. Smith]

Eric V. Smith added the comment:

Saksham: Also, it would be best to take this discussion of how to produce a 
patch to the python-committers mailing list: 
https://mail.python.org/mailman/listinfo/python-committers

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25449] Test OrderedDict subclass

[Eric Snow]

Eric Snow added the comment:

Regarding dict.__setitem__, see issue #24726.  Raymond outlined what needs to 
be fixed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Saksham Agrawal]

Saksham Agrawal added the comment:

I read the first 6 chapters of the devguide.

Now how should I proceed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] operator.subscript

[Raymond Hettinger]

Raymond Hettinger added the comment:

This is causing a reference leak problem:  
https://mail.python.org/pipermail/python-dev/2015-October/141993.html

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25449] Test OrderedDict subclass

[Eric Snow]

Changes by Eric Snow :


--
stage: commit review -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

[Eric Snow]

Eric Snow added the comment:

FTR, this will likely involve more than just fixing odict_repr().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Eric V. Smith]

Eric V. Smith added the comment:

Saksham: First we need our "experts" to decide what, if any, change is needed. 
If we decide that a change is needed, at that point we'd look at a patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Berker Peksag]

Berker Peksag added the comment:

> Also, it would be best to take this discussion of how to produce a patch to 
> the python-committers mailing list:

or the core-mentorship list: 
https://mail.python.org/mailman/listinfo/core-mentorship :)

--
nosy: +berker.peksag

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20504] cgi.FieldStorage, multipart, missing Content-Length

[Berker Peksag]

Berker Peksag added the comment:

The attached patch(cgi.patch) doesn't fix the problem for me: cgi-bug.py still 
fails with a TypeError. Here is a patch with a test to fix the problem.

With issue20504.diff applied:

$ ./python t.py 
5

(Only changed the "assert len(fields["my-arg"].file.read()) == 5" line with 
"print(len(fields["my-arg"].file.read()))")

--
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file40833/issue20504.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25417] Minor typo in Path.samefile docstring

[Berker Peksag]

Berker Peksag added the comment:

Fixed, thank you Antony.

--
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25417] Minor typo in Path.samefile docstring

[Antony Lee]

Antony Lee added the comment:

Actually there's also an extra dot at the end of the first line of the 
docstring (redundant with the one on the second line).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Eric V. Smith]

Eric V. Smith added the comment:

> Berker Peksag added the comment:
> 
>> Also, it would be best to take this discussion of how to produce a patch to 
>> the python-committers mailing list:
> 
> or the core-mentorship list: 
> https://mail.python.org/mailman/listinfo/core-mentorship :)

Argh! That's of course what I meant. Apologies all around.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Mark Dickinson]

Mark Dickinson added the comment:

Changing Python versions and issue type: the current behaviour is certainly 
deliberate, so a proposal to change it would be a feature request, which could 
only land in Python 3.6 or later.

--
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks for the update.

I'm not too worried about performance: I suspect that any additional overhead 
would be lost in the overhead of the Python machinery. It would be worth 
profiling to check, of course, before any change went in. I'd expect that most 
performance critical code of this type would be using NumPy/SciPy anyway.

I'm still unsure about whether the code is worth changing: I do agree that the 
behaviour suggested by C99 Annex G is (in the abstract) an improvement on 
Python's current behaviour, and compatibility with C would be a plus. On the 
other side, introducing an incompatibility with other versions of Python and 
with NumPy isn't ideal. For me, the potential benefits don't really overcome 
the drawbacks here, but I'd like to hear other opinions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25417] Minor typo in Path.samefile docstring

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7d65be20e0d8 by Berker Peksag in branch '3.5':
Issue #25417: Fix typo in Path.samefile() docstring
https://hg.python.org/cpython/rev/7d65be20e0d8

New changeset 0b09a866da77 by Berker Peksag in branch 'default':
Issue #25417: Fix typo in Path.samefile() docstring
https://hg.python.org/cpython/rev/0b09a866da77

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25449] Test OrderedDict subclass

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

New patch adds PurePythonOrderedDictSubclassTests, moves all tests except 
test_key_change_during_iteration from CPythonOrderedDictTests to 
OrderedDictTests to test Python implementation too, fixes a bug in values and 
items iteration that caused test_issue24347 to fail, and adds additional 
explicit checks for values() and items() to test_issue24347.

--
type: enhancement -> behavior
Added file: http://bugs.python.org/file40832/odict_subclass_test_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25454] operator.methodcaller should accept additional arguments during the call

[Evgeny Kapun]

New submission from Evgeny Kapun:

Currently, operator.methodcaller behaves like this:

def methodcaller(name, *args, **kwargs):
def caller(obj):
return getattr(obj, name)(*args, **kwargs)
return caller

That is, it is possible to supply arguments when the object is created but not 
during the call. I think that it will be more useful if it behaved like this:

def methodcaller(name, *args, **kwargs):
def caller(obj, *args2, **kwargs2):
return getattr(obj, name)(*args, *args2, **kwargs, **kwargs2)
return caller

--
components: Extension Modules
messages: 253307
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: operator.methodcaller should accept additional arguments during the call
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Mark Dickinson]

Mark Dickinson added the comment:

If the proposal is to add C99 Appendix G-style handling of nan+nanj results for 
complex multiplication, that doesn't seem unreasonable to me, though I'm not 
particularly convinced that the gain in complexity is worth it.  So -0 from me. 
Whatever happens, I'd hope that the complex multiplication operation 
remains simple and easily explainable, not degenerating into a mass of special 
cases.

I'd be opposed to adding special-case handing for float-by-complex 
multiplication (i.e., doing anything other than promoting the float to a 
complex by introducing a zero imaginary part, and then doing normal complex 
multiplication).  But I don't think that's what Francesco is proposing.

FWIW, NumPy semantics follow those of Python, though that's hardly an 
independent data point.

In answer to Steven, IEEE 754 has precisely nothing to say on this subject: it 
simply doesn't cover complex arithmetic.

Francesco: by the way, I'd be interested to see the C source that gave you `inf 
+ nan*j` for this.  How did you initialise the arguments to the multiplication? 
C99 has a significant issue here (fixed in C2011), namely that there's no 
standard way to create a complex value with given real and imaginary parts.  
(Using real_part + I*imaginary_part doesn't count, because in the absence of 
the Imaginary type, which few compilers seem to implement, the real part of the 
"I" constant mucks up the arithmetic w.r.t. infinities, NaNs and signed zeros.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Francesco Biscani]

Francesco Biscani added the comment:

Hi Mark,

the original code is C++, and the inf + nanj result can be reproduced by the 
following snippet:

"""
#include 
#include 

int main(int argc, char * argv[]) {
  std::cout << std::complex(3,0) / 0. << '\n';
  return 0;
}
"""

Here is the C99 version:

"""
#include 
#include 
#include 

int main(int argc, char * argv[]) {
  double complex a = 3.0 + 0.0*I;
  printf("%f + i%f\n", creal(a/0.), cimag(a/0.));
  return 0;
}
"""

This is on Linux x86_64 with GCC 4.9. Clang gives the same result. Adding the 
"-ffast-math" compilation flag changes the result for the C version but 
apparently not for the C++ one.

The original code came from an implementation of a special function f(z) which 
has a pole near the origin. When computing f(0), the C++ code returns 
inf+nan*j, which is fine (in the sense that it is a complex infinity of some 
kind). I then need to use this result in a larger piece of code which at one 
point needs to compute 1/f(0), with the expected result being 0 mathematically. 
This works if I implement the calculation all within C/C++, but if I switch to 
Python when computing 1/f(0) I get nan + nan*j as a result.

Of course I could do all sorts of stuff to improve this specific calculation 
and avoid the problems (possibly improving the numerical behaviour near the 
pole via a Taylor expansion, etc. etc. etc.).

Beware that implementing C99 behaviour will result in a noticeable overhead for 
complex operations. In compiled C/C++ code one usually has the option to switch 
on/off the -ffast-math flag to improve performance at the expense of 
standard-conformance, but I imagine this is not feasible in Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25455] Some repr implementations don't check for self-referential structures

[Evgeny Kapun]

New submission from Evgeny Kapun:

Implementations of repr for some of the types in the standard library doesn't 
check for self-referential structures. As a result, when calling repr() on such 
objects, Python crashes due to infinite recursion.

Example:
>>> import functools
>>> x = functools.partial(min)
>>> x.__setstate__((x, (), {}, {}))
>>> repr(x)
Segmentation fault

Another example:
>>> import xml.etree.ElementTree
>>> x = xml.etree.ElementTree.Element('')
>>> x.tag = x
>>> repr(x)
Segmentation fault

One more example:
>>> import io
>>> class X(io.TextIOWrapper): __slots__ = 'name'
>>> x = X(open('/dev/null'))
>>> x.name = x
>>> repr(x)
Segmentation fault

--
components: Extension Modules
messages: 253309
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Some repr implementations don't check for self-referential structures
type: crash
versions: Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory

[Steve Dower]

Changes by Steve Dower :


--
assignee:  -> steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

__repr__() allocates a list with the size len(od) and fills it iterating linked 
list. If the size of linked list is less then the size of the dict, the rest of 
the list is not initialized.

Even worse things happened when the size of linked list is greater then the 
size of the dict. Following example causes a crash:

from collections import OrderedDict
od = OrderedDict()
class K(str):
def __hash__(self):
return 1

od[K('a')] = 1
od[K('b')] = 2
print(len(od), len(list(od)))
K.__eq__ = lambda self, other: True
dict.__delitem__(od, K('a'))
print(len(od), len(list(od)))
print(repr(od))

Proposed patch fixes both issues.

--
components: +Extension Modules -Library (Lib)
keywords: +patch
stage: test needed -> patch review
type: behavior -> crash
versions:  -Python 2.7, Python 3.4
Added file: 
http://bugs.python.org/file40834/odict_repr_after_dict_setitem_delitem.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24782] Merge 'configure extensions' into main IDLE config dialog

[Mark Roseman]

Mark Roseman added the comment:

The extra width appears to be coming from the canvas inside 
VerticalScrolledFrame; the canvas gets the default size and the frame adjusts 
to fit its contents (the canvas and the scrollbar). If you really want to 
reduce the size, add a "-width" option where that canvas is being created.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25417] Minor typo in Path.samefile docstring

[Roundup Robot]

Roundup Robot added the comment:

New changeset 642a7be9f384 by Berker Peksag in branch '3.5':
Issue #25417: Remove the extra dot from docstring
https://hg.python.org/cpython/rev/642a7be9f384

New changeset 4cd2ae001d30 by Berker Peksag in branch 'default':
Issue #25417: Remove the extra dot from docstring
https://hg.python.org/cpython/rev/4cd2ae001d30

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23981] Update test_unicodedata.py to use script_helpers

[Roundup Robot]

Roundup Robot added the comment:

New changeset fbd83224e132 by Berker Peksag in branch '3.5':
Issue #23981: Update test_unicodedata to use script_helpers
https://hg.python.org/cpython/rev/fbd83224e132

New changeset 6315abbf5f71 by Berker Peksag in branch 'default':
Issue #23981: Update test_unicodedata to use script_helpers
https://hg.python.org/cpython/rev/6315abbf5f71

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23981] Update test_unicodedata.py to use script_helpers

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch, Christie.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25017] htmllib deprecated: Which library to use? Missing sane default in docs

[Nan Wu]

Nan Wu added the comment:

Updated the patch. The typo was fixed too. Thanks for the catching.

--
Added file: http://bugs.python.org/file40831/htmllib_deprecation_warning_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Ezio Melotti]

Ezio Melotti added the comment:

Saksham, if you would like to work on this issue you can check the devguide for 
more information.

--
components: +Interpreter Core
nosy: +eric.smith, ezio.melotti, lemburg, mark.dickinson, stutzbach
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5

[R. David Murray]

R. David Murray added the comment:

Thanks, but special-casing login in the 'auth' method means that the auth 
method isn't working right, since special-casing defeats the whole purpose of 
the auth mechanism.

I think we need to change the logic in auth so that it is checking for a 334 
even if it has been provided an initial response.  That is, outdent the block 
that starts with the '# Server replies...' comment.  Once that is done, 
auth_login becomes:

  def auth_login(self, challenge=None)
  if challenge is None:
  return encode_base64(self.user.encode('ascii'))
  else:
  return self.password

We may also need to add a try/except around the base64.decodebytes in auth.

And we need a unit test that demonstrates the current failure.

I'm also wondering now about the ascii encoding on the challenge and response.  
Someone should check the RFC to see if those are limited to ascii or if they 
can contain other bytes.  If they are limited to ascii we should stick in a 
comment to that effect with a pointer to the relevant RFC section.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14373] C implementation of functools.lru_cache

[Matt Joiner]

Changes by Matt Joiner :


--
nosy:  -anacrolix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[Richard Neumann]

New submission from Richard Neumann:

The class subprocess.CompletedProcess is currently lacking a __bool__() method.

It might be a practical feature to have the possibility to evaluate a 
CompletedProcess instance in an if/else block without the necessity to handle 
the exception raised by CompletedProcess.check_returncode().

Hence, I suggest adding the method

def __bool__(self):
return self.returncode == 0

to the class.

--
components: Library (Lib)
messages: 253282
nosy: conqp
priority: normal
severity: normal
status: open
title: Add __bool__() method to subprocess.CompletedProcess
type: enhancement
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Francesco Biscani]

New submission from Francesco Biscani:

The C++11/C99 standards define a complex infinity as a complex number in which 
at least one of the components is inf. Consider the Python snippet:

>>> complex(float('inf'),float('nan'))*2
(nan+nanj)

This happens because complex multiplication in Python is implemented in the 
most straightforward way, but the presence of a nan component "infects" both 
components of the result and leads to a complex nan result. See also how 
complex multiplication is implemented in Annex G.5.1.6 of the C99 standard.

It feels wrong that a complex infinity multiplied by a real number results in a 
complex nan. By comparison, the result given here by C/C++ is inf+nan*j.

Note also this:

>>> complex(float('inf'),float('nan'))+2  
(inf+nanj)

That is, addition has a different behaviour because it does not require mixing 
up the components of the operands.

This behaviour has unexpected consequences when one interacts with math 
libraries implemented in C/C++ and accessed via Python through some wrapping 
tool. For instance, whereas 1./(inf+nan*j) is zero in C/C++, it becomes in 
Python

>>> 1./complex(float('inf'),float('nan'))  
(nan+nanj)

--
messages: 253283
nosy: Francesco Biscani
priority: normal
severity: normal
status: open
title: Arithmetics with complex infinities is inconsistent with C/C++
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25453] Arithmetics with complex infinities is inconsistent with C/C++

[Saksham Agrawal]

Saksham Agrawal added the comment:

Hi

Would like to work on this bug...but I am new, would like some guidance

Please help me

--
nosy: +Saksham Agrawal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25449] Test OrderedDict subclass

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The patch was not ready for commit. The problem is that test_issue24347 fails 
in CPythonOrderedDictSubclassTests. The failure is random, you need to run test 
several times to encounter it.

Experimenting with this test I found other bug probably related to issue24347.

>>> from collections import OrderedDict
>>> od = OrderedDict()
>>> dict.__setitem__(od, 1, 2)
>>> od
OrderedDict([])

I expected rather raising an exception or showing an empty OrderedDict, that 
exposing NULL.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
title: IDLE: Save path automatically choses C:\Windows\system32 -> Python 3.5 
starts in C:\Windows\system32 as current directory
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory

[eryksun]

eryksun added the comment:

> 'Start in:' is blank and for what ever reason, the default is ...system32. 

When the "Start in" field of a .lnk shortcut is blank, the child process 
inherits the working directory of the parent process (i.e. the process that 
runs the shortcut), unless the parent passes some other directory to 
ShellExecute. 

If you copy the shortcut to the desktop, for example, Explorer sets the working 
directory to the desktop. If it's run from the command prompt, cmd uses its own 
working directory. When run from the Start menu, the child inherits Explorer's 
working directory, %SystemRoot%\System32.

The old installer (pre-3.5) sets "Start in" to the installation directory. IMO, 
a better choice would be "%USERPROFILE%". The Windows shell expands the 
environment variable to the current user's profile directory when it runs the 
shortcut. 

I'm not keen on using a profile subdirectory such as "Documents" or "Desktop", 
since a user can relocate most of the special folders in his or her profile. 
Unfortunately the "Start in" field won't accept shell: locations such as 
"shell:Personal" or "shell:Desktop". It would be nice if it did, since those 
take into account relocated folders.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory

[Terry J. Reedy]

Terry J. Reedy added the comment:

Thanks for the explanation.  When I did the test with Command Prompt, I 
happened to be in /Users/Terry, which is where C.P. starts.  %USERPROFILE% is 
what I was thinking of but could not precisely remember.  It worked when put in 
that box.

I think adding /Documents would be a mistake because many users (including me) 
put Python stuff in other subdirectories.

A minor mystery.  Changing Start in: for the Python icon requires admin 
permission; for the IDLE icon, not.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25017] htmllib deprecated: Which library to use? Missing sane default in docs

[Martin Panter]

Martin Panter added the comment:

Also beware it should be :mod: not :mode: :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25451] PhotoImage transparency methods

[None Becoming]

New submission from None Becoming:

The transparency methods of tkinter.PhotoImage seem to be missing.
Presumably, they would go something like:

def transparency_get(self, x, y):
"""Returns a boolean indicating if the pixel at (x,y) is transparent. """

return self.tk.call(self.name, 'transparency', 'get', x, y)

def transparency_set(self, x, y, boolean=True):
"""Make pixel at (x,y) transparent if boolean is true, opaque otherwise. """

self.tk.call(self.name, 'transparency', 'set', x, y, boolean)

--
components: Tkinter
messages: 253281
nosy: None Becoming
priority: normal
severity: normal
status: open
title: PhotoImage transparency methods
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com