Repetition of work in Jython

Hi all, So from what I understand, Jython translates Python code into JVM byte code. Does anyone know why this was chosen instead of translating Python bytecode to JVM bytecode directly? It seems that it would be a lot easier to get Jython up-to-speed if there could be some "shared components" bet

Re: Down casting Python objects

On Wed, Mar 10, 2010 at 12:24 AM, Rami Chowdhury wrote: > Could you tell us *why* you need to down-cast x? Explicit type-casting is > usually unnecessary in Python... Sure! It's related to the longer question I unwisely asked during PyCon [1] (when no one had time to read it, I suppose). I hav

Down casting Python objects

So I have `x', a instance of class `Foo'. I also have class `Bar', a class extending `Foo' with a couple of methods. I'd like to "down cast" x as efficiently as possible. Is it OK to just set `x.__class__ = Bar' and expect things to work OK in all major versions of CPython? -- http://mail.python.o

Re: Chaining 501 generators breaks everything?

Ack, just ran it from shell, realized my editor was just choking on a "maximum recursion depth exceeded" RuntimeError. Didn't realize generators used the call stack... - Andrey On Fri, Feb 19, 2010 at 2:47 PM, Andrey Fedorov wrote: > I implemented a Sieve of &

Chaining 501 generators breaks everything?

I implemented a Sieve of Eratosthenesprimes algorithm using generators: http://gist.github.com/309109 This code which chains together 500 generators works fine (~1/20th of a second) on my laptop. The code which chaines 501 generators (s/498/499

Bypassing properties on an object (also with __slots__?)

Two questions: 1 - is it documented that o.__dict__[attr] is a reliable way to bypass property methods? 2 - can one bypass a property method if the class has __slots__? Reason: I have a couple of different flavors of request objects which I need to make lazily conform to a standard interface. As

Re: Constraints on __sub__, __eq__, etc.

Hansen wrote: > On Thu, Feb 18, 2010 at 8:19 AM, Andrey Fedorov wrote: > >> It seems intuitive to me that the magic methods for overriding the +, -, >> <, ==, >, etc. operators should have no sideffects on their operands. Also, >> that == should be commutative and

Constraints on __sub__, __eq__, etc.

It seems intuitive to me that the magic methods for overriding the +, -, <, ==, >, etc. operators should have no sideffects on their operands. Also, that == should be commutative and transitive, that > and < should be transitive, and anti-commutative. Is this intuition written up in a PEP, or assu

Re: Checking if a function invocation will throw a TypeError?

Will do, thanks. Doing it to make a @curry decorator, which only executes a function once enough arguments have been passed in. - Andrey On Thu, Oct 29, 2009 at 6:53 PM, Chris Rebert wrote: > On Thu, Oct 29, 2009 at 11:43 AM, Andrey Fedorov > wrote: > > Is there a standard functi

Checking if a function invocation will throw a TypeError?

Is there a standard function that will check whether certain *args, and **kwargs satisfy a argspec of a function (s.t. it does not throw a TypeError). Say: def foo(a,b=1): pass check(foo, 1,2) # True check(foo, 1) # True check(foo) # False check(foo, 1, a=2) # False Cheers, Andrey -- http:/

How different are a generator's send and next methods

As far as I can tell, a generator's .next() is equivalent to .send(None). Is this true? If so, aren't they unified in a method with a single argument which defaults to None? - Andrey -- http://mail.python.org/mailman/listinfo/python-list

Re: Function to apply superset of arguments to a function

equest.POST else > None > ... > This is especially useful both when adding/removing POST variables, and when there end up being a lot of them. Cheers, Andrey On Wed, Sep 9, 2009 at 1:40 PM, David Stanek wrote: > On Wed, Sep 9, 2009 at 12:45 PM, Andrey Fedorov > wrote: > >

Function to apply superset of arguments to a function

Hi all, I've written a function [1] called apply_some which takes a set of keywords arguments, filters only those a function is expecting, and calls the function with only those arguments. This is meant to suppress TypeErrors - a way to abstract the logic which checks what arguments a passed-in fu