[Python-ideas] Re: Efficiency of set difference

06.06.22 10:51, Stephen J. Turnbull пише: Couldn't it be linear on min(len(left), len(right))? Ie, if len(left) < len(right): for elem in left: if elem in right: left.discard(elem) else: for elem in right: left.discard(elem)

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

03.06.22 21:43, Nadav Misgav пише: should I try to implement this? seems there is some acceptance No core developer supported this feature. My example shows that there is a problem with the proposed syntax. It is too similar to the existing valid syntax, it will confuse both people and the

[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions

01.06.22 16:59, Chris Angelico пише: On Wed, 1 Jun 2022 at 23:55, Serhiy Storchaka wrote: The advantage is that you cannot accidentally turn a function into a generator by adding "yield". If the result of the call is ignored (it is expected to be None), this bug can live a

[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions

31.05.22 16:21, Chris Angelico пише: On Tue, 31 May 2022 at 23:00, Aaron L via Python-ideas wrote: After getting used to writing async functions, I’ve been wanting use a similar syntax to declare generator functions. What's the advantage? You can just use normal function syntax to define

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

19.05.22 09:45, nadav.mis...@gmail.com пише: Awesome! never seen this syntax used before and the above libraries are not using it. Can you elaborate on the else part ? Why is it needed for the syntax to be correct and could you put any expression in the parenthesis ?

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

18.05.22 22:08, Nadav Misgav пише: I was thinking of a way to expand the current try-expect block to support condinitial expect block. I was imagining the new syntax as try:     expression block expect Exception if condition     expression block where the expect expression block would only

[Python-ideas] Re: infile and outfile parameters for the input function

02.05.22 22:55, sam.z.e...@gmail.com пише: ``` with open('/dev/tty', 'r+') as file: name = input('Name: ', infile=file, outfile=file) print(name) ``` How does it differ from just: ``` file.write('Name: ') name = file.readline() ``` ?

[Python-ideas] Re: int.to_base, int.from_base

02.05.22 08:03, Chris Angelico пише: Let's not go as far as a PEP yet, and figure out a couple of things: A PEP is necessary if we add Roman numerals and Cyrillic numerals, and Babylonian cuneiform numerals to the heap. ___ Python-ideas mailing

[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean

30.03.22 14:05, Adrian Torres Justo пише: We've used a lot of boolean environment variables in a recent project I've been working on, this led us to create a wrapper to os.getenv that essentially converts the result to a boolean using distutils.util.strtobool if an optional kwarg to our

[Python-ideas] Re: A string function idea

28.03.22 15:13, StrikerOmega пише: And I want to grab some kind of value from it. There is a powerful tool designed for solving such problems. Is is called regular expressions. sample.grab(start="fruit:", end="\n") >> 'apple' re.search(r'fruit:(.*?)\n', sample)[1]

[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary

14.03.22 15:07, Joao S. O. Bueno пише: - but what about keeping what exists and adding {,}  for an empty set? (it is not that unlike the one-element tuple, which already exists) If you want to create an empty set without using any identifier, use {*()}. The advantage is that it works in old

[Python-ideas] Re: Creating ranges with ellipsis

16.02.22 14:44, Soni L. пише: > This might be a silly idea but, would it be a good idea to have > ...[a:b:c] return a range(a, b, c)? See PEP 204. https://www.python.org/dev/peps/pep-0204/ ___ Python-ideas mailing list -- python-ideas@python.org To

[Python-ideas] Re: Missing expandvars equivalent in pathlib

10.02.22 12:59, anthony.flury via Python-ideas пише: > I know that /os.path/ includes a function /expandvars(..)/ which expands > any environment variables in a given path, but from looking at the > /pathlib/ documentation It seems there is > no equivalent to /os.path.expandvars(..) on any class/

[Python-ideas] Re: staticmethod vs classmethod [was: Add a decorators called @staticproperty]

19.12.21 19:41, Ethan Furman пише: > On 12/19/21 5:40 AM, Serhiy Storchaka wrote: > >> classmethod supersedes staticmethod. It was not clearly known when they >> were introduced, but now we see that there is very few use cases for >> staticmethod which cannot be replaced

[Python-ideas] Re: Add a decorators called @staticproperty

18.12.21 13:18, m...@chenjt.com пише: > It might be a good idea to use "@staticproperty" to solve this problem. > "@staticproperty" is a decorators, it mix the @staticmethod and @property. > Then the static property has getter and setter. classmethod supersedes staticmethod. It was not clearly

[Python-ideas] Re: Context managers in expressions

25.10.21 21:26, jcg.stu...@gmail.com пише: > I've been thinking for a while that it would be good to be able to use > context managers in an expression context, and I haven't been able to come up > with any arguments against it (although it may not be to everyone's taste) > and I can't see any

[Python-ideas] Re: Return False from __contains__ method if object not hashable for set and dict.

25.10.21 18:49, Kazantcev Andrey пише: > Now if do something like `[] in set()` python raise an exception, but if an > object isn't hashable then we know for sure that it isn't in the set. Propose > return False for these cases. What do you think? What was changed since this topic was discussed

[Python-ideas] Re: def variable = value

24.10.21 15:20, Stephen J. Turnbull пише: > What do you mean by "constructor" here? Normally that word refers to > methods that populate the attributes of instances (in Python, __init__ > and__new__). But functions and methods don't have such, so you must > mean something else? They have. Both

[Python-ideas] Re: Syntax for late-bound arguments

23.10.21 19:07, Chris Angelico пише: > _missing = object() > def spaminate(thing, count=_missing): > if count is _missing: count = thing.getdefault() > > Proposal: Proper syntax and support for late-bound argument defaults. > > def spaminate(thing, count=:thing.getdefault()): > ... Few

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

17.10.21 16:08, Eric V. Smith пише: > Serhiy: could you explain the difference? The difference between `for x in it: yield x` and `yield from it` is than in the latter case any values passed in with send() and any exceptions passed in with throw() are passed to the underlying iterator if it has

[Python-ideas] Re: Accessing target name at runtime

08.10.21 22:23, Jeremiah Paige пише: Point = namedtuple(<<<, 'x, y, z') Point > > > UUIDType = NewType(<<<, str) UUIDType > __main__.UUIDType In many cases similar to namedtuple and NewType this is not enough. You need to pass to the constructor not only name, but module

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

16.10.21 17:07, Erik Demaine пише: > (*it for it in its)  # tuple with the concatenation of iterables in 'its' As others already have said, it should evaluate to a generator, not to a tuple. But other question is occurred now. Should it be equivalent to def gen(its): for it in its:

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

16.10.21 17:07, Erik Demaine пише: > Extended unpacking notation (* and **) from PEP 448 gives us great ways > to concatenate a few iterables or dicts: > > ``` > (*it1, *it2, *it3)  # tuple with the concatenation of three iterables > [*it1, *it2, *it3]  # list with the concatenation of three

[Python-ideas] Re: Implementing additional string operators

13.10.21 22:03, Marc-Andre Lemburg пише: > Some examples: > - removal of file extensions > - removal of end tags > - removal of units > - removal of currencies > - removal of standard suffixes > - removal of wildcard patterns > etc. > > I find lots of such uses in the code bases I work with. I

[Python-ideas] Re: Implementing additional string operators

13.10.21 22:53, Peter Ludemann пише: > [*] Floating point x+y isn't always y+x, but floating point is its own > problematic world. AFAIK floating point x+y is always y+x, but (x+y)+z is not always x+(y+z). ___ Python-ideas mailing list --

[Python-ideas] Re: Implementing string unary operators

13.10.21 03:10, Jelle Zijlstra пише: > To get a new operator on a builtin type, you'll have to show that: > - It's a common operation; > - There's no convenient way to do it already; and > - The meaning of the operator is reasonably clear to a reader of the code. > > Recent examples of new

[Python-ideas] Re: Implementing string unary operators

13.10.21 03:05, MarylandBall Productions пише: > I would think `~string` could be good for a shorthand way to convert a string > to an integer, considering you’re “inverting” the string to another type, > though a downside to this would be that explicit is always better than > implicit and

[Python-ideas] Re: Invalidate list iterators after size changes?

09.10.21 01:24, Tyler Hou via Python-ideas пише: > Concretely, I'm proposing the following set of changes to Python: > > 1. If the size of a list, set, or dict changes, invalidate all existing > iterators to that containers. Document this behavior as part of the public > API. > 2. Attempting to

[Python-ideas] Re: Reusing more builtins for type-hinting

02.10.21 17:10, Todd пише: > Is there a reason we can't use "Object" and make "Any" just an alias for > "Object"? If you mean "object", then the reason is that "object" has no methods and attributes (besides few dunder methods like __repr__ and __reduce__), while "Any" has all methods and

[Python-ideas] Re: pathlib update idea: iterable Path that returns subpaths

02.10.21 15:44, Paul Moore пише: > The counter-argument is "there should be one obvious way" - we > definitely don't only have *one* way, at the moment, but none of them > are "obvious". My big problem is that I don't think that making Path > instances iterable is "obvious", either. What if the

[Python-ideas] Re: Reusing more builtins for type-hinting

01.10.21 15:01, Matt del Valle пише: > `any` (for use  instead of `typing.Any`) > `callable` (for use instead of `typing.Callable`) The problem is than any() and callable() are not types, but functions, whose names are accidentally similar to names of some typing types. If the name of callable()

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

01.10.21 22:35, Jonathan Crall пише: > My motivation for writing this suggestion is in an attempt to stop a > common anti-pattern, where instead of defining a `main` function (or a > function by any other name) an simply calling that by adding the above > two lines, a lot of Python users I work

[Python-ideas] Re: PEP Draft: Power Assertion

25.09.21 17:46, Guido van Rossum пише: > - I was envisioning something that provides an API that would allow a > test framework to do what pytest does; not a behavior chance to the > assert statement by default. > > - Please, please collaborate with the pytest developers on the design. +++

[Python-ideas] Re: A better math.factorial

17.09.21 05:23, Steven D'Aprano пише: factorial(23) == better_factorial(23) > False > > The problem is that since floats only have about 17 significant figures > or so, once you get to 23! the gamma function doesn't have enough > precision to give an exact answer. Of course that's easily

[Python-ideas] Re: os.workdir() context manager

14.09.21 22:43, Marc-Andre Lemburg пише: > Would there be interest in adding something like this to the os module > as os.workdir() ? There is already an open issue and PR for this: https://bugs.python.org/issue25625 https://github.com/python/cpython/pull/28271 My main concern is that it is not

[Python-ideas] Re: Power Assertions: Is it PEP-able?

12.09.21 21:36, Chris Angelico пише: > I wonder, could this be simplified a bit, on the assumption that a > well-written assertion shouldn't have a problem with being executed > twice? Instead of keeping all the subexpressions around (a run-time > cost), keep the AST of the expression itself (a

[Python-ideas] Re: Power Assertions: Is it PEP-able?

12.09.21 21:20, Guido van Rossum пише: > Maybe you all could collaborate on a PEP? This sounds a worthy topic. I can write an implementation if we decide on the interface. I am currently have higher priorities of other tasks than to make a research on this feature.

[Python-ideas] Re: Power Assertions: Is it PEP-able?

12.09.21 17:28, Guido van Rossum пише: > This is cool. > > AFAIK pytest does something like this. How does your implementation differ? What pytest does is awesome. I though about implementing it in the standard compiler since seen it the first time. > What is your argument for making this part

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

03.09.21 10:34, Thomas Grainger пише: > I think that it would be good to make TypeError more fine-grained. > Another example is: > sum(1, 2, 3) > Traceback (most recent call last): > File "", line 1, in > TypeError: sum() takes at most 2 arguments (3 given) I agree that TypeErrors raised

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

03.09.21 10:34, Thomas Grainger пише: > what's the reason for this not to raise AttributeError? At least backward compatibility. Currently a TypeError is raised in such cases, and AttributeError is not a subtype of TypeError. Also, not always any attribute is involved. For example, float()

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

12.09.21 07:48, Ram Krishna пише: > I guess having subclass for implementation errors to distinguish will be very > helpful, Typeerror has become very generic and finding solution is like > searching a needle in haystack for the new developers. > > Eg- TypeError: ‘int’ object is not iterable >

[Python-ideas] Re: classmethod __eq__ comparisons and Any wildcards

09.09.21 17:19, Randolf Scholz пише: > As a sidenote, I think it would actually be kinda cool to have the > `typing.Any` behave this way, i.e. always comparing to True. > One example where this would be useful is that it would allow comparisons like > > ```python > assert mytuple == (Any, "abc")

[Python-ideas] Re: Add @parametrize decorator to unittest library

07.09.21 05:31, Leonardo Freua пише: > When writing some unit tests with the standard Unittest library, I missed > being able to create parameterized tests. This functionality exists in PyTest > (https://docs.pytest.org/en/6.2.x/parametrize.html) and there is also a > library called

[Python-ideas] Re: Improve traceback for common `with` statement mistake

06.09.21 18:42, Chris Angelico пише: > On Tue, Sep 7, 2021 at 1:36 AM Finn Mason wrote: >> Thank you for testing that. I dug through the change log, and found >> bpo-12022: >> https://bugs.python.org/issue12022 >> It has been fixed in 3.11, but not mentioned in the What's New document. >>

[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

03.09.21 10:28, Thomas Grainger пише: > the way to make an (aysnc)generator that immediately raises > Stop(Async)Iteration immediately is to insert an unreachable `yield` > statement, however there's two ways to do it: I think it is too uncommon case to specify it in PEP 8.

[Python-ideas] Add a special TypeError subclass for implementation errors

There are two different kinds of TypeError: if the end user passes an instance of wrong type and if the author of the library makes an error in implementation of some protocols. For example, len(obj) raises TypeError in two cases: if obj does not have __len__ (user error) and if obj.returns

[Python-ideas] Re: NAN handling in statistics functions

26.08.21 12:05, Marc-Andre Lemburg пише: > Oh, good point. I was under the impression that NAN is handled > as a singleton. > > Perhaps this should be changed to make to make it easier to > detect NANs ?! Even ignoring a NaN payload, there are many different NaNs of different types. For example,

[Python-ideas] Re: Add explicit method overloading to STL

24.08.21 05:10, Will Bradley пише: > Don't know if this is already a PEP, but I'd love to see something > like this > >  in > Python— a decorator @overload that creates multiple copies of > functions/methods based on

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

22.08.21 16:27, Steven D'Aprano пише: > Quoting the subject line: > > "We should have an explicit concept of emptiness for collections" > > We do. It's spelled: > > len(collection) == 0 > > You can't get more explicit than that. (len(collection) == 0) is True

[Python-ideas] Re: startswith() and endswith() methods returning the matched value

09.08.21 17:05, fgalla...@gmail.com пише: > Two possibilities: > > 1) the perfectly backward compatible, retrun False > 2) the more pythonic, return the empty value of the object (i.e. "" for str) The problem is that for backward compatibility it should return True. And empty string's boolean

[Python-ideas] Re: startswith() and endswith() methods returning the matched value

09.08.21 05:05, fgalla...@gmail.com пише: > This is a proposal to change the behaviour of the startswith() and > endswith() methods for str, bytes and bytearray objects, making them > return the matched value instead of the True boolean. And what should it return for empty matched value?

[Python-ideas] Re: C API for converting Python integers to/from bytes sequences

08.08.21 11:41, Barry Scott пише: >> On 7 Aug 2021, at 19:22, Serhiy Storchaka wrote: >> 1. How to encode the byte order? >> >> a) 1 -- little endian, 0 -- big endian >> b) 0 -- little endian, 1 -- big endian >> c) -1 -- little endian, +1 -- big endian, 0 -- na

[Python-ideas] Re: C API for converting Python integers to/from bytes sequences

08.08.21 07:08, Stephen J. Turnbull пише: > Serhiy Storchaka writes: > > > Python integers have arbitrary precision. For serialization and > > interpolation with other programs and libraries we need to > > represent them [...]. [In the case of non-standard p

[Python-ideas] C API for converting Python integers to/from bytes sequences

Python integers have arbitrary precision. For serialization and interpolation with other programs and libraries we need to represent them as fixed-width integers (little- and big-endian, signed and unsigned). In Python, we can use struct, array, memoryview and ctypes use for some standard sizes

[Python-ideas] Re: `not not x` much faster than `bool(x)`

06.08.21 10:29, wyz2...@163.com пише: > Before the introduction of bool and also in other languages, `not not x` > was/is used to convert to True (1) and False (0). However, the old way is > still much faster than bool(x) or even operator.truth(x). > Test: >> py -3.10 -m timeit -s "objects = 1,

[Python-ideas] Re: writelines2?

13.07.21 14:15, sandhoners...@gmail.com пише: > My suggestion is to have either a writelines2 or a newline kwarg which does > put new lines automatically at the end of every line written The writelines method is the part of interface. Adding new parameter or new method to interface is a major

[Python-ideas] Re: builtins for running context managers

13.07.21 18:59, Thomas Grainger пише: > given that it's hard to implement this correctly I think there should be a > builtins.enter and builtins.aenter for use like this: > > > ``` > @dataclasses.dataclass > class WrapCmgr: > _cmgr: ContextManager[T] > > def __enter__(self) ->

[Python-ideas] Re: Allow modifying message of TypeError from NotImplemented

19.06.21 06:30, wyz2...@163.com пише: > Python raises TypeError when NotImplemented is returned from __add__, > __invert__ etc. and __radd__ etc. aren't available. > However, this disallows the customization of error messages. For example, in > Python 3.8, __float__ etc. were removed from

[Python-ideas] Re: Deprecate sum of lists

19.06.21 18:12, Marc-Andre Lemburg пише: >> But there could be endless debate about whether flatten( ("x", "y") ) should >> return a list or a tuple... > > Have it return an iterator :-) flatten = itertools.chain.from_iterable ___ Python-ideas mailing

[Python-ideas] Re: Deprecate sum of lists

19.06.21 07:33, Guido van Rossum пише: > [1] Does the unary star operator have a name when used like this in > Python? In JavaScript the equivalent syntax ("...chunk", where the "..." > are a literal ellipsis) is called "spread". We could borrow this term. I would not call is an operator.

[Python-ideas] Re: Deprecate sum of lists

18.06.21 18:42, Mathew Elman пише: > I don't see how allowing > > [x, y for x in a] > > follows from allowing > > [*chunk for chunk in list_of_lists]. Because in all other contexts you can replace `*(x, y)` with `x, y`. f(*(x, y)) => f(x, y) [*(x, y)] => [x, y] {*(x, y)} => {x,

[Python-ideas] Re: Deprecate sum of lists

18.06.21 17:38, Guido van Rossum пише: > Note the ambiguity around whether the user might have meant > >     [x,(y for y in a)] > > or > >     [(x, y) for y in a] Yes, I think that it could be interpreted in one of the following ways: [x, (y for y in a)] [x, *(y for y in a)]

[Python-ideas] Re: Deprecate sum of lists

18.06.21 00:22, Ben Rudiak-Gould пише: > Okay, slightly off-topic, but can we *please* allow > >     [*chunk for chunk in list_of_lists] > > some day. I think it was left out because some discussion concluded it > would be too confusing, which is ridiculous. I assumed it would work and > was

[Python-ideas] Re: Deprecate sum of lists

17.06.21 06:03, David Mertz пише: > I'm sympathetic to raising an exception on `sum(list_of_lists)` similar > to `sum(list_of_strings)`.  But what exactly is the recommended > substitute?  We have this: > > list(chain.from_iterable(list_of_lists)) > > Which is pretty nice, and what I'd probably

[Python-ideas] Re: The name Ellipsis should be a constant

31.05.21 22:24, André Roberge пише: > > > On Mon, May 31, 2021 at 4:17 PM Serhiy Storchaka > <mailto:storch...@gmail.com>> wrote: > 31.05.21 17:37, André Roberge пише: > > For consistency, `Ellipsis` (the name) should **always** refer to the > >

[Python-ideas] Re: The name Ellipsis should be a constant

31.05.21 23:28, Chris Angelico пише: > Although... since that's an arbitrary placeholder, it could be changed > to pretty much anything. Maybe <...> or something? The current repr > may not technically be ambiguous, but it will silently do the wrong > thing if you try to eval it. You can even

[Python-ideas] Re: The name Ellipsis should be a constant

31.05.21 22:59, Jelle Zijlstra пише: > Why isn't `repr(...)` just `...`? Because it would confuse with reprs for recursive collections. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: The name Ellipsis should be a constant

31.05.21 22:46, Chris Angelico пише: > Originally, the notation "..." could only be used inside a subscript, > and anywhere else, you'd have to spell it "Ellipsis". Now that you can > use "..." anywhere, would it be worth switching the repr to just be > that? How would you then distinguish a

[Python-ideas] Re: The name Ellipsis should be a constant

31.05.21 17:37, André Roberge пише: > For consistency, `Ellipsis` (the name) should **always** refer to the > same object that `...` refers to, so that both could not be assigned a > new value. Making Ellipsis a keyword will break ast.Ellipsis (and maybe some third-party libraries).

[Python-ideas] Re: New Idea: A safe keyword to execute the following statement in a failsafe mode.

23.05.21 12:42, Shivam Saini пише: >     except: >         pass Don't do this. Never write a bare except handler which does not re-raise an exception. There are few exceptions of this rule, but it is unlikely that you will see them in first years of your practice. It is an anti-pattern, and a

[Python-ideas] Re: New Idea: A safe keyword to execute the following statement in a failsafe mode.

23.05.21 16:22, Shivam Saini пише: > After all, python is known for one liners It is not Python that is known for one liners. Python syntax is rather opposed to one liners. It encourages and sometimes forces a user to write well-indented code. ___

[Python-ideas] Re: division of integers should result in fractions not floats

14.05.21 15:12, Martin Teichmann пише: > when dividing two integers, the result is a float, which means we immediately > lose precision. This is not good if you want to use code which supports > higher precision. Decimals come to mind, but also sympy. This loss of > precision could be avoided

[Python-ideas] Re: Add support for private variables, methods and functions in Python

06.05.21 15:46, Shreyan Avigyan пише: > But Python doesn't have pointers and getattr, settatr can be adjusted to work > with private members. It doesn't work this way. You cannot distinguish the use of getattr() which breaks encapsulation from the one which does not. Inside getattr() you only

[Python-ideas] Re: Add support for private variables, methods and functions in Python

05.05.21 17:18, Shreyan Avigyan пише: > I don't know if it's worth adding private to python modules but what about > classes? Private in class is an important feature in OOP that Python lacks > (Most OOP languages have private like Java, C++, etc.). I don't know why it > was introduced in the

[Python-ideas] Re: Support more conversions in format string

21.04.21 12:14, Paul Moore пише: > I don't have a particularly strong opinion here, other than to say I'm > not sure I like the upper case "I". It looks far too much like a lower > case "L" in the font I'm using here, which makes me think of C's > "long", so it's easy to confuse. So of the two

[Python-ideas] Re: Support more conversions in format string

23.04.21 12:22, Stephen J. Turnbull пише: > Serhiy Storchaka writes: > > > Currently format strings (and f-string expressions) support three > > conversions: !s -- str, !r -- repr and !a for ascii. > > It's not clear to me what these are good for, to be honest.

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

22.04.21 10:21, Stephen J. Turnbull пише: > @serhiy Moving my speculative discussion to python-ideas. CC as > courtesy, comment from you is welcome but not necessarily expected. > > Serhiy Storchaka writes: > > > format() without format specifier and str() should retur

[Python-ideas] Support more conversions in format string

Currently format strings (and f-string expressions) support three conversions: !s -- str, !r -- repr and !a for ascii. I propose to add support of additional conversions: for int, float and operator.index. It will help to convert automatically printf-like format strings to f-string expressions:

[Python-ideas] Re: Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?

15.04.21 10:03, Shreyan Avigyan пише: > After going through the > https://github.com/python/cpython/blob/master/Include/object.h it seems that > Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL. > This if statement could be directly implemented in Py_DECREF right?

[Python-ideas] Re: Revive: PEP 396 -- Module Version Numbers ?

12.04.21 21:49, Christopher Barker пише: > Over the years, I've seen __version__ used very broadly but not *quite* > in all packages. I've always known it was a convention, not a > requirement. But it turns out it's not even a "official" convention. If I have a time I finish my large patch for

[Python-ideas] Re: Python Idea - extension of 'with'

09.04.21 21:02, Guido van Rossum пише: > But if there are two proposals with conflicting semantics for the same > syntax that kills both ideas, doesn’t it? Because apparently it’s not > clear what the syntax should mean. Maybe. But there was also different idea for the "with" statement (with

[Python-ideas] Re: Adding syntax for the empty set

09.04.21 19:08, micro codery пише: > > You can now use `{*()}` as a syntax for empty set. > > I saw that in the ast module and think it's clever, mainly in a good > way. I don't think it is the same as having dedicated syntax for the > empty set partly because I think it needs to be taught.

[Python-ideas] Re: Adding syntax for the empty set

09.04.21 19:42, Ricky Teachey пише: > On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka > <mailto:storch...@gmail.com>> wrote: > You can now use `{*()}` as a syntax for empty set. > > Interestingly, Raymond Hettinger recently had a post on twitter > speci

[Python-ideas] Re: Adding syntax for the empty set

09.04.21 12:50, Matt del Valle пише: > I think sets are the only type in the builtins module > without a dedicated literal syntax? Not only. bytearray, frozenset, slice. It is difficult to create some complex objects without using constructor. Not counting range, memoryview and dict views,

[Python-ideas] Re: Python Idea - extension of 'with'

08.04.21 17:59, anthony.flury via Python-ideas пише: > I was wondering whether a worthwhile extension might be to allow the > `with` statement to have an `except` and  `else` clauses which would > have the same > semantics as wrapping the `with` block with a try - for example the > above would now

[Python-ideas] Re: Adding syntax for the empty set

08.04.21 19:58, ucod...@gmail.com пише: > I would like to propose adding literal syntax to allow creation of an empty > set without the need to call the type constructor. I believe the best choice > for such a literal, and one that has been proposed before, is `{,}`. You can now use `{*()}` as

[Python-ideas] Re: Suggesting feature for python - Big Set, Big Dictionary

23.03.21 07:55, Vijay Patel пише: > Suggestion: > 1. Big Set, Big Dictionary - > During design time, i am considering this question. With limited RAM > (example 4 GB), how can I store a dictionary/set of size greater than RAM. > > Is it possible to introduce Big Set / Big Dictionary which stores

[Python-ideas] Re: shouldn't slices be iterable ?

19.03.21 01:44, Cameron Simpson пише: > I know that range(start,end,stride) will produce what I'd want from > iter(slice(start,end,stride)), but wouldn't it be reasonable for a slice > itself to be iterable? > > Yes, only one obvious way and all that, but inside eg __getitem__ it > seems to me

[Python-ideas] Re: Enum: determining if a value is valid

12.03.21 23:48, Ethan Furman пише: > A question that comes up quite a bit on Stackoverflow is how to test to > see if a value will result in an Enum member, preferably without having > to go through the whole try/except machinery. > > A couple versions ago one could use a containment check: > >  

[Python-ideas] Re: Make list.reverse() more flexible

06.03.21 09:52, Vincent Cheong пише: > I see. I do agree that my reply brings about that 'verbose repeated' feeling, > haha. But for the record, it's not about having something in hand now for the > future, but it's more of a paradigmatic approach to the implementation. > Python has changed for

[Python-ideas] Re: Alternate lambda syntax

11.02.21 13:24, J. Pic пише: > Lambdas can be defined as such: > > w = lambda: [12] > x = lambda y: len(y) > > I'd like to propose the following: > > w = (): [12] > x = (y): len(y) This syntax is ambiguous. if (y): len(y): What does the first colon mean? You cannot say until you read the

[Python-ideas] Re: Additional LRU cache introspection facilities

12.01.21 21:28, Sebastian Kreft пише: > class ForcePythonLruCache(importlib.abc.MetaPathFinder): >     def find_spec(self, fullname, path, target=None): >         if fullname == '_functools': >             raise ImportError('_functools not available') You can just set sys.modules['_functools'] =

[Python-ideas] Re: Additional LRU cache introspection facilities

12.01.21 18:57, Steven D'Aprano пише: > Can you explain further why the cached function needs additional > syncronisation overhead? The cache uses a double-linked list to track what item is the oldest and changes it every time you call the cached function (move the found or new item to the

[Python-ideas] Re: Additional LRU cache introspection facilities

12.01.21 12:02, Steven D'Aprano пише: > Is anyone else interested in additional introspection facilities for the > functools.lru_cache? > > You can view the cache hit and miss statistics using the cache_info() > method, but you can't see what values actually are in the cache. That > would be

[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.

06.01.21 06:07, Mikhail V пише: > I know there is the "pathlib" module with all conversion methods, but > it's overkill for many > tasks. So I'd rather like to have an option to write for example: > > path = os.path.join (root, dir, sep = "posix") > > So that it joins with the forward slash

[Python-ideas] Re: Option to not raise if file does not exists for os.remove()?

29.12.20 22:58, Marco Sulla пише: > What about a parameter, false by default, that suppresses the > FileNotFoundError exception if true for os.remove()? Something similar > to exist_ok for os.makedirs(). You have two options (and it's too much in my opinion): try: os.remove(filename)

[Python-ideas] Re: Unpack operator "**" and Mapping

26.12.20 13:23, Anton Abrosimov пише: > I am trying to release comfortable dataclass unpacking using `**` operator. > Now I have 5 different ways to do it. > But not a single good one. Confused by the implementation of the unpacking > operator. > > So when I try to unpack any custom class, I

[Python-ideas] Re: Standalone bool?

22.12.20 03:18, David Mertz пише: > Indeed.  The discussion around this was quite specifically that many > people defined: > > True = 1 > False = 0 > > At the top of their code, and used that.  This was the main reason they > were built-ins rather than keywords, so as not to break that large

[Python-ideas] Re: Standalone bool?

21.12.20 10:11, Paul Bryan пише: > Wouldn't that still work if bool's __int__ returns 1? Implementing `__index__` would solve 90% of all problems with non-int booleans. But not the example provided by David (it requires `__add__`). And there may be more specific cases when you need to make

[Python-ideas] Re: Standalone bool?

21.12.20 10:09, David Mertz пише: > I sure hope this never happens! It would break millions of working lines > and kill a common useful pattern. > > ntrue = sum(this == that for this, that in items) It is too, but the main reason is that the C code parses boolean parameters as integers (using

  1   2   3   4   5   6   >