Re: Keypress Input
On Wednesday, July 15, 2015 at 11:30:40 PM UTC-5, Michael Torrie wrote: On 07/15/2015 07:03 PM, Rick Johnson wrote: too much to quote I think you've missed the whole point of the OP's project. Obviously my reply was not only too much to quote, but apparently, and sadly, too much to read! I don't know about anyone else here, but i would be cautious about replying to any post before i took the time to read the entire content. I mean, i'd wouldn't want to embarrass myself. But, I suppose this more evidence of the damage social media is doing to our collective attention spans. There are some studies that report an average attention span of only 8 seconds -- which is less than the attention span of a goldfish. AN EFFING GOLDFISH! CLOWN-FISH: Hello Dori! DORI: Who's Dori? I had read an article the other day about how smart phones are making people dumb. However, by focusing on the phone, which is nothing more than a tool, the author ignored the real cause of this ubiquitous intelligence drain that is rotting our culture from the inside out. It's not the *PHONES* that making people dumb, it's the *CONTENT* people *CHOOSE* that is turning us into a society of drooling, superficial, and mindless gossip zombies. TWITTER BEING THE MOST DESTRUCTIVE AND EVIL OF THEM ALL! With Twitter, we have a communication medium that encourages teeny tiny thoughtless reactions to whatever emotional drivel happens to be churning around in the daily cesspools of what, for whatever sociological reason, we still refer to as News. Is the size of some morally corrupt celeb's butt really news? Or the love interest of various talent-less glitterati anything we should concern ourselves with? Heck, just a few days ago, another lip singer made front page world news simply by licking a donut! BY LICKING AN EFFING DONUT! Are our lives that pathetic? In the past there were at least a few educational programs on the tele, now even so called educational channels have devolved into train-wrecks of thought UNprovoking emotion, with episode after episode of totally scripted reality TV far more concerned with shock value than entertainment -- much less education. I once believed that Facebook was the bottom of the barrel for social media -- BOY WAS I WRONG! It's seems there is no level that we, as a society will stoop, in the effort to destroy our capacity of intellectual evolution. So fire up those twitter engines and speed headlong into that wall of ignorant bliss! And don't bother trotting out the old cliche of grab a fiddle folks, because the unwashed masses are not refined enough to appreciate the higher intellectual emotions and the thoughtful introspection that such an instrument can produce, instead, grab a shiny rattle and shake it in front of their pasty little ignorant faces. For they can only understand simple concepts and the selfish emotions. :-O = = = ___^ __ ^_ ___'Modern-Society'___ -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 16 July 2015 at 20:03, Chris Angelico ros...@gmail.com wrote: The trouble with that is that it can quickly run you out memory when you accidentally trigger infinite recursion. A classic example is a simple wrapper function... def print(msg): print(ctime()+ +msg) With the recursion limit at its default of 1000, this can't do more than 1000 iterations before the system detects that it's stuck. With an infinite stack, this could destroy your system memory and then finally terminate with MemoryError... if you're lucky. If you're not, the whole system could get wedged before this gets killed. (Imagine, for instance, a computer with a large hard disk devoted to virtual memory. Long before that's exhausted, the system will be practically unusable, because every little operation will require going back to the disk.) That all sounds reasonable. However that can be looked another way. Soppose you have some code that traverses some tree, a strange imbalanced tree (say from some xml) It is, semantically at least, a reasonable aproach to process such a structure with some recursive function. Lets say we have a function that counts all li elements in a document for example. and recursively traverses the element tree. Because most xml is relatively flat (let's assume its rare to find more than 100 levels of nesting say) this function would perform perfectly well for most cases. however if some guy sent you an xml document with 1000 levels of nesting your program would crash. Now suddenly you have perfectly good functioning code that randomly crashes. because of some arbitrary limit. it most distinctly reminds me of a certain programming language that kills your thread after 3 operations because you are obviously-in-an-infinite-loop. it leaves a very bad taste in my mouth. That 30k limit (much less lines of source code ofc) is the reason you need nasty hacks to do stuff like implement BigInteger. That 1k stack limit is the limit you cant use perfectly good code just because your input data has some weird quirk. This puts python on par with jass2 and this deeply saddens me. Now i admit that it is possible to have infinite recursion but it is also possiblew to have infinite loops. and we don't kill your code after 1000 iterations of a while loop so why should we treat recursion any differently? Having a user defined maximum stack limit might be a good idea, eg if my stack takes up 100MB its prolly broke, but it should be my duty as a programmer to specify such a limit, not have it inflicted upon me (worse, in a manner that cannot be changed!). -- https://mail.python.org/mailman/listinfo/python-list
How does a dictionary work exactly?
Hello, I was trying to see how some have implemented a hashtable. I took a gather at dictobject.h/.c. It seems that underneath it all it's a linked list and that is used in order to store the actual information (I'm looking at PyDictEntry.) Am I correct in my assumption or is there more to this? I'm still looking into how new entries are handled. Thanks -- https://mail.python.org/mailman/listinfo/python-list
[issue24630] null pointer dereference in `load_newobj_ex`
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - out of date stage: - resolved status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Fri, Jul 17, 2015 at 3:34 AM, Joonas Liik liik.joo...@gmail.com wrote: That all sounds reasonable. However that can be looked another way. Soppose you have some code that traverses some tree, a strange imbalanced tree (say from some xml) It is, semantically at least, a reasonable aproach to process such a structure with some recursive function. Lets say we have a function that counts all li elements in a document for example. and recursively traverses the element tree. Because most xml is relatively flat (let's assume its rare to find more than 100 levels of nesting say) this function would perform perfectly well for most cases. however if some guy sent you an xml document with 1000 levels of nesting your program would crash. This sounds like a denial-of-service attack. If you can state that no reasonable document will ever have more than 100 levels of nesting, then you can equally state that cutting the parser off with a tidy exception if it exceeds 100 levels is safe. Now i admit that it is possible to have infinite recursion but it is also possiblew to have infinite loops. and we don't kill your code after 1000 iterations of a while loop so why should we treat recursion any differently? Partly because infinite recursion requires infinite storage too. If it truly is tail calls, then you can turn it into a while loop and not have the limit; otherwise, you run the risk of blowing out your RAM. Having a user defined maximum stack limit might be a good idea, eg if my stack takes up 100MB its prolly broke, but it should be my duty as a programmer to specify such a limit, not have it inflicted upon me (worse, in a manner that cannot be changed!). Actually, it is up to you. There's a default, but you can change it. def recurse(n): return n and recurse(n-1) ... recurse(998) 0 recurse(999) (throws RuntimeError) sys.getrecursionlimit() 1000 sys.setrecursionlimit(5) recurse(5) Traceback (most recent call last): File stdin, line 1, in module File stdin, line 1, in recurse File stdin, line 1, in recurse File stdin, line 1, in recurse File stdin, line 1, in recurse RuntimeError: maximum recursion depth exceeded sys.setrecursionlimit(5000) recurse(5000) (throws RuntimeError with a gigantic traceback) sys.setrecursionlimit(5) recurse(5) Segmentation fault Though as you can see, CPython does have other issues. If you crank the recursion limit up far enough, you *will* blow out your C stack. Other Pythons may behave differently, and different builds of CPython may crash at different points. But within reason, you can expand this limit, and you can certainly shrink it (eg to reduce the effect of a tree-parser DOS attack). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On 07/16/2015 01:07 AM, Steven D'Aprano wrote: The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. You mean toy examples? Toy examples serve useful purposes: - easy to understand - easy to write - esay to test as proof-of-concept (after all, if a routine can't handle a toy example, how is it going to handle real life?) With responses like these I can understand Antoon's position that folks are not arguing in good faith. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: How does a dictionary work exactly?
I was trying to see how some have implemented a hashtable. I took a gather at dictobject.h/.c. It seems that underneath it all it's a linked list and that is used in order to store the actual information (I'm looking at PyDictEntry.) Am I correct in my assumption or is there more to this? I'm still looking into how new entries are handled. The Python dictionary implementation has been pretty well optimized over the years, so it might not be the most easy-to-read code. You might actually try and latch onto a copy of dictobject.[ch] from a very old version of Python (1.5-ish). That will have much less in the way of speed tricks obfuscating the code. Very generally (I'm writing with a lot of water under the bridge since I last thought about this), a dictionary contains an array whose length is typically a power of two (2**n). When considering a key for insertion or lookup, a hash value is computed, and the last n bits of the resulting value are used as an index into that array. Each element of the array consists of a linked list of all the key/value pairs whose keys hash to that value. Once you've identified an element in the hash array, the linked list is traversed looking for the key. There are three operations: get, set, delete. Each operation has one of two actions to perform depending whether the key is found or not: * get - if found, return the corresponding value, if not, raise KeyError * set - if found, replace the old value with the new, if not, add a new key/value pair to the list * del if found, delete the key/value pair, if not, raise KeyError The challenge is to come up with a reasonable size hash array and a suitable hash function which balances the desire to not chew up all of memory with the desire to have very short lists. In Python's case, I believe that dictionaries with strings as keys (and the hash function used for strings) have been optimized for how Python's runtime works. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 16 July 2015 at 20:49, Chris Angelico ros...@gmail.com wrote: This sounds like a denial-of-service attack. If you can state that no reasonable document will ever have more than 100 levels of nesting, then you can equally state that cutting the parser off with a tidy exception if it exceeds 100 levels is safe. This particular example does have that kind of smell.. my bad for being careless with examples. what if its not a ddos tho, maybe its just strange data? how about you run some genetic algorithm to optimise something, and you store a log of your progress as a tree structure. then you have a script to traverse that tree for some reason, maybe to analyse the history and optimise the parameters of the search in the future. when the problem is complex it might well require thousands of steps to get to the desired outcome.. but over time the log grows longer and longer. at first as the script is written it's probably tested on some rather small logs, but they grow over time so eventually your program will implode on completely reasonable input. notice that the tree grows at a constant rate with generations rather than ~log(n) so it will not reach a natural limit other than finding a satisfying solution. whether that limit be 1k or 8k there is no single limit that is reasonable for all use cases and the range you can vary it is rather restricted.. (notice: this example has the issue with the genetic algorithm being potentially expensive to run so it might not reach the 1k limit, but that does not mean there are not other problems that share this property. what I want to convey here is that not all tree traversal has a natural depth limit and there are cases where it will be hit even with completely natural inputs) Partly because infinite recursion requires infinite storage too. If it truly is tail calls, then you can turn it into a while loop and not have the limit; otherwise, you run the risk of blowing out your RAM. A valid argument. tho 100MB stack space vs infinite stack space is still very much distinct. For a long running program it might not even be a big issue if some of the stack (the very bottom) is swapped to disk as the top will be nice and warm in the cache. and yes such a program is not exactly common but just because it uses a lot of memory does not mean it has frozen. it is the job of the programmer to say how much heap his program can use and it is also his job to say how much stack space is acceptable. also: def much_memory_1(str): return munch_memory_1(str+munch much memory!) much_memory_1(str) --vs-- def much_memory_2(str): tmp = str[:] while True: tmp +=munch much memory! return tmp # will never reach this much_memory_2(str) Having a user defined maximum stack limit might be a good idea, eg if my stack takes up 100MB its prolly broke, but it should be my duty as a programmer to specify such a limit, not have it inflicted upon me (worse, in a manner that cannot be changed!). Actually, it is up to you. There's a default, but you can change it. def recurse(n): return n and recurse(n-1) ... recurse(998) 0 recurse(999) (throws RuntimeError) sys.getrecursionlimit() 1000 sys.setrecursionlimit(5) recurse(5) Traceback (most recent call last): File stdin, line 1, in module File stdin, line 1, in recurse File stdin, line 1, in recurse File stdin, line 1, in recurse File stdin, line 1, in recurse RuntimeError: maximum recursion depth exceeded sys.setrecursionlimit(5000) recurse(5000) (throws RuntimeError with a gigantic traceback) sys.setrecursionlimit(5) recurse(5) Segmentation fault ..as i recall reading from a certain stackoverflow post the limit was about 8000 and possibly varying.. -- https://mail.python.org/mailman/listinfo/python-list
[issue24644] --help for runnable stdlib modules
R. David Murray added the comment: Please open individual issues to address individual modules that you would like to contribute to improving. Adding/fixing help is often best done by rewriting the argument parsing...contributions have been made to improve several modules already. In most cases we don't have tests for the -m features, and those need to be created first. In some cases we don't really want to continue to support whatever -m code exists (because it exists for no-longer-relevant historical reasons...though that doesn't apply in the two cases you reference). So each module needs to be addressed individually. To address the specific issue you raise: I believe that when we have rewritten things, we have chosen to follow argparse's lead and support both -h and --help for the display of help information. -- nosy: +r.david.murray resolution: - later stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24644 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Fri, 17 Jul 2015 03:34 am, Joonas Liik wrote: Now i admit that it is possible to have infinite recursion but it is also possiblew to have infinite loops. and we don't kill your code after 1000 iterations of a while loop so why should we treat recursion any differently? Because a while loop which repeats to many times is annoying but harmless, but a function that recurses too many times will blow up the stack and cause a seg fault, possibly executing arbitrary memory as code. You want malware and viruses to take over your system? That's how you get malware and viruses to take over your system. Having a user defined maximum stack limit might be a good idea, eg if my stack takes up 100MB its prolly broke, but it should be my duty as a programmer to specify such a limit, not have it inflicted upon me (worse, in a manner that cannot be changed!). You mean sys.getrecursionlimit() and sys.setrecursionlimit()? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On Thu, 16 Jul 2015 08:41 pm, Antoon Pardon wrote: On 07/16/2015 10:07 AM, Steven D'Aprano wrote: On Wednesday 15 July 2015 19:29, Antoon Pardon wrote: Suppose I start with the following: def even(n): True if n == 0 else odd(n - 1) def odd(n): False if n == 0 else even(n - 1) Well, both of those always return None, so can be optimized to: even = odd = lambda x: None :-) Fixing the obvious mistake (failing to return anything) leads to the next mistake. When all you have is a hammer, everything looks like a nail. def even(n): return n%2 == 0 def odd(n): return n%2 != 0 are faster, easier to understand, and don't turn into an infinite loop if you pass a negative integer. Nice of you to illustrate how being pedantic about something, can make a response useless with regard to the intended original question. Just because your intention in giving that code was X, doesn't mean that others cannot use that code to also do Y. Your example of a mutually recursive pair of functions is perfectly fine as a toy example to demonstrate a point. But the fact that people can only come up with toy examples to demonstrate the uses of unbounded recursion is telling. That's *my* point. It's orthogonal to your point. Sure your implementation for solving this particular problem is better if the purpose is to actually solve this problem. But it is useless as an illustration for the question I'm asking, which was about how to use a particular module. True. But my comment doesn't stop the OP from answering your question. A single post can lead to multiple replies you know :-) The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. So what did you expect? That I should give a real world example here with lots of details that would only detract from the information I'm looking for, just so that your curiosity would be satisfied? A non-toy example would be nice. There are non-toy examples of recursion which are still simple enough to express in a few lines, like the usual recursive algorithm for inorder traversal of a binary tree: def inorder(node): if node is not None: inorder(node.left) visit(node.data) inorder(node.right) If you can't come up with a non-toy example of mutual recursion, then something which is *obviously* useless is better than something useful-looking but actually a poor example of recursion. To go back to the if all you have is a hammer, everything looks like a nail analogy: if I want to demonstrate a hammer, I can pick an actual useful task (watch me build a chicken coop with a hammer, nails and timber); or I can pick something obviously pointless to demonstrate the technique (watch me nail this piece of wood to this other piece of wood); but what I shouldn't do is demonstrate something *bad* (watch me remove the battery from my iPhone by wacking it repeatedly with a hammer). def spam(s): return s if len(s) 50 else eggs(s + spam) def eggs(s): return s if len(s) 50 else spam(eggs + s) I'm not here to satisfy your or anyone else's curiosity. Fair enough. What are you here for? When you complain that Python doesn't have TCO, is your intent to persuade people that it should, with the ultimate aim to changing Python so that it gains TCO? If not, then what? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Where is pyvenv.py in new Python3.4 environment on CentOS7?
On Thursday, July 16, 2015 at 1:14:22 AM UTC-7, INADA Naoki wrote: How about `python3 -m venv` ? I guess that works, thanks. On Thu, Jul 16, 2015 at 6:54 AM, David Karr davidmic...@gmail.com wrote: I'm just learning more about Python (although I've been a Java dev for many years, and C/C++ before that). A book I'm reading (Learning Python Network Programming) refers to running pyvenv. I can find this in my Win7 environment, but I was planning on using my CentOS7 VM for most of this. I have both python (Python 2) and python3.4 installed. I noticed a python-virtualenv.noarch package, but it said it was already installed. Can someone elaborate on where I should be able to find or install this? (I tried asking this on the #python IRC channel, but I guess I couldn't yell loud enough.) -- https://mail.python.org/mailman/listinfo/python-list -- INADA Naoki songof...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 16 July 2015 at 21:58, Steven D'Aprano st...@pearwood.info wrote: On Fri, 17 Jul 2015 03:34 am, Joonas Liik wrote: Now i admit that it is possible to have infinite recursion but it is also possiblew to have infinite loops. and we don't kill your code after 1000 iterations of a while loop so why should we treat recursion any differently? Because a while loop which repeats to many times is annoying but harmless, but a function that recurses too many times will blow up the stack and cause a seg fault, possibly executing arbitrary memory as code. You want malware and viruses to take over your system? That's how you get malware and viruses to take over your system. That's just a buggy implementation, there are ways to extend the stack that nears its capacity, safely. Having a user defined maximum stack limit might be a good idea, eg if my stack takes up 100MB its prolly broke, but it should be my duty as a programmer to specify such a limit, not have it inflicted upon me (worse, in a manner that cannot be changed!). You mean sys.getrecursionlimit() and sys.setrecursionlimit()? ... and that buggy implementation means that when you sys.setrecursionlimit() you will overflow the stack and crash because the recursion limit is an aritificial safeguard and the underlying c buffer is not adjusted accordingly or at least so it would seem. https://docs.python.org/2/library/sys.html#sys.setrecursionlimit so as per the docs the programmer has no real control over how much stack his program can have. all you can say is let me ignore the safeguard a little longer, i hope i wont crash the program that is not the same as can i please have a stack depth of 2.. You are giving the programmer a choice between run out of stack and crash and mutilate interpreter internals and crash or zero out the hard drive this is not a real choice.. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 7/16/2015 7:45 AM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 5:31 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. Actually, they do contain all of that (at least, they do in Py3 - not sure about Py2 as I haven't checked). You can poke around with the locals at every point on the stack: def f(x): if x 10: g(x+10) return 5 def g(x): if x % 3: h(x + 2) return 7 def h(x): return 1/x try: x = -12 print(f(x)) except ZeroDivisionError as e: tb = e.__traceback__ while tb: fr = tb.tb_frame print(In function %s (%s:%d), x = %r % ( fr.f_code.co_name, fr.f_code.co_filename, fr.f_lineno, fr.f_locals[x], )) tb = tb.tb_next It's all there. And it's immensely helpful. One of the features of Idle is Debug = Stack Viewer, which, when invoked immediately after an exception, displays a tree widget with a node for each stack frame in the traceback. Running your code without the extra try: except: stuff, so a traceback is displayed, I easily see that x is -12, -2, and 0 in f, g, and h. I suspect that this feature is not well known and is underused. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
R. David Murray added the comment: I can't see doing io in __repr__ ever making sense, so I'm not sure this is a use case we care about. But Vinay might not have any objection to removing locking if it is redundant, so we'll see what he has to say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Keypress Input
On 7/15/2015 9:03 PM, Rick Johnson wrote:
You may have solved your input capturing problem, and i
don't think a GUI is the preferred solution for a
graphically deficient device anyhow, but you may well need a
GUI in the future, and this would be a fine example from which
to learn.
This really is a nice example. Your rationale for defining an app class
is the best I remember seeing.
To run in 3.x, change the first two lines to
import tkinter as tk
from tkinter.messagebox import showinfo, showerror
import Tkinter as tk
from tkMessageBox import showinfo, showerror
MSG1 = \
To begin retinal stimulation, press r or g or b on your keyboard
Hold key down for extended stimulation!
class App(tk.Tk):
def __init__(self):
tk.Tk.__init__(self)
self.bind(KeyPress, self.evtKeyDown)
self.bind(KeyRelease, self.evtKeyUp)
self.protocol(WM_DELETE_WINDOW, self.evtDeleteWindow)
w = tk.Label(self, text=MSG1)
w.pack()
self.config(bg='white')
self.geometry('500x500')
self.focus_set()
def evtDeleteWindow(self):
showinfo(The window is Dying, Goodbye cruel world!, parent=self)
self.destroy()
def evtKeyDown(self, event):
key = event.keysym.lower()
alert = False
if key == 'r':
self.config(bg='red')
elif key == 'g':
self.config(bg='green')
elif key == 'b':
self.config(bg='blue')
else:
Can condense block above to this easily extended code: (Replacing if
if/elif/elif/... chains, when possible, is part of mastering Python.)
try:
self['bg'] = {'r':'red', 'g':'green', 'b':'blue'}[key]
except KeyError:
msg = 'I *TOLD* you to press r or g or b, not {0!r}!'.format(key)
showerror('', msg, parent=self)
def evtKeyUp(self, event):
self.config(bg='white')
if __name__ == '__main__':
app = App()
app.title('Retina Stimultor')
app.mainloop()
print This code only executes *AFTER* the mainloop call returns!
Adding parens to print, when there is a single object being printed, has
no effect in 2.x and makes the statement work in 3.x. The following
works the same in both.
print(Mainloop has returned)
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
On Thu, Jul 16, 2015 at 1:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Fine by me. What is the mapping API that needs to be implemented though? Have a look at collections.MutableMapping. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
Terry Reedy tjre...@udel.edu writes: On 7/15/2015 9:51 PM, Ben Finney wrote: What well-defined data type exists with the following properties: * Mapping, key → value. * Each key is a sequence (e.g. `tuple`) of items such as text strings. * Items in a key may be the sentinel `ANY` value, which will match any value at that position. * A key may specify that it will match *only* sequences of the same length. * A key may specify that it will match sequences with arbitrarily many additional unspecified items. Every key should signal which of the last two alterntives holds. One can be a default. The signal can be 'in-band', in the tuple key itself, or 'out-of-band', not in the tuple key. Thanks. The part which puzzle me though: How do we teach the mapping type about that matching behaviour? -- \“Without cultural sanction, most or all of our religious | `\ beliefs and rituals would fall into the domain of mental | _o__) disturbance.” —John F. Schumaker | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
On Thu, Jul 16, 2015 at 3:55 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Thanks. The part which puzzle me though: How do we teach the mapping type about that matching behaviour? I'm not sure you really need a mapping type per se. The benefit of something like Python's dict is that it gives really fast lookups via the hash table... but with the match any concept, there's actually a potential for ambiguities, which means you need a sequential (strictest first) check. In any case, it's virtually impossible to hash a tuple of strings such that it can match multiple targets, based only on what the targets do. Steven's suggestion to turn this into an honest linear search is probably what I'd do; ultimately, a dict that can't hash its keys properly is going to devolve to that anyway. You could craft a mapping-like type that uses subscripts in this way. I'm not sure whether it'd help, but there's no particular reason for __getitem__ to not do a full linear search: class Lookup: def __getitem__(self, item): for matcher, value in self.stuff: keys = iter(item) for key in matcher: if key is ZERO_OR_MORE: return value # Matched! try: val = next(keys) except StopIteration: break # Too short, doesn't match if key != val and key is not ANY_ONE: break # Mismatch else: return value # Matched! raise KeyError(item) Then in your code, it would look like any other mapping type, but it'd still be the exact same linear search that Steven talked about. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
Chris Angelico ros...@gmail.com writes: I'm not sure you really need a mapping type per se. My reasons include (but I can probably think of more) testing membership via the ‘key in mapping’ syntax. with the match any concept, there's actually a potential for ambiguities, which means you need a sequential (strictest first) check. In any case, it's virtually impossible to hash a tuple of strings such that it can match multiple targets, based only on what the targets do. I'm fine with not having the keys hashed, so long as I can use the mapping API (membership test, item retrieval by key, rejecting keys that already match one of the items, etc.). In other words, I'm not limiting myself to Python's ‘dict’ type, which is why I've only been talking about a type which can be classified as a mapping type. Steven's suggestion to turn this into an honest linear search is probably what I'd do; ultimately, a dict that can't hash its keys properly is going to devolve to that anyway. Fine by me. What is the mapping API that needs to be implemented though? I can guess, but for code I intend to release, API design should not be a matter of guessing. I'd rather have an already-worked example of a custom mapping type that fully implements the API used by Python's mapping type, without having to discover it all by trial and error. Once this is out in the wild, I don't want to discover I made a bad API design decision. -- \ “When a well-packaged web of lies has been sold to the masses | `\over generations, the truth will seem utterly preposterous and | _o__)its speaker a raving lunatic.” —Dresden James | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
On 07/15/2015 10:53 PM, Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
You can't use a dict for the mapping, not unless you're smarter than
me, due to the requirement to hash the keys.
Dang. It's the mapping that I really need to solve, I think. A mapping
that has a custom “does this candidate match any existing key” and
“return the value for this key” to defer to the matching behaviour
described above.
Are those the ‘__contains__’, ‘__getitem__’ methods? What actually is
the API of a mapping type, that would need to be customised for this
application?
The problem is that potential key matches are found by hashes, and the hash of
('value1', ANY, 'next_value')
and
('value1, 'value2', 'next_value')
and
('value1', 'value3', 'next_value')
will not and cannot be the same.
If you fiddle with your object such that all instances hash to the same value
then you lose the O(1) lookup for the dict -- you basically have a list.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
[issue23601] use small object allocator for dict key storage
Stefan Behnel added the comment: Benchmark results look good to me (although a header line is missing) and seem to match my expectations. Sounds like we should allow this change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23601 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Mapping, with sequence as key, wildcard and subsequence matching
Ethan Furman et...@stoneleaf.us writes: On 07/15/2015 10:53 PM, Ben Finney wrote: Are those the ‘__contains__’, ‘__getitem__’ methods? What actually is the API of a mapping type, that would need to be customised for this application? The problem is that potential key matches are found by hashes For the Python ‘dict’ type, yes. I already know that I don't want that type, I want a custom mapping type which matches keys according to the algorithm I specify. So, I'm not asking “how do I make ‘dict’ do this?”. I am instead asking “how do I implement a custom type which can duck-type for ‘dict’ but have a different key-lookup implementation?”. -- \ “As the most participatory form of mass speech yet developed, | `\the Internet deserves the highest protection from governmental | _o__) intrusion.” —U.S. District Court Judge Dalzell | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
[issue24632] Improve documentation about __main__.py
Ezio Melotti added the comment: I think this is due to PEP 420 Namespace Packages. It works on Python 2 too: $ ls execdir/ foo.py __main__.py $ cat execdir/foo.py print(foo imported) $ cat execdir/__main__.py import foo; print(main imported) $ python execdir/ foo imported main imported $ python -V Python 2.7.8 I haven't done any tests about the interaction of namespace packages and __main__.py, but if there are additional semantics, they should be documented as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24632 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 07/15/2015 11:19 PM, Terry Reedy wrote: On 7/15/2015 5:29 AM, Antoon Pardon wrote: Can you explain how you would do mutual recursive functions? Suppose I start with the following: def even(n): True if n == 0 else odd(n - 1) def odd(n): False if n == 0 else even(n - 1) How do I rewrite those with your module? I will not answer for Baruchel's tco module. However, combining the two bodies and following the general rule of replacing tail recursive calls with assignments inside a while loop gives us def even(n): return not odd(n) def odd(n): while True: if not n: return False else: n -= 1 if not n: return True else: n -= 1 [ ... ] I believe that this pattern should work with any set of mutually recursive functions that always call each other in cyclic order. A more elaborate version does not have this limitation. Nice of you to illustrate the warping involved. ;-) -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Where is pyvenv.py in new Python3.4 environment on CentOS7?
How about `python3 -m venv` ? On Thu, Jul 16, 2015 at 6:54 AM, David Karr davidmichaelk...@gmail.com wrote: I'm just learning more about Python (although I've been a Java dev for many years, and C/C++ before that). A book I'm reading (Learning Python Network Programming) refers to running pyvenv. I can find this in my Win7 environment, but I was planning on using my CentOS7 VM for most of this. I have both python (Python 2) and python3.4 installed. I noticed a python-virtualenv.noarch package, but it said it was already installed. Can someone elaborate on where I should be able to find or install this? (I tried asking this on the #python IRC channel, but I guess I couldn't yell loud enough.) -- https://mail.python.org/mailman/listinfo/python-list -- INADA Naoki songofaca...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
[issue24642] Will there be an MSI installer?
New submission from Alex Walters: I use the *.msi installers for python to automate deployment of... an absurd number of python installations. I have been able to do this relatively easily, as the Windows installer didn't change much between 2.6 and 3.4 (possibly much longer than that, but I don't know about 2.5 or earlier). 3.5 added a new installer (the web installer), and apparently dropped the old standby *.msi installers, for the beta versions. Will there be *.msi installers for 3.5? -- components: Windows messages: 246796 nosy: paul.moore, steve.dower, tim.golden, tritium, zach.ware priority: normal severity: normal status: open title: Will there be an MSI installer? versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24642 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Mapping, with sequence as key, wildcard and subsequence matching
Ben Finney ben+pyt...@benfinney.id.au:
What well-defined data type exists with the following properties:
* Mapping, key → value.
* Each key is a sequence (e.g. `tuple`) of items such as text strings.
* Items in a key may be the sentinel `ANY` value, which will match any
value at that position.
* A key may specify that it will match *only* sequences of the same
length.
* A key may specify that it will match sequences with arbitrarily many
additional unspecified items.
What you are describing is a tree; the sequences specify paths:
class Node:
ANY = object()
UNDEFINED = object()
def __init__(self):
self.value = Node.UNDEFINED
self.children = {}
def setvalue(self, keyseq, value, offset=0):
try:
next = keyseq[offset]
except IndexError:
self.value = value
return
if next is Node.ANY:
raise KeyError()
try:
child = self.children[next]
except KeyError:
self.children[next] = child = Node()
child.setvalue(keyseq, value, offset + 1)
def lookup(self, keyseq, offset=0):
try:
next = keyseq[offset]
except IndexError:
for value in self.yieldall():
yield value
return
if next is Node.ANY:
for child in self.children.itervalues():
for value in child.lookup(keyseq, offset + 1):
yield value
return
try:
child = self.children[next]
except KeyError:
return
for value in child.lookup(keyseq, offset + 1):
yield value
def yieldall(self):
if self.value is not Node.UNDEFINED:
yield self.value
for child in self.children.itervalues():
for value in child.yieldall():
yield value
=
Usage:
=
tree = Node()
tree.setvalue((1, 2), 3)
print list(tree.lookup((1, 2)))
print list(tree.lookup((Node.ANY, 2)))
=
CAVEAT: Code barely tested.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
[issue24583] set.update(): Crash when source set is changed during merging
Roundup Robot added the comment: New changeset 5c3812412b6f by Raymond Hettinger in branch '3.5': Issue #24583: Fix crash when set is mutated while being updated. https://hg.python.org/cpython/rev/5c3812412b6f New changeset 05cb67dab161 by Raymond Hettinger in branch 'default': Issue #24583: Fix crash when set is mutated while being updated. https://hg.python.org/cpython/rev/05cb67dab161 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24583 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On Wednesday 15 July 2015 19:29, Antoon Pardon wrote: Suppose I start with the following: def even(n): True if n == 0 else odd(n - 1) def odd(n): False if n == 0 else even(n - 1) Well, both of those always return None, so can be optimized to: even = odd = lambda x: None :-) Fixing the obvious mistake (failing to return anything) leads to the next mistake. When all you have is a hammer, everything looks like a nail. def even(n): return n%2 == 0 def odd(n): return n%2 != 0 are faster, easier to understand, and don't turn into an infinite loop if you pass a negative integer. The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. I do believe that such examples surely must exist. But I'm yet to see one. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Robin Becker ro...@reportlab.com: which is said to be not primitive recursive ie cannot be unwound into loops; not sure whether that implies it has to be recursively defined or can perhaps be broken down some other way. For more eye-glazing You only need a single while loop plus primitive recursion to implement total recursion. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why pay DICE When TheGongzuo.com is !! FREE !!
Steve Hayes wrote in message news:gaibqatads4eamjchr9k4f5tau30un2...@4ax.com... On Tue, 14 Jul 2015 17:31:31 -0700 (PDT), trentonwesle...@gmail.com wrote: Greetings! You been Invited as a Beta User for TheGongzuo.com ( Absolutely Extended Trial). We bring to you TheGongzuo.com, Top notch highly talented IT (Information Technology / Software Industry) skilled Professional Candidates, So what does it actually DO? I'm assuming that it's some kind of enhancement for Python, but why would anyone actually use it? Who cares. They are a spammer. Who cares what they do, the fact they spam means they are unethical and you should NOT use their services. They ask Why pay DICE When TheGongzuo.com is !! FREE !!, the answer is DICE is ethical and they don't spam. They have added the following to the message... This message is sent in compliance with the new email bill section 301. Under Bill S.1618 TITLE III passed by the 105th US Congress, this message cannot be considered SPAM as long as we include the way to be removed, Paragraph (a)(c) of S.1618, further transmissions to you by the sender of this email will be stopped if you by send a response of REMOVE in the subject line of the email, we will remove you immediately from subscription. This is Usenet which is tied an email list. Such appended text is inappropriate as they posted to Google Groups which is a Web Front-End ( HTTP/HTTPS ) to Usenet ( NNTP ). However lets assume it was sent via email. They use a BS disclaimer Under Bill S.1618 TITLE III passed by the 105th US Congress,.That's false. It was NOT passed. Even if it had been passed, it would have been superseded by the US Can Spam Act and Amendments. That is the law, not Bill S.1618 TITLE III which never became law. If you see the appended text Under Bill S.1618 TITLE III passed by the 105th US Congress,, now you also know they are complete morons. Furthermore, the IP address is 49.206.15.227. which is ACTFIBERNET-Secundrabad, Beam Telecom Pvt Ltd of India. -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
I'm ill, so I am not trusting my own reasoning further than I can jump (not too far today) but I don't think you have a problem that is well-suited to a mapping. But it seems like a perfect fit for a tree, to me. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
.. The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. I do believe that such examples surely must exist. But I'm yet to see one. I believe the classic answer is Ackermann's function http://demonstrations.wolfram.com/RecursionInTheAckermannFunction/ which is said to be not primitive recursive ie cannot be unwound into loops; not sure whether that implies it has to be recursively defined or can perhaps be broken down some other way. For more eye-glazing http://math.stackexchange.com/questions/75296/what-is-the-difference-between-total-recursive-and-primitive-recursive-functions -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
[issue17359] Mention __main__.py explicitly in command line docs
Ezio Melotti added the comment: See also #24632. -- nosy: +ezio.melotti type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24642] Will there be an MSI installer?
Changes by STINNER Victor victor.stin...@gmail.com: -- components: +Installation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24642 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On Thu, Jul 16, 2015 at 8:41 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Fixing the obvious mistake (failing to return anything) leads to the next mistake. When all you have is a hammer, everything looks like a nail. def even(n): return n%2 == 0 def odd(n): return n%2 != 0 are faster, easier to understand, and don't turn into an infinite loop if you pass a negative integer. Nice of you to illustrate how being pedantic about something, can make a response useless with regard to the intended original question. Sure your implementation for solving this particular problem is better if the purpose is to actually solve this problem. But it is useless as an illustration for the question I'm asking, which was about how to use a particular module. Once again, tail call optimization is used as a way to make something more efficient that shouldn't need to be done at all. Bubble sort takes too long when I give it 1000 elements. How can I make it faster? Before looking at code improvements or language improvements, it's crucial to do algorithmic improvements. The recursive even() and odd() functions are O(n), the modulo ones are O(1). Bubble sort is simply a terrible way to sort long lists. Time spent optimizing bubble sort is time utterly and totally wasted, because you'll get more benefit by switching to quicksort, insertion sort, or a hybrid like Timsort. Time spent eliminating tail call stack frames is equally useless if a small algorithmic change can eliminate the recursion altogether. That's why we need examples that *can't* be trivially reimplemented some other way. Unless, of course, *all* TCO examples, even real-world ones, could be trivially reimplemented some other way, a theory which is gaining currency... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On 16/07/2015 09:07, Steven D'Aprano wrote: . Fixing the obvious mistake (failing to return anything) leads to the next mistake. When all you have is a hammer, everything looks like a nail. def even(n): return n%2 == 0 def odd(n): return n%2 != 0 .. what about def odd(n): ... return bool(n%2) ... def even(n): ... return not odd(n) ... not much more complex, but the logic for A(n) and not A(n) is only done once. Not really much to do with TCO though. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
[issue23319] Missing SWAP_INT in I_set_sw
Matthieu Gautier added the comment: The bug is also present in Python 2.7. Is it possible to backport this fix ? -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 07/16/2015 10:07 AM, Steven D'Aprano wrote: On Wednesday 15 July 2015 19:29, Antoon Pardon wrote: Suppose I start with the following: def even(n): True if n == 0 else odd(n - 1) def odd(n): False if n == 0 else even(n - 1) Well, both of those always return None, so can be optimized to: even = odd = lambda x: None :-) Fixing the obvious mistake (failing to return anything) leads to the next mistake. When all you have is a hammer, everything looks like a nail. def even(n): return n%2 == 0 def odd(n): return n%2 != 0 are faster, easier to understand, and don't turn into an infinite loop if you pass a negative integer. Nice of you to illustrate how being pedantic about something, can make a response useless with regard to the intended original question. Sure your implementation for solving this particular problem is better if the purpose is to actually solve this problem. But it is useless as an illustration for the question I'm asking, which was about how to use a particular module. The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. So what did you expect? That I should give a real world example here with lots of details that would only detract from the information I'm looking for, just so that your curiosity would be satisfied? I'm not here to satisfy your or anyone else's curiosity. Certainly not when that curiosity often enough is just a pretext for donning the role of judge or arbiter and where any simplification that was done to make the example better understandable is siezed upon as a reason to dismiss it, because one looks at it litterally, like you do above, and is unable or unwilling to understand the spirit of the example. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
[issue24583] set.update(): Crash when source set is changed during merging
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24583 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24621] zipfile.BadZipFile: File is not a zip file
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24621 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Mapping, with sequence as key, wildcard and subsequence matching
Zachary Ware zachary.ware+pyl...@gmail.com writes: On Thu, Jul 16, 2015 at 1:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Fine by me. What is the mapping API that needs to be implemented though? Have a look at collections.MutableMapping. Thank you, that's great! I hadn't realised the ‘collections’ module had such comprehensive coverage of Python built-in type APIs. Now to focus back on the “existing debugged implementation” part :-) -- \ “Nothing is so common as to imitate one's enemies, and to use | `\ their weapons.” —Voltaire, _Dictionnaire Philosophique_ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Mapping, with sequence as key, wildcard and subsequence matching
On 16/07/2015 07:37, Ben Finney wrote: Ethan Furman et...@stoneleaf.us writes: On 07/15/2015 10:53 PM, Ben Finney wrote: Are those the ‘__contains__’, ‘__getitem__’ methods? What actually is the API of a mapping type, that would need to be customised for this application? The problem is that potential key matches are found by hashes For the Python ‘dict’ type, yes. I already know that I don't want that type, I want a custom mapping type which matches keys according to the algorithm I specify. So, I'm not asking “how do I make ‘dict’ do this?”. I am instead asking “how do I implement a custom type which can duck-type for ‘dict’ but have a different key-lookup implementation?”. https://docs.python.org/3/reference/datamodel.html?emulating-container-types quote The collections module provides a MutableMapping abstract base class to help create those methods from a base set of __getitem__(), __setitem__(), __delitem__(), and keys() /quote Hence https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping Hunting for examples got me to http://code.activestate.com/recipes/578096-a-mutablemapping-that-can-use-unhashable-objects-a/ so fingers crossed, I'm just hoping that we're going in the right direction. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue24632] Improve documentation about __main__.py
Davide Rizzo added the comment: As far as I understand, assuming dir/ contains a __main__.py file $ python dir is equivalent to $ python dir/__main__.py in that it's behaviourally nothing more than executing a script in that dir and setting sys.path accordingly. This is the same in Python 2 and Python 3. This, together with the notion that zip files and directories are treated in the same way, allows running python file.zip since we have no option for executing a file *within* the zip file. Altogether, this is a significantly different behaviour than the one for python -m pkg. That would be closer to: import pkg.__main__ This also explains why the package __init__ is executed first (you import the package first, then the module). A significant difference is that it's not a real import (just as pkg.__init__ is not imported) and sys.modules is not affected. -- nosy: +davide.rizzo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24632 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Mapping, with sequence as key, wildcard and subsequence matching
On 16/07/2015 08:09, Mark Lawrence wrote: On 16/07/2015 07:37, Ben Finney wrote: Ethan Furman et...@stoneleaf.us writes: On 07/15/2015 10:53 PM, Ben Finney wrote: Are those the ‘__contains__’, ‘__getitem__’ methods? What actually is the API of a mapping type, that would need to be customised for this application? The problem is that potential key matches are found by hashes For the Python ‘dict’ type, yes. I already know that I don't want that type, I want a custom mapping type which matches keys according to the algorithm I specify. So, I'm not asking “how do I make ‘dict’ do this?”. I am instead asking “how do I implement a custom type which can duck-type for ‘dict’ but have a different key-lookup implementation?”. https://docs.python.org/3/reference/datamodel.html?emulating-container-types quote The collections module provides a MutableMapping abstract base class to help create those methods from a base set of __getitem__(), __setitem__(), __delitem__(), and keys() /quote Hence https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping Hunting for examples got me to http://code.activestate.com/recipes/578096-a-mutablemapping-that-can-use-unhashable-objects-a/ so fingers crossed, I'm just hoping that we're going in the right direction. Drat, should have scrolled down one more page on the activestate recipe, Stephen D'Aprano comment. quote This is very ingenious, but I wouldn't want to touch it with a ten foot pole for production code /quote Eric Snow replied. quote Oh yeah. I wouldn't use it in production either. :) I expect you could iron out the wrinkles, but there are better solutions. /quote -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 07/16/2015 12:43 AM, Gregory Ewing wrote: Antoon Pardon wrote: But it doesn't need to be all or nothing. How about the following possibility. When the runtime detects a serie of tail calls, it will keep the bottom three and the top three backtrace records of the serie. Whatever value you choose for N, keeping only the first/last N traceback frames will lead to someone tearing their hair out. I would say, that someone should get over himself. Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. I recently had an experience with some Java code running in an environment which believed that nobody would want to see more than about 30 traceback levels, and chopped the rest off. Of course, the information I desperately wanted was buried deeper than that... So? My experience is, that if you need to dig that deep in a stack trace, to find the information you need, you get it easier and faster by turning debug level logging on and going through the logs. YMMV. I also have to wonder, In my suggestion you would only start to loose traceback records after six consecutive tail calls. That IMO strongly suggest a loop. Most people suggest such a loop should be written iteratively. So my example would allow to keep 6 trace back records through such a loop while the iterative version would only keep one trace back record. But no one seems to be tearing their hair out for not having trace back records of the previous run through a loop. Yet you protest when trace back records disappear when such a loop is written recursively. So, -1 on any arbitrarily chosen traceback cutoff. Noted. It just doesn't carry much weight with me. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Keypress Input
On 7/16/2015 12:30 AM, Michael Torrie wrote: On 07/15/2015 07:03 PM, Rick Johnson wrote: too much to quote I think you've missed the whole point of the OP's project. He doesn't want to make a GUI. He simply wants to have his program do something like blink an LED when someone presses a big red button. He just wanted a quick way to test things out since his big red button can emulate a USB keyboard. So all he needed was a simple console app that can fetch keystrokes. In the end, though GPIO is very simple both electrically and in terms of Python, so that is the ultimate route he will go. If you read his last post you'll find he says this. Rick pretty much acknowledged what you said in this paragraph. You may have solved your input capturing problem, and i don't think a GUI is the preferred solution for a graphically deficient device anyhow, but you may well need a GUI in the future, and this would be a fine example from which to learn. It is a fine example. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
RE: Where is pyvenv.py in new Python3.4 environment on CentOS7?
-Original Message- From: Python-list [mailto:python-list- bounces+dk068x=att@python.org] On Behalf Of Mark Lawrence Sent: Wednesday, July 15, 2015 3:23 PM To: python-list@python.org Subject: Re: Where is pyvenv.py in new Python3.4 environment on CentOS7? On 15/07/2015 22:54, David Karr wrote: I'm just learning more about Python (although I've been a Java dev for many years, and C/C++ before that). Welcome to the world of sanity after years of insanity :) Uh, right. We'll see about that. I have no complaints or issues with the Java ecosystem, it's just not used that much in networking, which I'm edging into. A book I'm reading (Learning Python Network Programming) refers to running pyvenv. I can find this in my Win7 environment, but I was planning on using my CentOS7 VM for most of this. I have both python (Python 2) and python3.4 installed. I noticed a python-virtualenv.noarch package, but it said it was already installed. Can someone elaborate on where I should be able to find or install this? On my Windows 8.1 box its under C:\Python34\Tools\Scripts Same as my Win7 box, but that's not what I need. I want to work on this on my CentOS7 box. (I tried asking this on the #python IRC channel, but I guess I couldn't yell loud enough.) Yelling doesn't get you very far in the Python world, been there, seen it, done it, failed miserably, started again. Funnily enough the second time around was far more succesful. Yeah, I wasn't serious. I wasn't really yelling, just asking polite questions. It just made it seem like I needed to (yell) because I appeared to be invisible. I'm sure I'll have better luck when I can ask more interesting questions. -- https://mail.python.org/mailman/listinfo/python-list
[issue24621] zipfile.BadZipFile: File is not a zip file
Serhiy Storchaka added the comment: unzip can't proceed this file too. $ unzip -v not_working.zip Archive: not_working.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of not_working.zip or not_working.zip.zip, and cannot find not_working.zip.ZIP, period. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24621 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Mapping, with sequence as key, wildcard and subsequence matching
On 16/07/2015 08:11, Ben Finney wrote: Zachary Ware zachary.ware+pyl...@gmail.com writes: On Thu, Jul 16, 2015 at 1:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Fine by me. What is the mapping API that needs to be implemented though? Have a look at collections.MutableMapping. Thank you, that's great! I hadn't realised the ‘collections’ module had such comprehensive coverage of Python built-in type APIs. You might get some inspiration from http://nullege.com/codes/search/collections.MutableMapping -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Antoon Pardon antoon.par...@rece.vub.ac.be writes: On 07/13/2015 05:44 PM, Th. Baruchel wrote: Hi, after having spent much time thinking about tail-call elimination in Python (see for instance http://baruchel.github.io/blog/ ), I finally decided to write a module for that. You may find it at: https://github.com/baruchel/tco Tail-call elimination is done for tail-recursion as well as for continuation-passing style (cps) in a consistent syntax for both usages. Any tail-recursive function having the suitable format for being embeddable in the Y combinator can be used here with no change at all (with the main difference that tail-calls will be eliminated), but other continuations can also be added Can you explain how you would do mutual recursive functions? Suppose I start with the following: def even(n): True if n == 0 else odd(n - 1) def odd(n): False if n == 0 else even(n - 1) How do I rewrite those with your module? I'm not sure the module mentioned above has provision for that, but in any case the Y combinator has a corresponding fixed-point combinator called Y*. There is quite a bit of theory behind this, anybody interested can google, e.g., Y combinator mutual recursion, whose first result is: http://stackoverflow.com/questions/4899113/fixed-point-combinator-for-mutually-recursive-functions -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
[issue24642] Will there be an MSI installer?
Matthew Barnett added the comment: There's an executable installer; it's a .exe instead of a .msi. -- nosy: +mrabarnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24642 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 07/16/2015 01:11 PM, Chris Angelico wrote:
On Thu, Jul 16, 2015 at 8:41 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
Fixing the obvious mistake (failing to return anything) leads to the next
mistake. When all you have is a hammer, everything looks like a nail.
def even(n):
return n%2 == 0
def odd(n):
return n%2 != 0
are faster, easier to understand, and don't turn into an infinite loop if
you pass a negative integer.
Nice of you to illustrate how being pedantic about something, can
make a response useless with regard to the intended original question.
Sure your implementation for solving this particular problem is better
if the purpose is to actually solve this problem. But it is useless as
an illustration for the question I'm asking, which was about how to
use a particular module.
Once again, tail call optimization is used as a way to make something
more efficient that shouldn't need to be done at all.
Once again, the intend of the example is ignored. The question was
not about how tail call optimization could be done on this specific
example. The question was about how it could be done generally and
this example was just used as a vehicle to get the question more
easily explained.
Bubble sort takes too long when I give it 1000 elements. How can I
make it faster?
But that is not a similar question. A similar question would have been
if someone would have trouble with making comparing items somehow
parametric is his function. So he writes a bubblesort to illustrate
that he somehow wants to specify on call time how items get compared.
And what happens is that lots of people start critisizing the bubble sort
and ignore the actual question, even though the question was not about
bubble sort. Bubble sort was just used as a vehicle to easily explain
the question.
Before looking at code improvements or language improvements, it's
crucial to do algorithmic improvements.
But we were not looking at code improvements here. We were looking
at how to use a particular module.
The recursive even() and odd()
functions are O(n), the modulo ones are O(1). Bubble sort is simply a
terrible way to sort long lists.
Which are all beside the point. The intent of the even and odd functions
was not to actually use them in production, but as a vehicle to ask someone
on how to use his module. For anyone in this context to seize upon the
particular implementation of those functions, is just making it clear
he completly missed the specific intend and used these examples to get
on his high horse.
Time spent optimizing bubble sort is
time utterly and totally wasted, because you'll get more benefit by
switching to quicksort, insertion sort, or a hybrid like Timsort. Time
spent eliminating tail call stack frames is equally useless if a small
algorithmic change can eliminate the recursion altogether.
That depends on the purpose. When the purpose is to learn something, it
may be usefull to spend time on code unfit for production, because such
code is often more comprehensible than code for which tco would be actually
useful. So here you are critisizing code meant to learn something, because
it isn't useful.
That's why we need examples that *can't* be trivially reimplemented
some other way.
These functions were not intented to provide such an example. I also
think that was rather clear. So critisizing them because they are not
is just disingenuous.
Unless, of course, *all* TCO examples, even real-world ones, could be
trivially reimplemented some other way, a theory which is gaining
currency...
Of course they could be rather trivially reimplemented. They would
also become rather ugly and less easy to comprehend.
Here is one way to do the odd, even example.
def even(n):
return odd_even('even', n)
def odd(n):
return odd_even('odd', n)
def odd_even(fn, n):
while fn is not None:
if fn == 'even':
fn, n = (None, True) if n == 0 else ('odd', n - 1)
elif fn == 'odd':
fn, n = (None, False) if n == 0 else ('even', n - 1)
else:
raise ValueError(Unknown state: %s % fn)
return n
Any collection of functions that tail calls each other can rather
trivially be turned into a state machine like the above. You can
just paste in the code of the individual functions and replace
the return call combo's with an assignment indicating which 'function'
is to be 'called' next and its arguments.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Robin Becker wrote: I believe the classic answer is Ackermann's function http://demonstrations.wolfram.com/RecursionInTheAckermannFunction/ which is said to be not primitive recursive ie cannot be unwound into loops; not sure whether that implies it has to be recursively defined or can perhaps be broken down some other way. For more eye-glazing But am I right in thinking that TCO doesn't work for Ackermann's function, at least not as it's written down in the above page? J. -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On Thu, Jul 16, 2015 at 11:35 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
Of course they could be rather trivially reimplemented. They would
also become rather ugly and less easy to comprehend.
Here is one way to do the odd, even example.
def even(n):
return odd_even('even', n)
def odd(n):
return odd_even('odd', n)
def odd_even(fn, n):
while fn is not None:
if fn == 'even':
fn, n = (None, True) if n == 0 else ('odd', n - 1)
elif fn == 'odd':
fn, n = (None, False) if n == 0 else ('even', n - 1)
else:
raise ValueError(Unknown state: %s % fn)
return n
Any collection of functions that tail calls each other can rather
trivially be turned into a state machine like the above. You can
just paste in the code of the individual functions and replace
the return call combo's with an assignment indicating which 'function'
is to be 'called' next and its arguments.
That's not an algorithmic change, though. That's just a mechanical
change, and a poorly-written one. My point was that I have yet to see
anything that demands TCO and can't be algorithmically improved. The
best so far has been a quicksort that uses TCO to guarantee a maximum
on stack usage.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
New submission from James Salter:
For python 3.5, PC/pyconfig.h contains the following for vs2015 support:
/* VS 2015 defines these names with a leading underscore */
#if _MSC_VER = 1900
#define timezone _timezone
#define daylight _daylight
#define tzname _tzname
#endif
This breaks any python extension code that includes pyconfig.h and then defines
any function or variable called 'timezone', 'daylight', or 'tzname'.
My breaking case is a conflict with ucrt/sys/timeb.h from the Windows 10 kit
(for me: c:\program files (x86)\Windows
Kits\10\include\10.0.10056.0\ucrt\sys\timeb.h). This is used during compilation
of gevent, which includes that file via libev/ev_win32.c. timeb.h contains this
innocent structure:
struct __timeb32
{
__time32_t time;
unsigned short millitm;
short timezone;
short dstflag;
};
I think we need a different approach that doesn't conflict with common english
variable names and in particular other windows SDK includes.
--
components: Extension Modules
messages: 246803
nosy: James Salter
priority: normal
severity: normal
status: open
title: VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24643
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/16/2015 01:45 PM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 5:31 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I would say, that someone should get over himself. Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. Actually, they do contain all of that (at least, they do in Py3 - not sure about Py2 as I haven't checked). You can poke around with the locals at every point on the stack: Fine, I should have been more clear. The stack trace as it is generally produced on stderr after an uncought exception, doesn't contain the values of the variables on the stack. Sure. So you catch it at top level and grab whatever info you need. In some frameworks, this is already done for you - an uncaught exception from application code drops you into a debugger that lets you explore and even execute code at any level in the stack. This would be destroyed by automated tail call optimization. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
Zachary Ware added the comment: I suppose we'll have to resort to #ifndef _Py_timezone #if _MSC_VER = 1900 #define _Py_timezone _timezone #else #define _Py_timezone timezone #endif #endif ... -- components: +Build, Windows -Extension Modules nosy: +paul.moore, steve.dower, tim.golden, zach.ware stage: - needs patch versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 07/16/2015 03:47 PM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 11:35 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Any collection of functions that tail calls each other can rather trivially be turned into a state machine like the above. You can just paste in the code of the individual functions and replace the return call combo's with an assignment indicating which 'function' is to be 'called' next and its arguments. That's not an algorithmic change, though. That's just a mechanical change, and a poorly-written one. What did you expect when you talked about all tco examples (including real world ones) and the reimplementation being trivial? My point was that I have yet to see anything that demands TCO and can't be algorithmically improved. And how is this point relevant? Why should I care about what you have not seen? Will it give me new insights about my original question in this thread? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 07/16/2015 04:00 PM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Fine, I should have been more clear. The stack trace as it is generally produced on stderr after an uncought exception, doesn't contain the values of the variables on the stack. Sure. So you catch it at top level and grab whatever info you need. In some frameworks, this is already done for you - an uncaught exception from application code drops you into a debugger that lets you explore and even execute code at any level in the stack. What is unclear about as it is generally produced on stderr? That you can do a whole lot of stuff, doesn't mean that this whole lot of stuff is part of what generally happens. When people on this list ask a person to include the stacktrace with the description of the problem, they don't mean something that includes the values of the variables. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 07/16/2015 01:45 PM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 5:31 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I would say, that someone should get over himself. Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. Actually, they do contain all of that (at least, they do in Py3 - not sure about Py2 as I haven't checked). You can poke around with the locals at every point on the stack: Fine, I should have been more clear. The stack trace as it is generally produced on stderr after an uncought exception, doesn't contain the values of the variables on the stack. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
Steve Dower added the comment: Or we could define _timezone on those platforms that don't have the underscore. I'm not hugely fussed either way. We need to fix this though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On Fri, Jul 17, 2015 at 12:21 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: My point was that I have yet to see anything that demands TCO and can't be algorithmically improved. And how is this point relevant? Why should I care about what you have not seen? Will it give me new insights about my original question in this thread? I guess you shouldn't care, because to you, functional programming is an end in itself, XKCD 1270 style. You could alternatively show an example, if there are any, but if you'd rather just live the functional life, who am I to stop you? Go ahead. Write LISP code that runs in the Python interpreter, and then bemoan the stack limit. Meanwhile, I'll write Python code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
STINNER Victor added the comment: Can't we move the #define only in .c files where they are needed? Or in a private header (not included by Python.h)? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
Steve Dower added the comment: That's probably an option, though it would break extensions that use `timezone` expecting it to work. But it seems like any change is going to cause that. I prefer defining _Py_timezone, since at least we can offer something that is portable for all Python 3.5 platforms (that support timezones), unlike timezone/_timezone (MSVC deprecated `timezone` a few versions ago and has just removed it completely, hence the breakage). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 07/16/2015 04:27 PM, Chris Angelico wrote: On Fri, Jul 17, 2015 at 12:21 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: My point was that I have yet to see anything that demands TCO and can't be algorithmically improved. And how is this point relevant? Why should I care about what you have not seen? Will it give me new insights about my original question in this thread? I guess you shouldn't care, because to you, functional programming is an end in itself, XKCD 1270 style. You are wrong and how is this relevant? I use the functional style when I think it is more useful way in implementing things. And that is in a minority of the cases. You not having seen anything that demands TCO and can't be algorithmically improved, doesn't change anything about that. You agreeing with me or not, doesn't change anything about that either. Please explain how it would make a difference for me, whether or not you were given such an example? You could alternatively show an example, if there are any? As far as I can see, such an example is not relevant in this topic. It doesn't help in any way clarify on how the module written by the topic starter is to be used. You and steven just blundered into this topic, as if others need to use examples that satisfy your curiosity instead of examples helpful to get their own question accross. Behaving as if this topic is about convincing either of you and getting indignant when I don't accept that change in subject. And you are still behaving here as if I should indulge you, as if I somehow owe you such an example. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Fri, Jul 17, 2015 at 2:50 AM, Joonas Liik liik.joo...@gmail.com wrote: Wouldn't it be possible to have like a dynamically sized stack so that you can grow it endlessly with some acceptable overhead.. That would pretty much take care of the stack-overflow argument without many painful side effects on the semantics at least.. The trouble with that is that it can quickly run you out memory when you accidentally trigger infinite recursion. A classic example is a simple wrapper function... def print(msg): print(ctime()+ +msg) With the recursion limit at its default of 1000, this can't do more than 1000 iterations before the system detects that it's stuck. With an infinite stack, this could destroy your system memory and then finally terminate with MemoryError... if you're lucky. If you're not, the whole system could get wedged before this gets killed. (Imagine, for instance, a computer with a large hard disk devoted to virtual memory. Long before that's exhausted, the system will be practically unusable, because every little operation will require going back to the disk.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 07/16/2015 09:43 AM, Chris Angelico wrote: True. That said, though, it's not a justification for dropping stack frames; even in the form that's printed to stderr, there is immense value in them. It may be possible to explicitly drop frames that a programmer believes won't be useful, but a general and automated dropping of tail-call information will do more harm than good. The fact that some frameworks can show _even more_ helpful information out of a traceback only makes this stronger. If we had a general mechanism then we would also need to have a setting somewhere so we could adjust which frames to keep when debugging. I must say I don't see much value in a stack trace that says a called b called c called a called b called c called a called ... -- particularly when the line quoted has only the variable names, not their values, so you can't see what's changing. Of this whole thread, though, I like the 'recurse' keyword proposal best -- I have no issues with the programmer specifying when to ditch the stack frame, but maybe that's my assembly roots showing. ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Thu, Jul 16, 2015 at 5:31 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/16/2015 12:43 AM, Gregory Ewing wrote: Antoon Pardon wrote: But it doesn't need to be all or nothing. How about the following possibility. When the runtime detects a serie of tail calls, it will keep the bottom three and the top three backtrace records of the serie. Whatever value you choose for N, keeping only the first/last N traceback frames will lead to someone tearing their hair out. I would say, that someone should get over himself. Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. Actually, they do contain all of that (at least, they do in Py3 - not sure about Py2 as I haven't checked). You can poke around with the locals at every point on the stack: def f(x): if x 10: g(x+10) return 5 def g(x): if x % 3: h(x + 2) return 7 def h(x): return 1/x try: x = -12 print(f(x)) except ZeroDivisionError as e: tb = e.__traceback__ while tb: fr = tb.tb_frame print(In function %s (%s:%d), x = %r % ( fr.f_code.co_name, fr.f_code.co_filename, fr.f_lineno, fr.f_locals[x], )) tb = tb.tb_next It's all there. And it's immensely helpful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[ANN] bcolz v0.10.0
===
Announcing bcolz 0.10.0
===
What's new
==
This is a cleanup-and-refactor release with many internal optimizations
and a few bug fixes. For users, the most important improvement is the
new-and-shiny context manager for bcolz objects. For example for the
ctable constructor::
with bcolz.ctable(np.empty(0, dtype=i4,f8),
...: rootdir='mydir', mode=w) as ct:
...: for i in xrange(N):
...:ct.append((i, i**2))
...:
bcolz.ctable(rootdir='mydir')
ctable((10,), [('f0', 'i4'), ('f1', 'f8')])
nbytes: 1.14 MB; cbytes: 247.18 KB; ratio: 4.74
cparams := cparams(clevel=5, shuffle=True, cname='blosclz')
rootdir := 'mydir'
[(0, 0.0) (1, 1.0) (2, 4.0) ..., (7, 49.0)
(8, 64.0) (9, 81.0)]
This is very useful for on-disk objects since it takes care of flushing
the data automatically. It works with all the top-level functions as
listed in: http://bcolz.blosc.org/reference.html#top-level-functions.
For a complete list of changes check the release notes at:
https://github.com/Blosc/bcolz/blob/master/RELEASE_NOTES.rst
What it is
==
*bcolz* provides columnar and compressed data containers that can live
either on-disk or in-memory. Column storage allows for efficiently
querying tables with a large number of columns. It also allows for
cheap addition and removal of column. In addition, bcolz objects are
compressed by default for reducing memory/disk I/O needs. The
compression process is carried out internally by Blosc, an
extremely fast meta-compressor that is optimized for binary data. Lastly,
high-performance iterators (like ``iter()``, ``where()``) for querying
the objects are provided.
bcolz can use numexpr internally so as to accelerate many vector and
query operations (although it can use pure NumPy for doing so too).
numexpr optimizes the memory usage and use several cores for doing the
computations, so it is blazing fast. Moreover, since the carray/ctable
containers can be disk-based, and it is possible to use them for
seamlessly performing out-of-memory computations.
bcolz has minimal dependencies (NumPy), comes with an exhaustive test
suite and fully supports both 32-bit and 64-bit platforms. Also, it is
typically tested on both UNIX and Windows operating systems.
Together, bcolz and the Blosc compressor, are finally fulfilling the
promise of accelerating memory I/O, at least for some real scenarios:
http://nbviewer.ipython.org/github/Blosc/movielens-bench/blob/master/querying-ep14.ipynb#Plots
Other users of bcolz are Visualfabriq (http://www.visualfabriq.com/) the
Blaze project (http://blaze.pydata.org/), Quantopian
(https://www.quantopian.com/) and Scikit-Allel
(https://github.com/cggh/scikit-allel) which you can read more about by
pointing your browser at the links below.
* Visualfabriq:
* *bquery*, A query and aggregation framework for Bcolz:
* https://github.com/visualfabriq/bquery
* Blaze:
* Notebooks showing Blaze + Pandas + BColz interaction:
* http://nbviewer.ipython.org/url/blaze.pydata.org/notebooks/timings-csv.ipynb
*
http://nbviewer.ipython.org/url/blaze.pydata.org/notebooks/timings-bcolz.ipynb
* Quantopian:
* Using compressed data containers for faster backtesting at scale:
* https://quantopian.github.io/talks/NeedForSpeed/slides.html
* Scikit-Allel
* Provides an alternative backend to work with compressed arrays
* https://scikit-allel.readthedocs.org/en/latest/bcolz.html
Installing
==
bcolz is in the PyPI repository, so installing it is easy::
$ pip install -U bcolz
Resources
=
Visit the main bcolz site repository at:
http://github.com/Blosc/bcolz
Manual:
http://bcolz.blosc.org
Home of Blosc compressor:
http://blosc.org
User's mail list:
bc...@googlegroups.com
http://groups.google.com/group/bcolz
License is the new BSD:
https://github.com/Blosc/bcolz/blob/master/LICENSES/BCOLZ.txt
Release notes can be found in the Git repository:
https://github.com/Blosc/bcolz/blob/master/RELEASE_NOTES.rst
**Enjoy data!**
--
https://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
[issue24644] --help for runnable stdlib modules
New submission from Antony Lee:
Support for python -mrunnable-stdlib-module [-h|--help] is a bit patchy right
now:
$ python -mpdb -h
usage: pdb.py [-c command] ... pyfile [arg] ...
help elided
$ python -mpdb --help
Traceback (most recent call last):
File /usr/lib/python3.4/runpy.py, line 170, in _run_module_as_main
__main__, mod_spec)
File /usr/lib/python3.4/runpy.py, line 85, in _run_code
exec(code, run_globals)
File /usr/lib/python3.4/pdb.py, line 1685, in module
pdb.main()
File /usr/lib/python3.4/pdb.py, line 1629, in main
opts, args = getopt.getopt(sys.argv[1:], 'hc:', ['--help', '--command='])
File /usr/lib/python3.4/getopt.py, line 93, in getopt
opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
File /usr/lib/python3.4/getopt.py, line 157, in do_longs
has_arg, opt = long_has_args(opt, longopts)
File /usr/lib/python3.4/getopt.py, line 174, in long_has_args
raise GetoptError(_('option --%s not recognized') % opt, opt)
getopt.GetoptError: option --help not recognized
# -- not a getopt specialist but --help is actually listed in the call to
getopt!
$ python -mtrace -h
/usr/lib/python3.4/trace.py: option -h not recognized
Try `/usr/lib/python3.4/trace.py --help' for more information
$ python -mtrace --help
Usage: /usr/lib/python3.4/trace.py [OPTIONS] file [ARGS]
help elided
--
components: Library (Lib)
messages: 246808
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: --help for runnable stdlib modules
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24644
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24630] null pointer dereference in `load_newobj_ex`
Brad Larsen added the comment: Yeah, this appears to be fixed along with #24552. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/16/2015 04:00 PM, Chris Angelico wrote: On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Fine, I should have been more clear. The stack trace as it is generally produced on stderr after an uncought exception, doesn't contain the values of the variables on the stack. Sure. So you catch it at top level and grab whatever info you need. In some frameworks, this is already done for you - an uncaught exception from application code drops you into a debugger that lets you explore and even execute code at any level in the stack. What is unclear about as it is generally produced on stderr? That you can do a whole lot of stuff, doesn't mean that this whole lot of stuff is part of what generally happens. When people on this list ask a person to include the stacktrace with the description of the problem, they don't mean something that includes the values of the variables. True. That said, though, it's not a justification for dropping stack frames; even in the form that's printed to stderr, there is immense value in them. It may be possible to explicitly drop frames that a programmer believes won't be useful, but a general and automated dropping of tail-call information will do more harm than good. The fact that some frameworks can show _even more_ helpful information out of a traceback only makes this stronger. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23247] Crash in the reset() method of StreamWriter of CJK codecs
Aaron Hill added the comment: I've added a test case to exercise reset() -- Added file: http://bugs.python.org/file39934/fix-multibytecodec-segfault-with-test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
Wouldn't it be possible to have like a dynamically sized stack so that you can grow it endlessly with some acceptable overhead.. That would pretty much take care of the stack-overflow argument without many painful side effects on the semantics at least.. -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On Thu, Jul 16, 2015 at 3:28 AM, Robin Becker ro...@reportlab.com wrote: .. The point is, people keep insisting that there are a vast number of algorithms which are best expressed using recursion and which require TCO to be practical, and yet when asked for examples they either can't give any examples at all, or they give examples that are not well-suited to recursion. Or, at best, examples which are equally good when written either using recursion or iteration. I do believe that such examples surely must exist. But I'm yet to see one. I believe the classic answer is Ackermann's function http://demonstrations.wolfram.com/RecursionInTheAckermannFunction/ which is said to be not primitive recursive ie cannot be unwound into loops; not sure whether that implies it has to be recursively defined or can perhaps be broken down some other way. My recollection -- and it's been awhile since I've studied computability theory so I may be distorting things here -- is that primitive recursive functions can be computed using for loops, i.e. loops where the number of iterations is bounded in advance, whereas non-primitive recursive functions require while loops. -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Wednesday, July 15, 2015 at 10:45:12 PM UTC-5, Chris Angelico wrote: A GUI is another form of console. And a blindingly obvious association is another form of patronizing! What's next, are you going to tell us that a Volvo is a street-legal Scandinavian version of an armored personal carrier? Or perhaps you'll *WOW* us with your knowledge that a penis is merely another form of editable sausage? OBVIOUSLY YOUR SAUSAGE WAS CANNED IN VIENNA! Not all programs are run in a situation where this makes sense. Really? I thought every situation was exactly the same. How foolish am i? Oh please enlighten us with more of your wisdom! Also, please don't post Py2-only code when the OP clearly stated that 3.4.3 was being used... Chris i hate to burst you're little naive vajayjay bubble, but a vast majority of the Python community is currently using, and will for many years continue using, Python3.0. Just because they don't participate here = in your private self-aggrandizing blog = does not mean they don't exist! See, unlike you, we didn't start writing Python code a few years ago. No, we skipped the pike detour through the intellectual ghetto, and we've been writing Python code for many years. And we have millions of lines of code in our repos! And we're not about to risk exception hell just so we can get a few meager new features and a kewel new print function. Besides, most of the new features have long ago been patched by creative programmers or are available via the: from __future__ import KEWEL_NEW_FEATURE I have a statement about what you can do with your print function, but executing that statement might result in this fine group throwing an IntegrityError. Therefor, i'll leave the interpretation of my statement as an academic exercise for all the Usenet eyeball-parsers. sys.exit(0) -- https://mail.python.org/mailman/listinfo/python-list
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
Justin Bronder added the comment:
On 16/07/15 20:03 +, R. David Murray wrote:
R. David Murray added the comment:
Can you expand on the deadlock? Are you saying that the extra locking is
causing the deadlock?
--
nosy: +r.david.murray, vinay.sajip
versions: -Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24645
___
Sure, here is the simplest example of the deadlock I could come up with. Using
__repr__() in the way presented is pretty stupid in this case but it does make
sense if you have objects which are backed by a database where communication is
handled in a separate thread.
What happens is this:
1. The main thread calls into the logger, handle() grabs the I/O lock.
2. String expansion of the Blah instance begins, this makes a request to the
second thread.
3. The second thread wants to log prior to responding, it gets stuck waiting
for
the I/O lock in handle()
import logging
import logging.handlers
import queue
import types
import threading
fmt = logging.Formatter('LOG: %(message)s')
stream = logging.StreamHandler()
stream.setFormatter(fmt)
log_queue = queue.Queue(-1)
queue_handler = logging.handlers.QueueHandler(log_queue)
queue_listener = logging.handlers.QueueListener(log_queue, stream)
queue_listener.start()
def handle(self, record):
rv = self.filter(record)
if rv:
self.emit(record)
return rv
# Uncomment to remove deadlock
#queue_handler.handle = types.MethodType(handle, queue_handler)
logger = logging.getLogger()
logger.addHandler(queue_handler)
logger.setLevel(logging.DEBUG)
class Blah(object):
def __init__(self):
self._in = queue.Queue()
self._out = queue.Queue()
def pub():
self._in.get(block=True)
logging.info('Got a request')
self._out.put('hi')
self._pub_thread = threading.Thread(target=pub)
self._pub_thread.start()
def __repr__(self):
self._in.put('gimme data')
return self._out.get()
def __del__(self):
self._pub_thread.join()
b = Blah()
logger.info('About to log')
logger.info('blah = %s', b)
queue_listener.stop()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24645
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19918] PureWindowsPath.relative_to() is not case insensitive
Changes by Aaron Meurer aaron.meu...@continuum.io: -- nosy: +Aaron Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Keypress Input
On 07/16/2015 11:22 AM, Rick Johnson wrote: On Wednesday, July 15, 2015 at 11:30:40 PM UTC-5, Michael Torrie wrote: On 07/15/2015 07:03 PM, Rick Johnson wrote: too much to quote I think you've missed the whole point of the OP's project. Obviously my reply was not only too much to quote, but apparently, and sadly, too much to read! I don't know about anyone else here, but i would be cautious about replying to any post before i took the time to read the entire content. I mean, i'd wouldn't want to embarrass myself. I read a good deal of what you wrote, which is more than most do with such long, rambling posts. Good to know there were some good nuggets in there. This is as much as I read of your current post though. As soon as you started going off about gold fish, I'm out. It's true that attention spans are shorter these days. But it's also true there are ways of being concise. -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Thursday, July 16, 2015 at 3:11:56 PM UTC-5, Chris Angelico wrote: Where's the latest survey results? I think the numbers don't agree with you any more. Not that there's a source for that info, but a quick survey of yahoo results certainly continues to show more v2 activity. --anytime-- python v3 -- 143 python v2 -- 189 --Past month-- python v3 -- 386000 python v2 -- 554000 Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On Fri, Jul 17, 2015 at 4:23 AM, Joonas Liik liik.joo...@gmail.com wrote: On 16 July 2015 at 20:49, Chris Angelico ros...@gmail.com wrote: This sounds like a denial-of-service attack. If you can state that no reasonable document will ever have more than 100 levels of nesting, then you can equally state that cutting the parser off with a tidy exception if it exceeds 100 levels is safe. This particular example does have that kind of smell.. my bad for being careless with examples. what if its not a ddos tho, maybe its just strange data? That's why you're allowed to change the default limit either direction. If you're guarding against a DOS, you can crank it down; if you're working with something where 1000 stack entries isn't unreasonable, you can crank it up. I honestly don't know what you'd want to do if 5000+ stack entries isn't enough, but if you're working with something *that* deeply nested, you probably know a lot more about what you're doing than I ever will. Maybe you could recompile CPython with a bigger stack? Give Jython or PyPy a try? No idea. But I'm sure it'd be possible somehow. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
New submission from Justin Bronder: The Queue backing the QueueHandler is already sufficiently locking for thread-safety. This isn't a huge issue, but the QueueHandler is a very nice built-in which could be used to work around a deadlock I've encountered several times. In brief, functions which can cause other threads to log being called from either __repr__() or __str__(). -- components: Library (Lib) files: queue-handler-no-lock.patch keywords: patch messages: 246812 nosy: jsbronder priority: normal severity: normal status: open title: logging.handlers.QueueHandler should not lock when handling a record versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39935/queue-handler-no-lock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
Steve Dower added the comment: It's not, but #include python.h in any extension will make it available for you, so it's very likely that extensions have simply used it without adding their own conditional compilation for the various interpretations of whether timezone is standard or not. Bit of a strawman, granted. Maybe working at Microsoft has made me overly cautious about changes that could break *anyone* - it's a big deal in many groups here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Noob in Python. Problem with fairly simple test case
On Thursday, July 16, 2015 at 3:11:56 PM UTC-5, Chris Angelico wrote: Where's the latest survey results? I think the numbers don't agree with you any more. What? You think the handful of regulars on this list in any way shape or form somehow represents the multitude of *REAL* python programmers who work day in and day out in the trenches? ON THE FRONT LINES! Heck you're more naive than the BDFL: who gets a woody simply from gawking at that atrociously inaccurate TIOBI index! Oooh. Oooh. Python is moving up the list! Yeah, it's not just Python that's moving up. Besides, everybody knows his bots are out there manipulating the numbers! -- https://mail.python.org/mailman/listinfo/python-list
[issue23601] use small object allocator for dict key storage
Mark Shannon added the comment: +1 from me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23601 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How does a dictionary work exactly?
On Thu, Jul 16, 2015 at 1:36 PM, yoursurrogate...@gmail.com yoursurrogate...@gmail.com wrote: If I understand correctly, lookup would not be a constant, yes? On the contrary, that's what you desire, nearly constant time execution. To the greatest extent possible, you want the linked lists to be of length zero or one. Part of the magic is in figuring out good places to expand the size of the hash array. You don't want it to grow too big, but you still want most linked lists to be very short. The resize operation isn't done too often because it itself is expensive. I believe Python dicts start out with an overly large initial hash array (again, dredging up old memories of threads on python-dev) as an optimization to avoid lots of early resize operations. Skip -- https://mail.python.org/mailman/listinfo/python-list
[issue24646] Python accepts SSL certificate that should be rejected on OSX
New submission from Jussi Pakkanen:
Create a dummy certificate and build an ssl context like this:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cadata=dummy_certificate)
Then try to connect to a public service like this:
u = urllib.request.urlopen('https://www.google.com', context=ctx)
data = u.read()
Python will validate the server certificate even though it should reject it.
Attached is a script to demonstrate this.
This happens with Python 3.4.3 on OSX 10.10.4. Running the same script in
Ubuntu raises a certificate rejection exception as expected.
--
components: Library (Lib)
files: sslbug.py
messages: 246813
nosy: jpakkane
priority: normal
severity: normal
status: open
title: Python accepts SSL certificate that should be rejected on OSX
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file39936/sslbug.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24646
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Noob in Python. Problem with fairly simple test case
On Fri, Jul 17, 2015 at 6:03 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: but a vast majority of the Python community is currently using, and will for many years continue using, Python3.0. Where's the latest survey results? I think the numbers don't agree with you any more. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23247] Crash in the reset() method of StreamWriter of CJK codecs
Roundup Robot added the comment: New changeset 35a6fe0e2b27 by Victor Stinner in branch '3.4': Closes #23247: Fix a crash in the StreamWriter.reset() of CJK codecs https://hg.python.org/cpython/rev/35a6fe0e2b27 -- nosy: +python-dev resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
STINNER Victor added the comment: For me, it's not the responsability of python.h to ensure that the timezone symbol is available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h
Steve Dower added the comment: Agreed. However, I also don't want extensions to stop building because of a change we make. But since that's inevitable here, let's go with Zach's original suggestion and use a name that won't conflict. (IIRC, I originally put the #ifdefs in each file and was told to move them to pyconfig.h...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24647] Document argparse.REMAINDER as being equal to ...
New submission from Antony Lee:
Currently the argparse docs mention the special values +, * and ? by
their actual values instead of argparse.{ONE_OR_MORE,ZERO_OR_MORE,OPTIONAL},
but argparse.REMAINDER is mentioned as is. It seems easier to just use its
actual value (...) in the docs as well.
--
components: Library (Lib)
messages: 246824
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Document argparse.REMAINDER as being equal to ...
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24647
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24648] Allocation of values array in split dicts should use small object allocator.
New submission from Mark Shannon: Issue 23601 advocates using the small object allocator for dict-keys objects and the results of tests are good. Using the small object allocator for dict value-arrays as well seems like the obvious next step. -- components: Interpreter Core keywords: easy messages: 246828 nosy: Mark.Shannon priority: low severity: normal stage: needs patch status: open title: Allocation of values array in split dicts should use small object allocator. type: performance versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24648 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 7/16/2015 2:02 PM, Ethan Furman wrote:
On 07/16/2015 06:35 AM, Antoon Pardon wrote:
Here is one way to do the odd, even example.
def even(n):
return odd_even('even', n)
def odd(n):
return odd_even('odd', n)
def odd_even(fn, n):
while fn is not None:
if fn == 'even':
fn, n = (None, True) if n == 0 else ('odd', n - 1)
elif fn == 'odd':
fn, n = (None, False) if n == 0 else ('even', n - 1)
else:
raise ValueError(Unknown state: %s % fn)
return n
Wow -- definitely uglier and less easy to understand than the original
(even if the original had had the error-checking).
What you call ugly is an example of the core of the proof that
alternation and indefinite while looping are enough for turing
completeness, and that no recursive syntax is needed. Another way to
put it is that while loops perform recursion in the operational sense,
as opposed to the syntactical sense.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Nobody seemed to notice that I just posted a fairly typical tail call function: def setvalue(self, keyseq, value, offset=0): try: next = keyseq[offset] except IndexError: self.value = value return if next is Node.ANY: raise KeyError() try: child = self.children[next] except KeyError: self.children[next] = child = Node() child.setvalue(keyseq, value, offset + 1) In the context, the tail call is at least as clear as the corresponding while/for loop. In the case of this function, tail call elimination is hardly needed because the key sequence is probably not all that long (and if it were, the accompanying lookup function would overflow the stack anyway). At any rate, it demonstrates how the idiom has its place in Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
[issue23601] use small object allocator for dict key storage
Mark Shannon added the comment: Yes, but that shouldn't block this issue. I've opened issue 24648 instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23601 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
On 07/16/2015 12:14 PM, Joonas Liik wrote: You are giving the programmer a choice between run out of stack and crash and mutilate interpreter internals and crash or zero out the hard drive this is not a real choice.. +1 -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
R. David Murray added the comment: Can you expand on the deadlock? Are you saying that the extra locking is causing the deadlock? -- nosy: +r.david.murray, vinay.sajip versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
