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
[Python-Dev] Final PyCon Keynote from Google Speaker
Dear Python Colleague: I am happy to say that we have now completed the PyCon DC 2005 keynote speaker lineup, and that the final keynote will be given by Greg Stein, an engineering manager wirh Google's Blogger group, who will be speaking on "Python at Google" Greg is also known to many in the open source world as the chairman of the Apache Foundation, and he is a significant contributor to Subversion, WebDAV and Python. With the opening keynote from a Microsoft speaker, the second keynote from Guido van Rossum (the inventor of Python) and the last keynote from Google, PyCon is beginning to demonstrate just how significant Python has become in the modern world of software and Internet services. I hope you will join me in DC from March 23-25, and possibly attend the four-day sprint being held immediately before the conference. Pre- conference registration is available via http://www.python.org//pycon/2005/register.html This is going to be a great opportunity for all those with an interest in Python to see just how far the language has come. regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications ___ 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
On Friday 04 March 2005 14:35, Raymond Hettinger wrote: > 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? +1 That would seem to be the prudent choice. -- 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
[Python-Dev] Re: Moving towards Python 3.0 (was Re: Speed up
functioncalls) Reply-To: [EMAIL PROTECTED] A month ago, Nathan Binkert wrote: > > Wouldn't it be nicer to have a facility that let you send messages > > between processes and manage concurrency properly instead? You'll > > need > > most of this anyway to do multithreading sanely, and the benefit to > > the > > multiple process model is that you can scale to multiple machines, not > > just processors. For brokering data between processes on the same > > machine, you can use mapped memory if you can't afford to copy it > > around, which gives you basically all the benefits of threads with > > fewer pitfalls. > > I don't think this is an answered problem. There are plenty of > researchers on both sides of this fence. It is not been proven at all > that threads are a bad model. > > http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf or even > http://www.python.org/~jeremy/weblog/030912.html > I want to add: me, too. That is, while all my instincts incline toward message-passing and "bulkier" concurrency which emphasizes clusters more than multiprocessors, what's most certain to me is that we--computing people, academics, all of us together--really don't know yet what the right answers are. *My* personal desire: Python as a healthy industrial-strength language strong enough to support such radical experiments as Stackless, PyPy, a sophisticated multithreader, and so on. It has been; I expect it will be. Cameron Lairdhttp://www.phaseit.net Phaseit, Inc. [EMAIL PROTECTED] +1 281 996 8546 FAX ___ 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] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
OK, so this one is really short. Beyond the fact that I am probably doing this too late at night I also want to give the three people who have stepped forward to take over for me when I stopped writing the Summaries multiple chances to pick up on any of the Skipped Threads or even flesh out any of my thread summaries more. I have asked them to post their writing here to make the choosing of a successor a little on the open side. Hope to send this out Sunday night. --- = Summary Announcements = -- Giving myself a gold watch -- As some of you may have already heard or read, I am retiring from writing the python-dev Summaries after sending out the March 16 - 31 summary. It has been a long time coming and it required a kick in the ass (graciously supplied by Steve Holden) to finally make me let go of doing this and let someone else take over. The joy of the Summaries has dwindled over the 2.5 years I have been doing this. I was only doing them to be helpful. But now I would rather put my time and effort I have for Python into coding work rather than the Summaries. I would like to think I can be more productive and helpful as a programmer than a writer. And so there will only be three more regular Summaries after this written by yours truly. But do not worry about the Summaries dying! When I announced this (see http://mail.python.org/pipermail/python-dev/2005-March/051823.html for the thread that led to this), three individuals stepped forward to pick up the work once I step down. Steven Bethard, Tony Meyer, and Tim Lesher are being considered. I honestly have no clue how the heck I am going to choose between the three of them. As for my last Summary, expect a more expository one with my random thoughts on PyCon, Python, and anything else that comes to mind that I feel like using this space to abuse. You have Scott David Daniels to thank for that format idea for my final hurrah. Go to PyCon! I just booked my hotel room for PyCon_. You going to be there so I can shake your hand, thanking you for supporting Python? .. _PyCon: http://www.pycon.org/ = Summaries = - Python Security Response Team founded - For those of you who don't know, a security hole was found in XML-RPC servers in the stdlib that use register_instance; details at http://www.python.org/security/PSF-2005-001/ . In response to this, Guido has now formed the 'Python Security Response Team`_. This group's job is to respond to any and all security issues that come up as quickly as possible and to issue a patch in a timely fashion. .. _Python Security Response Team: http://www.python.org/security/ Contributing threads: - `Wanted: members for Python Security Response Team <>`__ -- Licensing issues in the stdlib -- It was reported to python-dev that 'profiler' and 'md5 do not conform to the Debian Free Software Guidelines. The specific issue was derived works using Python. This is obviously not a good thing. Things are in the works, though. The hope is to get the copyrights signed over and all of this cleared up. At worst the modules will be replaced with code licensed to the Python Software Foundation. If you care to accelerate this by writing replacements please do so. Contributing threads: - `license issues with profiler.py and md5.h/md5c.c <>`__ === Skipped Threads === + complex I/O problem + Is msvcr71.dll re-redistributable? + Son of PEP 246, redux + Re: PEP 246: LiskovViolation as a name + 2.3.5 and 2.4.1 release plans + Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15 + list of constants -> tuple of constants + Other library updates + Re: python/dist/src/Lib rfc822.py,1.78,1.79 + Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars + Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344 + Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39 + ViewCVS on SourceForge is broken + builtin_id() returns negative numbers + Clarification sought about including a multidimensional array object into Python core ___ 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
