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

Python 3.5.0

python.org

Post reply on HN
Print view View original

21–30 of 165 posts

Re: Python 3.5.0

#21

Post by andreasvc »

servbot wrote: post #18
vegabook wrote: post #8

Earlier quoted context omitted.

Agreed but does this apply in Numpy as well? Will Python matrix multiplications just work on lists of lists in which case they're much slower? Sorry just asking from a 2.7 holdout here as this might cause me to move.

From: http://legacy.python.org/dev/peps/pep-0465/#id24 Implementing __matmul__, __rmatmul__ and __imatmul__ will allow you to apply this operator to any given class. In that light, you could subclass the numpy matrix class yourself and simply apply these. As for whether these will be applied to Python lists, my speculation is: I doubt it. Its possibly the most commonly used data structure, and I doubt they would add…

The matrix multiplication on lists could be used for the cartesian product (see itertools.product). However this operation is rather uncommon so there's no good reason to use an operator for it.

It wouldn't incur any overhead, don't know why you'd think it would. Each method of any object only needs to be stored once, not again for every instance. The overhead comes from pointers and data fields such as the length.

Re: Python 3.5.0

#22

Post by dalke »

pdknsk wrote: post #16

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…

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.

Re: Python 3.5.0

#23

Post by kazagistar »

pdknsk wrote: post #16

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…

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.

Re: Python 3.5.0

#24

Post by masklinn »

pdknsk wrote: post #16

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…

> 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 >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)

Re: Python 3.5.0

#25

Post by [deleted] »

pdknsk wrote: post #16

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…

[deleted]

Re: Python 3.5.0

#26

Post by andreasvc »

pdknsk wrote: post #16

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…

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)]

Re: Python 3.5.0

#27

Post by [deleted] »

masklinn wrote: post #24
pdknsk wrote: post #16

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…

> 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…

[deleted]

Re: Python 3.5.0

#28

Post by task_queue »

wheaties wrote: post #5

Does this mean that asyncio will be deprecated as there's now 2 ways to accomplish much of the same thing or do they truly have different semantics?

It complements asyncio. In particular, you'd probably want to use asyncio's event loop to drive your coroutines.

Re: Python 3.5.0

#30

Post by rspeer »

bpicolo wrote: post #3
ricw wrote: post #2

By far the most exciting news here, to me, is PEP 484 typing module. Typing support would eliminate one of pythons biggest weaknesses. Furthermore, having it optional means it can remain as easy play and prototype with while becoming "more professional." The other features are all well rounded, with co-routines having quite some potential, though I'd have to play around with them first to assess. Now if everything wo…

I like the thought of coroutines, but it's definitely been especially slow for the ecosystem to adapt to asyncio so far. (And for good reason. It has new syntax that doesn't play well with non-asyncio). Adding even more syntax for the same things may slow down adoption more? Admittedly, it's much better syntax. The optional typing is a tricky subject. I'll have to wait until there are tools actually using it to see.…

PyCharm already takes advantage of optional typing using Python 3 annotations. The typing module will allow more types to be expressed, and I assume they'll update to take advantage of annotations that involve the typing module.
Post reply on HN