On Sat, Aug 01, 2020 at 02:08:08PM +1000, Chris Angelico wrote:
> On Sat, Aug 1, 2020 at 1:43 PM Steven D'Aprano wrote:
> > Some years ago, someone (I think it was Nick Coghlan?) proposed a
> > standard solution for this issue, a context manager + decorator function
> > that guarded against a
On Sat, Aug 1, 2020 at 1:43 PM Steven D'Aprano wrote:
> Some years ago, someone (I think it was Nick Coghlan?) proposed a
> standard solution for this issue, a context manager + decorator function
> that guarded against a specific exception. Nothing much came of it, but
> I did experiment with
On Fri, Jul 31, 2020 at 10:59 PM Steven D'Aprano
wrote:
> [...]
The first request in this thread was from Hans:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/
>
> He is using a dict to hold an array of columns indexed by name
>
On Fri, Jul 31, 2020 at 08:08:58PM -0700, Guido van Rossum wrote:
> > The other simple solution is `next(iter(mydict.items()))`.
> >
>
> That one always makes me uncomfortable, because the StopIteration it raises
> when the dict is empty might be misinterpreted. Basically I never want to
> call
On Fri, Jul 31, 2020 at 04:30:22PM -0700, Guido van Rossum wrote:
> > So:
> > dicts preserve order
> > the dict_views preserve this same order
> >
> > Some think that we can't call them "ordered", because somehow that implies
> > other things, like the ability to insert, etc, but while I don't
On Fri, Jul 31, 2020 at 7:59 PM Steven D'Aprano wrote:
> On Fri, Jul 31, 2020 at 04:08:43PM -0700, Guido van Rossum wrote:
> [...]
> > I'm guessing that indexing by 0, if it were possible, would be a
> convenient
> > idiom to implement the "first item" operation that has been requested
> >
On Fri, Jul 31, 2020 at 04:08:43PM -0700, Guido van Rossum wrote:
> Maybe it is common in numpy and pandas to keep adding operations to the
> same object until it breaks, but the key and items views already implement
> the Set ABC, and I'd rather refrain from having them *also* implement the
>
On Sat, Aug 1, 2020 at 10:19 AM Wes Turner wrote:
>
> We should be reading the source:
> https://github.com/python/cpython/blob/master/Objects/dictobject.c
>
> AFAIU, direct subscripting / addressing was not a use case in the design
> phase of the current dict?
>
> Could a
On Sat, Aug 1, 2020 at 8:14 AM Christopher Barker wrote:
>
>
> If that's all we've come up with in this lengthy thread, it's probably not
> worth it -- after all, both of those can be efficiently accomplished with a
> little help from itertools.islice and/or next().
>
100% agree.
> But I
We should be reading the source:
https://github.com/python/cpython/blob/master/Objects/dictobject.c
AFAIU, direct subscripting / addressing was not a use case in the design
phase of the current dict?
Could a __getitem__(slice_or_int_index) be implemented which just skips
over the NULLs?
Or would
On Sat, Aug 1, 2020 at 10:04 AM Wes Turner wrote:
>
> Actually, I think the reverse traversal case is the worst case because: it's
> not possible to use negative subscripts with islice (because that would
> require making a full copy).
>
> This doesn't work:
> >>> islice(dict.keys(), -1, -5)
>
Ok... I wrong. The array of items have a NULL key and value if one item is
deleted. Sorry for the confusion.
On Sat, 1 Aug 2020 at 01:09, Guido van Rossum wrote:
> the key and items views already implement the Set ABC, and I'd rather
> refrain from having them *also* implement the Sequence ABC.
On Sat, Aug 1, 2020 at 9:55 AM Marco Sulla wrote:
>
> On Sat, 1 Aug 2020 at 02:30, Stestagg wrote:
>>
>> The dict keys is compact only *until* you delete an item, at which point, a
>> hole is left in the array
>
> No, the array of items has no hole. The hole is inserted in the hashtable.
Yes,
Actually, I think the reverse traversal case is the worst case because:
it's not possible to use negative subscripts with islice (because that
would require making a full copy).
This doesn't work:
>>> islice(dict.keys(), -1, -5)
Reverse traversal did work in Python 2 but was foregone when making
On Fri, Jul 31, 2020 at 8:44 PM Guido van Rossum wrote:
> This is not great news. A solution could be to make dict.ordered() force
> compaction -- if there are no deleted keys this would be a no-op. We'd have
> to be able to tell in constant time whether this is the case. But yeah,
> this would
On Sat, 1 Aug 2020 at 02:30, Stestagg wrote:
> The dict keys is compact only *until* you delete an item, at which point,
> a hole is left in the array
>
No, the array of items has no hole. The hole is inserted in the hashtable.
___
Python-ideas
This is not great news. A solution could be to make dict.ordered() force
compaction -- if there are no deleted keys this would be a no-op. We'd have
to be able to tell in constant time whether this is the case. But yeah,
this would be a dangerous thing in the hands of folks below wizard level.
On Sat, 1 Aug 2020 at 00:32, Guido van Rossum wrote:
> If true this would be a huge argument against adding indexing and slicing
> (other than the special case starting with 0). However, I don't think it's
> true. The dict implementation (again, starting in 3.6) actually stores the
> list of
On Fri, Jul 31, 2020 at 4:12 PM Christopher Barker
wrote:
> On Fri, Jul 31, 2020 at 2:56 PM Marco Sulla
> wrote:
>
>> Yes. Since now dicts are ordered by insertion, also keys, values and
>> items are ordered the same way.
>>
>
> Preservation of oider was codified in version 3.7 (? at some
On Fri, Jul 31, 2020 at 2:56 PM Marco Sulla
wrote:
> Yes. Since now dicts are ordered by insertion, also keys, values and items
> are ordered the same way.
>
Preservation of oider was codified in version 3.7 (? at some point,
anyway). And while it may not explicitly say that the views will
On Fri, Jul 31, 2020 at 2:56 PM Marco Sulla
wrote:
> On Fri, 31 Jul 2020 at 22:14, Chris Angelico wrote:
>
>> So, constructing a tuple or list from the keys or items WILL give you a
>> sequence.
>>
>
> Yes. Since now dicts are ordered by insertion, also keys, values and items
> are ordered the
On Fri, 31 Jul 2020 at 22:14, Chris Angelico wrote:
> So, constructing a tuple or list from the keys or items WILL give you a
> sequence.
>
Yes. Since now dicts are ordered by insertion, also keys, values and items
are ordered the same way.
It seems to me more simple to add some sequence
On Sat, Aug 1, 2020 at 6:07 AM Ricky Teachey wrote:
>
> On Fri, Jul 31, 2020 at 3:52 PM Marco Sulla
> wrote:
>>
>> Is it not more simple to add some sequence methods to the dict views (if
>> there's a real need)?
>> If you do tuple(dict.keys()), you get the sequence of keys in the same
>>
On Fri, Jul 31, 2020 at 3:52 PM Marco Sulla
wrote:
> Is it not more simple to add some sequence methods to the dict views (if
> there's a real need)?
> If you do tuple(dict.keys()), you get the sequence of keys in the same
> insertion order of the dict. It seems to me that the duck already
On Thu, 30 Jul 2020 at 12:57, Vinay Sharma via Python-ideas <
python-ideas@python.org> wrote:
> Python has support for atomic types, I guess:
> Atomic Int:
> https://github.com/python/cpython/blob/master/Include/internal/pycore_atomic.h#L80
> Atomic Store:
>
Is it not more simple to add some sequence methods to the dict views (if
there's a real need)?
If you do tuple(dict.keys()), you get the sequence of keys in the same
insertion order of the dict. It seems to me that the duck already exists
and quacks.
___
> keyseq(), valueseq(), itemseq()
Yeah, that's a good one
On Fri, Jul 31, 2020, 12:18 PM Ricky Teachey wrote:
> On Fri, Jul 31, 2020 at 11:55 AM Wes Turner wrote:
>
>> +1 on (lazy) Sequence views optimized for sequential reads and random
>> access (which hide the dict implementation which
On Fri, Jul 31, 2020 at 11:55 AM Wes Turner wrote:
> +1 on (lazy) Sequence views optimized for sequential reads and random
> access (which hide the dict implementation which varies across which
> platforms?)
>
> I'm somewhat indifferent on the name:
>
> # Sequence views names:
> ## method() ->
+1 on (lazy) Sequence views optimized for sequential reads and random
access (which hide the dict implementation which varies across which
platforms?)
I'm somewhat indifferent on the name:
# Sequence views names:
## method() -> Sequence
- orderedkeys(), orderedvalues(), ordereditems()
- okeys(),
On Fri, Jul 31, 2020 at 10:31 AM Guido van Rossum wrote:
> So maybe we need to add dict.ordered() which returns a view on the items
> that is a Sequence rather than a set? Or ordereditems(), orderedkeys() and
> orderedvalues()?
>
>
I for one would be +1 on this idea.
On the bike shed hew:
So maybe we need to add dict.ordered() which returns a view on the items
that is a Sequence rather than a set? Or ordereditems(), orderedkeys() and
orderedvalues()?
On Fri, Jul 31, 2020 at 05:29 Ricky Teachey wrote:
> On Fri, Jul 31, 2020, 2:48 AM Wes Turner wrote:
>
>> # Dicts and DataFrames
On Fri, Jul 31, 2020, 2:48 AM Wes Turner wrote:
> # Dicts and DataFrames
> - Src:
> https://github.com/westurner/pythondictsanddataframes/blob/master/dicts_and_dataframes.ipynb
> - Binder:
> https://mybinder.org/v2/gh/westurner/pythondictsanddataframes/master?filepath=dicts_and_dataframes.ipynb
I think you are talking about shared/named semaphores. The problem with them is
that python doesn’t have support for shared semaphores, so the first step would
be to build an API providing access to shared semaphores, and then this API can
be used to synchronise shared memory.
> On
# Dicts and DataFrames
- Src:
https://github.com/westurner/pythondictsanddataframes/blob/master/dicts_and_dataframes.ipynb
- Binder:
https://mybinder.org/v2/gh/westurner/pythondictsanddataframes/master?filepath=dicts_and_dataframes.ipynb
- (interactive Jupyter Notebook hosted by
34 matches
Mail list logo
