[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: Thanks for the quick reply. On both Ubuntu and Centos, I’m installing Python using Pyenv, testing with 3.9.10 and 3.10.2. Pyenv provides a verbose install flag, I can rebuild the Python versions and review the build commands, if helpful? I’m testing with clean Linux distributions and I believe there is only one OpenSSL installed and available. I don’t know if it’s possible to gain more details from the Python ssl module to confirm? I did confirm the OpenSSL versions aligns using ssl.OPENSSL_VERSION. Command: pyenv install 3.10.2 --verbose https://github.com/pyenv/pyenv -- ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: I found the Python build recipes and Pyenv does appear to install OpenSSL from source. The only difference I can see, aside from the Python version, is an update on the OpenSSL versions; openssl-1.1.1l (3.9.10) to openssl-1.1.1k (3.10.2). The OpenSSL release notes do not appear to suggest anything relevant. https://github.com/pyenv/pyenv/blob/master/plugins/python-build/share/python-build/3.10.2 https://github.com/pyenv/pyenv/blob/master/plugins/python-build/share/python-build/3.9.10 https://github.com/pyenv/pyenv/blob/master/plugins/python-build/bin/python-build https://www.openssl.org/news/openssl-1.1.1-notes.html -- ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: Yes agreed, it may well be a Pyenv issue. Interestingly we can demonstrate that the global OpenSSL crypto policies is respected with the 3.9.10 version, through adjusting the policy. The ssl error occurs with the default policy setting and is resolved with the legacy policy setting. With 3.10.2 this is no longer the case. I can’t see any obvious changes to the build recipe that would cause this. -- ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: Update, the Pyenv team confirmed that they do not install OpenSSL in linux, its only installed for MacOS, and it should be built using the system OpenSSL within Linux. We're investigating further to attempt to debug the issue. Interestingly the OpenSSL build flags for both Python versions appear to be the same. `Trying link with OPENSSL_LDFLAGS=; OPENSSL_LIBS=-lssl -lcrypto; OPENSSL_INCLUDES=` I've attached the build logs for both the Python 3.9.10 and 3.10.2 build, in case you're able to review. Many thanks. https://github.com/pyenv/pyenv/issues/2257 -- Added file: https://bugs.python.org/file50653/python_builds.tar.gz ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: Many thanks Christian, see the attached for the output of the commands on Python 3.9.10 and 3.10.2, along with a diff removing version numbers and memory addresses. I've run the commands on the Ubuntu distribution, we can also run the same for the Centos VM, if helpful. There are a few differences in the outputs but nothing that appears obviously the cause. -- Added file: https://bugs.python.org/file50654/python_details.tar.gz ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
Adam added the comment: Many thanks Christian, that resolved the issue! I really appreciate your efforts here. -- ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12973] int_pow() implementation is incorrect
New submission from Adam : int_pow() (from Objects/intobject.c) shows incorrect results when Python is compiled with Clang (llvm.org); long story short: int_pow() function should use 'unsigned long' type instead of 'long' or some code gets optimised out. Please, refer to this bug report to find out the details: http://llvm.org/bugs/show_bug.cgi?id=10923 -- messages: 143985 nosy: a...@netbsd.org priority: normal severity: normal status: open title: int_pow() implementation is incorrect type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3490] Example Code Error in Tutorial Documentation
New submission from Adam <[EMAIL PROTECTED]>: In section 4.4 of the Python Tutorial (http://docs.python.org/tut/node6.html) there is a code example using prime numbers that results extraneous output. The else is incorrectly indented one tab too far to the right and is nested under (for x in range) rather than (for n in range). Current: >>> for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... Correct: >>> for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... -- assignee: georg.brandl components: Documentation messages: 70613 nosy: georg.brandl, yoshokun severity: normal status: open title: Example Code Error in Tutorial Documentation ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3490] Example Code Error in Tutorial Documentation
Adam <[EMAIL PROTECTED]> added the comment: You know what, you're absolutely right. My apologies for sending the bad submission. =\ ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41395] pickle and pickletools cli interface doesn't close input and output file.
Change by Adam : -- nosy: +achhina nosy_count: 7.0 -> 8.0 pull_requests: +30326 pull_request: https://github.com/python/cpython/pull/32257 ___ Python tracker <https://bugs.python.org/issue41395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41395] pickle and pickletools cli interface doesn't close input and output file.
Adam added the comment: Hi, First-time contributor here, I've made a patch in follow-up to the discussions that happened in Amir's patch in regards to this. I'd appreciate it if someone would be able to take a look and review it! https://github.com/python/cpython/pull/32257 -- ___ Python tracker <https://bugs.python.org/issue41395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43486] Python 3.9 installer not updating ARP table
New submission from Adam : 1. Install 3.9.0 using the following command line options: python-3.9.0.exe /quiet InstallAllUsers=1 2. Install 3.9.2 using the following command line options: python-3.9.2.exe /quiet InstallAllUsers=1 3. Observe that 3.9.2 successfully installed, however the ARP table does not reflect the latest version (see first screenshot in the attachment) it still shows 3.9.0 as installed. 4. Uninstall 3.9.2 using the following command line options: python-3.9.2.exe /uninstall /silent 5. Observe that Python 3.9.0 is still listed as installed in the ARP table. Looking in the registry, all Python installed products are removed except for Python Launcher. Maybe it is by design to leave Python Launcher on the system, maybe not, but I think keeping the ARP table tidy would reduce confusion for users. See second screenshot in the attachment. -- components: Installation files: 1.jpg messages: 388615 nosy: codaamok priority: normal severity: normal status: open title: Python 3.9 installer not updating ARP table type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49873/1.jpg ___ Python tracker <https://bugs.python.org/issue43486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43486] Python 3.9 installer not updating ARP table
Adam added the comment: The 64 installer doesn't even show up in the ARP table, only Python Launcher. -- ___ Python tracker <https://bugs.python.org/issue43486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39074] Threading memory leak in _shutdown_locks for non-daemon threads
New submission from Adam :
When running 3.7, we noticed a memory leak in threading._shutdown_locks when
non-deamon threads are started but "join()" or "is_alive()" is never called.
Here's a test to illustrate the growth:
=
import threading
import time
import tracemalloc
def test_leaking_locks():
tracemalloc.start(10)
snap1 = tracemalloc.take_snapshot()
def print_things():
print('.', end='')
for x in range(500):
t = threading.Thread(target=print_things)
t.start()
time.sleep(5)
print('')
gc.collect()
snap2 = tracemalloc.take_snapshot()
filters = []
for stat in
snap2.filter_traces(filters).compare_to(snap1.filter_traces(filters),
'traceback')[:10]:
print("New Bytes: {}\tTotal Bytes {}\tNew blocks: {}\tTotal blocks: {}:
".format(stat.size_diff, stat.size, stat.count_diff ,stat.count))
for line in stat.traceback.format():
print(line)
=
=
Output in v3.6.8:
New Bytes: 840 Total Bytes 840 New blocks: 1 Total blocks: 1:
File "/usr/local/lib/python3.6/threading.py", line 884
self._bootstrap_inner()
New Bytes: 608 Total Bytes 608 New blocks: 4 Total blocks: 4:
File "/usr/local/lib/python3.6/tracemalloc.py", line 387
self.traces = _Traces(traces)
File "/usr/local/lib/python3.6/tracemalloc.py", line 524
return Snapshot(traces, traceback_limit)
File "/gems/tests/integration/endpoint_connection_test.py", line 856
snap1 = tracemalloc.take_snapshot()
File "/usr/local/lib/python3.6/site-packages/_pytest/python.py", line 198
testfunction(**testargs)
File "/usr/local/lib/python3.6/site-packages/pluggy/callers.py", line 187
res = hook_impl.function(*args)
File "/usr/local/lib/python3.6/site-packages/pluggy/manager.py", line 87
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
File "/usr/local/lib/python3.6/site-packages/pluggy/manager.py", line 93
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/local/lib/python3.6/site-packages/pluggy/hooks.py", line 286
return self._hookexec(self, self.get_hookimpls(), kwargs)
File "/usr/local/lib/python3.6/site-packages/_pytest/python.py", line 1459
self.ihook.pytest_pyfunc_call(pyfuncitem=self)
File "/usr/local/lib/python3.6/site-packages/_pytest/runner.py", line 111
item.runtest()
==
Output in v3.7.4:
New Bytes: 36000Total Bytes 36000 New blocks: 1000Total
blocks: 1000:
File "/usr/local/lib/python3.7/threading.py", line 890
self._bootstrap_inner()
File "/usr/local/lib/python3.7/threading.py", line 914
self._set_tstate_lock()
File "/usr/local/lib/python3.7/threading.py", line 904
self._tstate_lock = _set_sentinel()
New Bytes: 32768Total Bytes 32768 New blocks: 1 Total blocks:
1:
File "/usr/local/lib/python3.7/threading.py", line 890
self._bootstrap_inner()
File "/usr/local/lib/python3.7/threading.py", line 914
self._set_tstate_lock()
File "/usr/local/lib/python3.7/threading.py", line 909
_shutdown_locks.add(self._tstate_lock)
=
It looks like this commit didn't take into account the tstate_lock cleanup that
happens in the C code, and it's not removing the _tstate_lock of completed
threads from the _shutdown_locks once the thread finishes, unless the code
manually calls "join()" or "is_alive()" on the thread:
https://github.com/python/cpython/commit/468e5fec8a2f534f1685d59da3ca4fad425c38dd
Let me know if I can provide more clarity on this!
--
messages: 358551
nosy: krypticus
priority: normal
severity: normal
status: open
title: Threading memory leak in _shutdown_locks for non-daemon threads
type: resource usage
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39074>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39074] Threading memory leak in _shutdown_locks for non-daemon threads
Change by Adam : -- type: resource usage -> security ___ Python tracker <https://bugs.python.org/issue39074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39074] Threading memory leak in _shutdown_locks for non-daemon threads
Adam added the comment: Looks like this issue might be a duplicate of https://bugs.python.org/issue37788 -- ___ Python tracker <https://bugs.python.org/issue39074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak
Adam added the comment: I ran into this bug as well, and opened an issue for it (before I saw this issue): https://bugs.python.org/issue39074 Was there a conclusion on the best way to fix this? It seems like the previous __del__ implementation would correct the resource leakage by removing the _tstate_lock from _shutdown_locks. -- nosy: +krypticus ___ Python tracker <https://bugs.python.org/issue37788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
Adam added the comment: I filed a bug for this a few weeks ago, and then found another ticket about the same issue before: https://bugs.python.org/issue37788 My ticket: https://bugs.python.org/issue39074 The memory leak was from a change introduced about 6 months ago: https://github.com/python/cpython/commit/468e5fec8a2f534f1685d59da3ca4fad425c38dd -- nosy: +krypticus ___ Python tracker <https://bugs.python.org/issue39201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29722] heapq.merge docs don't handle reverse flag well
New submission from Adam: The docs for heapq.merge are a little misleading. Iterables passed into heapq.merge with the reversed flag set to True must be sorted from largest to smallest to achieve the desired sorting effect, but the paragraph describing the function in the general case states that they should be sorted from smallest to largest. -- assignee: docs@python components: Documentation messages: 288997 nosy: adamniederer, docs@python priority: normal pull_requests: 388 severity: normal status: open title: heapq.merge docs don't handle reverse flag well type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29722] heapq.merge docs are misleading with the "reversed" flag
Changes by Adam : -- title: heapq.merge docs don't handle reverse flag well -> heapq.merge docs are misleading with the "reversed" flag ___ Python tracker <http://bugs.python.org/issue29722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31087] asyncio.create_subprocess_* do not honor `encoding`
Adam added the comment: It occurs both on Python 3.6 and 3.7 RC, so maybe it should be fixed in the 3.7 release. -- nosy: +adampl type: -> behavior versions: +Python 3.7 Added file: https://bugs.python.org/file47531/asyncio_encoding_test.py ___ Python tracker <https://bugs.python.org/issue31087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31087] asyncio.create_subprocess_* should honor `encoding`
Adam added the comment: After reading the docs more carefully, it's now plain to me that text encoding is not supported yet, so actually it's not a bug :) However the docs should be improved (and then an assertion could be added too) to prevent people from falling into this trap. Only the `universal_newlines` parameter is explicitly mentioned, while others (including `encoding` and `errors``) are passed to `subprocess.Popen`, which falsely suggests that they should work fine. Moreover, the `std*` properties of the subprocess have a `_transport._pipe.encoding` set to the encoding passed to `asyncio.create_subprocess_*`, but apparently it's not used at all. IMHO this is too messy. Alternatively this option could be implemented, which would require a new kind of StreamReader and StreamWriter. -- title: asyncio.create_subprocess_* do not honor `encoding` -> asyncio.create_subprocess_* should honor `encoding` type: behavior -> enhancement versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue31087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32627] Header dependent _uuid build failure on Fedora 27
Adam added the comment: Some systems might have both uuid.h and uuid/uuid.h. For example, NetBSD provides /usr/include/uuid.h, and one might also install libuuid from a package, and the latter has uuid/uuid.h. To fix this, do not include both files, when both have been detected. Here is a patch: --- Modules/_uuidmodule.c.orig +++ Modules/_uuidmodule.c @@ -3,8 +3,7 @@ #include "Python.h" #ifdef HAVE_UUID_UUID_H #include -#endif -#ifdef HAVE_UUID_H +#elif defined(HAVE_UUID_H) #include #endif -- nosy: +a...@netbsd.org ___ Python tracker <https://bugs.python.org/issue32627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28844] Pickling units
New submission from Adam:
See below code to show you can't round-trip units through pickle:
Python 3.5.1 |Anaconda 4.0.0 (64-bit)| (default, Feb 16 2016, 09:49:46) [MSC
v.1900 64 bit AMD64)]
import units
u = units.unit('myUnit')
x = u(3.0)
import pickle
f = open('C:/temp/what.pkl', 'wb')
pickle.dump(x, f)
f.close()
f = open('C:/temp/what.pkl', 'rb')
y = pickle.load(f)
---
TypeError Traceback (most recent call last)
in ()
> 1 y = pickle.load(f)
TypeError: __new__() missing 2 required positional arguments: 'num' and 'unit'
--
messages: 282099
nosy: abz64
priority: normal
severity: normal
status: open
title: Pickling units
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28844>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23402] dynload_shlib does not close ldl handles when the interpreter is shut down
New submission from Adam: I think dynload_shlib (and maybe some of the other non-ldl dynamic library loaders?) should close the libraries when the interpreter is shut down. Currently the handles are not ever closed and in ldl's case sometimes leaked. The reason I desire this behavior is I have Python opening a shared library that I also open (all within the same process), and I want to be able to reload the library at runtime (via dlclose() + dlopen()) by shutting down the Python interpreter, dlclose()/dlopen(), and re-starting Python on the other side, however having the hanging reference to the library within the interpreter is preventing my dlclose() call from unloading the library. I have attached a patch for dynload_shlib.c that tracks all handles returned by dlopen() and will close them properly when the interpreter is shut down. -- components: Interpreter Core files: python-dlopen.diff keywords: patch messages: 235490 nosy: Adam priority: normal severity: normal status: open title: dynload_shlib does not close ldl handles when the interpreter is shut down type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file38028/python-dlopen.diff ___ Python tracker <http://bugs.python.org/issue23402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24928] mock.patch.dict spoils order of items in collections.OrderedDict
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue24928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue24899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use better HTML and separate CSS
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue10716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24249] unittest API for detecting test failure in cleanup/teardown
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue24249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25041] document AF_PACKET socket address format
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue25041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24821] The optimization of string search can cause pessimization
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue24821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Changes by Adam : -- keywords: +patch Added file: http://bugs.python.org/file40711/unittest-add-gc.patch ___ Python tracker <http://bugs.python.org/issue17908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25344] Enhancement to Logging - Logging Stack
Changes by Adam : -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue25344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25344] Enhancement to Logging - Logging Stack
Changes by Adam : -- nosy: -azsorkin ___ Python tracker <http://bugs.python.org/issue25344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Adam added the comment: Any comments about this proposed patch? -- ___ Python tracker <http://bugs.python.org/issue17908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Adam added the comment: Is this enhancement still open? I've run into this problem previously, and would be more than happy to implement this feature. -- nosy: +azsorkin ___ Python tracker <http://bugs.python.org/issue17908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25834] getpass falls back when sys.stdin is changed
Adam Bartoš added the comment: Sorry, I don't. But my use case is not relevant any more since my package was a workround for problems with entering Unicode interactively on Windows, and these problems were resolved in Python since then. -- ___ Python tracker <https://bugs.python.org/issue25834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45865] Old syntax in unittest
Adam Johnson added the comment: Okay, I updated the PR to only remove inheritance from object. Should I reopen the ticket? (Not sure of the etiquette.) Perhaps I could later submit a second patch for use of `super()`, and so on? -- ___ Python tracker <https://bugs.python.org/issue45865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value
New submission from Adam Ulrich : round(250,-2) returns 200 round(350,-2) returns 400 round(450,-2) returns 400 round(550,-2) returns 600 round(5,-1) returns 0 round(15,-1) returns 20 round(500,-3) returns 0 round(1500,-3) returns 2000 expected: round of 5 to consistently rounds up. -- components: Interpreter Core messages: 411222 nosy: adam.ulrich priority: normal severity: normal status: open title: Rounding 5,50,500 behaves differently depending on preceding value type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46863] Python 3.10 OpenSSL Configuration Issues
New submission from Adam Pinckard : Python 3.10 does not appear to respecting the OpenSSL configuration within linux. Testing completed using Pyenv on both Ubuntu 20.04.4 and Centos-8. Note PEP 644 which requires OpenSSL >= 1.1.1 is released in Python 3.10. We operate behind a corporate proxy / firewall which causes an SSL error where the Diffie-Hellman key size is too small. In previous Python versions this is resolved by updating the OpenSSL configuration, e.g. downgrading the linux crypto policies `sudo update-crypto-policies --set LEGACY`. The issue is reproducible in both Ubuntu 20.04.4 and Centos-8. In both linux distributions the SSL error is resolvable in earlier Python version, using the OpenSSL configurations, but the configuration is not respected with Python 3.10.2. See the details below on the kernel versions, linux distributions, and Openssl versions, many thanks in advance. 1. Python 3.10.2 Error: (py_3_10_2) ➜ py_3_10_2 pip install --upgrade pip WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:997)'))': /simple/pip/ 2. Ubuntu details uname -a Linux Horatio 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.4 LTS Release:20.04 Codename: focal openssl version -a OpenSSL 1.1.1f 31 Mar 2020 built on: Wed Nov 24 13:20:48 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-dnfdFp/openssl-1.1.1f=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific 2. Centos-8 details uname -a Linux localhost.localdomain 5.4.181-1.el8.elrepo.x86_64 #1 SMP Tue Feb 22 10:00:15 EST 2022 x86_64 x86_64 x86_64 GNU/Linux cat /etc/centos-release CentOS Stream release 8 openssl version -a OpenSSL 1.1.1k FIPS 25 Mar 2021 built on: Thu Dec 2 16:40:48 2021 UTC platform: linux-x86_64 options: bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" OPENSSLDIR: "/etc/pki/tls" ENGINESDIR: "/usr/lib64/engines-1.1" Seeding source: os-specific engines: rdrand dynamic -- assignee: christian.heimes components: SSL messages: 414072 nosy: adam, christian.heimes priority: normal severity: normal status: open title: Python 3.10 OpenSSL Configuration Issues type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46873] inspect.getsource with some lambdas in decorators does not get the full source
New submission from Adam Hopkins : I believe the following produces an unexpected behavior: from inspect import getsource def bar(*funcs): def decorator(func): return func return decorator @bar(lambda x: bool(True), lambda x: False) async def foo(): ... print(getsource(foo)) The output shows only the decorator declaration and none of the function: @bar(lambda x: bool(True), lambda x: False) >From my investigation, it seems like this requires the following conditions to >be true: - lambdas are passed in decorator arguments - there is more than one lambda - at least one of the lambdas has a function call Passing the lambdas as default function arguments seems okay: async def foo(bar=[lambda x: bool(True), lambda x: False]): ... A single lambda seems okay: @bar(lambda x: bool(True)) async def foo(): ... Lambdas with no function calls also seem okay: @bar(lambda x: not x, lambda: True) async def foo(): ... Tested this on: - Python 3.10.2 - Python 3.9.9 - Python 3.8.11 - Python 3.7.12 -- messages: 414149 nosy: ahopkins2 priority: normal severity: normal status: open title: inspect.getsource with some lambdas in decorators does not get the full source versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46873] inspect.getsource with some lambdas in decorators does not get the full source
Adam Hopkins added the comment: Sorry about that. I am doing some more digging to see if I can find the route of it and a proposal for a non-breaking patch. The problem seems to be in BlockFinder.tokeneater. -- type: behavior -> versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue46873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46873] inspect.getsource with some lambdas in decorators does not get the full source
Change by Adam Hopkins : -- keywords: +patch pull_requests: +29728 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31605 ___ Python tracker <https://bugs.python.org/issue46873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46873] inspect.getsource with some lambdas in decorators does not get the full source
Adam Hopkins added the comment: Duplicate of https://bugs.python.org/issue38854 Sorry I didn't come across our before submitting. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38854] Decorator with paren tokens in arguments breaks inspect.getsource
Change by Adam Hopkins : -- nosy: +ahopkins nosy_count: 3.0 -> 4.0 pull_requests: +29736 pull_request: https://github.com/python/cpython/pull/31605 ___ Python tracker <https://bugs.python.org/issue38854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1033] Support for newline and encoding in tempfile module
New submission from Adam Hupp: It would be useful for tempfile.TemporaryFile and friends to pass newline and encoding arguments to the underlying io.open call. For example, several tests in test_csv use TemporaryFile and need to handle unicode file output or preserve exact newlines. This is simpler with direct support in TemporaryFile. The attached patch makes the following changes: 1) tempfile.TemporaryFile, NamedTemporaryFile, and SpooledTemporaryFile now pass newline and encoding to the underlying io.open call. 2) test_tempfile is updated 3) test_csv is updated to use the new arguments. -- components: Library (Lib) files: tempfile-newline-encoding.patch messages: 55328 nosy: hupp severity: normal status: open title: Support for newline and encoding in tempfile module type: rfe versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1033> __ tempfile-newline-encoding.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1033] Support for newline and encoding in tempfile module
Adam Hupp added the comment: One change I forgot to mention that may need discussion. I've changed the 'bufsize' arguments in tempfile to 'buffering', since that is consistent with the same change in os.fdopen. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1033> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1089] ever considered adding static typing to python?
Changes by Adam Wieckowski: -- components: Interpreter Core severity: minor status: open title: ever considered adding static typing to python? type: rfe versions: 3rd party __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1089> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1089] ever considered adding static typing to python?
Changes by Adam Wieckowski: -- type: rfe -> __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1089> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1098] decode_unicode doesn't nul-terminate
New submission from Adam Olsen: In the large else branch in decode_unicode (if encoding is not NULL or "iso-8859-1"), the new string it produces is not nul-terminated. This then hits PyUnicode_DecodeUnicodeEscape's octal escape case, which reads past the end of the string (but would stop if there was a nul there.) I found this via valgrind. -- messages: 55630 nosy: rhamphoryncus severity: normal status: open title: decode_unicode doesn't nul-terminate __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1098> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1237] type_new doesn't allocate space for sentinal slot
New submission from Adam Olsen: type_new() allocates the exact number of slots it's going to use, but various other functions assume there's one more slot with a NULL name field serving as a sentinel. I'm unsure why it doesn't normally crash. -- components: Interpreter Core messages: 56231 nosy: rhamphoryncus severity: normal status: open title: type_new doesn't allocate space for sentinal slot __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1237> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1237] type_new doesn't allocate space for sentinal slot
Adam Olsen added the comment:
typeobject.c:1842:type_new
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
nslots may be 0.
typeobject.c:1966:type_new assigns this just-past-the-end address to
tp_members
type->tp_members = PyHeapType_GET_MEMBERS(et);
type_new later calls PyType_Ready, which calls add_members.
typeobject.c:3062:add_members
for (; memb->name != NULL; memb++) {
Interestingly, traverse_slots and clear_slots both use Py_Size rather
than name != NULL (so I was wrong about the extent of the problem.)
Both seem only to be used for heap types. add_members is used by both
heap types and static C types, so it needs to handle both behaviours.
One possible (if ugly) solution would be to switch iteration methods
depending on if Py_Size() is 0 or not, making sure type_new sets
tp_members to NULL if Py_Size() is 0.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1237>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1237] type_new doesn't allocate space for sentinal slot
Adam Olsen added the comment: Ugh, you're right. I refactored PyType_GenericAlloc out of my fork, which is why I got a crash. Sorry for wasting your time. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1237> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288] dict.fromkeys - Odd logic when passing second dict.fromkeys as value
New submission from Adam Doherty:
Hello:
I'm am trying to conduct some tests on a list of data that checks for
the position of values in list elements using the bisect module. To
store the results of these tests for output to a template I have build a
dictionary with 47 keys the values of which are dictionaries themselves.
These inner dictionaries contain 7 keys that initially are valued at
zero. Looping through the data in my list I check for values from 1 to
47 and if I find the value I am looking for I lookup it's position in
the row using the bisect module. Using the current value I am looking
for and the position returned from bisect I increase the value in the
matching dictionary key value position by 1. Now for speed I have built
the dictionary using d =
dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0)) as this gives
the desired result. Unfortunately when I run my test for values each
value in the dictionary is listed as the total number of rows in the
data list. This is not the desired result which is correctly achieved
using:
d = {}
for x in xrange(1,48):
d[x] = dict.fromkeys(xrange(1,8),0)
I have included output from IDLE to demonstrate the problem.
--
components: Interpreter Core
files: problem-report.txt
messages: 56507
nosy: dohertywa
severity: normal
status: open
title: dict.fromkeys - Odd logic when passing second dict.fromkeys as value
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1288>
__>>> from bisect import bisect as bs
>>> from pysqlite2 import dbapi2 as sqlite
>>> conn = sqlite.connect("/home/dohertywa/testdata.db")
>>> data = [row for row in conn.execute("""SELECT f1,f2,f3,f4,f5,f6,f7 FROM
>>> testtable WHERE strftime('%m', testdate) = strftime('%m', '0001-10-01')""")]
>>> conn.close()
>>> data
[(4, 6, 7, 10, 19, 39, 43), (2, 5, 30, 32, 36, 37, 42), (9, 14, 22, 29, 43, 44,
46), (1, 13, 15, 18, 27, 32, 40), (2, 7, 19, 28, 31, 38, 45), (1, 2, 27, 33,
34, 42, 45), (2, 11, 22, 23, 33, 45, 46), (10, 11, 19, 20, 31, 40, 44), (5, 10,
26, 33, 42, 44, 45), (1, 11, 32, 33, 37, 45, 46), (8, 10, 12, 13, 19, 32, 42),
(8, 13, 18, 21, 24, 25, 36), (8, 12, 17, 18, 28, 29, 35), (5, 7, 15, 24, 26,
38, 43), (17, 21, 23, 25, 26, 33, 47), (16, 19, 27, 34, 44, 45, 46), (10, 22,
31, 35, 40, 43, 46), (7, 15, 23, 25, 27, 37, 40), (1, 7, 19, 23, 35, 37, 45),
(2, 5, 8, 11, 16, 20, 34), (7, 9, 16, 21, 27, 35, 45), (6, 14, 16, 20, 21, 23,
37), (3, 10, 16, 18, 21, 37, 47), (8, 19, 20, 23, 27, 40, 44), (5, 9, 10, 14,
32, 33, 39), (3, 4, 6, 13, 20, 34, 43), (25, 28, 29, 31, 32, 36, 45), (1, 2, 4,
12, 20, 34, 36), (6, 10, 13, 25, 27, 40, 43), (6, 14, 25, 29, 30, 36, 40), (3,
4, 5, 6, 41, 42, 45), (6, 19, 24, 25, 32, 34, 43), (5, 9, 10, 18, 20, 23, 46),
(2, 3, 7, 10, 20, 24, 33), (8, 15, 16, 17, 22!
, 32, 39), (7, 9, 12, 22, 24, 40, 41), (3, 11, 16, 21, 36, 43, 44), (2, 16,
17, 31, 34, 36, 38), (10, 16, 18, 23, 35, 36, 46), (3, 14, 25, 31, 32, 44, 45),
(3, 15, 23, 37, 38, 39, 43), (12, 22, 34, 37, 39, 43, 47), (3, 11, 23, 26, 27,
28, 31), (1, 16, 18, 21, 31, 40, 42), (7, 24, 26, 29, 34, 42, 47), (3, 4, 9,
18, 29, 34, 44), (3, 7, 14, 15, 20, 30, 46), (1, 8, 13, 23, 29, 31, 41), (14,
15, 21, 34, 36, 42, 44), (21, 23, 25, 26, 39, 41, 45), (8, 10, 18, 19, 26, 35,
42), (10, 15, 25, 30, 33, 40, 44), (2, 21, 23, 27, 29, 33, 41), (10, 16, 23,
24, 27, 33, 46), (9, 15, 33, 34, 38, 41, 44), (3, 5, 13, 19, 26, 35, 41), (8,
21, 29, 35, 38, 41, 46), (5, 20, 21, 23, 32, 40, 42), (3, 7, 27, 29, 38, 40,
43)]
>>> dp = dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0)) #a dictionary
>>> whose values are dictionaries whose values are 0.
>>> dp
{1: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 2: {1: 0, 2: 0, 3: 0, 4: 0, 5:
0, 6: 0, 7: 0}, 3: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 4: {1: 0, 2: 0,
3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 5: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0},
6: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 7: {1: 0, 2: 0, 3: 0, 4: 0, 5:
0, 6: 0, 7: 0}, 8: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 9: {1: 0, 2: 0,
3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 10: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0},
11: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 12: {1: 0, 2: 0, 3: 0, 4: 0, 5:
0, 6: 0, 7: 0}, 13: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 14: {1: 0, 2:
0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 15: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7:
0}, 16: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 17: {1: 0, 2: 0, 3: 0, 4:
0, 5: 0, 6: 0, 7: 0}, 18: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 19: {1:
0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 20: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6:
0, 7: 0}, 21: {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6:!
0, 7: 0}, 22: {1: 0, 2: 0, 3: 0
[issue1328] feature request: force BOM option
Adam Olsen added the comment: The problem with "being tolerate" as you suggest is you lose the ability to round-trip. Read in a file using the UTF-8 signature, write it back out, and suddenly nothing else can open it. Conceptually, these signatures shouldn't even be part of the encoding; they're a prefix in the file indicating which encoding to use. Note that the BOM signature (ZWNBSP) is a valid code point. Although it seems unlikely for a file to start with ZWNBSP, if were to chop a file up into smaller chunks and decode them individually you'd be more likely to run into it. (However, it seems general use of ZWNBSP is being discouraged precisely due to this potential for confusion[1]). In summary, guessing the encoding should never be the default. Although it may be appropriate in some contexts, we must ensure we emit the right encoding for those contexts as well. [2] [1] http://unicode.org/faq/utf_bom.html#38 [2] http://unicode.org/faq/utf_bom.html#28 -- nosy: +rhamphoryncus __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
Adam Olsen added the comment: On 11/1/07, James G. sack (jim) <[EMAIL PROTECTED]> wrote: > > James G. sack (jim) added the comment: > > Adam Olsen wrote: > > Adam Olsen added the comment: > > > > The problem with "being tolerate" as you suggest is you lose the ability > > to round-trip. Read in a file using the UTF-8 signature, write it back > > out, and suddenly nothing else can open it. > > I'm sorry, I don't see the round-trip problem you describe. > > If codec utf_8 or utf_8_sig were to accept input with or without the > 3-byte BOM, and write it as currently specified without/with the BOM > respectively, then _I_ can reread again with either utf_8 or utf_8_sig. > > No round trip problem _for me_. > > Now If I need to exchange with some else, that's a different matter. One > way or another I need to know what format they need and create the > output they require for their input. > > Am I missing something in your statement of a problem? You don't seem to think it's important to interact with other programs. If you're importing with no intent to write out to a common format, then yes, autodetecting the BOM is just fine. Python needs a more general default though, and not guessing is part of that. > > Conceptually, these signatures shouldn't even be part of the encoding; > > they're a prefix in the file indicating which encoding to use. > > Yes, I'm aware of that, but you can't predict what you may find in dusty > archives, or what someone may give to you. IMO, that's the basis of > being tolerant in what you accept, is it not? Garbage in, garbage out. There's a lot of protocols with whitespace, capitalization, etc that you can fudge around while retaining the same contents; character set encodings aren't one of them. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1373] turn off socket timeout in test_xmlrpc
New submission from Adam Hupp: The attached patch resolves the intermittent test_xmlrpc failures reported by Neal Norwitz[0]. test_xmlrpc starts the XMLRPC server with a socket timeout. This puts the socket into non-blocking mode which is incompatible with the use of socket.makefile as used by SocketServer. To work around this the test was specifically ignoring temporary read errors but the ignore was no longer working. The patch resolves this by removing the call to socket.settimeout and the code to ignore temporary read errors. I also had to change the `numrequests' parameter in FailingServerTestCase from 2->1. This test case only makes a single request per test (like the others) so numrequests=2 caused the test to hang. [0]http://mail.python.org/pipermail/python-3000/2007-October/011073.html -- components: Tests files: xmlrpc_nonblock.patch messages: 57048 nosy: hupp severity: normal status: open title: turn off socket timeout in test_xmlrpc versions: Python 3.0 Added file: http://bugs.python.org/file8677/xmlrpc_nonblock.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1373> __ xmlrpc_nonblock.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1380] fix for test_asynchat and test_asyncore on pep3137 branch
New submission from Adam Hupp: The attached patch resolves test failues in test_asynchat and test_asyncore. The asynchat failure was due to interpolating a byte string into a unicode string using %s. This resulted in a b'' byte representation in the final string. The fix is to use string constants instead of byte constants. The result is encoded to bytes later on. The asyncore failure was due to an explicit isinstance(data, bytes) check on the result of recv. The actual type in this case was buffer. I've removed the check since the next line calls data.replace(b'\n', b'') This all should fail for anything thats not a buffer or bytes. -- components: Library (Lib), Tests files: pep3137-asynfix.patch messages: 57086 nosy: hupp severity: normal status: open title: fix for test_asynchat and test_asyncore on pep3137 branch type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8684/pep3137-asynfix.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1380> __ pep3137-asynfix.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1720390] Remove backslash escapes from tokenize.c.
Ron Adam added the comment: Yes, I will update it. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1720390> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1420] Unicode literals in tokenize.py and tests.
New submission from Ron Adam:
Replaced Unicode literals in tokenize.py and it's tests files with byte
literals.
Added a compile step to the test to make sure the text file used in the
test are valid python code. This will catch changes that need to be
done in to the text (gold file) for future python versions.
--
components: Library (Lib)
files: tokenize_patch.diff
messages: 57366
nosy: ron_adam
severity: normal
status: open
title: Unicode literals in tokenize.py and tests.
versions: Python 3.0
Added file: http://bugs.python.org/file8732/tokenize_patch.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1420>
__Index: Lib/tokenize.py
===
--- Lib/tokenize.py (revision 58930)
+++ Lib/tokenize.py (working copy)
@@ -69,10 +69,10 @@
Single3 = r"[^'\\]*(?:(?:\\.|'(?!''))[^'\\]*)*'''"
# Tail end of """ string.
Double3 = r'[^"\\]*(?:(?:\\.|"(?!""))[^"\\]*)*"""'
-Triple = group("[uU]?[rR]?'''", '[uU]?[rR]?"""')
+Triple = group("[bB]?[rR]?'''", '[bB]?[rR]?"""')
# Single-line ' or " string.
-String = group(r"[uU]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*'",
- r'[uU]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*"')
+String = group(r"[bB]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*'",
+ r'[bB]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*"')
# Because of leftmost-then-longest match semantics, be sure to put the
# longest operators first (e.g., if = came before ==, == would get
@@ -90,9 +90,9 @@
Token = Ignore + PlainToken
# First (or only) line of ' or " string.
-ContStr = group(r"[uU]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*" +
+ContStr = group(r"[bB]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*" +
group("'", r'\\\r?\n'),
-r'[uU]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*' +
+r'[bB]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*' +
group('"', r'\\\r?\n'))
PseudoExtras = group(r'\\\r?\n', Comment, Triple)
PseudoToken = Whitespace + group(PseudoExtras, Number, Funny, ContStr, Name)
@@ -102,28 +102,28 @@
endprogs = {"'": re.compile(Single), '"': re.compile(Double),
"'''": single3prog, '"""': double3prog,
"r'''": single3prog, 'r"""': double3prog,
-"u'''": single3prog, 'u"""': double3prog,
-"ur'''": single3prog, 'ur"""': double3prog,
+"b'''": single3prog, 'b"""': double3prog,
+"br'''": single3prog, 'br"""': double3prog,
"R'''": single3prog, 'R"""': double3prog,
-"U'''": single3prog, 'U"""': double3prog,
-"uR'''": single3prog, 'uR"""': double3prog,
-"Ur'''": single3prog, 'Ur"""': double3prog,
-"UR'''": single3prog, 'UR"""': double3prog,
-'r': None, 'R': None, 'u': None, 'U': None}
+"B'''": single3prog, 'B"""': double3prog,
+"bR'''": single3prog, 'bR"""': double3prog,
+"Br'''": single3prog, 'Br"""': double3prog,
+"BR'''": single3prog, 'BR"""': double3prog,
+'r': None, 'R': None, 'b': None, 'B': None}
triple_quoted = {}
for t in ("'''", '"""',
"r'''", 'r"""', "R'''", 'R"""',
- "u'''", 'u"""', "U'''", 'U"""',
- "ur'''", 'ur"""', "Ur''
[issue1420] Unicode literals in tokenize.py and tests.
Ron Adam added the comment: George is correct. The changes are minimal. The only addition is to run the tokenize_tests.txt file though compile() as a way to force an exception if it needs updating in the future. The results of the compile are not used. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1420> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1441] Cycles through ob_type aren't freed
New submission from Adam Olsen: If I create a subclass of 'type' that's also an instance of 'type', then I change __class__ to point to itself, at which point it cannot be freed (as the type object is needed to delete the instance.) I believe this can be solved by resetting __class__ to a known-safe value. Presumably this should be a hidden subclass of type, stored in a C global, and used specifically for this purpose. type_clear can do the reset (checking that the passed in type is a heap type, perhaps with a heap type metaclass); I'm hoping __del__ and weakref callbacks are not an issue at this point, but I'll defer to the experts for verification. This log using gdb shows that type_dealloc is called for a normal type (BoringType), but not for the self-cyclic one (ImmortalType). ImmortalType shows up in every collection, never actually getting collected. (I'm assuming Python doesn't bother to delete heap types during shutdown, which is why type_dealloc isn't called more.) ** [EMAIL PROTECTED]:~/src/python-p3yk/build-debug$ gdb ./python GNU gdb 6.6.90.20070912-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set height 10 (gdb) break type_dealloc Breakpoint 1 at 0x80af057: file ../Objects/typeobject.c, line 2146. (gdb) commands Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". >silent >printf "*** type_dealloc %p: %s\n", type, type->tp_name >cont >end (gdb) break typeobject.c:2010 Breakpoint 2 at 0x80aec35: file ../Objects/typeobject.c, line 2010. (gdb) commands Type commands for when breakpoint 2 is hit, one per line. End with a line saying just "end". >silent >printf "*** type_new %p: %s\n", type, type->tp_name >cont >end (gdb) run Starting program: /home/rhamph/src/python-p3yk/build-debug/python Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread 0xb7e156b0 (LWP 25496)] [Switching to Thread 0xb7e156b0 (LWP 25496)] *** type_new 0x81c80ac: ZipImportError *** type_new 0x81e9934: abstractproperty *** type_new 0x81ea484: _Abstract *** type_new 0x81eab04: ABCMeta *** type_new 0x81eb6b4: Hashable *** type_new 0x81ecb7c: Iterable *** type_new 0x81ed9a4: Iterator *** type_new 0x81ede84: Sized *** type_new 0x81ee364: Container *** type_new 0x822f2fc: Callable *** type_new 0x822f974: Set *** type_new 0x823094c: MutableSet *** type_new 0x8230fec: Mapping *** type_new 0x823135c: MappingView *** type_new 0x823183c: KeysView *** type_new 0x8231eb4: ItemsView *** type_new 0x823252c: ValuesView *** type_new 0x8232ba4: MutableMapping *** type_new 0x82330ac: Sequence *** type_new 0x8233fa4: MutableSequence *** type_new 0x81e61ac: _Environ *** type_new 0x823657c: _wrap_close *** type_new 0x81d41a4: _Printer *** type_new 0x81dab84: _Helper *** type_new 0x81d12a4: error *** type_new 0x82ad5b4: Pattern *** type_new 0x82adc2c: SubPattern *** type_new 0x82ae134: Tokenizer *** type_new 0x82afb04: Scanner *** type_new 0x8249f34: _multimap *** type_new 0x824892c: _TemplateMetaclass *** type_new 0x82b0634: Template *** type_new 0x82b34ac: Formatter *** type_new 0x82b000c: DistutilsError *** type_new 0x82b40c4: DistutilsModuleError *** type_new 0x82b440c: DistutilsClassError *** type_new 0x82b4754: DistutilsGetoptError *** type_new 0x82b4a9c: DistutilsArgError *** type_new 0x82b4de4: DistutilsFileError *** type_new 0x82b512c: DistutilsOptionError *** type_new 0x82b57d4: DistutilsSetupError *** type_new 0x82b5b1c: DistutilsPlatformError *** type_new 0x82b5e64: DistutilsExecError *** type_new 0x82b61ac: DistutilsInternalError *** type_new 0x82b64f4: DistutilsTemplateError *** type_new 0x82b683c: CCompilerError *** type_new 0x82b6b84: PreprocessError *** type_new 0x82b6ecc: CompileError *** type_new 0x82b7214: LibError *** type_new 0x82b755c: LinkError *** type_new 0x82b7d4c: UnknownFileError *** type_new 0x82b9b6c: Log *** type_new 0x82ba994: Quitter *** type_new 0x82bcdbc: CodecInfo *** type_new 0x82bd104: Codec *** type_new 0x82bdd94: IncrementalEncoder *** type_new 0x82be224: BufferedIncrementalEncoder *** type_new 0x82be72c: IncrementalDecoder *** type_new 0x82bebbc: BufferedIncrementalDecoder *** type_new 0x82bf0c4: StreamWriter *** type_new 0x82bf5cc: StreamReader *** type_new 0x82bfad4: StreamReaderWriter *** type_new 0x82c022c: StreamRecoder *** type_new 0x82c221c: CodecRegistryError *** type_new 0x82c5414: _OptionError *** type_new 0x82c23f4: BlockingIOError *** type_new
[issue1720390] Remove backslash escapes from tokenize.c.
Ron Adam added the comment:
It looks like the disabling of \u and \U in raw strings is done. Does
tokenize.py need to be fixed, to match?
While working on this I was able to clean up the string parsing parts of
tokenize.c, and have a separate patch with just that.
And an updated patch with both the cleaned up tokenize.c and the no
escapes in raw strings in case it is desired after all.
Added file: http://bugs.python.org/file8762/tokenize_cleanup_patch.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1720390>
_Index: Parser/tokenizer.c
===
--- Parser/tokenizer.c (revision 58951)
+++ Parser/tokenizer.c (working copy)
@@ -1254,23 +1254,17 @@
/* Identifier (most frequent token!) */
nonascii = 0;
if (is_potential_identifier_start(c)) {
- /* Process r"", u"" and ur"" */
- switch (c) {
- case 'r':
- case 'R':
+ /* Process b"", r"" and br"" */
+ if (c == 'b' || c == 'B') {
c = tok_nextc(tok);
if (c == '"' || c == '\'')
goto letter_quote;
- break;
- case 'b':
- case 'B':
+ }
+ if (c == 'r' || c == 'R') {
c = tok_nextc(tok);
- if (c == 'r' || c == 'R')
-c = tok_nextc(tok);
if (c == '"' || c == '\'')
goto letter_quote;
- break;
- }
+ }
while (is_potential_identifier_char(c)) {
if (c >= 128)
nonascii = 1;
@@ -1417,59 +1411,51 @@
*p_end = tok->cur;
return NUMBER;
}
-
+
letter_quote:
/* String */
if (c == '\'' || c == '"') {
- Py_ssize_t quote2 = tok->cur - tok->start + 1;
- int quote = c;
- int triple = 0;
- int tripcount = 0;
- for (;;) {
- c = tok_nextc(tok);
- if (c == '\n') {
-if (!triple) {
- tok->done = E_EOLS;
- tok_backup(tok, c);
- return ERRORTOKEN;
-}
-tripcount = 0;
-tok->cont_line = 1; /* multiline string. */
- }
- else if (c == EOF) {
-if (triple)
- tok->done = E_EOFS;
-else
- tok->done = E_EOLS;
-tok->cur = tok->inp;
-return ERRORTOKEN;
- }
- else if (c == quote) {
-tripcount++;
-if (tok->cur - tok->start == quote2) {
- c = tok_nextc(tok);
- if (c == quote) {
- triple = 1;
- tripcount = 0;
- continue;
- }
- tok_backup(tok, c);
-}
-if (!triple || tripcount == 3)
- break;
- }
- else if (c == '\\') {
-tripcount = 0;
-c = tok_nextc(tok);
-if (c == EOF) {
- tok->done = E_EOLS;
- tok->cur = tok->inp;
- return ERRORTOKEN;
-}
- }
+ int quote = c;
+ int quote_size = 1; /* 1 or 3 */
+ int end_quote_size = 0;
+
+ /* Find the quote size and start of string */
+ c = tok_nextc(tok);
+ if (c == quote) {
+ c = tok_nextc(tok);
+ if (c == quote)
+quote_size = 3;
else
-tripcount = 0;
+end_quote_size = 1; /* empty string found */
}
+ if (c != quote)
+ tok_backup(tok, c);
+
+ /* Get rest of string */
+ while (end_quote_size != quote_size) {
+ c = tok_nextc(tok);
+ if (c == EOF) {
+if (quote_size == 3)
+ tok->done = E_EOFS;
+ else
+ tok->done = E_EOLS;
+ tok->cur = tok->inp;
+ return ERRORTOKEN;
+ }
+ if (quote_size == 1 && c == '\n') {
+ tok->done = E_EOLS;
+ tok->cur = tok->inp;
+ return ERRORTOKEN;
+ }
+ if (c == quote)
+ end_quote_size += 1;
+ else {
+ end_quote_size = 0;
+ if (c == '\\')
+ c = tok_nextc(tok); /* skip escaped char */
+ }
+ }
+
*p_start = tok->start;
*p_end = tok->cur;
return STRING;
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1720390] Remove backslash escapes from tokenize.c.
Changes by Ron Adam: Added file: http://bugs.python.org/file8763/no_raw_escapes_patch.diff _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1720390> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1225584] crash in gcmodule.c on python reinitialization
Changes by Adam Olsen: -- nosy: +rhamphoryncus _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1225584> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool
New submission from Adam Olsen:
(thanks go to my partner in crime, jorendorff, for helping flesh this out.)
lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on
the key passed. It's possible for the comparison to delete the key from
the dict, causing its own argument to be deallocated. This can lead to
bogus results or a crash.
A custom type with its own __eq__ method will implicitly INCREF the key
when passing it as an argument, which prevents incorrect behaviour from
manifesting. There are a couple ways around this though, as shown in my
attachment.
--
components: Interpreter Core
files: dictbug.py
messages: 57925
nosy: rhamphoryncus
severity: normal
status: open
title: lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool
Added file: http://bugs.python.org/file8820/dictbug.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1517>
__#!/usr/bin/env python
# This first approach causes dict to return the wrong value
# for the key. The dict doesn't create its own reference
# to startkey, meaning that address may get reused. We
# take advantage of that to swap in a new value without it
# noticing the key has changed.
class Foo(object):
def __init__(self, value):
self.value = value
def __hash__(self):
return hash(self.value)
def __eq__(self, other):
# self gets packed into a tuple to get passed to us,
# which INCREFs it and prevents us from reusing the
# address. To get around that we move the work into
# our return value's __nonzero__ method instead.
return BadBool(self.value, other.value)
class BadBool(object):
def __init__(self, a, b):
self.a = a
self.b = b
def __nonzero__(self):
global counter
if not counter:
counter = 1
# This is the bad part. Conceivably, another thread
# might do this without any malicious behaviour
# involved.
del d[d.keys()[0]]
d[Foo(2**32+1)] = 'this is never the right answer'
return self.a == self.b
print "Test 1, using __eq__(a, b).__nonzero__()"
d = {}
counter = 0
d[Foo(2)] = 'this is an acceptable answer'
print d.get(Foo(2), 'so is this')
print '*'
# This second version uses tuple's tp_richcompare. tuple
# assumes the caller has a valid reference, but Bar.__eq__
# purges that reference, causing the tuple to be
# deallocated. Watch only exists to make sure tuple
# continues to use the memory, provoking a crash.
#
# Interestingly, Watch.__eq__ never gets called.
class Bar(object):
def __hash__(self):
return 0
def __eq__(self, other):
d.clear()
return True
class Watch(object):
def __init__(self):
print "New Watch 0x%x" % id(self)
def __del__(self):
print "Deleting Watch 0x%x" % id(self)
def __hash__(self):
return 0
def __eq__(self):
print "eq Watch", self, other
return True
print "Test 2, using tuple's tp_richcompare"
d = {}
d.clear()
d[(Bar(), Watch())] = 'hello'
print d[(Bar(), Watch())]
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12398] Sending binary data with a POST request in httplib can cause Unicode exceptions
Adam Cohen added the comment: I encountered this issue as well. "params" is simply a bytestring, with no encoding. Workaround/proper solution is to cast the string as a bytearray with bytearray(params). -- nosy: +Adam.Cohen ___ Python tracker <http://bugs.python.org/issue12398> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13107] Text width in optparse.py can become negative
New submission from Adam Byrtek :
Code snippet from optparse.py:
344 self.help_position = min(max_len + 2, self.max_help_position)
345 self.help_width = self.width - self.help_position
Where self.width is initialized with the COLUMNS environment variable. On
narrow terminals it can happen that self.help_position < self.width, leading to
an exception in textwrap.py:
raise ValueError("invalid width %r (must be > 0)" % self.width)
ValueError: invalid width -15 (must be > 0)
A reasonable workaround would be to trim part of the help text instead of
causing an exception.
--
components: Library (Lib)
messages: 144947
nosy: adambyrtek
priority: normal
severity: normal
status: open
title: Text width in optparse.py can become negative
type: behavior
___
Python tracker
<http://bugs.python.org/issue13107>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Changes by Ron Adam : -- nosy: +ron_adam ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13003] Bug in equivalent code for itertools.izip_longest
Adam Forsyth added the comment: This is marked as "wont fix" but has been fixed, the resolution should be changed. -- nosy: +agforsyth ___ Python tracker <http://bugs.python.org/issue13003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Ron Adam added the comment: Instead of a get_instructions() function, How about using a DisCode class that defines the API for accessing Opinfo tuples of a disassembled object. So instead of... for instr in dis.bytecode_instructions(thing): process(instr) You could use... for instr in dis.DisCode(thing): process(instr) And I would like to be able to do... assertEqual(DisCode(thing1), DisCode(thing2)) It could also have a .dis() method that returns formatted output that matches what dis() currently prints. That would allow tests that use dis.dis() to get rid of capturing stdout with minimal changes. result = DisCode(func).dis() # return a dis compatible string. A DisCode object also offers a nice place to put documentation for the various pieces and an overall view of the new API without getting it confused with the current dis.dis() API. It's easier for me to remember an object with methods than several separate but related functions. (YMMV) This is very near a version of dis I did a while back where I removed the prints and returned a list of list object from dis.dis(). The returned object had __repr__ that formatted the data so it matched the current dis output. That made it work the same in a python shell. But I could still access and alter individual lines and fields by indexing or iterating it. While it worked nicely, it wouldn't be backwards compatible. -- nosy: +ron_adam ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Ron Adam added the comment: There is a test for 'yield from' as a function argument without the extra parentheses. f(yield from x) You do need them in the case of a regular yield. f((yield)) or f((yield value)) Shouldn't the same rule apply in both cases? * I'm trying to do a version of the patch with 'yield_from' as a separate item from 'yield' in the grammar, but it insists on the parentheses due to it being a yield_expr component. -- nosy: +ron_adam ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Ron Adam added the comment: Thanks for the updated links Nick. There is a comment in the docs that recommends putting parentheses around any yield expression that returns a value. So it is in agreement with that in the function argument case. The grammar I used does keep it as a variant. yield_expr 'yield' [testlist | yield_from] yield_from 'from' test The purpose of doing that is so I can do ... yield_expr 'yield' [testlist | yield_from | yield_raise] yield_from 'from' test yield_raise 'raise' [test ['from' test]] The yield_raise part is only an interesting exercise to help me understand cpythons internals better. I'm getting there and hope to be able to contribute to more bug fixes, and patches. :-) -- ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
New submission from Ron Adam : The following changes cleanup the eval loop and result in a pretty solid 2 to 3% improvement in pybench for me. And it is about 5% faster for long generators. * Change why enum type to int and #defines. And moved the why defines to opcode.h so that they can be seen by the genrator objects after a yield, return, or exception. * Added an "int f_why" to frames so the generator can see why it returned from a send. * Refactored generator obj so it can use the "f->f_why" to determine what to do without having to do several checks first. * Moved the generator specific execption save/swap/and clear out of the cevel main loop. No need to check for those on every function call. The only test that fails is the frame size is test_sys. I left that in for now so someone could check that, and tell me if it's ok to fix it, or if I need to do something else. I also considered putting the why on the tstate object. It might save some memory as there wouldn't be as many of those. -- components: Interpreter Core files: f_why.diff keywords: patch messages: 149583 nosy: ron_adam priority: normal severity: normal status: open title: Move generator specific sections out of ceval. type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23969/f_why.diff ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam added the comment: A simple test to show the difference. BEFORE: $ python3 -mtimeit "def y(n):" " for x in range(n):" "yield x" "sum(y(10))" 10 loops, best of 3: 3.87 usec per loop $ python3 -mtimeit "def y(n):" " for x in range(n):" "yield x" "sum(y(100))" 10 loops, best of 3: 186 msec per loop AFTER: $ ./python -mtimeit "def y(n):" " for x in range(n):" "yield x" "sum(y(10))" 10 loops, best of 3: 3.81 usec per loop $ ./python -mtimeit "def y(n):" " for x in range(n):" "yield x" "sum(y(100))" 10 loops, best of 3: 168 msec per loop before after y(10) usec's 3.873.81 - 1.55% y(100)msec's 186 168 - 9.67% -- ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Changes by Ron Adam : Removed file: http://bugs.python.org/file23969/f_why.diff ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam added the comment: New diff file. The main difference is I moved the saved why value to the tstate object instead of the frame object as why_exit. I'm not seeing the time savings now for some reason. Maybe the previous increase was a case of coincidental noise. (?) Still looking for other reasons though. ;-) Moving the generator code from the eval loop to the generator object may still be a good thing to do. -- Added file: http://bugs.python.org/file24047/f_why1.diff ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam added the comment:
I think the time benefits I saw are dependent on how the C code is compiled.
So it may be different on different compilers or the same compiler with only a
very minor change.
Some of the things I've noticed...
A switch is sometimes slower if it has a "default:" block.
Moving "why = tstate->why_exit;" to just before the if helps a tiny bit.
why = tstate->why_exit;
if (why != WHY_EXCEPTION) {
Returning directly out of the WHY_YIELD case.
case WHY_YIELD:
return result;
These will be mostly compiler dependent, but they won't slow things down any
either.
What I was trying to do is clean up things a bit in ceval.c. Having the why
available on the frame can help by allowing some things to be moved out of
ceval.c where it makes sense to do that.
I'll post a new diff tonight with the why_exit moved back to the frame object
and the why's back to enums. Yes, I think the frame object is a good place for
it.
One of the odd issues is the opcode and why values sometimes need to be pushed
on the value stack. Which means it needs to be converted to a pyobject first,
then converted back after it's pulled off the stack. I'm looking for a way to
avoid that.
I also was able to make fast_block_end section simpler and more understandable
without making it slower. I think it was trying to be too clever in order to
save some lines of code. That makes it very hard to figure out by someone else.
But first I need to finish my Christmas shopping, I'll post a new patch tonight
when I get a chance. :-)
--
___
Python tracker
<http://bugs.python.org/issue13607>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Changes by Ron Adam : Removed file: http://bugs.python.org/file24047/f_why1.diff ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam added the comment: Updated patch with suggested changes. It also has a cleaned up fast_block_end section. Concerning speed. What happens is (as Tim and Raymond have pointed out) that we can make some things a little faster, in exchange for other things being a little slower. You can play around with the order of the why cases in the fast_block_end section and see that effect. By using a switch instead of if-else's, that should result in more consistent balance between the block exit cases. The order I currently have gives a little more priority for exceptions and that seems to help a tiny bit with the ccbench scores. I think that is a better bench mark than the small micro tests like pybench does. The problem with pybench is, it doesn't test deeper nesting where these particular changes will have a greater effect. -- Added file: http://bugs.python.org/file24087/f_why2.diff ___ Python tracker <http://bugs.python.org/issue13607> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13659] Add a help() viewer for IDLE's Shell.
Ron Adam added the comment: What about having idle open a web browser session with pydocs new browse option? python3 -m pydoc -b We've added input fields to the pages that take the same input as help() command does. It also links to the online help pages, and you can view the source code of the files directly in the browser. (Sometimes that's the best documentation you can get.) -- nosy: +ron_adam ___ Python tracker <http://bugs.python.org/issue13659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11699] Doc for optparse.OptionParser.get_option_group is wrong
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue11699> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11644] Cross-link 2to3 documentation, what’s new and pyporting howto
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue11644> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11203] gzip doc is behind
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue11203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11785] email subpackages documentation problems
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue11785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Adam Woodbeck added the comment: I propose: object.copy_sign(other) Return a copy of *object* with the sign set to be the same as the sign of *other*. This format is most familiar to me. But like Ezio wrote, all other methods referring to first and second operands would need to updated to refer to *object* and *other*, respectively. -- ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Adam Woodbeck added the comment: Or rather: object.copy_sign(other) Return a copy of *object* with the sign set to be that of *other*. -- ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Adam Woodbeck added the comment: Sorry guys. I'm new at this. After reviewing this thread, Terry's suggestion makes the most sense to me. -- ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Adam Woodbeck added the comment: Hi Francisco, I finally found time to create a patch for this issue. I was just saving the patch I wrote as your update arrived in my inbox. I've included my patch for good measure. It's better to have two proposed patches than none at all in my opinion. Adam -- Added file: http://bugs.python.org/file9/issue_12185-ajw.patch ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12278] Core mentorship mention in the devguide
New submission from Adam Woodbeck : Jesse requested the devguide be updated to include a mention of the Python Mentors site. The attached patch is my rough draft. -- components: Devguide files: help.rst.patch keywords: patch messages: 137807 nosy: adam.woodbeck, ncoghlan priority: normal severity: normal status: open title: Core mentorship mention in the devguide Added file: http://bugs.python.org/file22271/help.rst.patch ___ Python tracker <http://bugs.python.org/issue12278> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12278] Core mentorship mention in the devguide
Adam Woodbeck added the comment: Éric, good point. I'll propose different wording when I have an opportunity later today. In the mean time, I'm certainly open to suggestions, especially as I get my feet wet. So you would also prefer a mention of the python-ideas and python-dev mailing lists, where the former is primarily for suggesting new development ideas, and the latter is for core language discussion. Correct? -- ___ Python tracker <http://bugs.python.org/issue12278> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12369] Revised core mentorship section of help.rst
New submission from Adam Woodbeck : Here is the latest update to the devguide's help.rst for your consideration. It includes Nick's tweaks to what I originally submitted. -- components: Devguide files: help.rst.patch keywords: patch messages: 138668 nosy: adam.woodbeck, ncoghlan priority: normal severity: normal status: open title: Revised core mentorship section of help.rst versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file22410/help.rst.patch ___ Python tracker <http://bugs.python.org/issue12369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Adam Woodbeck added the comment: I grepped the documentation in the cpython repository and replaced all mentions of "member(s)" with "attribute(s)" where I felt appropriate. I left mentions of "members" related to structs or any C documentation alone as I'm less confident of their terminology (I'm new around here). I used "methods and attribute" in io.rst because BufferedIOBase included one attribute and several methods. My terminology may be off, but I felt this was the correct replacement of "members." Please review the patch and critique it as necessary. -- keywords: +patch Added file: http://bugs.python.org/file22422/issue10403.patch ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Adam Woodbeck added the comment: I was always under the impression attributes and methods were mutually exclusive. I've corrected the patch as requested. -- Added file: http://bugs.python.org/file22436/issue10403_v2.patch ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Changes by Adam Woodbeck : Added file: http://bugs.python.org/file22438/issue10403_v3.patch ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10608] Add a section to Windows FAQ explaining os.symlink
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue10608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue10503> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Provide reference to detailed installation instructions
Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
