Alex Martelli wrote:
>> Of course that would mean establishing which *was* the best available
>> which, as we've seen this week, may not be easy.
>
> I believe it's: kqueue on FreeBSD ...
Such a statement assumes they are semantically equivalent. However, I
believe they aren't. A specific usage p
Greg Ewing wrote:
> There are many different select-like things around now
> (select, poll, epoll, kqueue -- are there others?) and
> random combinations of them seem to be available on any
> given platform. This makes writing platform-independent
> code that needs select-like functionality very aw
Ronald Oussoren wrote:
> Some time ago a warning was introduced for directories on sys.path
> that don't contain an __init__.py but have the same name as a package/
> module that is being imported.
>
> Is it intentional that this triggers for toplevel imports? These
> warnings are triggered i
Ross Cohen wrote:
> epoll also allows 64 bits of data to be tucked away and returned when events
> happen. Could be useful for saving a dict lookup for every event. However,
> there are some refcounting issues. Dict lookup per event could be traded
> for one on deregistration. All it needs is a sma
> Steve Holden <[EMAIL PROTECTED]> writes:
>> Rather than adding yet another platform-dependent module,
>> I'd like to see a unified Python interface in the stdlib
>> that uses whichever is the best one available.
>>
> Of course that would mean establishing which *was* the best available
> w
> It would help me enormously if someone could summarize the status and
> everything that went on. These are the things that would help me the
> most.
>
> * What are the speed diffs before/after the sprint
> * What was modified (summary)
> * What is left to do
>- doc
>- tests
>- code
First off, good work to everyone involved. You did a tremendous job.
I just hope to hell you're done, because I can't keep up! :-)
It would help me enormously if someone could summarize the status and
everything that went on. These are the things that would help me the
most.
* What are the spe
On May 26, 2006, at 6:27 PM, Steve Holden wrote:
> Greg Ewing wrote:
>> Fredrik Lundh wrote:
>>
>>
>>> roughly speaking, epoll is kqueue for linux.
>>
>>
>> There are many different select-like things around now
>> (select, poll, epoll, kqueue -- are there others?) and
>> random combinations of t
I wrote an epoll implementation which can be used as a drop-in replacement
for parts of the select module (assuming the program is using only poll).
The code can currently be used by doing:
import epoll as select
It was released under the Python license on sourceforge:
http://sourceforge.net/proj
Hi,
in the last time, I've found myself reimplementing a generator that provides a
sliding-window-view over a sequence, and I think this function is of a greater
usefullness, so that it might be included in itertools.
Basically, what the generator does it return all m consecutive elements from a
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
>
>>roughly speaking, epoll is kqueue for linux.
>
>
> There are many different select-like things around now
> (select, poll, epoll, kqueue -- are there others?) and
> random combinations of them seem to be available on any
> given platform. This make
Fredrik Lundh wrote:
> roughly speaking, epoll is kqueue for linux.
There are many different select-like things around now
(select, poll, epoll, kqueue -- are there others?) and
random combinations of them seem to be available on any
given platform. This makes writing platform-independent
code th
On Fri, May 26, 2006 at 11:56:06PM +0200, "Martin v. Löwis" wrote:
> I thought about this (even though I never used it), and I think there
> are good uses for EPOLLET.
There are, if the programmer wants to deal with it. Easy enough to add the
flag and give them the choice. I'll put together a sele
On Fri, May 26, 2006 at 11:43:05PM +0200, Ronald Oussoren wrote:
> >Ok, I'm not familiar with intimate details of kqueue. However, if
> >there
> >were a select.poll implementation based on kqueue, it would still
> >be an
> >improvement, since there isn't *any* implementation on OS X right now.
On 5/26/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> Some time ago a warning was introduced for directories on sys.path
> that don't contain an __init__.py but have the same name as a package/
> module that is being imported.
>
> Is it intentional that this triggers for toplevel imports?
Yes,
Hi,
Some time ago a warning was introduced for directories on sys.path
that don't contain an __init__.py but have the same name as a package/
module that is being imported.
Is it intentional that this triggers for toplevel imports? These
warnings are triggered in the build process for PyObjC
Ross Cohen wrote:
> I've never been fond of the edge-triggered mode. It's a pretty minor
> optimization, it saves scanning the set of previously returned fds to see
> if the events on them are still relevant. Given that there are added
> pitfalls to using that mode, it never seemed worth it. Any la
Hello. This is my first post.
I sent the patch for fixing mbcs codec bug to SourceForge, and I was adviced to
find
someone here with a multibyte version of Windows to look at the patch.
http://sourceforge.net/tracker/index.php?func=detail&aid=1455898&group_id=5470&atid=305470
Is there anyone? A
On 26-mei-2006, at 22:22, Ross Cohen wrote:
>>
>> AIUI, kqueue actually isn't implemented for PTYs on OS X, whereas
>> poll(2) is. Given this, I don't think kqueue is actually strictly
>> better. Although hopefully Apple will get their act together and
>> fix this deficiency.
>
> Ok, I'm
Ross Cohen wrote:
> 1) Provide an epoll implementation which is used "silently" when the call is
> available.
>
> 2) Expose both poll(2) and epoll(4) in python and build select.poll on top of
> whatever is available.
>
> Ok, so 2 is only different in that it exposes the lower level APIs. I'd li
I think you're getting to implementation details here. Whether a new
string is returned or a reference to the old one is an optimization
decision. I don't think it's worth legislating this behavior one way
or another (especially since it's mostly a theoretical issue).
--Guido
On 5/26/06, Walter D
Guido van Rossum wrote:
> On 5/26/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> [...]
>> And what happens if the separator is an instance of a subclass?
>>
>> class s2(str):
>> def __repr__(self):
>> return "s2(%r)" % str(self)
>>
>> print "foobar".partition(s2("o"))
>>
>> Currently t
On Fri, May 26, 2006 at 10:12:15PM +0200, "Martin v. Löwis" wrote:
> That said, I would be in favour of having select.poll "silently" use
> epoll where available. Of course, it would be good if a "cheap" run-time
> test could be made whether epoll is available at run-time (although
> just waiting f
> How about "not *only* as a separate set of calls"? If poll(2) and
> epoll(4) are both available on the underlying platform, then they
> should both be exposed to Python as separate APIs. Then, on top of
> that, a relatively simple layer which selects the most efficient
> mechanism can be expose
On Fri, May 26, 2006 at 02:49:44PM -0400, Jean-Paul Calderone wrote:
> On Fri, 26 May 2006 14:31:33 -0400, Ross Cohen <[EMAIL PROTECTED]> wrote:
> >
> >I agree that it should go into the select module, but not as a seperate
> >set of calls.
>
> How about "not *only* as a separate set of calls"? I
Ross Cohen wrote:
> True, and as I mentioned before, the python API more closely matches epoll
> in this case. The level-triggered mode of epoll is an almost perfect match.
> Someone went to some lengths to hide the details of the system poll
> interface.
Ah right, I missed that point. That makes
On Fri, May 26, 2006 at 08:48:42PM +0200, "Martin v. Löwis" wrote:
> Ross Cohen wrote:
> > I agree that it should go into the select module, but not as a seperate
> > set of calls. epoll is strictly better than poll. kqueue is strictly
> > better than poll. Windows has its own completion ports API.
On Fri, 26 May 2006 13:31:33 -0400, Ross Cohen <[EMAIL PROTECTED]> wrote:
>On Fri, May 26, 2006 at 01:10:30PM -0400, Jean-Paul Calderone wrote:
>> Of course, if there is a volunteer to maintain and support an extension
>> module, that's better than nothing. PyEpoll is missing a couple features I
On Fri, 26 May 2006 14:31:33 -0400, Ross Cohen <[EMAIL PROTECTED]> wrote:
>On Fri, May 26, 2006 at 08:03:12PM +0200, "Martin v. Löwis" wrote:
>> Ross Cohen wrote:
>> > Is there any interest in incorporating this into the standard python
>> > distribution?
>>
>> I would like to see epoll support in
Ross Cohen wrote:
> I agree that it should go into the select module, but not as a seperate
> set of calls. epoll is strictly better than poll. kqueue is strictly
> better than poll. Windows has its own completion ports API. Why should
> an application developer have to detect what platform they ar
Raymond Hettinger wrote:
> 1) Is str.rpartition() still wanted?
>
> Yes.
I might have missed my earlier 30-minute deadline with one minute (not
my fault! I was distracted! seriously!), but this time, I actually
managed to get the code in there *before* I saw the pronouncement ;-)
_
Jonathan LaCour wrote:
> There is, in fact, an implementation of kqueue for Python already
> available. I have not used it myself, but it is available here:
>
> http://python-hpio.net/trac/
>
> maybe the needforspeed people could take a look at this?
"take a look" is really quite involved.
> 1) Is str.rpartition() still wanted?
Yes.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, May 26, 2006 at 08:03:12PM +0200, "Martin v. Löwis" wrote:
> Ross Cohen wrote:
> > Is there any interest in incorporating this into the standard python
> > distribution?
>
> I would like to see epoll support in Python, but not in the way PyEpoll
> is packaged. Instead, I think it should go
Guido van Rossum wrote:
> On a related note, perhaps the needforspeed folks should look into
> supporting kqueue on systems where it's available? That's a really
> fast BSD-originated API to replace select/poll. (It's fast due to the
> way the API is designed.)
There is, in fact, an implementation
On 05/26/2006-10:07AM, Guido van Rossum wrote:
>
> I don't know what epoll is.
>
> On a related note, perhaps the needforspeed folks should look into
> supporting kqueue on systems where it's available? That's a really
> fast BSD-originated API to replace select/poll. (It's fast due to the
> way
Ross Cohen wrote:
> Is there any interest in incorporating this into the standard python
> distribution?
I would like to see epoll support in Python, but not in the way PyEpoll
is packaged. Instead, I think it should go into the select module,
and be named epoll_*.
Likewise, if kqueue was ever su
[Guido]
> +1, if you can also prove that the traceback will never be null. I
> failed at that myself last time I tried, but I didn't try very long or
> hard.
Thanks! I'm digging.
Stuck right now on this miserable problem that's apparently been here
forever: I changed PyErr_SetObject to start li
2006/5/26, Terry Reedy <[EMAIL PROTECTED]>:
> And the line before, while not formal English of the kind needed, say, for
> Decimal docs, works well enough for me as an expression of an informal
> conversational thought.
That's why Decimal docs were written by Raymond, ;)
--
.Facundo
Blog:
On Fri, May 26, 2006 at 01:10:30PM -0400, Jean-Paul Calderone wrote:
> Including a wrapper for this functionality would be quite useful for many
> python network apps. However, I think with ctypes going into 2.5, it might
> be better to consider providing epoll support using a ctypes-based modul
Guido van Rossum wrote:
> I don't know what epoll is.
>
> On a related note, perhaps the needforspeed folks should look into
> supporting kqueue on systems where it's available? That's a really
> fast BSD-originated API to replace select/poll. (It's fast due to the
> way the API is designed.)
ro
On Fri, May 26, 2006 at 01:13:44PM -0400, Ross Cohen wrote:
>The NeedForSpeed wiki lists /dev/epoll as a goal for the twisted folks. I
Just FYI, none of the Twisted items made it onto the list of items being
worked.
Thanks,
Sean
--
"You're thinking of Mr. Wizard." "[Emilio Lizardo's] a top sci
"Facundo Batista" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Just end user experience's two cents here
> (btw, this line is correct at English level?)
Since you asked...your question would be better written "is this line
correct English?"
And the line before, while not form
On Fri, May 26, 2006 at 11:47:43AM -0500, [EMAIL PROTECTED] wrote:
>
> Ross> I wrote an epoll implementation which can be used as a drop-in
> Ross> replacement for parts of the select module
> ...
> Ross> Is there any interest in incorporating this into the standard
> Ross> pyt
On Fri, 26 May 2006 11:47:43 -0500, [EMAIL PROTECTED] wrote:
>
>Ross> I wrote an epoll implementation which can be used as a drop-in
>Ross> replacement for parts of the select module
>...
>Ross> Is there any interest in incorporating this into the standard
>Ross> python distribu
I don't know what epoll is.
On a related note, perhaps the needforspeed folks should look into
supporting kqueue on systems where it's available? That's a really
fast BSD-originated API to replace select/poll. (It's fast due to the
way the API is designed.)
--Guido
On 5/26/06, Ross Cohen <[EMAIL
+1, if you can also prove that the traceback will never be null. I
failed at that myself last time I tried, but I didn't try very long or
hard.
--Guido
On 5/26/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> In various places we store triples of exception info, like a
> PyFrameObject's f_exc_type, f_
On 5/26/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> A.M. Kuchling wrote:
>
> > I didn't find an answer in the str.partition() thread in the archives
> > (it's enormous, so easy to miss the right message), so I have two
> > questions:
> >
> > 1) Is str.rpartition() still wanted?
Can't remember.
On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> I think that we can do one of the following, when we found "-1 * (1, 2, 3)":
>
> - Treat -1 as 0 and return an empty tuple (actual behavior).
> - Treat the negative as a reverser, so we get back (3, 2, 1).
> - Raise an error.
No, no, no. Th
Ross> I wrote an epoll implementation which can be used as a drop-in
Ross> replacement for parts of the select module
...
Ross> Is there any interest in incorporating this into the standard
Ross> python distribution?
Without going to the trouble of downloading epoll (always an
Since no Python code should be generating the warning (I would double-check that, obviously), I say take it out. At least from a PEP 352 perspective there is nothing about keeping it (or removing it).-Brett
On 5/26/06, Richard Jones <[EMAIL PROTECTED]> wrote:
On 25/05/2006, at 9:00 PM, Jim Jewett
2006/5/26, Steven Bethard <[EMAIL PROTECTED]>:
> On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > All this different ways enforce my vote: we should get an error...
> ...
> But if this change goes in, I want a big "we're breaking backwards
> incompatibility" message somewhere. I say
I wrote an epoll implementation which can be used as a drop-in replacement
for parts of the select module (assuming the program is using only poll).
The code can currently be used by doing:
import epoll as select
It was released under the Python license on sourceforge:
http://sourceforge.net/proj
On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> All this different ways enforce my vote: we should get an error...
Perhaps you missed Tim's post, so here's a few lines of my own code
that I know would break:
padding = [None] * (self.width - len(leaves))
left_padding = [None]
In various places we store triples of exception info, like a
PyFrameObject's f_exc_type, f_exc_value, and f_exc_traceback PyObject*
members.
No invariants are documented, and that's a shame. Patch 1145039 aims
to speed ceval a bit by relying on a weak guessed invariant, but I'd
like to make the s
2006/5/26, Fred L. Drake, Jr. <[EMAIL PROTECTED]>:
> Even better:
>
> "123"*-1
>
> We'd get to explain:
>
> - what the "*-" operator is all about, and
>
> - why we'd use it with a string and an int.
>
> I see possibilities here. :-)
All this different ways enforce my vote: we should get
Fred L. Drake, Jr. wrote:
> Even better:
>
> "123"*-1
>
> We'd get to explain:
>
> - what the "*-" operator is all about, and
>
> - why we'd use it with a string and an int.
>
> I see possibilities here. :-)
the infamous "*-" clear operator? who snuck that one into python?
_
Fred> I see possibilities here. :-)
Fred appears to be looking for more job security. ;-)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Fredrik Lundh wrote:
> Sean Reifschneider wrote:
>
>>> - Treat the negative as a reverser, so we get back (3, 2, 1).
>>
>> Then we could get:
>>
>>>>> print -123
>>321
>>
>> Yay!
>
> and while we're at it, let's fix this:
>
> >>> 0.66 * (1, 2, 3)
> (1, 2)
>
> and maybe even
On Friday 26 May 2006 11:50, Georg Brandl wrote:
> This is actually a nice idea, because it's even a more nonintuitive
> answer for Python newbies posting to c.l.py asking how to reverse
> a string
Even better:
"123"*-1
We'd get to explain:
- what the "*-" operator is all about, and
-
Sean Reifschneider wrote:
>> - Treat the negative as a reverser, so we get back (3, 2, 1).
>
> Then we could get:
>
>>>> print -123
>321
>
> Yay!
and while we're at it, let's fix this:
>>> 0.66 * (1, 2, 3)
(1, 2)
and maybe even this
>>> 0.5 * (1, 2, 3)
(1, 1)
bu
Facundo Batista wrote:
> 2006/5/26, Sean Reifschneider <[EMAIL PROTECTED]>:
>
>> On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote:
>> >- Treat the negative as a reverser, so we get back (3, 2, 1).
>>
>> Then we could get:
>>
>>>>> print -123
>>321
>
> An integer is NOT a se
2006/5/26, Sean Reifschneider <[EMAIL PROTECTED]>:
> On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote:
> >- Treat the negative as a reverser, so we get back (3, 2, 1).
>
> Then we could get:
>
>>>> print -123
>321
An integer is NOT a sequence.
OTOH, that should be consiste
On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote:
>- Treat the negative as a reverser, so we get back (3, 2, 1).
Then we could get:
>>> print -123
321
Yay!
Thanks,
Sean
--
Sometimes it pays to stay in bed on Monday, rather than spending the rest
of the week debugging Mon
2006/5/25, Fredrik Lundh <[EMAIL PROTECTED]>:
> >>> -1 * (1, 2, 3)
> ()
> >>> -(1, 2, 3)
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: bad operand type for unary -
>
> We Really Need To Fix This!
I don't see here an inconsistency. The operator "*" is not a
multipli
2006/5/25, Raymond Hettinger <[EMAIL PROTECTED]>:
> IIRC, Guido's words were that too much to the smarts in timeit.py were
> in the command-line interface and not in the Timer object were in should
> be.
Just end user experience's two cents here (btw, this line is correct
at English level?)
I fo
Hi Bob,
On Thu, May 25, 2006 at 10:58:21PM +, Bob Ippolito wrote:
> Python ints are a heck of a lot faster to work with than Python longs
> and have the additional benefit that psyco psyco.sourceforge.net> can optimize the hell out of int but can't do
> anything at all for long.
Alternat
On Friday 26 May 2006 21:12, Aahz wrote:
> We're coming down to the wire on _Python for Dummies_, and I'm
> trying to persuade the publisher to stick a blurb about SQLite on
> the cover, but my last understanding was that there was a small
> chance we might pull SQLite for insufficient docs. Is th
A.M. Kuchling wrote:
> I didn't find an answer in the str.partition() thread in the archives
> (it's enormous, so easy to miss the right message), so I have two
> questions:
>
> 1) Is str.rpartition() still wanted?
>
> 2) What about adding partition() to the re module?
And what happens if the s
I didn't find an answer in the str.partition() thread in the archives
(it's enormous, so easy to miss the right message), so I have two
questions:
1) Is str.rpartition() still wanted?
2) What about adding partition() to the re module?
--amk
___
Python
I've worked on two patches for NeedForSpeed, and would like someone
familiar with the areas they touch to review them before I check them
in, breaking all the buildbots which aren't broken yet ;)
They are:
http://python.org/sf/1346214
Better dead code elimination for the AST compiler
http://
We're coming down to the wire on _Python for Dummies_, and I'm trying to
persuade the publisher to stick a blurb about SQLite on the cover, but my
last understanding was that there was a small chance we might pull SQLite
for insufficient docs. Is that still true?
--
Aahz ([EMAIL PROTECTED])
On 5/26/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[Bob Ippolito]> Given the interchangeability of int and> long, I don't foresee any other complications with this change.>> Thoughts?+1, and for 2.5. Even int() doesn't always return an int anymore, and it's just stupid to bear the burden of an unbo
Greg Ewing wrote:
> Steve Holden wrote:
>
>
>>In actual fact the effbot has lately found itself so permeated with
>>Windows that it has become constituionally incapable of using a forward
>>slash. Don't know what's with the square brackets though ...
>
>
> I was thinking maybe that message ha
On 25/05/2006, at 9:00 PM, Jim Jewett wrote:
>> +/*
>> + *OverflowWarning extends Warning
>> + */
>> +SimpleExtendsException(PyExc_Warning, OverflowWarning, "Base
>> class for warnings about numeric overflow. Won't exist in Python
>> 2.5.");
>
> Take it out now?
What do people say? I impl
Neal Norwitz wrote:
> This is probably orthogonal to the problem, however, you may want to
> look into trying to speed up Python/errors.c. This link will probably
> not work due to sessions, but click on the latest run for python and
> Python/errors.c
>
> http://coverage.livinglogic.de/coverage/
[Tim]
>> PyLong_FromString() only sees the starting
>> address, and-- as it always does --parses until it hits a character
>> that doesn't make sense for the input base.
[Greg Ewing]
> This is the bug, then. long() shouldn't be using
> PyLong_FromString() to convert its argument, but
> something t
On 26-mei-2006, at 11:26, Bob Ippolito wrote:
>
> On May 26, 2006, at 8:35 AM, Ronald Oussoren wrote:
>
>> The current version of setup.py looks for the sqlite header files in
>> a number of sqlite-specific directories before looking into the
>> default inc_dirs. I'd like to revert that order bec
On May 26, 2006, at 8:35 AM, Ronald Oussoren wrote:
> The current version of setup.py looks for the sqlite header files in
> a number of sqlite-specific directories before looking into the
> default inc_dirs. I'd like to revert that order because that would
> make it possible to override the vers
Hi,
The current version of setup.py looks for the sqlite header files in
a number of sqlite-specific directories before looking into the
default inc_dirs. I'd like to revert that order because that would
make it possible to override the version of sqlite that gets picked
up. Any objections
80 matches
Mail list logo
