"'%s' % unicode_string" produces a unicode result.  I
think the following code should also return a unicode
string:

class Wrapper:
....def __str__(self):
........return unicode_string
'%s' % Wrapper()

That behavior would make it easier to write library
code that can work with either str objects or unicode
objects.

The fix is pretty simple (see that attached patch). 
Perhaps the PyObject_Text function should be called
_PyObject_Text instead.  Alternatively, if the function
is make public then we should document it and perhaps
also provide a builtin function called 'text' that uses it.

Logged In: YES 
user_id=38388

Nice patch. 

Only nit: PyObject_Text() should check that the result of
tp_str() is indeed either a string or unicode instance
(possibly from a subclass). Otherwise, the function wouldn't
be able to guarantee this feature - which is what it's all
about.

Logged In: YES 
user_id=35752

Attaching a better patch.  Add a builtin function called
"text".  Change PyObject_Text to check the return types as
suggested by Mark.  Update the documentation and the tests.

Logged In: YES 
user_id=35752

attempt to attach patch again

Logged In: YES 
user_id=35752

Assigning to effbot for review.  He had mentioned something
about __text__ at one point.

Logged In: YES 
user_id=38388

Looks OK to me; not sure what you mean with __text__ -
__str__ already has taken that role long ago.

Logged In: YES 
user_id=35752

Here's a quote from him:
> I'm beginning to think that we need an extra method
(__text__), that
> can return any kind of string that's compatible with
Python's text model.
>
> (in today's CPython, that's an 8-bit string with ASCII
only, or a Uni-
> code string.  future Python's may support more string
types, at least at
> the C implementation level).
>
> I'm not sure we can change __str__ or __unicode__ without
breaking
> code in really obscure ways (but I'd be happy to be proven
wrong).

My idea is that we can change __str__ without breaking code.
 The reason is that no one should be calling tp_str
directly.  Instead they use PyObject_Str.

I don't know what he meant by "string that's compatible with
Python's text model".  With my change, Python can only deal
with str or unicode instances.  I have no idea how we could
support other string implementations.

I don't want to introduce a text() builtin that calls
__str__ and then later realize that __text__ would be a
useful.  Perhaps this change is big enough to require a PEP.

Logged In: YES 
user_id=35752

Closing in favor of patch 1266570.

inspect.getsource in CVS and coming python2.4.1 failed when 
functions, etc., had a comments after the colon, and some other 
cases. Look at bug #1143895 for more.

This patch fixes this problem.

Logged In: YES 
user_id=329382

... It fixes the comment thing, all tests pass, but it's easy to construct 
failing cases.

Logged In: YES 
user_id=329382

Which inspect.py rev should the patch be made against? Python 2.4.0, 
Python 2.4 maint or Python CVS?

Logged In: YES 
user_id=469548

Python 2.4 maint is most important right now. I suspect it
would apply to the trunk cleanly as well.

Logged In: YES 
user_id=329382

The patch together with Armin's new tests seems ready to be checked 
in (of course, that's really not my call). If possible, of course do it before 
the 2.4.1 freeze in 5 hours.

Logged In: YES 
user_id=469548

I believe this could still go in between 2.4.1rc1 and 2.4.1
final, and I'm going to sleep after this message, so it'll
have to. ;)

Sorry for being anal-retentive, but what do you mean by
"it's easy to construct failing cases"? Do you believe
there's any regressions from 2.4.0? Or is it just that
inspect.getsource() isn't perfect and won't be either? If
the latter, I agree that it should be checked in.

Thanks for responding so quickly, by the way.

Logged In: YES 
user_id=329382

The comment was actually for the first patch I submitted here to fix the 
bugs. Then I realized the approach was stupid and made a new patch.

Logged In: YES 
user_id=29957

This needs a new testcase to exercise the failing behaviour.

Logged In: YES 
user_id=469548

Testcase patch is in bug #1143895. (glad I could reach you,
by the way)

Logged In: YES 
user_id=469548

Checked in on maint24 and HEAD.

Logged In: YES 
user_id=4771

2.4.1c2 is due in one week, this should go in I guess.  As far as I can see, the status is:

For CVS HEAD, the test patch attached with bug #1143895 applies cleanly.  The patch attached here applies ok (with an offset of one line) and fixes the new test cases just fine.

For 2.4 CVS, the test patch doesn't apply at all (test_inspect.py was reorganized in 2.5).  I attach a smaller test patch for 2.4 below.  The inspect.py patch applies cleanly and fixes this new test.

This should go in before 2.4.1c2 (planned in one week)...

Logged In: YES 
user_id=469548

Teehee. Well, I've now also checked in your test patch for 2.4.

Logged In: YES 
user_id=4771

Sorry, we must have written our comment at the same time.  I didn´t see 
yours before I posted mine, and I didn´t intend to reopen the tracker.

Ensure that the zlib project builds with the
"ReleaseItanium" configuration when for the
"ReleaseItanium" *solution* configuration.

Logged In: YES 
user_id=21627

Last I tried, zlib doesn't work on Itanium. Does it now?

Logged In: YES 
user_id=34892

I've been working through a compile for Win64 on a Win32 box
(using the platform SDK compiler). Here is the result of
test_zlib.py on Win64:

C:\trentm\tmp\py2_4-win64-ia64\python>PCbuild\python.exe
Lib\test\test_zlib.py
test_adler32empty (__main__.ChecksumTestCase) ... ok
test_adler32start (__main__.ChecksumTestCase) ... ok
test_crc32empty (__main__.ChecksumTestCase) ... ok
test_crc32start (__main__.ChecksumTestCase) ... ok
test_penguins (__main__.ChecksumTestCase) ... ok
test_badcompressobj (__main__.ExceptionTestCase) ... ok
test_baddecompressobj (__main__.ExceptionTestCase) ... ok
test_bigbits (__main__.ExceptionTestCase) ... ok
test_speech (__main__.CompressTestCase) ... ok
test_speech128 (__main__.CompressTestCase) ... ok
test_compressincremental (__main__.CompressObjectTestCase)
... ok
test_compressoptions (__main__.CompressObjectTestCase) ... ok
test_decompimax (__main__.CompressObjectTestCase) ... ok
test_decompinc (__main__.CompressObjectTestCase) ... ok
test_decompincflush (__main__.CompressObjectTestCase) ... ok
test_decompressmaxlen (__main__.CompressObjectTestCase) ... ok
test_decompressmaxlenflush (__main__.CompressObjectTestCase)
... ok
test_flushes (__main__.CompressObjectTestCase) ... ok
test_maxlenmisc (__main__.CompressObjectTestCase) ... ok
test_odd_flush (__main__.CompressObjectTestCase) ... ok
test_pair (__main__.CompressObjectTestCase) ... ok

----------------------------------------------------------------------
Ran 21 tests in 1.051s

OK

Logged In: YES 
user_id=34892

Martin,
I'm also curious how you've been compiling the ia64 Python
build that you put together. Do you use the Platform SDK and
cross-compile from Win32? Are you building in Visual Studio
or from the command-line? Etc.

Cheers,
Trent

Logged In: YES 
user_id=21627

See PCbuild/readme.txt. I use the SDK compiler for
cross-compilation, and vsextcomp.

Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

pcbuild.sln 1.6, 1.5.2.1
readme.txt 1.63
NEWS 1.1193.2.84

The pre-link event doesn't work doesn't work for me, so I
have to build zlib manually (with nmake) first before being
able to build zlib.pyd.

Skip the winsound project for "ReleaseItanium"
configuration builds on Windows. The current winsound.c
cannot build for Window/IA64 because the used _outp()
and _inp() port I/O routines in conio.h (at least the
one that is part of the current MS Platform SDK) are
hidden inside:

#ifdef  _M_IX86
...
#endif  /* _M_IX86 */

See:
C:\Program Files\Microsoft SDK\include\Win64\crt\conio.h

Logged In: YES 
user_id=21627

I'm rejecting this patch. The right solution is to
conditionalize the entire W9X block in winsound.c to _M_IX86.

When decorating a function without changing the signature, it 
is generally appropriate to preserve the metadata from original 
function. 
 
This currently involves copying the docstring and name and 
updating the function attribute dict manually. 
 
This patch adds an "update_meta" method to function objects 
which modifies the current function to masquerade as the 
original function. 
 
Test & documentation patches still to come. (Although the 
docstring text could also be used for the documentation) 
 

Logged In: YES 
user_id=99874

Nice... thanks. But I have to ask: is this really the right
set of metadata to be updating? Here are a few things that
perhaps ought be copied by update_meta:

    f.__name__     (already included)
    f.__doc__      (already included)
    f.__dict__     (already included)
    f.__module__   (probably should include)
    f.func_code.co_filename     (to match f.__name__, but
I'd leave it alone)

there's also the annoying fact that in IDLE (and in some
other python-aware
IDEs) one can see the argument signature for a function as a
"tool tip"
or other hint. Very handy that, but if a decorator is
applied then all
you will see is "func(*args, **kwargs)" which is less than
helpful. I'm
not sure whether this CAN be duplicated... I believe it is
generated by
examining the following:

    f.func_code.co_argcount
    f.func_code.co_varnames
    f.func_code.co_flags & 0x4
    f.func_code.co_flags & 0x8

...and I suspect (experimentation seems to confirm this)
that if you mangle
these then the code object won't work correctly. If anyone's
got a
suggestion for fixing this, I'd love to hear it.

Logged In: YES 
user_id=384806

If self and argument are swapped, making update_meta a
method on the source of information instead of the target,
then the bound method will be usable as a decorator. See
"Decorator decorator" in
http://www.python.org/moin/PythonDecoratorLibrary for the
same idea as a free function.

Logged In: YES 
user_id=1038590

It's an interesting idea, but I'm extremely uncomfortable
with the idea of a method that mutates the argument instance
passed in rather than the instance that owns the method.

Instead, I'd prefer to keep the current signature, and view
func.update_metadata() as infrastructure that things like
@simple_decorator and @decorating can build on top of. So
long as the method is kept in sync with additions to the set
of metadata, those two decorators would then be kept in sync
for free (which is the whole point).

Logged In: YES 
user_id=384806

Taken as behind-the-scenes infrastructure, not intended to
be used
directly, why not a pure-Python standalone function instead, for
easier maintenance? Also, that would avoid discriminating
against non-function callables. Although you can't use
decorator syntax with non-function callables, the decorator
functions themselves need not have that limitation.

The case for decorator-style: 1) When used as a decorator
there is no risk of getting the argument order wrong, even
if it does
change the argument.  2) It plays better with the open-closed
principle, allowing decoratees to provide custom meta-updaters.

Of course "update" in the name would be misleading, better
(supply|imbue|impress)_meta.

Logged In: YES 
user_id=1038590

We're not going to do it this way - most likely will be a
standard decorator for creating well-behaved decorators.

I'm not sure this is the correct place to do this, but I found the need 
for a python-config (similar to sdl-config, etc.) when building an 
C++ application that embeds python.

It accepts two arguments --cflags and --static-libs:

# ./python-config --cflags --static-libs 
-I/usr/include/python2.4
/usr/lib/python2.4/config/libpython2.4.a

I guess it could be expanded to do more, but it was all I needed.

Logged In: YES 
user_id=21627

This is the right place if you want this to be included in
the standard Python distribution. If you just want to share
it with others, the Python cookbook is a better place:

http://aspn.activestate.com/ASPN/Python/Cookbook/

In the current form, this is not acceptable, as it is
incomplete (e.g. there is no integration into the Python
build process, and we need to know what specific options are
expected from a *-config program, and implement them). Are
you willing to complete this?

Logged In: YES 
user_id=195710

Ok. I'll make an attempt. What do you mean by "what 
specific options are expected from a *-config program" 
?

Logged In: YES 
user_id=21627

It appears that the *-config programs (e.g. gtk-config, ...)
share command line options; this seems to be part of the
"pkg-config" system. I think we need to understand what
precisely the standard for these utilities is, and conform
to it.

Logged In: YES 
user_id=488897

Three comments:

1) When running this script, I got the following error on
Unix and Cygwin:

$ python-config.php --cflags --static-libs
-I/usr/local/include/python2.4
Traceback (most recent call last):
  File "<string>", line 1, in ?
AttributeError: 'module' object has no attribute 'lib'

2) Since we are Pythoneers, why write this script as a
shell-script instead of a Python script? (sh may not even be
available on Windows).

3) Isn't it easier / more reliable to get this information
via distutils? See section 5.6 of "Extending and Embedding
the Python Interpreter".

Logged In: YES 
user_id=195710

1. php? Anyway, I see that the 'lib' attribute actually isn't an official one. Bad 
call from my part.
2. Yes, I'm ashamed to have commited such atrocities. :-)
3. Ah, I see. Didn't know about that one.

That said, as loewis stated previously this script should probably follow the 
pkg-config standard anyhow. I haven't gotten around to do anything further in 
this matter, unfortunately.

Logged In: YES 
user_id=849994

Uploading a python-only version. This should conform more
with pkg-config, though every *-config program on my box has
other options.

Logged In: YES 
user_id=195710

Excellent work! Looks nice.

Logged In: YES 
user_id=21627

I took gbrandl's python-config, added a build process, and
committed this patch as #45417. Thanks to all contributors!

Patch to configure.in to fix problem described in:

http://sourceforge.net/tracker/?func=detail&aid=1162001&group_id=5470&atid=105470

Logged In: YES 
user_id=21627

This test is too weak. If CC is, say, "/opt/intel/bin/icc",
the test would fail, right?

So please come up with a separate test to determine if the
compiler is icc, and then skip the entire test whether it
accepts -OPT:Olimit.

Logged In: YES 
user_id=987664

OK, here's another attempt at it that uses the autoconf
AS_BASENAME macro. Additionally it removes libm from the
default libraries if you are using icc. Intel has their own
math library which is automatically linked, and using -lm
causes problems.

Sorry this took so long--anonymous CVS access had been down
for several days.

Logged In: YES 
user_id=21627

Hmm. I would really like to see something still more
general, but am willing to commit this if you assert that
nothing more general exists.

Eg. what if somebody links /usr/bin/cc to icc? You really
should find out whether the compiler *is* ICC, not whether
its name is icc (or, better yet, whether the compiler really
does support -OPT:Olimit). For example, if 'icc --version'
prints "Intel Compiler version 9.0" or some such, that would
be a reliable test for icc.

Logged In: YES 
user_id=987664

Well, it probably can be done but that would really require
a completely different patch. I unfortunately have not had
the time to produce such a patch.

Logged In: YES 
user_id=21627

Ok, something like this was committed as 41953; closing this
patch as out-of-date.