[issue31929] Raw strings create syntax error when last character is a single backslash
New submission from Barry : Raw strings create syntax error when last character is a backslash (\). This problem seems to exist across all versions of python (that I have access to) Sample Code: - Under Windows Python 2.7.3 Works Correctly: >>> test = r'C:\Program Files\^%(x86)\Internet Explorer\iexplore.exe' >>> print test C:\Program Files\^%(x86)\Internet Explorer\iexplore.exe Fails because last character is backslash >>> test = r'C:\Program Files\^%(x86)\Internet Explorer\' SyntaxError: EOL while scanning string literal - Under Linux Python 2.7.12 Works Correctly >>> j=r"\n" >>> print j \n Fails because last character is backslash >>> j=r"n\" SyntaxError: EOL while scanning string literal Works correctly: >>> j=r"n\n" >>> print j n\n Works correctly: >>> j=r"n\\" >>> print j n\\ - Under Linux Python 3.5.2 Fails because last character is backslash >>> j=r"\' File "", line 1 j=r"\' ^ SyntaxError: EOL while scanning string literal - -- components: Interpreter Core messages: 305448 nosy: mezzzmer priority: normal severity: normal status: open title: Raw strings create syntax error when last character is a single backslash type: compile error versions: Python 2.7, Python 3.5 ___ Python tracker <https://bugs.python.org/issue31929> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.
New submission from Barry Schwartz : The Objects/listsort.txt incorrectly implies that it is not possible to compute leading zero bits in O(1) time, using only standard C. For a fixed integer size it can be done, for instance, using de Bruijn sequences. See https://www.chessprogramming.org/BitScan (The existence of such methods is not as widely known as it ought to be.) -- assignee: docs@python components: Documentation messages: 411384 nosy: chemoelectric, docs@python priority: normal severity: normal status: open title: listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time. type: performance versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.
Barry Schwartz added the comment: Yes. Actually the issue is branching, not order of complexity, because looping at most 64 times is a linear-bounded operation. The methods I point out involve no branching! And so can be rather fast. I don't suggest they be used, but that the listsort.txt be revised. -- ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.
Barry Schwartz added the comment: I meant constant bounded -- ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: The attached patch builds on Mike's work. The core of the problem is that the Request object did not know what was going on. This means that it was not possible for get_authorization() to work for proxy-auth and www-auth. I change Request to know which of the four types of connection it represents. There are new methods on Request that return the right information based on the connection type. To understand how to make this work I needed to instrument the code. There is now a set_debuglevel on the OpenerDirector object that turns on debug in all the handlers and the director. I have added more debug messages to help understand this code. This code now passes the 72 test cases I run. I'll attach the code I used to test as a follow up to this. -- nosy: +b.a.scott Added file: http://bugs.python.org/file20821/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: Attached is the code I used to test these changes. See the README.txt file for details include the results of a test run. -- Added file: http://bugs.python.org/file20822/urllib2_tests.tar.gz ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: I left out some white space changes to match the style of the std lib code. Re posting with white space cleanup. -- Added file: http://bugs.python.org/file20824/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Changes by Barry Scott : Removed file: http://bugs.python.org/file20821/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46959] ctypes.util.find_library can delete /dev/null
New submission from Barry Davis :
This bug exists again: https://bugs.python.org/issue1521375
In ctypes/util we defend against gcc removing /dev/null by using a temp file,
but similar code for ld still uses /dev/null, resulting in it removing
/dev/null if it has permission, i.e. if running as root.
Reproduction steps in the original bug still work I think.
I found this when running pyinstaller.
I slimmed the test case down to:
import ctypes.util
libname = ctypes.util.find_library("ApplicationServices")
Here's my patch (indentation is wrong to just show the actual change needed):
--- Python-3.10.2/Lib/ctypes/util.py2022-03-08 14:34:52.188808751 +
+++ Python-3.10.2/Lib/ctypes/util.py2022-03-08 14:40:23.604615242 +
@@ -305,9 +305,11 @@
if libpath:
for d in libpath.split(':'):
cmd.extend(['-L', d])
-cmd.extend(['-o', os.devnull, '-l%s' % name])
-result = None
+temp = tempfile.NamedTemporaryFile()
try:
+ cmd.extend(['-o', temp.name, '-l%s' % name])
+ result = None
+ try:
p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
universal_newlines=True)
@@ -320,8 +322,15 @@
if not _is_elf(file):
continue
return os.fsdecode(file)
-except Exception:
+ except Exception:
pass # result will be None
+finally:
+try:
+temp.close()
+except FileNotFoundError:
+# Raised if the file was already removed, which is the
normal
+# behaviour if linking fails
+pass
return result
def find_library(name):
--
components: Library (Lib)
messages: 414756
nosy: barry.c.davis
priority: normal
severity: normal
status: open
title: ctypes.util.find_library can delete /dev/null
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46959>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38238] site.py reporting user site info even if ENABLE_USER_SITE=False
New submission from Barry Muldrey : site info is accessed externally via getusersitepackages() and getuserbase()... for example see "pip/_internal/locations.py" If ENABLE_USER_SITE is set to "False," or otherwise disabled, accesses to these methods should return '' or None (shouldn't they?). Currently, I have ENABLE_USER_SITE globally disabled (by various means), but pip's call to getusersitepackages() is still returning "~/.local/lib/...". This seems wrong. An alternative would be for external tools to manually import site.ENABLE_USER_SITE, but this seems incorrect. -- components: Library (Lib) messages: 352884 nosy: bjmuld priority: normal severity: normal status: open title: site.py reporting user site info even if ENABLE_USER_SITE=False type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38238] site.py reporting user site info even if ENABLE_USER_SITE=False
Change by Barry Muldrey : -- keywords: +patch pull_requests: +15888 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16303 ___ Python tracker <https://bugs.python.org/issue38238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27823] Change bare AttributeError messages to be more informative
Anilyka Barry added the comment: I'd forgotten that I did that. Looking back on it, this is indeed not a good change. Since there hasn't been any traction on in for 5 years, I think it's safe to say it's not something people want. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue27823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40126] Incorrect error handling in unittest.mock
New submission from Barry McLarnon :
The error handling in mock.decorate_callable (3.5-3.7) and
mock.decoration_helper (3.8-3.9) is incorrectly implemented. If the error
handler is triggered in the loop, the `patching` variable is out of scope and
raises an unhandled `UnboundLocalError` instead.
This happened as a result of a 3rd-party library that attempts to clear the
`patchings` list of a decorated function. The below code shows a recreation of
the incorrect error handling:
import functools
from unittest import mock
def is_valid():
return True
def mock_is_valid():
return False
def decorate(f):
@functools.wraps(f)
def decorate_wrapper(*args, **kwargs):
# This happens in a 3rd-party library
f.patchings = []
return f(*args, **kwargs)
return decorate_wrapper
@decorate
@mock.patch('test.is_valid', new=mock_is_valid)
def test_patch():
raise Exception()
--
components: Tests
messages: 365395
nosy: bmclarnon
priority: normal
severity: normal
status: open
title: Incorrect error handling in unittest.mock
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40126] Incorrect error handling in unittest.mock
Barry McLarnon added the comment: After further investigation, it seems this was fixed in https://github.com/python/cpython/commit/436c2b0d67da68465e709a96daac7340af3a5238 However, this fix was as part of an unrelated changeset and in a different function in 3.8+, and was never rolled back to 3.7 and below. PR opened to add the missing attribute instantiation to 3.7. -- nosy: -python-dev versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40126] Incorrect error handling in unittest.mock
Change by Barry McLarnon : -- components: +Library (Lib) -Tests ___ Python tracker <https://bugs.python.org/issue40126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40126] Incorrect error handling in unittest.mock
Barry McLarnon added the comment: Issue still exists in 3.7 and below, as it was part of a different function before. Current PR doesn't resolve the original issue that was raised. -- versions: +Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue40126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36132] Python cannot access hci_channel field in sockaddr_hci
Barry Byford added the comment: I was looking to control Bluetooth on Linux machines using the BlueZ Management API available at: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt The Bluetooth management sockets can be created by setting the hci_channel member of struct sockaddr_hci to HCI_CHANNEL_CONTROL (3) when creating a raw HCI socket. The resolution of this issue would enable access to that API. -- nosy: +ukBaz ___ Python tracker <https://bugs.python.org/issue36132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform
Barry Davis added the comment:
I've just hit this issue using Python-2.7.9, gcc-8.1.0, glibc-2.23.
The patch I made to fix the issue based on comments in this issue:
--- Python-2.7.9/setup.py 2019-01-25 09:30:39.049501423 +
+++ Python-2.7.9/setup.py 2019-01-25 09:30:55.369609646 +
@@ -1670,7 +1670,7 @@
else: # Linux and other unices
macros = dict()
-libraries = ['rt']
+libraries = ['rt', 'pthread']
if host_platform == 'win32':
multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
@@ -1690,6 +1690,7 @@
if sysconfig.get_config_var('WITH_THREAD'):
exts.append ( Extension('_multiprocessing', multiprocessing_srcs,
+libraries = libraries,
define_macros=macros.items(),
include_dirs=["Modules/_multiprocessing"]))
else:
--
nosy: +Barry Davis
___
Python tracker
<https://bugs.python.org/issue31171>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform
Barry Davis added the comment:
The behaviour I saw (32-bit only) was a python process getting stuck.
I got this from strace:
...
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
...
And this from gdb:
(gdb) bt
#0 0xb76fbc5d in __kernel_vsyscall ()
#1 0xb74af2a4 in sem_wait () from /lib/libpthread.so.0
#2 0xb69a5429 in ?? () from /usr/lib/python2.7/lib-dynload/_multiprocessing.so
#3 0xb75a262e in call_function (oparg=, pp_stack=0xbfb7f038) at
Python/ceval.c:4033
#4 PyEval_EvalFrameEx (f=, throwflag=) at
Python/ceval.c:2679
#5 0xb75a2f7d in PyEval_EvalCodeEx (co=, globals=
{'Queue': , 'atexit': , 'Semaphore': , 'Empty': , 'Full': , 'SimpleQueue': , 'assert_spawning': ,
'__all__': ['Queue', 'SimpleQueue', 'JoinableQueue'], '_multiprocessing':
, '_sentinel': ,
'__package__': 'multiprocessing', 'collections': ,
'__doc__': None, 'Condition': , 'JoinableQueue':
, '__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': <_Helper at remote 0xb71f824c>, 'vars': , 'SyntaxError': , 'unicode': , 'UnicodeDecodeError': ,
'memoryview': , 'isinstance...(truncated), locals=0x0, args=0xb535f5cc,
argcount=2, kws=0xb535f5d4, kwcount=0, defs=0xb69b6058, defcount=2,
closure=0x0) at Python/ceval.c:3265
#6 0xb75a0f3d in fast_function (nk=0, na=, n=2,
pp_stack=0xbfb7f178, func=) at
Python/ceval.c:4129
#7 call_function (oparg=, pp_stack=0xbfb7f178) at
Python/ceval.c:4054
#8 PyEval_EvalFrameEx (f=, throwflag=) at
Python/ceval.c:2679
...
(gdb) py-bt
#4 Frame 0xb536602c, for file /usr/lib/python2.7/multiprocessing/queues.py,
line 101, in put (self=, _recv=, _thread=None, _sem=,
acquire=, _semlock=<_multiprocessing.SemLock at remote 0xb53427c0>) at
remote 0xb53425cc>, _buffer=,
_closed=False, _send=, _jointhread=None, _reader=None, _opid=3752,
_rlock=, acquire=,
_semlock=<_multiprocessing.SemLock at remote 0xb53424
20>) at remote 0xb534240c>, _...(truncated)
...
--
___
Python tracker
<https://bugs.python.org/issue31171>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Changes by Barry Davis : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: I think this is the same issue I'm getting. I'm hitting it when compiling python 3.6.2 compiled with gcc-4.8.4. This wasn't occasional, it was every time I tried. As a feeble workaround I was compiling in parallel, then in serial when it fails, although I'm now hitting the same issue when building uwsgi-2.0.15. I'm building on a 56 core system so that might make me more likely to hit the issue. -- nosy: +Barry Davis ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30524] iter(classmethod, sentinel) broken for Argument Clinic class methods?
Changes by Emanuel Barry : -- nosy: +haypo, serhiy.storchaka stage: -> needs patch type: -> behavior ___ Python tracker <http://bugs.python.org/issue30524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: Looks like I was mistaken. My cross compiler was trying to load libgcc_s.so.1 from the standard location and not liking the one it found. Fixed for now by setting LD_LIBRARY_PATH to point at the dir containing the right libgcc_s.so.1 -- versions: -Python 3.6 ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: I meant my cross compiled python, not my cross compiler. -- ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Unfortunately not. I no longer have the time or means to work on this, sorry. I hope someone else can pick it up. -- ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Change by Emanuel Barry : -- nosy: -ebarry ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
New submission from Emanuel Barry : This is a follow-up to Issue27364. Back in Python 3.6, a silent warning was added for all invalid escape sequences in str and bytes. It was suggested that it would remain a silent warning (which still impacts tests, while not visually annoying the average user) for two releases (3.6 and 3.7), then would be upgraded to a non-silent warning for two subsequent releases (3.8 and 3.9) before becoming a full-on syntax error. With the 3.7 feature freeze on and going, I think it's time to evaluate the approach we take for 3.8 :) I suggest upgrading the DeprecationWarning to a SyntaxWarning, which is visible by default, for 3.8 and 3.9. I have cross-linked #27364 to this issue as well. -Em -- components: Interpreter Core messages: 312575 nosy: ebarry priority: normal severity: normal stage: needs patch status: open title: Raise non-silent warning for invalid escape sequences type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27364] Deprecate invalid escape sequences in str/bytes
Emanuel Barry added the comment: I have created Issue32912 as a follow-up to this issue for 3.8. -- ___ Python tracker <https://bugs.python.org/issue27364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Change by Emanuel Barry : -- keywords: +patch pull_requests: +5625 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33035] Some examples in documentation section 4.7.2 are incorrect
Emanuel Barry added the comment: The documentation is correct. The first argument in both of those cases is a str, which may not be what you were expecting, but the calls are still valid. -- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33284] Increase test coverage for numbers.py
New submission from Barry Devlin : The __bool__ method in the complex class in numbers is not tested. -- components: Tests messages: 315337 nosy: Barry Devlin priority: normal severity: normal status: open title: Increase test coverage for numbers.py versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue33284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33284] Increase test coverage for numbers.py
Barry Devlin added the comment: Hey, I updated my pull request based in your advice. Could you review it please? Best, Barry On Sat, 21 Apr 2018, 03:20 Terry J. Reedy, wrote: > > Terry J. Reedy added the comment: > > Barry, thank you for your first submission. > > You propose to test numbers.Complex.__bool__ > > def __bool__(self): > """True if self != 0. Called for bool(self).""" > return self != 0 > > by adding the following to Lib/test/test_abstract_numbers. > > +self.assertFalse(bool(complex(0,0))) > +self.assertTrue(bool(complex(1,2))) > > I believe that this particular addition should be rejected. It is a > concrete test of the builtin complex that partially duplicates the > following in test_complex. > > def test_boolcontext(self): > for i in range(100): > self.assertTrue(complex(random() + 1e-6, random() + 1e-6)) > self.assertTrue(not complex(0.0, 0.0)) > > Looking the tests of collections.abc in test_collections, I believe a > proper test should define a subclass of Complex (in Python), with at least > __init__ and __eq__ methods and test instances of *that*. > > If I were to review a patch, I would like to see a more extensive > addition, one that imports test_collections.ABCTestCase (or copies and > adapts the same) and uses it to test a much fuller implementation of > Complex. As it is, none of the numbers abc class methods are tested. > > Raymond, were you involved with the abc tests? Either way, what do you > think? > > -- > nosy: +rhettinger, terry.reedy > > ___ > Python tracker > <https://bugs.python.org/issue33284> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33401] `exec` attribute can't be set to objects in Python2 (SyntaxError)
Emanuel Barry added the comment: This is because `exec` is a keyword in Python 2, whereas in Python 3 it's a function. -- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33401] `exec` attribute can't be set to objects in Python2 (SyntaxError)
Emanuel Barry added the comment: Any valid variable name can be used as a an attribute; for example, "spam" is valid while "spam-eggs" is not. This isn't unique to classes, but to all assignments everywhere. If we allowed `o.exec = blah` then we should also allow `exec = blah` at the global scope and that's a whole load of not happening, much less in Python 2 (which isn't getting any significant updates anymore). -- ___ Python tracker <https://bugs.python.org/issue33401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33410] Using type in a format with padding causes TypeError
Emanuel Barry added the comment: `type` has a default `__format__` implementation which doesn't accept any formatting options. This is expected behaviour. -- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33423] [logging] Improve consistency of logger mechanism.
Change by Emanuel Barry : -- Removed message: https://bugs.python.org/msg316153 ___ Python tracker <https://bugs.python.org/issue33423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33423] [logging] Improve consistency of logger mechanism.
Emanuel Barry added the comment: You don't have access to this feature, so I've deleted the message for you :) -- nosy: +ebarry ___ Python tracker <https://bugs.python.org/issue33423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31952] Weird behavior on tupple item assignment
Emanuel Barry added the comment: This is a known issue, and is properly explained here: https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works -- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33892] doc Add a couple of "or she/her"
Emanuel Barry added the comment: Nice initiative! I like the idea of moving towards more inclusive documentation; as an addition, I would recommend using they/them/their instead - it's less clumsy to read (also, singular they is perfectly valid English) and includes everyone, even those who may not use either he/him or she/her pronouns :) All in all, great initiative, I encourage you to keep going in that direction! -- nosy: +ebarry ___ Python tracker <https://bugs.python.org/issue33892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
New submission from Kevin Barry : I have been trying to get PyRun_InteractiveLoop to run on a pty (Linux) without replacing stdin and stdout with that pty; however, it seems like Python (2.6.6) is hard-coded to only run interactively on stdin and stdout. Compile the attached program with: > gcc `python-config --cflags` working.c -o working `python-config --ldflags` and run it with: > ./working xterm -S/0 and you should see that there is no interactivity in the xterm that's opened. Compile the attached file with: > gcc -DREADLINE_HACK `python-config --cflags` working.c -o working > `python-config --ldflags` -lreadline -lcurses and run it with: > ./working xterm -S/0 to see how it runs with my best attempt to get it to function properly with a readline hack. Additionally, try running: > ./working xterm -S/0 > /dev/null > ./working xterm -S/0 < /dev/null both of which should cause interactivity in the xterm to fail, indicating that Python is checking stdin/stdout for tty status when determining if it should run interactively (i.e. it's not checking the tty status of the file passed to PyRun_InteractiveLoop.) Am I somehow using this function wrong? I've been trying to work around this problem for a while, and I don't think I should be using readline hacks (especially since they don't port to other OSes with ptys, e.g. OS X.) I even tried to patch the call to PyOS_Readline in tok_nextc (Parser/tokenizer.c) to use tok->fp instead of stdin/stdout, which caused I/O to use the pty but it still failed to make interactivity work. Thanks! Kevin Barry -- components: Interpreter Core, Library (Lib) files: working.c messages: 161586 nosy: Kevin.Barry priority: normal severity: normal status: open title: PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file25706/working.c ___ Python tracker <http://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment:
Here is a patch that corrects the problem (quoted below and attached.) This
only corrects the problem when 'PyOS_ReadlineFunctionPointer' is set, e.g. you
must 'import readline', otherwise Python will defer to stdin/stdout with
'PyOS_StdioReadline'.
The patch:
--- Python-2.6.8/Parser/tokenizer.c 2012-04-10 11:32:11.0 -0400
+++ Python-2.6.8-patched/Parser/tokenizer.c 2012-07-23 19:56:39.645992101
-0400
@@ -805,7 +805,7 @@
return Py_CHARMASK(*tok->cur++);
}
if (tok->prompt != NULL) {
-char *newtok = PyOS_Readline(stdin, stdout, tok->prompt);
+char *newtok = PyOS_Readline(tok->fp? tok->fp : stdin, tok->fp?
tok->fp : stdout, tok->prompt);
if (tok->nextprompt != NULL)
tok->prompt = tok->nextprompt;
if (newtok == NULL)
Kevin Barry
--
keywords: +patch
status: open -> pending
Added file:
http://bugs.python.org/file26491/Python-2.6.8-Run_Interactive-fix.patch
___
Python tracker
<http://bugs.python.org/issue14916>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment: I've attached a new example source file to demonstrate the fix. Compile the attached program with (*after* patching and installing Python): > gcc `python-config --cflags` working2.c -o working2 `python-config --ldflags` and run it with: > ./working2 xterm -S/0 < /dev/null > /dev/null (The redirection shows that it works when stdin/stdout aren't a tty.) I looked at the most-recent revision of tokenizer.c (http://hg.python.org/cpython/file/52032b13243e/Parser/tokenizer.c) and see that the change in my patch above hasn't been made already. Kevin Barry -- status: pending -> open Added file: http://bugs.python.org/file26492/working2.c ___ Python tracker <http://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment:
The patch from before needed a slight modification for when Python actually
defaults to an interactive session on stdin. Since I rebuild this for my
current distro (Slackware64 13.37,) I switched to the Python 2.6.6 source. This
might not be the proper way to handle the default case (e.g. 'Py_Main'), but
it's a start.
The patch (also attached):
--- ./Parser/tokenizer.c.orig 2012-07-23 22:24:56.513992301 -0400
+++ ./Parser/tokenizer.c2012-07-23 22:23:24.329992167 -0400
@@ -805,7 +805,7 @@
return Py_CHARMASK(*tok->cur++);
}
if (tok->prompt != NULL) {
-char *newtok = PyOS_Readline(stdin, stdout, tok->prompt);
+char *newtok = PyOS_Readline(tok->fp? tok->fp : stdin, (tok->fp &&
tok->fp != stdin)? tok->fp : stdout, tok->prompt);
if (tok->nextprompt != NULL)
tok->prompt = tok->nextprompt;
if (newtok == NULL)
Kevin Barry
--
Added file:
http://bugs.python.org/file26501/Python-2.6.6-Run_Interactive-fix.patch
___
Python tracker
<http://bugs.python.org/issue14916>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment: I've attached a simplified example program (working3.c) that demonstrates both the original problem and that the patch (Python-2.6.6-Run_Interactive-fix.patch) works. It eliminates the need for a pty, 'xterm', and redirection. Compile the attached program with: > gcc `python-config --cflags` working3.c -o working3 `python-config --ldflags` and run it with (before and after patching): > ./working3 Also, for verification, run 'python' with no arguments to show that default interactivity is preserved. Kevin Barry -- Added file: http://bugs.python.org/file26503/working3.c ___ Python tracker <http://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16051] Documentation missing pipes.quote()
New submission from Barry Morrison:
Documentation here: http://docs.python.org/library/pipes.html makes no mention
of quote()
But the link to Source code: Lib/pipes.py
http://hg.python.org/cpython/file/2.7/Lib/pipes.py has:
267 def quote(file):
268 """Return a shell-escaped version of the file string."""
269 for c in file:
270 if c not in _safechars:
271 break
272 else:
273 if not file:
274 return "''"
275 return file
276 # use single quotes, and put single quotes into double quotes
277 # the string $'b is then quoted as '$'"'"'b'
278 return "'" + file.replace("'", "'\"'\"'") + "'"
First _ever_ bug report, apologies if this is incorrect.
--
assignee: docs@python
components: Documentation
messages: 171326
nosy: Barry.Morrison, docs@python
priority: normal
severity: normal
status: open
title: Documentation missing pipes.quote()
type: enhancement
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue16051>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment: I still see the potential cause addressed by my patch in the 2.7, 3.3, and "default" branches, so I'm assuming that all versions from 2.6 on have this problem. I also see that I can elect to change the "Status" and "Resolution" of this report. Does that mean I need to do something besides wait for someone involved in the project to look at my patch? Kevin Barry -- versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28797] Modifying class __dict__ inside __set_name__
Emanuel Barry added the comment: Ow! I can confirm the bug still happens on latest trunk. Nice finding! -- nosy: +ebarry, ned.deily, rhettinger, serhiy.storchaka priority: normal -> release blocker stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue28797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28797] Modifying class __dict__ inside __set_name__
Changes by Emanuel Barry : -- nosy: +Martin.Teichmann ___ Python tracker <http://bugs.python.org/issue28797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28828] Connection reset by peer error when installing python packages
Emanuel Barry added the comment: Decorater: For very large projects, the switch from Python 2 to 3 is a non-trivial task that can take up years of work, and there are many reasons why one cannot switch. On the issue, however, for all PyPi-related issues, please go to the PyPa GitHub: https://github.com/pypa/pypi-legacy/ -- nosy: +ebarry resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue28828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10444] A mechanism is needed to override waiting for Python threads to finish
Emanuel Barry added the comment: Let's just close this. -- nosy: +ebarry resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue10444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23722] During metaclass.__init__, super() of the constructed class does not work
Changes by Emanuel Barry : -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue23722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28866] Unexpected behavior resulting from mro() and __setattr__ in interactive mode
Emanuel Barry added the comment: Additionally, trying to access an attribute before assigning it will result in an AttributeError on all subsequent accesses (even if set). I didn't manage to get a segfault, however. -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue28866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28868] Python advertising BeOpen.com domain
Emanuel Barry added the comment: Part of the copyright notice, as SilentGhost mentioned. This can't be removed. -- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue28868> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call
Emanuel Barry added the comment: As a matter of fact, A.__module__ in this case is abc.ABCMeta.__module__. A class body creates a __module__ key, while a direct metaclass call does not. -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue28869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call
Emanuel Barry added the comment: Oh, nicely spotted! Apparently I was wrong, and it does create a key; defaulting to __name__. About the original issue, I don't think it's easily possible to fix, sadly. -- ___ Python tracker <http://bugs.python.org/issue28869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment:
I understand the feeling. However, in a project I maintain, we want the other
way around - to be able to never have an empty list, even if the string is
empty (we resorted to using re.split in the end, which has this behaviour).
Consider:
rest = re.split(" +", rest)[0].strip()
This gives us None-like behaviour in splitting, at the cost of not actually
using str.split.
I'm +1 on the idea, but I'd like some way to better generalize str.split use
(not everyone knows you can pass None and/or an integer).
(At the same time, the counter arguments where str has too many methods, or
that methods shouldn't do too much, also apply here.)
But I don't like bikeshedding too much, so let's just count me as +1 for your
way, if there's no strong momentum for mine :)
--
nosy: +ebarry
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Changing the behaviour when sep is None is a big backwards-compatibility break, and I'm not sure we'd even want that. It's logical to allow passing None to mean the same thing as NULL (i.e. no arguments), and the behaviour in that case has been like that for... well, long enough that changing it isn't really feasible. I agree with Barry here, especially since this is a completely opt-in feature, and existing behaviour isn't changed without the user's knowledge. -- ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: That would work for my case, but it wouldn't for Barry's (unless I missed something). He wants a non-None argument to not leave empty strings, but I want a None argument to leave empty strings... I don't think there's a one-size-fits-all solution in this case, but feel free to prove me wrong :) -- ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Actually, there might be a way. We could make prune default to True if sep is None, and default to False if sep is not None. That way, we get to keep the existing behaviour for either case, while satisfying both of our use cases :) If that's a bad idea (and it quite probably is), I'll retract it. But it's an interesting possibility to at least consider. -- ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Matthew: Yes, that's exactly the way I was going about it. Thank you Raymond for your comments (and your informative answer on that SO question). I think that part of the problem is that no delimiter (or None) behaves differently than with a delimiter. If we wanted proper consistency, we would have needed to make passing None (or nothing) the same as passing whitespace, but alas, we have to work with what we have. As you said, API complexity is a concern that needs to be addressed. I think that the most important part is how it's documented, and, if phrased correctly (which is non-trivial), could actually simplify the explanation. Consider this draft: *** The value of the `prune` keyword argument determines whether or not consecutive delimiters should be grouped together. If `prune` is not given or None, it defaults to True if sep is None or not given, and False otherwise. If `prune` is True, consecutive delimiters (all whitespace if None or not given) are regarded as a single separator, and the result will not contain any empty string. The resulting list may be empty. Otherwise, if `prune` is False, consecutive delimiters are not grouped together, and the result may contain one or more empty string. The resulting list will never be empty. *** I may be oversimplifying this, but it seems to me that this might help some people by hopefully streamlining the explanation. This still doesn't solve the issue where a user can't say "split on a space or a tab, but not newlines", which IMO is lacking in the design, but that may be for another issue ;) I've wrapped up a basic patch which probably doesn't work at all; I'll put it up when it's at least partly working for everyone to look at. -- ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Here's an initial patch. It works exactly as discussed earlier, doesn't break any tests, and retains full backwards compatibility. No doc changes (except for the docstrings of str.[r]split) and no tests, as this is just a preliminary patch to see if there's any merit to the idea. -- keywords: +patch stage: -> test needed Added file: http://bugs.python.org/file45853/split_prune_1.patch ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Yes, I agree that being able to pass in a tuple would be really useful. As far as rolling out a custom function goes, I'd sooner reach for re.split than do that, so I don't really have a strong argument for either side. Feel free to play with the patch or make an entirely new one, though! I mainly submitted the patch to keep the discussion going, and eventually come to a concensus, but I don't have a strong opinion either way :) -- ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Changes by Emanuel Barry : Removed file: http://bugs.python.org/file45853/split_prune_1.patch ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Emanuel Barry added the comment: Barry: Sure, the docs example was just a quick write-up, you can word it however you want! Guido: Pretty much, except the other way around (when prune is False, i.e. "don't remove empty strings"). The attached patch exposes the behaviour (it's identical to last night's, but I'm re-uploading it as an unrelated file went in), except that the `prune` argument isn't keyword-only (I didn't know how to do this, and didn't bother searching for just a proof-of-concept). -- Added file: http://bugs.python.org/file45863/split_prune_1.patch ___ Python tracker <http://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28961] unittest.mock._Call ignores `name` parameter
Emanuel Barry added the comment: That indeed looks like a bug. Well spotted :) That code has been there since unittest.mock was added back in March 2012. If I were to guess, I'd say that it should be `if name is None: name = ''`. Care to submit a patch? -- nosy: +ebarry, michael.foord stage: -> needs patch title: Is it a bug(method `_Call.__new__` in unittest.mock)? -> unittest.mock._Call ignores `name` parameter type: enhancement -> behavior versions: +Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue28961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28961] unittest.mock._Call ignores `name` parameter
Changes by Emanuel Barry : -- stage: needs patch -> commit review ___ Python tracker <http://bugs.python.org/issue28961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't documented
Emanuel Barry added the comment: LGTM. Thanks for the patch! -- nosy: +ebarry stage: -> commit review ___ Python tracker <http://bugs.python.org/issue28794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27135] nested list produced with multiplication is linked to the same list
Emanuel Barry added the comment: The reason why Python behaves like that in this case is a side-effect of the way the data model is implemented. Lists are a mutable data type, which means that referencing the same list - which is what you are doing - as opposed to creating a new one each time, does exactly what is expected of the data model, which is to keep a reference to the original list. Consider: x = ?? y = x The object bound to `y` refers to the same object as the one bound to `x`, such that `x is y`, for every possible value of `x`. As `=` is the assignment operator (and not the copy operator, is such a thing existed), `y` merely has a reference to `x`. There are very valid use cases where you will want to get a reference to the original list to modify it, for example in a function that is meant to alter the original. If you want a copy, use `l[:]` (or `l.copy()` in more recent versions). In Python, every object and operation is evaluated once, when the interpreter comes across it (in a for or while loop, it will come over the same point multiple times, so it will evaluate it multiple times). By doing: [[x] * y] * n You are essentially doing this: l_1 = [x] # one-element list l_2 = l_1 * y # list with `y` times `x` in it (references to `x`, not copies) l_3 = [l_2] # a new list with one element, `l_2` l_4 = l_3 * n # list with `n` times `l_3` in it (references to `l_3`, not copies) As you can see, it makes no sense to have multiple different lists by doing that. Doing a list comprehension, such as: [[None] * n for _ in range(N)] Will evaluate a new list each time the interpreter comes across it, which will be N times for this case. Thus, you get a different list everytime. In other words, the reason that "That's just how it works" is because this behaviour is a side-effect, not something that's out of the way. Creating a new special case for this particular case seems like a very big stretch. Remember, "Special cases aren't special enough to break the rules." This change that is "seemingly trivial" to you is actually asking to break the Python semantics in some weird and convoluted way, for no gain since we have list comprehensions (that you seem to already be acquainted with). Did that seem like a sufficient answer? ;-) -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue27135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27137] functools.partial: Inconsistency between Python and C implementations
New submission from Emanuel Barry: functools.partial is a class in C, but the Python implementation is a function. This doesn't matter for most use cases where you only want the end result of the call to partial. A simple line in the REPL tells me enough (or so I thought) that I wouldn't need to check the implementation: >>> functools.partial Oh, it's a class, which means I can subclass it to add a custom repr for my needs. Unsurprisingly, it works. It may not be the best idea to subclass something that is meant to be final, but I'm simply overriding a single method, what could possibly go wrong? Besides one of the implementations not actually being a class. I'm suggesting to make the Python implementation also a class, for consistency and making sure that both the C and Python implementation match, in case someone else wants to do that too. The documentation ( https://docs.python.org/3/library/functools.html#functools.partial ) doesn't state that the Python and C implementations differ, but IMO this isn't a documentation bug. I haven't written a patch yet, will probably be done by tomorrow. Note: I haven't actually encountered this issue, but I suspect that it might arise if someone doesn't have access to _functools for whatever reason. And IMO, Python and C implementations of a feature should be fully equivalent (modulo implementation details à la OrderedDict.__root). Thoughts? -- components: Library (Lib) messages: 266503 nosy: ebarry, ncoghlan, rhettinger priority: normal severity: normal stage: needs patch status: open title: functools.partial: Inconsistency between Python and C implementations type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue27137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27135] nested list produced with multiplication is linked to the same list
Emanuel Barry added the comment:
You do raise a valid point, sequence repetition (*) on lists of mutable objects
serves very little purpose. However, as I stated, it is a side-effect of the
data model and changing it would be yet another special case, which aren't
special enough to break the rules, and this applies here.
Keep in mind that, currently, this is only confusing to newbies. Your idea
would make this confusing for long-time Python programmers.
If you still wish to propose such a change, I recommend to take this to the
Python-ideas mailing list (point to this issue in your email). Be warned though
that most core developers (and most non-core devs such as myself) will probably
prefer the statu quo, again because the change would be yet another special
case, and probably view this as an attractive nuisance ("Why does [[x] * y] * n
create separate lists but x = y = [] refer to the same list?").
--
___
Python tracker
<http://bugs.python.org/issue27135>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27137] functools.partial: Inconsistency between Python and C implementations
Emanuel Barry added the comment: Attached patch turns the Python implementation of functools.partial into a class. The implementation is as close to the C version as possible, except __repr__ where I went for a different, more Pythonic approach (output is identical). I haven't yet added tests for this, and I had to fix something (because some errors occur if _functools is not present and that's the only way I know to make the tests run against the Python implementation). One test fails with the patch (and sys.modules["_functools"] = None): ...E == ERROR: test_pickle (test.test_functools.TestPartialC) -- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_functools.py", line 224, in test_pickle f_copy = pickle.loads(pickle.dumps(f, proto)) _pickle.PicklingError: Can't pickle : it's not the sa me object as functools.partial -- Ran 148 tests in 0.216s FAILED (errors=1) I'll try to see what kind of tests I can add to this to reliably test both 'partial' implementations. I'll also see what I can do about that one failing test. Oddly enough, there seems to be a test for subclassing '_functools.partial', which I might extend. Raymond, what do you think? -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43035/functools_partial_1.patch ___ Python tracker <http://bugs.python.org/issue27137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27137] functools.partial: Inconsistency between Python and C implementations
Emanuel Barry added the comment: Serhiy, it seems as though _functools is always required for functools to work - heck, tests start to fail all over the place if it isn't available, because functools.reduce doesn't exist. Subclassing _functools.partial is already tested for, so I wouldn't qualify it as an implementation detail myself. Moreover, I feel that we should try to (somewhat) keep both implementations identical - or close enough. It seems that _pickle checks for _functools.partial, and that trying to pickle the pure Python version triggers the error in msg266530. This probably doesn't matter for most (if not all) of cases where CPython is concerned. But I care about the ability for alternate implementations to work the same way. Compromise: rename the current partial function to partial_func and keep it around ;-) -- ___ Python tracker <http://bugs.python.org/issue27137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27137] functools.partial: Inconsistency between Python and C implementations
Emanuel Barry added the comment: Functionally, both versions are equivalent, but one is a class and the other is not. From PEP 399: "Technical details of the VM providing the accelerated code are allowed to differ as necessary, e.g., a class being a `type` when implemented in C." It clearly states that it's an implementation detail. I've been beaten! However, the next paragraph also says this: "Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code." I think this contradicts itself, since IMO an object being a type is part of the public API (but obviously this thought isn't universal). Whatever happens with the pure Python implementation, shouldn't the PEP be clarified on that point? -- ___ Python tracker <http://bugs.python.org/issue27137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Changes by Emanuel Barry : -- Removed message: http://bugs.python.org/msg266608 ___ Python tracker <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Changes by Emanuel Barry : -- Removed message: http://bugs.python.org/msg266607 ___ Python tracker <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27155] '-' sign typo in example
Emanuel Barry added the comment: A negative return code generally means an error occurred. Negating retcode here is equivalent to abs(retcode), which shows you want a positive integer to appear in the message - it's not an error. Could replace '-retcode' with 'abs(retcode)' to be more clear. Possibly also add a comment in the code example body to further clarify this. -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue27155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type
Emanuel Barry added the comment: Works for me: >>> class X(type): pass ... >>> X(X) -- nosy: +ebarry resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27158] `isinstance` function does not handle types that are their own type
Emanuel Barry added the comment: Works for me: >>> class meta(type): pass ... >>> class X(type, metaclass=meta): pass ... >>> X.__class__ = X >>> type(X) is X True >>> isinstance(X, X) True -- nosy: +ebarry resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue27158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27158] `isinstance` function does not handle types that are their own type
Emanuel Barry added the comment: This seems as though you might be using an older version of the interpreter (I tested in 3.4.3, 3.5.1 and 3.6.0a1+). Where did you get your interpreter? The official releases are on https://www.python.org/downloads/ - if you got it somewhere else, that might be something for whoever packaged your installer to fix. -- ___ Python tracker <http://bugs.python.org/issue27158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: In Objects/typeobject.c#L2290, the code checks that the (meta?)class is exactly `type` and that there's one argument, then returns `Py_TYPE(x)`. Subclasses of `type` allowing a single argument is a side-effect of not overriding __new__, not a documented feature. Changing the call from `PyType_CheckExact` to `PyType_Check` makes it work, but I'm assuming there may be something I didn't think of. Or maybe there isn't, but either way, I don't consider that this is worth fixing -- if you want to call your subclass with only one argument, override __new__ and do the logic in there. And if you want the type of an object, use type directly. Also, there may be performance concerns here. `type` is heavily optimized in many places; I thought that `PyType_Check` called Python code, but after checking the macro definitions and testing a bit, it turns out I'm wrong. But if there *is* a negative performance impact, this probably can't go in -- this check runs everytime that type() is called, no matter how many arguments, and including in class creation; that's also probably why `PyType_CheckExact` was chosen to begin with. -- ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: Yes, that would be preferable. The error message is at Objects/typeobject.c#l2301, but keep in mind that this message is shown for both faulty calls to type() as well as any of its subclasses that don't override __new__, and I'm lukewarm on adding e.g. a PyType_Check call before that; might as well replace the PyType_CheckExact call and make this work. I'm not knowledgeable enough in that field though, you'll need a core dev's advice. -- stage: resolved -> ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: +1. I prefer that change, as using subclasses of `type` as if they were type itself never made sense to me. This shouldn't break existing code, but if it does, it was either a concealed bug or a very bad idea to begin with, and should be fixed either way. Attached patch implements Eryk's suggestion. I haven't found any tests that checked for subclasses of type specifically (except tests testing for metaclass stuff), and I haven't added any either. -- keywords: +patch stage: -> needs patch Added file: http://bugs.python.org/file43054/type_one_argument_1.patch ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Changes by Emanuel Barry : -- stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: Yes, `metatype == &PyType_Type` makes sure that only `type` itself is valid for the one-argument part, whereas subclasses can also do so right now. I clarified that in a comment in the new patch, so that someone doesn't accidentally revert this, thinking PyType_CheckExact is fine. Before the patch: >>> type(1, 2, 3) Traceback (most recent call last): File "", line 1, in TypeError: type() argument 1 must be str, not int After the patch: >>> type(1, 2, 3) Traceback (most recent call last): File "", line 1, in TypeError: type.__new__() argument 1 must be str, not int >>> class X(type): pass ... >>> X(1) Traceback (most recent call last): File "", line 1, in TypeError: type.__new__() argument 1 must be str, not int -- Added file: http://bugs.python.org/file43056/type_one_argument_2.patch ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27160] str.format: Silent truncation of kwargs when passing keywords containing colons
Changes by Emanuel Barry : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue27160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27160] str.format: Silent truncation of kwargs when passing keywords containing colons
Emanuel Barry added the comment: In other words, you cannot use keys containing a colon in str.format - you'll need to replace the colons by something else (for example an underscore, that works fine). -- nosy: +ebarry ___ Python tracker <http://bugs.python.org/issue27160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27137] Python implementation of `functools.partial` is not a class
Emanuel Barry added the comment: New patch after Serhiy's comments. I kept the __dict__ in pickling to properly pickle attributes that aren't defined by 'partial' itself; but if 'func', 'args' or 'keywords' are present and don't match the provided arguments, an error will be raised, as it should not be partial's responsibility to handle this; this is for the caller to do. -- Added file: http://bugs.python.org/file43059/functools_partial_2.patch ___ Python tracker <http://bugs.python.org/issue27137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: Fair enough. Should this get a note in What's new? Possibly in the "Changes in Python API" section. -- stage: patch review -> commit review versions: +Python 3.6 -Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27160] str.format: Silent truncation of kwargs when passing keywords containing colons
Emanuel Barry added the comment:
The behaviour is correct, it's your assumptions that aren't :)
The code for str.format only checks for what's before the colon (here, "HGNC")
and checks if that's part of the dict provided. It isn't, so it raises a
KeyError. It doesn't even get to the format spec part (which is a perfectly
valid format specifier). Your dict can contain anything or be empty, str.format
only checks for the existence of the key you asked for ("HGNC"). "{HGNC:11892}"
is also a perfectly valid Python string.
P.S.: While I'm fine with people calling me by my last name, there's another
developer whose name is Barry Warsaw, so let's try to avoid confusion here ;-)
--
___
Python tracker
<http://bugs.python.org/issue27160>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: Let me just make sure I got you right - you're fine with `type` and only `type` being able to use the one-argument form in 3.6, but prefer 3.5 and 2.7 to be even more permissive than they currently are? Regardless, I don't think this should go into a bugfix release. -- ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Changes by Emanuel Barry : -- Removed message: http://bugs.python.org/msg266711 ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: New patch with tests and documentation. I didn't really know where to put the tests; test_types seemed reasonable to me (other option was test_metaclass). -- stage: test needed -> commit review ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Changes by Emanuel Barry : Added file: http://bugs.python.org/file43060/type_one_argument_3.patch ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass
Emanuel Barry added the comment: New patch with Berker's comments. I'm really not used to Sphinx markup so thanks for that! > Is there any person who really thinks that their own patch is *not* ready for > commit review? :) Partial patches aren't that uncommon in some projects. I also sometimes don't trust that I got everything right (especially if it's in a very large codebase like CPython), and having a few more pair of eyes taking a look at it helps. -- Added file: http://bugs.python.org/file43062/type_one_argument_4.patch ___ Python tracker <http://bugs.python.org/issue27157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27166] interesting info
Changes by Emanuel Barry : -- Removed message: http://bugs.python.org/msg266751 ___ Python tracker <http://bugs.python.org/issue27166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27166] interesting info
Changes by Emanuel Barry : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue27166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21271] reset_mock needs parameters to also reset return_value and side_effect
Changes by Emanuel Barry : -- resolution: -> fixed stage: patch review -> resolved ___ Python tracker <http://bugs.python.org/issue21271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27192] Keyboard Shortcuts Consistently Cause Crashes
Changes by Emanuel Barry : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Tkinter Unresponsive With Special Keys ___ Python tracker <http://bugs.python.org/issue27192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27193] Tkinter Unresponsive With Special Keys
Changes by Emanuel Barry : -- components: +Extension Modules stage: -> needs patch type: -> behavior ___ Python tracker <http://bugs.python.org/issue27193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25548] Show the address in the repr for class objects
Emanuel Barry added the comment: I'd probably change all instances of ".*" in the regex matches to be "0x.+" instead. For the docstrings that have "..." in them, I would probably make those " at ..." as well (although you get decide if it hinders readability too much). Other than that patch LGTM. -- nosy: +ebarry stage: -> patch review ___ Python tracker <http://bugs.python.org/issue25548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
