On 2/6/06, Christopher Armstrong [EMAIL PROTECTED] wrote:
On 2/7/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
But I know that everyone and their email client is against me on this
one, so I am not going to really try to tear into this. But I do
think that lambda
On 2/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
On 2/5/06, Guido van Rossum [EMAIL PROTECTED] wrote:
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda,
Maybe someone has already brought this up, but my searching hasn't
revealed it. Is there any interest in something like this for the
functional module?
#!/usr/bin/env python2.4
# This program shows off a python decorator which implements
# tail call optimization. It does this by throwing an
Hi all,
As promized two months ago, I eventually finished the integration of the
'lsprof' profiler. It's now in an internal '_lsprof' module that is
exposed via a 'cProfile' module with the same interface as 'profile',
producing compatible dump stats that can be inspected with 'pstats'.
See
On 2/6/06, Brett Cannon [EMAIL PROTECTED] wrote:
And I think that a deferred object would help with one of
lambda's biggest uses and made its loss totally reasonable.
The ambiguity inherent from the perspective of a deferred object makes
a general one impractical. Both map(Deferred().attribute,
Jiwon Seo wrote:
After lambda being made more useful, can I hope that I will be able to
use lambda with multiple statements? :) Lambdas in Lisp and Python are
different, but in the usability perspective they don't need to differ
too much.
To my knowledge, nobody proposed to make it more
This is a design question which is why I'm posting here. Recently the
NumPy developers have become more aware of the difference between UCS2
and UCS4 builds of Python. NumPy arrays can be of Unicode type. In
other words a NumPy array can be made of up fixed-data-length unicode
strings.
Travis E. Oliphant wrote:
Currently that means that they are unicode strings of basic size UCS2
or UCS4 depending on the platform. It is this duality that has some
people concerned. For all other data-types, NumPy allows the user to
explicitly request a bit-width for the data-type.
Why
Hye-Shik Chang [EMAIL PROTECTED] writes:
I did some work to make ctypes+libffi compacter and liberal.
http://openlook.org/svnpublic/ctypes-compactffi/ (svn)
Here goes patches for the integration:
[1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2
[2]
Travis E. Oliphant wrote:
Numpy supports arrays of arbitrary fixed-length records. It is
much more than numeric-only data now. One of the fields that a
record can contain is a string. If strings are supported, it makes
sense to support unicode strings as well.
Hmm. How do you support
On 2/7/06, Paul Moore [EMAIL PROTECTED] wrote:
On 2/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
On 2/5/06, Guido van Rossum [EMAIL PROTECTED] wrote:
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
On 2/7/06, Michael Urman [EMAIL PROTECTED] wrote:
On 2/6/06, Brett Cannon [EMAIL PROTECTED] wrote:
And I think that a deferred object would help with one of
lambda's biggest uses and made its loss totally reasonable.
The ambiguity inherent from the perspective of a deferred object makes
a
I just came up with an idea how to resolve the VC versioning
problems for good: Python should link with mscvrt.dll (which
is part of the operating system), not with the CRT that the
compiler provides.
To do that, we would need to compile and link with the SDK
header files and import libraries,
IMO asynchat and asyncore are braindead. The should really be removed
from the standard library. The code is 10 years old and represents at
least 10-year-old thinking about how to do this. The amount of hackery
in Zope related to asyncore was outrageous -- basically most of
asyncore's guts were
Guido van Rossum wrote:
IMO asynchat and asyncore are braindead. The should really be removed
from the standard library. The code is 10 years old and represents at
least 10-year-old thinking about how to do this. The amount of hackery
in Zope related to asyncore was outrageous -- basically
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
...
what other reactive socket framework is there that would fit well into
the standard library ? is twisted really simple enough ?
Twisted is wonderful, powerful, rich, and very large. Perhaps a small
subset could be carefully extracted
Guido van Rossum [EMAIL PROTECTED] wrote:
IMO asynchat and asyncore are braindead. The should really be removed
from the standard library. The code is 10 years old and represents at
least 10-year-old thinking about how to do this. The amount of hackery
in Zope related to asyncore was
On Tue, 2006-02-07 at 16:01 -0800, Robert Brewer wrote:
Perhaps, but please keep in mind that the smtpd module uses both, currently,
and would have to be rewritten if either is removed.
Would that really be a huge loss?
-Barry
signature.asc
Description: This is a digitally signed message
On 2/8/06, Alex Martelli [EMAIL PROTECTED] wrote:
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
...
what other reactive socket framework is there that would fit well into
the standard library ? is twisted really simple enough ?
Twisted is wonderful, powerful, rich, and very large.
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
what's the current release plan for Python 2.5, btw? I cannot find a
relevant PEP, and the what's new says late 2005:
but I don't think that anyone followed up on this. what's the current
status ?
Guido and I had a brief discussion
It looks like we need a Python 2.5 Release Schedule PEP.
Jeremy
On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote:
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
what's the current release plan for Python 2.5, btw? I cannot find a
relevant PEP, and the what's new says late 2005:
On 2/7/06, Christopher Armstrong [EMAIL PROTECTED] wrote:
Twisted is wonderful, powerful, rich, and very large. Perhaps a small
subset could be carefully extracted
The subject of putting (parts of) Twisted into the standard library
comes up once every 6 months or so, at least on our
what other reactive socket framework is there that would fit well into
the standard library ? is twisted really simple enough ?
I've been very happy with Medusa, which is asyncore-based.
Perhaps the right idea is to fix the various problems of asyncore. We
might lift the similar code from
[Josiah Carlson]
...
Back to the topic that Guido was really complaining about: Zope +
asyncore. I don't doubt that getting Zope to play nicely with asyncore
was difficult,
It's more that mixing asyncore with threads is a bloody nightmare, and
ZEO and Zope both do that. Zope (but not ZEO)
On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote:
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
what's the current release plan for Python 2.5, btw? I cannot find a
relevant PEP, and the what's new says late 2005:
but I don't think that anyone followed up on this. what's the
On 2/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It looks like we need a Python 2.5 Release Schedule PEP.
Very draft: http://www.python.org/peps/pep-0356.html
Needs lots of work and release managers. Anthony, Martin, Fred, Sean
are all mentioned with TBDs and question marks.
n
Raymond Hettinger wrote:
| [Chris Smith]
|| Does it help to spell it like this?
||
|| def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
|| diff = abs(x - y)
|| ave = (abs(x) + abs(y))/2
|| return diff absolute_err or diff/ave relative_err
|
| There is a certain beauty
I just ran into a curious behavior with small floating points, trying to find
the limits of them on my machine (XP). Does anyone know why the '0.0' is
showing up for one case below but not for the other? According to my tests, the
smallest representable float on my machine is much smaller than
Tim Peters wrote:
Bugs and missing features in asyncore. For ZEO's purposes, if I had
designed it, I expect it would have used threads (without asyncore).
However, bits of code still sitting around suggest that it was at
least the _intent_ at one time that ZEO be able to run without threads
Travis == Travis E Oliphant [EMAIL PROTECTED] writes:
Travis Numpy supports arrays of arbitrary fixed-length records.
Travis It is much more than numeric-only data now. One of the
Travis fields that a record can contain is a string. If strings
Travis are supported, it makes
Martin v. Löwis wrote:
Tim Peters wrote:
Bugs and missing features in asyncore. For ZEO's purposes, if I had
designed it, I expect it would have used threads (without asyncore).
However, bits of code still sitting around suggest that it was at
least the _intent_ at one time that ZEO be able
Steve Holden wrote:
What is the reason that people want to use threads when they can have
poll/select-style message processing? Why does Zope require threads?
IOW, why would anybody *want* a threadsafe patch for asynchat?
In case the processing of events needed to block? If I'm
Fredrik Lundh [EMAIL PROTECTED] wrote:
Steve Holden wrote:
What is the reason that people want to use threads when they can have
poll/select-style message processing? Why does Zope require threads?
IOW, why would anybody *want* a threadsafe patch for asynchat?
In case the
33 matches
Mail list logo
