[Python-Dev] Re: Possible bug in `re` module in Python 3.11?

26.10.22 11:17, Piotr Waszkiewicz пише: Hi, I would like to ask your guidance as I'm entirely sure whether the problem I'm experiencing should be posted in CPython's repo as a bug issue. I've tried using newly released Python 3.11 interpreter in some of my projects and one of them failed to

[Python-Dev] Re: Adding new escapes to regex module

17.08.22 19:34, MRAB пише: It's not just Java. Perl supports all 4 of \h, \H, \v and \V. That might be why Java 8 changed. But Perl does not have conflict between strings and regular expressions, because regular expression is a separate syntax construct.

[Python-Dev] Re: Adding new escapes to regex module

16.08.22 23:24, MRAB пише: Other regex implementations have escape sequences for horizontal whitespace (`\h` and `\H`) and vertical whitespace (`\v` and `\V`). The regex module already supports `\h`, but I can't use `\v` because it represents `\0x0b', as it does in the re module. Now that

[Python-Dev] Re: Raw strings ending with a backslash

28.05.22 18:03, Damian Shaw пише: My understanding was that was part of the question being asked, is it possible to know what with the new PEG parser? You first need to define what is the end of a string. And I think it is not relevant to the grammar parser.

[Python-Dev] Re: Raw strings ending with a backslash

28.05.22 14:57, Damian Shaw пише: That PR seems to make \' and \" not special in general right? I think this is a more limited proposal, to only change the behavior when \ is at the end of a string, so the only behavior difference would never receiving the error "SyntaxError: EOL while

[Python-Dev] Re: Raw strings ending with a backslash

28.05.22 12:22, Steven D'Aprano пише: Now that we have a new parser for CPython, can we fix the old gotcha that raw strings cannot end in a backslash? Its an FAQ and has come up again on the bug tracker. https://docs.python.org/3/faq/design.html#id26

[Python-Dev] Re: Starting a new thread

10.05.22 18:12, Barney Stratford пише: This has a couple of advantages. I don’t have to import the threading module all over my code. I can use the neater syntax of function calls. The function’s definition makes it clear it’s returning a new thread since it’s decorated. It gets the plumbing

[Python-Dev] Re: Python grammar test cases

10.05.22 08:10, Venkat Ramakrishnan пише: I'm wondering if there's a repository of test cases that test the Python grammar. Any help would be appreciated. See test_grammar and test_syntax. And there are some test files for specific grammar features, like test_string_literals, test_unpack_ex,

[Python-Dev] Re: __dunder__ = None

01.05.22 19:32, Guido van Rossum пише: Non should behave as closely as possible to it not being defined at all. So return NotImplemented. But, as was noted by Spencer Brown, it is not how it works for __iter__(), __reversed__() and __contains__() (which have a special path for producing

[Python-Dev] Re: __dunder__ = None

01.05.22 13:02, Spencer Brown пише: It actually is documented as being supported here: https://docs.python.org/3.10/reference/datamodel.html#id2 , and as mentioned there __iter__(), __reversed__() and __contains__() also have special

[Python-Dev] __dunder__ = None

There is a special handling of `__hash__` set to None in the interpreter core. This is because every class inherited the `__hash__` attribute from "object", and setting `__hash__ = None` is a simple way to make it unhashable. It makes hash() raising the correct type of exception (TypeError),

[Python-Dev] Re: Restrict the type of __slots__

18.03.22 11:29, Serhiy Storchaka пише: It will break some code (there are 2 occurrences in the stdlib an 1 in scripts), but that code can be easily fixed. Actually it will break more code, because initializing __slots__ with a list is pretty common. Maybe restrict it to tuple or list

[Python-Dev] Restrict the type of __slots__

Currently __slots__ can be either string or an iterable of strings. 1. If it is a string, it is a name of a single slot. Third-party code which iterates __slots__ will be confused. 2. If it is an iterable, it should emit names of slots. Note that non-reiterable iterators are accepted too,

[Python-Dev] Make __mro_entries__ mandatory for non-types

Currently the class can inherit from arbitrary objects, not only types. If the object was not designed for this you can get a mysterious mistake, e g.: >>> class A(1): ... ... Traceback (most recent call last): File "", line 1, in TypeError: int() takes at most 2 arguments (3 given) If the

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

07.02.22 19:09, Victor Stinner пише: > After my NAN change (bpo-46640), Petr Viktorin asked me to update the > PEP 7. I proposed a change to simply say that "Python 3.11 and newer > versions use C99": But public headers should be compatible with C++, and not all C99 features are compatible with

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

07.02.22 17:55, Victor Stinner пише: > I'm asking to replace runtime checks with assertions when the C API is > "obviously" misused: replace PyErr_BadInternalCall(), > _Py_CheckFunctionResult() and _Py_CheckSlotResult() with assertions. > The exact scope should be defined. Would not be better to

[Python-Dev] Re: Suggestion: a little language for type definitions

08.01.22 01:59, jack.jan...@cwi.nl пише: >> If I can make a wild suggestion: why not create a little language for >> type specifications? We need a way to define aliases. For example, write: Data = Mapping[str, Sequence[Tuple[int, T]]] Factory = Callable[[int, Iterable[str]],

[Python-Dev] Re: Function Prototypes

24.12.21 00:09, Guido van Rossum пише: > Without decorator too (that was Lukasz’ idea). Why bother with the > decorator (*if* we were to go there)? It is errorprone. Some library provide function foo() which returns an instance of private type _Foo and people start using it as a type hint. A new

[Python-Dev] Re: The python command help is too long

20.12.21 21:34, Guido van Rossum пише: > Fair enough. Quick design proposal: > >   -h and --help print info about flags (existing flags) >   --help-env (or --env-help?) prints info about env vars (new flag) >   -X help prints info about -X options (new -X option) > > Two lines printed at the end

[Python-Dev] Re: RFC on Callable Syntax PEP

20.12.21 21:28, Brett Cannon пише: > As someone with use of this, would you find this useful (i.e. +1, +0)? > Serhiy already said "no" in another thread. In every file we import 5-10 or more names from the typing module. We still does not use PEP 585 and PEP 604 syntax, but are going to do this

[Python-Dev] Re: RFC on Callable Syntax PEP

20.12.21 13:42, Mark Shannon пише: > OOI, of those 1577 Callable type hints, how many distinct Callable types? Around 15-20%. Most of them are in tests which widely use pytest fixtures, so functions taking and returning callables are common. There are around 200 occurrences in non-test code, half

[Python-Dev] Re: RFC on Callable Syntax PEP

18.12.21 23:07, Terry Reedy пише: > Batuhan expresses my concerns better than I could, so I just add my > agreement. > > On 12/18/2021 3:13 PM, Batuhan Taskaya wrote: > >> tl;dr: I find it very troubling that we are going on a path where need >> to increase the language complexity (syntax) only

[Python-Dev] The python command help is too long

The output of "python -h" is 104 lines long now. It was only 51 lines in 3.6. 35% of it is about the -X option, and 30% about environment variables. Also some lines in the -X option description are too long (102 columns). Both topics are "advanced" and mostly interested for debugging. I suggest to

[Python-Dev] Re: multiple inheritance and `__str__`

01.12.21 09:56, Ethan Furman пише: > Some searching turned up issue 36793: "Do not define unneeded __str__ > equal to __repr__" . > > As can be seen, `__str__` is needed for inheritance to work properly.  > Thoughts on reverting that patch? As the author of issue36793 I do not think so. If you

[Python-Dev] Re: Optimizing literal comparisons and contains

29.11.21 18:36, Victor Stinner пише: > You should consider "no longer have to justify why it's not optimized" > as a clear benefit of making this change :-) This optimization is > proposed once a year for many years... > > For me, any possible compilation-ahead optimization (which doesn't > break

[Python-Dev] Re: Optimizing literal comparisons and contains

29.11.21 14:32, Mark Shannon пише: > Excluding  1 < 2 seems inconsistent. It is not excluded, it is just not included. There should be reasons for adding any feature, and the benefit should exceed the cost. ___ Python-Dev mailing list --

[Python-Dev] Re: Optimizing literal comparisons and contains

27.11.21 15:47, Jeremiah Vivian пише: > Many operations involving two literals are optimized (to a certain level). So > it sort of surprises me that literal comparisons are not optimized and > literal contains only convert the right operand to a constant if possible. > I'd like to implement

[Python-Dev] Re: Optimizing literal comparisons and contains

28.11.21 17:13, Skip Montanaro пише: >> That is not entirely true: >> https://github.com/python/cpython/pull/29639#issuecomment-974146979 > > The only places I've seen "if 0:" or "if False:" in live code was for > debugging. Optimizing that hardly seems necessary. In any case, the > original

[Python-Dev] Re: Do we need to remove everything that's deprecated?

12.11.21 12:55, Petr Viktorin пише: >   AttributeError: '[...]Tests' object has no attribute 'failUnless' > (bpo-45162) This one caused me troubles more then one time. It is so easy to make a typo and write assertEquals instead of assertEqual or assertRaisesRegexp instead of assertRaisesRegex.

[Python-Dev] Re: Having Sorted Containers in stdlib?

10.11.21 01:47, Bob Fang пише: > 1) Some mainstream language support them out of box: C++ for example > have set/map which are sorted by the key order, and Java has TreeMap > which is internally a Red-black tree. >From my C++ and Java experience, hashtable-based containers are much more useful

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

03.11.21 15:14, Stephen J. Turnbull пише: > So the only > time that wouldn't be true is if escape sequences are allowed to > represent characters. I believe unicode_escape is the only codec > that does. Also raw_unicode_escape and utf_7. And maybe punycode or idna, I am not sure.

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

03.11.21 14:31, Petr Viktorin пише: > For example: should the parser emit a lightweight audit event if it > finds a non-ASCII identifier? (See below for why ASCII is special.) > Or for encoding declarations? There are audit events for import and compile. You can also register import hooks if you

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

03.11.21 12:36, Petr Viktorin пише: > On 03. 11. 21 2:58, Kyle Stanley wrote: >> I'd suggest both: briefer, easier to read write up for average user in >> docs, more details/semantics in informational PEP. Thanks for working >> on this, Petr! > > Well, this is the brief write-up :) > Maybe it

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

03.11.21 11:01, Stephen J. Turnbull пише: > And of > course UTF-16 is incompatible in that sense, although I don't know if > anybody actually saves Python code in UTF-16. CPython does not currently support UTF-16 for source files. ___ Python-Dev

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

02.11.21 18:49, Jim J. Jewett пише: > If escape sequences were also allowed in comments (or at least in strings > within comments), this would make sense. I don't like banning them > otherwise, since odd characters are often a good reason to need a comment, > but it is definitely a "mention,

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

02.11.21 16:16, Petr Viktorin пише: > As for \0, can we ban all ASCII & C1 control characters except > whitespace? I see no place for them in source code. All control characters except CR, LF, TAB and FF are banned outside comments and string literals. I think it is worth to ban them in comments

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

This is excellent! 01.11.21 14:17, Petr Viktorin пише: >> CPython treats the control character NUL (``\0``) as end of input, >> but many editors simply skip it, possibly showing code that Python >> will not >> run as a regular part of a file. It is an implementation detail and we will get rid of

[Python-Dev] Re: RFC on Callable Type Syntax

12.10.21 00:03, Guido van Rossum пише: > But if I see > >     def Comparison(a: T, b: T) -> Literal[-1, 0, 1]: >     ... > > my first thought is that it's a comparison function that someone hasn't > finished writing yet, not a function type -- since if it did have at > least one line of code

[Python-Dev] Re: What is __int__ still useful for?

14.10.21 12:24, Eryk Sun пише: > Maybe an alternate constructor could be added -- such as > int.from_number() -- which would be restricted to calling __int__(), > __index__(), and __trunc__(). See thread "More alternate constructors for builtin type" on Python-ideas:

[Python-Dev] Re: What is __int__ still useful for?

13.10.21 20:10, Antoine Pitrou пише: > It used to be that defining __int__ allowed an object to be accepted as > an integer from various functions, internal and third-party, thanks to > being implicitly called by e.g. PyLong_AsLong. > > Today, and since bpo-37999, this is no longer the case. It

[Python-Dev] Re: Packing a long list of numbers into memory

11.10.21 01:35, MRAB пише: > Maybe what's needed is to add, say, '*' to the format string to indicate > that multiple values should come from an iterable, e.g.: > >     struct.pack_into(f'{len(nums)}*Q', buf, 0, nums) > > in this case len(nums) from the nums argument. See

[Python-Dev] Re: Why doesn't peephole optimise away operations with fast locals?

10.10.21 23:38, Guido van Rossum пише: > What's exasperating to me about this whole discussion is that nobody has > shown any reason why this kind of code would be occurring in user code. > STORE_FAST x LOAD_FAST x seems that it must come from a user writing > >     x = x No, it comes from

[Python-Dev] Re: Packing a long list of numbers into memory

10.10.21 19:05, Patrick Reader пише: > This still isn't a completely direct write - you're still creating an array > in between which is then copied into shm, whereas struct.pack_into writes > directly into the shared memory with no intermediate buffer. > > And unfortunately you can't do > >

[Python-Dev] Re: Packing a long list of numbers into memory

10.10.21 18:18, Facundo Batista пише: > You mean `array` from the `array` module? The only way I see using it > is like the following: > shm = shared_memory.SharedMemory(create=True, size=total_size) a = array.array('Q', nums) shm.buf[l_offset:r_offset] = a.tobytes() > > But I

[Python-Dev] Re: Packing a long list of numbers into memory

10.10.21 17:19, Facundo Batista пише: > I have a long list of nums (several millions), ended up doing the following: > > struct.pack_into(f'{len(nums)}Q', buf, 0, *nums) Why not use array('Q', nums)? ___ Python-Dev mailing list --

[Python-Dev] Re: RFC on Callable Type Syntax

07.10.21 19:41, S Pradeep Kumar пише: > 1. Syntax to replace Callable > > After a lot of discussion, there is strong consensus in typing-sig about > adding syntax to replace Callable. So, the above example would be > written as: > ```python > def print_purchases( >     user: User, >    

[Python-Dev] Re: Should I care what -3.14 // inf produces?

30.09.21 10:07, Jeff Allen пише: from decimal import Decimal Decimal('-3.14') // Decimal('Infinity') > Decimal('-0') You do not need an infinity to see the difference. >>> Decimal('3.14') % Decimal('2') Decimal('1.14') >>> Decimal('3.14') % Decimal('-2') Decimal('1.14') >>>

[Python-Dev] Re: Changing exception text in micro releases

24.09.21 16:51, Eric V. Smith пише: > This is clearly an improvement. My question is: is it okay to backport > this to 3.9 and 3.10? I think we have a rule that it's okay to change > the exception text, but I'm not sure how that applies to micro releases > (3.9.x, 3.10.1). I am sure that it will

[Python-Dev] Re: f-strings in the grammar

20.09.21 14:18, Pablo Galindo Salgado пише: > * The parser will likely have "\n" characters and backslashes in > f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d", "\x5c", etc? What about newlines in single quotes? Currently this works: f'''{1 + 2}'''

[Python-Dev] deprecated-removed

I always thought that the "deprecated" directive is used if the term of removing the deprecated feature is not set yet, and the "deprecated-removed" directive is used if it is set. After removing the feature both directives are replaced with the "versionchanged" directive which only specifies the

[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object

08.09.21 08:19, David Mertz, Ph.D. пише: > I attempted to do this today, as my first actual contribution to CPython > itself.  I think the prior attempt went down a wrong path, which is why > neither PR could actually pass tests. > > I've been looking at `posixmodule.c` for comparison,

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

29.08.21 23:16, Brett Cannon пише: > If you look at > https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451 > > you will see that `async

[Python-Dev] Re: Making code object APIs unstable

13.08.21 20:24, Guido van Rossum пише: > If these weren't part of the stable ABI, I'd choose (E). But because > they are, I think only (A) or (B) are our options. The problem with (C) > is that if there's code that links to them but doesn't call them (except > in some corner case that the user can

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

11.08.21 21:35, Brett Cannon пише: > So my question is whether we want to push to be more diligent about > updating What's New by b1 so people can provide feedback during the > betas beyond just reporting breaking changes? I think that What's New should be updated as soon as possible, immediately

[Python-Dev] types.Union or types.UnionType?

In 3.10 the union type (the type of the result of the | operator for types) was added (https://www.python.org/dev/peps/pep-0604/). It is exposed as types.Union. There are differences between typing.Union and types.Union: * typing.Union is indexable, types.Union is not. * types.Union is a class,

[Python-Dev] Re: Delayed evaluation of f-strings?

24.06.21 12:37, Eric Nieuwland пише: > In a recent discussion with a colleague we wondered if it would be > possible to postpone the evaluation of an f-string so we could use it > like a regular string and .format() or ‘%’. You can just use lambda: delayed_fstring = lambda: f"The current

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

07.06.21 08:41, Hai Shi пише: > There have an another question. There have many C API defined under > PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT(). > Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory? We should support binary compatibility to some degree, so there

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

07.06.21 06:05, Inada Naoki пише: > Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted > DeprecationWarning when > '#' format is used without PY_SSIZE_T_CLEAN defined. > In Python 3.10, they raise a RuntimeError, not a warning. Extension > modules can not use '#' format with

[Python-Dev] Re: Proposal: declare "unstable APIs"

06.06.21 06:48, Guido van Rossum пише: > On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner > wrote: > If possible, I would prefer to make PyThreadState, PyCodeObject and > other structures opaque, and only go through getter and setter > functions ;-)

[Python-Dev] Re: Proposal: declare "unstable APIs"

04.06.21 12:08, Petr Viktorin пише: > It is used, and I started the work :) > See e.g. > https://docs.python.org/3.10/c-api/sequence.html#c.PySequence_Concat Great news! Several core developers (including me) tried to solve this problem, but a large amount of work stopped us at an early stage.

[Python-Dev] Re: Proposal: declare "unstable APIs"

03.06.21 20:10, Guido van Rossum пише: > This is not a complete thought yet, but it occurred to me that while we > have deprecated APIs (which will eventually go away), and provisional > APIs (which must mature a little before they're declared stable), and > stable APIs (which everyone can rely

[Python-Dev] Re: In what tense should the changelog be written?

30.04.21 05:57, Larry Hastings пише: > When one writes one's "blurb" for the changelog, in what tense should it > be? See the previous discussion on this topic: https://mail.python.org/archives/list/python-dev@python.org/thread/C342Y73LALVFLI2ACFB3SH6ZDT2YTGPC/ . I always use "fixed", "removed",

[Python-Dev] Re: str() vs format(): trivia question

20.04.21 17:56, Ethan Furman пише: > urllib.urlencode currently uses `str()` on its non-bytes objects before > encoding the result.  This causes a compatibility break when integer > module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no > longer returns the integer representation;

[Python-Dev] Re: str() vs format(): trivia question

20.04.21 22:01, Guido van Rossum пише: > So to be clear, that one user wants f"{Color.RED}" to return "1" and not > " Color.RED" (or  something like that). The user should write f"{int(Color.RED)}" or f"{Color.RED.value}". I have also an idea to support of additional conversion characters, so

[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

16.04.21 16:07, Victor Stinner пише: > I propose to change the -W command line option and the PYTHONWARNINGS > environment variable to use the message as a regular expression in > Python 3.10. Or does anyone have a reason to keep the current behavior > as it is? > > I created

[Python-Dev] Re: How about using modern C++ in development of CPython ?

24.03.21 11:54, redrad...@gmail.com пише: > What about of using modern C++ in developing CPython ? > > With C++ we can get the following benefits: > 1) Readability - less code, most code is hidden by abstraction without losing > performance > 2) Maintainability - no code duplication in favor of

[Python-Dev] Re: 0xfor 3. Parser bug?

14.04.21 13:22, Stefano Borini пише: > This was just posted on SO > > https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3 > > I can reproduce it with a simpler example > 0xfor 3 > 15 > > Is it a bug in the parser, or working as intended? It's not

[Python-Dev] Re: Boundaries between numbers and identifiers

26.04.18 21:37, Serhiy Storchaka пише: > In Python 2.5 `0or[]` was accepted by the Python parser. It became an > error in 2.6 because "0o" became recognizing as an incomplete octal > number. `1or[]` still is accepted. > > On other hand, `1if 2else 3` is accepted despit

[Python-Dev] Re: NamedTemporaryFile and context managers

08.04.21 23:31, Ethan Furman пише: > In issue14243 [1] there are two issues being tracked: > > - the difference in opening shared files between posix and Windows > - the behavior of closing the underlying file in the middle of >   NamedTemporaryFile's context management > > I'd like to address

[Python-Dev] Re: When we remove 'U' mode of open()?

07.04.21 19:13, Victor Stinner пише: > Hi Inada-san, > > I'm +0 on removing again the flag, but I would prefer to not endorse > the responsibility. I am already responsible for enough incompatible > changes in Python 3.10 :-D > > Some context on this "U" open mode. The flag is accepted by many >

[Python-Dev] Re: Where and how can I contribute?

26.03.21 20:37, Terry Reedy пише: > On 3/26/2021 6:29 AM, Marco Sulla wrote: >> I would contribute to the project in my spare time. Can someone point >> me to some easy task? I know C and the Python C API a little. > > Review existing PRs.  In some cases (ask), convert existing patches > posted

[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

18.03.21 03:39, Victor Stinner пише: > I'm happy to see that Python 3.10 now also implements faster bytecode > which rely on this change ;-) It was used long time ago before 3.10. For example: a[i] = \ f() 2 0 LOAD_NAME0 (f) 2 CALL_FUNCTION

[Python-Dev] Re: [Release management] schedule for renaming the default branch

10.03.21 16:06, Pablo Galindo Salgado пише: > # What you need to do? > > You just need to update your local clone after the branch name changes. > From the local clone of the repository on a computer, > run the following commands to update the name of the default branch. > > $ git branch -m

[Python-Dev] Re: Signature discrepancies between documentation and implementation

09.02.21 12:22, Erlend Aasland пише: > What's the recommended approach with issues like > https://bugs.python.org/issue43094? Change the docs or the implementation? I > did a quick search on bpo, but could not find similar past issues. If the documentation and the C implemented function

[Python-Dev] Re: What's up with assignment expression and tuples?

05.02.21 09:51, Paul Sokolovsky пише: > a0 = 0 > b0 = 10 > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > a2 = a1 + 1 > b2 = b1 + 1 Such code quickly becomes unreadable. Especially if in real code function has additional arguments and names are longer that 2-3 characters. The

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

13.01.21 01:28, Victor Stinner пише: > I looked at Sphinx and Python versions of Debian, Ubuntu and Fedora: > https://bugs.python.org/issue42843#msg384963 > > In my list, there is only Debian Buster (stable) which doesn't have > Sphinx 3 yet. It uses Python 3.7 and so would not be affected by >

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

12.01.21 22:38, Julien Palard via Python-Dev пише: > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that > we could work around, some are bit harder, so we may need to bump > `needs_sphinx = '3.2'`

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

12.01.21 03:21, Larry Hastings пише: > I forgot about __slots__!  Yup, it's optional, and you can even delete > it, though after the class is defined I'm not sure how much difference > that makes. It affects pickling if __slotnames__ is not set yet. The latter is set when you pickle or copy an

[Python-Dev] Re: why include cpython/*.h, Need this macro ? # error "this header file must not be included directly"

10.01.21 09:53, junyixie пише: > #ifndef Py_LIMITED_API > # define Py_CPYTHON_FILEOBJECT_H > # include "cpython/fileobject.h" > # undef Py_CPYTHON_FILEOBJECT_H > #endif > > cpython/fileobject.h > ``` > #ifndef Py_CPYTHON_FILEOBJECT_H > # error "this header file must not be included directly"

[Python-Dev] Re: Where is the SQLite module maintainer

27.12.20 22:20, Erlend Aasland пише: > Who can help me review code that touches the sqlite3 module code base? > > > I've received a lot of constructive reviews from Victor Stinner, Dong-he > Na and Pablo Galindo on my past sqlite3 PR's; thank you so much! I still > feel uncomfortable requesting

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

17.11.20 11:55, Mark Shannon пише: > I'm wondering why > ``` > x = "value" > try: >     1/0 > except Exception as x: >     pass > ``` > > does not restore "value" to x after > the `except` block. > > There doesn't seem to be an explanation for this behavior in the docs or > PEPs, that I can

[Python-Dev] Re: When to remove BytesWarning?

11.11.20 15:05, John Hagen пише: > If I recall, it was str(bytes) warning that flagged in a few places and was > missing a .decode() call or similar. > > It seems like the bytes== warnings could be implemented in a type checker > such as mypy, if it doesn't > already do this. Assuming you have

[Python-Dev] Re: Who is target reader of tutorial?

05.11.20 11:12, Inada Naoki пише: > Since "How To" guide is not organized well, it is very tempting to > write all details in tutorial. > I have seen may pull requests which "improve" tutorial by describe > more details and make > the tutorial more perfect. > > But adding more and more

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

29.10.20 23:43, Victor Stinner пише: > * Current best effort support (no change): changes only happen if a > core dev volunteers to review and merge a change written by a > contributor. It is my preference. Several years ago I tested and fixed Python on OpenIndiana in virtual machine, but I was

[Python-Dev] Re: Macro for logging

21.10.20 15:30, Antoine Pitrou пише: > On Wed, 21 Oct 2020 14:19:37 +0200 > Marco Sulla wrote: >> If not already present, do you think it's useful to add a macro that does >> something like >> >> # ifdef Py_DEBUG >> fprintf(stderr, "%s\n", message); >> # endif > > In general, you want to do

[Python-Dev] Re: When to remove BytesWarning?

24.10.20 06:19, Inada Naoki пише: > To avoid BytesWarning, the compiler needs to do some hack when they > need to store bytes and str constants in one dict or set. > BytesWarning has maintenance costs. It is not huge, but significant. > > When can we remove it? My idea is: > > 3.10: Deprecate

[Python-Dev] Re: When to remove BytesWarning?

26.10.20 10:10, Inada Naoki пише: > Of course, there are some runtime costs too. > > https://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Modules/_functoolsmodule.c#L802 >

[Python-Dev] Re: Pickle for C extension?

19.10.20 20:39, Marco Sulla пише: > TL;DR Is it possible to use C code to implement the (un)pickling of an > type written in a C extension, as it was written in _pickle.c? > > Long explaining: I'm trying to create a C extension for frozendict. For > simplicity, first I wrote it in CPython, then I

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 20:56, Brett Cannon пише: > I think if the project is not maintained externally and thus synced into > the stdlib we can drop the attributes. I have found only one exception. decimal.__version__ refers to the version of the external specification which was not changed since 2009. I think

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

15.10.20 14:59, Victor Stinner пише: > If the __version__ variable is used, I suggest to start with a > deprecation period using a module __getattr__(): emit > DeprecationWarning, and only remove these variables in 2 Python > releases (PEP 387). This is a good idea, I though about it. But it

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 23:25, Batuhan Taskaya пише: > I've indexed a vast majority of the files from top 4K pypi packages to > this system, and here are the results about __version__ usage on > argparse, cgi, csv, decimal, imaplib, ipaddress, optparse, pickle, > platform, re, smtpd, socketserver, tabnanny

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 23:25, Batuhan Taskaya пише: > I've indexed a vast majority of the files from top 4K pypi packages to > this system, and here are the results about __version__ usage on > argparse, cgi, csv, decimal, imaplib, ipaddress, optparse, pickle, > platform, re, smtpd, socketserver, tabnanny

[Python-Dev] Remove module's __version__ attributes in the stdlib

Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

09.10.20 16:48, Antoine Pitrou пише: > Also, we now have an unmaintained module > (_decimal) requiring specific competence. It is not so bad. Due to high quality of the module there were not much changes in it in recent years, and many of them were cosmetic. We also have other Decimal experts.

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

04.10.20 01:06, Guido van Rossum пише: > On Sat, Oct 3, 2020 at 9:28 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: > The code of object.__dir__() is very old, it predates new-style classes, > and currently it gathers names using different algorithm than us

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

03.10.20 18:15, Guido van Rossum пише: > Is this the only place where a non-class object with __bases__ is > accepted? Or do we have more such? I recall that long ago you could use > certain non-class objects as base classes. The only other place is object.__dir__(). It recursively iterates the

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

03.10.20 12:45, Steven D'Aprano пише: > On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote: >> issubclass() accept types (extension types and new-style classes), >> classic classes and arbitrary objects with the __bases__ attribute as >> its arguments. >

[Python-Dev] Do we still need a support of non-type objects in issubclass()?

issubclass() accept types (extension types and new-style classes), classic classes and arbitrary objects with the __bases__ attribute as its arguments. The latter was added in issue464992 [1] to support the Zope extension ExtensionClass. I tested the current code of ExtensionClass [2], and seems

[Python-Dev] Re: Understanding why object defines rich comparison methods

23.09.20 03:05, Greg Ewing пише: > On 23/09/20 12:20 am, Steven D'Aprano wrote: >> Presumably back when rich comparisons were added, the choice would have >> been: >> >> - add one tp_richcompare slot to support all six methods; or >> >> - add six slots, one for each individual dunder >> >> in

[Python-Dev] Re: Enum and the Standard Library

22.09.20 16:57, Ethan Furman пише: > On 9/22/20 12:11 AM, Serhiy Storchaka wrote: >> The only exception is StrEnum -- overriding __str__ of str >> subclass may be not safe. Some code will call str() implicitly, other >> will read the string content o

  1   2   3   4   5   6   7   8   9   10   >