[Python-ideas] Re: pathlib.Path.makedirs

On Wed, Jan 13, 2021, at 08:31, Antonio Cavallo wrote: > Hi, > I've found myself typing too many time this: > pathlib.Path("some-dir-name").mkdir(parent=True, exist_ok=True) > > Wouldn't be better to have a pathlib.Path.makedirs with parent/exist_ok > set to True by default? Worth mentioning, th

[Python-ideas] Re: Python with braces formal proposal?

On Tue, Jan 5, 2021, at 17:17, lasizoillo wrote: > Sorry, but if I'm understanting the point is to make one-liners. For > example, if I want to do something like: > > $ env | grep "^XDG" > > In one python one liner like > > $ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value

[Python-ideas] Re: pathlib enhancements

On Fri, Jan 8, 2021, at 15:47, Joseph Martinot-Lagarde wrote: > One remark about this : .tar.gz files are the exception rather than the > rule, and AFAIK maybe the only one ? It's pretty common to have dots in > filenames instead of blanks for example, and stem does the right thing > here : '/da

[Python-ideas] Re: [Python-Dev] reversed enumerate

On Thu, Jan 21, 2021, at 18:48, Chris Angelico wrote: > Note that slicing is NOT easy. The proposed semantics for a reversed > enumeration would make slicing extremely odd. What proposed semantics? You were the one who posted a pure-python implementation that didn't bother to implement slicing.

[Python-ideas] Re: [Python-Dev] reversed enumerate

On Thu, Jan 21, 2021, at 19:19, Chris Angelico wrote: > Yeah, I don't think that'll work if you slice more than once, > especially with some iteration in between. I think part of the point of this implementation [or the other person's suggestion of having a "collection view", which amounts to the

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Fri, Jan 22, 2021, at 20:34, Inada Naoki wrote: > * Default encoding is "utf-8". it might be worthwhile to be a little more sophisticated than this. Notepad itself uses character set detection [it might not be reasonable to do this on the whole file as notepad does, but maybe the first 512 by

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Sat, Jan 23, 2021, at 05:06, Inada Naoki wrote: > On Sat, Jan 23, 2021 at 2:43 PM Random832 wrote: > > > > On Fri, Jan 22, 2021, at 20:34, Inada Naoki wrote: > > > * Default encoding is "utf-8". > > > > it might be worthwhile to be a little more s

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Sat, Jan 23, 2021, at 08:00, Stephen J. Turnbull wrote: > I see very little use in detecting the BOMs. I haven't seen a UTF-16 > BOM in the wild in a decade (as usual for me, that's Japan-specific, > and may be limited to the academic community as well), and the UTF-8 > BOM is a no-op if the de

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Sat, Jan 23, 2021, at 22:43, Matt Wozniski wrote: > 1. Deprecate calling `open` for text mode (the default) unless an > `encoding=` is specified, I have a suggestion, if this is going to be done: If the third positional argument to open is a string, accept it as encoding instead of buffering

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Sun, Jan 24, 2021, at 13:18, MRAB wrote: > Well, if you see patterns like b'\x00H\x00e\x00l\x00l\x00o' then it's > probably UTF16-BE and if you see patterns like > b'H\x00e\x00l\x00l\x00o\x00' then it's probably UTF16-LE. > > You could also look for, say, sequences of Latin characters and >

[Python-ideas] Re: Provide UTF-8 version of Python for Windows.

On Mon, Jan 25, 2021, at 22:49, William Pickard wrote: > Looks like that's only available for Microsoft Store apps only, so it > might not be viable for Python. I think the "Fusion manifest for an unpackaged Win32 app" part applies to non-store apps. [English version of the page: https://docs.

[Python-ideas] Re: Add a couple of options to open()'s mode parameter to deal with common text encodings

On Thu, Feb 4, 2021, at 18:46, Ben Rudiak-Gould wrote: > > On Thu, Feb 4, 2021 at 3:29 PM Chris Angelico wrote: > > With "t", it takes/gives Unicode objects, but with "b" it uses bytes. > > Sure, in Python 3, but not in Python 2, or C. > > Anyway, moral correctness is beside the point. People i

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

While we're on the subject of assignment expression limitations, I've occasionally wanted to write something like try: return a_dict[key] except KeyError: return (a_dict[key] := expression to construct value) ___ Python-ideas mailing list -- pyt

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

> On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote: > > > > While we're on the subject of assignment expression limitations, I've > > occasionally wanted to write something like > > > > try: > > return a_dict[key] > > except KeyError:

[Python-ideas] Re: Alternate lambda syntax

On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote: > Hello, > > On Thu, 11 Feb 2021 12:24:55 +0100 > "J. Pic" wrote: > > > Hi all, > > > > Lambdas can be defined as such: > > > > w = lambda: [12] > > x = lambda y: len(y) > > > > I'd like to propose the following: > > > > w = (): [12] >

[Python-ideas] Re: Alternate lambda syntax

On Fri, Feb 12, 2021, at 02:23, Paul Sokolovsky wrote: > > Great to hear there's no desire to stray away from JavaScript just for > > the purpose of being different. > > ... And on the 2nd thought, that won't work. The reason it works in JS > is that it doesn't have tuples. In Python, "(a, b) => (

[Python-ideas] Re: Arrow functions polyfill

On Sat, Feb 13, 2021, at 21:57, Steven D'Aprano wrote: > # Erlang > multiply(X,Y) -> X * Y. For the record, Erlang's lambda syntax is the relatively unpleasant "fun(X,Y) -> X * Y end". Elixir is the same, except that the keyword is fn. > Dart uses "=>" > > multiply(x, y) => x * y;

[Python-ideas] Re: Alternate lambda syntax

On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > except a couple of characters. So what currently looks like > > some_list.sort(key=lambda e: e[3].priority) > > would then be > > some_list.sort(key=(e)->e[3].priority) Let's not pretend the key argument being keyword-only is

[Python-ideas] Have virtual environments led to neglect of the actual environment?

I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in

[Python-ideas] Re: Arrow functions polyfill

On Tue, Feb 23, 2021, at 17:01, Rob Cliffe via Python-ideas wrote: > As far as I know, there is no case of valid syntax using 'lambda' where > replacing 'lambda' by 'def' results in valid syntax. > Can anyone provide a counter-example? > If not, I would support allowing 'def' as an alternative to

[Python-ideas] Re: [Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

I accidentally removed Python-Ideas from the recipient list while posting this reply. On Wed, Feb 24, 2021, at 09:16, Random832 wrote: > On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: > > Separate directories don't prevent clashes and system breakage. But they > > pr

[Python-ideas] Re: [Python-Dev] Re: Re: Re: Have virtual environments led to neglect of the actual environment?

On Wed, Feb 24, 2021, at 09:08, Paul Moore wrote: > I don't use Linux much, and I'm definitely not familiar with Linux > distribution tools, but from what I can gather Linux distributions > have made the choices: > > 1. Write key operating system utilities in Python. > 2. Share the Python interpre

[Python-ideas] Re: Integer concatenation to byte string

On Wed, Mar 3, 2021, at 04:09, Barry Scott wrote: > I was thinking of the C functions that are executed in ceval.c to run > the interpreter for any byte code. In that case, it's not clear how your proposed syntax would not have the same overhead [especially your suggestion of a += operator]

[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result

On Thu, Aug 26, 2021, at 08:50, Evan Greenup via Python-ideas wrote: > Currently, when what to execute external command, either os.system() or > subprocess functions should be invoked. > > However, it is not so convenient, it would be nice to use "``" symbol > to brace the shell command inside.

Re: [Python-ideas] DB-API support for sets?

On Wed, May 22, 2019, at 09:58, Inada Naoki wrote: > Placeholders may be substituted by server. > So we can't force to allow multiple values in one placeholder. Can the placeholder be substituted for multiple placeholders by the client side, which are then further individually substituted by the

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote: > class float: > def __json__(self): > if math.isfinite(self): return str(self) > return "null" Er, to be clear, the current JSON decoder returns 'Infinity', '-Infinity', or 'NaN', which are invalid JSON, not null. This beh

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

On Fri, Sep 27, 2019, at 12:48, Andrew Barnert via Python-ideas wrote: > or get rid of the guarantee that @dataclass returns your > class with extra dunders. Why is dataclass a decorator instead of a metaclass (or, as below, pseudo-metaclass) anyway? Is it just that the decorator syntax looks ni

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote: > On 04/10/2019 20:34, Caleb Donovick wrote: > > The first and perhaps the most obvious, is doing relational queries. > > ``` > > where_x_1 = db[x=1] > > ``` > > is more beautiful than > > ``` > > where_x_1 = db[dict(x=1)] > > where_x_1 = db[{'x':

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote: > > Allowing key value pairs in geitem need not change the interface of > > getitem. All the key value pairs could be collected as a dict and passed > > to getitem as the index. > > Um. Stop me if I'm wrong, but isn't that exactly a change to t

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Mon, Oct 7, 2019, at 10:02, Rhodri James wrote: > It would still break a lot of user __getitem__ implementations IHMO. It is already possible to pass any object. The fact that passing an object that an object is not designed to accept won't get good results doesn't mean the ability to do so "

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Mon, Oct 7, 2019, at 18:19, Cameron Simpson wrote: > On 07Oct2019 10:56, Joao S. O. Bueno wrote: > >So, in short, your idea is to allow "=" signs inside `[]` get notation to > >be translated > >to dicts on the call, > > Subjectively that seems like a tiny tiny win. I'm quite -1 on this idea;

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Tue, Oct 8, 2019, at 13:57, Steven D'Aprano wrote: > It is confusing as hell. When I saw this > > da[space=0, time=:2] > > I read it as a slice: > > da[ slice( (space=0, time=), 2, None) ] > > and thought "That must be a typo, because the time keyword > doesn't have a value." Do yo

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

On Tue, Oct 8, 2019, at 14:18, Anders Hovmöller wrote: > I don't see it. Can you give examples of all the variations of slicing > and their keyword equivalent so I understand what you mean? I'll write > out the slicing variants and you can fill in how it would look with > keyword arguments: > >

[Python-ideas] Re: Additional meanings for "in" operator and ability to customize implementation

On Sun, Oct 13, 2019, at 14:51, David Mertz wrote: > I would not want to overload plain strings' .__contains__() method to > mean "has this substring OR matches this compiled regex." Besides being > on a likely performance path, it's too special. And what about glob > patterns, for example? Thos

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

On Mon, Oct 21, 2019, at 22:00, Steve Jorgensen wrote: > I think some idea like this might be worth proposing. the first idea > that comes to my mind is to allow the name of a decorator to be an > fstring using `@'...'` or `@"..."` syntax. > > If, for example, you have `method_type = 'class'`, t

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

On Mon, Oct 21, 2019, at 22:30, Random832 wrote: > On Mon, Oct 21, 2019, at 22:00, Steve Jorgensen wrote: > > I think some idea like this might be worth proposing. the first idea > > that comes to my mind is to allow the name of a decorator to be an > > fstring using `@

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

On Wed, Oct 23, 2019, at 19:00, Christopher Barker wrote: > On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas > wrote: > > The main problem is that a str is a sequence of single-character str, each > > of which is a one-element sequence of itself, etc. forever. If you wanted > >

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

On Sat, Oct 26, 2019, at 20:26, David Mertz wrote: > Absolutely, utf-8 is a wonderful encoding. And indeed, worst case is > the same storage requirement as utf-16 or utf-32. For O(1) random > access into all strings, we have to eat 32-bits per character, one way > or the other, but of course the

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

On Sun, Oct 27, 2019, at 03:39, Andrew Barnert via Python-ideas wrote: > (Actually, IIRC, one of the two has a str type that, despite being 2.x, > is unicode rather than bytes, but with some extra undocumented > functionality to smuggle bytes around in a str and have it sometimes > work.) I do

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

On Sun, Oct 27, 2019, at 03:10, Andrew Barnert wrote: > On Oct 26, 2019, at 19:59, Random832 wrote: > > > > A string representation considering of (say) a UTF-8 string, plus an > > auxiliary list of byte indices of, say, 256-codepoint-long chunks [along > > with per

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

On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote: > On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote: > > > > throw is an expression, not a statement, in C++. I see no reason raise > > couldn't be an expression in Python. It doesn't even need a special > > rule in the gramma

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

On Sun, Nov 3, 2019, at 11:01, Andrew Barnert via Python-ideas wrote: > > counter-argument: foo = raise NIY > > What is that a counter-argument to? The fact that it would nearly > always be completely useless to assign a raise? > > I don’t know what NIY means here, but why couldn’t you write thi

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

On Tue, Nov 5, 2019, at 16:22, Greg Ewing wrote: > Random832 wrote: > > I have, occasionally, wanted to be able to resume a function > > after handling an exception ... In a hypothetical > > implementation that would allow such a thing, having the raise return a > > v

[Python-ideas] Re: A bit change to create a matrix variable in Python as easy as MATLAB and Julia!

On Thu, Nov 7, 2019, at 22:19, yejus...@163.com wrote: > (1) Keeping the original syntax of List unchanged，for example： > a = [1,2,3] # will be parsed to a normal list. > b = [[1,2,3],[4,5,6]] # will be parsed to a normal list，too. > Simply put, all the original list syntax remains

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

On Mon, Nov 11, 2019, at 03:22, Greg Ewing wrote: > On 11/11/19, 12:41 PM, Richard Damon wrote: > > it was DESIGNED to be inefficient (that was one of its design goals, to > > slow typesetters down to be slower than the machine they were working > > on). > > This is most likely a myth, see https:/

[Python-ideas] Re: `__lcontains__` for letting the other class determine container membership when `__contains__` fails

On Tue, Nov 12, 2019, at 20:00, Samuel Muldoon wrote: > > *Currently, the `in` operator (also known as `__contains__`) always > uses the rightmost argument's implementation.* minor bikeshed: I've always considered the "r" in these to mean "reverse", not "right". more serious issue: method pai

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

On Thu, Nov 14, 2019, at 03:57, Paul Moore wrote: > with \ > open(fname1) as f1, \ > open(fname2) as f2, \ > open(fname3) as f3, \ > open(fname4) as f4: So, uh... what if we didn't need backslashes for statements that begin with a keyword and end with a colon?

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

On Thu, Nov 14, 2019, at 11:54, Paul Moore wrote: > On Thu, 14 Nov 2019 at 16:42, Random832 wrote: > > > So, uh... what if we didn't need backslashes for statements that begin with > > a keyword and end with a colon? There's no syntactic ambiguity there, > >

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

On Thu, Nov 14, 2019, at 13:12, Andrew Barnert wrote: > And then you can run it on a whole mess of code and verify that it’s > only different in the cases where you want it to be different (what > used to be an ERRORTOKEN or NEWLINE is now an NL because we’re in the > middle of a with compound s

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

On Thu, Nov 14, 2019, at 16:23, MRAB wrote: > On 2019-11-14 19:51, Andrew Barnert via Python-ideas wrote: > > And that raises a point: the if keyword can appear in other places besides > > the start of a compound statement. Does tokenize.py have enough info to > > handle that properly? I don’t kn

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

On Fri, Nov 15, 2019, at 10:30, Joao S. O. Bueno wrote: > Just throwing this idea in: what about an approach _not touching_ the > parser or compiler at all? : > Just add __enter__ and __exit__ to tuples themselves! Instead of > repeating "why should we ever do that", we > _do_ that exactly to ent

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

On Sat, Nov 16, 2019, at 16:13, Greg Ewing wrote: > On 17/11/19 4:54 am, Ricky Teachey wrote: > > > I think it'd be at least as confusing as the current situation. > > It might be better to keep it as purely a context manager, and > not load it down with any other baggage. > > I wouldn't

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

On Sun, Nov 17, 2019, at 14:17, Oscar Benjamin wrote: > Also I don't know of any other misbehaving context managers besides > open so I'm not sure that a general utility is needed rather than just > a well-behaved alternative for open. It's not in dbapi2, but most database connections are context

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

On Sun, Nov 17, 2019, at 16:43, Greg Ewing wrote: > Probably. I may also have mixed it up with closing(), which > does something different. It occurs to me that almost any usage of closing likely has the same problem, in that the expression passed to closing may itself throw an exception. It may

[Python-ideas] Re: Tuple Comprehension

On Sun, Nov 17, 2019, at 21:39, Daniel Zeng wrote: > Syntax for tuple comprehension, something like: > (i, for i in range(10)) > > This shouldn't result in ambiguity, since generators need to be in > parentheses anyway: > (i, for i in range(10)) vs (1, (i for i in range(10))) I think it should

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

On Mon, Nov 18, 2019, at 03:42, Paul Moore wrote: > The context here has been lost - I've searched the thread and I can't > find a proper explanation of how open() "misbehaves" in any way that > seems to relate to this statement (I don't actually see any real > explanation of any problem with open(

[Python-ideas] Re: Differentiate variables form everything else

On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote: > def f(a, b): return a**(b+1) > g = partial(f, b==2) > h = lambda x: f(x, 2) > > Python can’t tell the difference between f, g, and h; they’re all > variables. An IDE could keep track of the fact that f was bound

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

On Mon, Nov 18, 2019, at 12:59, Paul Moore wrote: > On Mon, 18 Nov 2019 at 17:55, Random832 wrote: > > This particular chain of discussion is regarding a proposal to solve the > > problem posed in the original topic by using a parenthesized tuple display, > > i.e. cod

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

On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote: > But open() isn't designed *just* to be used in a with statement. It > can be used independently as well. What about > > f = open(filename) > header = f.readline() > with f: > # use f > > The open doesn't "create a future need

[Python-ideas] Re: Differentiate variables form everything else

On Mon, Nov 18, 2019, at 14:04, Chris Angelico wrote: > If by "constant" you mean that they are immutable, then maybe; there > aren't very many mutable callables (by comparison to the huge number > of functions). But you can't assume that a function is as constant as > a string literal. I meant a

[Python-ideas] Re: Tuple Comprehension

On Mon, Nov 18, 2019, at 13:35, Serhiy Storchaka wrote: > 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))) It'd be (*(i for i in range(10)),) but point taken. In fact, after thinking about it some

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

On Mon, Nov 18, 2019, at 19:32, Soni L. wrote: > let me ask again: can we make it so open() never fails, instead > returning a file that can be either "open", "closed" or "errored"? For one thing, it'd have to *truly never* fail. Not just on I/O errors but on things like passing bad function arg

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

On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote: > That sounds reasonable, with one proviso. I would *strongly* object to > calling context managers that conform to the new expectations "well > behaved", and by contrast implying that those that don't are somehow > "misbehaving". File objects have

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

On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote: > Because you don't have to create the context manager directly in the > with statement ...what? that's *my* argument. that's *precisely* why I consider open to be 'misbehaving'. Because you *should* be able to create a context manager outside th

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

On Tue, Dec 3, 2019, at 01:02, Kyle Stanley wrote: > However, if the OP wants to personally implement this behavior for > their own subclass of sets (instead of adding it to the language), that > could be done rather easily: The OP wanted to return the object that was in the set. I don't think t

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

What if there was a general mechanism to allow operators to be implemented by user code that does not belong to the class? If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, within that module all calls to that operator are replaced with a two-step process: call __operatorh

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

On Tue, Dec 3, 2019, at 11:36, Ricky Teachey wrote: > > > What if there was a general mechanism to allow operators to be implemented > > by user code that does not belong to the class? > > > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > > within that module all c

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

On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote: > -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

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

On Tue, Dec 3, 2019, at 20:46, Oscar Benjamin wrote: > What exactly is the idiom here? > > Using bare next is not a good idea because it leaks StopIteration > which can have awkward side effects. So are you suggesting something > like > > result = next(re.finditer(...), None) > if result is None:

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

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 be fun either. To me this

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

On Wed, Dec 4, 2019, at 11:05, Guido van Rossum wrote: > Not so fast. re.search() returns a Match object, while re.finditer() > and re.findall() return strings. For people who are just interested in > strings, the Match object is just a distraction. I think I am +1 on > adding re.findfirst() as

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

On Wed, Dec 4, 2019, at 11:49, Ethan Furman wrote: > On 12/04/2019 08:39 AM, Random832 wrote: > > 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

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

On Wed, Dec 4, 2019, at 11:51, Chris Angelico wrote: > Which of these are you expecting to be detected, and thus cause the > change in bytecode? More or less the same sort of operations where the use of the name super is detected within methods and causes the enclosing class to have a __class__ c

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

On Thu, Dec 5, 2019, at 12:25, Andrew Barnert via Python-ideas wrote: > It’s unfortunate that these functions aren’t better matched. Why is > there a simple-semantics find-everything and a match-semantics > find-iteratively and find-one? But I don’t think adding a > simple-semantics find-one tha

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

On Fri, Dec 6, 2019, at 14:50, MRAB wrote: > On 2019-12-06 18:24, Andrew Barnert via Python-ideas wrote: > > On Dec 6, 2019, at 09:51, Random832 wrote: > >> > >> If match objects are too hard to use, maybe they should be made more > >> user-friendly? What abo

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

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(r

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

On Sat, Dec 7, 2019, at 01:43, Serhiy Storchaka wrote: > This is incompatible with subscripting. match[0] returns match.group(0), > not match.groups()[0]. And dict[0] returns the value whose key is 0, not the first key of the dictionary. set[0] does not work at all. there is no general guarante

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019, at 12:31, Andrew Barnert via Python-ideas wrote: > > >>> getslice[] > > SyntaxError: invalid syntax > > What would you expect these to return? As an aside, I've occasionally wished that [] would be the same as [()], by analogy to [1,2].

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019, at 15:59, Steven D'Aprano wrote: > But why have the empty index default to () rather than None or 0 or -1 > or slice(None, None, None) or some other value? That's an arbitrary > and not a good one. My main reason for the suggestion was because that is the index used to acce

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

On Fri, Dec 13, 2019, at 19:24, Steven D'Aprano wrote: > `__builtins__` is a private CPython implementation detail, so the above > is always wrong in user code. Better: Wait, it is? Is there then no portable way to do the things like: - providing an alternate __builtins__ to evaluated code, with

[Python-ideas] Re: Segmentation of string

On Sat, Dec 14, 2019, at 04:06, smfiles wrote: > I think it's necessary to add a segment() method to str type or string > module. This method is used to split a string into m parts and return > all cases. With segment(), you can avoid tedious calculation and > indexing if you want to segment a

[Python-ideas] Re: Add symlinks option at shutil.move parameters

On Thu, Dec 19, 2019, at 17:43, Guido van Rossum wrote: > A quick look at the docs > shows what > the OP is likely after. > > The function has this signature: > > `shutil.``move`(*src*, *dst*, *copy_function=copy2*)¶ >

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

On Wed, Dec 25, 2019, at 21:09, python-ideas--- via Python-ideas wrote: > On the contrary, on sets you can apply union *and* difference. And > since union seems the exact contrary of difference, it's illogical that > | is used instead of +. But sets also support symmetric difference ^, and inter

[Python-ideas] Re: findfirst() from findalliter(), and first

On Fri, Dec 27, 2019, at 11:58, Juancarlo Añez wrote: > Fon *first()*, maybe calling it *take_one()* will clear up > misunderstandings about it's semantics. It may be worth mentioning that take [arbitrary n] is already present in itertools recipes. Though that gets into the debates about what sh

[Python-ideas] Re: Target-and-expression lists and if-try

On Tue, Dec 31, 2019, at 22:18, Andrew Barnert via Python-ideas wrote: > I’m just feeling out whether either one is so horrible that any larger > proposal (which I don’t have in anywhere near ready-to-share form yet) > would have to be rejected on that basis. (Which I think is a serious > possib

[Python-ideas] Re: Target-and-expression lists and if-try

On Wed, Jan 1, 2020, at 21:49, Andrew Barnert wrote: > On Jan 1, 2020, at 13:23, Random832 wrote: > > > > Neither of these constructs seems to be particularly useful outside the > > other one, > > Yes, and you already quoted me as saying that. I think I read "n

[Python-ideas] Re: Target-and-expression lists and if-try

On Thu, Jan 2, 2020, at 13:22, Dan Sommers wrote: > What about "if except" (any time I can eliminate a "not," that's a good > thing): wait, is this meant to be for the doesn't-throw case or does-throw? how are we eliminating the not? > if except x: > y > > which could even leave r

[Python-ideas] timezone-aware datetime.now

Right now there is no simple way to get a timezone-aware time for the current time in the current time zone [without resorting to outside libraries like pytz], I would like to propose a simple extension to datetime.now to allow returning an aware datetime object using a plain single-offset tzinf

[Python-ideas] Re: timezone-aware datetime.now

On Sat, Jan 4, 2020, at 15:11, Random832 wrote: > ... I just discovered, in the course of trying to make a more fleshed-out implementation, that the correct way to do this is datetime.now().astimezone(None) - this isn't explained very well in the documentation. I did notice, thoug

[Python-ideas] Re: python -m quality of life improvements

On Sat, Jan 11, 2020, at 02:06, Andrew Barnert via Python-ideas wrote: > Well, there are definitely subtle differences. If it’s a single file > rather than a package, running it as a script means you have to include > the extension; with -m you can’t. If you -m a package, argv[0] is the > path t

[Python-ideas] Compound statement colon (Re: Re: Improve SyntaxError for obvious issue:)

On Tue, Jan 14, 2020, at 18:15, David Mertz wrote: > For what it's worth, after 20+ years of using Python, forgetting the > colon for blocks remains the most common error I make by a fairly wide > margin. Of course, once I see the error message—even being not all that > descriptive of the real i

[Python-ideas] Allow relative seek on StringIO

Absolute seeking on a StringIO treats the offset as a character count regardless of the contents, so given that there is no "pretend it's UTF-8 and advance a given number of 'bytes'" machinery anyway, there's no reason not to allow seeking relative to the current location or the end of the 'file

[Python-ideas] Re: Allow relative seek on StringIO

On Thu, Jan 16, 2020, at 23:07, Guido van Rossum wrote: > Sounds like you should just submit a bug report (and a PR with a fix if > you feel up to it). Since a relative seek to position p is typically > just implemented as an absolute seek to position f.tell()+p, this looks > like an odd omissio

[Python-ideas] Re: Compound statement colon (Re: Re: Improve SyntaxError for obvious issue:)

On Fri, Jan 17, 2020, at 21:32, Josh Rosenberg wrote: > The colon remains syntactically necessary in some cases, particularly > to disambiguate cases involving one-lining (no block involved). Stupid > example: If the colon is optional, what does: I was only proposing making it optional in the mu

[Python-ideas] Re: addition of "nameof" operator

On Tue, Jan 21, 2020, at 16:32, Andrew Barnert via Python-ideas wrote: > What would the semantics of nameof be in Python? Would it just be > lambda obj: obj.__name__? Or some fancy inspect-module style chain of > “try this, then that, then the other”? Or does it need to look at the > compiled so

[Python-ideas] Re: !$? operators for gratuitous overloading

On Sun, Feb 2, 2020, at 11:41, MRAB wrote: > On 2020-02-02 15:00, Karl Ramm wrote: > > We have all shared in the observation that all but the most carefully > > considered operator overloading tends to reduce code readability. There > > also many programmers that feel that they need it to make the

[Python-ideas] statement-scoped context managers (was: Re: Pickle to/from filename or path)

On Fri, Feb 7, 2020, at 13:03, Todd wrote: > approaches like opening within the dump or load, which the wiki > still recommends [1]. > > So something like: > > with open('myfile.p', 'wb') as f: > pickle.dump(myobj, f) > > Would be: > > pickle.dump(myobj, 'myfile.p') What if you could write

[Python-ideas] Re: statement-scoped context managers

On Sat, Feb 8, 2020, at 17:14, Soni L. wrote: > On 2020-02-08 6:53 p.m., Bruce Leban wrote: > > On Sat, Feb 8, 2020 at 1:22 PM Chris Angelico wrote: > >> Exactly how much code would be wrapped in the 'with' block? > > > > This is an intriguing idea, and in the example it's fairly easy to wrap

[Python-ideas] Re: statement-scoped context managers

On Sat, Feb 8, 2020, at 18:06, Random832 wrote: > My own expectation, for what it's worth, would be something like [snip] After thinking about it some more, I realized that my idea can basically be translated to "all with-expressions in the statement get added to an implicit ExitSt

[Python-ideas] Re: prefix/suffix for bytes (was: New explicit methods to trim strings)

On Sat, Mar 7, 2020, at 19:31, Cameron Simpson wrote: > >I *think* I understand the issues. And I can see that some software would > >need to work with filenames as arbitrary bytes. But that doesn't mean that > >you can do much with them that way. > > Given that the entire UNIX filename API is byt

  1   2   3   >