Re: [Python-Dev] Patch Reviewing
Reinhold Birkenfeld wrote: just felt a little bored and tried to review a few (no-brainer) patches. Thanks! They are now all closed. Please understand that there is a chance that a review posted *only* to python-dev might get lost/overlooked by the committers, and then somebody may need to duplicate your work later. So it is better to include the review in the patch, and only post a summary to python-dev. Regards, Martin ___ 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
Re: [Python-Dev] a bunch of Patch reviews
Martin v. Löwis wrote:
Irmen de Jong wrote:
I've looked at one bug and a bunch of patches and
added a comment to them:
Thanks! I have now processed the ones for which I found guidance.
Thank you
As for the remaining ones:
[ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
Looks good but added suggestion about when to test for special case
So what to do about this? Wait whether he revises the patch?
Accept anyway? Update the patch myself?
I think I will revise the patch myself.
I was just waiting for some more input, but
since nobody replied, I'll just go ahead with it.
[ 1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
So what do you propose to do? AFAICT, there is no definition of
SEGMENT_SIZE in a TCP implementation, and I think we should not try
to make up a value.
Well, for the VMS platform a value has been made up...
Why make an exception for that one and not for Win32?
IMO, Python should expose sockets more or less as-is. If the system
has a flaw, Python should expose it instead of working around it.
Is this the default way of treating system flaws, or should
they be considered on a per-case basis? I can imagine that
some system flaws are just plain stupid and are easy to
hide (or circumvent) in the Python implementation.
The recv/send segment size issue can have nasty results
on Win32, see the referenced bug report 853507
socket.recv() raises MemoryError exception which I think
is related to this.
(yes, I know that Tim marked that bug as wontfix)
Note: I'm not too experienced with Win32 programming and so I
don't have a very good argumentation for the buffer size issue
on this platform. If there is somebody with better understanding
of the issues involved here, please advise.
(it's just empirical knowledge that I have that leads me to
believe that win32's tcp implementation suffers from similar
recv/send size problems as VMS does-- for which a special
case was made in the code)
[ 1062014 ] fix for 764437 AF_UNIX socket special linux socket names
Can you please elaborate the problem? What is a special linux socket
name?
See bug report 764437. AF_UNIX sockets on Linux can have so-called
'kernel' socket names that don't show up in the filesystem (regular
unix domain sockets do). The current socketmodule doesn't treat
this special kind of unix domain sockets well.
This fix was submitted during the last python bug day you can
find some more info here too: http://www.python.org/moin/PythonBugDayStatus
Regardless, the comment of the other reviewer is also valid: any patch
needs documentation and test cases.
Yes, Johannes is right. I should have made docs and test cases
but didn't get around to doing that yet.
When my home network is fixed (router failure) I'll try to spend
some time improving the patches.
Regards
Irmen de Jong
___
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
RE: [Python-Dev] Re: [Python Dev] PEP 309
Nick Coghlan writes: I'm actually half-tempted to suggest that [map, filter and reduce] should be aliased in the functional module for 2.5 (in addition to being in builtins - ala the contents of the exceptions module). Well, I think it's a good idea, so I'll formally propose it! Let's alias map, filter, and reduce into the functional module now that it exists. This doesn't create any need or pressure to remove these as builtins, but it does contemplate a day when we might choose to make such a choice. -- Michael Chermside ___ 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
RE: [Python-Dev] Re: [Python Dev] PEP 309
Nick Coghlan writes: I'm actually half-tempted to suggest that [map, filter and reduce] should be aliased in the functional module for 2.5 (in addition to being in builtins - ala the contents of the exceptions module). Well, I think it's a good idea, so I'll formally propose it! Let's alias map, filter, and reduce into the functional module now that it exists. This doesn't create any need or pressure to remove these as builtins, but it does contemplate a day when we might choose to make such a choice. -1 map(), filter(), and zip() have already evolved into imap(), ifilter(), ifilterfalse(), and izip() which we already have in the itertools module. Introducing extra copies of the old list/builtin versions doesn't improve anyone's life. It adds bloat without adding new functionality. Also, someone else (Alex maybe) was proposing another module for functions that consume an iterator and return a scalar (like sum(), min(), max(), etc). The idea was to make some of the itertools recipes into a module (any, all, no, take, etc). If that happens, then there would be yet another possible home for reduce. If you want to add something new and useful to the functional module, try a compose() function. Raymond ___ 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
[Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.27, 1.1193.2.28
On Friday 04 March 2005 03:56, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Misc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6024/Misc Modified Files: Tag: release24-maint NEWS Log Message: SF bug #1155938: Missing None check for __init__(). Won't this break working (but erroneous) code? If so, should it be applied to the 2.4 branch? class f(object): ... def __init__(self): ... self.a = 1 ... return True ... a=f() -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
RE: [Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.27, 1.1193.2.28
SF bug #1155938: Missing None check for __init__(). Won't this break working (but erroneous) code? If so, should it be applied to the 2.4 branch? Hmm, more than one poster found the error message to be helpful in detecting buggy code. The non-None return value was a pretty good indicator that the code was doing something other than what the programmer intended. OTOH, there is almost certainly some existing, working code that would stop working. How about changing this to a warning in Py2.4? Raymond ___ 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
