Greg Ewing wrote:
Antoine Pitrou wrote:
For starters, since py3k is supposed to support non-blocking IO, why not write a
portable API to make a raw file or socket IO object non-blocking?
I think we need to be clearer what we mean when we talk
about non-blocking in this context. Normally when
Hrvoje Niksic wrote:
Under Linux, select() may report a socket file descriptor
as ready for reading, while nevertheless
a subsequent read blocks.
Blarg. Linux is broken, then. This should not happen.
This could for example
happen when data has arrived
Martin v. Löwis writes:
From time to time, people ask what they can do push a change into Python
that they really think is important. I once offered that people who
want a patch in Python really badly should review 10 other patches in
return, up to the point where they make a
Greg Ewing wrote:
Even if you don't agree that using O_NONBLOCK with select/poll is the
best approach to non-blocking, I think there is enough existing practice
of doing this to warrant separate consideration of non-blocking sockets
(in the OS sense) and select/poll.
I'm not saying there
Well, that happens. An alternative to withdrawing entirely, would be
increasing the price (eg, to ten patches as you originally suggested).
Or specifying windows in your calendar when the offer is open. Eg,
avoid doubling up on release times when you need make time to build
installers etc.
On 10:01 am, greg.ew...@canterbury.ac.nz wrote:
Hrvoje Niksic wrote:
Under Linux, select() may report a socket file descriptor
as ready for reading, while nevertheless
a subsequent read blocks.
Blarg. Linux is broken, then. This should not happen.
You know what else
Collin Winter wrote:
[...] I've found a few examples of code using the memo attribute ([1], [2],
[3]) [...]
As author of [2] (current version here [4]) I can tell you my reason.
cvs2svn has to store a vast number of small objects in a database, then
read them in random order. I spent a lot of
Michael Haggerty mhagger at alum.mit.edu writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
records the type of each object (essentially, the name of its class) in
each record. The space for these strings
Martin v. Löwis wrote:
I do see the point you are making here. Even if lxml gets mature and
static, that doesn't necessarily apply to the external libraries it uses.
However, I should note that exactly the same argument also applies to
sqlite3 and gdbm, which, again, are in the stdlib today,
Hello all,
Not sure if this is the same as the LinuxQuestions award, but it looks
different:
(German)
http://www.linux-magazin.de/news/cebit_2009_openstreetmap_erntet_zwei_linux_new_media_awards
I particularly like this snippet from the google translation:
The prize was Martin von Löwis of
On Fri, Mar 6, 2009 at 6:34 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
The prize was Martin von Löwis of the Python Foundation on behalf of the
Python community itself.
This is a funny translation from German-to-English. :-)
But yeah, a good one and the prize was presented by Kluas
On Fri, Mar 6, 2009 at 5:45 AM, Antoine Pitrou solip...@pitrou.net wrote:
If these strings are not interned, then perhaps they should be.
There is a similar optimization proposal (w/ patch) for attribute names:
http://bugs.python.org/issue5084
If I understand correctly, that would help with
Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
Antoine Pitrou wrote:
Michael Haggerty mhagger at alum.mit.edu writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
records the type of
CC'ing python-dev, as more RFEs might be uncovered :)
Daniel (ajax) Diniz wrote:
Martin v. Löwis wrote:
I think a patch (or full file) would be good enough. We could put it
into the tracker itself, and publish it prominently where people
upload files.
I'll post it as a patch and a full file
Tennessee Leeuwenburg writes:
I hope that somebody will pick up the slack here, because review is
really important to the workflow, and getting more people involved in
reviewing at some level is more important (because it's less
glamorous in itself) than attracting coders.
I would
Antoine Pitrou wrote:
Michael Haggerty mhagger at alum.mit.edu writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
records the type of each object (essentially, the name of its class) in
each record. The
I am trying to script a Python installation on Windows, using msiexec from
the windows cmd prompt. I do not want to register extensions.
I have tried all the combinations I can find on the following page:
http://www.python.org/download/releases/2.5/msi/
But, no matter how I run msiexec, it seems
ACTIVITY SUMMARY (02/27/09 - 03/06/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2364 open (+31) / 14890 closed (+17) / 17254 total (+48)
Open issues with patches: 822
Stefan Behnel wrote:
Martin v. Löwis wrote:
I do see the point you are making here. Even if lxml gets mature and
static, that doesn't necessarily apply to the external libraries it uses.
However, I should note that exactly the same argument also applies to
sqlite3 and gdbm, which, again, are in
Antoine Pitrou wrote:
Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
Antoine Pitrou wrote:
Michael Haggerty mhagger at alum.mit.edu writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy tjre...@udel.edu wrote:
Stefan Behnel wrote:
Martin v. Löwis wrote:
I do see the point you are making here. Even if lxml gets mature and
static, that doesn't necessarily apply to the external libraries it
uses.
However, I should note that exactly
Guido van Rossum wrote:
On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy tjre...@udel.edu wrote:
No, it is expected to just work because sqlite3 is (presumably) very
careful about backwards compatibility, and because the Windows DLL API
(just like the shared library API in Linux and other systems)
I hope that somebody will pick up the slack here, because review is
really important to the workflow, and getting more people involved in
reviewing at some level is more important (because it's less
glamorous in itself) than attracting coders.
Ok, then let me phrase it this way: if somebody
I guess I'm saying that I'm surprised people aren't a bit more
appreciative of the opportunity to review code.
Not sure what people you are referring to here which aren't
appreciative of the opportunity to review code. Committers?
Non-committers?
I don't think I would even be on this list or
On Fri, Mar 6, 2009 at 11:08 AM, Terry Reedy tjre...@udel.edu wrote:
I do not know whether upgrades (like 3.0.0 to 3.0.1) would clobber other
things added here.
It would, but not in a harmful way.
By 'clobber', I meant 'delete', and I do not see how that would not be
harmful ;-). I don't
If it is possible for a hostile outsider to trigger the DOS by sending
mail to be processed by an application using the library, and the
application can't avoid the DOS without ditching / forking /
monkeypatching the library, then I would call the bug a security bug,
period.
IIUC, it would
The prize was Martin von Löwis of the Python Foundation on behalf of the
Python community itself.
This is a funny translation from German-to-English. :-)
But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix.
Congratulations!
Actually, the prize went to Python,
charlie wrote:
I am trying to script a Python installation on Windows, using msiexec
from the windows cmd prompt. I do not want to register extensions.
I have tried all the combinations I can find on the following page:
http://www.python.org/download/releases/2.5/msi/
But, no matter how I
Thanks for the reply.
This question is out of scope for python-dev; use python-l...@python.org
instead.
The last time I tried a question about the msi installer on python-list, no
one answered, so I thought it might be more appropriate for the dev list.
I actually thought this might be a bug
On Fri, 6 Mar 2009 at 20:57, Martin v. L??wis wrote:
If it is possible for a hostile outsider to trigger the DOS by sending
mail to be processed by an application using the library, and the
application can't avoid the DOS without ditching / forking /
monkeypatching the library, then I would call
Interesting. I assume you are referring to Windows here, right? Does that
just work because the DLL is in the same directory?
Correct. Also, because changes to SQLite don't change the API, just the
implementation.
Regards,
Martin
___
Python-Dev
DLLs/sqlite3.dll 557K
This is sqlite3 itself. I am presuming that the phrase replace the
sqlite DLL above refers to this one
Correct.
-- although the same argument actually holds for the .pyd file
Not quite. You can download Windows binaries for newer sqlite
versions from sqlite.org, so
I see. I didn't realize you were talking about adding your own files
to these directories. I have no idea; the best way to find out is to
experiment. I could see the default policy of Windows installers go
either way.
An upgrade installation removes all old files it installed (the old
MSI is
IIRC, that was the rationale for cmp() removal in 3.0.1.
And indeed, that removal already caused a bug report and broke
the efforts of SWIG to support Python 3.0.
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
[Martin v. Löwis]
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
removing API can possibly serve a user.
Am not following you here. My suggestion was to remove the two
methods in Py3.1 which isn't even in alpha
I don't mind whether its in or out, but as a language user I think it's
best to minimise undocumented interfaces.
According to that principle, if it's in, then it should also work as
documented (and be documented), and be supported. If it's out then it
should either be removed entirely or be
On Fri, Mar 6, 2009 at 10:01 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Antoine Pitrou wrote:
Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
Antoine Pitrou wrote:
Michael Haggerty mhagger at alum.mit.edu writes:
It is easy to optimize the pickling of instances by
Stephen J. Turnbull wrote:
A suggestion, though. View the contribution visualization video based
on the commit log (the URL was posted here a while back, but I don't
seem to have it offhand), which shows what a vibrant community this is
in a very graphic way.
There's one here:
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
removing API can possibly serve a user.
Am not following you here. My suggestion was to remove the two
methods in Py3.1 which isn't even in alpha yet.
Your proposal
On Fri, Mar 6, 2009 at 7:19 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
removing API can possibly serve a user.
Am not following you here. My suggestion was to
Jesse Noller jnoller at gmail.com writes:
I would tend to agree with Martin,
Agreed as well.
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Mar 6, 2009 at 5:17 PM, Raymond Hettinger pyt...@rcn.com wrote:
I believe there was a thread (in January 2008) with a decision to keep
qsize() but to drop empty() and full().
Based on our experiences so far, I think that of the two options we
have, both of which are bad, it's better to
[Guido van Rossum]
Based on our experiences so far, I think that of the two options we
have, both of which are bad, it's better to keep things in 3.1 that we
were planning to remove but forgot, than to make 3.1 have a whole slew
of additional removals. We've removed cmp() in 3.0.1, and I think
Martin v. Löwis wrote:
The prize was Martin von Löwis of the Python Foundation on behalf of the
Python community itself.
This is a funny translation from German-to-English. :-)
But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix.
Congratulations!
Actually, the prize
44 matches
Mail list logo
