Mailman 3 June 2018 - Python-ideas

Re: [Python-ideas] staticmethod and classmethod should be callable
by Jeroen Demeyer June 21, 2018

June 21, 2018

On 2018-06-21 11:00, INADA Naoki wrote: > When Python 4, I think we can even throw away classmethod and > staticmethod object. > PyFunction can have binding flag instead, like METH_CLASS and > METH_STATIC for PyCFunction. > classmethod and staticmethod is just a function which modify the flag. One issue with that idea is that staticmethod, classmethod can actually arbitrary objects, not only Python functions. In fact, even this object can be created: >>> … [View More]

1 0

POPT (Python Ob ject Provider Threads)
by Martin Bammer June 20, 2018

June 20, 2018

Hello, because Python is a very dynamic language the memory management is heavily used. A lot of time is used for creating (reserve memory and fill object structure with data) and destroying objects. Because of this and because of the discussions about the GIL I was wondering if there isn't a solution to get Python code really executed in parallel without the need to create several processes and without a huge overhead. And here comes the idea for POPT. With this idea the Python interpreter … [View More]

5 6

Copy (and/or pickle) generators
by Micheál Keane June 20, 2018

June 20, 2018

Add a function to generator objects to copy the entire state of it: Proposed example code: game1 = complicated_game_type_thing() # Progress the game to the first decision point choices = game1.send(None) # Choose something response = get_a_response(choices) # Copy the game generator game2 = game1.copy() # send the same response to each game x = game1.send(response) y = game2.send(response) # verify the new set of choices is the same assert x == y History: I found this stackoverflow Q&… [View More]amp;A <https://stackoverflow.com/questions/7180212/why-cant-generators-be-pickled> which among other things linked to an in-depth explanation of why generators could not be pickled <http://peadrop.com/blog/2009/12/29/why-you-cannot-pickle-generators/> and this enhancement request for 2.6 <https://bugs.python.org/issue1092962> on the bugtracker. All the reasons given there are perfectly valid.... but they were also given nearly 10 years ago. It may be time to revisit the issue. I couldn't turn up any previous threads here related to this so I'm throwing it out for discussion. Use case: My work involves Monte Carlo Tree Searches of games, eventually in combination with tensorflow. MCTS involves repeatedly copying the state of a simulation to explore the potential outcomes of various choices in depth. If you're doing a game like Chess or Go, a game state is dead simple to summarize - you have a list of board positions with which pieces they have and whose turn it is. If you're doing complex games that don't have an easily summarized state at any given moment, you start running into problems. Think something along the lines of Magic the Gathering with complex turn sequences between players and effect resolutions being done in certain orders that are dependent on choices made by players, etc. Generators are an ideal way to run these types of simulations but the inability to copy the state of a generator makes it impossible to do this in MCTS. As Python is being increasingly used for data science, this use case will be increasingly common. Being able to copy generators will save a lot of work. Keep in mind, I don't necessarily propose that generators should be fully picklable; there are obviously a number of concerns and problems there. Just being able to duplicate the generator's state within the interpreter would be enough for my use case. Workarounds: The obvious choice is to refactor the simulation as an iterator that stores each state as something that's easily copied/pickled. It's probably possible but it'll require a lot of thought and code for each type of simulation. There's a Python2 package from 2009 called generator_tools <https://pypi.org/project/generator_tools/> that purports to do this. I haven't tried it yet to see if it still works in 2.x and it appears beyond my skill level to port to 3.x. PyPy & Stackless Python apparently support this within certain limits? Thoughts? Washington, DC USA ffaristocrat(a)gmail.com [View Less]

7 7

Dedicated string concatenation operator
by Ken Hilton June 20, 2018

June 20, 2018

Hi all, just another wild idea. I've been working a lot with PHP lately (boo!), and one of the things I have a love-hate relationship with in it is its string concatenation operator: . Counter-intuitively to Python, `.` is used to concatenate strings; `"str1" . "str2"` evaluates to `"str1str2"`. Even though it's kind of weird, I find the separation between addition and concatenation useful. In PHP, `"str1" + "str2"` evaluates to 0; `"str1" . "str2"` evaluates to `"str1str2"`. Obviously, in … [View More]

3 2

Check type hints in stack trace printing
by Daniel Sánchez Fábregas June 20, 2018

June 20, 2018

My idea consist in: Adding a method to perform type checking in traceback objects When printing stack traces search for mistyped arguments and warn about them to the user. Don't know if it is in the roadmap, but seems that have a good cost/benefit ratio to me.

5 6

Re: [Python-ideas] POPT (Python Ob ject Provider Threads) (Antoine Pitrou)
by Martin Bammer June 19, 2018

June 19, 2018

Am 2018-06-19 um 18:00 schrieb python-ideas-request(a)python.org: > Re: POPT (Python Ob ject Provider Threads) (Antoine Pitrou) Currently it's just an idea. I didn't have the time yet to create a prototype implementation.

1 0

Alternative spelling for list.append()
by Mikhail V June 19, 2018

June 19, 2018

[by request I've made new subject and summary of proposal] The idea is to introduce new syntax for the list.append() method. Syntax: Variant 1. Use special case of index, namely omitted index: mylist[] = item Examples: mylist = [1, 2, 3] --> [1, 2, 3] mylist[] = x --> [1, 2, 3, x] mylist[] = [foo, bar] --> [1, 2, 3, [foo, bar]] instead of current: mylist = [1, 2, 3] mylist.append(x) mylist.append([foo, bar]) … [View More]Variant 2. Use one of the augmented assignment operators. For example using ^= operator: mylist = [1, 2, 3] mylist ^= x mylist ^= [foo, bar] For example using >>= operator: mylist = [1, 2, 3] mylist >>= x mylist >>= [foo, bar] Other operators may be considerd as well. Motivation ----------- 1. Assignment form reduces text amount in statements and makes the right-hand part, namely the item, clean of additional brackets, which is improtant especially by more complex items which can also contain brackets or quotes. For example: mylist.append([[foo, bar], [] ]) Could be written as: mylist[] = [[foo, bar], [] ] Which preserves the original item form and has generally more balanced look. 2. Method form has one general issue, especially by longer variable names. Example from https://docs.python.org/3/tutorial/datastructures.html ... for row in matrix: transposed_row.append (row[i]) transposed.append (transposed_row) It becomes hard to read because of lack of spacing between variable names and list names. With the new syntax it could be written: for row in matrix: transposed_row[] = row[i] transposed[] = transposed_row 3. Item appending is very frequent operation. In current syntax, extend() method has dedicated syntax. mylist1 += mylist2 One of important aspects of proposal is that it should discourage usage of += for appending an item. Namely the idea is to discourage this form : mylist += [item] Because it is clunky and may cause additional confusion. E.g. adding brackets is often used and understood as operation of increasing dimension of a list - so in case of variable (not literal) the immediate reaction to this form is that there might be intention to increase the dimension of list, and not just create a list from say, an integer. But of course, increasing the dimension may be also the intention, so this construct causes extra brain load. Also in current syntax it is possible to add item to a dictionary with assignment statement: mydict[key] = item Despite it is also possible via update() method. In both cases assignment form gained popularity and used very often. [View Less]

10 24

Remember the Vasa
by Paddy3118 June 18, 2018

June 18, 2018

I thought it might be helpful for the Python community to be aware of the growth issues that the C++ community has/is discussing, at the moment. I am *not *saying we have those same issues, but we might know to avoid similar issues in our future? Here's and letter: http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf And an article on a later interview: http://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/

3 2

Operator for inserting an element into a list
by Mikhail V June 17, 2018

June 17, 2018

I think it would be logical to have the insert operator for lists. Similar to list extend operator += , it could use one of augmented assignment operators, e,g, /=. L = ["aa"] L[0] /= "bb" -> ["bb", "aa"] L[0] /= [1,2] -> [[1,2], "aa"] etc. Without index it would work like append(): L /= "bb" #-> ["aa", "bb"] As for possible spellings I like this one as well: L[i] ^= e The proposed solution is meant to have insert() method semantics, plus … [View More]

14 60

Meta-PEP about C functions
by Jeroen Demeyer June 17, 2018

June 17, 2018

I have finished my "meta-PEP" for issues with built-in (implemented in C) functions and methods. This is meant to become an "informational" (not standards track) PEP for other PEPs to refer to. You can read the full text at https://github.com/jdemeyer/PEP-functions-meta I also give brief ideas of solutions for the various issues. The main idea is a new PyTypeObject field tp_ccalloffset giving an offset in the object structure for a new PyCCallDef struct. This new struct replaces … [View More]

2 1