Mailman 3 November 2016 - Python-ideas

Allow random.choice, random.sample to work on iterators
by Random832 Dec. 3, 2016

Dec. 3, 2016

Currently these functions fail if the supplied object has no len(). There are algorithms for this task that can work on any finite iterator (for example, files as a stream of lines), and the functions could fall back to these if there is no len().

7 10

Add optional defaults to namedtuple
by Jelte Fennema Dec. 2, 2016

Dec. 2, 2016

It would be nice to have a supported way to add defaults to namedtuple, so the slightly hacky solution here does not have to be used: http://stackoverflow.com/a/18348004/2570866 Jelte

5 4

Decorator to avoid a mistake
by fleblanc50 Nov. 30, 2016

Nov. 30, 2016

Hi there, I like python easy extend class and reusse code, but sometime I overwrite involontary some functions or variables from parents. I think about a decorator to confirm overwrite is intended and put a warning if is not present. class A: def hello(self): print('Hello A') class B: def hello(self): print('Hello B') class C: @overwrite def hello(self): print('Hello C') b=B() c=C() b.hello() Warning overwrite hello method... Hello B c.hello() … [View More]

14 28

Make threading.Event support test-and-set
by Celelibi Nov. 27, 2016

Nov. 27, 2016

Hello, I have a case of multithreaded program where under some condition, I would want to test the flag of the Event object and clear it atomically. This would allow me to know which thread has actually cleared the flag and thus should perform some more work before setting it again. The isSet method is of course not good enough because it's subject to race conditions. (Not even sure the GIL would make it safe.) The changes to threading.py would be pretty trivial: @@ -515,8 +515,10 @@ … [View More]

1 0

Python Documentation
by adil gourinda Nov. 26, 2016

Nov. 26, 2016

This is a small example of my idea, If you appreciate my little work I will continue working on it. If no, thank you for your attention and your comprehension :-)

3 2

Distribution agnostic Python project packaging
by James Pic Nov. 25, 2016

Nov. 25, 2016

Hi all ! Ive heard some people saying it was rude to post on a mailing list without introducing yourself so here goes something: my name is James Pic and I've been developing and deploying a wide variety fof Python projects Python for the last 8 years, I love to learn and share and writing documentation amongst other things such as selling liquor. The way I've been deploying Python projects so far is probably similar to what a lot of people do and it almost always includes building runtime … [View More]dependencies on the production server. So, nobody is going to congratulate me for that for sure but I think a lot of us have been doing so. Now I'm fully aware of distribution specific packaging solutions like dh-virtualenv shared by Spotify but here's my mental problem: I love to learn and to hack. I'm always trying now distributions and I rarely run the one that's in production in my company and when I'm deploying personal projects I like funny distributions like arch, Alpine Linux, or interesting paas solutions such as cloudfoundry, openshift, rancher and many others. And I'm always facing the same problem: I have to either build runtime dependencies on the server, either package my thing in the platform specific way. I feel like I've spent a really huge amount of time doing this king of thing. But the java people, they have jars, and they have smooth deployments no matter where they deploy it. So that's the idea I'm trying to share: I'd like to b able to build a file with my dependencies and my project in it. I'm not sure packaging only Python bytecode would work here because of c modules. Also, I'm always developing against a different Python version because I'm using different distributions because it's part of my passions in life, as ridiculous as it could sound to most people, I'm expecting at least some understanding from this list :) So I wonder, do you think the best solution for me would be to build an elf binary with my Python and dependencies that I could just run on any distribution given its on the right architecture ? Note that I like to use Arm too, so I know I'd need to be able to cross compile too. Thanks a lot for reading and if you can to take some time to share your thoughts and even better : point me in a direction, if that idea is the right solution and I'm going to be the only one interested I don't care if it's going to take years for me to achieve this. Thanks a heap ! Beat regards PS: I'm currently at the openstack summit in Barcelona if anybody there would like to talk about it in person, in which case I'll buy you the drinks ;) [View Less]

7 8

Freelance Marketplace
by andreas Nov. 23, 2016

Nov. 23, 2016

Hi, With freelancing and freelancing marketplaces being so popular, why not have a platform especially for Python related tasks and only limit the community to a job board ? Andreas

3 2

Contribution Reward System
by andreas Nov. 22, 2016

Nov. 22, 2016

Hi, I was thinking if a reward system for contributions would add motivation to those who want to contribute. Something in the lines of a reputation system. This has been done before with success. Thanks

5 4

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]
by Steven D'Aprano Nov. 19, 2016

Nov. 19, 2016

On Thu, Nov 17, 2016 at 07:37:36AM +0100, Mikhail V wrote: > On 17 November 2016 at 01:06, Steven D'Aprano <steve(a)pearwood.info> wrote: > > > It doesn't matter what keyword you come up with, you still have the > > problem that this idea introduces a new keyword. New keywords always > > break backwards compatibility, which means there has to be a good reason > > to do it. > > Any meaningful name you pick as a keyword will probably clash with > > … [View More]somebody's code, which means you will break their working program by > > introducing a new keyword. > > I appreciate how you explain things, you point to the root of problems and > it always makes my logic better. Thank you :-) [...] > > But the first question > > we'd ask is, what do other languages do? Python rarely invents new > > programming ideas itself, but it does copy good ideas from other > > languages. > > I don't know why, but this sounds somehow pessimistic. In some ways it is. But Python is a conservative language (despite the "radical" feature of significant indentation, but even that was a proven concept from at least one other language, ABC, before Guido used the idea). Things may have been different two decades ago when Python was a brand-new language with a handful of users. Python is a mature language now with a huge user-base. It is probably one of the top five most popular languages in the world, and certainly one of the top ten. We have a responsibility to our users: - to minimise the amount of disruption to their code when they upgrade; - that means avoiding breaking backwards compatibility unless there is significant benefit to make up for the pain; - and long deprecation periods before removing obsolete features; - since it typically takes five years, or even ten, to remove a deprecated feature, we should avoid wasting users' time by adding new and exciting experimental features that turn out to be a bad idea. Nick Coghlan has a good blog post that explains the tension in the Python community between those who want the language to evolve faster, and those who want it to evolve slower: http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python… For people used to the rapid change in the application space (new versions of Chrome virtually daily; Ubuntu brings out new operating system versions every six months) Python seems to move really, really slowly. But for a programming language, Python moves radically fast: most C code written in the 1970s probably works correctly today, and it can easily be a decade between C versions. [...] > First main question then would be: > Are augmented assignment operators needed *much*? They are. They were one of the most often requested features before Python. Most people consider that they improve the quality of code. [...] > In this case the work on thinking out a better > syntax for in-place stuff is not so useless as it > seems to be now. Mikhail, you are missing the point that people have already spent decades thinking about "a better syntax for in-place stuff", and for Python that syntax is augmented assignment. I'm sorry that *you personally* don't like this syntax. That puts you in a very small minority. Not everybody likes every part of Python syntax. But I think it is time for you to give up: you cannot win this battle. > If Python will *someday* be able to optimise > the simple A = A + 1 to in-place without > need of special syntax (by type annotation probably?), I really, really hope not. Type annotations are irrelevant here. Python doesn't need type annotations to know the type of A at runtime. The advantage of augmented assignment is that it allows me, the programmer, to decide whether or not I want in-place array operations. It is *my* choice, not the compiler's, whether I create a new list: A = B = [1, 2, 3] A = A + [4] assert B == [1, 2, 3] or make the change in-place: A = B = [1, 2, 3] A += [4] assert B == [1, 2, 3, 4] [...] > WAS: > Binary_mask += numpy.sum(B, C) > > NEW: > 1). prefix keyword approach examples: > > incal Binary_mask + numpy.sum(B, C) > inc Binary_mask + numpy.sum(B, C) > calc Binary_mask + numpy.sum(B, C) > exec Binary_mask + numpy.sum(B, C) Those suggestions waste perfectly good and useful variable names as keywords (I have code that uses inc and calc as names, and exec is the name of a built-in function). And not one of those examples makes it clear that this is an assignment. Augmented assignment does make it clear: it uses a variation on the = binding operator. (Its not actually an operator, but for lack of a better name, I'll call it one.) It follows the same basic syntax as regular assignment: target = expression except that he augmented operator is inserted before the equals sign: target -= expression target += expression target *= expression etc. At this point, I think it is a waste of time to continue discussing alternatives to augmented assignment syntax. I'm happy to discuss the culture of Python and how we decide on making changes to the language, but I am not interested in discussing augmented assignment itself. -- Steve [View Less]

5 6

Generator-based context managers can't skip __exit__
by Ram Rachum Nov. 19, 2016

Nov. 19, 2016

Hi everyone, Here is a simplification of a problem that's been happening in my code: import contextlib @contextlib.contextmanager def f(): print('1') try: yield finally: print('2') g = f() g.__enter__() This code prints 1 and then 2, not just 1 like you might expect. This is because when the generator is garbage-collected, it gets `GeneratorExit` sent to it. This has been a problem in my code since in some instances, I tell a context manager not to do its `… [View More]

8 20