I discovered that when compiling for readline against a Fink install a
warning was spit out about the lack of a function definition. Turned
out a function that #ifdef'ed a macro was not being triggered because
configure.in was not catching the header file in /sw/lib for readline.
Since /sw is already looked at by setup.py, is there any way to have
configure.in do it as well so as to have some consistency? Or is
prepending ``LDFLAGS=/sw/lib`` the only way? If so, does it warrant
mentioning in the README?
On Sat, 17 Jul 2004 22:06:33 -0700, tim_one(a)users.sourceforge.net
> Update of /cvsroot/python/python/dist/src/PC
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23589/PC
> Modified Files:
> Log Message:
> Woo hoo! All the encoding tests pass on Windows (& I downloaded the
> 14 input files needed to run all of them).
Thanks for fixing cjkcodecs to build in Windows again. I'll rearrange
cjkcodecs.h to get rid of the problem you described, soon. :)
Can we get rid of Lib/FCNTL.py for 2.4? AFAICT, its existence does nothing
but create obscure problems for Windows users. For an old example, in
import fcntl as _fcntl
# If PYTHONCASEOK is set on Windows, stinking FCNTL.py gets
# imported, and we don't get an ImportError then. Provoke
# an AttributeError instead in that case.
except (ImportError, AttributeError):
For an example from yesterday:
I don't know all the ways this happens, but a surprising number of Windows
users end up with a file named:
in their Lib directories, and then tons of things break, because imports of
fcntl pick that up instead of getting the ImportError cross-platform code
expects on Windows.
I know that one persistent user traced this to one of the Python-aware
installer-builders creating allupper.pyc files from ALLUPPER.py files on
Windows, but it's not worth the effort of tracking this down: since the day
it was introduced, FCNTL.py has generated a deprecation warning telling you
to use fcntl instead. The builtin fcntl was introduced in 1.5a3. Enough
Michael Walter wrote:
> I was under the impression that nmake worked with .sln or .vcproj files.
> On Sat, 17 Jul 2004 21:59:35 +1000, Nick Coghlan <ncoghlan(a)iinet.net.au> wrote:
>>I'm probably missing something obvious, but what can I use to interpret
>>the vcproj build files?
That something obvious I mentioned? The main problem I had was that
nmake isn't in the free VC Toolkit.
It eventually occured to me that it isn't in the VC toolkit because its
already in some of the other free downloads from MS. . .
Thanks, anyway :)
Nick Coghlan | Brisbane, Australia
Email: ncoghlan(a)email.com | Mobile: +61 409 573 268
On WinXP, it segfaults instantly, while trying to import site.py. I'm able
to get into the interpreter by passing -S (skips importing site.py). Any
attempt to run the test suite also segfaults instantly, even with -S.
My name is Mike Mangino. I am an IT weenie in Chicago Illinois, USA who
has used python in various projects for several years. I have recently
finished school (again) and am looking for a project I can work on to
learn. My huge ambition is to eventually port python to the palm pilot
with a reasonable graphical interface. I have learned my lesson in the
past about jumping into ambitious projects too quickly. As such, I am
interested fixing and triaging bugs in the sourceforge tracker.
Earlier today I added a comment to http://www.python.org/sf/982679 to
tell the user how to fix the problem they were having (it was a bug in
their code, not python) How do I have somebody close that request? In
the future, if I fix one of the issues, is there somebody I should email
to make changes?
I look forward to helping out in whatever way I can. I have experience
in C, Java, databases and many other languages in addition to an MBA
with focus on Finance. My guess is that the C will be most helpful, but
who knows. If you want to discuss asset pricing, I can probably help
with that as well.
If anyone is in the Chicago area, I would love to buy you a beer and
pick your brain.
Is it true that 'as' is going to become a keyword in future? I ask,
because I was thinking about implementing an 'as' function, such that:
will work for Python 2.2 and up.
Actually, I've already written and tested the function itself, it's just
that I would like to be sure that I shouldn't try to come up with another
I'm planning to check in some changes to the logging package. I'd appreciate
comments on the following:
1. A backwards-compatible change to basicConfig(), making simple
configuration of logging easier than before. For example, to change the
level of the root logger to DEBUG:
For example, to change the message format:
logging.basicConfig(format="%(asctime)s %(levelname)-5s %(message)s")
To log to a file in append mode (for write mode, add a filemode="w"
To log to an existing stream:
s = open("/logs/myapp.log", "w")
2. Refactoring of RotatingFileHandler into BaseRotatingHandler and
RotatingFileHandler. The reason for this is the addition of a new class,
TimedRotatingFileHandler, which rotates files based on time-dependent
criteria. (See SF patch #921318 for more details).
3. Logger.log() changed to throw a TypeError if raiseExceptions is set and
the level passed in is not an integer.
If the changes seem generally acceptable, then I'll also add a section in
the docs which describes the above basic use cases under a "Basic use of the
logging package" section which appears earlier in the logging docs than it
does currently. Except for the documentation changes, I'm planning to commit
by 3 July.
> Update of /cvsroot/python/python/dist/src/Lib/distutils
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3551
> Modified Files:
> Log Message:
> The new distutils features justify a new version number, imo.
> If someone has other ideas for the numbering scheme, please change to
> something else (1.1.0 ?).
After I committed this, it ocurred to me: certainly 2.4.0 ?