[issue41540] Test test_maxcontext_exact_arith (_decimal) consumes all memory on AIX

Tony Reix added the comment: Hi Stefan, In your message https://bugs.python.org/issue41540#msg375462 , you said: "However, instead of freezing the machine, the process gets a proper SIGKILL almost instantly." That's probably due to a very small size of the Paging Space of

[issue41754] Webbrowser Module Cannot Find xdg-settings on OSX

New submission from Tony DiLoreto : The following code does not work on many OSX installations of Python via homebrew: >>> import webbrowser >>> webbrowser.open("http://www.google.com";) And throws the following error stack trace: File "/us

[issue41829] sqlite3.Row always read as tuple when supplied to executemany

New submission from Tony Wu : Supplying a sequence or sqlite3.Row objects to sqlite3.Connection.executemany will cause the Row objects to be interpreted as Sequences instead of Mappings even if the statement to be executed uses named parameter substitution. That is, values in the Rows are

[issue41829] sqlite3.Row always read as tuple when supplied to executemany

Change by Tony Wu : -- nosy: +ghaering ___ Python tracker <https://bugs.python.org/issue41829> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42173] Drop Solaris support

Tony Albers added the comment: No no no, please don't. Apart from FreeBSD, illumos distros are the only really hard-core UNIX OS'es still freely available, the features taken into account. SMF, dtrace and several hypervisor types makes illumos really stand out. I understand that

[issue36087] ThreadPoolExecutor max_workers none issue

New submission from Tony Hammack : ThreadPoolExecutor(max_workers=None) throws exception when it should not. Inconsistent with 3.4 documentation. If max_workers=None, then it should use the amount of cpus as threadcount. -- components: Library (Lib) messages: 336354 nosy: Tony

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

New submission from Tony Roberts : In dynload_win.c LoadLibraryExW is called with the GIL held. This can cause a deadlock in an uncommon case where the GIL also needs to be acquired when another thread is being detached. Both LoadLibrary and FreeLibrary acquire the Windows loader-lock. If

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: Sure, I'll get that done in the next couple of days. -- ___ Python tracker <https://bugs.python.org/issue33895> ___ ___

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Change by Tony Roberts : -- keywords: +patch pull_requests: +7393 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: GetProcAddress and GetModuleHandle do block in the same way as LoadLibrary and FreeLibrary - they acquire the loader lock too. Yes, ideally the application would terminate its threads cleanly, however when Python is embedded in another application it may not

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: Sure, that's reasonable :) For my case I have a usable workaround so not back porting it to < 3.8 is fine for me. My workaround will just leak the thread state if another thread is in __import__, which happens so rarely that it's not really a pro

[issue15129] file.readline() cannot read weird ascii character in file

New submission from Tony Malykh : readline() or readlines() method can read the file up to the line where weird character ascii code 26 appears. I would like to read the entire file though. A simple example attached. -- components: IO files: testpy.zip messages: 163363 nosy

[issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close()

New submission from Tony Gedge: Sending a zero-length UDP packet to asyncore closes socket by default. The default implementation of recv() assumes that zero-length data means close. This isn't true for UDP - it is possible to send a zero-length payload packet. A possible work-around

[issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close()

Tony Gedge added the comment: If it's true that asyncore doesn't support UDP, I'd suggest at least a statement to this effect in the documentation. As far as I can see, there's nothing to suggest it won't work with UDP. -- _

[issue22318] unitest documentation on assertItemsEqual misleading

New submission from Tony Flury: The notes on assertItemsEqual do not make it clear that the comparison works by using their hash value, and not their __eq__ implementation - i.e. it does an 'is' not an '==' between objects in the sequence. If the sequences being compared

[issue7247] 2.6.4 fnctl test failure

New submission from Tony Vroon : chain...@prometheus ~ $ python2.6 /usr/lib64/python2.6/test/test_fcntl.py struct.pack: '\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' test_fcntl_64_bit (__main__.TestFcntl)

[issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4

Tony Vroon added the comment: This is AMD64 Linux, to be specific a 2.6.32-rc5-00336-g8d5eb43 kernel running on a dual Opteron 2435 system. The distribution is Gentoo linux, with a glibc version of 2.10.1-r0, compiled with GCC 4.4.2 -- ___ Python

[issue1522237] _threading_local.py logic error in _localbase __new__

Tony Nelson added the comment: Thanks, Amaury. The new test works here on Python2.6.1, failing without the fix and passing with it. (Passing MyLocal(a=1) and failing MyLocal(1), as expected.) With the fix, _threading_local.py supports positional arguments to subclass __init__, as well as

[issue5610] email feedparser.py CRLFLF bug: $ vs \Z

New submission from Tony Nelson : feedparser.py does not pares mixed newlines properly. NLCRE_eol, which is used to search for the various newlines at End Of Line, uses $ to match the end of string, but $ also matches \n$, due to a wise long-ago patch by the Effbot. This causes feedparser to

[issue5610] email feedparser.py CRLFLF bug: $ vs \Z

Tony Nelson added the comment: make test still passes all tests except test_httpservers on my Python 2.6.1 build. The network resource was not enabled and tk is not available. The new test for CRLFLF at the end of a message body is added to Lib/email/test_email at the end of the TestParsers

[issue5636] csv.reader next() method missing

New submission from Tony Joblin : On windows using 3.0.1 the csv.reader.next() public method is missing. The documentation says that this method should exist and it does exist in previous versions. There is a __next__ method available and constructs like: for row in reader print(row

[issue5638] test_httpservers fails CGI tests if --enable-shared

New submission from Tony Nelson : test_httpservers fails the CGI tests if Python was built as a shared library (./config --enable-shared) and not yet installed. To run such a Python without installing it, the command line must define LD_LIBRARY_PATH to point to the build directory. I see that

[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192

Tony Nelson added the comment: The OP's diagnosis of a buffer boundary problem is correct, but incomplete. The problem can be reproduced by calling feedparser FeedParser.feed() directly, or as my patch test does, by calling BufferedSubFile.push() directly. The proper fix is for push

[issue3169] email/header.py doesn't handle Base64 headers that have been insufficiently padded.

Tony Nelson added the comment: Postel's law suggests that, as bad padding can be repaired, decode_header ought to do so. The patch does that, adds a test for it, and alters another test to still properly fail on really bad encoded data. The test doesn't check a single character enco

[issue3169] email/header.py doesn't handle Base64 headers that have been insufficiently padded.

Changes by Tony Nelson : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue3169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue4487] Add utf8 alias for email charsets

Tony Nelson added the comment: This seems entirely reasonable, helpful, and in accord with the mapping of ascii to us-ascii. I recommend accepting this patch or a slightly fancier one that would also do "utf_8". There are pobably other encoding names with the same issue of being a

[issue4487] Add utf8 alias for email charsets

Changes by Tony Nelson : -- versions: +Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue4487> ___ ___ Python-bugs-list mailing list Unsub

[issue1079] decode_header does not follow RFC 2047

Tony Nelson added the comment: I think the problem is best viewed as headers are not being parsed according to RFC2822 and decoded after that, so the recognition of encoded words should be looser, and not require whitespace around them, as it is not required in all contexts. Patch and test

[issue4491] email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF

Tony Nelson added the comment: See patch in issue1079. I don't think email.header can require whitespace until it decodes parsed headers, as whitespace is not always required. -- nosy: +barry, tony_nelson versions: +Python 2.7 ___ Python tr

[issue1079] decode_header does not follow RFC 2047

Tony Nelson added the comment: The email package does not follow the RFCs in anything to do with header parsing or decoding. This is a known deficiency. So no, I am not thinking of atoms at all -- and neither is email.header.decode_header()! :-( Until email.header actually parses headers

[issue1054967] bdist_deb - Debian packager

Changes by Tony Meyer : -- nosy: +anadelonbrin ___ Python tracker <http://bugs.python.org/issue1054967> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue845560] imaplib: traceback from _checkquote with empty string

Tony Meyer added the comment: Why does the patch being very small make it more trouble? -- ___ Python tracker <http://bugs.python.org/issue845560> ___ ___ Pytho

[issue6443] _winreg.QueryValueEx confused on double null terminated strings

Tony Grue added the comment: I see this was closed,though it sounds like it's because a work around is found, not because the code now handles multiple null values in a row. Looking at code from the github mirror (pasted below); it looks like the issue is that the countStrings function b

[issue27725] Use Py_SIZE(x) instead of x->ob_size

New submission from REIX Tony: I'm porting Python 2.7.* on AIX. I am now using a version 13.1.3.2 of XLC. I was previously using version 12.1.0.14 . It appears that this new compiler shows a potential issue in Python v2 code. This issue seems to appear when -O2 is used. I was porting P

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: Hi Raymond I've got several email exchanges with the IBM XLC expert. From his own study of my issue, his conclusion is that this kind of Python v2 coding is not ANSI-aliasing safe. It seems that there is a standard that requires C code to NOT do some kin

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: Thanks a lot Stefan, that should completely explain my issues. -fno-strict-aliasing -fwrapv for gcc So, that means that you would get better performance if you applied on Python v2.7 what Python v3.5 did about Py_SIZE(x) . However, there are probably other places

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: With XLC v13 -O2, using -qalias=noansi for building Objects/longobject.o only and not for all the other .o files did fix the 10 more failed tests I see with -O2 compared to -O0 (7-8 failed tests). So, ANSI-aliasing in Objects/longobject.c is the issue. About

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: OK. However, compiling ONLY the file Objects/longobject.c with -qalias=noansi did fix the issue on AIX. That could be the same on Linux. I haven't tried to use Py_SIZE() in all places where it should be used. Now trying to figure out why GCC behaves worst

[issue24741] Hangs and errors while testing on Ubuntu/Intel

New submission from REIX Tony: I'm now porting Python (2.7.10 and 3.4.3) on AIX. Before that, I wanted to build and test on reference machines in order to see what is expected during building and testing. However, on Ubuntu/i586 and Ubuntu/x86_64, I face hangs and errors during test pha

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: run on Ubuntu/i586 : $ make test > Go.res3 2>&1 & $ tail -f Go.res [164/390] test_cgi Silent ! ^C [1]+ Stoppedmake test > Go.res3 2>&1 reixt@b017569-ux:~/FromOldPC/FromOldPC/Projets/ToolBox/PYTHON-3/Python-

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: Thnaks for the information. I'm surprised that: $ make test > Go.res3 2>&1 & makes issues that do not appear with: $ nohup make test > Go.res3 2>&1 & Anyway, we know the root cause now, and there is a work-around. So, closing th

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: Hum I'm now building Python 2.7.10 RPMs on AIX. The .spec file works fine. However, when adding make test in the .spec file, I've got the tests blocked in test_io. The same with 2.7.6 . Going into the directory and trying "make quicktest"

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: I got strange things: Tests blocked in: [300/400/22] test_signal and: # ps -edf | grep python root 7405612 12320954 0 14:52:04 pts/2 0:00 ./python -m -c -l -x test_io root 7929900 34209932 0 14:52:04 pts/2 0:00 ./python -m -c -l -x test_io

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: About test_io, when running it alone by: ./python ./Lib/test/test_io.py > /tmp/test_io.res I got NO error ! Done 2 times on each of my 2 AIX machines. Hu Why these tests do block in the middle ? -- ___ Pyt

[issue24741] Hangs and errors while testing on Ubuntu/Intel

REIX Tony added the comment: Yes. I'm on my own for AIX debugging. I'm afraid too. ;) OK. What I need is build more skills about how to get into deep details when things run badly. Lot of fun. ;) Thx -- ___ Python tracker <http://bu

[issue24046] Incomplete build on AIX

REIX Tony added the comment: Fresh openssl versions are now available for AIX: 1.0.1p and 1.0.2d . See: http://www.bullfreeware.com/search.php?package=openssl -- nosy: +trex58 ___ Python tracker <http://bugs.python.org/issue24

[issue20600] test_create_server_ssl_verify_failed() failure on "PPC64 AIX 3.x" buildbot

REIX Tony added the comment: I'm now working about the port of Python 3.4.3 on AIX. So, I'm interesting with issues dealing with AIX. I'm now building a view of the issues on AIX 6.1 . -- nosy: +trex58 ___ Python tracker <http

[issue25467] Put “deprecated” warnings first

New submission from Tony R.: Python has wonderful, detailed documentation. I love it! Unfortunately, I have often found myself reading the otherwise-excellent documentation on a class/function/whatever, only to find out at the END of my reading that it is deprecated. This is frustrating

[issue25467] Put “deprecated” warnings first

Tony R. added the comment: > Thanks for the report and the patch. Thank you for the review! > I think a better way to handle this would be to add a "tag" next to the > function name for both deprecations and "new in", and leave the actual > deprecation/new-i

[issue25467] Put “deprecated” warnings first

Tony R. added the comment: > On Oct 26, 2015, at 1:49 PM, Ezio Melotti wrote: > > Not sure if there's a clever way to do it though (maybe a CSS class can be > added to the directives and the labels can be added with CSS :after). I was thinking something along th

[issue25467] Put “deprecated” warnings first

Tony R. added the comment: > On Oct 26, 2015, at 4:28 PM, Ezio Melotti wrote: > > This is true, but on the other hand you might want to see the [new in 3.4] > while looking at 3.6 docs and working on a program that must support Python > 3.3+. Anyway we can discuss this again

[issue9694] argparse required arguments displayed under "optional arguments"

Changes by tony gaetani : -- nosy: +tonygaetani ___ Python tracker <http://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

New submission from Tony R.: In the documentation, I noticed several uses of ``.. versionchanged::`` that described things which had been added. I love Python, and its documentation, and I wanted to contribute. So, I figured a low-risk contribution would be to change ``.. versionchanged

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

Tony R. added the comment: > My weak opinion is that a new parameter is a new API item, not just a change > in behaviour, so should probably have “versionadded”. This was my reasoning as well. Also, when I noticed so many instances of ``.. versionchanged`` that all say “Added

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

Tony R. added the comment: > Here are the original descriptions of the old LaTeX version. Holy crap! You all used to use LaTeX?! :D (I know--LaTeX is still going strong in academia. I just had no idea it was ever part of Python’s documentation, except as an output format.) > Ad

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

Tony R. added the comment: > Part of the problem is getting the granularity right. The initial intent was > that 'version*' were annotations for the enclosing object (function, class, > method, etc.). If we want to have something more granular (parameter > added / depr

[issue43001] python3.9.1 test_embed test_tabnanny failed

Tony Martin Berbel added the comment: I had the same error I ran the make test command with >&log But I don't know where to look for the log file -- nosy: +wingarmac ___ Python tracker <https://bugs.python

[issue43001] python3.9.1 test_embed test_tabnanny failed

Tony Martin Berbel added the comment: I found lastlog and attached it ! -- Added file: https://bugs.python.org/file49800/lastlog ___ Python tracker <https://bugs.python.org/issue43

[issue43001] python3.9.1 test_embed test_tabnanny failed

Tony Martin Berbel added the comment: My system crashed completely. I reinstalled Ubuntu. Sorry I couldn't help more ... :( ___ MARTIN BERBEL, Tony GSM: +32 (0) 477 / 33.12.48 -- Le mer. 10 févr. 2021 à 04:06, Tony M

<    1   2