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

151–160 of 181 posts

Re: Migrating to Python 3 with pleasure

#151

Post by sametmax »

dozzie wrote: post #109
sametmax wrote: post #100

Earlier quoted context omitted.

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 !

Every time somebody mentions how awsome f-strings are makes me laugh. It was around ten years ago when Python community was looking down at Perl and shell with their string interpolation, but now that Python got pretty much the same it's suddenly not considered a misfeature.

We were wrong. We aknowledged it and improved. It's a good thing.

Re: Migrating to Python 3 with pleasure

#152

Post by sametmax »

jstimpfle wrote: post #118
sametmax wrote: post #96

Earlier quoted context omitted.

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.

You say that because you are not a sysadmin. Python user base is very rich.

Re: Migrating to Python 3 with pleasure

#153

Post by dagw »

sametmax wrote: post #150
dagw wrote: post #130

Earlier quoted context omitted.

multiprocessing and threading pools While certainly awesome, these are in python 2.7 as well. Although I don't remember if they where in 2.7 first of back-ported to 2.7 from 3.

__Reliable__ pools are only in 3.

Cool. What's changed?

Re: Migrating to Python 3 with pleasure

#154

Post by pletnes »

cup-of-tea wrote: post #115

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…

If you’re doing data science, do consider the anaconda python distribution with conda environments instead. Intel MKL linked numpy gives a lot better performance, and conda can install binary dependencies for libs that are tricky to compile even on linux. Pip packages are just more work and less performance in my experience (~10x)

Re: Migrating to Python 3 with pleasure

#155

Post by Sean1708 »

Doxin wrote: post #120
orf wrote: post #42

Earlier quoted context omitted.

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)

Did you try your example? It never worked in Python2 and it doesn't work in Python3 by design.

  Python 2.7.12 (default, Dec  4 2017, 14:50:18) 
  [GCC 5.4.0 20160609] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> x = {'foo': 5, 'bar': 6}
  >>> y = {'foo': 7, 'baz': 9}
  >>> dict(x, **{'fo'+'o': 'bar'}, **y)
    File "", line 1
      dict(x, **{'fo'+'o': 'bar'}, **y)
                                 ^
  SyntaxError: invalid syntax

  Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
  [GCC 5.4.0 20160609] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> x = {'foo': 5, 'bar': 6}
  >>> y = {'foo': 7, 'baz': 9}
  >>> dict(x, **{'fo'+'o': 'bar'}, **y)
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: type object got multiple values for keyword argument 'foo'
  >>> {**x, 'fo'+'o': 'bar', **y}
  {'foo': 7, 'baz': 9, 'bar': 6}

Re: Migrating to Python 3 with pleasure

#156

Post by maxerickson »

sametmax wrote: post #97
maxerickson wrote: post #37

Earlier quoted context omitted.

The Path object won't construct a path from an integer. >>> from pathlib import Path >>> p=Path(1) Traceback (most recent call last): File " ", line 1, in File "/usr/lib/python3.6/pathlib.py", line 979, in __new__ self = cls._from_parts(args, init=False) File "/usr/lib/python3.6/pathlib.py", line 654, in _from_parts drv, root, parts = self._parse_args(args) File "/usr/lib/python3.6/pathlib.py", line 638, in _parse_ar…

p=Path(str(1)) Python is strongly typed.

Yes, that's pretty much the question metaobject was asking.

Should I have said "numeric characters" or "numeric strings" in my last paragraph instead of numbers?

Re: Migrating to Python 3 with pleasure

#157

Post by jsjohnst »

djrobstep wrote: post #72
jsjohnst wrote: post #58

Earlier quoted context omitted.

Do you mean the columns of the row?

No, I mean the rows. Each row is semantically an ordered mapping.

Shouldn’t the collection of rows be a set or list, not a dictionary?

That said, you disagreed with my question then went on to show my question was on point.

The “rows themself” being an ordered map means you are referring to the columns, the order being set by the SELECT clause or table definition order (in case of wildcard).

That said, I personally feel iterating over table columns in that way to be a “bad code smell”. Not saying it’s bad in all cases, but generally it’s an anti-pattern to me.

Re: Migrating to Python 3 with pleasure

#158

Post by Sean1708 »

sametmax wrote: post #93
alexbecker wrote: post #80

Earlier quoted context omitted.

The new dict implementation was introduced in 3.5 (with forced order randomization, which was removed in 3.6) because it is faster and uses less memory than the previous non-ordered dict. Ordering is merely a nice byproduct. So you're not paying any penalty. OrderedDict is fundamentally different because it is designed to allow inserting/removing keys in the middle of the ordering in O(1) time. It does not use the ne…

Actually, 3.7 are not always ordered. If you delete a key, order is not guaranteed anymore. For performance reasons.

Are you sure about that? I thought they considered that but decided to just make them always ordered in the end.

Re: Migrating to Python 3 with pleasure

#159

Post by icedchai »

djrobstep wrote: post #70
icedchai wrote: post #54

Earlier quoted context omitted.

Unless there is an "order by" clause, the order of rows in the result set is undefined and non-deterministic from query to query.

As I said: > Not the result set, the rows of the result set. Each row is a mapping with ordered keys.

Perhaps you are confused and mean "columns"? ("Rows of the result set" is what I was referring to.)

A result set has rows, which are not in a deterministic order unless an "order by" is provided. Each row has columns. The columns are in order, obviously.

Re: Migrating to Python 3 with pleasure

#160

Post by newen »

cup-of-tea wrote: post #115

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…

For me, it's as simple as python is not a moving target. Whatever new changes there are in python 3 doesn't affect me since I won't be using any of the new features even if I were to use python 3.
Post reply on HN