(original) (raw)

On Mon, Sep 12, 2016 at 10:25 AM INADA Naoki <songofacandy@gmail.com> wrote:

So fundamental question is: Is it to so bad thing that some people
write code depending on CPython and PyPy implementation?

Yes. See below.

I think cross-interpreter libraries can use OrederedDict correctly
when they should use it. (They may run test on micropython, Jython and IronPython).

The problem is that libraries which could otherwise be cross-VM compatible are not because they depend upon an implementation detail. So it becomes an additional porting burden on people trying to use the library on another VM that could've been avoided if we required people to be explicit about their needs.

BUT...

At this point I think coding up an example patch against beta1 offering a choice of disordered iteration capability that does not increase memory or iteration overhead in any significant way is needed.

The problem is... I don't know how to express this as an API. Which sinks my whole though process and tables the idea.

A parameter to .items(), .keys() and .values() is undesirable as it isn't backwards compatible \[meaning it'll never be used\] and .keys() needs to match \_\_iter\_\_ which can't have one anyways. A parameter on dict construction is similarly infeasible.

Requiring the use of an orderdict like type in order to get the behavior is undesirable. Effectively I'm asking for some boolean state in each dict as to if it should iterate in order or not and a way to expose that to pure Python code in a way that namespace dicts iterate in order by default and others do not unless explicitly configured to do so.

oh well. end thought process on my end. it was good while it lasted.

Thanks for the compact and ordered dicts! People will love them. :)

-gps