Hacker News new | past | comments | ask | show | jobs | submit login

PEP 0448 in addition to already implemented PEP 3132 make it very tempting to switch. If PEP 0448 had unpacking in comprehensions I'd switch. (Doesn't seem be a follow-up PEP just for that functionality yet.)

https://www.python.org/dev/peps/pep-0448/ https://www.python.org/dev/peps/pep-3132/

I'd be really nice to use this.

  >>> [*range(i) for i in range(5)]
Instead of this monstrosity right now.

  >>> [x for y in (range(i) for i in range(5)) for x in y]
Python 2.7 has some minor features that 3 dropped unfortunately, which still makes me hesitate.

Such as filter keeping the type. In 3 it returns an iterator.

  >>> filter(lambda x: x in 'ABC', 'ABCDEFA')
  'ABCA'
Or this mostly cosmetic feature.

  >>> filter(lambda x: x[0] > x[1], ((1, 2), (4, 3)))
  >>> filter(lambda (x, y): x > y, ((1, 2), (4, 3))) # equivalent, error in 3
Also dropped. (It's slower than using the dedicated base64 module though.)

  >>>'Python'.encode('base64')
  'UHl0aG9u\n'
Also, I like print.



Hi, I implemented most of PEP448. We actually implemented

  [*range(i) for i in range(5)]
and

  {**d for d in ds}
but it was removed ultimately because people in dev-python found it confusing. If you're interested in seeing that construction in Python, I suggest waiting until 3.5 gains some traction and then making a suggestion in python-ideas.


I have a few follow-up ideas/discussions to raise on the list, and this'll be one of them. As you say, I'd like to wait for things to settle and people to get an idea of the new functionality first.

FWIW, I'm the PEP writer. It's not my invention, I just wrote it up. It still makes me glad when people mention the PEP, though :).


Joshua, you're not just the PEP writer: You also helped a lot with the implementation! Anyway, it also makes me happy :) By the way, we really need someone to document our feature.

http://bugs.python.org/issue24136


> Such as filter keeping the type. In 3 it returns an iterator.

> >>> filter(lambda x: x in 'ABC', 'ABCDEFA') > 'ABCA'

it was a special case for a few types, didn't (couldn't) work for all types e.g.

    >>> filter(lambda x: x in 'ABC', set('ABC'))
    ['A', 'C', 'B']
> Also, I like print.

I like Python 3's print. It's kind-of a pain because my day-to-day uses Python 2 and the context switch is annoying, but 3's is way more flexible and readable:

    print <<f, foo, bar # (or is it >>file? I can never remember)
versus

               actually makes sense, no sigil soup
                       ||
                       \/
    print(foo, bar, file=f, flush=True)
                               /\
                               ||
                   separate statement necessary in P2
and because it's an expression it can be used in more context than Python 2's print statement.

I feel you on the loss of argument unpacking, it was a very convenient feature (though not too common IME)


In case you haven't seen it, in Python 2.7:

  >>> from __future__ import print_function
  >>> print("hi")
  hi
  >>>
My team is starting to use it as we look to migrate various command line utilities to python 3.


Other options for your first case are:

    >>> sum((range(i) for i in range(5)), [])
    [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
and

    >>> import itertools
    >>> list(itertools.chain.from_iterable(range(i) for i in range(5)))
    [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
"filter keeping the type". That was only true for some types. Python 2.7's filter does not maintain the set type:

    >>> filter(lambda x: x in 'ABC', {'A','B','C','D','E','F','A'})
    ['A', 'C', 'B']
Regarding the cosmetic feature, that's a consequence of PEP 3113 -- Removal of Tuple Parameter Unpacking , https://www.python.org/dev/peps/pep-3113/ , which also applies to functions.

I use 's.encode("hex")' often. I realize why hex/base64 are gone, but it's so short and easy in Python 2.7.


> sum((range(i) for i in range(5)), [])

This won't work in Python 3 since `range` is a new type (and it's O(n²) anyway, so not missed).

The second option is idiomatic IMHO.


Indeed! I incorrectly thought I tested that under both versions. And I didn't notice the O() performance, which is:

    >>> for i in range(20):
    ...   t1 = time.time()
    ...   n = len(sum((list(range(i)) for i in range(2**i)), []))
    ...   t2 = time.time()
    ...   print(i, t2-t1)
    ... 
    0 0.00010800361633300781
    1 2.288818359375e-05
    2 2.5033950805664062e-05
    3 4.00543212890625e-05
    4 7.295608520507812e-05
    5 0.00017499923706054688
    6 0.0005929470062255859
    7 0.0024929046630859375
    8 0.012469053268432617
    9 0.14577507972717285
    10 1.7278220653533936
    11 17.82376503944397
    ^C
(MHO too, BTW.)


This:

    >>> [x for y in (range(i) for i in range(5)) for x in y]
can be simplified into:

    [y for x in range(5) for y in range(x)]


Are you tied to 2.7 for any other libraries or are these minor bits all that's keeping you from switching? If so I'd really recommend you just try python3 for a week, and have a play with some of the new features/functionality and the minor points will soon melt away.


Actually, filter always returning an iterator was one of the benefits of python3 for me; you don't have to think about the return type or always import itertools, everything just returns an iterator.


> Also, I like print.

That really bugged me for a while, but then I added a "snippet" into my editor. Now I type: pr then the tab-key, and it transforms to:

    print('', )  # with cursor between quotes
and it works well, also I have similar shortcuts for logging.


fwiw:

    >>> codecs.encode(b'Python', 'base64')
    b'UHl0aG9u\n'
The encodings still exist; hex works too (or hex_codec in older Python 3s). Python 3 just restricted the encode/decode methods to always go str to bytes or bytes to str.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: