headers
Reinhold Birkenfeld | 1 Jan 2005 03:19
Favicon

Patch Reviewing

Hello,

just felt a little bored and tried to review a few (no-brainer) patches.

Here are the results:

* Patch #1051395

  Minor fix in Lib/locale.py: Docs say that function _parse_localename
  returns a tuple; but for one codepath it returns a list.

  Patch fixes this by adding tuple(), recommending apply.

* Patch #1046831

  Minor fix in Lib/distutils/sysconfig.py: it defines a function to
  retrieve the Python version but does not use it everywhere; Patch
  fixes this, recommending apply.

* Patch #751031

  Adds recognizing JPEG-EXIF files (produced by digicams) to imghdr.py.
  Recommending apply.

* Patch #712317

  Fixes URL parsing in urlparse for URLs such as http://foo?bar. Splits
  at '?', so assigns 'foo' to netloc and 'bar' to query instead of
  assigning 'foo?bar' to netloc. Recommending apply.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brett C. | 1 Jan 2005 04:11
Picon

python-dev Summary for 2004-11-16 through 2004-11-30 [draft]

With school starting up again Monday and New Years being tomorrow I don't plan 
to send this out until Tuesday.

Hope everyone has a good New Years.

-Brett

-----------------------------------

=====================
Summary Announcements
=====================
PyCon_ is coming up!  Being held March 23-25 in Washington, DC, registration is 
now open at http://www.python.org/pycon/2005/register.html for credit card 
users (you can pay by check as well; see the general info page for the conference).

.. _PyCon: http://www.python.org/pycon/2005/

=========
Summaries
=========
---------------------------------------------
Would you like the source with your function?
---------------------------------------------
Would you like all functions and classes to contain a __pycode__ attribute that 
contains a string of the code used to compile that code object?  Well, that 
very idea was proposed.  You would use a command-line switch to turn on the 
feature in order to remove the memory and any performance overhead for the 
default case of not needing this feature.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Hettinger | 1 Jan 2005 03:53
Favicon

Re: Patch Reviewing

[Reinhold Birkenfeld]
> just felt a little bored and tried to review a few (no-brainer) patches.

Thanks, please assign to me and I'll apply them.

Raymond Hettinger
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Kurt B. Kaiser | 1 Jan 2005 05:55
Picon
Favicon

Weekly Python Patch/Bug Summary

Patch / Bug Summary
___________________

Patches :  261 open ( +4) /  2718 closed ( +3) /  2979 total ( +7)
Bugs    :  801 open ( -6) /  4733 closed (+16) /  5534 total (+10)
RFE     :  165 open ( +2) /   139 closed ( +0) /   304 total ( +2)

New / Reopened Patches
______________________

Patch for bug 999042.  (2004-12-23)
       http://python.org/sf/1090482  opened by  Darek Suchojad

_AEModule.c patch  (2004-12-25)
       http://python.org/sf/1090958  opened by  has

py-compile DESTDIR support to compile in correct paths  (2004-12-27)
CLOSED http://python.org/sf/1091679  opened by  Thomas Vander Stichele

Refactoring Python/import.c  (2004-12-30)
       http://python.org/sf/1093253  opened by  Thomas Heller

socket leak in SocketServer  (2004-12-30)
       http://python.org/sf/1093468  opened by  Shannon -jj Behrens

sanity check for readline remove/replace  (2004-12-30)
       http://python.org/sf/1093585  opened by  DSM

miscellaneous doc typos  (2004-12-31)
CLOSED http://python.org/sf/1093896  opened by  DSM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Ippolito | 2 Jan 2005 04:40
Gravatar

Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3

On Jan 1, 2005, at 5:33 PM, jackjansen <at> users.sourceforge.net wrote:

> Update of /cvsroot/python/python/dist/src/Mac/OSX
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14408
>
> Modified Files:
> 	fixapplepython23.py
> Log Message:
> Create the wrapper scripts for gcc/g++ too.
>
> +SCRIPT="""#!/bin/sh
> +export MACOSX_DEPLOYMENT_TARGET=10.3
> +exec %s "${ <at> }"

This script should check to see if MACOSX_DEPLOYMENT_TARGET is already 
set.  If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for 
compilation (say I'm compiling an extension that requires 10.4 
features) then I'm going to have some serious problems with this fix.

-bob

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Jack Jansen | 2 Jan 2005 22:28
Picon
Picon
Favicon

Re: Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3


On 2-jan-05, at 4:40, Bob Ippolito wrote:
>> +SCRIPT="""#!/bin/sh
>> +export MACOSX_DEPLOYMENT_TARGET=10.3
>> +exec %s "${ <at> }"
>
> This script should check to see if MACOSX_DEPLOYMENT_TARGET is already 
> set.  If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for 
> compilation (say I'm compiling an extension that requires 10.4 
> features) then I'm going to have some serious problems with this fix.

I was going to do that, but then I thought it didn't make any sense, 
because this script is *only* used in the context of Apple-provided 
Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 
10.3 (be it lower or higher) while compiling an extension for Apple's 
2.3 is going to produce disappointing results anyway.

But, if I've missed a use case, please enlighten me.
--
Jack Jansen, <Jack.Jansen <at> cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Ippolito | 2 Jan 2005 22:35
Gravatar

Re: Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3


On Jan 2, 2005, at 4:28 PM, Jack Jansen wrote:

>
> On 2-jan-05, at 4:40, Bob Ippolito wrote:
>>> +SCRIPT="""#!/bin/sh
>>> +export MACOSX_DEPLOYMENT_TARGET=10.3
>>> +exec %s "${ <at> }"
>>
>> This script should check to see if MACOSX_DEPLOYMENT_TARGET is 
>> already set.  If I have some reason to set 
>> MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an 
>> extension that requires 10.4 features) then I'm going to have some 
>> serious problems with this fix.
>
> I was going to do that, but then I thought it didn't make any sense, 
> because this script is *only* used in the context of Apple-provided 
> Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other 
> than 10.3 (be it lower or higher) while compiling an extension for 
> Apple's 2.3 is going to produce disappointing results anyway.
>
> But, if I've missed a use case, please enlighten me.

You're right, of course.  I had realized that I was commenting on the 
fixpython script after I had replied, but my concern is still 
applicable to whatever solution is used for Python 2.4.1.  Anything 
lower than 10.3 is of course an error, in either case.

-bob
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Jansen | 3 Jan 2005 00:16
Picon
Picon
Favicon

Re: Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3


On 2-jan-05, at 22:35, Bob Ippolito wrote:
>> On 2-jan-05, at 4:40, Bob Ippolito wrote:
>>>> +SCRIPT="""#!/bin/sh
>>>> +export MACOSX_DEPLOYMENT_TARGET=10.3
>>>> +exec %s "${ <at> }"
>>>
>>> This script should check to see if MACOSX_DEPLOYMENT_TARGET is 
>>> already set.  If I have some reason to set 
>>> MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an 
>>> extension that requires 10.4 features) then I'm going to have some 
>>> serious problems with this fix.
>>
>> I was going to do that, but then I thought it didn't make any sense, 
>> because this script is *only* used in the context of Apple-provided 
>> Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other 
>> than 10.3 (be it lower or higher) while compiling an extension for 
>> Apple's 2.3 is going to produce disappointing results anyway.
>>
>> But, if I've missed a use case, please enlighten me.
>
> You're right, of course.  I had realized that I was commenting on the 
> fixpython script after I had replied, but my concern is still 
> applicable to whatever solution is used for Python 2.4.1.  Anything 
> lower than 10.3 is of course an error, in either case.

2.4.1 will install this fix into Apple-installed Python 2.3 (if 
applicable, i.e. if you're installing 2.4.1 on 10.3), but for its own 
use it will have the newer distutils, which understands that it needs 
to pick up MACOSX_DEPLOYMENT_TARGET from the Makefile, so it'll never
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Ippolito | 3 Jan 2005 03:43
Gravatar

Darwin's realloc(...) implementation never shrinks allocations

Quite a few notable places in the Python sources expect realloc(...) to 
relinquish some memory if the requested size is smaller than the 
currently allocated size.  This is definitely not true on Darwin, and 
possibly other platforms.  I have tested this on OpenBSD and Linux, and 
the implementations on these platforms do appear to relinquish memory, 
but I didn't read the implementation.  I haven't been able to find any 
documentation that states that realloc should make this guarantee, but 
I figure Darwin does this as an "optimization" and because Darwin 
probably can't resize mmap'ed memory (at least it can't from Python, 
but this probably means it doesn't have this capability at all).

It is possible to "fix" this for Darwin, because you can ask the 
default malloc zone how big a particular allocation is, and how big an 
allocation of a given size will actually be (see: <malloc/malloc.h>).  
The obvious place to put this would be PyObject_Realloc, because this 
is at least called by _PyString_Resize (which will fix 
<http://python.org/sf/1092502>).

Should I write up a patch that "fixes" this?  I guess the best thing to 
do would be to determine whether the fix should be used at runtime, by 
allocating a meg or so, resizing it to 1 byte, and see if the size of 
the allocation changes.  If the size of the allocation does change, 
then the system realloc can be trusted to do what Python expects it to 
do, otherwise realloc should be done "cleanly" by allocating a new 
block (returning the original on failure, because it's good enough and 
some places in Python seem to expect that shrink will never fail), 
memcpy, free, return new block.

I wrote up a small hack that does this realloc indirection to CVS 
trunk, and it doesn't seem to cause any measurable difference in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Peters | 3 Jan 2005 06:13
Picon

Re: Darwin's realloc(...) implementation never shrinks allocations

[Bob Ippolito]
> Quite a few notable places in the Python sources expect realloc(...) to
> relinquish some memory if the requested size is smaller than the
> currently allocated size.

I don't know what "relinquish some memory" means.  If it means
something like "returns memory to the OS, so that the reported process
size shrinks", then no, nothing in Python ever assumes that.  That's
simply because "returns memory to the OS" and "process size" aren't
concepts in the C standard, and so nothing can be said about them in
general -- not in theory, and neither in practice, because platforms
(OS+libc combos) vary so widely in behavior here.

As a pragmatic matter, I *expect* that a production-quality realloc()
implementation will at least be able to reuse released memory,
provided that the amount released is at least half the amount
originally malloc()'ed (and, e.g., reasonable buddy systems may not be
able to do better than that).

> This is definitely not true on Darwin, and possibly other platforms.  I have tested
> this on OpenBSD and Linux, and the implementations on these platforms do
> appear to relinquish memory,

As above, don't know what this means.

> but I didn't read the implementation.  I haven't been able to find any
> documentation that states that realloc should make this guarantee,

realloc() guarantees very little; it certainly doesn't guarantee
anything, e.g., about OS interactions or process sizes.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane