Re: [Python-ideas] Suggestion: Extend integers to include iNaN

29.09.18 09:31, Steve Barnes пише: I think that it should be relatively simple to extend the Python integer class to have a NaN flag, possibly by having a bit length of 0, and have it follow the same rules for the handling of floating point NaN, i.e. any mathematical operation on an iNaN returns

Re: [Python-ideas] Make the @contextmanager of contextlib to be a real contextmanager

05.01.19 14:52, Moon丶sun пише: As we know,when we import the module--'contextlib',we can use the decorator '@contextmanager' and keyword ‘yield’ to make a 'instance' of Class '_GeneratorContextManager' in 'contextlib' module,then we can use it like: with 'instance' as 'xx':     'code block'

Re: [Python-ideas] Unified style of cache management API

27.03.19 15:46, Ma Lin пише: re module [1] and struct module [2] have module-level cache for compiled stuffs. Other third-party modules may also need cache for something. Do we need an unified cache management API like this? I suppose it's not mandatory, but welcome each module to use this

Re: [Python-ideas] PEP: Dict addition and subtraction

21.03.19 14:51, Chris Angelico пише: ... then, in the interests of productive discussion, could you please explain? What is it about dict addition that makes it harder to understand than other addition? Currently the + operator has 2 meanings for builtin types (both are widely used), after

Re: [Python-ideas] Add output() helper function to subprocess module

04.04.19 11:59, Greg Ewing пише: Nathaniel Smith wrote: On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing wrote: output(args) --> (status, output) Isn't this already available as: run(args, stdout=PIPE)? Yes, but you need to do more than that to get the output as a string. This is the relevant

Re: [Python-ideas] Unified style of cache management API

29.03.19 20:52, Brett Cannon пише: On Thu, Mar 28, 2019 at 10:53 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: 28.03.19 19:45, Brett Cannon пише: > So I would say that a cache-clearing function convention would be a > reasonable starting point. If

Re: [Python-ideas] Unified style of cache management API

28.03.19 19:45, Brett Cannon пише: So I would say that a cache-clearing function convention would be a reasonable starting point. If that turns out to not be enough for folks we can talk about expanding it, but I think we should start small and grow from there as needed. So what name would

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

23.03.19 18:24, Christopher Barker пише: I wonder how often + is used with lists in the stdlib... Searching for "+ [" shows that even concatenating with the string display and comprehensions is several times more common that merging dicts. And there should be cases not covered by this simple

Re: [Python-ideas] Dict joining using + and +=

01.03.19 21:31, Guido van Rossum пише: On Thu, Feb 28, 2019 at 10:30 PM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: And this opens a non-easy problem: how to create a mapping of the same type? Not all mappings, and even not all dict subclasses have a copying co

Re: [Python-ideas] Dict joining using + and +=

01.03.19 12:44, Steven D'Aprano пише: On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote: Currently Counter += dict works and Counter + dict is an error. With this change Counter + dict will return a value, but it will be different from the result of the += operator. That's how

Re: [Python-ideas] Dict joining using + and +=

04.03.19 21:24, Guido van Rossum пише: * Dicts are not like sets because the ordering operators (<, <=, >, >=) are not defined on dicts, but they implement subset comparisons for sets. I think this is another argument pleading against | as the operator to combine two dicts. Well, I suppose

Re: [Python-ideas] Dict joining using + and +=

04.03.19 15:29, Serhiy Storchaka пише: Using "|" looks more natural to me than using "+". We should look at discussions for using the "|" operator for sets, if the alternative of using "+" was considered, I think the same arguments for preferring &

Re: [Python-ideas] Dict joining using + and +=

28.02.19 23:19, Greg Ewing пише: Serhiy Storchaka wrote: I do not understand why we discuss a new syntax for dict merging if we already have a syntax for dict merging: {**d1, **d2} (which works with *all* mappings). But that always returns a dict. A '+' operator could be implemented by other

Re: [Python-ideas] Dict joining using + and +=

01.03.19 06:21, Guido van Rossum пише: On Wed, Feb 27, 2019 at 11:18 PM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: Counter uses + for a *different* behavior!  >>> Counter(a=2) + Counter(a=3) Counter({'a': 5}) Well, you can see this as a special

Re: [Python-ideas] Dict joining using + and +=

27.02.19 20:48, Guido van Rossum пише: On Wed, Feb 27, 2019 at 10:42 AM Michael Selik > wrote > The dict subclass collections.Counter overrides the update method for adding values instead of overwriting values.

[Python-ideas] Not all operators are useful (was Why operators are useful)

15.03.19 19:51, Guido van Rossum пише: There's been a lot of discussion about an operator to merge two dicts. I participated in the beginning but quickly felt overwhelmed by the endless repetition, so I muted most of the threads. But I have been thinking about the reason (some) people like

Re: [Python-ideas] Preallocated tuples and dicts for function calls

09.03.19 03:02, Greg Ewing пише: Martin Bammer wrote: what about the idea that the interpreter preallocates and preinitializes the tuples and dicts for function calls where possible when loading a module? This would not be thread-safe. Locking would be needed around uses of the preallocated

Re: [Python-ideas] Preallocated tuples and dicts for function calls

08.03.19 23:16, Martin Bammer пише: what about the idea that the interpreter preallocates and preinitializes the tuples and dicts for function calls where possible when loading a module? Before calling a function then the interpreter would just need to update the items which are dynamic and

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

06.03.19 22:12, Matěj Cepl пише: I am a lead maintainer of Python packages in OpenSUSE and I can see the pattern of many packagers adding blindly python setup.py test to %check section of our SPEC file. The problem is that if the package doesn't use unittest (it actually uses nose, pytest

Re: [Python-ideas] True and False are singletons

18.03.19 22:52, Wes Turner пише: >>> True = 1   File "", line 1 SyntaxError: can't assign to keyword The error message will be changed in 3.8. >>> True = 1 File "", line 1 SyntaxError: cannot assign to True ___ Python-ideas mailing list

Re: [Python-ideas] True and False are singletons

18.03.19 22:58, Greg Ewing пише: Oleg Broytman wrote:    Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True. In that case the conventional way to write it would be     if settings[MY_KEY] == True:     ... It's not a

Re: [Python-ideas] PEP: Dict addition and subtraction

21.03.19 15:24, Chris Angelico пише: On Fri, Mar 22, 2019 at 12:17 AM Serhiy Storchaka wrote: 21.03.19 14:51, Chris Angelico пише: ... then, in the interests of productive discussion, could you please explain? What is it about dict addition that makes it harder to understand than other

Re: [Python-ideas] Dict joining using + and +=

04.03.19 15:43, Serhiy Storchaka пише: 01.03.19 12:44, Steven D'Aprano пише: On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote: Also, if the custom dict subclass implemented the plus operator with different semantic which supports the addition with a dict, this change will break

Re: [Python-ideas] Starap function exists but it seems there's not such thing as "doublestarmap"

10.04.19 12:55, Krokosh Nikita пише: I need smth like starstarmap('{a} / {b}/ {c}'.format, [{a:1, b:2, c:3}, {a:4, b:5, c:6}, ...]) Use the format_map method of str. >>> list(map('{a} / {b}/ {c}'.format_map, [{'a':1, 'b':2, 'c':3}, {'a':4, 'b':5, 'c':6}])) ['1 / 2/ 3', '4 / 5/ 6']

Re: [Python-ideas] Implement POSIX ln via shutil.link and shutil.symlink

30.05.19 00:22, Barry пише: Serhiy, I think, is conflating two things. 1. How to write software robust aginst attack. 2. How to replace a symlink atomically. Why do you need to replace a symlink atomically? This is a solution, what problem it solves?

[Python-ideas] Re: Implement POSIX ln via shutil.link and shutil.symlink

04.06.19 10:25, Inada Naoki пише: On Sat, Jun 1, 2019 at 4:10 PM Serhiy Storchaka wrote: Why do you need to replace a symlink atomically? This is a solution, what problem it solves? There is another, more common / realistic usage of atomic symlink replacing. When deploy PHP application

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

13.05.19 12:38, Tom Hale пише: As suggested by Toshio Kuratomi at https://bugs.python.org/issue36656, I am raising this here for inclusion in the shutil module. Mimicking POSIX, os.symlink() will raise FileExistsError if the link name to be created already exists. A common use case is

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

16.05.19 14:33, Antoine Pitrou пише: On Thu, 16 May 2019 13:05:48 +0300 Serhiy Storchaka wrote: 16.05.19 11:28, Barry Scott пише: To replace one symlink with another atomically is possible by using rename() or renameat() something like: os.symlink( src, tmp_symlink

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

16.05.19 11:28, Barry Scott пише: To replace one symlink with another atomically is possible by using rename() or renameat() something like: os.symlink( src, tmp_symlink ) os.rename( tmp_symlink, dst ) Somebody can replace tmp_symlink between os.symlink() and os.rename().

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

14.05.19 19:50, Steven D'Aprano пише: On Tue, May 14, 2019 at 02:43:03PM +0300, Serhiy Storchaka wrote: Sorry, but I do not understand what problem do you try to solve. If somebody can create a file named link_name between unlink and symlink, he can also remove and create a file named link_name

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

16.05.19 08:46, Anders Hovmöller пише: In the general case because of features that until / was introduced was unique to functions defined in C. But in the case of the dict constructor that's just a weird misfeature. If it did in fact take *args and handled it it would be perfectly fine and

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

16.05.19 17:05, Antoine Pitrou пише: On Thu, 16 May 2019 16:04:36 +0300 Serhiy Storchaka wrote: 16.05.19 14:33, Antoine Pitrou пише: On Thu, 16 May 2019 13:05:48 +0300 Serhiy Storchaka wrote: 16.05.19 11:28, Barry Scott пише: To replace one symlink with another atomically is possible

[Python-ideas] Custom converters in str.format() and f-strings

Currently str.format() and f-strings support three converters. Converting is specified by the "!" character followed by a letter which denotes the converter. s: str() r: repr() a: ascii() In some cases it would be useful to apply other converters. One obvious example is escaping special

[Python-ideas] More alternate constructors for builtin type

Constructors for builtin types is too overloaded. For example, int constructor: * Converts a number (with truncation) to an integer. * Parses human readable representation of integer from string or bytes-like object. Optional base can be specified. Note that there is an alternate constructor

Re: [Python-ideas] More alternate constructors for builtin type

06.05.19 17:49, Guido van Rossum пише: 20-25 years ago this might have been a good idea. Unfortunately there's so much code (including well-publicized example code) that I'm not sure it's a good use of anyone's time to try and fix this. I do not propose to change the current behavior. I

[Python-ideas] Re: Make tuple a context manager

13.07.19 23:25, Kyle Stanley пише: Serhiy Storchaka wrote: Are your aware of contextlib.nested()? And why it was deprecated and removed? Was contextlib.nested() removed primarily due to to the inconsistencies mentioned in https://bugs.python.org/issue5251 or was it something else? Yes

[Python-ideas] Re: Non-standard evaluation for Python

14.07.19 07:06, Andrew Barnert via Python-ideas пише: (Re-sending, because this was originally a reply to an off-list message by Nima Hamidi) On Jul 13, 2019, at 14:12, Nima Hamidi > wrote: Sometimes it's necessary not to evaluate the expression. Two such

[Python-ideas] Re: Non-standard evaluation for Python

14.07.19 23:20, Nima Hamidi пише: Thank you for your question! It would depend on the implementation of DataFrame.__getitem__. Note that BoundExpression is endowed with locals and globals of the callee. So, it does have access to x in your example. I think the way that data.table in R handles

[Python-ideas] Re: Custom string prefixes

27.08.19 06:38, Andrew Barnert via Python-ideas пише: * JSON (register the stdlib or simplejson or ujson), What if the JSON suffix for? JSON is virtually a subset of Python except that that it uses true, false and null instead of True, False and None. If you set these three variables you

[Python-ideas] Re: Skip modules by default in star-import

26.07.19 20:43, Serhiy Storchaka пише: I propose to change the rule for determining the set of public names if `__all__` is not defined. In addition to underscored names I propose to exclude names of modules. Opened an issue and a PR: https://bugs.python.org/issue38215 https://github.com

[Python-ideas] Add a slot for "keys" in tp_as_mapping

Most C API uses type slots instead looking up in the type's dictionary for methods. But there are few methods used in basic operations which do not have corresponding slots. For example "keys", "__trunc__" and "__length_hint__". In particularly, "keys" is checked in dict.__init__() and

[Python-ideas] Re: for ... except, with ... except

26.07.19 23:46, MRAB пише: On 2019-07-26 19:26, Serhiy Storchaka wrote: [snip] I propose to add "except" clause to "for" and "with" statement to catch exceptions in the code that can't be wrapped with "try ... except".   for VAR in EXPR:   B

[Python-ideas] Re: for ... except, with ... except

26.07.19 23:57, Guido van Rossum пише: These are interesting ideas. It looks like you intend the except clause of the for loop to *only* cover the iter() and next() calls that are implicit in the for loop. You're right that it's awkward to catch exceptions there. Right. If you want to catch

[Python-ideas] Re: Skip modules by default in star-import

26.07.19 23:53, Guido van Rossum пише: Serhiy proposed a relatively minor change to the behavior of `import *` in the absence of __all__. This sounds like an idea we could try though we should have a look at the implications for various well-known packages. It is also a relatively minor

[Python-ideas] Re: for ... except, with ... except

26.07.19 21:52, Bruce Leban пише: On Fri, Jul 26, 2019 at 11:27 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: So you will be able to add errors handling like in:      with connect() as stream:          for data in stream:        

[Python-ideas] Re: PEP's shouldn't require a sponsor

25.07.19 15:14, Batuhan Taskaya пише: Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering

[Python-ideas] Skip modules by default in star-import

From the description of the import statement in the language reference [1]: The *public names* defined by a module are determined by checking the module's namespace for a variable named ``__all__``; if defined, it must be a sequence of strings which are names defined or imported by that module.

[Python-ideas] for ... except, with ... except

Python allows you to write code in tight and readable form. Consider the following example. with connect() as stream: # connect() or __enter__() can fail. for data in stream: # __next__() can fail write(data) # write() can fail The problem is that different lines can

[Python-ideas] Re: Skip modules by default in star-import

26.07.19 21:10, Anders Hovmöller пише: This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. I do not think that this is always a problem. It is common to refactor the code by defining names in

[Python-ideas] Re: Error handling toggle / levels

26.09.19 12:07, salemalbr...@gmail.com пише: So when coding, at deferent stages we need different levels of error handling. For example at stage of finding the concept, initial implementation, alpha, releasing testing, etc. By some bits of code we can simulate enable/disable error handling.

[Python-ideas] Re: Add __slots__ to dataclasses to use less than half as much RAM

27.09.19 19:48, Andrew Barnert via Python-ideas пише: On Friday, September 27, 2019, 07:47:41 AM PDT, Johnny Dahlberg wrote: > My proposal: Implement `@dataclass(slots=True)` which does the same thing as attrs: Replaces the class with a modified class that has a `__slots__` property

[Python-ideas] Re: Suggestion for behaviour change import mechanics

30.10.19 00:41, Steven D'Aprano пише: Think about the behaviour of ``from module import name`` in pure Python. Currently, it is straightforward to explain: try to import module, or fail if it doesn't exist; name = module.name, or fail if the name doesn't exist. Things are more

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

03.11.19 12:31, Anders Hovmöller пише: On 3 Nov 2019, at 10:28, Steven D'Aprano wrote: Given: values = ["Hello", b"World"] would you expect ' '.join(values) to return "Hello b'World'" because that's what you'll get calling str automatically. Side note! That misfeature of python 3

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

15.11.19 12:40, Jonathan Fine пише: The original poster wanted, inside 'with' context management, to open several files. Context management is, roughly speaking, deferred execution wrapped in a try ... except statement. In case of open() there is no deferred execution. The resource is

[Python-ideas] Re: Tuple Comprehension

18.11.19 04:39, Daniel Zeng пише: Syntax for tuple comprehension, something like: (i, for i in range(10)) (**(i for i in range(10))) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

03.12.19 21:04, Andrew Barnert via Python-ideas пише: On Dec 3, 2019, at 02:00, Serhiy Storchaka wrote: What it will return if implement | for dicts? It should be mentioned in the PEP. It should be tested with a preliminary implementation what behavior is possible and more natural. What

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 03:46, Oscar Benjamin пише: result = next(re.finditer(...), None) if result is None: # raise or something else: # use result `next(re.finditer(...), None)` is a weird way of writing `re.search(...)`. `next(re.finditer(...), defaults)` is the same as `re.search(...) or

[Python-ideas] Re: Suggestion for language addition

03.12.19 02:02, Jan Bakuwel пише: Idea: To include optional "end if", "end while", "end for" and "end name>", "end " in the language. The Python interpreter would test that any "end" matches with the correct corresponding statements and have the correct indentation, in other words throw an

[Python-ideas] Re: Sets for easy interning(?)

03.12.19 02:25, Soni L. пише: This is an odd request but it'd be nice if, given a set s = {"foo"}, s["foo"] returned the "foo" object that is actually in the set, or KeyError if the object is not present. Even use-cases where you have different objects whose differences are ignored for

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

I general, I am against this proposition. It makes the language more complex without adding any benefit. There are already many ways of merging dicts, including the expression form. It conflicts with Counter. It can make the code more errorprone because + or | for dicts will no longer fail

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

03.12.19 07:04, Guido van Rossum пише: Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this wouldn't be fun either. To me this is monkeypatching without an explicit need for it, i.e. if you

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 20:01, Guido van Rossum пише: On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: [Guido]  > I think I am +1 on  > adding re.findfirst() as proposed by the OP. It is not clear what it should return. A Match o

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:24, Guido van Rossum пише: Your example uses sets -- did you mean {3: 4} instead of {3}? Sorry. Yes, I meant {3: 4}. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 18:05, Guido van Rossum пише: On Wed, Dec 4, 2019 at 12:34 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: `next(re.finditer(...), None)` is a weird way of writing `re.search(...)`. `next(re.finditer(...), defaults)` is the same as `re.search(...) or

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:18, Guido van Rossum пише: On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: And the same question for |. Should `{} | Mapping()` and `{} | []` work? Ditto -- {} | Mapping() should work, but {} | [] should not. set() | Set() f

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

04.12.19 18:39, Random832 пише: On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: 03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this wouldn't

[Python-ideas] Re: Fwd: re.findfirst()

03.12.19 13:53, Juancarlo Añez пише: There are many ugly recipes about to handle the common use case that could be handled by: def findfirst(regex, text, default=None, flags=0):      return next(finditer(regex, text, flags=flags), default=default) Oh, this is the most strange use

[Python-ideas] Re: Suggestion for language addition

05.12.19 04:43, Andrew Barnert via Python-ideas пише: Yes, you have to unlearn it. Exceptions are not that expensive in Python (and in a lot of other modern languages)—but even if they were, you’d still have to deal with the fact that Python uses them pervasively. Every for loop ends with an

[Python-ideas] Re: Fwd: re.findfirst()

On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez > wrote: The OP thinks that the case for wanting just the string for a first regex match, or a verifiable default if there is no match, is way too common, that the advice on the web is not very good (it

[Python-ideas] Re: Argumenting in favor of first()

09.12.19 07:41, Guido van Rossum пише: Nobody is going to write a blog post about 2-arg next() (there just isn't enough for more than a sentence or two) but people write tutorials about itertools all the time, since it's such a rich module. So I think it's likely that first() will get some

[Python-ideas] Re: Argumenting in favor of first()

11.12.19 10:45, Steven D'Aprano пише: The thing is, we're fooled by the close similarity of iteration over iterators and other iterables (sequences and containers). Destructive iteration and non-destructive iteration is a big difference. Utility functions like the proposed `first` that try to

[Python-ideas] Re: Argumenting in favor of first()

12.12.19 03:22, Stephen J. Turnbull пише: I would prefer that it not be implemented at all, but if it is implemented, its behavior should respect the intuition of the majority of those who want it, which seems to me to be "a variant of next() that doesn't raise and returns None by default on an

[Python-ideas] Re: Add "elif" to "for_stmt" and "while_stmt"

14.12.19 23:37, komissar.off.and...@gmail.com пише: Hello! I think it will be useful in Python syntax if we can use "elif" in "for" and "while" statements besides "else" Example for i in range(j): ... elif i > 5: ... else: ... What you think about this change? I sometimes

[Python-ideas] Re: Argumenting in favor of first()

13.12.19 12:45, Steven D'Aprano пише: On Fri, Dec 13, 2019 at 09:24:20AM +0200, Serhiy Storchaka wrote: 12.12.19 03:22, Stephen J. Turnbull пише: I would prefer that it not be implemented at all, but if it is implemented, its behavior should respect the intuition of the majority of those who

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

05.12.19 21:07, Guido van Rossum пише: The case for findfirst() becomes stronger! There seem plenty of ways to get this wrong. I write several functions every day. There are many ways to get this wrong. But I do not propose to include all these functions in the stdlib. If I want to include

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

05.12.19 23:47, Kyle Stanley пише: Serhiy Storchaka wrote: > We still do not know a use case for findfirst. If the OP would show his > code and several examples in others code this could be an argument for > usefulness of this feature. I'm not sure about the OP's exact use case,

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

06.12.19 04:31, Guido van Rossum пише: (There are apparently subtle differences between re.search() and re.findall() -- not sure if they matter in this case.) There is no any differences. Also, analyzing examples from GitHub, in most cases the pattern contains no or single group, so the code

[Python-ideas] Re: Argumenting in favor of first()

06.12.19 00:09, Ethan Furman пише: I haven't followed the main thread, but I can unequivocally state that for-loop version is easier to read. I completely agree.   The only thing missing to make the intent crystal clear is one more word in the function name:     def

[Python-ideas] Re: Argumenting in favor of first()

06.12.19 07:38, Steven D'Aprano пише: I'm sorry, I can't tell what that is supposed to do. Is the "return {}" supposed to be inside the loop? If so, it has been accidentally dedented. Is it meant to be outside the loop? The "for-else" is redundent, since there is no break. for item in

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

06.12.19 19:49, Random832 пише: If match objects are too hard to use, maybe they should be made more user-friendly? What about adding str and iterable semantics to match objects so it can be used as str(re.search(...)); tuple(re.search(...)); a, b = re.search(...)? What is semantic of these

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

06.12.19 23:20, Kyle Stanley пише: Serhiy Storchaka wrote: > It seems that in most cases the author just do not know about > re.search(). Adding re.findfirst() will not fix this. That's definitely possible, but it might be just as likely that they saw re.findall() as being more simple

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

06.12.19 23:21, Random832 пише: On Fri, Dec 6, 2019, at 15:17, Serhiy Storchaka wrote: 06.12.19 19:49, Random832 пише: If match objects are too hard to use, maybe they should be made more user-friendly? What about adding str and iterable semantics to match objects so it can be used as str

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

25.10.19 15:53, Andrew Barnert via Python-ideas пише: If you were designing a new Python-like language today, or if you had a time machine back to the 90s, it would be a different story. Interesting, how far in past you will need to travel? Initially builtin types did not have methods or

[Python-ideas] Re: Extending @ syntax to allow expressions

22.10.19 06:41, Andrew Barnert via Python-ideas пише: 2: I'm not sure what this would to to uses of "@" as an operator, as has been suggested various times for various laudable reasons; remember that an @decorator or other function definition is just another statement, and arbitrary

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

24.10.19 14:27, David Mertz пише: On Thu, Oct 24, 2019, 7:19 AM Richard Damon > wrote: My one comment about this is to quote from PEP 20, the Zen of Python There should be one-- and preferably only one --obvious way to do it. No problem, the new

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise FuckPython(":("))

28.10.19 20:38, Andrew Barnert via Python-ideas пише: Many of them are abusing throw(StopIteration) to fake a “takewhile clause” in comprehensions Well, so actually you needed the break expression. Or multistatement comprehension. ___ Python-ideas

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

23.10.19 13:08, Steven D'Aprano пише: But the advantage of changing the syntax is that it becomes the One Obvious Way, and you know it will be efficient whatever version or implementation of Python you are using. There is already the One Obvious Way, and you know it will work whatever version

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

23.10.19 18:16, Steven D'Aprano пише: The average word length in English is five characters. That means that in a list of typical English words, more than a third of the expression is made up of the quotes and commas. In the example you give, there are twelve characters in the words themselves

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

23.10.19 14:00, Steven D'Aprano пише: On Wed, Oct 23, 2019 at 01:42:11PM +0300, Serhiy Storchaka wrote: 23.10.19 13:08, Steven D'Aprano пише: But the advantage of changing the syntax is that it becomes the One Obvious Way, and you know it will be efficient whatever version or implementation

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

Stefano Borini Wrote in message:r > This may be a pet peeve of mine, but with the introduction of typehints, more > and more function definitions have become longer than 80characters. This used > to seldom happen in the past.The problem, as I see it, is that there seem to > be a general

[Python-ideas] Re: namedtuple for dict.items()/collections.abc.Mappings.items()

30.11.19 23:16, Soni L. пише: It'd be quite nice if dict.items() returned a namedtuple so all these x[0], x[1], el[0], el[1], etc would instead be x.key, x.value, el.key, el.value, etc. It would be more readable and more maintainable. It was discussed before. The problem is that creating,

[Python-ideas] Re: Calendar.year()

Abdur-Rahmaan Janhangeer Wrote in message:r > Greetings list,In the calendar module, i find it terribly unintuitive to have > a calendar.month but not a calendar.year, the default being > calendar.calendarSuggestion: replace calendar.calendar by > calendar.yearYours,Abdur-Rahmaan

[Python-ideas] Re: Add a slot for "keys" in tp_as_mapping

19.09.19 11:00, Greg Ewing пише: Serhiy Storchaka wrote: PyDict_Merge() is called every time when you have a call like `f(a=1, **kw)` So would not be worth to add slots for keys (and maybe for values and items) to the tp_as_mapping structure? Only if looking up those methods is taking

[Python-ideas] Re: Resolve append/add API inconsistency between set and list

14.10.19 03:47, Chris Angelico пише: Though a set.__setitem__() method might be helpful here. If you set an item to any truthy value, it is added to the set; set it to a falsy value and it will be discarded (without error if it wasn't there, so assignment in this way is idempotent). That would

[Python-ideas] Re: Resolve append/add API inconsistency between set and list

14.10.19 09:54, Chris Angelico пише: On Mon, Oct 14, 2019 at 5:41 PM Serhiy Storchaka wrote: 14.10.19 03:47, Chris Angelico пише: Though a set.__setitem__() method might be helpful here. If you set an item to any truthy value, it is added to the set; set it to a falsy value

[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)

24.02.20 22:02, Guido van Rossum пише: Hm, that's actually an interesting take. Can you compare it to the kind of "quoting" that happens in a lambda? Is there some kind of translation of the OP's original example (Lottery ~ Literacy + Wealth + Region) to a lambda involving those words? I

[Python-ideas] Re: Exception for parameter errors

04.03.20 09:06, Steven D'Aprano пише: Proposal: add a new exception, ParameterError, for parameter errors. For backwards compatibility it would have to be a subclass of TypeError. If add such exception, ArgumentError looks more appropriate name. Where the interpreter now raises TypeError for

[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)

24.02.20 02:27, Aaron Hall via Python-ideas пише: I have no behavior for integers in mind. I would expect high-level libraries to want to implement behavior for it. - sympy - pandas, numpy, sklearn, statsmodels - other mathematically minded libraries (monadic bind or compose?) To do this we

[Python-ideas] Re: Perhaps allow leading zeroes in integer literals

06.02.20 14:03, Jonathan Fine пише: >>> 001 SyntaxError: invalid token The error message was improved in the latest Python: 001 File "", line 1 SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers 1. It was good to remove from

<    1   2   3   4   5   6   >