Live data from Hacker News

Python 3.5.0

python.org

151–160 of 165 posts

Re: Python 3.5.0

#151

Earlier quoted context omitted.

> What are the cases where you use it / rely on it? Basically any time I need to unpack inside a lambda (e.g. functional programming) and have to use something like itertools.groupby(), I run into trouble with Python 3. For example: from itertools import groupby def groupby_unsorted(items, key): return map(lambda (g, l): (g, map(lambda (k, v): v, l)), groupby(sorted(map(lambda v: (key(v), v), items)), lambda (k, v):…

But tuple unpacking inside lambdas is actually supported in Python 3, isn't it?

Could you give me an example of what you mean?

Re: Python 3.5.0

#152
post #71

Earlier quoted context omitted.

It has the ability to statically check the type system , that's amazing. Moreover async/await with async resource management (which C# doesn't have yet) gives it a real edge for server development.

> Moreover async/await with async resource management (which C# doesn't have yet) In C#, the using statement combines with async/await . It is cool that Python finally gains proper async/await, there is no need to diss other languages.

IDisposable's dispose is not an async function, there is no IAsyncDisposable interface with language support. There is however, a proposal https://github.com/dotnet/roslyn/issues/114 , I'm not dissing the language but things are the way they are.

Re: Python 3.5.0

#153
post #71
post #59

Earlier quoted context omitted.

Care to share some highlights? Fifth to second sounds like a big difference!

It has the ability to statically check the type system , that's amazing. Moreover async/await with async resource management (which C# doesn't have yet) gives it a real edge for server development.

> async/await with async resource management (which C# doesn't have yet) gives it a real edge for server development

An edge over what? You're still limited to a single thread via the GIL. Until that problem is solved, Python is certainly not the best bet (all else aside) for server development.

Re: Python 3.5.0

#154
post #90

Earlier quoted context omitted.

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

Re: Python 3.5.0

#155

Earlier quoted context omitted.

At first glance, parameter tuple unpacking seems like a silly hack that was wisely removed, explained here http://legacy.python.org/dev/peps/pep-3113/ What are the cases where you use it / rely on it?

> What are the cases where you use it / rely on it? Basically any time I need to unpack inside a lambda (e.g. functional programming) and have to use something like itertools.groupby(), I run into trouble with Python 3. For example: from itertools import groupby def groupby_unsorted(items, key): return map(lambda (g, l): (g, map(lambda (k, v): v, l)), groupby(sorted(map(lambda v: (key(v), v), items)), lambda (k, v):…

Python has comprehensions for this style of programming:

    def groupby_unsorted(iterable, key):
        return [(k, [v for k, v in g])
                for k, g in
                groupby(sorted((key(v), v) for v in iterable),
                        lambda item: item[0])]
    print(groupby_unsorted([1, 2, 3, 4], lambda v: v % 2))

Re: Python 3.5.0

#156
post #57

I'd love to use Python 3. Alas, I work in the defense industry and am working on a new development project in Python 2.6. Why? Because that's the version that's already installed on the client's systems, and getting anything new installed is such a nightmare of Vogon-esque policies and procedures that I've learned not to even ask. I'm constantly having to hack around bugs in ancient versions of libraries that have be…

If that's because you work on Redhat, see if at least the epel repository is available to you. No idea if or when it'll have Python 3.5 but it's usually ahead of the base repo.

for folks using RHEL/CentOS >= 6.5 then https://www.softwarecollections.org/en might be the way to go, once 3.5 is available there.

Re: Python 3.5.0

#157

Earlier quoted context omitted.

Not in the defence industry.

I work in the defense industry. Sometimes it is indeed easier to ask for forgiveness than permission, but you must be very careful. Obviously anything that violates any NDAs or security agreements is not to be pushed at all, but I've had no problems writing and running Python and MATLAB programs. Point is, defense industry doesn't automatically equal a locked down environment.

I'll chime in here and say that quite a few people in aerospace/defense (at least where I work) prefer Python to some of the more traditionally used tools.

I've written a number of scripts for data analysis and simulation in Python that are much more portable for us since we don't need to get a license to run MATLAB on computers out in the field.

Re: Python 3.5.0

#158
post #57

I'd love to use Python 3. Alas, I work in the defense industry and am working on a new development project in Python 2.6. Why? Because that's the version that's already installed on the client's systems, and getting anything new installed is such a nightmare of Vogon-esque policies and procedures that I've learned not to even ask. I'm constantly having to hack around bugs in ancient versions of libraries that have be…

If that's because you work on Redhat, see if at least the epel repository is available to you. No idea if or when it'll have Python 3.5 but it's usually ahead of the base repo.

Yeah, maybe RHEL 8 will have it, maybe as early at 2017. Maybe. :)

Re: Python 3.5.0

#159

And yet, Python 2 usage is still strong while Python 3 adoption has actually slowed down , and at this rate, it will probably stop being used completely while Python 2 continues to live on: https://www.reddit.com/r/programming/comments/3k9yif/larry_w...

Python 3 usage doubled in the last year: https://caremad.io/2015/04/a-year-of-pypi-downloads/

Re: Python 3.5.0

#160
post #155

Earlier quoted context omitted.

> What are the cases where you use it / rely on it? Basically any time I need to unpack inside a lambda (e.g. functional programming) and have to use something like itertools.groupby(), I run into trouble with Python 3. For example: from itertools import groupby def groupby_unsorted(items, key): return map(lambda (g, l): (g, map(lambda (k, v): v, l)), groupby(sorted(map(lambda v: (key(v), v), items)), lambda (k, v):…

Python has comprehensions for this style of programming: def groupby_unsorted(iterable, key): return [(k, [v for k, v in g]) for k, g in groupby(sorted((key(v), v) for v in iterable), lambda item: item[0])] print(groupby_unsorted([1, 2, 3, 4], lambda v: v % 2))

Yes, list comprehensions can take care of some of these, but you're completely missing the entire point.

The point was that writing something like

  lambda item: item[0]
in your code is inferior to

  lambda (k, v): k
in terms of readability and comprehensibility. It is both longer and it also doesn't document the fact that the item is semantically a key-value pair.

The problem is not (and has never been) whether something is "necessary" or "possible". Tuple unpacking obviously completely unnecessary to begin with, it has nothing to do with whether this is done in a parameter or not. The problem is whether the code is expressed better via unpacking.

Post reply on HN