On Mon, Jun 29, 2020 at 21:30 MRAB wrote:
> On 2020-06-30 02:14, Steven D'Aprano wrote:
> [snip]
> > Counter-proposal: hex escapes allow optional curly brackets, similar to
> > unicode name escapes. You could even allow spaces within the braces, for
> > grouping:
> >
> > # Existing:
> >
Is there any reason why collections.abc.[Sequence|MutableSequence] do
not have "__eq__" for free?
I was writing some tests now and was caught by surprise there.
(chcking the docs, if my custom MutbaleSequence also
inherits from "collections.abc.Set" I will have working "__eq__" - and
"__ne__", me
>
>
> But we're not talking about *dict*, we're talking about dict.items which
> returns a set-like object:
>
> py> from collections.abc import Set
> py> isinstance({}.items(), Set)
> True
>
> So dict.items isn't subscriptable because it's an unordered set, not a
> sequence.
Or is it
Brett Cannon wrote:
> It's a discussion issue. PEP 554 is trying to focus on the API of
> subinterpreters and doesn't want to distract from that by bringing the GIL
> into it.
> That being said, the general expectation from everyone involved is there
> will be a perl-interpreter GIL.
> On Sat, Jun
On Mon, Jun 29, 2020 at 11:02:54PM -0700, Christopher Barker wrote:
> > So dict.items isn't subscriptable because it's an unordered set, not a
> > sequence.
>
>
> Or is it a set because it can’t be indexed? If I have the history right,
> dict.items was first implemented with the “old” dict imple
Hi
A quick collection of responses:
But we're not talking about *dict*, we're talking about dict.items which
> returns a set-like object:
>
> py> from collections.abc import Set
> py> isinstance({}.items(), Set)
> True
>
>
This property is nice, as .keys() (for example) can operate l
I don't recall why this was done. It seems somewhat odd, since Set and
Mapping in the same module do have __eq__. I don't care much for the
default implementation though.
(I don't understand why you would want to inherit from both Sequence and
Set -- and certainly the resulting mongrel type would
On Tue, Jun 30, 2020 at 2:28 PM MRAB wrote:
>
> On 2020-06-30 02:14, Steven D'Aprano wrote:
> [snip]
> > Counter-proposal: hex escapes allow optional curly brackets, similar to
> > unicode name escapes. You could even allow spaces within the braces, for
> > grouping:
> >
> > # Existing:
> >
On 2020-06-30 13:25, Chris Angelico wrote:
On Tue, Jun 30, 2020 at 2:28 PM MRAB wrote:
On 2020-06-30 02:14, Steven D'Aprano wrote:
[snip]
> Counter-proposal: hex escapes allow optional curly brackets, similar to
> unicode name escapes. You could even allow spaces within the braces, for
> group
On Tue, 30 Jun 2020 at 11:57, Guido van Rossum wrote:
> I don't recall why this was done. It seems somewhat odd, since Set and
> Mapping in the same module do have __eq__. I don't care much for the
> default implementation though.
>
> (I don't understand why you would want to inherit from both Se
On Wed, Jul 1, 2020 at 1:57 AM MRAB wrote:
>
> On 2020-06-30 13:25, Chris Angelico wrote:
> > On Tue, Jun 30, 2020 at 2:28 PM MRAB wrote:
> >>
> >> On 2020-06-30 02:14, Steven D'Aprano wrote:
> >> [snip]
> >> > Counter-proposal: hex escapes allow optional curly brackets, similar to
> >> > unicode
On 2020-06-30 17:20, Chris Angelico wrote:
On Wed, Jul 1, 2020 at 1:57 AM MRAB wrote:
On 2020-06-30 13:25, Chris Angelico wrote:
> On Tue, Jun 30, 2020 at 2:28 PM MRAB wrote:
>>
>> On 2020-06-30 02:14, Steven D'Aprano wrote:
>> [snip]
>> > Counter-proposal: hex escapes allow optional curly br
On Tue, Jun 30, 2020 at 5:35 AM Steven D'Aprano wrote:
> On Mon, Jun 29, 2020 at 11:02:54PM -0700, Christopher Barker wrote:
>
> > Or is it a set because it can’t be indexed? If I have the history right,
> > dict.items was first implemented with the “old” dict implementation,
> which
> > did no
On Tue, Jun 30, 2020 at 5:05 AM Steven D'Aprano wrote:
> For single-character escape codes, I see no benefit at all to this, only
> disadvantages. However I do see a tiny potential benefit to hex escapes,
> for the rare occassions that they are immediately followed by something
> that looks like
On 30/06/2020 04:08, Steven D'Aprano wrote:
We can write
inefficient code because dicts do *not* support index access:
for i in range(len(d)):
for j,item in enumerate(d.items()):
if j == i:
do(item)
We certainly can. The above is no different (apar
On 30/06/2020 18:31, Christopher Barker wrote:
The first improvement on that was the iter* methods, and then (inspired by
JAVA) it was determined that we could have view objects that could provide
efficient iterators, and also set-like behavior. But I don't see any
comments in the PEP about why i
I think I'm missing something. Daniel wants a `list.get` method with
similar semantics to `dict.get`. So instead of writing:
```
try:
x = lst[i]
except IndexError:
x = default
```
one could write `x = lst.get(i, default)`. How would you rewrite that with
PEP 505?
I've also wanted this a
On Tue, Jun 30, 2020 at 5:26 AM wrote:
> Brett Cannon wrote:
> > It's a discussion issue. PEP 554 is trying to focus on the API of
> > subinterpreters and doesn't want to distract from that by bringing the
> GIL
> > into it.
> > That being said, the general expectation from everyone involved is t
Hello!
Which would be the use cases for this feature?
I can't think of one.
I think that "nice to have" leads to the ways of Perl.
Regards,
On Sat, Jun 27, 2020 at 9:34 AM Daniel. wrote:
> When I need to traverse nested dicts, is a common pattern to do
>
> somedict.get('foo', {}).get('bar',
I just want to make clear that safe navegator is enough to deal with this.
Now that this is clear, the use case is almost always the same. I received
some json as response and want to extract a nested value.
The way I'm doing this today is overloading an infix operator (I'm using
>>) to emulate s
On 2020-06-30 23:26, Daniel. wrote:
I just want to make clear that safe navegator is enough to deal with this.
Now that this is clear, the use case is almost always the same. I
received some json as response and want to extract a nested value.
The way I'm doing this today is overloading an in
toolz.get_in is designed for exactly this.
https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.get_in
The whole library is great!
Alex
On Wed, 1 Jul 2020 at 8:03 am, MRAB wrote:
> On 2020-06-30 23:26, Daniel. wrote:
> > I just want to make clear that safe navegator is enough to de
On Tue, Jun 30, 2020 at 09:04:15PM +0300, Mikhail V wrote:
> > Counter-proposal: hex escapes allow optional curly brackets, similar to
> > unicode name escapes. You could even allow spaces within the braces, for
> > grouping:
> >
> > # Proposed enhancement:
> > "\x{2b}2c" # '+2c'
> >
On Tue, Jun 30, 2020 at 10:25:45PM +1000, Chris Angelico wrote:
> Be careful of semantics here. I'm not sure which languages do what,
> but I just checked Perl, and "\x{1234}" is equivalent to Python's
> "\u1234", not to "\x12\x34". This proposal is for the latter, which
> could be sneakily confus
Very similar things could be said about dict.get too, no? It's easy to
write your own function that does the same thing or to catch an
exception.
On the other hand, it seems far more likely to miss keys in a dictionary
than it is to repeatedly mistake indices in a list.
> Which would be the us
On Tue, Jun 30, 2020 at 8:55 PM David Lowry-Duda
wrote:
> On the other hand, it seems far more likely to miss keys in a dictionary
> than it is to repeatedly mistake indices in a list.
>
exactly -- dict keys are arbitrary, and it's pretty common to store
"sparse" data by simply leaving out the k
On Tue, Jun 30, 2020 at 11:55 AM Rhodri James wrote:
> On 30/06/2020 18:31, Christopher Barker wrote:
> > The first improvement on that was the iter* methods, and then (inspired
> by
> > JAVA) it was determined that we could have view objects that could
> provide
> > efficient iterators, and also
On Tue, Jun 30, 2020, at 10:57, Guido van Rossum wrote:
> I don't recall why this was done. It seems somewhat odd, since Set and
> Mapping in the same module do have __eq__. I don't care much for the
> default implementation though.
> >
> > Anyway, maybe there is a reason it is not a given. Any
This will be helpful for python linters, own data types, etc.
Example:
class SQL_String(str):
@property
def __chr__(self): # SQL_string.__chr__ will return string that need to
be before string start
return 's'
def __check__(self): # This method will be called by intep
29 matches
Mail list logo
