I have a use case where I'm writing a small filter in Python which
should be able to take output from the find command to filter and
optionally pass it to other commands (like xargs), but also can be
passed specific filenames for the input and/or output. Find can output
it's filenames in null-term
# Experimental Syntax Proposal
I would like to propose that Python adopts a modified process
before introducing significant changes of its syntax.
## Preamble
Given the following file:
```python
# coding: experimental-syntax
from experimental-syntax import fraction_literal
from experimental-sy
This is just a hack idea I had for functions/methods that have
parameters with default values, possibly outside the control of the user
of said function, where sometimes it is desired to pass an argument to
the function that differs from the default but other times it is desired
to just use the def
On 2020-10-24 at 12:29:01 -0400,
Brian Allen Vanderburg II via Python-ideas wrote:
> ... Find can output it's filenames in null-terminated lines since it
> is possible to have newlines in a filename(yuck) ...
Spaces in filenames are just as bad, and much more common:
$ touch 'foo bar'
$
I had many times the same idea: why can't we just "say" to the called
function "use your own default"? I'm quite sure this is possible in a
tricky way, since defaults are stored in the function object.
Anyway, honestly I don't like your syntax proposal.
See PEP 638:
https://www.python.org/dev/peps/pep-0638/
If I have understood well, it proposes what you want
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mai
> If you look in PEP 622 you'll see that there was a rejected idea `if
> match ...` that's pretty similar. We nixed it because it just made the
> PEP larger. For 3.11 we can consider something like this.
Of course I understand the PEP is already pretty big. But if it goes
through and we start thin
If you find PEP-634 a bit dry, you might give a try to PEP-636 (written in
an explanatory style rather than a hard-spec style). You can always go back
to PEP-634 for the precise details.
On Fri, 23 Oct 2020 at 13:48, Ricky Teachey wrote:
> Fwiw, although I see how PEP 634 has the potential to be
On Sat, Oct 24, 2020 at 4:39 PM Marco Sulla
wrote:
> See PEP 638:
> https://www.python.org/dev/peps/pep-0638/
>
> If I have understood well, it proposes what you want
>
No, it does not. It proposes actual changes to the Python interpreter.
Under my proposal, something like what is proposed ther
On Sat, Oct 24, 2020, 3:47 PM Daniel Moisset wrote:
> If you find PEP-634 a bit dry, you might give a try to PEP-636 (written in
> an explanatory style rather than a hard-spec style). You can always go back
> to PEP-634 for the precise details.
>
Thank you that looks really helpful!
> Why should a failed match return None? That's not helpful if it matches
> but the value itself is None.
The only pattern that would match `None` is this one:
print(None := get_value()) # Always None
Here, the walrus operator would always return `None`. Either because the
function return
I think that instead of dict unpacking specifically, what we need is to come up
with a way to use the pattern-matching proposed in PEP 634 outside of match
statements. This would make it possible to unpack any pattern.
My opinion is that the walrus operator is practically waiting to support
pat
Steven D'Aprano wrote:
> # Dotted names
> from types import SimpleNamespace
> obj = SimpleNamespace()
> obj.spam = **{'obj.spam': 1}
> assert obj.spam == 1
>
> # Subscripts
> arr = [None]*5
> arr[1], arr[3] = **{'arr[3]': 33, 'arr[1]': 11}
> assert arr == [None, 11, None, 33, None]
Currently in P
On Sat, 24 Oct 2020 at 21:49, André Roberge wrote:
> No, it does not. It proposes actual changes to the Python interpreter.
>
> Under my proposal, something like what is proposed there would first be
> implemented as a third party package.
>
Not sure, but yes, the PEP proposes a change to the in
I really like this style of programming, especially after fooling around with
Rust a lot,
where pattern matching and its variations, like "if let" are working really
well.
I also like the idea of using the walrus operator in this use case, while it is
probably up
for a lot of discussing if th
15 matches
Mail list logo
