Mailman 3 July 2001 - Python-Dev

Making a .pyd using Cygwin?
by Greg Ewing 05 Jul '01

05 Jul '01

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 days ago. Thanks for any help, Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

3 2

While we're deprecating...
by Thomas Wouters 05 Jul '01

05 Jul '01

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 sizes other than '8', and rip out the code in 2.3 ? -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 3

python-dev summary 2001-06-21 - 2001-07-05
by Michael Hudson 05 Jul '01

05 Jul '01

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 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.

1 0

python-dev summary 2001-06-21 - 2001-07-05
by Michael Hudson 05 Jul '01

05 Jul '01

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, 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.

1 0

Re: [Python-Dev] summer summaries
by Michael Hudson 05 Jul '01

05 Jul '01

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. > > Been there, done that. :) I thought you might know what I was talking about here... Cheers, M. -- If your telephone company installs a system in the woods with no one around to see them, do they still get it wrong? -- Robert Moir, alt.sysadmin.recovery

1 0

Will the new type system allow automatic coercion?
by Jack Jansen 05 Jul '01

05 Jul '01

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 way, these CoreFoundation objects, sort-of inherited from NextStep and they share a lot of design with Python objects, but I digress) that can show itself as a Unicode string or an 8 bit string or a number of other things. It would be nice if users could pass these CFString objects in places where a string or unicode is expected. Simply said, if PyArg_Parse s format would accept my objects. Will the new type system allow me to do this? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

summer summaries
by Michael Hudson 05 Jul '01

05 Jul '01

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 connection should be back to full strength in October. Cheers, M. -- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work. -- C Hacking -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

2 1

Checkin problems (slightly off-topic)
by Thomas Heller 04 Jul '01

04 Jul '01

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; previous revision: 1.21 done Mailing python-checkins(a)python.org... Generating notification message... Generating notification message... done. 2001-07-04 09:52:14 Failed to get user name for uid 34174 The checkin succeeded, but no mail is sent :-( I have no clue what uid 34174 is, surely not my SF user id (which is 11105). Has anyone seen this problem before, or can offer other help? Thanks, Thomas

4 7

CVS
by Thomas Wouters 03 Jul '01

03 Jul '01

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 revision elease21' in <file>" warnings and just all logentries for those files. Am I missing something simple, here, or should I hack logmerge to parse the symbolic names, figure out the even-dotted revision for each file from the uneven-dotted branch-tag, and filter out stuff outside that range ? :P -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 4

PEP 250, site-python, site-packages
by Gregor Hoffleit 03 Jul '01

03 Jul '01

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