Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating to Python 3 with pleasure

github.com

Post reply on HN
Print view View original

111–120 of 181 posts

Re: Migrating to Python 3 with pleasure

#111

Post by PeterisP »

ridiculous_fish wrote: post #49
StavrosK wrote: post #28

Earlier quoted context omitted.

I think that's a habit you need to shake. If something is undefined, you should intuitively shy away from expecting things from it. If I found myself wondering why some undefined behavior was not consistent, I'd question why I even believed it should be consistent in the first place.

Would you expect that `str(some_dict) == str(some_dict)`?

For that exact line I might expect that the result is true but still consider that line as "smelly" and meaningless, since dict equality cannot be compared by comparing their string representation.

I'd expect that any two ways of forming a dict with exactly same contents can result in different str(x) representation, and also that serializing and deserializing a dict can result in a different string representation.

Re: Migrating to Python 3 with pleasure

#112

Post by StavrosK »

eesmith wrote: post #110
StavrosK wrote: post #108

Earlier quoted context omitted.

No, of course not. Some order has to be applied to serialize it to a string, but that order is not defined between calls.

Python long ago made the guarantee that: > Keys and values are iterated over in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary’s history of insertions and deletions. If keys, values and items views are iterated over with no intervening modifications to the dictionary, the order of items will directly correspond. That is, the order will be maintained between…

A section called "CPython implementation detail" looks like the very antithesis of a guarantee, to me.

Re: Migrating to Python 3 with pleasure

#113

Post by eesmith »

StavrosK wrote: post #112
eesmith wrote: post #110

Earlier quoted context omitted.

Python long ago made the guarantee that: > Keys and values are iterated over in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary’s history of insertions and deletions. If keys, values and items views are iterated over with no intervening modifications to the dictionary, the order of items will directly correspond. That is, the order will be maintained between…

A section called "CPython implementation detail" looks like the very antithesis of a guarantee, to me.

My apologies. I looked for the answer I knew was there, and quoted the wrong section because it matched what I was looking for.

I should have quoted the next section:

> If items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond.

Curiously, the "Dictionary view objects" section at https://docs.python.org/2.7/library/stdtypes.html#dictionary... has the same "Keys and values are iterated over in an arbitrary order which is non-random ..." text, but without being inside of a "CPython implementation detail" box.

Re: Migrating to Python 3 with pleasure

#114

Post by cup-of-tea »

AlexCoventry wrote: post #8

I've moved to python 3 over the past couple of months, after resisting for the better part of a decade. I like it. One surprising thing I learned from this document is that dicts now iterate in assignment order, not hash order. That's going to break some code for people.

This is why you read the documentation rather than relying on what a piece of library code appears to do. Maybe all programmers have to learn this the hard way.

Re: Migrating to Python 3 with pleasure

#115

Post by cup-of-tea »

It's so strange to me that data scientists would need to be convinced to move to Python 3. It's superior in every way to legacy Python. I can understand maintaing Python 3 compatbility for legacy systems if you don't want to have Python 3 as a dependancy, but data scientists will be writing mostly ad hoc code and using Jupyter notebooks. The people around me are not allowed to use Python 2, in fact they're generally required to use the latest version of Python 3.

For anyone having trouble with maintaing multiple Python versions, I recommend Pyenv. You can install multiple local versions and switch between them. The selected version then uses the standard commands "python" and "pip", etc. which you can use to make your virtualenv from.

Re: Migrating to Python 3 with pleasure

#116

Post by fyi1183 »

djrobstep wrote: post #79
amyjess wrote: post #64

Earlier quoted context omitted.

> Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. Here's one real-life use case of that: Avro records. One of the formats Avro uses is a text format that's basically ordered JSON. One company I worked for years ago used Avro as its wire protocol, and some Avro data was stored as JSO…

Great example. I hate to think of all the developer hours wasted because JSON doesn't maintain key ordering.

Not to mention the lost opportunities for delta compression.

Re: Migrating to Python 3 with pleasure

#117

Post by latte »

metaobject wrote: post #20
jstimpfle wrote: post #11

Earlier quoted context omitted.

> test_path = datasets_root / dataset / 'test' > Previously it was always tempting to use string concatenation (concise, but obviously bad), now with pathlib the code is safe, concise, and readable. This is the kind of feature that I'm wary to use even in scripts: questionable benefit, and probably too clever.

I don't have a machine available right now, but I wonder what happens if two adjacent path elements are integers? Does it perform division instead of path/string concatenation?

You can't concatenate a path with an integer:

  >>> Path.cwd() / 1
  TypeError: argument should be a path or str object, not
Also, note that the '/' operator is left-associative, so even if you have two adjacent numbers when joining paths, there will be no division.

Re: Migrating to Python 3 with pleasure

#118

Post by jstimpfle »

sametmax wrote: post #96
jstimpfle wrote: post #11

Earlier quoted context omitted.

> test_path = datasets_root / dataset / 'test' > Previously it was always tempting to use string concatenation (concise, but obviously bad), now with pathlib the code is safe, concise, and readable. This is the kind of feature that I'm wary to use even in scripts: questionable benefit, and probably too clever.

Benefit is huge: it's readable, easy to type, and takes care of joining with proper "/" or "\" depending of the plateform.

I'll challenge you: You shouldn't have many paths, should keep them at a centralized location in the code, and there you could just use a normal function with a proper self-documenting name.

It's not like programs consist of path operations to a significant degree, so using fancy syntactic sugar doesn't seem like a worthwhile optimization to me. At all.

Re: Migrating to Python 3 with pleasure

#119

Post by lozenge »

dbcurtis wrote: post #73
thijsvandien wrote: post #22

Earlier quoted context omitted.

It was recently decided that as of 3.7 it will be. (Source: https://mail.python.org/pipermail/python-dev/2017-December/1... )

Hmmmmmm.... that makes it hard for other implementations. CPython isn't the whole of the Python world. Requirements like that can be problematic for implementations like Micropython, for instance.

I suspect the reasoning was with CPython dominating, people would eventually make this assumption in their code, perhaps unintentionally, and reduce compatibility. Better to make it official.

Re: Migrating to Python 3 with pleasure

#120

Post by Doxin »

orf wrote: post #42
est wrote: post #39

Earlier quoted context omitted.

return {**old, 'foo': 'bar'} # Old way return dict(old, foo='bar') Not much difference if you ask me.

It's twice as slow, doesn't work with more than one dictionary, you can't easily control the merge prescience and you can't (easily) use expressions/variables in the keys: {**x, 'fo'+'o': 'bar', **y}

    return dict(x, **{'fo'+'o': 'bar'}, **y)
The new syntax is some mild syntactic sugar. (Which isn't a bad thing IMO)
Post reply on HN