[issue6171] Class Browser selection in Ubuntu
Serge added the comment: TreeNode class which is used in IDLE class browser create a window for a text label on each single click and apparently under Ubuntu tcl looses first left button click and therefore doesn't generate left buttond double click event. In this patch I make changes to the TreeNode class so it creates a window for a text label only when needed (i.e. during initialization or when it was delete after "collapse" command) -- components: +IDLE keywords: +patch nosy: +Serge Added file: http://bugs.python.org/file16168/idle_classbrowser.patch ___ Python tracker <http://bugs.python.org/issue6171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1094] TypeError in poplib.py
New submission from Serge Julien: In poplib.py, lines 137-138, bytes and str are compared, leading to a TypeError: [...] 137while line != '.': 138if line[:2] == '..': [...] where type(line) = -- components: Library (Lib) messages: 55617 nosy: serge.julien severity: normal status: open title: TypeError in poplib.py versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1094> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1094] TypeError in poplib.py
Serge Julien added the comment: Patch proposal. Tell me if it's right to submit it here: this is the first patch I submit __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1094> __ poplib.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38701] datetime.timedelta string representation is ambiguous
New submission from Serge Matveenko : Negative `timedelta` string representation is ambiguous. ``` >>> from datetime import datetime, timedelta >>> d2 = datetime.now() >>> d1 = d2 - timedelta(days=42, seconds=5) >>> str(d2 - d1) '42 days, 0:00:05' >>> str(d1 - d2) '-43 days, 23:59:55' ``` I would expect `str(d1 - d2)` to be one of the following: * '-42 days, 0:00:05' * '-(42 days, 0:00:05)' * '- 42 days, 0:00:05' -- components: Library (Lib) messages: 356041 nosy: lig priority: normal severity: normal status: open title: datetime.timedelta string representation is ambiguous type: behavior versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40616] Add `asyncio.BufferQueue`
New submission from Serge Matveenko : It looks handy to be able to leverage `collections.deque` ability to be sized it `asyncio.Queue`. This could provide the ability to implement backpressure in the queue or just use it as a buffer in messaging systems. The implementation provided in the linked PR. -- components: asyncio messages: 368788 nosy: asvetlov, lig, yselivanov priority: normal pull_requests: 19377 severity: normal status: open title: Add `asyncio.BufferQueue` ___ Python tracker <https://bugs.python.org/issue40616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38701] datetime.timedelta string representation is ambiguous
Serge Matveenko added the comment: I would be happy to submit a PR if there would be an agreement on the format. -- ___ Python tracker <https://bugs.python.org/issue38701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33953] The DEFAULT_ENTROPY variable used to store the current default random bytes value should be documented for `secrets` module
Change by Serge Matveenko : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue33953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33953] The DEFAULT_ENTROPY variable used to store the current default random bytes value should be documented for `secrets` module
Change by Serge Matveenko : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue33953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38701] datetime.timedelta string representation is ambiguous
Change by Serge Matveenko : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33953] The DEFAULT_ENTROPY variable used to store the current default random bytes value should be documented for `secrets` module
Change by Serge Matveenko : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40616] Add `asyncio.BufferQueue`
Change by Serge Matveenko : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14329] proxy_bypass_macosx_sysconf does not handle singel ip addresses correctly
New submission from Serge Droz : On MacOS in urllib the function proxy_bypass_macosx_sysconf does not handle proxy settings which are just IP addresses correctly: If there is any IP address, always true is reported. Reason: the mask is calculated wrong. The attached patch fixes this. NB This is also an issue in other python versions -- assignee: ronaldoussoren components: Macintosh files: urllib_macos.diff keywords: patch messages: 155973 nosy: Serge.Droz, ronaldoussoren priority: normal severity: normal status: open title: proxy_bypass_macosx_sysconf does not handle singel ip addresses correctly versions: Python 2.6 Added file: http://bugs.python.org/file24880/urllib_macos.diff ___ Python tracker <http://bugs.python.org/issue14329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36706] Python script on startup stucks at import
New submission from serge g : I am not sure if it is python's issue (correct me if this is wrong place for report). But sometimes (probably every 3-4 attempt) when I run script, interpreter just stucks for some time (0.5-3 minutes) and then actually runs the script normally. To figure out what happens I increased verbosity (python -vv) and actually python hangs on import on this line: ... # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.abi3.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.py # /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/__pycache__/scrypt.cpython-37.pyc matches /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.py # code object from '/home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/__pycache__/scrypt.cpython-37.(pyc' (here >>>>>) import 'cryptography.hazmat.primitives.kdf.scrypt' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6e3c73c8> import 'cryptography.hazmat.backends.openssl.backend' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6c129c88> import 'cryptography.hazmat.backends.openssl' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6d30d240> # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.cpython-37m-x86_64-linux-gnu.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.abi3.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.py # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.pyc ... I had version 3.5 installed before and didn't notice such issue. Other scripts from my project suffer from this symptom as well. My configuration is: debian 9 python 3.7.3 [GCC 6.3.0 20170516] on linux cryptography module – version 2.6.1 -- components: Library (Lib) messages: 340722 nosy: serge g priority: normal severity: normal status: open title: Python script on startup stucks at import type: performance versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33953] The DEFAULT_ENTROPY variable used to store the current default random bytes value should be documented for `secrets` module
New submission from Serge Matveenko : There is the corresponding section on the topic here https://github.com/python/cpython/blob/3.6/Doc/library/secrets.rst#how-many-bytes-should-tokens-use The current value of 32 bytes is mentioned there correctly. Unfortunately, there is no way to know which constant in the `secrets` stores this value. It is easy to imagine a use case to use say `DEFAULT_ENTROPY * 4` in the code and stay updated with the default entropy being increased over time. Thus, it looks reasonable to document the `secrets.DEFAULT_ENTROPY` constant in the module docs. -- assignee: docs@python components: Documentation messages: 320402 nosy: docs@python, lig priority: normal severity: normal status: open title: The DEFAULT_ENTROPY variable used to store the current default random bytes value should be documented for `secrets` module type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34104] email.message.get_payload should enforce correct encoding
New submission from Serge Droz : The issue is really this: https://noxxi.de/research/mime-5-easy-steps-to-bypass-av.html get_payload should with decode=Treu should check the validity of the syntax and throw an error if it is not. This would happen if the underlying call to base64.decode would be called with validate=True -- messages: 321574 nosy: droz priority: normal severity: normal status: open title: email.message.get_payload should enforce correct encoding ___ Python tracker <https://bugs.python.org/issue34104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34104] email.message.get_payload should enforce correct encoding
Change by Serge Droz : -- type: -> security ___ Python tracker <https://bugs.python.org/issue34104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: Dear Keith, that is exactly how it should be! (I cross-checked with a HP calculator to make sure.) -- ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: What most engineers would like to see implemented in Python is a new engineering notation identical to the one implemented in the omnipresent HP calculators. Quoting from the HP-15C Owner's Handbook: "- In engineering notation, the first significant digit is always present in the display. The number you key in after f ENG specifies the number of additional digits to which you want to round the display. - Engineering notation shows all exponents in multiples of three." Source + examples, see page 59: http://www.hp.com/ctg/Manual/c03030589.pdf Most of the time, engineers are not after high precision. Ball park figures are good enough in a world where everything is built to a specified tolerance. For example, most electronic resistors feature 5% tolerance. Safety factors take care of the rest and assure a building will not collapse. This should not be that difficult to implement? I promise, every six months an engineer will stop by here asking for this. Instead of nagging, this could already have been implemented one way or the other. The large demand for this feature really warrants it. Thanks! -- ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24546] sequence index bug in random.choice
New submission from Serge Anuchin: It seems there is minor bug in random.choice. I've got traceback from my server with IndexError from random.choice, but sequence wasn't empty (seq value was: u'\u0411\u0413\u0414\u0416\u0418\u041b\u0426\u042b\u042d\ u042e\u042f\u0410\u0412\u0415\u041a\u041c\u0420\u0422\ u042312456789') Maybe I mistaken, but only explanation that I have for this exception is rounding by int() of random value that was very close to 1. TL;RD: >>> int(0.5) 1 >>> seq = 'test' >>> seq[int(0.5 * len(seq))] # logic from random.choice IndexError: string index out of range Is it plausible explanation of exception or I'am wrong? ------ components: Library (Lib) messages: 246038 nosy: Serge Anuchin, mark.dickinson, rhettinger priority: normal severity: normal status: open title: sequence index bug in random.choice type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue24546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24546] sequence index bug in random.choice
Serge Anuchin added the comment: > Which platform & Python is that? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Linux li307-195 2.6.39.1-x86_64-linode19 #1 SMP Tue Jun 21 10:04:20 EDT 2011 x86_64 GNU/Linux -- ___ Python tracker <http://bugs.python.org/issue24546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24546] sequence index bug in random.choice
Serge Anuchin added the comment: > Serge, you'll have to find some way to get more information on exactly what > is failing in order for this issue to make progress. This exception occurred only once and I can't reproduce it. Additional system specs in attachment. -- Added file: http://bugs.python.org/file39870/additional_specs.txt ___ Python tracker <http://bugs.python.org/issue24546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25315] OrderedDict mangled private attribute is inaccessible
Serge Matveenko added the comment: Zach, ok I got your point. But there is Python implementation in the library still which does not conform the one done in C. Such a behavior is tremendously confusing. If there is both Python and C implementation in the library they must conform each other. And there is nothing with "you *really* shouldn't use this" when you need to especially when it is there. If it is there it must work as it written. Otherwise why Python does have this peace of code while it is completely useless as reference? -- resolution: wont fix -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue25315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25315] OrderedDict mangled private attribute is inaccessible
Serge Matveenko added the comment: If Python source does conform the one in C, it will be completely fine and understandable to have such a change and to rely on it in using version checks or whatever. -- ___ Python tracker <http://bugs.python.org/issue25315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25315] OrderedDict mangled private attribute is inaccessible
Serge Matveenko added the comment: Ok, then the OrderedDict is useless for any advanced hacking like altering the order in which __setitem__ stores items. It is just useless Python code and so much appliances missed for this class:( Thank you all for these completely helpful answers. -- ___ Python tracker <http://bugs.python.org/issue25315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25315] OrderedDict mangled private attribute is inaccessible
Serge Matveenko added the comment: Sorry for reopening. I completely agree with the point that is it not necessary for Python and C implementations to duplicate each other. But then the Python OrderedDict implementation should be dropped from the library source. The code that is there now is nothing more than confusing. For some one not aware of C implementation it is very hard to get from documentation that the code she sees via "Go to definition" feature of her IDE is not meant to be executing at all. -- resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue25315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: @rhettinger I completely agree with not creating a backward incompatibility at this point in time. The real issue is that decimal.to_eng_string() was written to a (unfortunately chosen) proprietary specification which does not entirely correspond to the engineering notation. A quick web search shows that a lot of people are in search of a *true* engineering notation implementation. In the phylosophy of "batteries included" it is a pity this useful and very common notation is currently missing in Python. I would therefore suggest adding a decimal.to_true_eng_string() with the true engineering notation. Hence, this bug could be reclassified as asuggestion for enhancement. -- ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
New submission from Serge Stroobandt: In https://docs.python.org/2/library/string.html#formatstrings the proprietary (IBM) specifcation "Decimal Arithmetic Specification" http://www.gobosoft.com/eiffel/gobo/math/decimal/daconvs.html is incorrectly being heralded as "the" specifiaction for engineering notation. However, upon reading this IBM specifation carefully, one will note that the specifaction itself actually admits not applying the engineering notation in the case of infinite numbers. An emphasized version of the exact quote accompanied with a discussion can be found here: http://stackoverflow.com/a/17974598/2192488 Correct behaviour for decimal.to_eng_string() would be to equally employ engineering notation in the case of infinite numbers. I suggest renaming the current behaviour to decimal.to_ibm_string(). References: http://www.augustatech.edu/math/molik/notation.pdf https://en.wikipedia.org/wiki/Engineering_notation https://en.wikipedia.org/wiki/General_Conference_on_Weights_and_Measures http://www.bipm.org/en/CGPM/db/11/11/ PS: I am a MSc in Electronic Engineering. -- components: Extension Modules files: engineering_notation.pdf messages: 259047 nosy: Keith.Brafford, eric.smith, ezio.melotti, serge.stroobandt priority: normal severity: normal status: open title: decimal.to_eng_string() does not implement engineering notation in all cases. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file41730/engineering_notation.pdf ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: An emphasized version of the exact quote is here now: http://stackoverflow.com/a/35045233/2192488 -- ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: Mark: Don't shoot the messenger! I literally quoted the implemented proprietary specification. However, I do agree that the term "numbers (or bases) with an infinte decimal representation" would be more appropriate in this context. Also, improving documentation is good, but having a new function with the desired *true* engineering notation would be even better! Admittedly, this was my ultimate objective for filing this enhancement bug. Thanks for commenting on StackExchange. -- type: behavior -> enhancement ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Serge Stroobandt added the comment: Related issue: https://bugs.python.org/issue8060 -- ___ Python tracker <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8060] PEP 3101 string formatting missing engineering presentation type for floating point
Serge Stroobandt added the comment: As per https://bugs.python.org/issue26223#msg259772 , can we please reopen this? I kind of hate it when *real* issues are kept closed for years (6!) until another lost soul comes by with the same itch... -- nosy: +serge.stroobandt versions: +Python 3.6 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue8060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
New submission from serge-sans-paille :
See https://bugs.llvm.org/show_bug.cgi?id=43830, but basically the follwing
code:
```
// a.c
#include
int main() {
Py_Initialize();
PyRun_SimpleString("import readline; print(readline.__doc__)");
return 0;
}
```
compiled like this:
```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -lpython3.9
```
runs fine:
```
% ./a.out
Importing this module enables command line editing using GNU readline.
```
However the following:
```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -ledit
-lpython3.9
```
compiles but segfaults at runtime.
--
messages: 355656
nosy: serge-sans-paille
priority: normal
severity: normal
status: open
title: Symbol resolution conflict when embeding python in an application using
libedit
type: crash
___
Python tracker
<https://bugs.python.org/issue38634>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Change by serge-sans-paille : -- keywords: +patch pull_requests: +16512 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16986 ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Change by serge-sans-paille : -- pull_requests: +16513 pull_request: https://github.com/python/cpython/pull/16986 ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
serge-sans-paille added the comment: @ned I(d rather see this as an evolution of Issue13631, as this solves a problem when libreadline and libedit are both loaded in the same executable. As such, using libedit instead of readline wouldn't solve the issue: what if the program Python is embeded in is linked to readline? I find python approach relatively elegant: detect the linked library at runtime and use the ad-hoc implementation based on this. An other option would be to dlopen readline using the RTLD_LOCAL flag, so that we get a better, non intrusive symbol resolution. What do you think? -- ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
New submission from serge-sans-paille : How to reproduce: ``` git clone https://github.com/python/cpython && cd cpython mkdir -p _build/optimized cd _build/optimized ../../configure --enable-optimizations CC=clang make cd .. ./optimized/python -m test.regrtest -wW --slowest -j0 --timeout=1800 2>&1 | grep "error: Could not read profile code.profclangd" ``` This bug no longer happens on master branch because it's related to test_peg_generator. -- components: Build messages: 379972 nosy: serge-sans-paille priority: normal severity: normal status: open title: Python 3.9 testing fails when building with clang and optimizations are enabled versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
Change by serge-sans-paille : -- keywords: +patch pull_requests: +21955 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23037 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
Change by serge-sans-paille : -- pull_requests: +22054 pull_request: https://github.com/python/cpython/pull/23141 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37140] ctypes change made clang fail to build
Change by serge-sans-paille : -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue37140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37140] ctypes change made clang fail to build
serge-sans-paille added the comment: @vstinner: to reproduce the issue ``` git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir _build cd _build cmake3 ../llvm -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/install -DPYTHON_EXECUTABLE=$HOME/sources/cpython/_build/install/bin/python3 make -j4 ``` -- ___ Python tracker <https://bugs.python.org/issue37140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36618] clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes
serge-sans-paille added the comment: @vstinner: once you have a portable version of alignof, you can deciding to *not* use the pool allocator if the required alignment is greater than 8B, or you could modify the pool allocator to take alignment information as an extra parameter? -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue36618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28015] configure --with-lto builds fail when CC=clang on Linux, requires gold linker
serge-sans-paille added the comment: Looks like a package dependency issue: installing ``llvm-dev`` package should fix the problem. Or in that particular case ``llvm-3.8-dev``. -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue28015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode
serge-sans-paille added the comment:
Not an expert of Python build, but I've been creating a few « reverse engineer
challenge » where I had to ship modified version of the interpreter, so played
with it a bit.
I agree consistency is nice to reason about. It looks better to me to *not*
link with libpython.so directly. This is probably better as this does not make
``libpython`` an install requirement (e.g. when one wants to embed a minimal
version of python)
As a short check, I ran
```
nm libpython3.so | grep ' [tT] ' | cut -d ' ' -f 3 | while read line; do nm
python | grep ' [tT] ' | cut -d ' ' -f 3 | grep $line >/dev/null || { echo
"bad: $line"; break; }; done
```
and everything looks fine, so all symbols should already be in the interpreter.
I've also checked whether that's an issue or not for user-defined native
extensions and everything runs smoothly without the explicit dep.
So the argument would be: why adding this dep when it's not needed?
--
nosy: +serge-sans-paille
___
Python tracker
<https://bugs.python.org/issue34814>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25315] OrderedDict mangled private attribute is inaccessible
New submission from Serge Matveenko (lig):
Consider this code in Python 3.5.0:
Python 3.5.0 (default, Sep 26 2015, 14:59:25)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
... def __setitem__(self, *args, **kwargs):
... print(self._OrderedDict__root)
... OrderedDict.__setitem__(self, *args, **kwargs)
...
>>> md = MyDict({'a': 1})
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in __setitem__
AttributeError: 'MyDict' object has no attribute '_OrderedDict__root'
However in Python 3.4:
Python 3.4.2 (default, Jul 9 2015, 17:24:30)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
... def __setitem__(self, *args, **kwargs):
... print(self._OrderedDict__root)
... OrderedDict.__setitem__(self, *args, **kwargs)
...
>>> md = MyDict({'a': 1})
--
components: Library (Lib)
messages: 252296
nosy: Serge Matveenko (lig)
priority: normal
severity: normal
status: open
title: OrderedDict mangled private attribute is inaccessible
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue25315>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25657] virtualenv's activate does not update LD_LIBRARY_PATH
New submission from serge-sans-paille: My use cas of virtual env was the following: 1. create a virtual env 2. install a third party shared library and its python wrapper 3. import the wrapper that itself loads the shared library The problem is that the shared library gets install into /lib (which is a normal behavior) but virtualenv's activate does not update LD_LIBRARY_PATH A possible fix would be to add the following lines into virtualenv's activate: ``` if [ -n "$_OLD_VIRTUAL_LD_LIBRARY_PATH" ] ; then PATH="$_OLD_VIRTUAL_LD_LIBRARY_PATH" export LD_LIBRARY_PATH unset _OLD_VIRTUAL_LD_LIBRARY_PATH fi ``` and a bit later ``` _OLD_VIRTUAL_LD_LIBRARY_PATH="$LD_LIBRARY_PATH" LD_LIBRARY_PATH="$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH ``` in a simialr manner to what is done with `PATH` -- messages: 254845 nosy: serge-sans-paille priority: normal severity: normal status: open title: virtualenv's activate does not update LD_LIBRARY_PATH type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25657] virtualenv's activate does not update LD_LIBRARY_PATH
serge-sans-paille added the comment: ok, I'll report there then. Sorry for the noise :-/ -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue25657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
