[issue36155] ./python -m test -m test_gc fails

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

It seems that some collection from some other test is happening between the 
three calls to get_objects:

self.assertIn(l, gc.get_objects(generation=0))
self.assertNotIn(l, gc.get_objects(generation=1))
self.assertNotIn(l, gc.get_objects(generation=2))

The easiest solution is deactivating the gc at the beginning of the test and 
reactivating it afterwards, as the test is relying on manual collection. In 
this way, external collections cannot affect the test. I will prepare a PR.

--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[Larry Hastings]

Change by Larry Hastings :


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

___
Python tracker 

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

[issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0

[Larry Hastings]

Larry Hastings  added the comment:


New changeset 56f8783e3e32ddc0cb84a96711e3861aea9895ac by larryhastings (Alex 
Viscreanu) in branch '3.5':
[3.5] bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210) (#10994)
https://github.com/python/cpython/commit/56f8783e3e32ddc0cb84a96711e3861aea9895ac


--
nosy: +larry

___
Python tracker 

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

[issue36155] ./python -m test -m test_gc fails

[Karthikeyan Singaravelan]

New submission from Karthikeyan Singaravelan :

I am not sure of the exact cause about this failure but `./python.exe -m test 
-m test_gc` fails though `./python.exe -m test -v test_gc` passes. This test 
was recently added with 175421b58cc97a2555e474f479f30a6c5d2250b0 and issue36016.

./python.exe -m test -m test_gc
== CPython 3.8.0a2+ (heads/master:f684d83d86, Mar 1 2019, 10:39:16) [Clang 
7.0.2 (clang-700.1.81)]
== macOS-10.10.4-x86_64-i386-64bit little-endian
== cwd: 
/Users/karthikeyansingaravelan/stuff/python/cpython/build/test_python_21045
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.85 [  1/420] test_grammar
[snip]
0:00:36 load avg: 2.17 [156/420] test_gc -- test_future5 run no tests
test test_gc failed -- Traceback (most recent call last):
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_gc.py", line 
775, in test_get_objects
self.assertNotIn(l, gc.get_objects(generation=2))
AssertionError: [[...]] unexpectedly found in 
0:00:48 load avg: 2.14 [157/420/1] test_gdb -- test_gc failed

--
components: Tests
messages: 336898
nosy: inada.naoki, pablogsal, xtreak
priority: normal
severity: normal
status: open
title: ./python -m test -m test_gc fails
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue36103] Increase shutil.COPY_BUFSIZE

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +patch
pull_requests: +12121
stage:  -> patch review

___
Python tracker 

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

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[David Bolen]

David Bolen  added the comment:

I suspect changes for this issue may be creating test_io failures on my windows 
builders, most notably my x86 Windows 7 builder where test_io has been failing 
both attempts on almost all builds.  It fails with a lock failure during 
interpreter shutdown, and commit ef4ac967 appears the most plausible commit out 
of the set introduced at the first failing build on Feb 24.

See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first 
failure.  test_io has failed both attempts on all but 3 of the subsequent 16 
tests of the 3.x branch.

It might be worth noting that this builder is slow, so if there are timeouts 
involved or a race condition of any sort it might be triggering it more readily 
than other builders.  I do, however, see the same failures - albeit less 
frequently and not usually on both tries - on the Win8 and Win10 builders.

For what it's worth one other oddity is that while having test_multiprocessing* 
failures are relatively common on the Win7 builder during the first round of 
tests due to exceeding the timeout, they usually pass on the retry, but over 
this same time frame have begun failing - not due to timeout - even on the 
second attempt, which is unusual.  It might be coincidental but similar 
failures are also showing up sporadically on the Win8/Win10 builders where such 
failures are not common at all.

--
nosy: +db3l

___
Python tracker 

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

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

[Saba Kauser]

Saba Kauser  added the comment:

Thanks  Karthikeyan!

--

___
Python tracker 

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

[issue36018] Add a Normal Distribution class to the statistics module

[miss-islington]

miss-islington  added the comment:


New changeset 9add4b3317629933d88cf206a24b15e922fa8941 by Miss Islington (bot) 
(Raymond Hettinger) in branch 'master':
bpo-36018: Add documentation link to "random variable" (GH-12114)
https://github.com/python/cpython/commit/9add4b3317629933d88cf206a24b15e922fa8941


--

___
Python tracker 

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

[issue36018] Add a Normal Distribution class to the statistics module

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +12120

___
Python tracker 

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

[issue29539] [smtplib] collect response data for all recipients

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3)  added the comment:

i have a fully built patch and personally tested (i use it 24/7) but
haven't done test_* yet as was requested

On Thu, Feb 28, 2019 at 9:16 PM Windson Yang  wrote:

>
> Windson Yang  added the comment:
>
> sls, are you working on this feature now?
>
> --
> nosy: +Windson Yang
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue36072] str.translate() behaves differently for ASCII-only and other strings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree.  The fact the CPython attempts to optimize all_ascii.translate(table) 
is a CPython implementation detail, not a language feature.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue36154] Python quit unexpectedly error

[kellena]

New submission from kellena :

I'm on a Mac running Mojave, version 10.14.3. I installed Python 3.7. I'm now 
getting a "Python quit unexpectedly" error consistently and I don't know why or 
if I did something to cause it. I've tried uninstalling and reinstalling but 
I'm still getting the error. I've checked online resources such as Stack 
Overflow and "reinstall" is pretty much the standard suggestion, which I've 
already done.

Here's the full error. Please tell me how to fix this:

> Process:   Python [7756]
> Path:  
> /Library/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
> Identifier:Python
> Version:   3.7.2 (3.7.2)
> Code Type: X86-64 (Native)
> Parent Process:Code Helper [785]
> Responsible:   Python [7756]
> User ID:   501
> 
> Date/Time: 2019-02-27 16:27:29.136 -0600
> OS Version:Mac OS X 10.14.3 (18D109)
> Report Version:12
> Bridge OS Version: 3.3 (16P3133)
> Anonymous UUID:DB5CA6AD-7D99-F9D4-0475-D401946AB77E
> 
> Sleep/Wake UUID:   D7171268-D6D9-464C-B881-A97EE3C3AB2D
> 
> Time Awake Since Boot: 17000 seconds
> Time Since Wake:   420 seconds
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Application Specific Information:
> dyld2 mode
> abort() called
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib0x7fff6b87723e __pthread_kill + 10
> 1   libsystem_pthread.dylib   0x7fff6b92dc1c pthread_kill + 285
> 2   libsystem_c.dylib 0x7fff6b7e01c9 abort + 127
> 3   org.python.python 0x0001049ff420 fatal_error + 592
> 4   org.python.python 0x0001049fe784 _Py_FatalInitError + 
> 36
> 5   org.python.python 0x000104a27031 pymain_main + 7921
> 6   org.python.python 0x000104a2713a _Py_UnixMain + 58
> 7   libdyld.dylib 0x7fff6b737ed9 start + 1
> 
> Thread 0 crashed with X86 Thread State (64-bit):
>   rax: 0x  rbx: 0x00010b3955c0  rcx: 0x7ffeeb313e88  
> rdx: 0x
>   rdi: 0x0307  rsi: 0x0006  rbp: 0x7ffeeb313ec0  
> rsp: 0x7ffeeb313e88
>r8: 0x   r9: 0xb7d055e4  r10: 0x  
> r11: 0x0206
>   r12: 0x0307  r13: 0x7fff9e5139a0  r14: 0x0006  
> r15: 0x002d
>   rip: 0x7fff6b87723e  rfl: 0x0206  cr2: 0x7fff9e511188
>   
> Logical CPU: 0
> Error Code:  0x02000148
> Trap Number: 133
> 
> 
> Binary Images:
>0x1048eb000 -0x1048ebfff +org.python.python (3.7.2 - 3.7.2) 
> <122E5A60-3D65-3759-AD3F-54658AA10863> 
> /Library/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
>0x1048f3000 -0x104accff7 +org.python.python (3.7.2, [c] 
> 2001-2018 Python Software Foundation. - 3.7.2) 
> <779A7040-54B9-3956-85A6-C3CFE0C5A52A> 
> /Library/Frameworks/Python.framework/Versions/3.7/Python
>0x10b2df000 -0x10b35da87  dyld (655.1) 
> <3EBA447F-A546-366B-B302-8DC3B21A3E30> /usr/lib/dyld
> 0x7fff3e4af000 - 0x7fff3e8fcfef  com.apple.CoreFoundation (6.9 - 
> 1562) <02A2C178-9FF6-385C-A9C5-7F4FC9D66311> 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> 0x7fff687f9000 - 0x7fff687faff7  libDiagnosticMessagesClient.dylib 
> (107) <15210AC0-61F9-3F9D-A159-A009F62EB537> 
> /usr/lib/libDiagnosticMessagesClient.dylib
> 0x7fff68bab000 - 0x7fff68bacffb  libSystem.B.dylib (1252.200.5) 
>  /usr/lib/libSystem.B.dylib
> 0x7fff68e05000 - 0x7fff68e5cff7  libc++.1.dylib (400.9.4) 
>  /usr/lib/libc++.1.dylib
> 0x7fff68e5d000 - 0x7fff68e72fff  libc++abi.dylib (400.17) 
> <446F4748-8A89-3D2E-AE1C-27EEBE93A8AB> /usr/lib/libc++abi.dylib
> 0x7fff69ac1000 - 0x7fff69d24ffb  libicucore.A.dylib (62109.0.1) 
>  /usr/lib/libicucore.A.dylib
> 0x7fff6a653000 - 0x7fff6add9fe7  libobjc.A.dylib (750.1) 
> <804715F4-F52D-34D0-8FEC-A25DC08513C3> /usr/lib/libobjc.A.dylib
> 0x7fff6b536000 - 0x7fff6b548ffb  libz.1.dylib (70.200.4) 
> <15F7B40A-424C-33BB-BF2C-7E8195128B78> /usr/lib/libz.1.dylib
> 0x7fff6b5b9000 - 0x7fff6b5bdff3  libcache.dylib (81) 
> <704331AC-E43D-343A-8C24-39201142AF27> /usr/lib/system/libcache.dylib
> 0x7fff6b5be000 - 0x7fff6b5c8ff3  libcommonCrypto.dylib (60118.220.1) 
> <9C865644-EE9A-3662-AB77-7C8A5E561784> /usr/lib/system/libcommonCrypto.dylib
> 0x7fff6b5c9000 - 0x7fff6b5d0fff  libcompiler_rt.dylib (63.4) 
> <817772E3-E836-3FFD-A39B-BDCD1C357221> 

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

@sabakauser You can find python-list mailing list here : 
https://mail.python.org/mailman/listinfo/python-list

--
nosy: +xtreak

___
Python tracker 

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

[issue36066] Add `empty` block to `for` and `while` loops.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Syntax changes need PEPs.  By default, syntax changes are rejected.  This is 
especially true for new keywords, as any acceptible word will already be in 
use, and hence its introduction *will* break code.

We are still having issues over having temporarily made 'async' and 'await' 
'semi-keywords' (for 2 versions) to smooth out breakage.  So new keywords must 
enable something previously difficult.  But implementing the 'empty' idea is 
fairly trivial, as demonstrated in the initial post.

A third alternative is a peak(iterator) class with a __bool__ method.  I posted 
one once, probably on python-list.  But the extra overhead every iteration must 
be larger than the simple assignment, which is so fast one should not worry 
about it.  I suspect the flag also beats the chain alternative.
---

[More opinionated than the above ...]

Calling what is easy and works today 'non-idiomatic' is nearly pure opinion and 
not persuasive as a rhetorical device.

The complicated rules for else-never interaction to be far more 
'anti-idiomatic' from a comprehension point of view.  In any case, a flag 
allows easy, flexible, and precise ordering of never, something, and either-way 
code.

--
nosy: +terry.reedy
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

[Saba Kauser]

Saba Kauser  added the comment:

Could you please share the URL

--

___
Python tracker 

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

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I suspect that this may not be a cpython issue, in which case, it should be 
closed here as 'not-a-bug'.  I suggest that you present this on python-list and 
ask 'where is the bug most likely to be?'  You should get more readers there.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue36122] Second run of 2to3 continues to modify output

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> not a bug
type: enhancement -> behavior

___
Python tracker 

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

[issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12119

___
Python tracker 

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

[issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f684d83d86e1990784816d4b243d724e6ab8304f by Victor Stinner in 
branch 'master':
bpo-36142: Exclude coreconfig.h from Py_LIMITED_API (GH-12111)
https://github.com/python/cpython/commit/f684d83d86e1990784816d4b243d724e6ab8304f


--

___
Python tracker 

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

[issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12118

___
Python tracker 

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

[issue29539] [smtplib] collect response data for all recipients

[Windson Yang]

Windson Yang  added the comment:

sls, are you working on this feature now?

--
nosy: +Windson Yang

___
Python tracker 

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

[issue36153] Freeze support documentation is misleading.

[Windson Yang]

Windson Yang  added the comment:

IIUC, your script (using Sklearn/tensorflow) will cause an infinite loop when 
building with pyinstaller. Would you mind upload an example script so I can try 
to reproduce it?

--
nosy: +Windson Yang

___
Python tracker 

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

[issue36152] IDLE: Remove close_when_done from colorizer close()

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thanks for digging up the history.  I would have approved without, but feel 
better with.  Using the colorizer close method to close a window seemed flakey 
to me, and it seems someone else thought the same long ago.  I suspect the 
machinery was left to avoid breaking external uses.  PEP 434 changed this 
avoidance being *necessary*.  (I am sure I have seen a SO answer with 
percolator + colorizer, as in turtledemo.)

IDLE has had a too many shutdown bugs and still has some.  Not adding one was 
my main concern when reviewing.

--

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[STINNER Victor]

STINNER Victor  added the comment:

AppVeyor failed on the backport to Python 3.7 of my fix: PR 12108.

Ok, now I understand the bug in Python 3.7. 
locale.getlocale(locale.LC_CTYPE)[1] returns None because Python doesn't set 
LC_CTYPE to the user preferred locale. I'm not sure of which locale is used in 
practice in that case, but at least I can say that None is not the expected 
encoding name... str.encode() and bytes.decode() use UTF-8 when None is passed 
as the encoding. locale.getpreferredencoding() returns 'cp1252' which is the 
ANSI code page.

Python 3.8 is different. In bpo-34485, I modified Python 3.8 to set LC_CTYPE 
locale to the user preference (ANSI code page):
---
commit 177d921c8c03d30daa32994362023f777624b10d
Author: Victor Stinner 
Date:   Wed Aug 29 11:25:15 2018 +0200

bpo-34485, Windows: LC_CTYPE set to user preference (GH-8988)

On Windows, the LC_CTYPE is now set to the user preferred locale at
startup: _Py_SetLocaleFromEnv(LC_CTYPE) is now called during the
Python initialization. Previously, the LC_CTYPE locale was "C" at
startup, but changed when calling setlocale(LC_CTYPE, "") or
setlocale(LC_ALL, "").

pymain_read_conf() now also calls _Py_SetLocaleFromEnv(LC_CTYPE) to
behave as _Py_InitializeCore(). Moreover, it doesn't save/restore the
LC_ALL anymore.

On Windows, standard streams like sys.stdout now always use
surrogateescape error handler by default (ignore the locale).
---

--

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Steve Dower]

Steve Dower  added the comment:

The sitecustomize.py file is totally available, and the only limitation there 
is packages can't inject themselves into it on installation. And if you want to 
trigger it on a package import then you totally can (though there's *another* 
discussion about that being a bad idea).

.pth files really only satisfy the "run at startup because I'm a dependency of 
something that my user wants and don't make them opt-in to my changed 
behaviour", which I don't like :)

If encodings need to be available without an explicit import, sure, we can add 
a point for those. Import hooks can always be injected by a package __init__.py 
before the importer will try and resolve the module, so nothing is needed 
there. But having a PEP with specific use cases to argue about is the way to 
create new mechanisms here. I don't agree we need a solution before declaring 
that the old way should be avoided and will eventually be removed, provided we 
don't add noisy warnings until there's an alternative.

--

___
Python tracker 

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

[issue36153] Freeze support documentation is misleading.

[Sridhar Iyer]

New submission from Sridhar Iyer :

The documentation on freeze_support listed on 
https://docs.python.org/3/library/multiprocessing.html need to be fixed

This mentions:
"Calling freeze_support() has no effect when invoked on any operating system 
other than Windows. In addition, if the module is being run normally by the 
Python interpreter on Windows (the program has not been frozen), then 
freeze_support() has no effect."

This is not true. Sklearn/tensorflow libraries tend to cause an infinite loop 
when frozen with pyinstaller (tested on python 3.6 on ubuntu 14.04). 
freeze_support is the only way to get around the situation and should be 
included before including any other module that includes a multiprocessing 
library (not just in main).

--
assignee: docs@python
components: Documentation
messages: 336881
nosy: Sridhar Iyer, docs@python
priority: normal
severity: normal
status: open
title: Freeze support documentation is misleading.
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Ivan Pozdeev]

Change by Ivan Pozdeev :


--
pull_requests: +12117

___
Python tracker 

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

[issue36152] IDLE: Remove close_when_done from colorizer close()

[Cheryl Sabella]

Change by Cheryl Sabella :


--
assignee: cheryl.sabella -> terry.reedy

___
Python tracker 

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

[issue36152] IDLE: Remove close_when_done from colorizer close()

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +12116
stage:  -> patch review

___
Python tracker 

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

[issue36152] IDLE: Remove close_when_done from colorizer close()

[Cheryl Sabella]

New submission from Cheryl Sabella :

Remove the unused `close_when_done` parameter from `close()` in 
`colorizer.ColorDelegator()`.

* The second parameter to close() is called `close_when_done` and it is 
expected to contain a toplevel widget that has a destroy() method.

* Originally, the editor window had code that would send self.top (if 
colorizing was in process) as the value for this parameter:

doh = colorizing and self.top
self.color.close(doh) # Cancel colorization

* This was changed via this commit 
(https://github.com/python/cpython/commit/8ce8a784bd672ba42975dec752848392ff9a7797)
 in 2007 to instead be:
 
self.color.close(False)
self.color = None

The value of `False` made it so the destroy code in colorizer wouldn't be run 
even though `None` or leaving the parameter off would have been more clear.

In any case, this `close_when_done` hasn't been used since 2007.

--
assignee: cheryl.sabella
components: IDLE
messages: 336880
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Remove close_when_done from colorizer close()
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue35975] Put back the ability to parse files where async/await aren't keywords

[Guido van Rossum]

Guido van Rossum  added the comment:

> Would not be simpler to just drop the support of Python versions <3.7 in new 
> MyPy versions?

Not really -- mypy has a lot of users who run it over (very) large code bases 
that can't easily be upgraded. Basically mypy has to support all Python 
versions that haven't reached their end of life yet. (And it's also important 
that mypy not be constrained to the same Python version as the target code.)

I suppose we could just stick with the existing typed_ast that supports 3.4 
through 3.7, but we actually have a use case for the end_lineno and 
end_col_offset fields that were just added to ast in 3.8, and in general we'd 
like to support any future grammar elements and ast features.

--

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[miss-islington]

Change by miss-islington :


--
pull_requests: +12115

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ab71f8b793f7b42853ccd2a127ae7720adc5bcb4 by Victor Stinner in 
branch 'master':
bpo-29571: Fix test_re.test_locale_flag() (GH-12099)
https://github.com/python/cpython/commit/ab71f8b793f7b42853ccd2a127ae7720adc5bcb4


--

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[STINNER Victor]

STINNER Victor  added the comment:

> This seems to have broken test_re on Windows, see 
> https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.1

It seems like the ANSI code page is 1252 ("cp1252").

== CPython 3.7.0a0 (master:d31b28e16a2387d0251df948ef5d1b33d4357652, Mar 5 
2017, 21:47:06) [MSC v.1900 32 bit (Intel)]
==   Windows-2012ServerR2-6.3.9600-SP0 little-endian
==   hash algorithm: siphash24 32bit
==  cwd: C:\projects\cpython\build\test_python_1844
==  encodings: locale=cp1252, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, 
verbose=0, bytes_warning=2, quiet=0, hash_randomization=1, isolated=0)
Using random seed 5949816

...

FAIL: test_locale_flag (test.test_re.ReTests)
--
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_re.py", line 1422, in test_locale_flag
self.assertTrue(pat.match(bletter))
AssertionError: None is not true

> getpreferredencoding() takes a completely different path on windows
> (returns a codepage) and isn't related to the C locale.

On my Windows 10 with Python 3.8, getpreferredencoding() (and 
getpreferredencoding(False)) returns "cp1252", getlocale(LC_CTYPE)[1] returns 
"1252". Python has an alias "1252" for "cp1252".

On Windows, getpreferredencoding() is implemented as 
_locale._getdefaultlocale()[1]. _getdefaultlocale()[1] is implemented with:

PyOS_snprintf(encoding, sizeof(encoding), "cp%d", GetACP());

At the end, it's the ANSI code page (1252).

--

I don't understand how the change ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 
introduced a regression. And so I don't understand how commit 
21a74312f2d1ddee71fade709af49d078085ec30 (revert) could fix anything.

--

On my PR 12099, two Windows CI run and both succeeded:

* AppVeyor: pythoninfo says "locale.encoding: cp1252"
  https://ci.appveyor.com/project/python/cpython/builds/22726025
* Windows PR Tests on Azure Pipeline: pythoninfo also says "locale.encoding: 
cp1252"

When the change ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 was merged, Python had 
no working Windows CI. Things evolved at lot in the meanwhile.

I also tested manually my PR 12099 on my Windows 10 VM which also uses cp1252: 
test_re pass.

--

re.LOCALE flag of re.compile() for a bytes pattern uses the following function 
of Modules/_sre.c:

LOCAL(int)
char_loc_ignore(SRE_CODE pattern, SRE_CODE ch)
{
return ch == pattern
|| (SRE_CODE) sre_lower_locale(ch) == pattern
|| (SRE_CODE) sre_upper_locale(ch) == pattern;
}

--

___
Python tracker 

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

Re: Lifetime of a local reference

[Chris Angelico]

On Fri, Mar 1, 2019 at 9:31 AM Marko Rauhamaa  wrote:
>
> Roel Schroeven :
> > In the absence of any other mention of bindings being removed, to me
> > it seems clear that bindings are not automatically removed. Otherwise
> > many things become ambiguous. Example: the documentation for dicts
> > defines "d[key] = value" as "Set d[key] to value". Does that mean it
> > can get unset later behind your back? Of course not.
>
> Nothing is so obvious here.
>
> A Python implementation is free to do anything at all that complies with
> correct semantics. Sometimes correct behavior is unspecified.
>
> In your case, "d[key] = value", the binding can disappear if the name d
> becomes "stale". d[key] will be bound if anybody should look but if the
> compiler or runtime environment can prove nobody will every look, it
> might be able to optimize it away.

The point was that so long as d exists, so does d[key]. There is no
way for d[key] to legitimately become "stale" and expired. There is
also no way for a function local name to become "stale" while it's
running. They are attributes of the function's context.

> If you accept that
>
>open("xyz")
>
> can silently close the file immediately, sometime later or never, you
> should have no problem believing that
>
>f = open("xyz")
>
> could behave the same way.

No, because 'f' is a name.

> > It's purely an implementation detail. As long as the visible behavior
> > of the program complies with the language specification, the compiler
> > can do as it wishes.
>
> And that's the key: what is specified for Python? It would appear
> nothing has been stated explicitly so it would be dangerous for a Python
> application to rely on assumed semantics.

Not true.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29539] [smtplib] collect response data for all recipients

[sls]

sls  added the comment:

Did you make a PR ? I didn't notice this issue and did a quick fix: 
https://github.com/python/cpython/pull/12104

I was hoping this or similar fixes would be implemented in 3.7.x

Anyways. I'd suggest to return both success and errors for each recipient. 
sendmail returns a dict already. Why not adding each status?

Maybe using something like "mta_result" as variable instead of senderrs, which 
is in my opinion more clear to understand. Also, this would have the advantage 
to parse the return value easily and you're able to access more verbose 
information like mta msg id and so on.

--

___
Python tracker 

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

Re: Lifetime of a local reference

[Marko Rauhamaa]

Roel Schroeven :
> In the absence of any other mention of bindings being removed, to me
> it seems clear that bindings are not automatically removed. Otherwise
> many things become ambiguous. Example: the documentation for dicts
> defines "d[key] = value" as "Set d[key] to value". Does that mean it
> can get unset later behind your back? Of course not.

Nothing is so obvious here.

A Python implementation is free to do anything at all that complies with
correct semantics. Sometimes correct behavior is unspecified.

In your case, "d[key] = value", the binding can disappear if the name d
becomes "stale". d[key] will be bound if anybody should look but if the
compiler or runtime environment can prove nobody will every look, it
might be able to optimize it away.

If you accept that

   open("xyz")

can silently close the file immediately, sometime later or never, you
should have no problem believing that

   f = open("xyz")

could behave the same way.

> It's purely an implementation detail. As long as the visible behavior
> of the program complies with the language specification, the compiler
> can do as it wishes.

And that's the key: what is specified for Python? It would appear
nothing has been stated explicitly so it would be dangerous for a Python
application to rely on assumed semantics.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33944] Deprecate and remove pth files

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

On second thought, the inability to debug code that runs at startup, before 
user code ever gets control, is a fundamental issue (this problem arises for 
any software that has startup code), so such a facility in stock codebase has a 
merit.

--

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Ivan Pozdeev]

Change by Ivan Pozdeev :


--
pull_requests: +12114

___
Python tracker 

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

[issue36151] Incorrect answer when calculating 11/3

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Aiden: in the future, please do not post unnecessary screenshots of text. They 
are hostile to the blind and slight-impaired, they make it impossible to copy 
your code and run it ourselves, and they cannot be searched for.

Instead, copy and paste the text demonstrating the code and the results:

py> 11/3
3.6665


Thank you.

Zachary: while the rest of your comments were excellent, please don't tell 
people that Decimal is "exact". Decimal is a floating point format just like 
floats are, and so suffers the same kinds of rounding errors as binary floats. 
In fact, Decimal often suffers from larger rounding errors than binary, which 
is why serious numeric data scientists still use binary float.

The advantages of Decimal over binary float is that you can configure how much 
precision is used, and that any number you can write out exactly in base 10 can 
be represented exactly as a Decimal. But it still has to round off values which 
cannot be represented exactly as Decimals.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue36151] Incorrect answer when calculating 11/3

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To add to Zach's answer:

Please do not mark issues for IDLE just because you use IDLE to send your code 
to Python and display the returned string answer. If in any doubt, rerun the 
same code directly with Python either interactively or from the command line.  
(Note: Windows requires "", not '', on command line.)

C:\Users\Terry>python -c "print(11/3)"
3.6665 

As for the result: 11/3 cannot be exactly represented as a binary (or decimal) 
finite-precision floating point number.  In this case, the nearest binary float 
is less that 11/3.  Python prints floats with up to 17 decimal digits.We 
can get more with the decimal module.

>>> decimal.Decimal(11/3)
Decimal('3.666518636930049979127943515777587890625')

We can also check with decimal float literals
>>> 11/3 == 3.6665)
True

This expression is true for all 18 digit literals from
3.66630 to
3.66674

It would have been better to ask about 11/3 on python-list (for instance), 
where other beginners could see the answer, rather than here.  I will repost my 
answer there.

--

___
Python tracker 

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

[issue29539] [smtplib] collect response data for all recipients

[R. David Murray]

Change by R. David Murray :


--
nosy: +sls

___
Python tracker 

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

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

[R. David Murray]

R. David Murray  added the comment:

Sorry, that should be #29539.

--
superseder: Deprecate string concatenation without plus -> [smtplib] collect 
response data for all recipients

___
Python tracker 

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

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

[R. David Murray]

R. David Murray  added the comment:

Thanks for the PR, but this is a duplicate of #29539, which I think has a 
better API proposal.  Since the original author never actually submitted a PR 
there, perhaps you could pick up his work (after pinging the issue).

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Deprecate string concatenation without plus
versions: +Python 3.8 -Python 3.7

___
Python tracker 

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

[issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce()

[Christian Heimes]

Christian Heimes  added the comment:

Yes, N and O accept NULL and pass the exception up the call stack. It's not a 
bug. 
https://docs.python.org/3/c-api/arg.html?highlight=py_buildvalue#c.Py_BuildValue

--
nosy: +christian.heimes
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue36151] Incorrect answer when calculating 11/3

[Zachary Ware]

Zachary Ware  added the comment:

This has nothing to do with IDLE and everything to do with how floating point 
numbers work; have a read through 
https://docs.python.org/3/tutorial/floatingpoint.html for an introduction to 
floating point.  If you need exact decimal math, use the `decimal` module 
instead.

--
assignee: terry.reedy -> 
components:  -IDLE
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Incorrect answer when calculating 11//3 -> Incorrect answer when 
calculating 11/3

___
Python tracker 

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

[issue36151] Incorrect answer when calculating 11//3

[Aiden Zhou]

Change by Aiden Zhou :


Removed file: https://bugs.python.org/file48180/Screenshot (102)_LI.jpg

___
Python tracker 

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

Re: dash/underscore on name of package uploaded on pypi

[Terry Reedy]

On 2/28/2019 11:09 AM, ast wrote:

Hello

I just uploaded a package on pypi, whose name is "arith_lib"

The strange thing is that on pypi the package is renamed "arith-lib"
The underscore is substitued with a dash

If we search for this package:

pip search arith

arith-lib (2.0.0) - A set of functions for miscellaneous arithmetic
(so a dash)

For installation both:

pip install -U arith_lib
pip install -U arith-lib

are working well

and in both case I got a directory with an underscore

C:\Program Files\Python36-32\Lib\site-packages

28/02/2019  16:57      arith_lib
28/02/2019  16:57      arith_lib-2.0.0.dist-info

What happens ?


To expand on Paul's answer.

English uses '-' both as a connector for compound names and as a 
subtraction operator.  Context usually makes the choice obvious.  But 
context-free parsers must choose just one, and for computation, 
subtraction wins.  'arith-lib' is parsed as (arith) - (lib).  Many 
algorithm languages use '_' instead of '-' as the compounder for 
identifiers (object names).


In addition,  Python uses filenames -(minus) '.py' as identifiers for 
imported modules.  So if the repository allows '-' in package names, 
installers must convert '-' to '_'.  But if the repository allows 
'arith_lib' and 'arith-lib' to be distinct names for different packages, 
both would be installed with the same file name.  So the repository 
standardizes on one form, and it went with English instead of Pythonese.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

[issue36151] Incorrect answer when calculating 11//3

[Aiden Zhou]

Change by Aiden Zhou :


Added file: https://bugs.python.org/file48180/Screenshot (102)_LI.jpg

___
Python tracker 

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

[issue36151] Incorrect answer when calculating 11//3

[Aiden Zhou]

New submission from Aiden Zhou :

When calculating 11//3, the last digit of the decimals is wrongly rounded to 5 
as obviously it needs to be rounded to 7. IDLE (Python 3.7 32-bit)

--
assignee: terry.reedy
components: IDLE
files: Screenshot (102)_LI.jpg
messages: 336868
nosy: azihdoeun, terry.reedy
priority: normal
severity: normal
status: open
title: Incorrect answer when calculating 11//3
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48179/Screenshot (102)_LI.jpg

___
Python tracker 

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

Re: Need help with Python3.4 and Avro

[Terry Reedy]

On 2/28/2019 11:19 AM, Mihir Kothari wrote:


I am not sure if this is the right list, but trying to get help from
experienced python users for my issue.


This is a good place to get a somewhat different set of such people.


I have posted the issue in stackoverflow, but yet to see any response. I am
trying my luck here.

I have my question here: https://stackoverflow.com/q/54833834/3165644


You should edit the title and body of your SO question.

Titles should get the attention of people who might be able to answer, 
and not push them away.  Including '3.4' in the title implies that 
specific practical knowledge of 3.4 is essential.  The fraction of 
'experienced Python users' using 3.4 is around .01  You can mention in 
the body that you are currently using 3.4, but I do not expect that this 
is completely essential to your problem, or an answer.  An answer given 
for 3.7, say, should very likely run on 3.4, or be modifiable to do.


In the title, I would change 'Avro' to the more specific 'Apache Avro'.

Copy and paste the complete traceback in the body.  Format it as code.

> If needed, I can give the details in this email too, please let me know.

I believe most people consider stackoverflow to be a safe link to click 
on.  However, a brief summary would more likely get such a click.


"When trying to convert an Avro schema to JSON, I get
  AvroError(sp?): Tha datum is not the example of schema"
['AvroError is hypothesized since not given.  The spelling error 
indicates that the message was re-typed instead of pasted.]


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

[issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Does not Py_BuildValue() check the argument for "N" for NULL?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: Lifetime of a local reference

[Roel Schroeven]

Rhodri James schreef op 28/02/2019 om 13:09:

On 27/02/2019 21:39, Roel Schroeven wrote:

Rhodri James schreef op 27/02/2019 om 15:18:
Aren't we overthinking this?

I think it's pretty clear that a variable is never deleted before it
goes out of scope. A quick search in the documentation points me to
(https://docs.python.org/3/reference/datamodel.html#objects-values-and-types):


"Objects are never explicitly destroyed; however, when they become
unreachable they may be garbage-collected. An implementation is allowed
to postpone garbage collection or omit it altogether — it is a matter of
implementation quality how garbage collection is implemented, *as long
as no objects are collected that are still reachable*." (emphasis mine)

In the original example (without del), f is reachable everywhere in the
function after the initial binding, so it can not be deleted.

Comparisons with C on this point don't seem very relevant: C doesn't
have destructors or garbage collection. I don't even see what the C
equivalent for "del f" could be. You could perhaps compare with C++,
where destructors are also not called before the object goes out of
scope (a difference is that in C++ the destructor explicitly always is
called at that moment).


I think you're making the mistake of equating names ("variables") and
objects here.


Yes, on second reading that quote from the documentation is not very 
relevant.



It is not clear to me that a name can't be removed from
the dictionary of locals before it goes out of scope, so long as it
doesn't get referred to again,


It is said that an assignment binds a name to an object in the current 
local namespace (if there is no 'global' or 'nonlocal'). It is said that 
deletion (the del statement) of a name removes the binding of that name 
from the local namespace (again, if there is no 'global' or 'nonlocal').


In the absence of any other mention of bindings being removed, to me it 
seems clear that bindings are not automatically removed. Otherwise many 
things become ambiguous. Example: the documentation for dicts defines 
"d[key] = value" as "Set d[key] to value". Does that mean it can get 
unset later behind your back? Of course not.



just like C optimisers can note that a
local doesn't get used again and reclaim the storage.  At that point the
object can become unreachable, and will in Marko's example.
The equivalent to "del f" that you can't imagine is the optimiser at work.


But note that reclaiming storage in C has no side effects. No locks are 
released, no files are closed. No destructor is run, since C has no such 
thing. It's purely an implementation detail. As long as the visible 
behavior of the program complies with the language specification, the 
compiler can do as it wishes. In C's relative C++, variables going out 
of scope *do* have side effects, and there it *is* guaranteed that that 
only happes at the end of the scope (however the compiler sees fit to 
implement that).


(Also note that the concept of "unreachable" does not exist in C; C does 
not have names and objects like Python).


Python's "del" on the other hand most certainly has a visible effect. It 
is not purely an implementation detail.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Need help with Python3.4 and Avro

[Mihir Kothari]

Hi,

I am not sure if this is the right list, but trying to get help from
experienced python users for my issue.
I have posted the issue in stackoverflow, but yet to see any response. I am
trying my luck here.

I have my question here: https://stackoverflow.com/q/54833834/3165644

If needed, I can give the details in this email too, please let me know.

Regards,
Mihir.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: dash/underscore on name of package uploaded on pypi

[Paul Moore]

On Thu, 28 Feb 2019 at 16:14, ast  wrote:
>
> Hello
>
> I just uploaded a package on pypi, whose name is "arith_lib"
>
> The strange thing is that on pypi the package is renamed "arith-lib"
> The underscore is substitued with a dash

The version with a dash is the normalised form of the name - see
https://www.python.org/dev/peps/pep-0503/#normalized-names

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce()

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +12113
stage:  -> patch review

___
Python tracker 

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

[issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce()

[Zackery Spytz]

New submission from Zackery Spytz :

The PyBytes_FromStringAndSize() and PyObject_GetAttrString() calls in 
PyCData_reduce() are not checked for failure.

--
components: Extension Modules, ctypes
messages: 336866
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Possible assertion failures due to _ctypes.c's PyCData_reduce()
type: crash
versions: Python 2.7, Python 3.7, Python 3.8

___
Python tracker 

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

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
components: +email
nosy: +barry, r.david.murray

___
Python tracker 

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

[issue36149] use of uninitialised memory in cPickle.

[Thomas Wouters]

Change by Thomas Wouters :


--
keywords: +patch
pull_requests: +12112
stage:  -> patch review

___
Python tracker 

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

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

[sls]

Change by sls :


--
keywords: +patch
pull_requests: +12111
stage:  -> patch review

___
Python tracker 

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

[issue36149] use of uninitialised memory in cPickle.

[Thomas Wouters]

New submission from Thomas Wouters :

There is a bug in cPickle that makes it use uninitialised memory when reading a 
truncated pickle from a file (an actual C FILE*, not just any file-like 
object). Using MemorySanitizer:

% ./python
Python 2.7.15 (default, redacted, redacted) 
[GCC 4.2.1 Compatible Clang (redacted)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile, cPickle
>>> f = tempfile.TemporaryFile()
>>> f.write('F')
>>> f.seek(0)
>>> cPickle.load(f)
Uninitialized bytes in __interceptor_strlen at offset 1 inside [0x70101b50, 
3)
==23453==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x561a9110d51b in PyString_FromFormatV Objects/stringobject.c:241:22
#1 0x561a912ba454 in PyErr_Format Python/errors.c:567:14
#2 0x561a91303bc8 in PyOS_string_to_double Python/pystrtod.c
#3 0x561a90b4a7d7 in load_float Modules/cPickle.c:3618:9
#4 0x561a90b48ca7 in load Modules/cPickle.c:4779:17
#5 0x561a90b56d9c in cpm_load Modules/cPickle.c:5758:11
#6 0x561a91260b89 in call_function Python/ceval.c:4379:17

The problem is Modules/cPickle:readline_file end-of-file handling logic:

for (; i < (self->buf_size - 1); i++) {
if (feof(self->fp) ||
(self->buf[i] = getc(self->fp)) == '\n') {
self->buf[i + 1] = '\0';
*s = self->buf;
return i + 1;
}
}

When feof(self->pf) becomes true, the code skips over writing to self->buf[i] 
(which hasn't been written to yet), only writes to self->buf[i+1], and returns 
self->buf.

There is an additional problem that the code fails to check for the EOF return 
of getc(), which means it may write EOF-cast-to-a-char to self->buf[i] without 
realising it's meant to be an EOF. (EOF is usually -1, but I don't remember if 
that's a valid cast or undefined behaviour.) Theoretically this could cause 
invalid, truncated pickles to be read succesfully, but with the wrong value for 
the last item. (It could perhaps do even worse things with files that change 
while cPickle is reading them, but that's harder to reason about.)

(Use of uninitialised memory is a potential security issue, although so is 
using pickles, so I'm conflicted about the bug type...)

--
components: Interpreter Core
messages: 336865
nosy: twouters
priority: normal
severity: normal
status: open
title: use of uninitialised memory in cPickle.
type: security
versions: Python 2.7

___
Python tracker 

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

Re: Using PyArg_ParseTuple to with optional fields.

[DL Neil]

Anthony,


On 28/02/19 10:18 PM, Anthony Flury via Python-list wrote:
I am trying to write an extension module with a function (actually an 
__init__ method, but I am not sure that matters) where the function can 
be called as either :

     my_func()
or
     my_func( a, b, c, d) - where a,b,c,d are all doubles.
I would prefer not to allow the function to be called with some 
arguments specified - it is either all four - or none.


Perhaps it does matter - __init__() only ever returns None, which 
may/not be of-concern at the 'top end'.


During the last few days, either 'here' or over on Python-Tutor, there 
has been a discussion about alternate ways to instantiate an object, ie 
with different numbers of arguments.




I have tried the following format strings to PyArg_ParseTuple :
  * "" - but this a mandatory 4 doubles - doesn't allow for the no

...> Can I do what I want with a single call to PyArg_ParseTuple  ?

+1 for using provided (and optimised) standard facilities!

What advantages does PyArg provide? Has its use become 'blinkers' - a 
straight-jacket to your thinking?


If the data is coming from outside Python directly, is it not possible 
to use named-keyword arguments, ie pick-up the 'optional' 
auto-magically? Somewhere in the existing code there's probably already 
some coding for the 'empty args' option, inserting default values...


How about *args (or *kwargs)? Remember that the "args" (sans asterisk) 
becomes a tuple inside the method. It can be empty or filled. That 
leaves you with two tests: len() zero or four, and (optionally) a loop 
to check that the four arg-tuple elements are all() floats.


--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

[sls]

New submission from sls :

MTA status codes (visible via setdebuglevel(1)) are not accessible as the 
`sendmail`-method stores them only locally (code, resp).

I suggest to store the mta status codes, for instance: "250, b'2.0.0 Ok: queued 
as XYZ" etc. in an instance attribute (tuple) to access them on smtp-sessions. 

As an email developer those information are very important to me.

--
components: Library (Lib)
messages: 336864
nosy: sls
priority: normal
severity: normal
status: open
title: smtplib.SMTP.sendmail: mta status codes only accessible by local 
variables
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue35931] pdb: "debug print(" crashes with SyntaxError

[daniel hahler]

Change by daniel hahler :


--
pull_requests: +12109
stage: resolved -> patch review

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Anthony Sottile]

Anthony Sottile  added the comment:

> What I think Anthony is looking for are ways to register “start up functions” 
> that get executed automatically when the Python interpreter starts up

yes, this is what I want to still exist :)


my hope is that there's a clear standards-track replacement *before* 
deprecating .pth (which currently satisfies my usecases for startup functions)

--

___
Python tracker 

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

[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
keywords: +patch
pull_requests: +12108
stage:  -> patch review

___
Python tracker 

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

[issue35931] pdb: "debug print(" crashes with SyntaxError

[daniel hahler]

daniel hahler  added the comment:

Re-opening: it currently still crashes with a NameError when using "debug 
doesnotexist", or "debug doesnotexist()".

Will create a new PR for this.

--
status: closed -> open

___
Python tracker 

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

[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Also the change from PyUnicode_FromStringAndSize to PyBytes_FromStringAndSize 
happened here: https://bugs.python.org/issue8966

--

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Feb 28, 2019, at 09:40, Anthony Sottile  wrote:
> 
> I don't think even this is unanimous.  Things like registering codecs, 
> instrumenting coverage in subprocesses, etc. all seem like legitimate uses of 
> the arbitrary code execution feature

Except pth files are a terrible interface for that, given all the other 
problems, including weird wall-of-code inducing restrictions on what actually 
gets executed.

I’m in agreement with Steve Dower in principle here.  I would like to see a 
solution that deprecates and eventually removes arbitrary code execution in pth 
files, leaves sys.path extension alone (for now ), and improves the 
discoverability and debuggability of magical pth files.

What I think Anthony is looking for are ways to register “start up functions” 
that get executed automatically when the Python interpreter starts up.  Perhaps 
somewhat analogous to atexit functions?  But if we’re going to officially 
support a feature like that, I think a PEP would be the right vehicle to suss 
out all the gory details, like, should these things be global across all 
invocations of the interpreter, how a user or application would disable that, 
how would bugs in start up functions get discovered, reported, and debugged, 
what if any execution order guarantees should be made, etc.

--

___
Python tracker 

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

[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope

[Charalampos Stratakis]

New submission from Charalampos Stratakis :

Coverity scan on python2 resulted in this error.

Python-2.7.15/Modules/_ctypes/cfield.c:1297: alloc_fn: Storage is returned from 
allocation function "PyString_FromString".
Python-2.7.15/Objects/stringobject.c:143:5: alloc_fn: Storage is returned from 
allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from 
allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning 
storage allocated by "malloc".
Python-2.7.15/Objects/stringobject.c:143:5: var_assign: Assigning: "op" = 
"PyObject_Malloc(37UL + size)".
Python-2.7.15/Objects/stringobject.c:164:5: return_alloc: Returning allocated 
memory "op".
Python-2.7.15/Modules/_ctypes/cfield.c:1297: var_assign: Assigning: "result" = 
storage returned from "PyString_FromString((char *)ptr)".
Python-2.7.15/Modules/_ctypes/cfield.c:1311: leaked_storage: Variable "result" 
going out of scope leaks the storage it points to.
1309|   } else
1310|   /* cannot shorten the result */
1311|-> return PyString_FromStringAndSize(ptr, size);
1312|   }
1313|   

This was fixed on python3 with 
https://github.com/python/cpython/commit/19b52545df898ec911c44e29f75badb902924c0b

Partially backporting this change for this file should fix the issue.

--
components: Extension Modules
messages: 336859
nosy: cstratak, vstinner
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going 
out of scope
versions: Python 2.7

___
Python tracker 

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

[issue13096] ctypes: segfault with large POINTER type names

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
nosy: +vstinner

___
Python tracker 

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

[issue13096] ctypes: segfault with large POINTER type names

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

It seems the python2 backport was incomplete as a PyMem_Free is missing, making 
buf leak.

--
nosy: +cstratak

___
Python tracker 

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

[issue13096] ctypes: segfault with large POINTER type names

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
pull_requests: +12107

___
Python tracker 

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

[issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable

[STINNER Victor]

STINNER Victor  added the comment:

I discussed with Ernest on #python-infra. It was an issue with the DNS 
"resolving the host back to 127.0.1.1 (...) so vsftpd is telling users to 
connect back to themselves".

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

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Anthony Sottile]

Anthony Sottile  added the comment:

> contain features we all want to get rid of

I don't think even this is unanimous.  Things like registering codecs, 
instrumenting coverage in subprocesses, etc. all seem like legitimate uses of 
the arbitrary code execution feature

--

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[STINNER Victor]

STINNER Victor  added the comment:

Ah, I can reproduce the bug on Fedora 29 using "LANG=en_IN ./python -m test -v 
test_re".

The problem is that locale.getlocale() is not reliable: it pretends that the 
locale encoding is ISO8859-1, whereas the real encoding is UTF-8:

$ LANG=en_IN ./python 
Python 3.8.0a2+ (heads/master:4cbea518a0, Feb 28 2019, 18:19:44) 
>>> chr(224).encode('ISO8859-1')
b'\xe0'
>>> import _testcapi
>>> _testcapi.DecodeLocaleEx(b'\xe0', 0, 'strict')
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: decode error: pos=0, reason=decoding error

>>> import locale

# Wrong encoding
>>> locale.getlocale(locale.LC_CTYPE)
('en_IN', 'ISO8859-1')
>>> locale.setlocale(locale.LC_CTYPE, None)
'en_IN'
>>> locale._parse_localename('en_IN')
('en_IN', 'ISO8859-1')

# Real encoding
>>> locale.getpreferredencoding()
'UTF-8'
>>> locale.nl_langinfo(locale.CODESET)
'UTF-8'


Attached PR 12099 fix the issue.

--

___
Python tracker 

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

[issue29571] test_re is failing when local is set for `en_IN`

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12106
stage:  -> patch review

___
Python tracker 

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

[issue36144] Dictionary addition.

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Current python-ideas thread for the issue : 
https://mail.python.org/pipermail/python-ideas/2019-February/055509.html

--

___
Python tracker 

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

[issue33944] Deprecate and remove pth files

[Steve Dower]

Steve Dower  added the comment:

> But think of the poor user who doesn’t have that expertise or ability to hack 
> on an installed Python’s site.py file.

This is actually part of the thinking behind the reportabug tool I started (and 
why when you format it as raw text you get the listing of everything in any 
directory on sys.path - mostly because I haven't added a Markdown rendering of 
that). If the answer is to enhance that and tell users "run `reportabug 
mybrokenmodule` and send me the output", well, that's why I put it on GitHub :) 
https://github.com/zooba/reportabug

I see no reason to hold up adding pth logging to -v, so anyone interested 
please feel free to do a PR.

The only reason I see to hold up PE 10131 (docs update) is because it documents 
the rationale for using arbitrary code execution in a pth file. Since we 
clearly want to get rid of it, I don't think we should in any way rationalize 
it in the docs.

Once these are done, I think we'll have to reevaluate whether .pth files are 
actually a problem in their normal behavior, and whether the benefit outweighs 
the cost. But since we're all agreed that they aren't easy to debug and contain 
features we all want to get rid of, there's not much point using the current 
state to do the cost/benefit analysis. Let's fix the bits we can fix first and 
then see where we stand.

--

___
Python tracker 

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

[issue36018] Add a Normal Distribution class to the statistics module

[miss-islington]

miss-islington  added the comment:


New changeset ef17fdbc1c274dc84c2f611c40449ab84824607e by Miss Islington (bot) 
(Raymond Hettinger) in branch 'master':
bpo-36018: Add special value tests and make minor tweaks to the docs (GH-12096)
https://github.com/python/cpython/commit/ef17fdbc1c274dc84c2f611c40449ab84824607e


--

___
Python tracker 

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

[issue36146] Refactor setup.py

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12105

___
Python tracker 

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

[issue36146] Refactor setup.py

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12104

___
Python tracker 

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

[issue36018] Add a Normal Distribution class to the statistics module

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +12103

___
Python tracker 

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

[issue36146] Refactor setup.py

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4cbea518a0827d23a41a45b03a8af729c2f16605 by Victor Stinner in 
branch 'master':
bpo-36146: Refactor setup.py (GH-12093)
https://github.com/python/cpython/commit/4cbea518a0827d23a41a45b03a8af729c2f16605


--

___
Python tracker 

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

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Dusan Gligoric]

Dusan Gligoric <7...@protonmail.com> added the comment:

Hey folks,

This is still an issue with 3.7.2

===

# Python 3.7.2 (default, Jan 10 2019, 23:51:51) 
# [GCC 8.2.1 20181127] on linux

from multiprocessing import  Manager

manager = Manager()
d = manager.dict({})

d["test"] = {"a": 123}
# update fails
d["test"]["a"] = 321
# add fails
d["test"]["b"] = 321

print(d)

--
nosy: +dusan76
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue36144] Dictionary addition.

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Also note: That Python ideas thread that xtreak linked ( 
https://mail.python.org/pipermail/python-ideas/2015-February/031748.html ) 
largely rejected the proposal a couple weeks before PEP 448 was approved. At 
the time, the proposal wasn't just about +/+=; that was the initial proposal, 
but operator overloading was heavily criticized for the failure to adhere to 
either addition or concatenation semantics, so alternate constructors and 
top-level functions similar to sorted were proposed as alternatives (e.g. 
merged(dicta, dictb)). The whole thread ended up being about creating an 
approved, built-in way of one-lining: d3 = d1.copy(); d3.update(d2)

A key quote though is that this was needed because there was no other option 
without rolling your own merged function. Andrew Barnert summarized it best:

"I'm +1 on constructor, +0.5 on a function (whether it's called updated or 
merged, whether it's in builtins or collections), +0.5 on both constructor and 
function, -0.5 on a method, and -1 on an operator.

"Unless someone is seriously championing PEP 448 for 3.5, in which case I'm 
-0.5 on anything, because it looks like PEP 448 would already give us one 
obvious way to do it, and none of the alternatives are sufficiently nicer than 
that way to be worth having another."

As it happens, PEP 448 was put in 3.5, and we got the one obvious way to do it.

Side-note: It occurs to me there will be one more "way to do it" in 3.8 
already, thanks to PEP 572:

(d3 := d1.copy()).update(d2)

I think I'll stick with d3 = {**d1, **d2} though. :-)

--

___
Python tracker 

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

[issue36144] Dictionary addition.

[Guido van Rossum]

Guido van Rossum  added the comment:

I changed my mind and am now in favor. Most of the arguments against could also 
be used against list+list. Counter addition is actually a nice special case of 
this -- it produces the same keys but has a more sophisticated way of merging 
values for common keys. Please read the python-ideas thread!

--

___
Python tracker 

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

[issue36144] Dictionary addition.

[Josh Rosenberg]

Josh Rosenberg  added the comment:

scoder: dict(X, **M) is broken unless M is known to be string keyed (it used to 
work, but in Python 3, it will raise a TypeError). It's part of the argument 
for the additional unpacking generalizations from PEP 448; {**X, **M} does what 
dict(X, **M) is trying to do, but without abusing the keyword argument passing 
convention.

You also claim "It takes me a while to see the dict merge under that heap of 
stars", but that's at least as much about the newness of PEP 448 (and for many 
Python coders, a complete lack of familiarity with the pre-existing varargs 
unpacking rules for functions) as it is about the punctuation; after all, you 
clearly recognize dict(X, **M) even though it's been wrong in most contexts for 
years.

In any event, I'm a strong -1 on this, for largely the same reasons as Raymond 
and others:

1. It doesn't provide any new functionality, just one more way to do it; += is 
satisfied by .update, + is satisfied (more generally and efficiently) by the 
unpacking generalizations

2. It's needlessly confusing; addition is, for all existing types in the 
standard library I can think of, lossless; the information from both sides of 
the + is preserved in some form, either by addition or concatenation (and in 
the concatenation case, addition is happening, just to the length of the 
resulting sequence, and order is preserved). Addition for dictionaries would 
introduce new rules specific to dicts that do not exist for any other type 
regarding loss of values, non-additive resulting length, etc. Those rules would 
likely be similar to those of dict literals and the update method, but they'd 
need to be made explicit. By contrast, the PEP 448 unpacking generalization 
rules followed the existing rules for dict literals; no special rules occur, it 
just behaves intuitively (if you already knew the rules for dict literals 
without unpacking being involved).

3. Almost any generic, duck-typing based code for which addition makes sense 
will not make sense for dicts simply because it loosens the definition of 
addition too much to be useful, so best case, it still raises TypeError (when 
dicts added to non-dict things), worst case, it silently operates in a way that 
violates the rules of both addition and concatenation rather than raising a 
TypeError that the generic code could use to determine the correct thing to do.

4. The already mentioned conflict with Counter (which already has an addition 
operator, with lossless semantics)

5. (Minor) It means PyDict_Type needs a non-NULL tp_as_number, so now it's 
slightly slower to reject dicts as being non-numeric at the C layer

Problem #2 could be used to argue for allowing | instead of + (which would also 
resolve #4, and parts of #3), since | is already used for unioning with sets, 
and this operation is much closer to a union operation than addition or 
concatenation. Even so, it would still be misleading; at least with sets, there 
is no associated value, so it's still mostly lossless (you lose the input 
lengths, but the unique input data is kept); with dicts, you'd be losing values 
too.

Basically, I think the PEP 448 unpacking syntax should remain as the "one-- and 
preferably only one --obvious way to" combine dictionaries as a one-liner. It's 
more composable, since it allows adding arbitrary additional key/value pairs, 
and more efficient, since it allows combining more than two dicts at once with 
no additional temporaries: dicta + dictb + dictc requires "dictab" to be made 
first, then thrown away after dictab + dictc produces dictabc, while {**dicta, 
**dictb, **dictc} builds dictabc directly.

The only real argument I can see for not sticking to unpacking is that it 
doesn't allow for arbitrary dict-like things to produce new dict-like things 
directly; you'd have to rewrap as myspecialdict({**speciala, **specialb}). But 
I don't think that's a flaw worth fixing if it means major changes to the 
behavior of what I'm guessing is one of the three most commonly used types in 
Python (along with int and tuple, thanks to the integration of dicts into so 
many facets of the implementation).

--
nosy: +josh.r

___
Python tracker 

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

[issue34631] Upgrade to OpenSSL 1.1.1b

[Christian Heimes]

Change by Christian Heimes :


--
keywords: +patch
pull_requests: +12102
stage:  -> patch review

___
Python tracker 

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

dash/underscore on name of package uploaded on pypi

[ast]

Hello

I just uploaded a package on pypi, whose name is "arith_lib"

The strange thing is that on pypi the package is renamed "arith-lib"
The underscore is substitued with a dash

If we search for this package:

pip search arith

arith-lib (2.0.0) - A set of functions for miscellaneous arithmetic
(so a dash)

For installation both:

pip install -U arith_lib
pip install -U arith-lib

are working well

and in both case I got a directory with an underscore

C:\Program Files\Python36-32\Lib\site-packages

28/02/2019  16:57  arith_lib
28/02/2019  16:57  arith_lib-2.0.0.dist-info

What happens ?
--
https://mail.python.org/mailman/listinfo/python-list

Embedding Python (3.7) on OSX crash on Py_Initialize when run as bundle

[Arnaud Loonstra]

Hi,

I'm trying to wrap my head around an OSX app which has python embedded. 
This works fine if I run the build on the same machine as it is build on.


However when using Travis to build the app I can only get it to run from 
the terminal. A double click on the appdir (or using open) results in a 
crash.


trace:
0   libsystem_kernel.dylib  0x7fffb9d6cd42 __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fffb9e5a457 pthread_kill + 90
2   libsystem_c.dylib   0x7fffb9cd24bb __abort + 140
3   libsystem_c.dylib   0x7fffb9cd242f abort + 144
4   com.your-company-name.www   0x000108c6674e fatal_error + 606
5   com.your-company-name.www 	0x000108c65b3a _Py_FatalInitError 
+ 26

6   com.your-company-name.www   0x000108c65bbe Py_Initialize + 126

I can't figure out what is going wrong. I can only guess that's there's 
something preventing it to access the python files?


The build log on travis is here:
https://travis-ci.org/hku-ect/NatNet2OSCbridge/jobs/499348594

It's artefact is here:
https://pong.hku.nl/~buildbot/nightly/NatNet2OSCbridge_osx_7ceb.zip

Python is build with the following flags:
./configure --prefix 
$HOME/openFrameworks/apps/devApps/$APPNAME/bin/python --disable-shared 
--with-openssl=$(brew --prefix openssl);


Anybody any pointers or advice?

Rg,

Arnaud
--
https://mail.python.org/mailman/listinfo/python-list

[issue34631] Upgrade to OpenSSL 1.1.1b

[Christian Heimes]

Christian Heimes  added the comment:

Hi macOS and Windows devs,

as I explained in 
https://mail.python.org/pipermail/python-dev/2019-February/156470.html we need 
to update Python 3.7 to OpenSSL 1.1.1 eventually. 1.1.0 will reach EOL in 
September.

--
components: +Windows, macOS
nosy: +ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
title: Upgrade to OpenSSL 1.1.1 -> Upgrade to OpenSSL 1.1.1b
versions: +Python 3.7

___
Python tracker 

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

[issue21879] str.format() gives poor diagnostic on placeholder mismatch

[Francisco Couzo]

Francisco Couzo  added the comment:

I'm preparing the PR myself

--

___
Python tracker 

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

Re: Lifetime of a local reference

[Marko Rauhamaa]

Chris Angelico :
> What if an exception gets raised at some point before the function has
> returned? The exception object will give full access to the function's
> locals.

It wouldn't hurt for the Python gods to make an explicit ruling on the
matter.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36143] Auto-generate Lib/keyword.py

[STINNER Victor]

STINNER Victor  added the comment:

> Do not haste with this. After implementing pgen in Python, Lib/keyword.py can 
> be generated directly by pgen.

That's bpo-35808 and PR 11814 which is under review.

Anyway, at the end, it would be nice if Lib/keyword.py would be regenerated by 
"make regen-all". Currently, "regen-all" doesn't regenerate everything. For 
example, configure is not regenerated.

--
nosy: +vstinner

___
Python tracker 

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

[issue21879] str.format() gives poor diagnostic on placeholder mismatch

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

@dmzz, You can convert the patch into a PR on github or Open a PR with your own 
implementation.

If working with this same patch, the next step would be to test the patch if it 
is still in good shape now before opening a PR.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue36143] Auto-generate Lib/keyword.py

[Guido van Rossum]

Guido van Rossum  added the comment:

Hum, it seems the right solution was to arrange for async and await to appear 
in the list of keywords despite their special status. Nevertheless in theory 
there's something that can be done here to auto-regenerate the list derived 
from the Grammar.

--

___
Python tracker 

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

[issue36146] Refactor setup.py

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12101

___
Python tracker 

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

[issue36143] Auto-generate Lib/keyword.py

[Guido van Rossum]

Guido van Rossum  added the comment:

(However that doesn't seem to work. Anyway, there's a list of all keywords 
there.)

--

___
Python tracker 

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

[issue36146] Refactor setup.py

[STINNER Victor]

New submission from STINNER Victor :

The detect_modules() method of setup.py became longer and longer over
the years. It is now 1128 lines long. It's way too long: it becomes
very hard to track the lifetime of a variable and many variables are
overriden on purpose or not. Shorter functions help to track the
lifetime of variables, ease review and reduce the number of bugs.

--
components: Build
messages: 336841
nosy: vstinner
priority: normal
severity: normal
status: open
title: Refactor setup.py
versions: Python 3.8

___
Python tracker 

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