On Sun, Dec 15, 2019 at 09:00:31PM -0800, Larry Hastings wrote:
> I think we should decide the question "should set
> objects maintain insertion order?" literally without any consideration
> about performance implications.
In your opening post:
> I also want FAST lookup because I soemtimes rem
On 12/17/19 2:02 AM, Steven D'Aprano wrote:
Without being facetious[1] if you don't care about performance, you
don't need a set, you could use a list.
Lists don't enforce uniqueness. Apart from that a list would probably
work fine for my needs; in my admittedly-modest workloads I would
pr
On Tue, 17 Dec 2019 at 11:13, Larry Hastings wrote:
> I lack this strongly mathematical view of sets others have espoused; instead
> I view them more like "dicts without values". I'm therefore disgruntled by
> this inconsistency between what are I see as closely related data structures,
> and
On Tue, 17 Dec 2019 at 11:48, Paul Moore wrote:
> On Tue, 17 Dec 2019 at 11:13, Larry Hastings wrote:
> > I lack this strongly mathematical view of sets others have espoused;
> instead I view them more like "dicts without values". I'm therefore
> disgruntled by this inconsistency between what a
17.12.19 14:05, Ivan Levkivskyi пише:
As a random data point, I often see the pattern where one needs to
remove duplicates
from the list while preserving the order of first appearance.
This is for example needed to get stability in various type-checking
situations (like union items, type variab
...
[Larry]
>> One prominent Python core developer** wanted this feature for years, and I
>> recall
>> them saying something like:
>>
>> Guido says, "When a programmer iterates over a dictionary and they see the
>> keys
>> shift around when the dictionary changes, they learn something!" To that
[Larry]
> "I don't care about performance" is not because I'm aching for Python to
> run my code slowly. It's because I'm 100% confident that the Python
> community will lovingly optimize the implementation.
I'm not ;-)
> So when I have my language designer hat on, I really don't concern myself
We ran into an issue where having the SQLite library built with
-DSQLITE_THREADSAFE=0,
but then the sqlite3 module (really, the _sqlite3.so0 crashing in threading
code. So I have
to ask if it is intended that the sqlite3 Python module always be built with a
thread safe
SQLite library.
Thanks
On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom
wrote:
> We ran into an issue where having the SQLite library built with
> -DSQLITE_THREADSAFE=0,
> but then the sqlite3 module (really, the _sqlite3.so0 crashing in
> threading code. So I have
> to ask if it is intended that the sqlite3 Python mo
