[issue1226] lib/sched.py superfluous code for removal
New submission from lorph: Line 114 of lib/sched.py: It has a superfluous variable assignment which I deleted. "void =" -- components: Library (Lib) files: sched.py messages: 56210 nosy: lorph severity: normal status: open title: lib/sched.py superfluous code for removal versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1226> __"""A generally useful event scheduler class. Each instance of this class manages its own queue. No multi-threading is implied; you are supposed to hack that yourself, or use a single instance per application. Each instance is parametrized with two functions, one that is supposed to return the current time, one that is supposed to implement a delay. You can implement real-time scheduling by substituting time and sleep from built-in module time, or you can implement simulated time by writing your own functions. This can also be used to integrate scheduling with STDWIN events; the delay function is allowed to modify the queue. Time can be expressed as integers or floating point numbers, as long as it is consistent. Events are specified by tuples (time, priority, action, argument). As in UNIX, lower priority numbers mean higher priority; in this way the queue can be maintained as a priority queue. Execution of the event means calling the action function, passing it the argument. Remember that in Python, multiple function arguments can be packed in a tuple. The action function may be an instance method so it has another way to reference private data (besides global variables). Parameterless functions or methods cannot be used, however. """ # XXX The timefunc and delayfunc should have been defined as methods # XXX so you can define new kinds of schedulers using subclassing # XXX instead of having to define a module or class just to hold # XXX the global state of your particular time and delay functions. import heapq __all__ = ["scheduler"] class scheduler: def __init__(self, timefunc, delayfunc): """Initialize a new instance, passing the time and delay functions""" self.queue = [] self.timefunc = timefunc self.delayfunc = delayfunc def enterabs(self, time, priority, action, argument): """Enter a new event in the queue at an absolute time. Returns an ID for the event which can be used to remove it, if necessary. """ event = time, priority, action, argument heapq.heappush(self.queue, event) return event # The ID def enter(self, delay, priority, action, argument): """A variant that specifies the time as a relative time. This is actually the more commonly used interface. """ time = self.timefunc() + delay return self.enterabs(time, priority, action, argument) def cancel(self, event): """Remove an event from the queue. This must be presented the ID as returned by enter(). If the event is not in the queue, this raises RuntimeError. """ self.queue.remove(event) heapq.heapify(self.queue) def empty(self): """Check whether the queue is empty.""" return not self.queue def run(self): """Execute events until the queue is empty. When there is a positive delay until the first event, the delay function is called and the event is left in the queue; otherwise, the event is removed from the queue and executed (its action function is called, passing it the argument). If the delay function returns prematurely, it is simply restarted. It is legal for both the delay function and the action function to to modify the queue or to raise an exception; exceptions are not caught but the scheduler's state remains well-defined so run() may be called again. A questionably hack is added to allow other threads to run: just after an event is executed, a delay of 0 is executed, to avoid monopolizing the CPU when other threads are also runnable. """ # localize variable access to minimize overhead # and to improve thread safety q = self.queue delayfunc = self.delayfunc timefunc = self.timefunc pop = heapq.heappop while q: time, priority, action, argument = checked_event = q[0] now = timefunc() if now < time: delayfunc(time - now) else: event = pop(q) # Verify that the event was not removed or altered #
[issue1226] lib/sched.py superfluous code for removal
Changes by lorph: -- severity: normal -> minor type: -> resource usage __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1226> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: May I recommend using libtomcrypt instead of openssl because of the advertising problem outlined here? http://bugs.python.org/issue9119 In my opinion, libtomcrypt is easier to use and cleaner. It compiles on Windows without requiring Perl, and is free of the advertising clause in OpenSSL since it is public domain. http://libtom.org/?page=features&newsitems=5&whatfile=crypt -- nosy: +lorph ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: > OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most > cases. Gregory, do you have any evidence to substantiate this claim? Not that it isn't plausible, but I couldn't find any benchmarks, and here the author of libtomcrypt finds it to be 40% faster than OpenSSL concerning RSA operations. http://www.adras.com/TomsFastMath-faster.t71-93.html > but I am generally in favor of absolute performance per byte of all > algorithms concerned being available Performance isn't all that matters, or else Python would have used GMP, as Guido discussed here: http://mail.python.org/pipermail/python-3000/2007-September/010329.html It is also not a convincing argument that new python libraries should use OpenSSL if possible just because that is what _ssl uses. Compiling Python with OpenSSL support has been optional because it puts additional restrictions on the PSF license. Spreading this restriction to the future crypto module (when we have a choice not to) doesn't make sense. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: > It certainly makes more sense than making Python depend on *several* crypto > libraries. Since libtomcrypt is public domain, you could incorporate the source into the tree without making it a binary dependency. The same cannot be said for OpenSSL. I certainly wouldn't mind having 1 dependency on NSS, but having 2 modules depend on OpenSSL is a step in the wrong direction. > As for the licensing restriction, it doesn't seem to disturb many Python > users. It's the first time I see someone complaining about it. It took several years until someone like Marc-Andre Lemburg to find that the Python website might be violating that license. Perhaps the reason is because no one bothers to read licenses carefully. People are probably violating the license without knowing it. If you take a look at the clause "All advertising materials mentioning features or use of this software must display the following acknowledgment", you will find at least 2 problems. One is that if you mention something like "base64" in whatever could be deemed "advertising", you will be subject to this clause because base64 is a feature of OpenSSL, even if you don't use their implementation. Another problem is the difference between the clause "features or use of this software", which is semantically different from "features of this software or use of this software". Is it worth the risk to depend on Eric Young's proclivity to sue now that he works for RSA and produces competing software called BSAFE? Maybe it is for you, but certainly not for me. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: > The solution to stop violating it is trivial, though: just add the required mention(s). That only solves the problem for Python.org. It does not solve the problem for everyone else that has to write "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) This product includes cryptographic software written by Eric Young (e...@cryptsoft.com)" in advertisement that mentions features. > Unless "base64" is an OpenSSL trademark, this is FUD. The license clearly states: "All advertising materials mentioning features or use of this software". Do you somehow disagree that base64 is a feature of the OpenSSL library? http://www.openssl.org/docs/crypto/BIO_f_base64.html -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: > Do you think that if OpenSSL provided its own implementation of strlen(), > every text that mentions strlen() needs to acknowledge OpenSSL? Do you > realize how ridiculous that is? If that text is deemed to be advertising by Eric Young and a court of law, then absolutely yes. The license is short, clear, and does not make any exceptions for features that you might deem to be commonplace. http://www.openssl.org/source/license.html I also agree that this is ridiculous, but believing something is ridiculous does not make it any less real as Barnes and Nobles learned the hard way by using Amazon's one-click patent. > The important thing to realize is that libtomcrypt is intentionally written in very portable C. That is great but it leaves a lot on the table. Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as [...] are not likely to be part of libtomcrypt, A quick glance at libtomcrypt tells me otherwise. It is portable C, but it still has inline assembler. It has optimizations using SSE2, x86, x86_64, and PPC32. Even though it might not have that new Intel AES instruction yet, this is the same argument people had for using GMP for python's integers. If there is a problem with multiple libraries, I'd like to reiterate my support for migrating to NSS. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
lorph added the comment: > The license of a software product cannot affect software that is not even > aware of that said product. I never claimed that the clause triggered for all software in existence. We are talking about OpenSSL being bundled with Python where Python is very much aware of OpenSSL. Provided the following 3 circumstances are met, the advertisement clause applies: 1. You are distributing Python with OpenSSL 2. You are "advertising". 3. Your advertising mentions features. By mentioning features of Python, or even a feature of OpenSSL you don't even use (base64), by the wording of the license you are obligated to also advertise OpenSSL and Eric Young. This obviously has a chilling effect on the distribution and advertising of Python apps. Think about the 100 char blurb on every small web banner. > In fact, if fast means "vulnerable to side-channel cryptanalysis" I'm firmly > opposed to it, and I don't know if that's the case here. OpenSSL has at least > been subject to significant attention in that regard. LTC does address side-channel attacks, but this is a moot point since by using a high level language like Python, you are vulnerable to memory scanning since you cannot normally zero out Python strings (something you may wish to consider in the crypto API). I'd also add that the "rounds" option should be left in for compatibility reasons. For easy usage, a default such as CBC could be specified. Otherwise, I don't think there is anything wrong with the API. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672115] Assignment to __bases__ of direct object subclasses
lorph <[EMAIL PROTECTED]> added the comment: Is anyone still working on this? It seems like an oddity of python that has been a stumbling block for me to create a super reload. I've found that i am able to bypass this problem by creating the following definition: class object(object):pass However, this feels like an ugly hack. ------ nosy: +lorph ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue672115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
