Mailman 3 February 2014 - Python-ideas

Make it optional
by anatoly techtonik Feb. 11, 2014

Feb. 11, 2014

Flexibility of something is the fact that you are not forced to use it in some unnatural way. I'd say that most PEPs related to core Python are flexible, but I am not sure about the rest. PEPs are made to resolve ambiguities. But it doesn't mean limiting flexibility and setting hard limitation. What is hard limitation standard? For example, marking version you can not parse as pre-release. PIP actually does this, which prevents all packages with versions that are not comply with "versioning PEP" from installing. "pre-release" is a feature. Inflexible, tempting to guess, getting in a way, implicit and confusing. I just filled three or four bugs about it. How come that it appeared at all? Well, because it is useful. In some cases. But the problem is that it affects you even if you don't need it. "Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all. -- anatoly t.

5 7

switch statement as context manager?
by Sturla Molden Feb. 11, 2014

Feb. 11, 2014

I've noticed that PyExt has a switch statement implemented as a context manager. with switch(foobar): if case(1): pass if case(2): pass Would this be something to consider for the standard lib, e.g. contextlib? Sturla

10 15

Re: [Python-ideas] Inline Functions - idea
by Alex Rodrigues Feb. 11, 2014

Feb. 11, 2014

Over the last few days I've been considering a lot of what we talked about regarding Python scoping and inline functions. Today I found a further use case for inline functions (one which is a fair bit harder to replicate using standard techniques). I was working on writing a basic linear algebra calculator for school and one of the annoying things about doing it is that every time you want to do an element-wise operation on the matrix (which is a list of lists) you have to nest what is essentially one line of code inside a pair of for loops. Below I've done three basic linear algebra functions which are written as if there was a builtin "inline()" which transformed a standard function into an inline function and also assuming that python had more powerful lambdas. I feel that these represent a good use case, because the inline function serves to make the code both shorter and clearer. import copy @inline def element_wise(func): func = inline(func) for i, row in enumerate(matrix): result.append([0]*len(row)) for j, el in enumerate(row): func() def is_symmetric(matrix): element_wise(lambda: if matrix[i][j] != matrix[j][i]: return False) return True def matrix_add(matrix, matrix2): result = copy.deepcopy(matrix) element_wise(lambda: result[i][j] = matrix[i][j] + matrix2[i][j]) return result def matrix_multiply(matrix, matrix2): result = copy.deepcopy(matrix) element_wise(lambda: result[i][j] = sum([a*b for a,b in zip(matrix[i], [r[j] for r in matrix2])])) return result

5 4

int()
by Liam Marsh Feb. 11, 2014

Feb. 11, 2014

Hello, do you think it is possible to operate with bytes like with ints? useing the fact than ord('A')==65 ; will it possible to use b'A' like 65 or 00100001, in binary, for example for encryption of files, etc... thank you.

4 3

Question about `list.insert`
by Ram Rachum Feb. 10, 2014

Feb. 10, 2014

Hi, I'm curious. If I append an item to a list from the left using `list.insert`, will Python always move the entire list one item to the right (which can be super-slow) or will it check first to see whether it can just allocate more memory to the left of the list and put the item there, saving a lot of resources? Thanks, Ram.

10 18

FW: Inline Functions - idea
by Alex Rodrigues Feb. 10, 2014

Feb. 10, 2014

I have to agree about matrix_multiply, it's not that clean. But try writing it out without inline and you'll find that it is quite a bit longer. If we were aiming for more readability I suppose we could do this def matrix_multiply(matrix, matrix2): def dot_product(i, j): sum = 0 for x in range(len(matrix2)): sum += matrix[i][x] * matrix2[x][j] return sum result = copy.copy(matrix) element_wise(result[i][j] = dot_product(i, j)) return result Which is still superior to the best syntax currently available. So being concerned about the readablility of the function, while legitimate, is not actually a knock on the syntax just on the way I wrote it. > ________________________________ >> From: amber.yust(a)gmail.com >> Date: Mon, 10 Feb 2014 19:20:41 +0000 >> Subject: Re: [Python-ideas] Inline Functions - idea >> To: lemiant(a)hotmail.com; python-ideas(a)python.org >> >> I find your example code far less readable than just writing out the >> loops in the appropriate functions, especially for matrix_multiply. >> >> On Mon Feb 10 2014 at 10:51:35 AM, Alex Rodrigues >> <lemiant(a)hotmail.com<mailto:lemiant@hotmail.com>> wrote: >> Over the last few days I've been considering a lot of what we talked >> about regarding Python scoping and inline functions. Today I found a >> further use case for inline functions (one which is a fair bit harder >> to replicate using standard techniques). I was working on writing a >> basic linear algebra calculator for school and one of the annoying >> things about doing it is that every time you want to do an element-wise >> operation on the matrix (which is a list of lists) you have to nest >> what is essentially one line of code inside a pair of for loops. >> Below I've done three basic linear algebra functions which are written >> as if there was a builtin "inline()" which transformed a standard >> function into an inline function and also assuming that python had more >> powerful lambdas. I feel that these represent a good use case, because >> the inline function serves to make the code both shorter and clearer. >> >> >> import copy >> >> @inline >> def element_wise(func): >> func = inline(func) >> for i, row in enumerate(matrix): >> result.append([0]*len(row)) >> for j, el in enumerate(row): >> func() >> >> def is_symmetric(matrix): >> element_wise(lambda: if matrix[i][j] != matrix[j][i]: return False) >> return True >> >> def matrix_add(matrix, matrix2): >> result = copy.deepcopy(matrix) >> element_wise(lambda: result[i][j] = matrix[i][j] + matrix2[i][j]) >> return result >> >> def matrix_multiply(matrix, matrix2): >> result = copy.deepcopy(matrix) >> element_wise(lambda: result[i][j] = sum([a*b for a,b in >> zip(matrix[i], [r[j] for r in matrix2])])) >> return result >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org<mailto:Python-ideas@python.org> >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/

2 1

sentinel_exception argument to `iter`
by Ram Rachum Feb. 10, 2014

Feb. 10, 2014

Hi, This time I'm posting on the right list :) Sorry for the mistake in the last thread. `iter` has a very cool `sentinel` argument. I suggest an additional argument `sentinel_exception`; when it's supplied, instead of waiting for a sentinel value, we wait for a sentinel exception to be raised, and then the iteration is finished. This'll be useful to construct things like this: my_iterator = iter(my_deque.popleft, IndexError) What do you think? Ram.

10 32

@partials = decorators
by Ron Adam Feb. 9, 2014

Feb. 9, 2014

On 02/06/2014 05:14 AM, Nick Coghlan wrote:> On 6 February 2014 20:34, Ron Adam<ron3200(a)gmail.com> wrote: (clipped unrelated discussion) > As far as what you're proposing goes, is it essentially a way to > declare a function like (spelling out the lambdas fully): > > def S(x): > def _second(y): > def _third(z): > return x(z)(y(z)) > return _third > return _second > > As something much shorter like this: > > def S (x)(y)(z): > return x(z)(y(z)) > > The main potential benefit I could see to a construct like that is > that it may allow the more consistent creation of closures that > support pickling, since the outer functions are guaranteed not to have > any side effects and to have argument capture as their*only* > significant state. This means that you could take the inner function, > pickle it along with its closure variables and reconstruct that at the > far end, only relying on the name of the outer function. > > Such a construct could also make decorator factories easier to write. > > def decorator(f): > # Do something with f > > def decorator_factory(some, args, here)(f): > # Do something with f, but have access to the bound args. > > There's an argument to be made that the extra parens in the function > header are too easy to miss, but I still see "make it easier to write > side-effect free closures" as an idea worth discussing further. It's a different feature than the one I was suggesting, which was a type of continuations... but the two concepts are related and compatible. I think the S(x)(y)(z): is adding more complexity to function signatures which are already more complex than I like, but there is an alternate option... What if these *calls* were equivalent... S(x, y, z) == S(x)(y)(z) * There might need to be some additional device or syntax needed to make it work. (* see '@' comments further down.) That is on the call side, so the definition would still be the same. def(x, y, z): ... Which is nice, because it gives us partials at a lower level which may have some advantages over a library function. And it gives us a better way to define decorators. def deco(func, *args, **kwds): ... deco(func, *args, **kwds) == deco(func)(*args, **kwds) or deco(func)(*args)(**kwds) In effect making a decorators into partials. @deco def foo(...): ... Hmmm... Could the @ syntax be generalised in this case? @foo(func) Partial waiting for rest... Then the more general case... a_op = @foo(op) # Partial waiting for rest. a_x = @a_op(x) a = a_x(y) That would be cool, unifies decorators and partials with decorator syntax! I think it's even back-words compatible if you allow this equivalency. def foo(x, y): ... @foo(x, y) == foo(x, y) # An identity partial And the decorator case becomes... @partial def func(): ... And we get this equivalency as well.... @partial == partial # I think this could work. The reason these things are interesting to me is that, I've been thinking about the order of function arguments and if there could be some generalised concepts that can be applied to that problem. Being able to use normal functions effectively in these ways, (with partials, and continuations), is related to the order of the arguments and how they are commonly used. Cheers, Ron

3 5

Iterative development
by anatoly techtonik Feb. 7, 2014

Feb. 7, 2014

Yet another idea that some of you will find strange. It is a parallel Python development process. It doesn't affect or replace current practice, so nobody gets hurt. It is also about open process, where openness means transparency (eliminate hidden communication), inclusiveness (eliminate exclusive rights and privileges) and accessibility (eliminate awkward practices and poor user experience). The idea is to split development of Python into two weeks cycle. Every two weeks is "iteration". Iteration consists of phases: 1. Planning (one, two days) 2. Execution 3. Testing 4. Demo 5. Retrospective Some of you, who familiar with concept of "sprint" and know something about "agile" buzzwords will find this idea familiar. In fact, this is borrowed from some of the best practices of working with remote teams who use this methodology. (Planning) So, during these the first, planning phase, people, who'd like to participate - choose what should be implemented in this iteration. For that there should be a list of things to be done. This list is called "backlog". People collaboratively estimate complexity and sort the things by priority. (Execution) You take a thing from backlog, mark that you're working on it, so that other people who are also interested can find you. If you need help, you split the thing into subtasks and make these tasks open for people to find and jump in. (Testing) This is a phase when work done is compared with actual thing description. Sometimes this leads to new insights, new ideas, new bugs and more work to be done in subsequent iteration. Sometimes it appears that during execution the thing completely diverged from what was originally planned. (Demo) Demonstration of the things done. Record progress, give credits and close mark things in backlog as done. Demo is made for broader community that just for a list of participants. (Retrospective) This is an important phase that is dedicated to gathering and processing feedback to improve the iteration loop. Every person reports what he/she liked and disliked, what was the % of overall fun. Then some things and ideas are being born from the feedback - what can be improved - being it tools, interaction with people or some other things that get in the way. -- anatoly t.

16 49

Simplifying .format() based string interpolation
by Robert Hölzl Feb. 7, 2014

Feb. 7, 2014

Hello All, I REALLY like str.format() from PEP3101 since it is simple to use, powerful and extendable. Especially I like the possibility to use named fields for two reasons: readability AND it is less error prone. i.E. compare "{name} is {value} ({value:X} in hex)" to "{} is {} ({1:X} in hex)". In a lot of cases all fields are identical with variables from the local/global name space. This means in the above example one had to write: "{name} is {value} ({value:X} in hex)".format(name=name, value=value) But such statements are violating the DRY principles! How about introducing new string tokens beginning with 'f', which tells the parser to take over that job. In this case one simply had to write: f"{name} is {value} ({value:X} in hex)" and the parser would replace this by "{name} is {value} ({value:X} in hex)".format( **collections.ChainMap(locals(), globals()) ) Would be glad to hear your thoughts, Robert

7 10