s until you call
its next() method.
> Q2: Is there a way that handles both lists and generators, so I don't
> have to worry about which one I've got?
I don't think this is possible. A generator must be called (with
next()) in order for its code to take over and see if it is e
python_org();
system ("install_python.exe");
goto have_python;
}
Seriously, people who want executables wouldn't notice the difference.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Mike Meyer wrote:
jfj <[EMAIL PROTECTED]> writes:
I think a better question would be "What do *generator expressions* do
that list comprehensions don't?". And always use list comprehensions
unless you want the extra bit.
As the OP, I can say why I didn't ask tho
Robert Kern wrote:
jfj wrote:
2) to convert a list/tuple/string to a list, which is
done extremely fast.
Add "any iteratable". Genexps are iterables.
The thing is that when you want to convert a tuple to a list
you know already the size of it and you can avoid using append()
and exp
I jfj wrote:
make_fractal_with_seed (x for x in range(1) if fibonacci_prime
(x))
and this is stupendus.
At least range should be xrange.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
ter('(.*)address(.*)')
writeMask=makewriter('(.*)netmask(.*)')
This is rather advanced python programming though, but it shows
cool dynamic function creation features and it's never early to
get into it;)
jfj
--
http://mail.python.org/mailman/listinfo/python-list
n we should also remove:
x=[] to x=list()
x=[1,2,3] to x=list(1,2,3)
I think "list" is useful only:
1) to subclass it
2) to convert a list/tuple/string to a list, which is
done extremely fast.
But for iterators I find the list comprehension syntax nicer.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Swaroop C H wrote:
AFAIK, there isn't any reliable way to call Perl modules from Python.
pyperl. pyperl. pyperl.
+10 on making this a standard module for embrace+extend reasons
*and* because perl is not that bad after all.
jf
--
http://mail.python.org/mailman/listinfo/python-list
Peter Otten wrote:
To confuse a newbies and old hands alike, Bengt Richter wrote:
got me for one:)
To make it a bit clearer, a StopIteration raised in a generator expression
silently terminates that generator:
*any* exception raised from a generator, terminates the generator
jfj
--
http
Peter Otten wrote:
Child()
child
father
mother
parent # <-- parent only once
<__main__.Child object at 0x402ad38c>
D-uh?
class Parent(object):
def __init__(self):
print "parent"
super(Parent, self).__init__()
class Father
Peter Otten wrote:
jfj wrote:
Peter Otten wrote:
Here is an alternative approach that massages the initializer signatures
a bit to work with super() in a multiple-inheritance environment:
super(Father, self).__init__(p_father=p_father, **more)
Is there any advantage using super in this
.__init__ (self, params) is simpler
and does the job perfectly well.
super seems to be needed in "Dynamic Inheritance" cases where
we don't know an object's bases and there are comlicated mro issues!
jfj
--
http://mail.python.org/mailman/listinfo/python-list
fort were poured into speeding
up Python as Sun devoted to Java, Python would be better than Java in every
respect."
Except from a the standard, powerful,
looks-good-everywhere-and-has-a-tree-widget GUI toolkit? :)
Seriously, I think this is *very* important.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Dan Bishop wrote:
x = 17
sum(x for x in xrange(101))
5050
x
17
Your example with generator expressions is interesting.
Even more interesting is:
def foo(x):
y= (i for i in x)
return y
From the disassembly it seems that the generator is a code object but
'x' is not a cell variable. WTF?
t; in global_dictionary, local_dictionary
In this case it uses the opcode LOAD_NAME which looks first in locals
and then in globals (and actually, then in __builtins__)
For functions it uses either LOAD_FAST for locals or LOAD_GLOBAL for
globals.
HTH
jfj
--
http://mail.python.org/mailman/listinfo/python-list
s in the __dict__ of the instance, indeed.
OTOH, I'm talking about the "concept of python" and not CPython
implementation, and that's why I have these questions:)
Thanks,
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch wrote:
Moreover the documentation
sais that if the first argument is an instance, its class will be
used for the classmethod. OTOH, "class scope" is not a real thing in
python. It is just some code which is executed and then we get its
locals and use it on Class(localsDict, Base
Diez B. Roggisch wrote:
I understand that this is a very peculiar use of
classmethods but is this error intentional?
Or did I completely missed the point somewhere?
A little bit: classmethods are defined in a class context.
def foo(cls):
print cls
class A:
foo = classmethod(foo)
The error
Hi.
Suppose this:
def foo (x):
print x
f = classmethod (foo)
class A: pass
a=A()
a.f = f
a.f()
# TypeError: 'classmethod' object is not callable!
###
I understand that this is a very peculiar use of
classmethods but is this error intentional?
Or did
Carl Banks wrote:
transformations gets rebound, so you'd need a reference to it.
That certainly is an application. I guess it depends on one's
programming background.
I'd only use nested (function, class) definition to accomplish
such a feature:
def genclass(x,y):
clas
Antoon Pardon wrote:
Op 2005-02-19, jfj schreef <[EMAIL PROTECTED]>:
once foo() returns there is no way to modify 'x'!
It becomes a kind of constant.
In this particular case yes. But not in general, what about
this:
def F():
... l = []
... def pop():
... return l.pop()
It carries around a silly cell object for the
rest of its lifetime. see xx.func_closure.
At least, I think this is what happens...
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
jfj wrote:
Carl Banks wrote:
Ted Lilley wrote:
Unfortunately, it doesn't work. It seems the closure keeps track
of
the variable fed to it dynamically - if the variable changes after
[...]
At least, that's the explanation I'm deducing from this behavior.
And tha
sted functions that
reference variables from their outer scope"? (although if find
this little useful and un-pythonic)
Personally, i think that this is a problem with the way lisp
and other languages define the term "closure". But python is
different IMO, and the ability to referenc
Fredrik Lundh wrote:
"jfj" <[EMAIL PROTECTED]> wrote:
Wait! second that. We would like to
hmm. are you seconding yourself, and refering to you and yourself as we?
:)
"we" refers to all python users.
no. your foo() function raises B, and is called from the exception
bruno modulix wrote:
Ilias Lazaridis wrote:
I'm a newcomer to python:
[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/comp.lang.python/msg/75f0c5c35374f553
My trollometer's beeping...
When person 'A' calls person 'B' a troll, these are the possibilities:
jfj wrote:
IMHO, a more clean operation of raise would be either:
1) raise w/o args allowed *only* inside an except clause to
re-raise the exception being handled by the clause.
Wait! second that. We would like to
###
def bar():
raise
def b5():
try:
raise A
like to ask: Are the semantics of 'raise w/o args' a result of
python's implementation? If python was re-designed, would that
be different? In python 3000, would you consider changing this
and if yes, to what semantics? May this be changed in 2.5?
Thanks
jfj
-
#
;t be free if
it wasn't for gcc. Just for that I _believe_ python, being open source,
should support mingw as the default. But I *don't care* and I don't
mind, really ;)
jfj
--
http://mail.python.org/mailman/listinfo/python-list
ay* matter AFAIK, may be threads. Because each thread
has its own stack --in non-stackless python-- stack size may be an issue
if it's too much and there are **many** threads. Otherwise, it should
not have any impact on performance.
jfj
# cure to insomnia: when you lay down, try to figure out
Brian Beck wrote:
print "Closed: %s" % fileName
Call me a pedant, but what'd wrong with:
print 'closed: ' + filename
or
print 'closed:', filename
?
Modulus operator good but don't over-use it. Otherwise, bad style.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
as to capture people as they were.
So I think the lack of a real computer science today, and the lack of
real software engineering today, is partly due to this pop culture.
"""
So, let's not be so self-important , and see this interview
as one who bashes perl and admir
I just realized that I'm trolling.
We all sometimes get into a trollwar despite our intensions
(even FL). So, I would like to apologize on behalf
of all those who participated in it. I'm sorry you had to witness
that.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
rrogant noob -- just like arrogant experts...
Inconsistenly y'rs
jfj
--
http://mail.python.org/mailman/listinfo/python-list
the universe.
There is no trolling involved here. Maybe wrong use of the english
language. But then again, this is the newgroups and the english
language is ill-used all the time:)
Regards,
jfj
--
http://mail.python.org/mailman/listinfo/python-list
r backwards
compatibility, but in Python 3000 it may be the other way around.
Thanks all.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Alex Martelli wrote:
jfj <[EMAIL PROTECTED]> wrote:
Then, without looking at the previous code, one can say that "x" is a
function which takes one argument.
One can say whatever one wishes, but saying it does not make it true.
One can say that x is a green frog, but that
Alex Martelli wrote:
I still wouldn't see any "inconsistency" even if two different ways of
proceeding gave the same result in a certain case. That would be like
saying that having x-(-y) give the same result as x+y (when x and y are
numbers) is ``inconsistent''... the word ``inconsistent'' just d
Diez B. Roggisch wrote:
If things worked as you wanted it to, that would mean that passing a bound
method as argument to a class and storing it there to an instance variable
that would "eat up" the arguments - surely not the desired behaviour.
Could you please give an example of this ?
If you mean:
Alex Martelli wrote:
jfj <[EMAIL PROTECTED]> wrote:
Isn't that inconsistent?
That Python has many callable types, not all of which are descriptors?
I don't see any inconsistency there. Sure, a more generalized currying
(argument-prebinding) capability would be more powerf
Dan Perl wrote:
"jfj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
However this is not possible for another instance method:
class A:
pass
class B:
def foo(x,y)
print x,y
b=B()
A.foo = b.foo
a=A()
# error!!!
a.foo()
##
Python complains t
I don't understand.
We can take a function and attach it to an object, and then call it
as an instance method as long as it has at least one argument:
#
class A:
pass
def foo(x):
print x
A.foo = foo
a=A()
a.foo()
#
However this is not possible for another instance method
Francis Girard wrote:
What was the goal behind this rule ?
If you have a list which contains integers, strings, tuples, lists and
dicts and you sort it and print it, it will be easier to detect what
you're looking for:)
G.
--
http://mail.python.org/mailman/listinfo/python-list
Francis Girard wrote:
Wow ! What is it that are compared ? I think it's the references (i.e. the
adresses) that are compared. The "None" reference may map to the physical 0x0
adress whereas 100 is internally interpreted as an object for which the
reference (i.e. address) exists and therefore gre
Stephen Thorne wrote:
On Thu, 27 Jan 2005 09:08:59 +0800, Simon Wittber
<[EMAIL PROTECTED]> wrote:
According to the above post:
a) If the allocation is > 256 bytes, call the system malloc.
b) If the allocation is < 256, use its own malloc implementation, which
allocates memory in 256 kB chunks and
Nick Coghlan wrote:
1. Applies only if you are making large slices, or a lot of slices with
each containing at least 3 elements.
A view can also *cost* memory, when it looks at a small piece of a
large item. The view will keep the entire item alive, even though it
needs only a small piece.
Tha
Jeff Shannon wrote:
So, what problem is it, exactly, that you think you'd solve by making
tuple slices a view rather than a copy?
I think views are good for
1) saving memory
2) saving time (as you don't have to copy the elements into the new tuple)
And they are worth it. However, (as in other
Ron Garret wrote:
In article <[EMAIL PROTECTED]>,
"Erik Bethke" <[EMAIL PROTECTED]> wrote:
I have NEVER experienced this kind of programming joy.
Just wait until you discover Lisp!
;-)
I've had it with all those lisp posts lately ;-)
There were functional and non-functional programming languag
Stephen Thorne wrote:
Hi guys,
I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see things suddenly become harder
than they need to be.
Don't worry, it's not gonna go away because
I wish it was in Amsterdam.. ;)
Gerald
--
http://mail.python.org/mailman/listinfo/python-list
Yo.
Why can't we __setitem__ for tuples?
The way I see it is that if we enable __setitem__ for tuples there
doesn't seem to be any performance penalty if the users don't use it
(aka, python performance independent of tuple mutability).
On the other hand, right now we have to use a list if we want t
51 matches
Mail list logo
