[Python-ideas] Re: PEP Idea: native f-string support as a match pattern
Stephen J. Turnbull wrote:
> I think this is a pretty unconvincing example. While people seem to
> love to hate on regular expressions, it's hard to see how that beats
> def unquote(string: str) -> str:
> m = re.match(r"^(?:"(.*)"|'(.*)'|(?Pvalue3))$", string)
RegEx feels overkill for this. Certainly takes longer to read, understand and
test.
Here's a more convincing example, let's build an imaginary data format parser:
```python
data = '''\
scores:
- Matthew: 100
- David: 90
groceries:
- spam: 3
- eggs: 12
'''
parsed = {}
for line in data.splitlines():
match line:
case f"{heading}:"
parsed[heading] = {}
case f"- {name}: {count}":
parsed[heading][name] = int(count)
print(parsed)
# Gives {'scores': {'Matthew': 100, 'David': 90}, 'groceries': {'spam': 3,
'eggs': 12}}
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EOAIBI7MUW4FO5FQJVTC47VX7O4ES6J5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP Idea: native f-string support as a match pattern
Since Python has built-in syntax for interpolated strings, I believe it's a
good area to idea to extend it to pattern matching, like so:
def unquote(string: str) -> str:
match string:
case f'"{value}"':
return value
case f"'{value}'":
return value
case _:
return string
Doing this with current match syntax is not as easy.
I have other reasons to consider this idea as well, but before I try to pursue
this, I'd like to know if something like this was already discussed when the
proposal was being made?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/4D2CRUSACUYK2VNYHULBUQ525QAF7XDV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Idea: Better return type annotation syntax
Jelle Zijlstra wrote: > > I like this too. A practical issue is that list[(a, b)] and list[a, b] look > the same to the compiler, but they would mean very different things. It's > not obvious how to fix this in a backward-compatible way. > > I think it looks much cleaner, and if there isn't any drawbacks to adding > > this syntax, I'd love to work on bringing this to life. Restricting it to only the top level of a return type annotation should do the trick! Such that: def f() -> (X, Y, Z): ... is interpreted as tuple[X, Y, Z], but: def f(x: (X, Y, Z)) -> None: ... def f() -> Union[int, (X, Y, Z)]: ... def f() -> list[(X, Y, Z)]: ... Are not considered as tuple[...] ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GDTLCSBIGY7W6GNWHUMRGY7KKFDKT3LU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP Idea: Better return type annotation syntax
With the recent submission of [PEP 677][1], I was reminded of an idea I had with function annotation syntax since the very beginning: why not let me write: ```python def f() -> tuple[int, str]: return 42, 'foo' ``` as: ```python def f() -> (int, str): return 42, 'foo' ``` Is there any inherent reason for this, other than that it isn't an actual "type"? I think it looks much cleaner, and if there isn't any drawbacks to adding this syntax, I'd love to work on bringing this to life. [1]: https://www.python.org/dev/peps/pep-0677/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NLZOBGSJT3A7KVSZVIHCQBOGKZ2E7AI2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] reversed enumerate
Instead of changing how `reversed()` works, wouldn't a `reversed=True` property on `enumerate` itself (which checks if the iterable being reversible) suffice? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3A2QCZ6U6EIYAYZ6OQSBYY2IT5CEGW6D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] dataclasses to have a way to make hashable fields immutable
currently in a `dataclasses.dataclass` based class, you can either have it hashable and completely immutable (using frozen=True and eq=True), or you can have it hashable but completely mutable (by using unsafe_hash=True) unsafe_hash provides the convenience of being able to mutate some fields, while computing your hash by other, non-mutable fields. But there is nothing enforcing the fact that the fields marked with `hash=True` should stay immutable, otherwise it completely breaks hashability. The suggestion is, for the dataclass to throw an error if you try to mutate a field that contributes to the hash of that dataclass. Or, to have a flag that allows you to do so. Suggestions for the flag name could be @dataclass(freeze_hashable_fields=True) class A: ... or @dataclass(frozen_hash=True) class A: ... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BQ75RNKQKV6KCTZ2UWDU2RNDHDIQNCZG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
Alright, I see why `str.isfloat()` isn't a thing, and having a builtin float validation function was besides the point anyway. Thanks for the clarifications :) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UGW5TOIYE73F6SPUBY3F3X64NPS6T7ML/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] str.isfloat()
str currently has methods like isdecimal, isnumeric and isdigit, but there isn't an isfloat check, which could be very handy. a trivial implementation could be as simple as: try: float(self) return True except ValueError: return False ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KEUR54FVEE7FRY4RGLK4IGTJOTKXQH5H/ Code of Conduct: http://python.org/psf/codeofconduct/
