"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"?
> > >
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
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 ZE
> "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
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 thr
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 1
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
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
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 o
[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
> 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 t
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
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
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
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 v
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 messa
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 out
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 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
a while ago, I wrote
> > Hopefully something can get hammered out so that at least the Python
> > 3 docs can premiere having been developed on by the whole community.
>
> why wait for Python 3 ?
>
> what's the current release plan for Python 2.5, btw? I cannot find a
> relevant PEP, and the "what
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.
strange. I'd say it works perfectly fine for what it was designed for
(after
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 rep
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, not
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
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 fol
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
> > > thi
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
> 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] htt
Martin v. Löwis wrote:
> 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 bi
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.
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.
Cur
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 u
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().attribu
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 prev
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 except
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 kee
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.
I don't think it helps usability much if anonymous
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
> > > thi
38 matches
Mail list logo
