101–110 of 181 posts
I've been toying around with Python 3 and using it for most of my personal/hack projects, but I somehow missed the unpacking improvements: https://www.python.org/dev/peps/pep-0448/ In particular, being able to create an updated copy of a dict with a single expression is pretty cool: return {**old, 'foo': 'bar'} # Old way new = old.copy new['foo'] = ['bar'] return new
a, *b, c = range(10)
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.
If you were relying on keys order before, you were not only doing it wrong, but you were doing so despite being told again and again.
the Path thing is incredible! I wasn't aware of it. I'll definitively be replacing my os.path.join calls for a more readable version of it.
I'd been a 2.7 holdout for ages, but when f-strings were greenlit for 3.6, I decided then and there that all my new personal projects would be written in 3. I'm glad I did. F-strings are wonderful, as is pathlib and the enhanced unpacking syntax. Since I started my current job, I've also been writing as many scripts as I can in Python 3 as well (and Docker has been a godsend for that because I can now deploy 3.6 scri…
Could you provide more info on your setup for this? I work on some EL 6 servers and would be interested in using this setup.
I'll often do something similar to this, where I have a CLI tool that I'm not ready to deploy server-wide yet, and has hefty dependencies.
The pattern I use is to have a wrapper shell script that calls:
docker run -it --rm --volume "$(pwd)/$1:/file_to_process:z" --user $(id -u) container-image /opt/command_to_run /fileToProcess
The :z mount parameter may or may not be needed depending upon whether you have SELinux enabled or not (by default, SELinux prevents countainers accessing any file on the host, and :z changes the SE context to allow access). I don't know if this is the case with EL6 tho.
The -t parameter shouldn't be used if your script is running in a pipeline (it creates a pseudo-tty). So it may be worth having some kind of conditional to remove this.
The wrapper I use also has a conditional to add the "$(pwd)" prefix to the call parameter only if the parameter is a relative path.
Is the np.dot -> @ tip reliable? I thought these were fairly different in practice.
What do you mean? `A.dot(B)` and `A @ B` are the same thing for NumPy arrays. You might be mixing it up with the weirdness of `array` versus `matrix`, but that's totally separate.
Several posters indicate that they’ve stuck to python 2.7 even for small side projects until now. I cannot understand why? Python 3 seems to have been technically superior for a few years, and side projects must surely be good for learning something new?
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)`?
Earlier quoted context omitted.
Wow, I switched to Python 3 really early on and never knew about pathlib.
And the multiprocessing and threading pools. And collections.ChainMap. And f-strings. And yield from. And type hints. And statistics. And ipadress. And secrets. And matmul. And subprocess.run. Come on, Python 3 is packed with awesomeness !
Earlier quoted context omitted.
Would you expect that `str(some_dict) == str(some_dict)`?
No, of course not. Some order has to be applied to serialize it to a string, but that order is not defined between calls.
> 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 calls, so long as the dictionary had not been modified.
Going back to "str(some_dict) == str(some_dict)". I would not expect to always be the same, but for entirely different reasons. Consider:
class Strange():
def __repr__(self):
import random
return str(random.random())
some_dict = {1: Strange()}
>>> str(some_dict) == str(some_dict)
False