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

[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

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 in

[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: 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: 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]], Optional[list[Data[T

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

[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 C+

[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] 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, but

[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? But

[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), bu

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

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

[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: 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 o

[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 https://github.com/python/cpython/issues/93

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

[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: 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 so

[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: 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 sta

[Python-Dev] Re: PEP 572 TargetScopeError

08.08.19 20:00, Barry Warsaw пише: Rather than just a vote, if you have a rationale for one over the other, I’d love to hear it. Feel free to weigh in here or on the issue. I do not have arguments for SyntaxError but the rationale for TargetScopeError does not look strong to me. IndentationE

[Python-Dev] Re: What to do about invalid escape sequences

09.08.19 18:30, Guido van Rossum пише: This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? Possible options: 1. SyntaxWarning in 3.8+ (the current status). 2. DeprecationWarning in 3.8, SyntaxWarning in 3.9+ (revert changes in 3.8 only). 3. Depr

[Python-Dev] Re: What to do about invalid escape sequences

09.08.19 19:39, Steve Dower пише: I also posted another possible option that helps solve the real problem faced by users, and not just the "we want to have a warning" problem that is purely ours. Warnings solve two problems: * Teaching users that a backslash has special meaning and should be

[Python-Dev] Re: What to do about invalid escape sequences

10.08.19 02:04, Gregory P. Smith пише: I've merged the PR reverting the behavior in 3.8 and am doing the same in the master branch. I was going to rebase it to master and go in normal backporting process if we decide that DeprecationWarning should be in master. I waited the end of the discuss

[Python-Dev] Re: What to do about invalid escape sequences

10.08.19 22:10, Glenn Linderman пише: As pointed out elsewhere, Raw strings have limitations, paths ending in \ cannot be represented, and such do exist in various situations, not all of which can be easily avoided... except by the "extra character contortion" of   "C:\directory\ "[:-1]  (does

[Python-Dev] Raw string literals and trailing backslash

Currently a raw literal cannot end in a single backslash (e.g. in r"C:\User\"). Although there are reasons for this. It is an old gotcha, and there are many closed issues about it. This question is even included in FAQ. The most common workarounds are: r"C:\User" "\\" and r"C:\User\

[Python-Dev] Re: What to do about invalid escape sequences

11.08.19 23:07, Glenn Linderman пише: On 8/11/2019 1:26 AM, Serhiy Storchaka wrote: 10.08.19 22:10, Glenn Linderman пише: I wonder how many raw strings actually use the \"  escape productively? Maybe that should be deprecated too! ?  I can't think of a good and necessary use f

[Python-Dev] Re: Raw string literals and trailing backslash

12.08.19 22:41, Glenn Linderman пише: On 8/12/2019 12:08 AM, Serhiy Storchaka wrote: Currently a raw literal cannot end in a single backslash (e.g. in r"C:\User\"). Although there are reasons for this. It is an old gotcha, and there are many closed issues about it. This questio

[Python-Dev] Re: What to do about invalid escape sequences

12.08.19 22:51, Glenn Linderman пише: On 8/12/2019 12:11 AM, Serhiy Storchaka wrote: For example, in many cases `\"` can be replaced with `"'"'r"`, but it does not look pretty readable. No, that is not readable.  But neither does it seem to be valid syntax, or

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

29.08.19 18:35, Steve Dower пише: The main reason for making it as a per-machine install by default was because there was no other way to replace the Python 3.4 launcher, but I suspect that's less of an issue now. (If the old one wasn't replaced, it would take precedence over the new per-user

[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?

20.09.19 22:19, Vinay Sajip via Python-Dev пише: I just ran an analysis of static variable definitions in CPython code, using clang, on Ubuntu and Windows. The results should be available here: https://cpython.red-dove.com/ As I understand it, _Py_IDENTIFIER instances are supposed to hold cons

[Python-Dev] Re: small improvement idea for the CSV module

29.10.19 22:37, Oz Tiram пише: Quite a few tutorials show how to use namedtuple to gain memory saving and speed, over the DictReader. Python's own documentation has got a recipe in the collections modules[1] Hence, I was wondering why not go the extra step and add a new class to the CSV module

[Python-Dev] Do not fallback to __trunc__ when convert to int

Currently __trunc__ is used for two purposes: * In math.trunc() which just calls __trunc__. * In int() and PyNumber_Long() as a fallback if neither __int__ nor __index__ are implemented. Unlike to __int__ and __index__ there is not a slot corresponding to __trunc__. So using it is slower than

[Python-Dev] Re: Do not fallback to __trunc__ when convert to int

01.11.19 00:03, Guido van Rossum пише: It seems a good idea to add __int__ to Fraction, but if you stop falling back to __trunc__, won't that cause backwards compatibility issues? Most numeric types (int, float, Decimal, NumPy types) implement both __trunc__ and __int__. The only known excepti

[Python-Dev] Deprecating the "u" string literal prefix

The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix?

[Python-Dev] Re: Deprecating the "u" string literal prefix

03.12.19 19:31, Guido van Rossum пише: I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated. Yes, I also think that it is too early to deprecate it just now. Python 2 is not completely dead yet. But I would ha

[Python-Dev] Re: Deprecating the "u" string literal prefix

03.12.19 23:44, Ned Batchelder пише: On 12/3/19 12:16 PM, Serhiy Storchaka wrote: The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features

[Python-Dev] Re: Deprecating the "u" string literal prefix

04.12.19 04:41, Ned Batchelder пише: On 12/3/19 8:13 PM, Inada Naoki wrote: I think it is too early to determine when to remove it. Even only talking about it causes blaming war. Has anyone yet given a reason to remove it? It will change working code into broken code. Why do that? Why the "

[Python-Dev] Re: Macros instead of inline functions?

04.12.19 14:08, Skip Montanaro пише: As I wander around the code base, I keep seeing macro definitions in the C code. For example, there are four CALL* macros defined in Python/ast_opt.c which contain not entirely trivial bits of syntax. That code is from 2017 (as compared to, say, Modules/audioo

[Python-Dev] Re: Macros instead of inline functions?

04.12.19 18:54, Skip Montanaro пише: I don't think stable code which uses macros should be changed (though I see the INCREF/DECREF macros just call private inline functions, so some conversion has clearly been done). Still, in new code, shouldn't the use of macros for more than trivial use cases

[Python-Dev] Re: Macros instead of inline functions?

04.12.19 22:12, Skip Montanaro пише: This is my last post on this, at least as far as specific usage instances are concerned. See my question about PEP 7 below. If that is a discussion people think worthwhile, please start a new thread. if (!VISIT(...)) { return 0; }

[Python-Dev] Re: Deprecating the "u" string literal prefix

04.12.19 16:02, Anders Munch пише: Victor Stinner [mailto:vstin...@python.org] wrote: You may want to have a look at the deferred PEP 501 -- General purpose string interpolation: https://www.python.org/dev/peps/pep-0501/ I'm struggling to see what i-strings would do for i18n that str.format d

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

06.12.19 21:16, Kyle Stanley пише: Would it be reasonable to require an minimum amount of versions to be specified (such as n versions ahead), but provide flexibility in terms to delaying the removal, as needed? IMO, it would be more convenient for users to have a "minimum removal" version in m

[Python-Dev] Re: Documenting sorted/min/max prerequisites

14.12.19 12:45, Steven D'Aprano пише: The list.sort method is documented to only use less than: https://docs.python.org/3/library/stdtypes.html#list.sort but I don't think that is correct, it seems to use greater than if it exists and less than doesn't. My understanding is that items need to de

[Python-Dev] Re: Documenting sorted/min/max prerequisites

14.12.19 15:29, Steven D'Aprano пише: I might be misinterpreting the evidence, but sorting works on objects that define `__gt__` without `__lt__`. py> class A: ... def __init__(self, x): self.x = x ... def __gt__(self, other): return self.x > other.x ... py> L = [A(9), A(1), A(8)] py> L.

[Python-Dev] Re: Documenting sorted/min/max prerequisites

15.12.19 12:27, Steven D'Aprano пише: Since list.sort guarantees that it will only use the `<` less than operator, should we make the same guarantee for sorted, min and/or max? Perhaps. And also for heapq and maybe some other functions. Do you mind to create a PR? It is common to make generi

[Python-Dev] Parameters of str(), bytes() and bytearray()

Currently str() takes up to 3 arguments. All are optional and positional-or-keyword. All combinations are valid: str() str(object=object) str(object=buffer, encoding=encoding) str(object=buffer, errors=errors) str(object=buffer, encoding=encoding, errors=errors) str(encoding=encoding) str(errors

[Python-Dev] Re: Should set objects maintain insertion order too?

16.12.19 04:48, Larry Hastings пише: As of 3.7, dict objects are guaranteed to maintain insertion order.  But set objects make no such guarantee, and AFAIK in practice they don't maintain insertion order either.  Should they? I do have a use case for this. In one project I maintain a "ready" l

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 02:55, Kyle Stanley пише: I'd much prefer to see something like this: >>> str(b'\xc3\xa1') ... TypeError: bytes argument without an encoding Is there some use case for returning "b'\\xc3\\xa1'" from this operation that I'm not seeing? To me, it seems equally, if not more confusing and

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

15.12.19 16:30, David Mertz пише: I bet someone in the world has written code like: foo = str(**dynamic-args()) And therefore, disabling "silly" combinations of arguments will break their code occasionally. Do you have real world examples? ___ Pyth

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 10:34, Eric V. Smith пише: On 12/16/2019 3:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable for

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 18:35, Guido van Rossum пише: On Sun, Dec 15, 2019 at 6:09 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: 1. Forbids calling str() without object if encoding or errors are specified. It is very unlikely that this can break a real code, so I propose to m

[Python-Dev] Re: Should set objects maintain insertion order too?

17.12.19 14:05, Ivan Levkivskyi пише: As a random data point, I often see the pattern where one needs to remove duplicates from the list while preserving the order of first appearance. This is for example needed to get stability in various type-checking situations (like union items, type variab

[Python-Dev] Re: Should set objects maintain insertion order too?

26.12.19 00:56, Tim Peters пише: - I don't have a theory for why dict build time is _so_ much higher than dict lookup time for the nasty keys. 1/2 of items were copied to a new hashtable when the dict grew up. 1/4 of items were copied twice. 1/8 of items were copied three times, etc. In avera

[Python-Dev] Re: Documenting Python's float.__str__()

21.01.20 10:37, Eric V. Smith пише: For what it's worth, float's repr internally uses a format of '.17g'. So, format(value, '.17g') will be equal to repr(f), where f is any float. It was in Python 2, but since Python 3.1 it returns the shortest unambiguous representation, which may be shorter

[Python-Dev] Re: Documenting Python's float.__str__()

21.01.20 12:37, Eric V. Smith пише: Yes (I wrote a lot of that), but '.17g' doesn't mean to always show 17 digits. See https://github.com/python/cpython/blob/master/Python/pystrtod.c#L825 where the repr (which is format_code =='r') is translated to format_code = 'g' and precision = 17. But I

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

23.01.20 17:20, Victor Stinner пише: Incompatible changes which require "if : (...) else: (...)" or "try: except (...): ": * Removed tostring/fromstring methods in array.array and base64 modules * Removed collections aliases to ABC classes * Removed fractions.gcd() function (which is similar to

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

24.01.20 01:36, Barry Warsaw пише: Given that we’ve changed the release cadence to one major release per year, it doesn’t seem that much of a burden to revert and carry these changes forward into Python 3.10. And if it helps with the migration off of Python 2.7, then +1 from me. There are e

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 03:29, Tim Peters пише: If it's intended that Python-the-language requires this, that needs to be documented. I think it is already documented somewhere. Even Python implementations like collections.abc.Sequence and collections.abc.Mapping were changed to use `x is y or x == y` inste

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 10:29, Serhiy Storchaka пише: Even Python implementations like collections.abc.Sequence and collections.abc.Mapping were changed to use `x is y or x == y` instead of just `x == y` few versions ago. https://bugs.python.org/issue26915

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 13:57, Chris Angelico пише: Are there any non-container uses where this comes up? Can the rule be codified simply as that container membership, in all core/stdlib types, is defined by "x is y or x == y"? Also a membership test for iterators (which is already explicitly documented).

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

23.01.20 17:20, Victor Stinner пише: > * Removed collections aliases to ABC classes Adding loud warning was one of largest compatibility breaking changes in 3.8, because many active projects treat warnings in tests as errors. I had doubts about removing them. On one side, they were deprecated

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

25.01.20 00:29, Tim Peters пише: I think it needs more words, though, to flesh out what about this is allowed by the language (as opposed to what CPython happens to do), and to get closer to what Guido is trying to get at with his "*implicit* calls". For example, it's at work here, but there's n

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

We could introduce parallel kinds of collections: ValueList/IdentityList, ValueDict/IdentityDict, etc. Ones would use comparison by value and do not preserve identity (so we could use more efficient storage for homogeneous collections, for example a list of small ints could spend 1 byte/item).

[Python-Dev] Re: PEP 584: Add Union Operators To dict

05.02.20 14:27, Musbur пише: I have one suggestion: Wouldn't it be useful for these operators to also accept sets (functionally acting like a dict with None for all values)? This would make it very elegant to 'normalize' dicts by pruning (dict & set) or padding (set | dict) dictionaries. I woul

[Python-Dev] Re: PEP 584: Add Union Operators To dict

06.02.20 21:38, Brandt Bucher пише: One issue that's come up during PR review with Guido and Serhiy is, when evaluating `a | b`, whether or not the default implementation should call an overridden `copy()` method on `a` in order to create an instance of the correct subclass (rather than a plai

[Python-Dev] Re: Clarification of unpacking semantics.

06.02.20 08:28, Brandt Bucher пише: Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation logic of unpacking operations. Previously, all elements were evaluated prior to being collected in a container. Now, these operations are interleaved. For example, the code `[*a, *b]` use

[Python-Dev] Re: PEP 584: Add Union Operators To dict

07.02.20 01:00, Paul G пише: I will note that it doesn't seem to be true that operators never call standard methods. Looks like date.__add__ calls date.toordinal and date.fromordinal (at least in the pure Python implementation), and datetime calls those plus tzinfo.utcoffset. Not sure if the ru

[Python-Dev] Re: Clarification of unpacking semantics.

07.02.20 01:00, Guido van Rossum пише: How did we move from [*a,...] to print(*a,...)? They are quite different. They are quite similar. The code for `(*a, *b, *c)` is: 1 0 LOAD_NAME0 (a) 2 LOAD_NAME1 (b) 4 LOAD_NAME

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

17.02.20 23:02, Guido van Rossum пише: Now that the last bits of discussion about PEP 584 have been settled (we will *not* be calling the `copy` or `update` methods) I am accepting this PEP. Congratulations Steven and Brandt! Thanks to everyone else who gave their opinion. Formally, I will ju

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

18.02.20 19:35, Brandt Bucher пише: ...it was decided that `d1 | d2` also should ignore the types of the operands and always return a dict. And it accepts only dicts, not general mappings, in difference to `{**d1, **d2}`. So the only disadvantage of `{**d1, **d2}` is that it is not well known a

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

27.02.20 10:46, Chris Angelico пише: On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka wrote: sympy/utilities/runtests.py Sorry, but the current code globs = globs.copy() if extraglobs is not None: globs.update(extraglobs) looks much clearer to me than the proposed globs = globs

[Python-Dev] Re: How to respond to repeated bad ideas

03.03.20 01:03, Skip Montanaro пише: Atm we don't have an index of ideas, apart from pep 3099, and I'm not sure we can make one (can we?), so I do not see a way to prevent this from happening. Maybe an informational PEP which briefly lists rejected ideas? There is a risk to accept this PEP a

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

26.03.20 00:08, Cameron Simpson пише: I think a more "Python normal" module might have multiple enum classes, maybe with overlapping names. Do you have any examples of more "Python normal" modules? We discuss here the behavior of the private method Enum._convert_() used exclusively in the std

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

26.03.20 01:04, Cameron Simpson пише: My concern is basicly that in normal Python usage, the names within a class (and thus the names in an enum) are named to be distinct within the class namespace. So I would not expect the names for particular values to have extra qualification (eg I expect t

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

26.03.20 01:35, Ivan Pozdeev via Python-Dev пише: E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I would search the code for "AddressFamily" to see what I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

25.03.20 21:54, Ethan Furman пише: Serhiy had the idea of having Enum._convert also modify the __str__ and __repr__ of newly created enumerations to display the module name instead of the enumeration name (https://bugs.python.org/msg325007): --> socket.AF_UNIX    ==>  --> print(socket.AF_UNIX)

[Python-Dev] Re: reversed enumerate

01.04.20 21:45, Ilya Kamenshchikov пише: I needed reversed(enumerate(x: list)) in my code, and have discovered that it wound't work. This is disappointing because operation is well defined. It is also well defined for str type, range, and - in principle, but not yet in practice - on dictionary

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

03.04.20 18:13, joannah nanjekye пише: From my CS theory, a control flow graph models a program flow and one of its main characteristics is it has one entry and exit point. IIRC, CPython’s compilation process involves generation of a control flow graph. Contrary to peephole optimizations, opt

[Python-Dev] Re: Question about bytecode stability

06.04.20 06:48, Jonathan Goble пише: My question is, are the opcodes guaranteed stable across the lifetime of a single 3.x release? In other words, are they guaranteed to not change values or semantics between 3.x.y and 3.x.(y+1)? Reading through the list of opcodes in the dis documentation, it

[Python-Dev] Re: Improvement to SimpleNamespace

15.04.20 05:59, Raymond Hettinger пише: SimpleNamespace() is really good at giving attribute style-access. I would like to make that functionality available to the JSON module (or just about anything else that accepts a custom dict) by adding the magic methods for mappings so that this works:

[Python-Dev] Re: Improvement to SimpleNamespace

15.04.20 10:06, Raymond Hettinger пише: [Serhiy] As a workaround you can use object_hook=lambda x: SimpleNamespace(**x) That doesn't suffice because some valid JSON keys are not valid identifiers. You still need a way to get past those when they arise: catalog.books.fiction['Paradise Lost

[Python-Dev] Re: Adding a "call_once" decorator to functools

01.05.20 01:23, Paul Ganssle пише: class LazyList:     def __init__(self, some_iterator):     self._iter = some_iterator     self._list = None     @call_once     def as_list(self):     self._list = list(self._iter)     return self._list call_once is not applicable here,

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

06.05.20 00:46, Victor Stinner пише: Subinterpreters and multiprocessing have basically the same speed on this benchmark. It does not look like there are some advantages of subinterpreters against multiprocessing. I am wondering how much 3.9 will be slower than 3.8 in single-thread single-i

[Python-Dev] Deprecate os.removedirs() and os.renames()

It seems to me that os.removedirs() and os.renames() was added just for symmetry with os.makedirs(). All three functions have similar structure and was added in the same commit. Seems they were initially code examples of using some os.path and os functions. Unlike to quite popular os.makedirs(

[Python-Dev] Re: Please welcome our next Release Manager, Pablo!

20.05.20 01:54, Barry Warsaw пише: In light of the release of Python 3.9b1, let’s take a moment to celebrate all the great work that our Python 3.8 and 3.9 release manager Łukasz has done. The role of Python Release Manager is hugely important to each successful release, and it can be a lot o

[Python-Dev] Re: Map errno==ETIME to TimeoutError

24.05.20 17:48, Eric V. Smith пише: Does anyone have an opinion on https://bugs.python.org/issue39673? It maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT. http://man7.org/linux/man-pages/man3/errno.3.html says: *ETIME *Timer expired (POSIX.1 (XSI STREAMS optio

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

[Python-Dev] Cycles in the __context__ chain

It is possible to create a loop by setting the __context__ attribute of the raised exception, either explicitly, or implicitly, using "raise ... from ...". Creating a loop can leads to the hanging in infinite loop or crash due to stack overflow. Several years ago we did have issues related to E

[Python-Dev] How to specify optional support of arguments

In Python 3.3 a number of functions in the os module got the support of new options, like dir_fd or follow_symlinks. I well remember this because the initial reason of my contribution to CPython was related to this feature. The support of new options was platform dependent. They were supported

[Python-Dev] Re: How to specify optional support of arguments

14.06.20 23:45, Ivan Pozdeev via Python-Dev пише: 1. The documentation clearly says that it's supported depending on OS flavor -- so if I want to know if I can supply it, I need to rather check `os.name`. Those members are thus redundant.     If the distinction is finer than os.name then I'd

[Python-Dev] Re: How to specify optional support of arguments

15.06.20 04:06, Greg Ewing пише: Instead of a bunch of ad-hoc mechanisms for finding out about platform-dependent arguments, maybe there should be a function in the inspect module for testing whether a function has a given argument. Then you could say something like    if inspect.hasargument(gl

[Python-Dev] Re: When can we remove wchar_t* cache from string?

12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "

[Python-Dev] Re: Improving inspect capabilities for classes

16.06.20 21:02, Guido van Rossum пише: It would certainly be much easier to get through the review process. Adding a `__filename__` (why not `__file__`?) attribute to classes is a major surgery, presumably requiring a PEP, and debating the pros and cons and performance implications and fixing a

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

17.06.20 11:42, Victor Stinner пише: zip(strict=True) should help to write more reliable code. Maybe it's time to review stdlib code to check if some functions would deserve the addition of strict=True? I had a look and found a few suspicious usage of zip(). But I'm not sure if we want to make th

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

19.06.20 02:57, Guido van Rossum пише: On Thu, Jun 18, 2020 at 2:36 PM Eric Fahlgren > wrote: We've implemented the new zip in our sitecustomize.py, and think the keyword makes it easier.  I've instructed our development staff to examine all use of zip

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

23.06.20 12:18, Victor Stinner пише: For example, we can consider continuing to provide raw access to a PyObject** array, but an object can reply "sorry, I don't support this PyObject** protocol". Also, I expect to have a function call to notify the object when the PyObject** view is not longer n

<    5   6   7   8   9   10   11   12   >