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
[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 t
On Fri, Mar 6, 2009 at 5:17 PM, Raymond Hettinger 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 keep things i
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 was also to add a warning for 3.0.2. This is what I
primarily object to.
Okay, that's fine. Seemed prudent but it isn't essential.
This is for a feature
that has a
Jesse Noller 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:
http://mail.python.org/mailman/options
On Fri, Mar 6, 2009 at 7:19 PM, "Martin v. Löwis" 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 remove th
>> 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
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:
http://www.
On Fri, Mar 6, 2009 at 10:01 AM, Michael Haggerty wrote:
> Antoine Pitrou wrote:
>> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>>> Antoine Pitrou wrote:
Michael Haggerty alum.mit.edu> writes:
> It is easy to optimize the pickling of instances by giving them
>
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
[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 yet.
> 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
removin
> 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
>> 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.or
> 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 ma
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 cal
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
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
>> 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
> 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 w
On Fri, Mar 6, 2009 at 11:08 AM, Terry Reedy 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 know
> 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 lis
> 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 somebod
Guido van Rossum wrote:
On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy 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) is
designed to
On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy 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
Antoine Pitrou wrote:
> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>> Antoine Pitrou wrote:
>>> Michael Haggerty alum.mit.edu> writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
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
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
Average
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
Antoine Pitrou wrote:
> Michael Haggerty 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 spa
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.
>
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 f
Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
> Antoine Pitrou wrote:
> > Michael Haggerty 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
On Fri, Mar 6, 2009 at 5:45 AM, Antoine Pitrou 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 unpickling, but
On Fri, Mar 6, 2009 at 6:34 PM, Michael Foord 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 Knooper of Knoppix.
Congr
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 th
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 t
Michael Haggerty 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 cons
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
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
> 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 e
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 isn'
"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 recomm
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 b
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
45 matches
Mail list logo
