[issue45073] windows installer quiet installation targetdir escapes "quote"-symbol

[Eryk Sun]

Eryk Sun  added the comment:

A literal backlash has to be escaped by doubling it if it precedes a double 
quote, else it escapes the double quote character. This is how typical 
command-line argument parsing handles backslash in Windows [1]: 

* 2n backslashes followed by a quotation mark produce n backslashes
  followed by begin/end quote. This does not become part of the
  parsed argument, but toggles the "in quotes" mode.
* (2n) + 1 backslashes followed by a quotation mark again produce n
  backslashes followed by a quotation mark literal ("). This does
  not toggle the "in quotes" mode.
* n backslashes not followed by a quotation mark simply produce n
  backslashes.

For example:

import ctypes
shell32 = ctypes.WinDLL('shell32', use_last_error=True)
shell32.CommandLineToArgvW.restype = ctypes.POINTER(ctypes.c_wchar_p)
n = ctypes.c_int()

Escape the trailing backslash as a literal backslash:

>>> cmd = r'/quiet TargetDir="D:\pyt hon\\" AssociateFiles=0'
>>> args = shell32.CommandLineToArgvW(cmd, ctypes.byref(n))
>>> args[:n.value]
['/quiet', 'TargetDir=D:\\pyt hon\\', 'AssociateFiles=0']

Escape the double quote as a literal double quote:

>>> cmd = r'/quiet TargetDir="D:\pyt hon\" AssociateFiles=0'
>>> args = shell32.CommandLineToArgvW(cmd, ctypes.byref(n))
>>> args[:n.value]
['/quiet', 'TargetDir=D:\\pyt hon" AssociateFiles=0']

---

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw

--
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue45074] asyncio hang in subprocess wait_closed() on Windows, BrokenPipeError

[William Fisher]

New submission from William Fisher :

I have a reproducible case where stdin.wait_closed() is hanging on
Windows. This happens in response to a BrokenPipeError. The same code 
works fine on Linux and MacOS.

Please see the attached code for the demo.

I believe the hang is related to this debug message from the logs:


DEBUG <_ProactorWritePipeTransport closing fd=632>: Fatal write error on pipe 
transport
Traceback (most recent call last):
  File 
"C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\proactor_events.py", 
line 379, in _loop_writing
f.result()
  File 
"C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\windows_events.py", 
line 812, in _poll
value = callback(transferred, key, ov)
  File 
"C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\windows_events.py", 
line 538, in finish_send
return ov.getresult()
BrokenPipeError: [WinError 109] The pipe has been ended


It appears that the function that logs "Fatal write error on pipe transport" 
also 
calls _abort on the stream. If _abort is called before stdin.close(), 
everything is okay. 
If _abort is called after stdin.close(), stdin.wait_closed() will hang.

Please see issue #44428 for another instance of a similar hang in wait_closed().

--
components: asyncio
files: wait_closed.py
messages: 400810
nosy: asvetlov, byllyfish, yselivanov
priority: normal
severity: normal
status: open
title: asyncio hang in subprocess wait_closed() on Windows, BrokenPipeError
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50250/wait_closed.py

___
Python tracker 

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

[issue45073] windows installer quiet installation targetdir escapes "quote"-symbol

[DMI-1407]

New submission from DMI-1407 :

If the windows installer (Python 3.8.9 64bit exe) is run in quiet mode and the 
TargetDir option is used, then the last quote (") symbol gets escaped if the 
path ends with an backslash (\).

Example: /quiet TargetDir="D:\pyt hon\" AssociateFiles=0
Result: TargetDir=hon\" AssociateFiles=0
this raises the error that the path contains a invalid character... (the quote 
ofc)

Example: /quiet TargetDir="D:\pyt hon" AssociateFiles=0
Result: installs correctly


so in general "D:\pyt hon" indicates a file thats named "pyt hon" where "D:\pyt 
hon\" indicates a folder.
whatever "D:\pyt hon\" should be valid and i dont understand why the first 
backslash does not escape the p and leads to "D:pyt hon" ...

its really annoying, pls do at least write a notice into the docs that the 
installer behaves like this. :/

--
components: Installation
messages: 400809
nosy: DMI-1407
priority: normal
severity: normal
status: open
title: windows installer quiet installation targetdir escapes "quote"-symbol
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

[issue45020] Freeze all modules imported during startup.

[Inada Naoki]

Inada Naoki  added the comment:

I don't want all frozen header files to be committed in git repository.
Can't we just build them during build process?

--

___
Python tracker 

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

[issue45071] python 3.9.2 contains _bz2.pyd associates CVE-2019-12900 and CVE-2016-3189 of bzip2-1.0.6

[Zachary Ware]

Zachary Ware  added the comment:

This is a duplicate of bpo-44549.

For future reports, please first check for existing issues, and also ensure 
that you are looking at the latest release of the version you are reporting 
against.

--
nosy: +zach.ware
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> BZip 1.0.6 Critical Vulnerability

___
Python tracker 

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

[issue45070] python 3.9.2 contains wininst-10.0-amd64.exe. wininst-10.0.exe.wininst-7.1.exe. wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe and wininst-14.0.exe associate

[Zachary Ware]

Zachary Ware  added the comment:

As noted in bpo-45068, these executables are helpers for deprecated 
functionality.  It is safe to delete them if they concern you and you don't 
need the deprecated functionality.  They will not be updated except to remove 
them.

--
components: +Distutils, Windows
nosy: +dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
resolution:  -> wont fix
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

[issue45072] python 3.9.2 contains ensurepip and pip associates CVE-2021-3572 of pip-20.2.3

[Zachary Ware]

Zachary Ware  added the comment:

As noted in bpo-45068, v3.9.2 is out of date.  v3.9.7 includes pip v21.2.3.

--
nosy: +zach.ware
resolution:  -> out of date
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

[issue45068] python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

[Zachary Ware]

Zachary Ware  added the comment:

v3.9.2 is rather out of date at this point; v3.9.7 was released just yesterday 
and includes OpenSSL v1.1.1l.  If you're concerned about issues in the version 
of OpenSSL included with Python v3.9.2, you are encouraged to update to the 
latest v3.9.7, or replace the OpenSSL DLLs with your own.

The various wininst-*.exe executables are helpers for the deprecated distutils 
bdist_wininst command, and you are encouraged to not use them :).  You can 
safely remove them if you do not need bdist_wininst functionality.  They will 
not be updated.

--
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
title: python 3.9.2 contains wininst-10.0-amd64.exe. 
wininst-10.0.exe.wininst-7.1.exe. 
wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe 
and wininst-14.0.exe associates CVE-2016-9843、CVE-2016-9841、CVE-2016-9840 and 
CVE-2016-9842 of zlib(1.2.8, 1.2.3,1.2.5) -> python 3.9.2 contains 
libcrypto-1_1.dll and libssl-1_1.dll associates 
CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i

___
Python tracker 

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

[issue34561] Replace list sorting merge_collapse()?

[Tim Peters]

Change by Tim Peters :


--
keywords: +patch
pull_requests: +26550
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28108

___
Python tracker 

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

[issue45072] python 3.9.2 contains ensurepip and pip associates CVE-2021-3572 of pip-20.2.3

[xcl-1]

New submission from xcl-1 <1318683...@qq.com>:

python 3.9.2 contains ensurepip and pip associates CVE-2021-3572 of pip-20.2.3

--
messages: 400803
nosy: xcl123
priority: normal
severity: normal
status: open
title: python 3.9.2 contains ensurepip and pip associates CVE-2021-3572 of 
pip-20.2.3

___
Python tracker 

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

[issue45071] python 3.9.2 contains _bz2.pyd associates CVE-2019-12900 and CVE-2016-3189 of bzip2-1.0.6

[xcl-1]

New submission from xcl-1 <1318683...@qq.com>:

python 3.9.2 contains _bz2.pyd associates CVE-2019-12900 and CVE-2016-3189 of 
bzip2-1.0.6

--
messages: 400802
nosy: xcl123
priority: normal
severity: normal
status: open
title: python 3.9.2 contains _bz2.pyd associates CVE-2019-12900 and 
CVE-2016-3189 of bzip2-1.0.6

___
Python tracker 

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

[issue45070] python 3.9.2 contains wininst-10.0-amd64.exe. wininst-10.0.exe.wininst-7.1.exe. wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe and wininst-14.0.exe associate

[xcl-1]

New submission from xcl-1 <1318683...@qq.com>:

python 3.9.2 contains wininst-10.0-amd64.exe. wininst-10.0.exe.wininst-7.1.exe. 
wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe 
and wininst-14.0.exe associates CVE-2016-9843、CVE-2016-9841、CVE-2016-9840 and 
CVE-2016-9842 of zlib(1.2.8, 1.2.3,1.2.5)

--
messages: 400801
nosy: xcl123
priority: normal
severity: normal
status: open
title: python 3.9.2 contains wininst-10.0-amd64.exe. 
wininst-10.0.exe.wininst-7.1.exe. 
wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe 
and wininst-14.0.exe associates CVE-2016-9843、CVE-2016-9841、CVE-2016-9840 and 
CVE-2016-9842 of zlib(1.2.8, 1.2.3,1.2.5)

___
Python tracker 

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

[issue45069] python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

[xcl-1]

New submission from xcl-1 <1318683...@qq.com>:

python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates 
CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i

--
messages: 400800
nosy: xcl123
priority: normal
severity: normal
status: open
title: python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates 
CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i

___
Python tracker 

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

[issue45068] python 3.9.2 contains wininst-10.0-amd64.exe. wininst-10.0.exe.wininst-7.1.exe. wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe and wininst-14.0.exe associate

[xcl-1]

xcl-1 <1318683...@qq.com> added the comment:

python 3.9.2 contains wininst-10.0-amd64.exe. wininst-10.0.exe.wininst-7.1.exe. 
wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe 
and wininst-14.0.exe associates CVE-2016-9843、CVE-2016-9841、CVE-2016-9840 and 
CVE-2016-9842 of zlib(1.2.8, 1.2.3,1.2.5)

--
title: python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates 
CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i -> python 3.9.2 contains wininst-10.0-amd64.exe. 
wininst-10.0.exe.wininst-7.1.exe. 
wininst-8.0.exe.wininst-9.0.exe.wininst-9.0-amd64.exe.wininst-14.0-amd64.exe 
and wininst-14.0.exe associates CVE-2016-9843、CVE-2016-9841、CVE-2016-9840 and 
CVE-2016-9842 of zlib(1.2.8, 1.2.3,1.2.5)

___
Python tracker 

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

[issue45068] python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

[xcl-1]

New submission from xcl-1 <1318683...@qq.com>:

Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow 
the output length argument in some cases where the input length is close to the 
maximum permissable length for an integer on the platform. In such cases the 
return value from the function call will be 1 (indicating success), but the 
output length value will be negative. This could cause applications to behave 
incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this 
issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL 
versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is 
out of support and no longer receiving public updates. Premium support 
customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade 
to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 
1.0.2y (Affected 1.0.2-1.0.2x).

--
components: Build
messages: 400798
nosy: xcl123
priority: normal
severity: normal
status: open
title: python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates 
CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449
 of openssl-1.1.1i
type: security

___
Python tracker 

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

Re: Create a real-time interactive TUI using Python.

[hongy...@gmail.com]

On Wednesday, September 1, 2021 at 12:49:51 AM UTC+8, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 1:59 AM hongy...@gmail.com  wrote: 
> > 
> > I want to know whether python can be used to create real-time interactive 
> > TUI, as hstr [1] does. 
> > 
> > [1] https://github.com/dvorka/hstr 
> >
> Yes. 

The following are some python TUI framework libraries/projects I have 
discovered so far:

https://github.com/pfalcon/picotui
https://github.com/peterbrittain/asciimatics
https://github.com/bczsalba/pytermgui
https://github.com/GeorgeFilipkin/pulsemixer
https://github.com/jwlodek/py_cui
https://github.com/saulpw/visidata
https://github.com/willmcgugan/textual
https://github.com/urwid/urwid

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Michael F. Stemper]

On 31/08/2021 16.13, Chris Angelico wrote:



But ultimately, it all just means that timezones are too hard for
humans to handle, and we MUST handle them using IANA's database. It is
the only way.


Tom Scott makes this point quite strongly on Computerphile:



And amusingly.

--
Michael F. Stemper
Always remember that you are unique. Just like everyone else.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Create a real-time interactive TUI using Python.

[Dennis Lee Bieber]

On Tue, 31 Aug 2021 06:12:42 -0700 (PDT), "hongy...@gmail.com"
 declaimed the following:

>I want to know whether python can be used to create real-time interactive TUI, 
>as hstr [1] does.
>

Most of these utilities appear to rely upon embedding commands into the
OS SHELL prompt. You could embed pretty much anything to be run as part of
the prompt display.
https://github.com/dvorka/hstr/blob/master/CONFIGURATION.md#bash-history-settings

Since source for HSTR is available, nothing prevents you from recoding
everything in Python -- though I'm fairly certain Python may be a bit
slower unless you can take advantage of compiled C libraries (regex,
perhaps). Based upon the animated GIF, you'll have to master the curses
library from Python.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

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

Re: urgent

[Grant Edwards]

On 2021-08-29, Hari  wrote:

> i was download ur python software but it is like boring user
> interface for me like young student to learn ,can u have any
> updates?

Check the calendar, it must be September again...

Well, almost.

-- 
Grant Edwards   grant.b.edwardsYow! Did I do an INCORRECT
  at   THING??
  gmail.com

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

Re: Struggling to understand timedelta rpesentation when applying an offset for an hour earlier - why is days = -1?

[Dennis Lee Bieber]

On Tue, 31 Aug 2021 03:59:52 -0700 (PDT), dcs3spp via Python-list
 declaimed the following:


>I cannot understand why the resultant datetime.timedelta is days=-1, 
>seconds=82800 (23 hours) .
>

Read the documentation...
https://docs.python.org/3/library/datetime.html#timedelta-objects


>Why is it not an hour earlier as seconds=-3600? Why is days = -1 when the 
>resultant calculated date is the same, year, day, month??

"""
and days, seconds and microseconds are then normalized so that the
representation is unique, with

0 <= microseconds < 100

0 <= seconds < 3600*24 (the number of seconds in one day)

-9 <= days <= 9
"""

Note that microseconds and seconds are ALWAYS normalized to be a positive
integer. So your input on -3600 is normalized to +82800 from the previous
day.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

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

[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

[Gregory Szorc]

Gregory Szorc  added the comment:

I think patch broke building on macOS < 11 when building with a 11.0+ SDK and 
targeting macOS < 11? This build configuration previously used to work with 
3.9.6.

clang -Wno-unused-result -Wsign-compare -g -O0 -Wall -arch x86_64 
-mmacosx-version-min=10.9 -Wno-nullability-completeness 
-Wno-expansion-to-defined -Wno-undef-prefix -isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
 -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes 
-Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal 
 -I. -I./Include -arch x86_64 -mmacosx-version-min=10.9 
-Wno-nullability-completeness -Wno-expansion-to-defined -Wno-undef-prefix 
-isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/S
 DKs/MacOSX11.1.sdk -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -DMACOSX -DUSING_MALLOC_CLOSURE_DOT_C=1 
-DHAVE_FFI_PREP_CIF_VAR=1 -DHAVE_FFI_PREP_CLOSURE_LOC=1 
-DHAVE_FFI_CLOSURE_ALLOC=1 -DPy_BUILD_CORE_BUILTIN  -I_ctypes/darwin -c 
./Modules/_ctypes/callproc.c -o Modules/callproc.o
python-3.9> ./Modules/_ctypes/callproc.c:1459:15: error: redefinition of 
'_dyld_shared_cache_contains_path' as different kind of symbol
cpython-3.9> static bool (*_dyld_shared_cache_contains_path)(const char *path);
cpython-3.9>   ^
cpython-3.9> 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/mach-o/dyld.h:121:13:
 note: previous definition is here
cpython-3.9> extern bool _dyld_shared_cache_contains_path(const char* path) 
  __API_AVAILABLE(macos(11.0), ios(14.0), watchos(7.0), tvos(14.0)) 
DYLD_DRIVERKIT_UNAVAILABLE;
cpython-3.9> ^
cpython-3.9> ./Modules/_ctypes/callproc.c:1464:42: error: non-object type 'bool 
(const char *)' is not assignable
cpython-3.9> _dyld_shared_cache_contains_path = 
dlsym(libsystem_b_handle, "_dyld_shared_cache_contains_path");
cpython-3.9>  ^
cpython-3.9> ./Modules/_ctypes/callproc.c:1464:9: error: 
'_dyld_shared_cache_contains_path' is only available on macOS 11.0 or newer 
[-Werror,-Wunguarded-availability-new]
cpython-3.9> _dyld_shared_cache_contains_path = 
dlsym(libsystem_b_handle, "_dyld_shared_cache_contains_path");
cpython-3.9> ^~~~
cpython-3.9> 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/mach-o/dyld.h:121:13:
 note: '_dyld_shared_cache_contains_path' has been marked as being introduced 
in macOS 11.0 here, but the deployment target is macOS 10.9.0
cpython-3.9> extern bool _dyld_shared_cache_contains_path(const char* path) 
  __API_AVAILABLE(macos(11.0), ios(14.0), watchos(7.0), tvos(14.0)) 
DYLD_DRIVERKIT_UNAVAILABLE;
cpython-3.9> ^
cpython-3.9> ./Modules/_ctypes/callproc.c:1464:9: note: enclose 
'_dyld_shared_cache_contains_path' in a __builtin_available check to silence 
this warning
cpython-3.9> _dyld_shared_cache_contains_path = 
dlsym(libsystem_b_handle, "_dyld_shared_cache_contains_path");
cpython-3.9> ^~~~
cpython-3.9> ./Modules/_ctypes/callproc.c:1482:10: error: 
'_dyld_shared_cache_contains_path' is only available on macOS 11.0 or newer 
[-Werror,-Wunguarded-availability-new]
cpython-3.9>  if (HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME) {
cpython-3.9>  ^~~~
cpython-3.9> ./Modules/_ctypes/callproc.c:1474:5: note: expanded from macro 
'HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME'
cpython-3.9> _dyld_shared_cache_contains_path != NULL
cpython-3.9> ^~~~
cpython-3.9> 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/mach-o/dyld.h:121:13:
 note: '_dyld_shared_cache_contains_path' has been marked as being introduced 
in macOS 11.0 here, but the deployment target is macOS 10.9.0
cpython-3.9> extern bool _dyld_shared_cache_contains_path(const char* path) 
  __API_AVAILABLE(macos(11.0), ios(14.0), watchos(7.0), tvos(14.0)) 
DYLD_DRIVERKIT_UNAVAILABLE;
cpython-3.9> ^
cpython-3.9> ./Modules/_ctypes/callproc.c:1482:10: note: 

[issue44450] Generator expressions trace differently on Windows than on Mac

[Ned Batchelder]

Ned Batchelder  added the comment:

Looks like this is fixed with 3.10.0rc1, thanks.

--

___
Python tracker 

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

RE: urgent (actually NOT urgent at all.)

[Avi Gross via Python-list]

This is a bit sillier then some other discussions here!

There are many programs (especially back when more command-line programs were 
used) that presented default prompts like "$" and many or most of them let you 
over-ride it.

Can someone tell this person that if >>> is not pleasing, they can do something 
like:

import sys
sys.ps1 = "what do you wish Mistress? -=> "

And this can be set per session or perhaps across all accounts in an 
installation as a default?

Some people focus on minutiae rather than either accept a language as being 
what it is, or finding a different way that meets their needs.

I occasionally have made the prompt empty for a while so I can more easily do 
cut and paste from it. All that is needed for some is to make whatever prompt 
be somewhat unique among the other prompts they normally face. Sure, on some 
screens there are ways to add color or even odd characters and  graphics to 
some prompts but who needs sexy?

Realistically, many of us do so much of the programming elsewhere as in some 
editor or environment, and especially a language like python where indentation 
levels are strictly a part of the language.


-Original Message-
From: Python-list  On 
Behalf Of Barry
Sent: Tuesday, August 31, 2021 7:02 PM
Cc: Python-list@python.org
Subject: Re: urgent



> On 31 Aug 2021, at 16:53, jak  wrote:
> 
> Il 31/08/2021 03:05, Python ha scritto:
>> Hari wrote:
>>> i was download ur python software but it is like boring user 
>>> interface for me like young student to learn ,can u have any updates?
>> God, let me die please...
> 
> Oh no, please don't speak in that way ... evidently now that python 
> has reached its tenth version its prompt is a little boring. It may 
> need to be replaced. You could open a competition notice to vote on 
> the new prompt. I would vote for:
> 
> :^P>

The big problem with >>> is that it means a third level quote in email clients.
So when people cut-n-paste REPL output it’s formatted badly by email clients.
A prompt that avoided that issue would be nice.

>>> print(“this is not a quoted reply”)

Barry

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

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

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 11.27, MRAB wrote:
> On 2021-08-31 23:31, Chris Angelico wrote:
>> On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:
>>>
>>> [snip]
>>> In the EU, DST in the member states changes at the same time. It's not
>>> like the US where it ripples across the timezones, so the differences
>>> vary during the change. It all happens in one go.
>>>
>>
>> Ah, good to know. I think that actually makes a lot of sense; in the
>> US, they try to let everyone pretend that the rest of the world
>> doesn't exist ("we always change at 2AM"), but in Europe, they try to
>> synchronize for the convenience of commerce ("everyone changes at 1AM
>> UTC").
>>
>> A quick browse of Wikipedia suggests that some European countries
>> (outside of the EU, which mandates DST transitions) have constant
>> year-round UTC offsets. In theory, there could be a non-EU country
>> that observes DST with different dates, but I can't find any examples.
>> Here's hoping, hehe.
>>
> It goes forwards on the last Sunday of March and back on the last Sunday
> of October.

and @Chris' point about the lack of synchronisation:

«
Daylight saving starts each year at 2am on the last Sunday in September,
and ends at 3am on the first Sunday in April.

Daylight saving starts  Daylight saving ends
26 September 2021   3 April 2022
»
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/


Have learned something new about my adopted-country today! Apparently
New Zealand was once one of those half-hour-out countries (until 1946).
From when no "Daylight Saving time" was recognised. In 1974 a trial took
place, and after public debate, the idea extended - continuing today:
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/history-of-daylight-saving-in-nz/


To explain the rationale for "Daylight Saving", ie "Summer Time":
«
The 2008 survey found that 82% of New Zealanders approved of the 2007
extension to the period of daylight saving time.

The rationale for changing the time over the summer months is that more
sunlight hours will fall in the early morning if standard time is
applied year round. In summer, these early morning sunlight hours are
seen as being wasted as many people are asleep at that time. If the
sunlight hours are shifted to the evening, by way of daylight saving
time, they are more useful.
»
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44359] test_ftplib fails as "env changes" if a socket operation times out in a thread: TimeoutError is not catched

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue45062] test_asyncio: test_huge_content_recvinto() failed on PPC64LE RHEL8 Refleaks 3.9

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

> Yeah. And if you think you've heard it all, sign up for the
> tzdata-announce mailing list and wait for the next phenomenon. I think
> Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
> change, for (with short notice) announcing that they'd have DST during
> summer but not during Ramadan. Since "summer" is defined by a solar
> calendar and "Ramadan" is defined by a lunar calendar, that means the
> DST exclusion might happen entirely in winter (no effect), at one end
> or other of summer (shortens DST, just changes the dates), or in the
> middle of summer (DST on, DST off, DST on, DST off, in a single year).
> But they will, at some point, be eclipsed by an even more bizarre
> timezone change. I don't dare try to predict what will happen, because
> I know that the reality will be even worse


Similar to the situation where a few US cities maintain a different
time-zone to the rest of the(ir) state, our refinery (in the Middle
East) maintained just such a Ramadan-clock. I think such might be quite
a common practice (which I'll describe, below).

When considered, and motivation aside, it's not so very different from
schemes enabling employees to choose their personal start-time (usually
within a range, eg "glide time"), ideas to reduce 'rush hour' grid-locks
by spreading commuter start/finish times, etc.


At the refinery (computer center), we started one (or was it two) hours
earlier that usual - as close to dawn as possible, ie the beginning of
the daily fast.

"Western employees" could take regular breaks, and usually 'disappeared'
for 'midday meal', somewhere around 1030~1130.

Muslim employees had no breaks. In lieu, they went home early - to be
able to sleep. Later came sunset-prayers, and thereafter
breaking-the-fast. Typically, there would be activities, and more meals,
during the night.

Meantime, the non-Muslims maintained a short 'afternoon shift', going
home commensurately early.

Others in the community were totally confused: "Why didn't you answer
your phone yesterday afternoon?", "a meeting at 0700 - you must be
joking!", etc. The pattern and predictability were broken!


I thought it was a fabulous idea, actually leaving the office on-time
(for a change), and heading straight down to the beach for some
wind-surfing...

That said, it really messed with your head. People staggered-in and
managed little output first-thing. (need I say more?)

At a more amusing level: my door was literally always-open, and because
my office was at the end of a corridor, colleagues required only a
glance to see if I was 'available'. The door only closed for
personal/confidential discussions or when I was 'out' - except during
Ramadan when I didn't want to insult anyone by drinking tea, effectively
in-public. So, when the door was closed for long periods, this confused
my staff. Indeed, I would often be asked "where have you been?" when I'd
been working-away at my desk all-along, but simply hadn't got up to open
the door once 'the coast was clear'. Life's rich tapestry...

In my case, I blame "Ramadan-hours" for 'flipping the switch' (in my
head) and turning a late-night owl, and stereotypical techie/hacker;
into an 'early bird'. Ironically such serves me well today - dealing
with clients and colleagues on the other side of the planet, who much
prefer me to wake-early, so that they don't have to interrupt their
evenings at home...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45020] Freeze all modules imported during startup.

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +26549
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28107

___
Python tracker 

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

[issue45067] Failed to build _curses on CentOS 7

[Senthil Kumaran]

New submission from Senthil Kumaran :

I verified that ncurses-devel is installed.

./configure is able to verify ncurses

checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking for term.h... yes

But _curses fails to build, this is the output message from `make`


gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 
-Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Werror=implicit-function-declaration 
-fvisibility=hidden -I./Include/internal -DHAVE_NCURSESW=1 
-I/usr/include/ncursesw -I./Include -I. -I/usr/local/include 
-I/local/home/senthilx/cpython/Include -I/local/home/senthilx/cpython -c 
/local/home/senthilx/cpython/Modules/_curses_panel.c -o 
build/temp.linux-x86_64-3.11/local/home/senthilx/cpython/Modules/_curses_panel.o
gcc -pthread -shared 
build/temp.linux-x86_64-3.11/local/home/senthilx/cpython/Modules/_curses_panel.o
 -L/usr/local/lib -lpanelw -lncursesw -o 
build/lib.linux-x86_64-3.11/_curses_panel.cpython-311-x86_64-linux-gnu.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module 
named '_curses'

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc  pwd   time


Failed to build these modules:
_curses


Following modules built successfully but were removed because they could not be 
imported:
_curses_panel

--
messages: 400795
nosy: orsenthil
priority: normal
severity: normal
status: open
title: Failed to build _curses on CentOS 7
type: compile error
versions: Python 3.11

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 9:20 AM dn via Python-list
 wrote:
>
> On 01/09/2021 09.13, Chris Angelico wrote:
> > On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
> >  wrote:
> >>> Yeah. I do recommend making good use of the IANA tzinfo database
> >>> though (especially since Python 3.9 made that a bit easier to access),
> >>> as it's usually easier to get people to tell you what city/state
> >>> they're in, rather than whether daylight time will be active or not.
> >>> (It might take a little bit of translation to figure out that, for
> >>> instance, New Brunswick CA is America/Halifax, but that's not too hard
> >>> usually.) Letting tzinfo do all the work means you don't have to fret
> >>> about anyone's daylight saving transition dates, or whether they've
> >>> decided to change their clocks by half an hour to be different from
> >>> Japan's clocks, or to have DST not applicable during Ramadan, or to
> >>> have double DST, or double-negative DST. And yes, those are all real,
> >>> because you can't make up anything as insane as actual clock politics.
> >>
> >> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> >> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> >> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> >> time numerically: "17:00-3"
> >>
> >> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> >> "1600", and I can figure it to be "0800" for me:
> >>
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> >> and
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
> >>   rounding to 24hrs: 08:00
> >>   (the next day)
> >
> > No, that's not reliable... because of that abomination called Daylight
> > Saving Time. Since I used New Brunswick, and since she's just gone
> > online, I'll use a specific example:
> >
> > DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> > going to focus on a weekly event here). Since she lives in NB, Canada,
> > she defines that time by what IANA refers to as America/Halifax.
> >
> > I want to be there at the start of each stream, since I'm one of her
> > moderators. But I live in a suburb of Melbourne - my clock shows what
> > IANA calls Australia/Melbourne.
> >
> > To turn this into a purely mathematical calculation, you have to know
> > exactly when she will go on or off DST, and when I will go on or off.
> > Trying to turn it into an offset is going to fail badly as soon as you
> > talk about "next Tuesday" and one of us is shifting DST this weekend.
> >
> > That's why it's better to let Python (or something) handle the whole
> > thing. Don't concern yourself with exactly what the hour differences
> > are, or which way DST is going, or anything; just convert Halifax time
> > to Melbourne time.
>
> OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
> but expect my poor, over-worked (and under-paid) computer to calculate
> it all for me...
>
>
> I should have split the earlier explanation of two calculations, more
> clearly:
>
> Devicat can declare the start as "6pm" ("localisation")
> and state that the time-zone is UTC-3
> - or as @MRAB suggested, translate it to "21:00 UTC"
> ("internationalisation")
>
> You (@Chris) then perform the second-half calculation, by adjusting the
> UTC-value to your time-zone.
>
> - and were I to attend, would personalise ("localise") the time
> similarly - but using my locality's (different) UTC-offset.

Gotcha gotcha. Unfortunately that, while theoretically easier, is not
correct; she streams at 6pm every week, which means that the UTC time
is *different* in June and December.

> I agree, the idea of 'Summer Time' is a thorough pain - even more-so
> when the host publishes in local-time but forgets that there will be a
> "spring forward" or "fall back" between the time of publication and the
> meeting-date!

Right. Which is basically guaranteed when it's a recurring event.

> Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
> will be happy.
>
> If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
> or not), the international community can make their own and personal
> arrangements, without winding-through the opaque and arcane
> seasonal-adjustments described!
>
> Plus the virtue(?) of using International Standards!

She'd have to either specify two different UTC times, or two different
local times. Instead, it's safer to just have her publish one local
time (since that's how she's defining things), and let us all convert
directly to our own timezones every time.

> The "New Brunswick" in Canada is quite close to the "New Brunswick" in
> New Jersey (USA) - in physical distance, but the two are in distinct
> time-zones. (Yes, you did say "CA", but easily 'missed' - by author and
> reader alike)

Fair point. I'm not familiar with New Brunswick, New 

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[MRAB]

On 2021-08-31 23:31, Chris Angelico wrote:

On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:


[snip]
In the EU, DST in the member states changes at the same time. It's not
like the US where it ripples across the timezones, so the differences
vary during the change. It all happens in one go.



Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").

A quick browse of Wikipedia suggests that some European countries
(outside of the EU, which mandates DST transitions) have constant
year-round UTC offsets. In theory, there could be a non-EU country
that observes DST with different dates, but I can't find any examples.
Here's hoping, hehe.

It goes forwards on the last Sunday of March and back on the last Sunday 
of October.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 09.13, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
>  wrote:
>>> Yeah. I do recommend making good use of the IANA tzinfo database
>>> though (especially since Python 3.9 made that a bit easier to access),
>>> as it's usually easier to get people to tell you what city/state
>>> they're in, rather than whether daylight time will be active or not.
>>> (It might take a little bit of translation to figure out that, for
>>> instance, New Brunswick CA is America/Halifax, but that's not too hard
>>> usually.) Letting tzinfo do all the work means you don't have to fret
>>> about anyone's daylight saving transition dates, or whether they've
>>> decided to change their clocks by half an hour to be different from
>>> Japan's clocks, or to have DST not applicable during Ramadan, or to
>>> have double DST, or double-negative DST. And yes, those are all real,
>>> because you can't make up anything as insane as actual clock politics.
>>
>> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
>> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
>> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
>> time numerically: "17:00-3"
>>
>> Given that, someone at UTC-4 knows that his/her rendez-vous will be
>> "1600", and I can figure it to be "0800" for me:
>>
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
>> and
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
>>   rounding to 24hrs: 08:00
>>   (the next day)
> 
> No, that's not reliable... because of that abomination called Daylight
> Saving Time. Since I used New Brunswick, and since she's just gone
> online, I'll use a specific example:
> 
> DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> going to focus on a weekly event here). Since she lives in NB, Canada,
> she defines that time by what IANA refers to as America/Halifax.
> 
> I want to be there at the start of each stream, since I'm one of her
> moderators. But I live in a suburb of Melbourne - my clock shows what
> IANA calls Australia/Melbourne.
> 
> To turn this into a purely mathematical calculation, you have to know
> exactly when she will go on or off DST, and when I will go on or off.
> Trying to turn it into an offset is going to fail badly as soon as you
> talk about "next Tuesday" and one of us is shifting DST this weekend.
> 
> That's why it's better to let Python (or something) handle the whole
> thing. Don't concern yourself with exactly what the hour differences
> are, or which way DST is going, or anything; just convert Halifax time
> to Melbourne time.

OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
but expect my poor, over-worked (and under-paid) computer to calculate
it all for me...


I should have split the earlier explanation of two calculations, more
clearly:

Devicat can declare the start as "6pm" ("localisation")
and state that the time-zone is UTC-3
- or as @MRAB suggested, translate it to "21:00 UTC"
("internationalisation")

You (@Chris) then perform the second-half calculation, by adjusting the
UTC-value to your time-zone.

- and were I to attend, would personalise ("localise") the time
similarly - but using my locality's (different) UTC-offset.


I agree, the idea of 'Summer Time' is a thorough pain - even more-so
when the host publishes in local-time but forgets that there will be a
"spring forward" or "fall back" between the time of publication and the
meeting-date!

[the song says "Summer Time, and the living is easy". Unfortunately,
Ella Fitzgerald isn't here to wrap her head around the problem, so I
guess it's up to us...]

Once again, it is a localisation/internationalisation problem. Why would
you/I know, if and when, New Brunswick moves in/out of Summer Time? As
described, it is another 'big ball of mud'.

Far better to have the local deal with 'local issues', and for us to
handle our own (time-zone) problems!
(why should Devicat concern herself with MLB-based issues, or NZST, or
wherever and etc?)

[BTW: welcome to the first day of 'summer'!]


Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
will be happy.

If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
or not), the international community can make their own and personal
arrangements, without winding-through the opaque and arcane
seasonal-adjustments described!

Plus the virtue(?) of using International Standards!


>> For many of us, the mental-calculations are relatively easy to manage.
>> For Python the code is trivial. Computation is easier than terminology
>> 'translation' (particularly when one has to research the terms first!
>> - did you know what "ADT" meant?)
> 
> I asked DeviCat what country and province ("state" in other regions)
> she lived in, and then confirmed with her that Halifax time was 

Re: urgent

[Chris Angelico]

On Wed, Sep 1, 2021 at 9:03 AM Barry  wrote:
>
>
>
> > On 31 Aug 2021, at 16:53, jak  wrote:
> >
> > Il 31/08/2021 03:05, Python ha scritto:
> >> Hari wrote:
> >>> i was download ur python software but it is like boring user interface for
> >>> me like young student to learn ,can u have any updates?
> >> God, let me die please...
> >
> > Oh no, please don't speak in that way ... evidently now that python has
> > reached its tenth version its prompt is a little boring. It may need to
> > be replaced. You could open a competition notice to vote on the new
> > prompt. I would vote for:
> >
> > :^P>
>
> The big problem with >>> is that it means a third level quote in email 
> clients.
> So when people cut-n-paste REPL output it’s formatted badly by email clients.
> A prompt that avoided that issue would be nice.
>
> >>> print(“this is not a quoted reply”)
>

Welp, gonna have to convince people that the Python 3000 decision
needs to be reversed :)

https://www.python.org/dev/peps/pep-3099/#interactive-interpreter

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

Re: urgent

[Barry]



> On 31 Aug 2021, at 16:53, jak  wrote:
> 
> Il 31/08/2021 03:05, Python ha scritto:
>> Hari wrote:
>>> i was download ur python software but it is like boring user interface for
>>> me like young student to learn ,can u have any updates?
>> God, let me die please...
> 
> Oh no, please don't speak in that way ... evidently now that python has
> reached its tenth version its prompt is a little boring. It may need to
> be replaced. You could open a competition notice to vote on the new
> prompt. I would vote for:
> 
> :^P>

The big problem with >>> is that it means a third level quote in email clients.
So when people cut-n-paste REPL output it’s formatted badly by email clients.
A prompt that avoided that issue would be nice.

>>> print(“this is not a quoted reply”)

Barry

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

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

[issue44895] refleak test failure in test_exceptions

[Irit Katriel]

Irit Katriel  added the comment:

Oh, I see now what you meant. 

I think you're right that it's cleanup. I changed dash_R_cleanup to put the 
sys._clear_type_cache() after clear_caches() and the leak is gone:

@@ -166,9 +166,6 @@ def dash_R_cleanup(fs, ps, pic, zdc, abcs):
 zipimport._zip_directory_cache.clear()
 zipimport._zip_directory_cache.update(zdc)
 
-# clear type cache
-sys._clear_type_cache()
-
 # Clear ABC registries, restoring previously saved ABC registries.
 abs_classes = [getattr(collections.abc, a) for a in 
collections.abc.__all__]
 abs_classes = filter(isabstract, abs_classes)
@@ -181,6 +178,12 @@ def dash_R_cleanup(fs, ps, pic, zdc, abcs):
 
 clear_caches()
 
+# clear type cache
+sys._clear_type_cache()
+
+support.gc_collect()
+



I did this because I suspected it's something related to types, because it only 
happen when we define the exception classes (A and B) inside the test function. 

So maybe the type objects of these exceptions are not cleared from the type 
cache because they have refcount > 0 but by the time  clear_caches() and 
gc.collect() finish they are cleared?


Note this doesn't mean the change I made is always right - maybe the whole body 
of dash_R_cleanup should be in a loop until nothing changes?

--

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[Géry]

Géry  added the comment:

No worries, it was almost twenty years ago.

> But it's probably better to raise a dedicated exception in that case and 
> catch it in main(), rather than just calling sys.exit() deep inside the other 
> code.

Yes I agree, and I think you explained very clearly why it is better in the 
blog post:

> Another refinement is to define a Usage() exception, which we catch in an 
> except clause at the end of main():
> […]
> This gives the main() function a single exit point, which is preferable over 
> multiple return 2 statements.

So I think you made two independent points:

- raising a dedicated exception instead of calling `sys.exit` inside nested 
functions and catching it inside `main` allows a single exit point;
- calling `sys.exit` outside of `main` instead of inside prevents exiting the 
Python interpreter in an interactive session.

--

___
Python tracker 

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

[issue45064] Raising AttributeError in descriptor decorator causing searching attribute in __mro__

[Raymond Hettinger]

Raymond Hettinger  added the comment:

To get a better insight into what is going on, see
https://docs.python.org/3/howto/descriptor.html#invocation-from-an-instance
  
The relevant text is, "So if __getattr__() exists, it is called whenever 
__getattribute__() raises AttributeError (either directly or in one of the 
descriptor calls)."

If needed, you can bypass the __getattr__ hook by calling 
object.__getattribute__ directly:

>>> object.__getattribute__(C(), 'test')
Traceback (most recent call last):
  File "", line 1, in 
  object.__getattribute__(c, 'test')
  File "/Users/raymond/Documents/tmp14.py", line 26, in __get__
raise AttributeError("Python bug?")
AttributeError: Python bug?

--
nosy: +rhettinger

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[Jack DeVries]

Jack DeVries  added the comment:

> Your docs seem to promote the second, whereas I've usually preferred the
> former. Was this a considered choice on your part?

First and foremost, stupid GitHub is not letting the permalink load for some
reason, but yes; this was discussed in the conversation with @graingert on
June 29th – it was his suggestion. Later, @pradyunsg from PyPa added some
suggestions about how the document described console script entrypoints,
and the documentation around this issue changed a bit again.

As far as my perspective, I also never personally use the sys.exit idiom
myself. After all, an exception is going to cause a non-zero exit code, and a
traceback is always going to have a lot more value than an exit code.

I was, however, surprised to learn how pip treats console script entry points
in the course of working on this document. Specifically, it generates an
executable script that does wrap the function in sys.exit.I definitely think
that the way the document communicates this fact while teaching the idiom is a
good thing, so I think that whole "Idiomatic Usage" section is good.

I do think we can tweak the document slightly to make it less prescriptive,
though, because in reality a lot of people _don't_ use this idiom, so
presenting it as a de-facto standard is misleading. Plus, it's not
Pythonic to dole out prescriptive boilerplate.

I attached a diff that steers in that direction. What do you all think? It is
a pretty slight change, but I think it better strikes a balance.

--
Added file: https://bugs.python.org/file50249/less_prescriptive.diff

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:
>
> [snip]
> In the EU, DST in the member states changes at the same time. It's not
> like the US where it ripples across the timezones, so the differences
> vary during the change. It all happens in one go.
>

Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").

A quick browse of Wikipedia suggests that some European countries
(outside of the EU, which mandates DST transitions) have constant
year-round UTC offsets. In theory, there could be a non-EU country
that observes DST with different dates, but I can't find any examples.
Here's hoping, hehe.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[MRAB]

On 2021-08-31 22:53, 2qdxy4rzwzuui...@potatochowder.com wrote:

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico  wrote:


On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:



> What about Phoenix?  In the winter, it's the same time there as it is in
> San Francisco, but in the summer, it's the same time there as it is in
> Denver (Phoenix doesn't observe Daylight Saving Time).

I prefer to say: In winter, San Francisco (or Los Angeles) is the same
as Phoenix, but in summer, Los Angeles changes its clocks away, and
Denver changes to happen to be the same as Phoenix.


Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST.  San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.


At least the US has governed DST transitions. As I understand it, any
given city has to follow one of the standard time zones, and may
EITHER have no summer time, OR transition at precisely 2AM/3AM local
time on the federally-specified dates. (I think the EU has also
mandated something similar for member states.)


That's my understanding, too.


[snip]
In the EU, DST in the member states changes at the same time. It's not 
like the US where it ripples across the timezones, so the differences 
vary during the change. It all happens in one go.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 7:54 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-01 at 07:32:43 +1000,
> Chris Angelico  wrote:
>
> > On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> > > What about Phoenix?  In the winter, it's the same time there as it is in
> > > San Francisco, but in the summer, it's the same time there as it is in
> > > Denver (Phoenix doesn't observe Daylight Saving Time).
> >
> > I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> > as Phoenix, but in summer, Los Angeles changes its clocks away, and
> > Denver changes to happen to be the same as Phoenix.
>
> Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
> (aka US/Mountain), but only Denver observes DST.  San Francisco and Los
> Angeles are both in America/Los_Angeles, and both observe DST.

America/Phoenix is a separate time zone from America/Denver. During
winter they represent the same time, but during summer, Phoenix
doesn't change its offset, and Denver does.

(San Francisco isn't an IANA timezone; the city precisely follows Los
Angeles time.)

> > ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> > timezone change ...
>
> Yeah, I read about that somewhere.  Remember when the Pope declared that
> September should skip a bunch of days?

Well, that's from transitioning from the Julian calendar to the
Gregorian. The same transition was done in different countries at
different times. The Pope made the declaration for the Catholic church
in 1582, and all countries whose official religion was Catholic
changed at the same time; other countries chose their own schedules
for the transition. Notably, Russia converted in 1918, immediately
after the "October Revolution", which happened on the 25th of October
on the Julian calendar, but the 7th of November on the Gregorian.

> Way back in the 1990s, I was working with teams in Metro Chicago, Tel
> Aviv, and Tokyo (three separate teams, three really separate time zones,
> at least two seaprate DST transition dates).  I changed my wristwatch to
> 24 hour time (and never looked back).  I tried UTC for a while, which
> was cute, but confusing.

I tried UTC for a while too, but it became easier to revert to local
time for my watch and just do the conversions directly.

Perhaps, in the future, we will all standardize on UTC, and daylight
time will be a historical relic. And then, perhaps, we will start
getting frustrated at relativity-based time discrepancies ("it's such
a pain scheduling anything with someone on Mars, their clocks move
faster than ours do!").

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

[issue27334] [sqlite3] context manager leaves db locked if commit fails in __exit__

[STINNER Victor]

STINNER Victor  added the comment:

Nice!

--
nosy: +vstinner

___
Python tracker 

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

[issue45064] Raising AttributeError in descriptor decorator causing searching attribute in __mro__

[Yurii Karabas]

Yurii Karabas <1998uri...@gmail.com> added the comment:

Hi Mateusz,

It's not a bug, it's expected behavior.

__getattr__ called when the default attribute access fails with an 
AttributeError (either __getattribute__() raises an AttributeError because name 
is not an instance attribute or an attribute in the class tree for self; or 
__get__() of a name property raises AttributeError).

You can find more information here: 

https://docs.python.org/3/reference/datamodel.html?highlight=__getattr__#object.__getattr__

--
nosy: +uriyyo
resolution:  -> not a bug
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

[issue45025] Reliance on C bit fields in C API is undefined behavior

[STINNER Victor]

STINNER Victor  added the comment:

> My use case for these low-level APIs is to write tests for low-level 
> string/encoding handling in my custom use of the PyPreConfig and PyConfig 
> structs. I wanted to verify that exact byte sequences were turned into 
> specific representations inside of Python strings. This includes ensuring 
> that certain byte sequences retain their appropriate "character" width in 
> internal storage.

CPython contains many checks to ensure that a string always use the most 
effecient storage, especially in debug mode. The C API should not allow to 
create a string using an inefficient storage, unless you "abuse" the C API :-D

I'm not sure what do you test.

--

___
Python tracker 

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

[issue14088] sys.executable generating canonical path

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-20443 "__code__. co_filename should always be an absolute path". I 
had a revert a change which affected sys.argv[0]:

commit a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b
Author: Victor Stinner 
Date:   Mon Dec 9 17:34:02 2019 +0100

bpo-20443: No longer make sys.argv[0] absolute for script (GH-17534)

In Python 3.9.0a1, sys.argv[0] was made an asolute path if a filename
was specified on the command line. Revert this change, since most
users expect sys.argv to be unmodified.

--

___
Python tracker 

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

[issue44019] operator.call/operator.__call__

[STINNER Victor]

STINNER Victor  added the comment:

> `call(f, *args, **kwargs) == f(*args, **kwargs)`

So you can want to reintroduce the Python 2 apply() function which was removed 
in Python 3.

You can reimplement it in 2 lines, no?

def call(func, *args, **kwargs):
  return func(*args, **kwargs)

--

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico  wrote:

> On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> > What about Phoenix?  In the winter, it's the same time there as it is in
> > San Francisco, but in the summer, it's the same time there as it is in
> > Denver (Phoenix doesn't observe Daylight Saving Time).
> 
> I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> as Phoenix, but in summer, Los Angeles changes its clocks away, and
> Denver changes to happen to be the same as Phoenix.

Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST.  San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.

> At least the US has governed DST transitions. As I understand it, any
> given city has to follow one of the standard time zones, and may
> EITHER have no summer time, OR transition at precisely 2AM/3AM local
> time on the federally-specified dates. (I think the EU has also
> mandated something similar for member states.)

That's my understanding, too.

> If we could abolish DST world-wide, life would be far easier. All the
> rest of it would be easy enough to handle.

Agreed.

> ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> timezone change ...

Yeah, I read about that somewhere.  Remember when the Pope declared that
September should skip a bunch of days?

> > Having lived in the United States my entire life (and being a nerd), I
> > can confirm that (1) I'm used to it and handle it as well as possible,
> > but (2) many people are not and don't.
> 
> Yup, absolutely. I've been working internationally for a number of
> years now, so my employment has been defined by a clock that isn't my
> own. I got used to it and developed tools and habits, but far too many
> people don't, and assume that simple "add X hours" conversions
> suffice.

Way back in the 1990s, I was working with teams in Metro Chicago, Tel
Aviv, and Tokyo (three separate teams, three really separate time zones,
at least two seaprate DST transition dates).  I changed my wristwatch to
24 hour time (and never looked back).  I tried UTC for a while, which
was cute, but confusing.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45042] Many multiprocessing tests are silently skipped since 3.9

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue45053] MD5SumTests.test_checksum_fodder fails on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> But there is also an issue in the script itself. It fails or produces a 
> mojibake when the filesystem encoding and the stdout encoding do not match.

I don't know Tools/scripts/md5sum.py. Can you show an example which currently 
fails?

--

___
Python tracker 

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

[issue45063] PEP 657 Fine Grained Error Locations: omit indicators if they are one the whole line, to make tracebacks shorter

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Python 3.11 makes it worse: up to 1.5x longer

Sound like you likely want to use the environment variable to deactivate the 
extra information ;)

--

___
Python tracker 

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

[issue45063] PEP 657 Fine Grained Error Locations: omit indicators if they are one the whole line, to make tracebacks shorter

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>In my example, there are 6 frames. The indicators cover the whole line of 3 
>frames: 50%. It's a common case, it's not special.

Special is not uncommon, is just some different behaviour rather than the 
default one. I am not arguing that is a rare scenario, I am arguing that is a 
special case.

--

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[Guido van Rossum]

Guido van Rossum  added the comment:

You're right, I'm being inconsistent. :-(  I withdraw my objection.

There are cases where sys.exit() is easier than returning an exit code, e.g. 
when the error is discovered deep inside some other code. But it's probably 
better to raise a dedicated exception in that case and catch it in main(), 
rather than just calling sys.exit() deep inside the other code. It's probably 
too fine a point for a tutorial. Sorry!

--

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-01 at 08:36:55 +1200,
> dn via Python-list  wrote:
>
> > ... there is less consideration about working-out what time it is in
> > Pune cf Kolkata, than between (say) San Francisco and Denver -
> > although they are in the same country, are they in the same time-zone,
> > or not?  (they aren't!)
>
> What about Phoenix?  In the winter, it's the same time there as it is in
> San Francisco, but in the summer, it's the same time there as it is in
> Denver (Phoenix doesn't observe Daylight Saving Time).

I prefer to say: In winter, San Francisco (or Los Angeles) is the same
as Phoenix, but in summer, Los Angeles changes its clocks away, and
Denver changes to happen to be the same as Phoenix.

> And then there's Indiana, a medium size state that tends to get ignored
> (they used to advertise "there's more than just corn in Indiana").  Most
> of Indiana is in US/Eastern, but the cities that are (for practical
> purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

At least the US has governed DST transitions. As I understand it, any
given city has to follow one of the standard time zones, and may
EITHER have no summer time, OR transition at precisely 2AM/3AM local
time on the federally-specified dates. (I think the EU has also
mandated something similar for member states.)

If we could abolish DST world-wide, life would be far easier. All the
rest of it would be easy enough to handle.

> ChrisA is right; you can't make this [stuff] up.

Yeah. And if you think you've heard it all, sign up for the
tzdata-announce mailing list and wait for the next phenomenon. I think
Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
change, for (with short notice) announcing that they'd have DST during
summer but not during Ramadan. Since "summer" is defined by a solar
calendar and "Ramadan" is defined by a lunar calendar, that means the
DST exclusion might happen entirely in winter (no effect), at one end
or other of summer (shortens DST, just changes the dates), or in the
middle of summer (DST on, DST off, DST on, DST off, in a single year).
But they will, at some point, be eclipsed by an even more bizarre
timezone change. I don't dare try to predict what will happen, because
I know that the reality will be even worse

> Having lived in the United States my entire life (and being a nerd), I
> can confirm that (1) I'm used to it and handle it as well as possible,
> but (2) many people are not and don't.

Yup, absolutely. I've been working internationally for a number of
years now, so my employment has been defined by a clock that isn't my
own. I got used to it and developed tools and habits, but far too many
people don't, and assume that simple "add X hours" conversions
suffice.

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

[issue39452] Improve the __main__ module documentation

[Géry]

Géry  added the comment:

@jack__d

Thanks for the rewrite! This is a great expansion. Unfortunately I didn’t have 
the time to review it before the merge. If I find something to be improved I 
will let you know.

@gvanrossum

> Your docs seem to promote the second, whereas I've usually preferred the 
> former.

Are you sure? Yet in your 2003 blog post [*Python main() 
functions*](https://www.artima.com/weblogs/viewpost.jsp?thread=4829) you 
promoted the opposite idiom `if __name__ == "__main__": sys.exit(main())` over 
the idiom `if __name__ == "__main__": main()`:

> Now the `sys.exit()` calls are annoying: when `main()` calls `sys.exit()`, 
> your interactive Python interpreter will exit! The remedy is to let 
> `main()`'s return value specify the exit status.

I am interested in the rationale if you changed your mind.

--

___
Python tracker 

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

[issue45063] PEP 657 Fine Grained Error Locations: omit indicators if they are one the whole line, to make tracebacks shorter

[STINNER Victor]

STINNER Victor  added the comment:

> I don't follow what you want to change in 3.10.0 final, PEP 657 is for Python 
> 3.11. Can you clarify?

Ah, I thaught that the PEP was implemented in 3.10, I didn't notice that it's a 
new feature of Python 3.11 :-)

> Regarding the issue: I understand what you mean but I don't think we should 
> get into suppressing the indicators in special situations.

In my example, there are 6 frames. The indicators cover the whole line of 3 
frames: 50%. It's a common case, it's not special.

Python tracebacks are already very verbose: a single exception can easily take 
20-30 lines. It's worse for chained exceptions. Python 3.11 makes it worse: up 
to 1.5x longer.

--
priority: release blocker -> 
title: PEP 657 Fine Grained Error Locations: make the traceback less verbose 
when possible -> PEP 657 Fine Grained Error Locations: omit indicators if they 
are one the whole line, to make tracebacks shorter

___
Python tracker 

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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue44895] refleak test failure in test_exceptions

[STINNER Victor]

STINNER Victor  added the comment:

> It could be a problem with the way _Py_RefTotal is incremented/decremented.

It can be a cache which is kept alive and then clear the following iteration. 
See my previous comment:

test leaked [-4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 
4] references, sum=0

libregrtest/refleak.py does its best to clear *all* caches, type caches, free 
lists, etc. A single cache which is not cleared can confused libregrtest.

--

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 08:36:55 +1200,
dn via Python-list  wrote:

> ... there is less consideration about working-out what time it is in
> Pune cf Kolkata, than between (say) San Francisco and Denver -
> although they are in the same country, are they in the same time-zone,
> or not?  (they aren't!)

What about Phoenix?  In the winter, it's the same time there as it is in
San Francisco, but in the summer, it's the same time there as it is in
Denver (Phoenix doesn't observe Daylight Saving Time).

And then there's Indiana, a medium size state that tends to get ignored
(they used to advertise "there's more than just corn in Indiana").  Most
of Indiana is in US/Eastern, but the cities that are (for practical
purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

ChrisA is right; you can't make this [stuff] up.

Having lived in the United States my entire life (and being a nerd), I
can confirm that (1) I'm used to it and handle it as well as possible,
but (2) many people are not and don't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
 wrote:
> > Yeah. I do recommend making good use of the IANA tzinfo database
> > though (especially since Python 3.9 made that a bit easier to access),
> > as it's usually easier to get people to tell you what city/state
> > they're in, rather than whether daylight time will be active or not.
> > (It might take a little bit of translation to figure out that, for
> > instance, New Brunswick CA is America/Halifax, but that's not too hard
> > usually.) Letting tzinfo do all the work means you don't have to fret
> > about anyone's daylight saving transition dates, or whether they've
> > decided to change their clocks by half an hour to be different from
> > Japan's clocks, or to have DST not applicable during Ramadan, or to
> > have double DST, or double-negative DST. And yes, those are all real,
> > because you can't make up anything as insane as actual clock politics.
>
> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> time numerically: "17:00-3"
>
> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> "1600", and I can figure it to be "0800" for me:
>
> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> and
> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
>   rounding to 24hrs: 08:00
>   (the next day)

No, that's not reliable... because of that abomination called Daylight
Saving Time. Since I used New Brunswick, and since she's just gone
online, I'll use a specific example:

DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
going to focus on a weekly event here). Since she lives in NB, Canada,
she defines that time by what IANA refers to as America/Halifax.

I want to be there at the start of each stream, since I'm one of her
moderators. But I live in a suburb of Melbourne - my clock shows what
IANA calls Australia/Melbourne.

To turn this into a purely mathematical calculation, you have to know
exactly when she will go on or off DST, and when I will go on or off.
Trying to turn it into an offset is going to fail badly as soon as you
talk about "next Tuesday" and one of us is shifting DST this weekend.

That's why it's better to let Python (or something) handle the whole
thing. Don't concern yourself with exactly what the hour differences
are, or which way DST is going, or anything; just convert Halifax time
to Melbourne time.

> For many of us, the mental-calculations are relatively easy to manage.
> For Python the code is trivial. Computation is easier than terminology
> 'translation' (particularly when one has to research the terms first!
> - did you know what "ADT" meant?)

I asked DeviCat what country and province ("state" in other regions)
she lived in, and then confirmed with her that Halifax time was what
her clock showed. The term "ADT" was never relevant.

In a lot of situations, you don't even need to ask the human - you can
let the web browser or desktop app report the timezone. The app can
say something like "In order to schedule this event,  will need to
know your time zone. Is that okay?" and then send the IANA timezone
name.

> Teasing @Chris: I'm not sure why it should be amusing that two entities
> called 'Ireland' should have different time-zones (pot?kettle) - after
> all, does "Western Australia" use the same time-zone as "South
> Australia"? For that matter, the same as the bulk of the Australian
> population?

Western Australia uses Australia/Perth timezone, and South Australia
uses Australia/Adelaide. They're different base times from the east
coast where I am by two hours, and half an hour, respectively; and
they have different DST rules.

On the east coast, we all have the same winter time, but in summer,
Melbourne, Sydney, and Hobart move clocks forward, but Brisbane
doesn't.

> The time-zone which perplexes me most, is India. This because it is not
> only a different hour, but also requires a 30-minute off-set - operating
> at UTC+5:30!

Yup, we got that too... Adelaide is half an hour back from Melbourne
(UTC+9:30). But it gets worse. Kathmandu is on a quarter hour. And the
Chatham Islands (part of New Zealand) are 12:45 ahead of UTC in
winter, and then they add an hour of DST in summer, putting them at
UTC+13:45.

> Fortunately, like China, the entire country (officially) operates in the
> same time-zone. Accordingly, there is less consideration about
> working-out what time it is in Pune cf Kolkata, than between (say) San
> Francisco and Denver - although they are in the same country, are they
> in the same time-zone, or not?
> (they aren't!)

That would be convenient for working within China, but on the flip
side, it means that geographically-nearby locations can have vastly
different clocks. Oh, and 

[issue42414] unable to document fields of dataclass

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Laurie: thanks for linking that, it seems like there isn't that much enthusiasm.

--

___
Python tracker 

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

[issue31299] Add "ignore_modules" option to TracebackException.format()

[Irit Katriel]

Irit Katriel  added the comment:


New changeset 863154c9292e70c5a8a1a3f22ef4ee42e2304281 by Irit Katriel in 
branch 'main':
bpo-31299: make it possible to filter out frames from tracebacks (GH-28067)
https://github.com/python/cpython/commit/863154c9292e70c5a8a1a3f22ef4ee42e2304281


--

___
Python tracker 

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 00.45, Chris Angelico wrote:
> On Tue, Aug 31, 2021 at 8:55 PM MRAB  wrote:
>> On 2021-08-31 02:16, dn via Python-list wrote:
>>> On 31/08/2021 11.07, Dennis Lee Bieber wrote:
 On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
  declaimed the following:
>>> ...
>>>
  Might have helped to mention you were in China... To me, CST is North
 America Central Standard Time (and I'd have expected this time of year to
 see CDT - Central Daylight Time)... That led me on a weird meaningless side
 track...
>>> ...
>>>
  I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
>>>
>>>
>> What annoys me is when someone starts that a webinar will start at, say,
>> xx ET. I have to know which country that person is in and whether
>> daylight savings is currently in effect (EST or EDT?) so that I can
>> convert to my local time.
> 
> If someone says "ET", then I would assume they mean America/New_York -
> it seems that only in the US do people so utterly assume that everyone
> else is in the same country. In Europe, I hear people say "CEST" and
> such (though I still prefer "Europe/Prague" or whatever country
> they're in), so the only issue there is that they don't always say
> "CEDT" when it's daylight time.

We tackle the inter-related subjects of "localisation" and
"internationalisation" in our (non-Python) training courses.

The 'problem' with a local-time, eg "0900 ET" (as above), is that it is
local. It is really only intended to communicate locally.

The definitions of "local" and 'local understanding' do vary. For
example, Australia stretches over multiple time-zones and thus people in
Melbourne are familiar with the idea of adjusting a Sydney-time to their
local clock. Similarly, US-based folk. However, many other localities
don't have such concerns and thus don't think that way!


At the level of "inter-personal communication", should one say (only)
what is in your head, or perform the 'translation' as a politeness to
your reader?

In @Chris' example, 'the reader' could be anywhere in the world. So, it
would be difficult, and lengthy, to provide for all - but should you
write such an invitation 'for all' ("Hi Everyone"), or should it be
addressed to the individual reader ("Dear Colleague")?

After years (decades!) of being woken in the early-hours of the morning
by (time-zone-ignorant) colleagues, my recommendation is to use both!


If the invitation is mine, typically I will write ("transmit") my local
time, because that is how I'm thinking as I type. On a
second-pass/editing the text, I will be considering how the reader will
"receive" the information.

If we're talking about a staff-meeting, it may be possible to list the
reader's time/date. In the case of an webinar hoping to attract
international participation, the recommendation is to add a
UTC-equivalent. (ideas developed, below)



>> It's so much easier to use UTC.
>>
>> I know what timezone I'm in and whether daylight savings is currently in
>> effect here, so I know the local offset from UTC.

Exactly! The very purpose of having an "international" standard.

Also, the very reason why Python has two groups of time-and-date
functions - so that one may work in local-time, or international-time/UTC.


Please note, the adjustments described (offsets) are *numeric*.
Accordingly, being told that one of our members resides 'at' UTC-4, and
knowing that I am currently at UTC+12, we can figure-out a 16-hour
'time-difference'.

NB in reality, having too few fingers, I would go 'the other way' (ie 24
- 16 ) and work with the idea that our colleague's clock is eight-hours
'ahead' of mine (so, as I've recently 'passed' 0800, that would make it
~1600/4pm for him - remembering that I am already 'in' Wednesday,
whereas Americans are still struggling to catch-up by finishing Tuesday)


> Yeah. I do recommend making good use of the IANA tzinfo database
> though (especially since Python 3.9 made that a bit easier to access),
> as it's usually easier to get people to tell you what city/state
> they're in, rather than whether daylight time will be active or not.
> (It might take a little bit of translation to figure out that, for
> instance, New Brunswick CA is America/Halifax, but that's not too hard
> usually.) Letting tzinfo do all the work means you don't have to fret
> about anyone's daylight saving transition dates, or whether they've
> decided to change their clocks by half an hour to be different from
> Japan's clocks, or to have DST not applicable during Ramadan, or to
> have double DST, or double-negative DST. And yes, those are all real,
> because you can't make up anything as insane as actual clock politics.

So, given that it is a NUMERIC calculation, dispense with "New Brunswick
CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
time numerically: "17:00-3"

Given that, someone at UTC-4 knows that his/her 

[issue42791] There is no way to json encode object to str.

[Irit Katriel]

Irit Katriel  added the comment:

See also Issue35111.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue42791] There is no way to json encode object to str.

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +ezio.melotti, rhettinger

___
Python tracker 

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

[issue24981] Add a test which uses the ast module to compile the stdlib

[Irit Katriel]

Irit Katriel  added the comment:

I think there is something like this here: 

https://github.com/python/cpython/blob/22fe0eb13c3441b71b60aaea0e7fe289a29783da/Lib/test/test_ast.py#L1498

--
nosy: +iritkatriel

___
Python tracker 

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

[issue21736] Add __file__ attribute to frozen modules

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

>> Would it be sufficient to hold a reference to the connection object?
>
> Yes

Good, that simplifies things. I'll wait with this until we've resolved PR 27940 
though.

--

___
Python tracker 

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

Re: Struggling to understand timedelta rpesentation when applying an offset for an hour earlier - why is days = -1?

[Chris Angelico]

On Wed, Sep 1, 2021 at 1:55 AM dcs3spp via Python-list
 wrote:
>
> Hi,
>
> I wonder if anyone can help
>
> I am struggling to understand the representation of timedelta when used in 
> conjunction with astimezone.
>
> Given the code below, in a python interactive interpreter, I am trying to 
> calculate a resultant datetime an hour earlier from a UTC datetime
>
> ```bash
> >>> dt = datetime(2021, 8, 22, 23, 59, 31, tzinfo=timezone.utc)
> >>> hour_before=dt.astimezone(timezone(-timedelta(seconds=3600)))
> >>> hour_before
> datetime.datetime(2021, 8, 22, 22, 59, 31, 
> tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=82800)))
> ```
>
> I cannot understand why the resultant datetime.timedelta is days=-1, 
> seconds=82800 (23 hours) .
>
> Why is it not an hour earlier as seconds=-3600? Why is days = -1 when the 
> resultant calculated date is the same, year, day, month??

It's consistent with modulo arithmetic:

>>> x = -3600
>>> x // 86400
-1
>>> x % 86400
82800

>>> help(datetime.timedelta)
...
 |  --
 |  Data descriptors defined here:
 |
 |  days
 |  Number of days.
 |
 |  microseconds
 |  Number of microseconds (>= 0 and less than 1 second).
 |
 |  seconds
 |  Number of seconds (>= 0 and less than 1 day).
 |
 |  --

The sub-day portions are guaranteed to be zero or above, meaning that
a small negative offset is described as "a day ago, plus 23 hours"
rather than "an hour ago". It's the exact same thing, though.

If you would prefer to see ALL components negative, just negate the
timedelta and then negate each component; that will give you an
equivalent timedelta.

>>> datetime.timedelta(seconds=-3600)
datetime.timedelta(days=-1, seconds=82800)
>>> -datetime.timedelta(seconds=-3600)
datetime.timedelta(seconds=3600)
>>> datetime.timedelta(seconds=-3600-86400)
datetime.timedelta(days=-2, seconds=82800)
>>> -datetime.timedelta(seconds=-3600-86400)
datetime.timedelta(days=1, seconds=3600)

Hope that explains it!

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

[issue45059] Typo: using "==" instead of "="

[Terry J. Reedy]

Change by Terry J. Reedy :


--
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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

miss-islington  added the comment:


New changeset 2280bc116301d45efc4d69cea452d272fdcd05b1 by Miss Islington (bot) 
in branch '3.9':
bpo-45059: Add module cleanup to IDLE test_macosx (GH-28102)
https://github.com/python/cpython/commit/2280bc116301d45efc4d69cea452d272fdcd05b1


--

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

miss-islington  added the comment:


New changeset 0f274cb2d78f71073e9d7295df3b9006e7bf1097 by Miss Islington (bot) 
in branch '3.10':
bpo-45059: Add module cleanup to IDLE test_macosx (GH-28102)
https://github.com/python/cpython/commit/0f274cb2d78f71073e9d7295df3b9006e7bf1097


--

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

Change by miss-islington :


--
pull_requests: +26548
pull_request: https://github.com/python/cpython/pull/28105

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

Change by miss-islington :


--
pull_requests: +26547
pull_request: https://github.com/python/cpython/pull/28104

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 22fe0eb13c3441b71b60aaea0e7fe289a29783da by Terry Jan Reedy in 
branch 'main':
bpo-45059: Add module cleanup to IDLE test_macosx (GH-28102)
https://github.com/python/cpython/commit/22fe0eb13c3441b71b60aaea0e7fe289a29783da


--

___
Python tracker 

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

Re: src layout for projects seems not so popular

[Paul Bryan]

An interesting thread in PyPA (with links to other threads) discussing
src layout:
https://github.com/pypa/packaging.python.org/issues/320

On Tue, 2021-08-31 at 10:53 +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings list,
> 
> Just an observation. Out of Github's trending repos for
> Python for today, I could find only 2 repos using the src layout.
> Matplotlib and another one.
> https://github.com/trending/python?since=daily
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius

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

[issue45055] Fresh build on Windows fails the first time for zlib.c

[Guido van Rossum]

Guido van Rossum  added the comment:

I've seen it a few times. I don't do this that often, but since I've discovered 
"git worktree" this has occurred to me a few times (can't recall if it was 
every time, but today wasn't the first). I'm totally happy to be the human in 
the retry loop. :-)

--

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 31.08.2021 20:14, Brett Cannon wrote:
> 
> Brett Cannon  added the comment:
> 
>> set __file__ (and __path__) on frozen modules?
> 
> See https://bugs.python.org/issue21736

The patch on that ticket is straight from PyRun, where the
__file__ location is set in a way which signals that the file
does not exist, but instead is baked into the executable:

>>> import os
>>> os.__file__
'/os.py'

Not doing this breaks too many tests in the test suite for no
good reason, which is why I mentioned "practicality beats
purity" in the ticket.

--

___
Python tracker 

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

[issue33426] [doc] Behavior of os.path.join does not match documentation

[Zachary Ware]

Change by Zachary Ware :


--
nosy: +zach.ware

___
Python tracker 

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

[issue44188] ThreadPoolExecutor unbalanced semaphore count

[Antoine Pitrou]

Antoine Pitrou  added the comment:

To be clear, this probably doesn't have any actual consequence, since the right 
number of threads is launched anyway (at least in the example). But it's 
probably worth making the implementation less quirky (also, the semaphore's 
internal counter *might* overflow at some point?).

--
components: +Library (Lib) -asyncio
nosy: +pitrou

___
Python tracker 

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

[issue45055] Fresh build on Windows fails the first time for zlib.c

[Diego Ramirez]

Change by Diego Ramirez :


--
nosy: +DiddiLeija

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[Diego Ramirez]

Change by Diego Ramirez :


--
nosy: +DiddiLeija

___
Python tracker 

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

[issue45066] email parser fails to decode quoted-printable rfc822 message attachemnt

[Diego Ramirez]

Change by Diego Ramirez :


--
nosy: +DiddiLeija

___
Python tracker 

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

[issue45066] email parser fails to decode quoted-printable rfc822 message attachemnt

[anarcat]

anarcat  added the comment:

looking at email.feedparser.FeedParser._parse_gen(), it looks like this is 
going to be really hard to fix, because the parser just happily recurses into 
the sub-part without ever checking the CTE (content-transfer-encoding). that's 
typically only done on "get_payload()", which is obviously not called there 
because we're streaming the email in.

in general, it looks like support for quoted-printable, as a CTE (which is 
https://datatracker.ietf.org/doc/html/rfc2045#section-6.7), seems to be spotty 
at best. multipart/ parts will raise the (undocumented) exception 
InvalidMultipartContentTransferEncodingDefect if they encounter it, for example:

https://github.com/python/cpython/blob/3.9/Lib/email/feedparser.py#L322

so I'm not sure how to handle this. it's not clear to me either how to 
workaround this problem at all... is there a way to keep the parser from 
recursing like this?

--

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Brett Cannon]

Brett Cannon  added the comment:

> set __file__ (and __path__) on frozen modules?

See https://bugs.python.org/issue21736

--

___
Python tracker 

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

[issue44188] ThreadPoolExecutor unbalanced semaphore count

[Antoine Pitrou]

Change by Antoine Pitrou :


--
versions: +Python 3.11 -Python 3.8

___
Python tracker 

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

[issue45039] use ADDOP_LOAD_CONST consistently

[miss-islington]

miss-islington  added the comment:


New changeset ebbd0ac5d8850a1630090c210b2454b4b26c7daa by Miss Islington (bot) 
in branch '3.10':
bpo-45039: Consistently use ADDOP_LOAD_CONST in compiler rather than ADDOP_O(c, 
LOAD_CONST,...) (GH-28015)
https://github.com/python/cpython/commit/ebbd0ac5d8850a1630090c210b2454b4b26c7daa


--

___
Python tracker 

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

[issue45066] email parser fails to decode quoted-printable rfc822 message attachemnt

[anarcat]

New submission from anarcat :

If an email message has a message/rfc822 part *and* that part is
quoted-printable encoded, Python freaks out.

Consider this code:

import email.parser
import email.policy

# python 3.9.2 cannot decode this message, it fails with
# "email.errors.StartBoundaryNotFoundDefect"

mail = """Mime-Version: 1.0
Content-Type: multipart/report;
 boundary=aa
Content-Transfer-Encoding: 7bit


--aa
Content-Type: message/rfc822
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=3D"=3Dbb"


--=3Dbb
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=3Dutf-8

x=
x

--=3Dbb--

--aa--
"""

msg_abuse = email.parser.Parser(policy=email.policy.default + 
email.policy.strict).parsestr(mail)

That crashes with: email.errors.StartBoundaryNotFoundDefect

This should normally work: the sub-message is valid, assuming you
decode the content. But if you do not, you end up in this bizarre
situation, because the multipart boundary is probably considered to be
something like `3D"=3Dbb"`, and of course the above code crashes
with the above exception.

If you remove the quoted-printable part from the equation, the parser actually 
behaves:

import email.parser
import email.policy

# python 3.9.2 cannot decode this message, it fails with
# "email.errors.StartBoundaryNotFoundDefect"

mail = """Mime-Version: 1.0
Content-Type: multipart/report;
 boundary=aa
Content-Transfer-Encoding: 7bit


--aa
Content-Type: message/rfc822
Content-Disposition: inline

MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=bb"


--=bb
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8

xx

--=bb--

--aa--
"""

msg_abuse = email.parser.Parser(policy=email.policy.default + 
email.policy.strict).parsestr(mail)

The above correctly parses the message.

This problem causes all sorts of weird issues. In one real-world
example, it would just stop parsing headers inside the email because
long lines in headers (typical in Received-by headers) would get
broken up... So it would not actually fail completely. Or, to be more
accurate, by *default* (ie. if you do not use strict), it does not
crash and instead produces invalid data (e.g. a message without a
Message-ID or From).

On most messages that are encoded this way, the strict mode will
actually fail with: email.errors.MissingHeaderBodySeparatorDefect
because it will stumble upon a header line that should be a
continuation but instead is treated like a full header line, so it's
missing a colon (":").

--
components: email
messages: 400764
nosy: anarcat, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email parser fails to decode quoted-printable rfc822 message attachemnt
type: crash
versions: Python 3.9

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

miss-islington  added the comment:


New changeset c1db7598790d037e58cd99c06d5c166433d63322 by Miss Islington (bot) 
in branch '3.9':
bpo-45059: Fix IDLE test typo: using "==" instead of "=" (GH-28086)
https://github.com/python/cpython/commit/c1db7598790d037e58cd99c06d5c166433d63322


--

___
Python tracker 

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

[issue45057] Simplify RegressionTestResult

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +26546
pull_request: https://github.com/python/cpython/pull/28103

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

miss-islington  added the comment:


New changeset 337c8adf31c46b688a5f82bcb64dc6f1ad56703d by Miss Islington (bot) 
in branch '3.10':
bpo-45059: Fix IDLE test typo: using "==" instead of "=" (GH-28086)
https://github.com/python/cpython/commit/337c8adf31c46b688a5f82bcb64dc6f1ad56703d


--

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +26545
pull_request: https://github.com/python/cpython/pull/28102

___
Python tracker 

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

[issue45039] use ADDOP_LOAD_CONST consistently

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

___
Python tracker 

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

[issue45057] Simplify RegressionTestResult

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2b76a5322fdf71d62b531fd765085f96f981c244 by Serhiy Storchaka in 
branch 'main':
bpo-45057: Simplify RegressionTestResult (GH-28081)
https://github.com/python/cpython/commit/2b76a5322fdf71d62b531fd765085f96f981c244


--

___
Python tracker 

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

[issue45057] Simplify RegressionTestResult

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +26544
pull_request: https://github.com/python/cpython/pull/28101

___
Python tracker 

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

[issue45039] use ADDOP_LOAD_CONST consistently

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +26543
pull_request: https://github.com/python/cpython/pull/28100

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Definitely a typo.  Will apply fix and backport.

The first import of macosx initializes _tk_type to None.  The line in question 
intends to re-initialize it so that the subsequent assert can only pass if 
_init_tk_type changes it to something required.

Many other tests also set _tk_type as needed.  _tk_type should be restored in 
tearDownModule.  I will add that in a separate PR.  (The class cleanup already 
restores platform.)

--

___
Python tracker 

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

[issue45039] use ADDOP_LOAD_CONST consistently

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 70ccee418d1f9d34ed15cfe7104221f9cfd27d03 by Irit Katriel in 
branch 'main':
bpo-45039: Consistently use ADDOP_LOAD_CONST in compiler rather than ADDOP_O(c, 
LOAD_CONST,...) (GH-28015)
https://github.com/python/cpython/commit/70ccee418d1f9d34ed15cfe7104221f9cfd27d03


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 54f100514b02f6628450043e21ccfe39350d7ac7 by Serhiy Storchaka in 
branch 'main':
bpo-45059: Fix IDLE test typo: using "==" instead of "=" (GH-28086)
https://github.com/python/cpython/commit/54f100514b02f6628450043e21ccfe39350d7ac7


--
message_count: 1.0 -> 2.0
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +26541
pull_request: https://github.com/python/cpython/pull/28098

___
Python tracker 

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

[issue45059] Typo: using "==" instead of "="

[miss-islington]

Change by miss-islington :


--
pull_requests: +26542
pull_request: https://github.com/python/cpython/pull/28099

___
Python tracker 

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

Re: Trouble propagating logging configuration

[Dieter Maurer]

Loris Bennett wrote at 2021-8-31 15:25 +0200:
>I am having difficulty getting the my logging configuration passed on
>to imported modules.
>
>My initial structure was as follows:
>
>  $ tree blorp/
>  blorp/
>  |-- blorp
>  |   |-- __init__.py
>  |   |-- bar.py
>  |   |-- foo.py
>  |   `-- main.py
>  `-- pyproject.toml
>
>whereby the logging configuration is done in main.py.
>
>After thinking about it, I decided maybe the inheritance wasn't working
>because main.py is in the same directory as the other files.

Should you speak about Python's `logging` module, then
the "inheritance" does not depend on the source layout.
Instead, it is based on the hierarchy of dotted names.
It is completely up to you which dotted names you are using
in your `getLogger` calls.

Furthermore, the place of the configuration (and where in the
code it is activated) is completely irrelevant for the "inheritance".

For details, read the Python documentation for the `logging` module.
-- 
https://mail.python.org/mailman/listinfo/python-list