[Python-Dev] Re: PEG parser and raw strings
28.05.20 22:26, Vito De Tullio пише: Hi. Just a question about the new PEG parser: will it support lone slash in raw strings? the fact that r'\' doesn't work as expected it's a strange exception to remember. As others said, this is a part of the tokenizer. I once experimented with changing the tokenizer to make a backslash always inert in raw strings. This change breaks code in ~15 files in the stdlib and tests, so it would likely break a large amount of user code. The cost is too high. https://github.com/python/cpython/pull/15217 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MBCBDAJROOZD52P3OUSGC6BHMFZEJQC3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-05-22 - 2020-05-29)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7487 ( +9)
closed 45080 (+80)
total 52567 (+89)
Open issues with patches: 3011
Issues opened (58)
==
#39343: Travis CI: documentation job fails in library/nntplib.rst with
https://bugs.python.org/issue39343 reopened by chris.jerdonek
#40133: Provide additional matchers for unittest.mock
https://bugs.python.org/issue40133 reopened by gregory.p.smith
#40733: Make IDLE doc more visible, mention in main python docs page
https://bugs.python.org/issue40733 opened by phr
#40734: /usr/bin surprisingly in sys.path under IDLE
https://bugs.python.org/issue40734 opened by phr
#40735: test_nntplib: sporadic failures, NetworkedNNTP_SSLTests.test_w
https://bugs.python.org/issue40735 opened by chris.jerdonek
#40736: better message for re.search TypeError ("expected string or by
https://bugs.python.org/issue40736 opened by chris.jerdonek
#40739: find_library broken for binutils >= 2.32 / 2.34
https://bugs.python.org/issue40739 opened by Frederik Rietdijk
#40741: Upgrade to SQLite v3.32.1 in Windows and macOS builds
https://bugs.python.org/issue40741 opened by erlendaasland
#40742: Doc: Parallel build break audit table
https://bugs.python.org/issue40742 opened by mdk
#40743: [CMake] It's 2020, where is CMake?
https://bugs.python.org/issue40743 opened by TheUltimatePineapple
#40744: Explicitly drop support for SQLite version < 3.7.3
https://bugs.python.org/issue40744 opened by erlendaasland
#40745: Typo in library/typing
https://bugs.python.org/issue40745 opened by hectorcanto
#40746: test_gdb failing on Raspbian on 3.9, regression from 3.8
https://bugs.python.org/issue40746 opened by gregory.p.smith
#40747: sysconfig.get_config_var("py_version_nodot") should return 3_1
https://bugs.python.org/issue40747 opened by mattip
#40748: Tutorial 4.7 More on Defining Functions missing screen prompts
https://bugs.python.org/issue40748 opened by Chas Belov
#40749: Consider adding decorator for required inner class
https://bugs.python.org/issue40749 opened by Elijah Rippeth
#40754: ModuleNotFoundError: No module named '_testinternalcapi' under
https://bugs.python.org/issue40754 opened by honglei.jiang
#40756: Second argument of LoggerAdapter.__init__ should default to No
https://bugs.python.org/issue40756 opened by arturoescaip
#40757: tarfile: ignore_zeros = True won't raise exception even on inv
https://bugs.python.org/issue40757 opened by mxmlnkn
#40758: For 7.2.7. Code Examples, distinguish between the Tutorial and
https://bugs.python.org/issue40758 opened by Chas Belov
#40759: Deprecate the symbol module
https://bugs.python.org/issue40759 opened by BTaskaya
#40762: Writing bytes using CSV module results in b prefixed strings
https://bugs.python.org/issue40762 opened by sidhant
#40763: zipfile.extractall is safe by now
https://bugs.python.org/issue40763 opened by VA
#40766: Add support for SQLITE_DIRECTONLY and SQLITE_INNOCUOUS for use
https://bugs.python.org/issue40766 opened by erlendaasland
#40767: Allow pure Wayland to get default XDG webbrowser
https://bugs.python.org/issue40767 opened by Jeremy Attali
#40769: Pegen: cover extra surrounding parentheses for invalid annotat
https://bugs.python.org/issue40769 opened by BTaskaya
#40770: RFE: Run linkchecker on documentation on the CI
https://bugs.python.org/issue40770 opened by hroncok
#40771: python3 fromtimestamp generates OSError
https://bugs.python.org/issue40771 opened by jamercee
#40772: module 'resource' has no attribute 'RLIMIT_VMEM'
https://bugs.python.org/issue40772 opened by Titusz Ban
#40773: DOC: Fix rendering for 'retval' on the pdb page
https://bugs.python.org/issue40773 opened by cheryl.sabella
#40775: Fix missing dot in sqlite3 Node type name
https://bugs.python.org/issue40775 opened by erlendaasland
#40777: _datetimemodule.c:3328:16: error: initializer element is not c
https://bugs.python.org/issue40777 opened by smani
#40782: AbstactEventLoop.run_in_executor is listed as an async method,
https://bugs.python.org/issue40782 opened by jamesba
#40785: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails
https://bugs.python.org/issue40785 opened by ngie
#40786: madvise should be accessible outside of mmap instance
https://bugs.python.org/issue40786 opened by ngie
#40788: Build issue Solaris 10 Sparc
https://bugs.python.org/issue40788 opened by munocat
#40791: hmac.compare_digest could try harder to be constant-time.
https://bugs.python.org/issue40791 opened by Devin Jeanpierre
#40794: dataclass signatures and docstrings w/future-annotations
https://bugs.python.org/issue40794 opened by BTaskaya
#40797: multiprocessing.Semaphore has undocumented get_value() method
https://bugs.python.org/issue40797 opened by remi.lapeyre
#40798: Th
[Python-Dev] Repr: where to place the address and additional info?
The default repr of Python object is formatted using the following pattern:
<{typename} object at {address:#x}>
And many custom reprs use similar patterns, but add some additional type
specific information. The type name first, followed by details and
address. All is surrounded by angle quotes. The question is in what
order to show address and other details? Should the address be at rear
or in the middle?
<{typename} {details} at {address:#x}>
<{typename} at {address:#x} {details}>
There are examples of both ways in the stdlib. I am going to add new
custom reprs [1] and need to know what pattern looks better.
Also, is "object" mandatory after the type name?
<{typename} object {details} at {address:#x}>
<{typename} object at {address:#x} {details}>
[1] https://bugs.python.org/issue24391
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ANF7LRGBQ2AWP2KUJKHVY3GGQRH6PDYD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repr: where to place the address and additional info?
On 2020-05-29 21:02, Serhiy Storchaka wrote:
The default repr of Python object is formatted using the following pattern:
<{typename} object at {address:#x}>
And many custom reprs use similar patterns, but add some additional type
specific information. The type name first, followed by details and
address. All is surrounded by angle quotes. The question is in what
order to show address and other details? Should the address be at rear
or in the middle?
<{typename} {details} at {address:#x}>
<{typename} at {address:#x} {details}>
There are examples of both ways in the stdlib. I am going to add new
custom reprs [1] and need to know what pattern looks better.
Also, is "object" mandatory after the type name?
<{typename} object {details} at {address:#x}>
<{typename} object at {address:#x} {details}>
[1] https://bugs.python.org/issue24391
FWIW, my preference is for the address at the end for reasons already
stated in the issue.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/JK2LVYUTO4VJHFERETLD2RJLNJJVARKB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repr: where to place the address and additional info?
If you are going to give details, you'd better use the "equivalent expression" kind of repr. As I explained earlier in the "Enum._convert
should change __repr__", the angle brackets repr doesn't actually give any information that the user can rely upon except the type and the
address.
On 29.05.2020 23:02, Serhiy Storchaka wrote:
The default repr of Python object is formatted using the following pattern:
<{typename} object at {address:#x}>
And many custom reprs use similar patterns, but add some additional type specific information. The type name first, followed by details
and address. All is surrounded by angle quotes. The question is in what order to show address and other details? Should the address be at
rear or in the middle?
<{typename} {details} at {address:#x}>
<{typename} at {address:#x} {details}>
There are examples of both ways in the stdlib. I am going to add new custom
reprs [1] and need to know what pattern looks better.
Also, is "object" mandatory after the type name?
<{typename} object {details} at {address:#x}>
<{typename} object at {address:#x} {details}>
[1] https://bugs.python.org/issue24391
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ANF7LRGBQ2AWP2KUJKHVY3GGQRH6PDYD/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/2SK5LUEC6UZVFVCZF45W2BO7KPR2Y24Z/
Code of Conduct: http://python.org/psf/codeofconduct/
