Comment by bmh100 | Hacker News Reader

Comment by bmh100 | Hacker News Reader

Parent Full thread

You gain access to continued language support in 2020. New features involving strings will have less risk of bugs. The "range" function is more memory efficient. Integer division automatically floors, reducing bug risk. Dictionaries with guaranteed ordering. Thousands separator in string formatting. Bit length on integers. Combinations with replacement on itertools. New, faster I/O library and faster json. Concurrent futures module. Ability to define stable ABI for extensions. New CLI option parsing module. Dictionary-based logging configuration. Index and count on ranges. Barrier synchronization for threads. Faster sorting via internal upgrade to Timsort. Async I/O. Support for spawn and forkserver in multiprocessing. Child context in multuprocessing. Has collision cost reduced. Significantly faster startup. Type hints. Faster directory traversal. Faster regular expression parsing. Faster I/O for bytes. Faster dumps. Reduced method memory usage through better caching. Dramatically less memory usage by random. Faster string manipulation. Faster propert calls. Formatted string literals (interpolated strings). Asynchronous generators. Asynchronous comprehensions.

How much faster might your code run just by upgrading to Python 3? How much memory might you save?

> Dictionaries with guaranteed ordering.

I don't think you're suppose to depend on the ordering of dictionaries. It's an implementation detail which might get changed, although it wont actually ever be changed because people will come to depend on it.

I'm specifically referring to OrderedDict in this case, which does have guaranteed, insertion-based ordering. It was introduced in 3.1, circa 2009, via PEP 372.

https://docs.python.org/2/library/collections.html#ordereddi...

> New in version 2.7.

That's a good point. I didn't realize that it was also introduced into 2.7 at the same time.

> I don't think you're suppose to depend on the ordering of dictionaries. It's an implementation detail which might get changed, although it wont actually ever be changed because people will come to depend on it.

I came here to make the same distinction - though I will say I hope you are wrong about people coming to depend on it when OrdereredDict is still there for a reason. The docs still plainly state that Dict should be considered un-ordered and do not make mention of this implementation detail (nor should they).

You forgot functools.lru_cache. I've found in some Python 2.7 projects you can speed things up with a hacky dictionary-cache, but the proper functools.lru_cache gives better results and is far more flexible.

Like many database-backed apps performance is currently limited by I/O, and memory is limited based on the size of the data sets I load (machine learning). A faster, lower memory Python does sound nice but I'm not sure how much effect it would actually have in real life.

Reply on news.ycombinator.com