Mailman 3 July 2001 - Python-Dev

Making a .pyd using Cygwin?
by Greg Ewing July 5, 2001

July 5, 2001

Is it feasible to compile a Python extension module for Windows using Cygwin? I have tried this, and the linker tells me that it can't export '_bss_start__', '_bss_end__', '_data_start__' and '_data_end__' because they're not defined. I tried defining some symbols with those names in a c file and got it to link, but importing the resulting extension causes the interpreter to hang. I'm using Python 2.1, Windows 2000 Professional, and whatever version of Cygwin was the latest as of a couple of … [View More]

3 2

While we're deprecating...
by Thomas Wouters July 5, 2001

July 5, 2001

While we're in the deprecation mood (not that I changed my mind on xrage() ;P) how about we deprecate the alternate-tab-size-comment checks of the parser. That is, generate a deprecation warning for these comments: "tab-width:", /* Emacs */ ":tabstop=", /* vim, full form */ ":ts=", /* vim, abbreviated form */ "set tabsize=", /* will vi never die? */ with … [View More]

3 3

python-dev summary 2001-06-21 - 2001-07-05
by Michael Hudson July 5, 2001

July 5, 2001

The less typo-ed version! This is a summary of traffic on the python-dev mailing list between June 21 and July 4 (inclusive) 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list(a)python.org or comp.lang.python in the usual way. Give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration) All python-dev members are interested in seeing ideas … [View More]discussed by the community, so don't hesitate to take a stance on a PEP if you have an opinion. This is the eleventh summary written by Michael Hudson. Summaries are archived at: <http://starship.python.net/crew/mwh/summaries/> Posting distribution (with apologies to mbm) Number of articles in summary: 252 40 | [|] | [|] | [|] | [|] | [|] 30 | [|] | [|] | [|] [|] [|] | [|] [|] [|] [|] | [|] [|] [|] [|] 20 | [|] [|] [|] [|] | [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 0 +-004-019-007-016-042-018-028-013-005-015-016-029-027-013 Thu 21| Sat 23| Mon 25| Wed 27| Fri 29| Sun 01| Tue 03| Fri 22 Sun 24 Tue 26 Thu 28 Sat 30 Mon 02 Wed 04 This will be my last python-dev summary for a while, as I'm going to be mostly away from the internet for the summer. However, Andrew Kuchling has agreed to take up writing them again, so there should be no interruption in the summaries. * Support for "wide" Unicode characters * Paul Prescod posted a draft of PEP 261 'Support for "wide" Unicode characters': <http://mail.python.org/pipermail/python-dev/2001-June/015644.html> which proposes adding a compile time option to configure unicode objects to store "code points" (the integers that the unicode specification maps to "characters" -- though that word is dangerously overlodaed in the Unicode arena) in 32 bit integers -- they're currently stored in 16 bits. This was (I believe) at least partially inspired by the Unicode Consortium assigning code points outside the "Basic Multilingual Plane" (i.e. the range of 16 bit integers). Noone is convinced that this is the best possible solution (a better solution might be to have unicode objects that could either store code points in 16 bits or 32 bits as necessary, and this solution could have binary compatibility problems), but it seems noone has the time to implement a better one (and a better one would probably have compatibility problems that couldn't be fixed by a simple recompile): <http://mail.python.org/pipermail/python-dev/2001-July/015674.html> (I apologise for any abuse of terminology in the above - I know very little about the issues surrounding Unicode). * Python specializing compiler * Armin Rigo announced his "Python specializing compiler", psyco: <http://mail.python.org/pipermail/python-dev/2001-June/015503.html> It works on the principle that you can compile a faster version of a function if you know stuff about the arguments it's likely to be called with. This is one of the more asthetically pleasing of the possible ways to speed Python up (it's similar to some tactics used by the seemingly defunct self compiler), but it's still a very large amount of work away from being useful... * IPv6 * *Very* preliminary support for IPv6 - the "next generation internet protocol" was checked in. The support thus far doesn't actually support IPv6 at all, but rather emulates IPv6's new functions for IPv4 addresses, so that code for Python 2.2 will hopefully be portable between machines that do and do not support IPv6, whilst being able to use IPv6 where it is supported (I hope that makes sense). Unfortunately the checkin broke the build on some platforms (OSF1, Windows) but I believe these problems are now sorted out. IPv6 support has been muttered about for years now, so it's nice to finally see some movement, even if it is causing some x-platform pain. * PEP 260: simplifying xrange * Guido posted PEP 260, a proposal to removed some of the less useful aspects of the xrange type: <http://mail.python.org/pipermail/python-dev/2001-June/015590.html> Support was muted; there's the usual concern on removing "little used" features -- what if someone (who maybe doesn't read comp.lang.python or these summaries) uses them? * site-python, site-packages * Gregor Hoffleit posted a request that <prefix>/lib/site-python be considered a standard install target: <http://mail.python.org/pipermail/python-dev/2001-July/015715.html> as the current standard of <prefix>/lib/pythonX.X/site-packages/ makes life awkward for packagers. It's possible Gregor asked the wrong bunch of people; a non-version dependent path makes life awkward for those who want to mantain more than version of Python, and that includes most of the people on pyton-dev. OTOH, it probably also includes everyone who cares about the cross-version portability of the code they write, so it seems that movemnet is unlikely here (could be wrong, though). Cheers, M. [View Less]

1 0

python-dev summary 2001-06-21 - 2001-07-05
by Michael Hudson July 5, 2001

July 5, 2001

This is a summary of traffic on the python-dev mailing list between June 21 and July 4 (inclusive) 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list(a)python.org or comp.lang.python in the usual way. Give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration) All python-dev members are interested in seeing ideas discussed by the community, … [View More]so don't hesitate to take a stance on a PEP if you have an opinion. This is the eleventh summary written by Michael Hudson. Summaries are archived at: <http://starship.python.net/crew/mwh/summaries/> Posting distribution (with apologies to mbm) Number of articles in summary: 252 40 | [|] | [|] | [|] | [|] | [|] 30 | [|] | [|] | [|] [|] [|] | [|] [|] [|] [|] | [|] [|] [|] [|] 20 | [|] [|] [|] [|] | [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 0 +-004-019-007-016-042-018-028-013-005-015-016-029-027-013 Thu 21| Sat 23| Mon 25| Wed 27| Fri 29| Sun 01| Tue 03| Fri 22 Sun 24 Tue 26 Thu 28 Sat 30 Mon 02 Wed 04 This will be my last python-dev summary for a while, as I'm going to be mostly away from the internet for the summer. However, Andrew Kuchling has agreed to take up writing them again, so there should be no interruption in the summaries. * Support for "wide" Unicode characters * Paul Prescod posted a draft of PEP 261 'Support for "wide" Unicode characters': <http://mail.python.org/pipermail/python-dev/2001-June/015644.html> which proposes adding a compile time option to configure unicode objects to store "code points" (the integers that the unicode specification maps to "characters" -- though that word is dangerously overlodaed in the Unicode arena) in 32 bit integers -- they're currently stored in 16 bits. This was (I believe) at least partially inspired by the Unicode Consortium assigning code points outside the "Basic Multilingual Plane" (i.e. the range of 16 bit integers). Noone is convinced that this is the best possible solution (a better solution might be to have unicode objects that could either store code points in 16 bits or 32 bits as necessary, and this solution could have binary compatibility problems), but it seems noone has the time to implement a better one (and a better one would probably have compatibility problems that couldn't be fixed by a simple recompile): <http://mail.python.org/pipermail/python-dev/2001-July/015674.html> (I apologise for any abuse of terminology in the above - I know very little about the issues surrounding Unicode). * Python specializing compiler * Armin Rigo announced his "Python specializing compiler", psyco: <http://mail.python.org/pipermail/python-dev/2001-June/015503.html> It works on the principle that you can compile a faster version of a function if you know stuff about the arguments it's likely to be called with. This is one of the more asthetically pleasing of the possible ways to speed Python up (it's similar to some tactics used by the seemingly defunct self compiler), but it's still a very large amount of work away from being useful... * IPv6 * *Very* preliminary support for IPv6 - the "next generation internet protocol" was checked in. The support thus far doesn't actually support IPv6 at all, but rather emulates IPv6's new functions for IPv4 addresses, so that code for Python 2.2 will hopefully be portable between machines that do and do not support IPv6, whilst being able to use IPv6 where it is supported (I hope that makes sense). Unfortunately the checkin broke the build on some platforms (OSF1, Windows) but I believe these problems are now sorted out. IPv6 support has been muttered about for years now, so it's nice to finally see some movement, even if it is causing some x-platform pain. * PEP 260: simplifying xrange * Guido posted PEP 260, a proposal to removed some of the less useful aspects of the xrange type: <http://mail.python.org/pipermail/python-dev/2001-June/015590.html> Support was muted; there's the usual concern on removing "little used" features -- what if someone (who maybe doesn't read comp.lang.python or these summaries) uses them? * site-python, site-packages * Gregor Hoffleit posted a request that <prefix>/lib/site-python be considered a standard install target: <http://mail.python.org/pipermail/python-dev/2001-July/015715.html> as the current standard of <prefix>/lib/pythonX.X/site-packages/ makes life awkward for packagers. It's possible Gregor asked the wrong bunch of people; a non-version dependent path makes life awkward for those who want to mantain more than version of Python, and that includes most of the people on pyton-dev. OTOH, it probably also includes everyone who cares about the cross-version portability of the code they write, so it seems that movemnet is unlikely here (could be wrong, though). Cheers, M. [View Less]

1 0

Re: [Python-Dev] summer summaries
by Michael Hudson July 5, 2001

July 5, 2001

Andrew Kuchling <akuchlin(a)mems-exchange.org> writes: > On Wed, Jul 04, 2001 at 11:30:42PM +0100, Michael Hudson wrote: > >would be significantly more tedious. Would someone else be able to do > >them for a bit? I can provide the scripts I use to generate the > > I'm willing to pick them up again for a bit. Thanks! I've got one in the boiler for today, which I'll post soon. > >I could also do with a break from it for more general reasons. > > … [View More]

1 0

Will the new type system allow automatic coercion?
by Jack Jansen July 4, 2001

July 4, 2001

Something I've suddenly started to need is automatic coercion implemented by the source type. I have a type implemented in C, and while automatic coercion from any other type to my type is easy to implement (in your O& routine you simply check whether the passed object is of a type you can coerce) there is no way to do the reverse (at least, not that I'm aware of, please enlighten me). And now I have this CFString type (a wrapper around the MacOS CoreFoundation object. Nice things, by the … [View More]

2 1

summer summaries
by Michael Hudson July 4, 2001

July 4, 2001

My internet connection is going to get drastically worse tomorrow, and while I could still do the python-dev summaries over the summer, it would be significantly more tedious. Would someone else be able to do them for a bit? I can provide the scripts I use to generate the distributions and format into text and xhtml, and continue to archive them on my starship pages. It's not that much work; a few hours a fortnight. I could also do with a break from it for more general reasons. My internet … [View More]

2 1

Checkin problems (slightly off-topic)
by Thomas Heller July 4, 2001

July 4, 2001

After I tried to set up syncmail notification for the anygui project, I did not get it to work. Then I found out that exactly the same problem occurs if I try to checkin into other SF projects I have, also python. Here is the message I get: C:\sf\distutils\distutils\command>cvs commit -m "dummy checkin for testing, please ignore" cvs commit: Examining . Checking in bdist_wininst.py; /cvsroot/python/distutils/distutils/command/bdist_wininst.py,v <-- bdist_wininst.py new revision: 1.22; … [View More]

4 7

CVS
by Thomas Wouters July 3, 2001

July 3, 2001

Slightly off-topic, but I've depleted all my other sources :) I'm trying to get CVS to give me all logentries for all checkins in a specific branch (the 2.1.1 branch) so I can pipe it through logmerge. It seems the one thing I'm missing now is a branchpoint tag (which should translate to a revision with an even number of dots, apparently) but 'release21' and 'release21-maint' both don't qualify. Even the usage logmerge suggests (cvs log -rrelease21) doesn't work, gives me a bunch of "no … [View More]

3 4

PEP 250, site-python, site-packages
by Gregor Hoffleit July 3, 2001

July 3, 2001

PEP 250 talks about adopting site-packages for Windows systems. I'd like to discuss the sitedirs as a whole. Currently, site.py appends the following sitedirs to sys.path: * <prefix>/lib/python<version>/site-packages * <prefix>/lib/site-python If exec-prefix is different from prefix, then also * <exec-prefix>/lib/python<version>/site-packages * <exec-prefix>/lib/site-python

8 15