Building C/C++ Extensions for Python
Description:
Enthought is proud to announce "Building C/C++ extensions for Python,"
an intense 3 day course taught by David Beazley, David Abrahams, and
Eric Jones, the lead authors of SWIG, Boost.Python, and Weave. This
hands-on course is geared toward C/C++ programmers and teaches the
start-to-finish process of exposing C/C++ libraries for use in Python.
Students are sure to benefit from this opportunity to learn from three
of the leading experts in the field.
The class teaches the fundamentals of designing and building Python
extensions and addresses the common problems that arise during the
process. Boost.Python, SWIG, and Weave are central to the discussion,
and each is covered in depth. Fundamental topics such as handling
reference counts and building Python 2.2 style extension types by hand
are also covered. Other topics discussed include Pyrex, distributing
extensions using distutils, debugging extensions, and solving shared
library issues.
The course is divided equally between lectures and hands-on programming
sessions. Users will need to bring either a Linux or a Windows
NT/2000/XP, network enabled, laptop to the class with Python 2.2 and a
C++ compiler installed for the programming sessions. More information
about setup requirements is available at the website.
Space is limited.
Website:
http://www.enthought.com/training/building_extensions.html
Signup Information:
Call (512) 536-1057 to reserve your place.
Dates:
December 9th, 10th, and 11th, 2002 (Monday through Wednesday)
Instruction Hours:
Instruction runs from 9am-9pm on the first two days (with breaks for
lunch, dinner, and between sessions), and 9am-6pm on the final day of
the class.
Location:
The Driskill Hotel
www.driskillhotel.com
604 Brazos Street
Austin, Texas
The Driskill is conveniently located in the heart of downtown Austin.
And, yes, it has high speed internet connections in the guest rooms.
What's Included:
3 nights of lodging
All meals and snacks
Unlimited caffeinated drinks
Class materials
3 days of instruction
Cost:
$2400.00 US.
About the Authors:
David Beazley
David is an assistant professor in the Department of Computer Science at
the University of Chicago. He has worked on Python extension building
since 1996 and is the creator of SWIG (www.swig.org). He is also the
author of the "Python Essential Reference." David holds a PhD in
Computer Science from the University of Utah.
David Abrahams
David is a founding member and moderator of Boost (www.boost.org) and
heads Boost Consulting, a company dedicated to providing professional
support and development services for the Boost C++ libraries and
associated tools. He has been an ANSI/ISO C++ committee member since
1996, when he contributed a theory, specification, and implementation of
exception handling for the C++ standard library. In his 14-year career
he has developed applications for the desktop and embedded devices in
the fields of music software, speech recognition, and circuit
simulation. David holds a BSE in Computer Science from the University
of Pennsylvania.
Eric Jones
Eric has a broad background in engineering and software development and
leads Enthought's product engineering and software design. Eric is a
lead developer on the SciPy (www.scipy.org) and Weave projects and has
taught numerous courses about Python and how to leverage it for
scientific computing. Prior to co-founding Enthought, Eric worked in
the fields of numerical electromagnetics and genetic optimization. Eric
holds a PhD degree in Electrical Engineering from Duke University.
----------------------------------------------
eric jones 515 Congress Ave
www.enthought.com Suite 1614
512 536-1057 Austin, Tx 78701
pycurl -- A Python interface to the curl library
Version 7.10.1
What is it?
-----------
The pycurl package is a Python interface to the curl library
(http://curl.haxx.se/libcurl/). pycurl has been successfully built
and tested with Python versions from 1.5.2 to 2.2.2 on various Unix
platforms and Windows.
The curl library is a client-side URL transfer library supporting FTP,
FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE and LDAP. The curl
library also supports HTTPS certificates, HTTP POST, HTTP PUT, FTP
uploads, proxies, cookies, basic authentication, file transfer resume
of FTP sessions, HTTP proxy tunneling and more. For information on
how the curl library works, please consult the curl library web pages
(http://curl.haxx.se/libcurl/using/).
All the functionality provided by the curl library can used through
the pycurl interface.
Download
--------
The latest version of pycurl can be obtained at:
http://pycurl.sourceforge.net/
Changes since the last version
------------------------------
* Added new module-level function version_info() from
libcurl-7.10.
Licence
-------
Copyright (c) 2001-2002 by Kjetil Jacobsen
Copyright (c) 2001-2002 by Markus F.X.J. Oberhumer
pycurl is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published
by the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
=================================================
SC-Track Roundup 0.5.1 - an issue tracking system
=================================================
This is a bugfix release for version 0.5.0 - if you're upgrading from before
that, you *must* read doc/upgrading.txt!
Unfortunately, the Zope frontend for Roundup is currently broken. I will be
looking into fixing it for the next patch release.
Roundup requires python 2.1.3 or later for correct operation.
We've had a good crack at bugs (thanks to all who contributed!):
- fixed filter() with no sort/group (sf bug 618614)
- fixed register with no session (sf bug 618611)
- fixed log / pid file path handling in roundup-server (sf bug 617981)
- fixed old gadfly compatibiltiy problem, for sure this time (sf bug 612873)
- https URLs from config now recognised as valid (sf bug 619829)
- nicer display of tracker list in roundup-server (sf bug 619769)
- fixed some missed renaming instance -> tracker (sf bug 619769)
- allow blank passwords again (sf bug 619714)
- made form table cell alignment consistent (sf bug 621887)
- include stylesheet in docs (sf bug 623183)
- store PIPE messages so we can re-send them on errors (sf bug 623082)
- implemented "retire" cgi action, added to user index (sf bug 618612)
- included doc ideas from Bernhard Reiter (sf feature 621941)
- handle "unset" status in status auditor (sf bug 621250)
- homogenise newlines in CGI text submissions (sf bug 614072)
- merged Zope Collector #372 fix from ZPT CVS trunk
- implemented the missing Interval.__add__
- metakit cleanups
- nicer "navigation" style in index views
- highlight index rows in groups of three
- handle missing Link values in anydbm backend set() operation
- expose the tracker config as a variable for templating
- fixed history to display username instead of userid
- shipped templates didn't import all hyperdb types in dbinit.py
- fixed bug in Interval serialisation
- issues in 'done-cbb' are now also moved to 'chatting' on new messages
- added ability to implement new templating utility methods
- expose the Date.pretty method to templating
Source and documentation is available at the website:
http://roundup.sourceforge.net/
Release Info (via download page):
http://sourceforge.net/projects/roundup
Mailing lists - the place to ask questions:
http://sourceforge.net/mail/?group_id=31577
About Roundup
=============
Roundup is a simple-to-use and -install issue-tracking system with
command-line, web and e-mail interfaces. It is based on the winning design
from Ka-Ping Yee in the Software Carpentry "Track" design competition.
Note: Ping is not responsible for this project. The contact for this project
is richard(a)users.sourceforge.net.
Roundup manages a number of issues (with flexible properties such as
"description", "priority", and so on) and provides the ability to:
(a) submit new issues,
(b) find and edit existing issues, and
(c) discuss issues with other participants.
The system will facilitate communication among the participants by managing
discussions and notifying interested parties when issues are edited. One of
the major design goals for Roundup that it be simple to get going. Roundup
is therefore usable "out of the box" with any python 2.1+ installation. It
doesn't even need to be "installed" to be operational, though a
disutils-based install script is provided.
It comes with two issue tracker templates (a classic bug/feature tracker and
a minimal skeleton) and six database back-ends (anydbm, bsddb, bsddb3, sqlite,
metakit and gadfly).
Plex 1.1.4 is available:
http://www.cosc.canterbury.ac.nz/~greg/python/Plex/
This version fixes a bug which could cause the argument
of a Rep or Rep1 to fail to match at the beginning of
a line.
What is Plex?
-------------
Plex is a lexical analysis module for Python
which provides Flex-like facilities. See the
above URL for more information.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Ta-daa!
The release of Python 2.2.2 is here. This is a fully backwards
compatible bugfix release for Python 2.2.1.
Thanks to all who submitted last-minute bug reports and fixes -- and
thanks even more to those who didn't wait until the last minute! :-)
Python 2.2.2 has a large number of bug fixes in all areas of the
interpreter and the library; for a full account see the release notes,
available via the link below. With special dispensation from the
"bugfixes only" rule, a brand new version of the email package is
also included: email 2.4.3.
The new release is available here:
http://www.python.org/2.2.2/
It will soon be available from mirror sites all over the world -- for
a speedy download, try the mirror site nearest to you first:
http://www.python.org/Mirrors.html
As usual, a Windows installer and a Unix/Linux source tarball are made
available, as well as tarballs of the documentation in various forms.
At the moment, no Mac version is available, though I expect that Jack
Jansen will produce one soon. Likewise, no Linux RPMs are available
yet; I expect that Sean Reifschneider will prepare these shortly.
I'm especially grateful to Michael Hudson, Raymond Hettinger and Neal
Norwitz for their hard work on backporting the large volume of patches
from Python 2.3. Without them this release would not have been
possible.
--Guido van Rossum (home page: http://www.python.org/~guido/)
USENIX'03 - FREENIX Track
June 9-14, 2003
San Antonio, Texas
http://www.usenix.org/events/usenix03/cfp/freenix.html
I'd just like to encourage members of the Python community to consider
submitting a paper to the USENIX'03 FREENIX track. FREENIX is an
ideal venue for describing new and interesting work on open-source and
freely available software projects. Although submissions should
describe mature work, papers do not need to be research papers. In
fact, submissions describing projects that are underway, but not yet
finished are actively encouraged.
Putting on my educator hat for a moment, I'd also like to add that
FREENIX is a very nice venue for students. USENIX has always
encouraged student submissions--in fact, student presenters often
receive free conference registration and may apply for grants to cover
travel and hotel expenses. Therefore, if you're working on something
cool, this is a perfect opportunity to tell people about it.
More details about FREENIX can be found at the above URL. Submissions
are due by November 18, 2002. Hopefully you'll join us in San
Antonio!
Cheers,
David Beazley
(Member, FREENIX Program Committee)
Pyrex 0.4.5 is now available:
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
New Features:
* There is now a 'public' declaration for
making Pyrex-defined variables and functions
available to external C code.
There are also some other minor improvements and bug
fixes. See the CHANGES file in the distribution for a
full list.
What is Pyrex?
--------------
Pyrex is a new language for writing Python extension modules.
It lets you freely mix operations on Python and C data, with
all Python reference counting and error checking handled
automatically.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
This is a summary of traffic on the `python-dev mailing list`_ between
October 1, 2002 and October 13, 2002 (inclusive). It is intended to
inform the wider Python community of on-going developments on the list
that might interest the wider Python community. To comment on
anything mentioned here, 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 (or anything else for that matter)
if you have an opinion. And if all of this really interests you then
get involved and join Python-dev!
This is the fourth summary written by Brett Cannon (with a partially
fried brain thanks to the GRE).
All summaries are now archived at http://www.python.org/dev/summary/
thanks to A.M. Kuchling.
Please note that this summary is written using reStructuredText_ which
can be found at http://docutils.sourceforge.net/rst.html . Any
unfamiliar punctuation is probably markup for reST_; you can safely
ignore it (although I suggest learning reST; its nice and is accepted
for PEP markup). Also, because of the wonders of reformatting thanks
to whatever program you are using to read this, I cannot guarantee you
will be able to run this text through Docutils_ as-is. If you want to
do that, get the original text version.
.. _python-dev mailing list:
http://mail.python.org/mailman/listinfo/python-dev
.. _Docutils:
.. _reST:
.. _reStructuredText: http://docutils.sf.net/
======================
Summary Announcements
======================
This is a new section to the summary that I have decided to introduce.
It is mainly going to serve to make any general announcements or
comments on this summary and this summary alone. All universal
comments will stay at the top of the summaries.
Just to let everyone know, I am taking off for two weeks on vacation
starting 2002-10-14 and I will not return until 2002-10-30. Now,
before you all start sobbing over the loss of one of my great
summaries, you should know that Raymond Hettinger has graciously taken
up the job of temp summarizer for me and will do the summary while I
am gone.
Michael Hudson has made the suggestion that I inject more of my
personality into the summary so as to liven it up a little. I am
personally quite happy to do this. But the real question is do you,
fine reader, mind the idea? If I don't hear from throngs of people
going "your sarcastic tone takes away from the wonderfully drawl
summaries and that is a bad thing", then I will just go ahead and
write with personality. Just don't complain later. =)
2.2.2b1 has been occupying Python-dev during this summary period, and
so this summary is shorter than usual. I left out a bunch of threads
that were discussing bugfixes that I either didn't find interesting or
didn't think the rest of the world would care about.
A.M. Kuchling has put all Python-dev summaries up at
http://www.python.org/dev/summary/ . So now the archive is
centralized instead of spread out among three web sites. I am sure
the original archive sites will stay (I will keep mine up), but all
future references will go to that page.
Now it's time for my personal favor of the month. I am going to start
applying to grad school for computer (science | programming) when I
get back from vacation. If anyone knows of Python-friendly schools
out there, let me know. Heck, I am even willing to leave America to
go to school as long as the classes are in English. So if you know of
any, please let me know!
And now on to the summary.
=========================================
`Python 2.2.2 beta release on Monday!`__
=========================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029204.html
splinter thread:
- `RELEASED: Python 2.2.2b1`__
__ http://mail.python.org/pipermail/python-dev/2002-October/029337.html
Python 2.2.2.b1 was released on Monday, October 7. This is the reason
(or perhaps excuse is a better description) for the lighter summary
this week. A good amount of the traffic on Python-dev was about
bugfixing 2.2.2.b1. Most of this probably would not interest the
average Python user, and thus I didn't summarize a bunch of threads.
Taking the GRE also didn't help with my free time and thus has caused
me to cut down on the summary since I am having to go through a huge
backlog to get this out the door.
=========================================
`Dropping support for Tcl 8.0 and 8.1`__
=========================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029024.html
Martin v. Loewis asked if it would be okay to drop support for Tcl_
8.0 and 8.1 since `_tkinter.c`_ has special code in there just for
those outdated versions. Guido ok'ed it, so if you are using those
still using a version of Tk from way back when, it's time to upgrade.
.. _Tcl: http://www.tcl.tk/
.. __tkinter.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul…
===========================================
`*very* revised proposal for interfaces`__
===========================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029042.html
Previously John Williams came up with a proprosal for implementing the
stuff from `PEP 245`_ (Python Interface Syntax) and `PEP 246`_ (Object
Adaptation). From my understanding of what John has done, it appears
he has written an interface system in pure Python. If you want
backstory to this long and involved discussion to get an interface
system into Python read the Python-dev Summaries for 2002-08-16 to
2002-09-01 and 2002-09-01 to 2002-09-15 .
Gerald Williams, Michael Chermside, and Esteban Castro all commented
on the implementation and made various suggestions.
John said that he was not done yet implementing this. But if you were
interested in the whole previous discussion on interfaces you could
consider looking at what John has done. As for it going into the
language, I suspect that will have to wait until John is done and has
convinced the PEP writers and Python-dev that his implementation fits
the bill. Stay tuned.
If you want some more background info on interfaces, read the
previously mentioned summaries. As for object adaptation, read on
c.l.py and on Python-dev anything by Alex Martelli on the subject. He
has become the main proponent of object adaptation and has written
several very extensive essays on the subject.
.. _PEP 245: http://www.python.org/peps/pep-0245.html
.. _PEP 246: http://www.python.org/peps/pep-0246.html
=====================
`perplexed by mro`__
=====================
__ http://mail.python.org/pipermail/python-dev/2002-October/029035.html
Splinter threads:
- `Re: my proposals about mros (was: perplexed by mro)`__
- `C3 implementation`__
__ http://mail.python.org/pipermail/python-dev/2002-October/029167.html
__ http://mail.python.org/pipermail/python-dev/2002-October/029230.html
Samuele Pedroni said he was "trying to wrap [his] head around the mro
computation in 2.2". Apparently there is the algorithm mentioned at
http://www.python.org/2.2.1/descrintro.html (dubbed the naive
algorithm) and then the one implemented in `typeobject.c`_ (called the
2.2 algorithm). Samuele discovered some inconsistencies with the
implemented algorithm that he desired some explanation about.
Guido responded, thankful that someone was giving this a look because
his "intuition about the equivalence between algorithms turned out to
be wrong". Guido stated that he thought that he wrote the algorithm
from the book "Putting Metaclasses To Work" correctly sans raising an
error when major conflicts occur in the ordering. In a later email
Guido explained that the naive algorithm came about by his attempt to
simplify the explanation of the 2.2 algorithm. Guido pretty much
wrote the algorithm from the aforementioned book. Now the algorithm
is not simple, so Guido did his best to simplify the explanation.
Unknowningly, though, he came up with a variant on the algorithm in
his explanation.
Greg Ewing pointed out that he thought the naive algorithm was nicer
since it seemed to work more intuitively and was easier to explain
(and remember kids, these are basic tenants in Python programming).
Guido ended up stating that "If Samuele agrees that the naive
algorithm works better, [Guido will] try to make it so in 2.3". Well,
Samuele said that the "2.2 mro is the worst of our options".
There was a problem, though, with the naive algorithm; it is not
monotonic as pointed out by Samuele. This led him to put out two
options:
1. Use the naive algorithm, which had the drawback of not being
monotonic. Samuele also believed that it didn't produce "the most
natural results".
2. Adopt C3_ as described at
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html and
apparently used by Goo_ . This algorithm is monotonic and Samuele
says is more intuitive in its results.
Guido got around to reading the C3_ paper and agreed that "we should
adopt C3". He thought that the 2.2 algorithm was like the L*[LOOPS]
algorithm mentioned in the paper, but he is not positive. Samuele
then wrote a C implementation of the algorithm. Guido said he would
get to the patch after 2.2.2b1 got out the door.
.. _C3: http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
.. _Goo: http://www.ai.mit.edu/~jrb/goo/manual.43/goomanual_55.html
.. _typeobject.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objec…
===============================
`Psyco requests and patches`__
===============================
__ http://mail.python.org/pipermail/python-dev/2002-October/029038.html
Armin Rigo of psyco_ an email to Python-dev with some thoughts on
psyco and some requests. After mentioning how he wished more people
realized psyco is meant to be used by anyone and not speed-hungry
coders (it is a cool app and if you have any interest in compilers you
should take a look) and that psyco could get some more advertising he
mentioned three patches that he wrote (patches 617309_ , 617311_ , and
617312_ ) against 2.2.2 that he would like to see be accepted so as to
ease maintenance of psyco.
Armin also mentioned how he would like to move psyco forward. He
pointed out he would like to eventually write it all in Python. This
would require tracking changes in the interpreter that psyco dealt
with. He would like to keep this in mind when Python 3 discussions
kick up (and don't ask when that will happen; not for a VERY long
time).
In regards to Armin's patches, Martin v. Loewis thought they broke
binary compatibility (big no-no between micro releases), but Armin
claimed it didn't.
After glancing over the patches it seems they have all been applied
against 2.2.2 and are being actively worked on by Armin for
application to 2.3.
.. _617309: http://www.python.org/sf/617309
.. _617311: http://www.python.org/sf/617311
.. _617312: http://www.python.org/sf/617312
.. _psyco: http://psyco.sf.net/
======================================================================
`PEP239 (Rational Numbers) Reference Implementation and new issues`__
======================================================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029065.html
splinter threads:
- `Re: PEP239 (Rational Numbers) Reference Implementation and new
issues`__
__ http://mail.python.org/pipermail/python-dev/2002-October/029068.html
Christopher Craig uploaded `patch 617779`_ that implemented `PEP 239`_
(Rational Numbers). He had some questions for Python-dev, though,
regarding a couple points. These few points have become the bane of
my summarizing existence; this thread is huge.
One was whether division should return rationals instead of floats.
Since rationals keep precision in division they are the most accurate
way to perform division. THey also make the most output sense (e.g.
1/3). Problem with this is that rational math is slow and this would
cause issue with any code that expected a float.
The next issue was about comparison. Should a rational compare only
when it is exactly equal to a float or when the float is really close?
Lastly, Christopher wondered if rationals should hash the same as
floats. The answer to the second issue would influence the answer to
this issue.
Issue 1. Eric Raymond was for returning a rational. Francois was kind
of on the fence. Christian was +1 for returning rationals. Guido
said ABC did this and that numeric processes thus ended up being slow.
Issue 2. Christian said "Let it grow! Let the user feel what
precision he's carrying around, and how much they throw away when they
reduce down to a float."
Issue 3. Eric Raymond suggested a global "fuzz" variable that defines
a "close-enough-for-equality range"; this idea was used by APL.
Andrew Koenig was against this because you don't always want a fuzzy
comparison and it destroys substitutability: "If a==b, it is not
always true that f(a)==f(b)". Andrew said he preferred Scheme's
numeric model. To this, Guido said that "'It works in Scheme' doesn't
give me a warm fuzzy feeling that it's been tried in real life"; Tim
later laid the smack down on Scheme's numeric model and ended it with
"There's a reason the NumPy folks never bug you for Scheme features
<wink>". Christian pointed out that keeping it as a rat would prevent
overflows from ever occuring from long division. Tim was staunchly
against a fuzz variable. Raymond suggested a fuzz comparison function
that took in a fuzz value. Christopher said that the way it stands
now in the implementation is that rationals are coerced to floats and
then compared. Oren Tirosh suggested a thired boolean,
'Undetermined', that would be raised when the "difference between A
and B is below the error margin". David Abrahams said that Boost
discussed this and said that the cost of adding ternary logic was not
worth it.
Andrew asked how rats could be optimized. He suggested ditching
trailing zeros. Tim wondered how much of a save you would get from
this. Raymond Hettinger suggested having a builtin variable that
would specify the "maximum denominator magnitude". Christian liked
this idea. Greg didn't think this would be a good solution because
people using rats are going to want them specifically because they are
exact. So Raymond suggest the default be unrestricted denominator.
Guido brought up the question of how rats should be represented when
printed.
The syntax for rats came up. Greg Ewing got the ball rolling by
suggesting the syntax for rat division as ``\\\``. M.A. Lemburg
suggested just having a constructor like ``rat(2,3)``. The discussion
then had a gamut of suggested syntax: ``2:3``, ``2r3``, ``{2/3}``
(Guido shot this down because he wants to leave the option open for
possible set notation), ``<2/3>``,``2r/3``, something by Barry using
an extended character that Pine wouldn't display (it was a joke), and
finally ``2/3r`` by Guido. People agreed that this last one suggested
by Guido was the best one. Tim also pointed out that Scheme has
notation to specify whether a number is exact or not and using the 'r'
notation would basically provide the same functionality.
But regardless of what syntax people preferred, it was overwhelmingly
agreed that choosing the syntax should wait until rationals have been
in the language for a while and it is known how they are used.
If you only read one thing, read Tim's emails since he explains all of
this really well and is the resident math whiz on Python-dev.
.. _patch 617779: http://www.python.org/sf/617779
.. _PEP 239: http://www.python.org/peps/pep-0239.html
==================================================
`Non-ASCII characters in test_pep277.py in 2.3`__
==================================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029247.html
Guido pointed out that test_pep277.py_ uses an encoding cookie which
was not being recognized by his toolchain. At some point he stated
that he is "still not 100% comfortable with using arbitrary coding
cookies in the Python distribution".
The reason I mention this thread (beyond for the quote above) is that
info on how to get XEmacs to recognize the cookie came out. Sjoerd
Mullender sent out the link
http://www.xemacs.org/Documentation/packages/html/mule-ucs_2.html
which helped some people. As for Linux distro-specific problems, M.A.
Lemburg noticed that SuSE puts Mule support in a package named
'mule-ucs-xemacs' and once he got the package loaded XEmacs worked.
.. _test_pep277.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/t…
======================================================
`Unclear on the way forward with unsigned integers`__
======================================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029249.html
Splinter threads:
- `PEP 263 in the works`__
__ http://mail.python.org/pipermail/python-dev/2002-October/029289.html
Mark Hammond was "a little confused by the new world order for working
with integers in extension modules". Mark wanted know how to create
objects that were more like a collection of bits than an integer. Tim
suggested creating a Python long; that would act more like an unsigned
int in terms of its bits.
The FutureWarning for hexadecimal constants was brought up and it was
pointed out that to deal with those just stick an 'L' at the end.
Remember folks, that in Python 2.3 ``0x80000000L == 2147483648``.
The usefulness of __future__ statements also came up. Tim wondered
how useful they were. Thomas Wouters, though, came to __future__'s
defense and explained how it helped him migrate people to newer
versions of Python without being yelled at for breaking their code.
=================================================
`segmentation fault with python2.3a0 from cvs`__
=================================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029286.html
Gersen Kurz was having problems importing a huge file. The bug was
attributed to cygwin's malloc implementation, so people might want to
watch out for that.
It was also pointed out that a loop with a bunch of items in a dict
created a huge number of references. It turns out that dicts use
dummy references in its implementation for when something is deleted.
So don't be alarmed by huge references even after you deleting an
immense dict.
==========================================
`Snapshot win32all builds of interest?`__
==========================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029352.html
As mentioned in the last summary, Mark Hammond wondered if anyone
would care to have access to compiled snapshots of CVS for Windows.
He got enough of a response to give access at
http://starship.python.net/crew/mhammond . This is not like the
standard Windows installer, though; "This version installs no
shortcuts, does not compile .pyc files etc - you are pretty much on
your own. Pythonwin\start_pythonwin.pyw is installed to start
Pythonwin, but you must do so manually". Mark would like to know if
you end up using this.
===========================================
`Set-next-statement in Python debuggers`__
===========================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029377.html
Richie Hindle wants to write a pure Python debugger; the problem is
that it would be difficult without certain C-level stuff exposed to
Python. Specifically, he wants frame.f_lasti (to be found in
frameobject.c_ ) to be writable by Python so he "could implement
Set-Next-Statement".
Michael Hudson is the first email I have of someone chiming against
this. He thought it would be better to make it a descriptor so as
that "you can do some sanity checking on the values". Guido then
chimed in saying that if it was writable that would open up a hole for
crashing a program. Guido eventually said making it read-only would
be fine.
This led to Armin Rigo pointing out that you can crash the interpreter
already with the new module "or by writing crappy .pyc files". Guido
acknowledged this, but said he didn't want to add anymore if it could
be helped. He pointed out that he wants to stick with the idea that a
segfault is Python's fault unless proven otherwise.
.. _frameobject.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objec…
=====================
`Multibyte repr()`__
=====================
__ http://mail.python.org/pipermail/python-dev/2002-October/029442.html
A patch was applied that allowed repr() to return characters with the
high bit set; repr() used the "multibyte C library for printing string
if available". This had caused a bug and made Guido wonder if this
was a good thing to do. For an example::
>>> u = u'\u1f40' # Python 2.2
>>> s = u.encode('utf8')
>>> s
'\xe1\xbd\x80'
>>>
>>> u = u'\u1f40'
>>> s = u.encode('utf8')
>>> s
'1⁄2\x80' # Notice the extended character
>>>
"The latter output is not helpful, because the encoding of s is not
the locale's encoding".
Martin v. Loewis said that he thought author of the patch's intention
was "to get 'proper' output in interactive mode for strings". Part of
the issue with all of this is the GNU readline calls setlocale()
automatically. A patch came about to reset it in the extension module
back to its original state.
The issue of whether pickling would break because of this. Guido
tried it and had no issue. Atsuo Ishimoto (who brought up the
possible problem) said it broke when using the ShiftJIS locale.
But the worry of having repr() be locale-specific still lingered.
Martin said he was "convinced that having repr locale-specific is
unacceptable". He said, though, that having the tp_print slot use a
locale-aware print function was fine and to have it differ from
tp_repr was fine. But this was shot down by Guido; "tp_print only
gets invoked when sys.stdout is a real file; otherwise str() or repr()
get invoked". Apparently tp_print is a performance optimization and
thus should be fully transparent and not be different in any way to
the user.
Guido said that the multibyte-string patch should be backed out. With
the pickle issue and different semantics for sys.stdout because of
tp_print, Guido said the patch had to be backed out.
As Tamito Kajiyama said, "one of the virtues of Python is that Python
has no language feature that is (automagically) affected by locale
settings".
=======================================
`tp_dictoffset calculation in 2.2.2`__
=======================================
__ http://mail.python.org/pipermail/python-dev/2002-October/029502.html
Guido asked David Abrahams and Kevin Jacobs if a change in how
tp_dictoffset (found in `typeobject.c`_ ) was calculated would affect
them. To give some background, tp_dictoffset "tells us where the
instance dict pointer is in the instance object layout". This was a
three step process (all Guido's words):
1. (Line 1113) For dynamically created types (i.e. created by class
statements), if the new type has no __slots__, the dominant base class
has a zero tp_dictoffset, and the dominant base doesn't have a custom
tp_getattro, a __dict__ will be added to the instance layout, and its
tp_dictoffset is calculated by taking the end of the base class
instance struct (or in a more complicated way if tp_itemsize is
nonzero).
2. (Line 1941) If the dominant base has a nonzero tp_dictoffset, copy
the tp_dictoffset from the dominant base.
3. (Line 2090) The tp_dictoffset of the first non-dominant base class
that has a nonzero tp_dictoffset is copied.
That last rule had caused Guido and Jeremey Hylton some problems with
some code they were bugfixing. Guido wanted to just get rid of that
rule since he though "it is *always* wrong". Both David and Kevin
said that nothing broke for them, so that is now all straightened out.
==========================
`Memory size overflows`__
==========================
__ http://mail.python.org/pipermail/python-dev/2002-October/029535.html
Armin Rigo pointed out some potential overflow errors "with objects of
very large sizes". The issue was when the amount of memory needed to
allocate was calculated there was the chance that it would overflow.
Armin suggested adding macros to deal with various issues.
Arrive Tim Peters, creator of pymalloc. He admitted that he "always
ignore[s] these [errors] until one pops up in real life" since
"Checking slows the code, and that causes [Tim] pain <0.5 wink>". He
pointed out another possible overflow calculation problem. But it was
a basically a hopeless battle since malloc() has its own
cross-platform issues.
But Tim did say that if it was decided to go down the macro route,
then he wanted something like what Zope does:
``DO_SOMETHING_OR(RESULT_LVALUE, INPUT1, ..., ON_ERROR_BLOCK);``. The
result goes into RESULT_LVALUE unless there is a problem, in which
case ON_ERROR_BLOCK is run.
Christian Tismer chimed in and said that he thought we should just
move completely over to 64 bit math. Ruby had done it successfully so
it wasn't like we were taking a blind leap. It would also save us the
hassle from doing it down the road when 64 bit processors become the
norm instead of the exception.
