[Python-ideas] Re: Regular Expression | re - Support String List Input Type List[str]
Hi, I would like to have the same function re.search(pattern, input) to keep main code structure to be the same. The input into the re.search function will be depended on other previous functions. It is also more dynamic for users. Thank you. ___ 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/SMBNFYXY3DGLQ6SHIRDQSEAYFE654DU3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
Sorry if this isn't the right thread -- there's a few now. But for an example of using both positional and keyword index parameters: I maintain a library (gridded) that provides an abstraction over data on various types of grid (in this case generally Oceanographic model output) -- they can be rectangular grids, curvilinear, unstructured triangular, The point of the library is to save the user from having to understand how all those grids work and, rather, be able to work with the data as if it were a continuous field. For example, if I want to know the sea surface temperature at a given location, I need to figure out what cell that location is in, what the values are at the corners of that cell, and then interpolate over the cell. After abstracting that, one can create a gridded.Variable object, and then do: sea_surface_temp.at(-78.123, 28.432) and get the value at those coordinates. So it would be pretty nifty to do: sea_surface_temp[-78.123, 28.432], which of course I could do with Python as it is. But in some instance, there is more than one way to interpolate, so it would be great to have: sea_surface_temp[-78.123, 28.432, interp='linear'] and that would require having mixed positional and keyword index parameters. -CHB On Sun, Sep 27, 2020 at 6:48 PM Stephan Hoyer wrote: > On Sat, Sep 26, 2020 at 8:40 PM Steven D'Aprano > wrote: > >> On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote: >> >> > In this fashion have you considering having keyword only indices, that >> is >> > to only allow either obj[1, 2] or obj[row=1, col=2] (if the class >> supports >> > it), and disallow mixing positional and keyword indices, meaning obj[1, >> > col=2] would be a SyntaxError. >> >> That would severely reduce the usefulness of this feature for me, >> probably by 80 or 90%, and possibly make it useless for xarray and >> pandas. >> >> (I don't speak for the pandas or xarray devs, I'm happy to be >> corrected.) > > > From my perspective as a developer for both xarray and pandas, both > "mixed" and "keyword only" indexing have use cases, but I would guess > keyword only indexing is more important. > > In xarray, we currently have methods that awkwardly approximate keyword > only indexing (e.g., xarray.DataArray.sel() and xarray.DataArray.isel() > both allow for named dimensions with **kwargs), but nothing for the "mixed" > case (neither method supports positional *args). > ___ > 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/IPEP5YXUQKCNCARJH4NKF7I757M7XLCA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/UBQS7YPOS3KD4PBPTWOBTKXOS6QSEAM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On Sun, Sep 27, 2020 at 2:18 PM MRAB wrote: > Consider, for example, the use-case of a function that has an optional > parameter and you want a way to know whether an argument has been > provided but None is a valid value that could be passed in. > > Having a singleton such as Missing would be helpful there. > The trouble is that's what None was supposed to be for. Over time, Missing would presumably fall victim to the same fate that befell None. You'd also probably have to extend PEP 505 to support Missing-aware operators. Maybe a singleton that supported no useful operations, not even __eq__ or __bool__, would be sufficiently inconvenient that it would only be used for defaults and "is" tests for said defaults. On Sun, Sep 27, 2020 at 10:52 PM Chris Angelico wrote: > English treats 1 as special and 0 as the same as other numbers when it > comes to singulars and plurals. [...] What do > other languages do in this way? > You were asking about natural languages but perhaps it's worth mentioning that Haskell has tuples of length 0, 2, 3, ..., but no tuples of length 1. Tuples are meant for putting n values where 1 value is expected, and when n=1 you just put the value there. On Mon, Sep 28, 2020 at 11:47 AM Stefano Borini wrote: > Also, it would give different behavior between d[x] and d[x, **kw], > which in my opinion should be a fully degenerate case. > On the other hand, it would make d[x,] and d[x, **kw] consistent, which they also ought to be. What a mess. ___ 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/XQ47DN75KKH5LECSBCGSCH5WVLKMYDIS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Regular Expression | re - Support String List Input Type List[str]
On 2020-09-28 at 23:10:24 -, Giang Le wrote: > I would like to propose an idea for the regular expression module > re.search(Pattern, Input) to support List[str] input type. > So it will return a matched object list if the input is a string > list. Otherwise, it will return a normal matched object, if the input > is a normal string How would that change be better than a new function: def regex_search_list(regex, pattern, list_of_inputs): [regex.search(pattern, input) for input in list_of_inputs] (or possibly an equivalent method of regexen)? ___ 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/QSOAHKIKTJMYEWT24L6NTYIXSFLPT5LP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Regular Expression | re - Support String List Input Type List[str]
Hi Everyone, I would like to propose an idea for the regular expression module re.search(Pattern, Input) to support List[str] input type. So it will return a matched object list if the input is a string list. Otherwise, it will return a normal matched object, if the input is a normal string Best Regards Giang ___ 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/4LOOP2FDK7JQ7XU3Z4Y7JNLOOW5FQOHH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On Mon, 28 Sep 2020 at 15:45, Eric Wieser wrote: > > Would another option be to just stop using the tuple-less index in the > presence of new syntax - so by example, I don't think it would be a reliable approach. Now you end up with a "randomly" occurring special case depending on how it's invoked. Also, it would give different behavior between d[x] and d[x, **kw], which in my opinion should be a fully degenerate case. -- Kind regards, Stefano Borini ___ 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/UJR4GMFJ2KHHBLKWIKP2JIU2PZUVJK6M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On 2020-09-28 06:51, Chris Angelico wrote:
On Mon, Sep 28, 2020 at 3:33 PM Christopher Barker wrote:
As for using an empty tuple, thanks Guido for laying out the logic so succinctly, and it
does make it pretty simple that only the one index case is special. Nevertheless, I think
most folks expect the special case to be at the end of the "series", not in the
middle -- i.e.
four is the same as three is the same as two, one is special, and zero is not
allowed.
rather than
four is the same as three is the same as two, one is special, and zero is the
same as two, three, four, ...
For that reason, I prefer a separate sentinel.
English treats 1 as special and 0 as the same as other numbers when it
comes to singulars and plurals. You talk about "an item", but "no
items" or "two items" or "three items". As you descend through the
numbers, four ("items") is the same as three ("items") is the same as
two ("items"), and one is special ("item"), and zero is back to the
normal case ("items").
I'm not saying that English should be the fundamental basis upon which
Python is designed, but at least there's some precedent :) What do
other languages do in this way? Are other human languages based around
the idea that zero matches others, or are there different ways to
write things?
Dutch is, of course, of particular interest here :)
Some languages have singular, dual, and plural.
Some languages use the singular if the number ends with 1, so "20
items", "21 item", "22 items".
I believe I read somewhere that some languages are OK with "found 2
files" and "found 1 file", but reject "found 0 files"; it has to be
"didn't find any files".
And some languages don't inflect for number at all.
___
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/TDTNTMDYNCRUAVKQKQV4DZBUWGKGJDPI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved Error Message for "Unhashable Type"
> The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash It's true, but I don't think it would be too hard to preserve some of the context in some of those common cases. In that bug report, I suggested adding an optional parameter for the format string used to generate the error message to PyObject_Hash and PyObject_HashNotImplemented (but I haven't yet tried to sketch out a full code change). That doesn't fully cover the case where hash calls hash recursively, and obviously we wouldn't want to handle that in a way that potentially mucks with the performance of hash functions. > do any existing built in error message have links in them? I don't think so, which is maybe a reason to avoid the inconsistency. I don't know whether that's the result of some intentional decision. I do think it can be useful to have more direct links to documentation, though. > at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there. I think that's reasonable. On Mon, Sep 28, 2020 at 11:41 AM Christopher Barker wrote: > On Mon, Sep 28, 2020 at 6:34 AM Samuel Freilich via Python-ideas < > python-ideas@python.org> wrote: > >> The message does not include: >> >> * The word "hashable" verbatim, which appears in the glossary >> > * A link to https://docs.python.org/3/glossary.html#term-hashable >> > > That's a pretty good entry that does talk about the importance of > hashability in dicts and sets. So making it easier to find might be enough > to help here. > > So +1 on adding that link to the error message (if, in fact, links in > error messages are on the table at all -- do any existing built in error > message have links in them? > > and/or at least add "unhashable" to the glossary -- after all, both > "mutable" and "immutable" are in there. > > -CHB > > > > > > > > > >> * A suggestion of what to do instead >> >> For example: >> TypeError: dict keys must be hashable ( >> https://docs.python.org/glossary.html#term-hashable), 'list' is not. >> Consider using a primitive type (e.g. int, str) or immutable sequence (e.g. >> tuple, frozenset). >> >> (That could be too much stuff, my point is I think there's room for >> improvement over "unhashable type: 'list'".) >> >> I filed a bug about this (https://bugs.python.org/issue41114), but it >> was closed by a core contributor, who suggested discussing that on this >> list instead. While it's true that you can Google the error message and >> find the relevant information, I think the error message text would be >> worth improving. >> >> Peace, >> -Sam >> ___ >> 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/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ 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/YVXEYKK5A76QTCNNSZP2DMSHPKBGFEYV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
https://github.com/python/cpython/blame/master/Lib/unittest/test/testmock/testwith.py#L16
On Mon, Sep 28, 2020 at 12:00 PM Wes Turner wrote:
> `my_dict = (json.load(f) with open(filename.json, "r") as f)`
>
> Would that be called a generator expression / comprehension context
> manager?
>
> https://docs.python.org/3/reference/datamodel.html#context-managers
>
> https://docs.python.org/3/library/contextlib.html
>
> PEP 343 added the "with" statement.
>
> Tests that would need to be extended / that may be useful references:
>
> https://github.com/python/cpython/blob/master/Lib/test/test_with.py
>
> https://github.com/python/cpython/blob/master/Lib/test/test_contextlib.py
>
>
> https://github.com/python/cpython/blob/master/Lib/test/test_contextlib_async.py
>
>
> https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py#L1701
> test_with_statement
>
>
> https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py#L1864
> test_async_with
>
> https://github.com/python/cpython/blob/master/Grammar/python.gram
>
> Would there be any new scope issues?
>
>
> On Mon, Sep 28, 2020, 11:12 AM Eric Wieser
> wrote:
>
>> This reminds me of a previous proposal I can't remember if I hit the list
>> with, allowing
>>
>> with open(filename.json, "r") as f:
>> my_dict = json.load(f)
>>
>> to be spelt as a single expression:
>>
>> my_dict = (json.load(f) with open(filename.json, "r") as f)
>>
>> Obviously this would be more useful in comprehensions, but it might
>> encourage people not to lazily write `json.load(open("filename.json",
>> "r"))` because they want an expression, and end up leaving files open.
>>
>> Eric
>> ___
>> 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/QR233SIBDHWDZLKWURUHXG37BDWJHA7Z/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
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/NA2J2YOYWXGNAUWHDWMD6TGDXMHIT5CX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
`my_dict = (json.load(f) with open(filename.json, "r") as f)`
Would that be called a generator expression / comprehension context manager?
https://docs.python.org/3/reference/datamodel.html#context-managers
https://docs.python.org/3/library/contextlib.html
PEP 343 added the "with" statement.
Tests that would need to be extended / that may be useful references:
https://github.com/python/cpython/blob/master/Lib/test/test_with.py
https://github.com/python/cpython/blob/master/Lib/test/test_contextlib.py
https://github.com/python/cpython/blob/master/Lib/test/test_contextlib_async.py
https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py#L1701
test_with_statement
https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py#L1864
test_async_with
https://github.com/python/cpython/blob/master/Grammar/python.gram
Would there be any new scope issues?
On Mon, Sep 28, 2020, 11:12 AM Eric Wieser
wrote:
> This reminds me of a previous proposal I can't remember if I hit the list
> with, allowing
>
> with open(filename.json, "r") as f:
> my_dict = json.load(f)
>
> to be spelt as a single expression:
>
> my_dict = (json.load(f) with open(filename.json, "r") as f)
>
> Obviously this would be more useful in comprehensions, but it might
> encourage people not to lazily write `json.load(open("filename.json",
> "r"))` because they want an expression, and end up leaving files open.
>
> Eric
> ___
> 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/QR233SIBDHWDZLKWURUHXG37BDWJHA7Z/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/22UA6LNX547HKZ66JJFWMLXUFY4CZ7YR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved Error Message for "Unhashable Type"
On Mon, Sep 28, 2020 at 6:34 AM Samuel Freilich via Python-ideas < python-ideas@python.org> wrote: > The message does not include: > > * The word "hashable" verbatim, which appears in the glossary > * A link to https://docs.python.org/3/glossary.html#term-hashable > That's a pretty good entry that does talk about the importance of hashability in dicts and sets. So making it easier to find might be enough to help here. So +1 on adding that link to the error message (if, in fact, links in error messages are on the table at all -- do any existing built in error message have links in them? and/or at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there. -CHB > * A suggestion of what to do instead > > For example: > TypeError: dict keys must be hashable ( > https://docs.python.org/glossary.html#term-hashable), 'list' is not. > Consider using a primitive type (e.g. int, str) or immutable sequence (e.g. > tuple, frozenset). > > (That could be too much stuff, my point is I think there's room for > improvement over "unhashable type: 'list'".) > > I filed a bug about this (https://bugs.python.org/issue41114), but it was > closed by a core contributor, who suggested discussing that on this list > instead. While it's true that you can Google the error message and find the > relevant information, I think the error message text would be worth > improving. > > Peace, > -Sam > ___ > 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/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/NNYGJBU7QOCKWOU3LLQPOG4CKGETTGSO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
This reminds me of a previous proposal I can't remember if I hit the list with,
allowing
with open(filename.json, "r") as f:
my_dict = json.load(f)
to be spelt as a single expression:
my_dict = (json.load(f) with open(filename.json, "r") as f)
Obviously this would be more useful in comprehensions, but it might encourage
people not to lazily write `json.load(open("filename.json", "r"))` because they
want an expression, and end up leaving files open.
Eric
___
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/QR233SIBDHWDZLKWURUHXG37BDWJHA7Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding mixed positional and keyword to PEP 637
I can offer another example where the new syntax is likely to be of use to numpy. We currently have the following as synonyms: ``` np.copyto(a, b, casting='unsafe') a[...] = b ``` Obviously, it would be nice if we could allow other casting rules for `[]` assignment: ``` np.copyto(a, b, casting='safe') a[..., casting='safe'] = b ``` Eric ___ 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/KO2EM52NWS2SGW45WROO45JG43XHZW6S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved Error Message for "Unhashable Type"
28.09.20 16:31, Samuel Freilich via Python-ideas пише:
> The error message for using a mutable sequence as a set item or map key
> seems to frequently confuse Python beginners. The current wording is:
>
{[1, 2, 3]: [4, 5, 6]}
> TypeError: unhashable type: 'list'
>
> The first thing a Google search finds for "unhashable type" is ~4k Stack
> Overflow results like:
> https://stackoverflow.com/questions/13264511/typeerror-unhashable-type-dict
>
> The message does not include:
> * The type on which the operation is performed
> * Which input to the operation is the problem
> * The word "hashable" verbatim, which appears in the glossary
> * A link to https://docs.python.org/3/glossary.html#term-hashable
> * A suggestion of what to do instead
>
> For example:
> TypeError: dict keys must be hashable
> (https://docs.python.org/glossary.html#term-hashable), 'list' is not.
> Consider using a primitive type (e.g. int, str) or immutable sequence
> (e.g. tuple, frozenset).
>
> (That could be too much stuff, my point is I think there's room for
> improvement over "unhashable type: 'list'".)
The code which raises TypeError does not know whether it was called
internally by dict or set method or explicitly by hash(). So neither the
type of container, nor operation are known. And it may be raised when
the key is a tuple which contains a list, that contradicts the proposed
error message.
___
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/7EVB4OKTTL6AQN2MAVNQLV3RJHE2IAI5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
Would another option be to just stop using the tuple-less index in the presence
of new syntax - so by example,
```
SYNTAXINDEX KWARGS
d[*[]]() {}
d[*[],] () {}
d[**{}] () {}
d[**{},] () {}
d[foo=1] () {'foo': 1}
d[foo=1,] () {'foo': 1}
d[x] x {} (valid existing syntax)
d[x,] (x,) {} (valid existing syntax)
d[x, *[]] (x,) {}
d[x, *[],](x,) {}
d[x, **{}](x,) {}
d[x, **{},] (x,) {}
d[x, foo=1] (x,) {'foo': 1}
d[x, foo=1,] (x,) {'foo': 1}
```
Essentially, the rules are:
* Does the indexing contain any of the new syntax proposed in this PEP (`*`,
`**`, or explicit kwarg)? If yes:
* Always pass a tuple as the index. This is new-style indexing, lets leave
behind the weird corner cases. `()` is a natural choice of singleton.
* If no:
* Use the existing rule of parsing the contents of `[]` as a tuple
The one downside of this approach is that perfect forwarding of `__getitem__`
requires a small dance
```
def __getitem__(self, args, **kwargs):
if not type(args) is tuple and not kwargs:
# this is pre-PEP-637 indexing
return self._wrapped[args]
else:
# the presence of `*` or `**` is enough to force PEP-637 indexing, even
# if those are empty
return self._wrapped[*args, **kwargs]
```
This would only come up in new code though - any forwarding `__getitem__`
without `**kwargs` would already be written correctly.
I'd argue it would be sufficient to note this a usage note in the PEP.
Eric
___
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/ZGPKU3EGXH72OGNGSBJO26ITHOREBGJ4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Improved Error Message for "Unhashable Type"
The error message for using a mutable sequence as a set item or map key
seems to frequently confuse Python beginners. The current wording is:
>>> {[1, 2, 3]: [4, 5, 6]}
TypeError: unhashable type: 'list'
The first thing a Google search finds for "unhashable type" is ~4k Stack
Overflow results like:
https://stackoverflow.com/questions/13264511/typeerror-unhashable-type-dict
The message does not include:
* The type on which the operation is performed
* Which input to the operation is the problem
* The word "hashable" verbatim, which appears in the glossary
* A link to https://docs.python.org/3/glossary.html#term-hashable
* A suggestion of what to do instead
For example:
TypeError: dict keys must be hashable (
https://docs.python.org/glossary.html#term-hashable), 'list' is not.
Consider using a primitive type (e.g. int, str) or immutable sequence (e.g.
tuple, frozenset).
(That could be too much stuff, my point is I think there's room for
improvement over "unhashable type: 'list'".)
I filed a bug about this (https://bugs.python.org/issue41114), but it was
closed by a core contributor, who suggested discussing that on this list
instead. While it's true that you can Google the error message and find the
relevant information, I think the error message text would be worth
improving.
Peace,
-Sam
___
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/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/
Code of Conduct: http://python.org/psf/codeofconduct/
