[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Santiago Gala (sgala)
Date: 2007-02-25 12:17
Message:
Logged In: YES
user_id=178886
Originator: YES
Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk
Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:
$python -c "print repr('á %s')"
'\xc3\xa1 %s'
$ python -c "print repr('éi')"
'\xc3\xa9i'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1664966 ] crash in exec statement if uncode filename cannot be decoded
Bugs item #1664966, was opened at 2007-02-21 08:31 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) >Assigned to: Jeremy Hylton (jhylton) Summary: crash in exec statement if uncode filename cannot be decoded Initial Comment: In case the exec statement gets an open file with a unicode object in f->f_fp the return value of PyString_AsString is not checked for an error and therefore a NULL pointer is given to PyRun_File which then leads to a crash. in ceval.c: line 4171 ff FILE *fp = PyFile_AsFile(prog); char *name = PyString_AsString(PyFile_Name(prog)); PyCompilerFlags cf; cf.cf_flags = 0; if (PyEval_MergeCompilerFlags(&cf)) v = PyRun_FileFlags(fp, name, Py_file_input, globals, locals, &cf); else v = PyRun_File(fp, name, Py_file_input, globals, locals); Name is NULL after conversion. Patch would be: FILE *fp = PyFile_AsFile(prog); char *name = PyString_AsString(PyFile_Name(prog)); if(name == NULL) return -1; PyCompilerFlags cf; -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1664966 ] crash in exec statement if uncode filename cannot be decoded
Bugs item #1664966, was opened at 2007-02-21 08:31 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Jeremy Hylton (jhylton) Summary: crash in exec statement if uncode filename cannot be decoded Initial Comment: In case the exec statement gets an open file with a unicode object in f->f_fp the return value of PyString_AsString is not checked for an error and therefore a NULL pointer is given to PyRun_File which then leads to a crash. in ceval.c: line 4171 ff FILE *fp = PyFile_AsFile(prog); char *name = PyString_AsString(PyFile_Name(prog)); PyCompilerFlags cf; cf.cf_flags = 0; if (PyEval_MergeCompilerFlags(&cf)) v = PyRun_FileFlags(fp, name, Py_file_input, globals, locals, &cf); else v = PyRun_File(fp, name, Py_file_input, globals, locals); Name is NULL after conversion. Patch would be: FILE *fp = PyFile_AsFile(prog); char *name = PyString_AsString(PyFile_Name(prog)); if(name == NULL) return -1; PyCompilerFlags cf; -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 15:58 Message: Logged In: YES user_id=31392 Originator: NO Committed revision 53901. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Comment added) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Mattias Engdeg�rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 16:22
Message:
Logged In: YES
user_id=31392
Originator: NO
I guess I should get back to this bug report at least once a year. I'm
trying to understand how Scheme handles eval. If I look at R5RS or R6RS,
I see that the eval procedure takes an environment as an argument. The
procedures that create environment all seem to create variants of the
top-level environment (an empty environment, the interactive environment,
etc.). I don't see any way to create an environment that contains the
bindings visible in a particular region of code. Am I missing something?
--
Comment By: Mattias Engdeg�rd (yorick)
Date: 2006-04-03 17:36
Message:
Logged In: YES
user_id=432579
Lest my last comment be interpreted as overly arrogant,
please be assured that it was not meant as anything other
than an explanation of why I reported this as a bug in the
first place. I do understand that Python works the way it
does; I just want it to be even better. :-)
--
Comment By: Mattias Engdeg�rd (yorick)
Date: 2006-04-03 17:12
Message:
Logged In: YES
user_id=432579
>The source of the problem is that scoping decisions are made
>statically.
No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:
Q: In what environment is the eval() argument evaluated?
typically in one of three ways:
A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.
Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.
Observe that none of the answers depend on what the
expression looks like.
Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions
1) x
and
2) lambda: x
should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.
In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.
Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:
A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.
This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 15:44
Message:
Logged In: YES
user_id=31392
The source of the problem is that scoping decisions are made
statically. If a variable is determined
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Settings changed) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
>Assigned to: Jeremy Hylton (jhylton)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:53
Message:
Logged In: YES
user_id=22785
This could & probably should be fixed, at the cost of making
the core debugger support more complicated. The current
version of TurboGears has code that triggers the same bug.
That said, I don't have a patch to fix the core...
--
Comment By: applebucks (scott_marks)
Date: 2006-10-08 23:54
Message:
Logged In: YES
user_id=120857
I didn't say Python is lame. I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it. That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.
Not to mention it makes my debugging tough. :)
More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 16:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
--
Comment By: applebucks (scott_marks)
Date: 2006-10-04 02:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does. In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.
Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.
I hope for a more optimistic reply.
---
[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build
Bugs item #1668133, was opened at 2007-02-25 01:03 Message generated for change (Comment added) made by inow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: clemens fischer (inow) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build Initial Comment: 'uname -rms' FreeBSD 6.2-STABLE i386 'cc --version' cc (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. trying to build python-2.4.4 from ports/lang/python24, i get the following messages, where earlier versions have been compiled and installed w/o problems: "./configure" stage: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: see the Autoconf documentation configure: WARNING: ncurses.h: section "Present But Cannot Be Compiled" configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ncurses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for ncurses.h... yes the 'readline' extension builds fine, though: building 'readline' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so I also tried this command after noticing that freebsd needs some special define for wchars: $ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES' ===> Building for python24-2.4.4 case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 3) in /usr/local/include/db43 db.h: found (4, 4) in /usr/local/include/db44 db lib: using (4, 4) db-4.4 INFO: Can't locate Tcl/Tk libs and/or headers building 'nis' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat': /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by kuran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 13:21
Message:
Logged In: YES
user_id=366566
Originator: NO
Code coverage tools run afoul
--
Comment By: John Ehresman (jpe)
Date: 2006-10-30 11:53
Message:
Logged In: YES
user_id=22785
This could & probably should be fixed, at the cost of making
the core debugger support more complicated. The current
version of TurboGears has code that triggers the same bug.
That said, I don't have a patch to fix the core...
--
Comment By: applebucks (scott_marks)
Date: 2006-10-08 19:54
Message:
Logged In: YES
user_id=120857
I didn't say Python is lame. I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it. That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.
Not to mention it makes my debugging tough. :)
More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 12:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
--
Comment By: applebucks (scott_marks)
Date: 2006-10-03 22:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does. In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.
Not to mention that the workaround ("be sure to rename your
class fac
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by kuran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 13:23
Message:
Logged In: YES
user_id=366566
Originator: NO
Ahem.
Code coverage tools run afoul of this bug as well. A common case is to
run coverage tools using a test suite. If this bug is triggered, then the
resulting coverage data isn't valid.
--
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 13:21
Message:
Logged In: YES
user_id=366566
Originator: NO
Code coverage tools run afoul
--
Comment By: John Ehresman (jpe)
Date: 2006-10-30 11:53
Message:
Logged In: YES
user_id=22785
This could & probably should be fixed, at the cost of making
the core debugger support more complicated. The current
version of TurboGears has code that triggers the same bug.
That said, I don't have a patch to fix the core...
--
Comment By: applebucks (scott_marks)
Date: 2006-10-08 19:54
Message:
Logged In: YES
user_id=120857
I didn't say Python is lame. I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it. That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.
Not to mention it makes my debugging tough. :)
More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 12:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
--
Comment By: applebucks (scott_marks)
Date: 2006-10-03 22:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... w
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 11:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 19:43
Message:
Logged In: YES
user_id=849994
Originator: NO
First of all: Python's Unicode handling is very consistent and
straightforward, if you know the basics. Sadly, most people don't know the
difference between Unicode and encoded strings.
What you're seeing is not a bug, it is due to the fact that if you print
Unicode to the console, and Python could correctly find out your terminal
encoding, the Unicode string is automatically encoded in that encoding.
If you output to a file, Python does not know which encoding you want to
have, so all Unicode strings are converted to ascii only.
Please direct further questions to the Python mailing list or newsgroup.
The basic rule when handling Unicode is: use Unicode everywhere inside the
program, and byte strings for input and output.
So, your code is exactly the other way round: it takes a byte string,
decodes it to unicode and *then* prints it.
You should do it the other way: use Unicode literals in your code, and
when you write something to a file, *encode* them in utf-8.
--
Comment By: Santiago Gala (sgala)
Date: 2007-02-25 11:17
Message:
Logged In: YES
user_id=178886
Originator: YES
Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk
Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:
$python -c "print repr('á %s')"
'\xc3\xa1 %s'
$ python -c "print repr('éi')"
'\xc3\xa9i'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668540 ] I can't change attribute __op__ in new-style classes
Bugs item #1668540, was opened at 2007-02-25 23:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: netimen (netimen) Assigned to: Nobody/Anonymous (nobody) Summary: I can't change attribute __op__ in new-style classes Initial Comment: I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem. In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called. For instance, if I set __mul__ operator to method object new_mul and write setattr(obj, '__mul__', new_mul) obj *= 1 # __mul__ will be called. # But obj.__mul__(1) # new_mul will be called. With common methods and with old-style classes all works properly. P.S. Sorry for my English -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668540 ] I can't change attribute __op__ in new-style classes
Bugs item #1668540, was opened at 2007-02-25 20:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: netimen (netimen) Assigned to: Nobody/Anonymous (nobody) Summary: I can't change attribute __op__ in new-style classes Initial Comment: I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem. In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called. For instance, if I set __mul__ operator to method object new_mul and write setattr(obj, '__mul__', new_mul) obj *= 1 # __mul__ will be called. # But obj.__mul__(1) # new_mul will be called. With common methods and with old-style classes all works properly. P.S. Sorry for my English -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 20:10 Message: Logged In: YES user_id=849994 Originator: NO These special methods are looked up upon the type for new-style classes. This won't change. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-810714 ] nested variables in 'class:' statements
Bugs item #810714, was opened at 2003-09-22 17:05 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: nested variables in 'class:' statements Initial Comment: from the user's point of view, variables originating from nested scopes could erratically become bound in the 'class' statement. The 'class:' statements works by capturing all locals() after executing the body; however, this is not exactly the same as what an explicit call to locals() would return because of the missing PyFrame_FastToLocals() call in the implementation of LOAD_LOCALS in ceval.c. It was thought that PyFrame_FastToLocals() was unnecessary at that point because the class body bytecode only uses LOAD_NAME/STORE_NAME and not fast locals -- but this is no longer true with nested scopes. See attached examples. -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:35 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Armin Rigo (arigo) Date: 2004-01-08 17:13 Message: Logged In: YES user_id=4771 Attached is a draft. I am not sure that I understand all the implications of nested variables in the presence of class bodies, so please don't check in this patch. -- Comment By: Armin Rigo (arigo) Date: 2003-09-24 12:47 Message: Logged In: YES user_id=4771 I'm not sure how to solve this. I could make a patch to LOAD_LOCALS to prevent free variables from showing up in the class.__dict__. For the 2nd problem I'm not familiar enough with compile.c to know how to make the binding 'b="foo"' sufficient to prevent 'b' from also being considered free in the class definition (which is what occurs). Note also that bare 'exec' statements should then be forbidden in class definitions in the presence of free variables, for the same reason as it is forbidden in functions: you cannot tell whether a variable is free or local. As an example of this, if in the attached example we replace b="foo" with exec 'b="foo"' then the last print correctly outputs 'foo' instead of 6 but what actually occurs is that the value of the argument b in f(a,b) was modified by the class definition -- it is a way to change the binding of a variable in an enclosing frame, which should not be possible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 19:16 Message: Logged In: YES user_id=80475 Do you have a proposed patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-810714 ] nested variables in 'class:' statements
Bugs item #810714, was opened at 2003-09-22 17:05 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) >Assigned to: Jeremy Hylton (jhylton) Summary: nested variables in 'class:' statements Initial Comment: from the user's point of view, variables originating from nested scopes could erratically become bound in the 'class' statement. The 'class:' statements works by capturing all locals() after executing the body; however, this is not exactly the same as what an explicit call to locals() would return because of the missing PyFrame_FastToLocals() call in the implementation of LOAD_LOCALS in ceval.c. It was thought that PyFrame_FastToLocals() was unnecessary at that point because the class body bytecode only uses LOAD_NAME/STORE_NAME and not fast locals -- but this is no longer true with nested scopes. See attached examples. -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:36 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:35 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Armin Rigo (arigo) Date: 2004-01-08 17:13 Message: Logged In: YES user_id=4771 Attached is a draft. I am not sure that I understand all the implications of nested variables in the presence of class bodies, so please don't check in this patch. -- Comment By: Armin Rigo (arigo) Date: 2003-09-24 12:47 Message: Logged In: YES user_id=4771 I'm not sure how to solve this. I could make a patch to LOAD_LOCALS to prevent free variables from showing up in the class.__dict__. For the 2nd problem I'm not familiar enough with compile.c to know how to make the binding 'b="foo"' sufficient to prevent 'b' from also being considered free in the class definition (which is what occurs). Note also that bare 'exec' statements should then be forbidden in class definitions in the presence of free variables, for the same reason as it is forbidden in functions: you cannot tell whether a variable is free or local. As an example of this, if in the attached example we replace b="foo" with exec 'b="foo"' then the last print correctly outputs 'foo' instead of 6 but what actually occurs is that the value of the argument b in f(a,b) was modified by the class definition -- it is a way to change the binding of a variable in an enclosing frame, which should not be possible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 19:16 Message: Logged In: YES user_id=80475 Do you have a proposed patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668565 ] inspect.getargspec() fails with keyword-only arguments
Bugs item #1668565, was opened at 2007-02-25 13:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() fails with keyword-only arguments Initial Comment: If a function's signature includes both keyword-only arguments and *args or **kwargs then inspect.getargspec() assigns the name for the * and ** arguments to the first one or two keyword-only arguments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build
Bugs item #1668133, was opened at 2007-02-25 02:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: clemens fischer (inow) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build Initial Comment: 'uname -rms' FreeBSD 6.2-STABLE i386 'cc --version' cc (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. trying to build python-2.4.4 from ports/lang/python24, i get the following messages, where earlier versions have been compiled and installed w/o problems: "./configure" stage: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: see the Autoconf documentation configure: WARNING: ncurses.h: section "Present But Cannot Be Compiled" configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ncurses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for ncurses.h... yes the 'readline' extension builds fine, though: building 'readline' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so I also tried this command after noticing that freebsd needs some special define for wchars: $ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES' ===> Building for python24-2.4.4 case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 3) in /usr/local/include/db43 db.h: found (4, 4) in /usr/local/include/db44 db lib: using (4, 4) db-4.4 INFO: Can't locate Tcl/Tk libs and/or headers building 'nis' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat': /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386
[ python-Bugs-1667877 ] Install fails with no error
Bugs item #1667877, was opened at 2007-02-24 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 23:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668540 ] I can't change attribute __op__ in new-style classes
Bugs item #1668540, was opened at 2007-02-25 23:06 Message generated for change (Comment added) made by netimen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: netimen (netimen) Assigned to: Nobody/Anonymous (nobody) Summary: I can't change attribute __op__ in new-style classes Initial Comment: I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem. In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called. For instance, if I set __mul__ operator to method object new_mul and write setattr(obj, '__mul__', new_mul) obj *= 1 # __mul__ will be called. # But obj.__mul__(1) # new_mul will be called. With common methods and with old-style classes all works properly. P.S. Sorry for my English -- >Comment By: netimen (netimen) Date: 2007-02-26 01:02 Message: Logged In: YES user_id=1728694 Originator: YES But.. then how to overload operators& -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 23:10 Message: Logged In: YES user_id=849994 Originator: NO These special methods are looked up upon the type for new-style classes. This won't change. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.5
Bugs item #1659171, was opened at 2007-02-13 09:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.5 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 14:16 Message: Logged In: YES user_id=33168 Originator: NO Can you test with 2.5 from SVN and confirm your program works in the complete context? -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-22 04:25 Message: Logged In: YES user_id=1718463 Originator: YES The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-14 13:24 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. The exception precisely describes the error in your code ImportError: dynamic module does not define init function (inittestlib) Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module. If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug. -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-14 00:52 Message: Logged In: YES user_id=1718463 Originator: YES I suspect that this is a duplicate of Bug [1548092]. Note that, there it is asserted that tparm returns NULL on certain invalid strings. That does not seem to be true. It returns NULL for valid trivial strings, too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668596 ] distutils chops the first character of filenames
Bugs item #1668596, was opened at 2007-02-25 22:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Pointon (freecondiments) Assigned to: Nobody/Anonymous (nobody) Summary: distutils chops the first character of filenames Initial Comment: Python 2.5c1, Windows XP SP2. distutils chops the first character from some filenames if the package_data key is ''. Minimal example: The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error. On my box, this fails with: running bdist running bdist_dumb running build running build_py error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error. On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1658959 ] os.wait child process fail when under stress
Bugs item #1658959, was opened at 2007-02-13 05:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Groff (thegroff) Assigned to: Nobody/Anonymous (nobody) Summary: os.wait child process fail when under stress Initial Comment: when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 14:19 Message: Logged In: YES user_id=33168 Originator: NO Note that on some versions of Linux 2.4, calling wait() can return ECHILD even when there is a child. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 07:57 Message: Logged In: YES user_id=21627 Originator: NO What operating system are you using? Why do you think this is a bug in Python and not in your operating system? Are you sure there are any unwaited-for children when ECHILD is returned? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:23 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:05 Message: Logged In: YES user_id=4771 Well, try making an "empty" class Foo(object): pass, and see what magically shows up in Foo.__dict__.keys(). Here is the __dict__ descriptor used for instances of Foo. This descriptor is connected to subtype_dict() and subtype_setdict() in typeobject.c. INCREF/DECREFs are in theory missing around every use of the dictionary returned by _PyObject_GetDictPtr(), because more or less any such use could remove the dict from the object from which _PyObject_GetDictPtr() returned from, and so decref the dict - while it's used. This might require some timing, to check the performance impact. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 01:14 Message: Logged In: YES user_id=357491 OK, then I am going to need a little guidance to dive into this more since this is going into some murky waters for me. =) For the normal, non-evil case of an empty Python class (``class Foo(object): pass``), I would think that accessing __dict__ would fall through to the tp_getset for object, and then fall to the same slot for type. Now that is obviously not happening since you get a straight dict back for that attribute access and not a dict proxy as would be suggested based on my logic listed above. So, my question is, where is the code that handles fetching Foo().__dict__? And if you have an inkling of where I should be looking in terms of possible refcounting additions that would be great as well. -- Comment By: Armin Rigo (arigo) Date: 2006-06-29 21:19 Message: Logged In: YES user_id=4771 Brett: I think you're approaching the problem from the wrong angle. The problem is being allowed to freely tamper with the dict stored in objects. Getting NULL errors here and there is only a symptom. As I explain, the '__dict__' descriptor object needs to do some more checks, and to be fully safe some Py_INCREF/Py_DECREF are needed in some critical places. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:45 Message: Logged In: YES user_id=357491 For the deldict.py crasher, if you look at the traceback there is no good place to do a check that tp_dict is sane except in type_module() or PyDict_GetItem(). Now adding the NULL check in type_module() will fix this specific problem, but that seems like an ad-hoc patch. Why don't we check for NULL in PyDict_GetItem() and return NULL just like the PyDict_Check() test? I am sure the answer is "performance", but this is not PyDict_GETITEM()and thus already is not the performance-critical version anyway. So why shouldn't we check for NULL there and possibly catch other errors? -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:41 Message: Logged In: YES user_id=357491 Simple patch for the loosing_dict_ref.py crasher is attached. Just checked for possible NULL values in what is needed by _Py_ForgetReference(). Let me know what you think, Armi
[ python-Bugs-1649098 ] non-standard: array[0]
Bugs item #1649098, was opened at 2007-01-31 10:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Abt (jabt)
>Assigned to: Thomas Heller (theller)
Summary: non-standard: array[0]
Initial Comment:
in Modules/_ctypes/ctypes.h:
typedef struct {
[..]
ffi_type *atypes[0];
} ffi_info;
AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).
Please change *atypes[0] to *atypes[1]!
Bye,
Johannes
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 14:24
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, could you take a look?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build
Bugs item #1668133, was opened at 2007-02-25 01:03 Message generated for change (Comment added) made by inow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: clemens fischer (inow) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build Initial Comment: 'uname -rms' FreeBSD 6.2-STABLE i386 'cc --version' cc (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. trying to build python-2.4.4 from ports/lang/python24, i get the following messages, where earlier versions have been compiled and installed w/o problems: "./configure" stage: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: see the Autoconf documentation configure: WARNING: ncurses.h: section "Present But Cannot Be Compiled" configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ncurses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for ncurses.h... yes the 'readline' extension builds fine, though: building 'readline' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so I also tried this command after noticing that freebsd needs some special define for wchars: $ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES' ===> Building for python24-2.4.4 case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 3) in /usr/local/include/db43 db.h: found (4, 4) in /usr/local/include/db44 db lib: using (4, 4) db-4.4 INFO: Can't locate Tcl/Tk libs and/or headers building 'nis' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat': /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2
[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build
Bugs item #1668133, was opened at 2007-02-25 01:03 Message generated for change (Comment added) made by inow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: clemens fischer (inow) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build Initial Comment: 'uname -rms' FreeBSD 6.2-STABLE i386 'cc --version' cc (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. trying to build python-2.4.4 from ports/lang/python24, i get the following messages, where earlier versions have been compiled and installed w/o problems: "./configure" stage: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: see the Autoconf documentation configure: WARNING: ncurses.h: section "Present But Cannot Be Compiled" configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ncurses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for ncurses.h... yes the 'readline' extension builds fine, though: building 'readline' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so I also tried this command after noticing that freebsd needs some special define for wchars: $ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES' ===> Building for python24-2.4.4 case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 3) in /usr/local/include/db43 db.h: found (4, 4) in /usr/local/include/db44 db lib: using (4, 4) db-4.4 INFO: Can't locate Tcl/Tk libs and/or headers building 'nis' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat': /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Santiago Gala (sgala)
Date: 2007-02-25 23:27
Message:
Logged In: YES
user_id=178886
Originator: YES
re: consistent, my experience it is that python unicode handling is
consistently stupid, doing almost always the wrong thing. It remembers me
of the defaults of WordPerfect, that were always exactly the opposite of
what the user wanted 99% of time. I hope python 3000 comes fast and stops
that real pain.
I love the language, but the way it handles unicode provokes hundreds of
bugs.
>Python could correctly find out your terminal
>encoding, the Unicode string is automatically encoded in that encoding.
>
>If you output to a file, Python does not know which encoding you want to
>have, so all Unicode strings are converted to ascii only.
>>> sys.getfilesystemencoding()
'UTF-8'
so python is really dumb if print does not know my filesystemencoding, but
knows my terminal encoding.
I though breaking the least surprising behaviour was not considered
pythonic, and now you tell me that having a program running on console but
issuing an exception when redirected is intended. I would prefer an
exception in both cases. Or, even better, using
sys.getfilesystemencoding(), or allowing me to set defaultencoding()
>Please direct further questions to the Python mailing list or newsgroup.
I would if I didn't consider this behaviour a bug, and a serious one.
>The basic rule when handling Unicode is: use Unicode everywhere inside
the
>program, and byte strings for input and output.
>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.
>
>You should do it the other way: use Unicode literals in your code, and
>when y(ou write something to a file, *encode* them in utf-8.
Do you mean that I need to say print unicode(whatever).encode('utf8'),
like:
>>> a = unicode('\xc3\xa1','utf8') # instead of 'á', easy to read and
understand, even in files encoded as utf8. Assume this is a literal or
input
...
>>> print unicode(a).encode('utf8') # because a could be a number, or a
different object
every time, instead of "a='á'; print a"
Cool, I'm starting to really love it. Concise and pythonic
Are you seriously meaning that there is no way to tell print to use a
default encoding, and it will magically try to find it and fail for
everything not being a terminal?
Are you seriously telling me that this is not a bug? Even worse, that it
is "intended behaviour". BTW, jython acts differently about this, in all
the versions I tried.
And with -S I am allowed to change the encoding, which is crippled in site
for no known good reason.
python -S -c "import sys; sys.setdefaultencoding('utf8'); print
unicode('\xc3\xa1','utf8')" >test
(works, test contains an accented a as intended
>use Unicode everywhere inside the
>program, and byte strings for input and output.
Have you ever wondered that to use unicode everywhere inside the program,
one needs to decode literals (or input) to unicode (the next sentence you
complain about)?
>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.
I follow this principle in my programming since about 6 years ago, so I'm
not a novice. I'm playing by the rules:
a) "decodes it to unicode" is the first step to get it into processing.
This is just a test case, so processing is zero.
b) I refuse to believe that the only way to ensure something to be printed
right is wrapping every item into unicode(var).encode('utf8') [The
redundant unicode call is because the var could be a number, or a different
object]
c) or making my code non portable by patching site.py to get a real
encoding instead of asc
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:36 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:23 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:05 Message: Logged In: YES user_id=4771 Well, try making an "empty" class Foo(object): pass, and see what magically shows up in Foo.__dict__.keys(). Here is the __dict__ descriptor used for instances of Foo. This descriptor is connected to subtype_dict() and subtype_setdict() in typeobject.c. INCREF/DECREFs are in theory missing around every use of the dictionary returned by _PyObject_GetDictPtr(), because more or less any such use could remove the dict from the object from which _PyObject_GetDictPtr() returned from, and so decref the dict - while it's used. This might require some timing, to check the performance impact. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 01:14 Message: Logged In: YES user_id=357491 OK, then I am going to need a little guidance to dive into this more since this is going into some murky waters for me. =) For the normal, non-evil case of an empty Python class (``class Foo(object): pass``), I would think that accessing __dict__ would fall through to the tp_getset for object, and then fall to the same slot for type. Now that is obviously not happening since you get a straight dict back for that attribute access and not a dict proxy as would be suggested based on my logic listed above. So, my question is, where is the code that handles fetching Foo().__dict__? And if you have an inkling of where I should be looking in terms of possible refcounting additions that would be great as well. -- Comment By: Armin Rigo (arigo) Date: 2006-06-29 21:19 Message: Logged In: YES user_id=4771 Brett: I think you're approaching the problem from the wrong angle. The problem is being allowed to freely tamper with the dict stored in objects. Getting NULL errors here and there is only a symptom. As I explain, the '__dict__' descriptor object needs to do some more checks, and to be fully safe some Py_INCREF/Py_DECREF are needed in some critical places. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:45 Message: Logged In: YES user_id=357491 For the deldict.py crasher, if you look at the traceback there is no good place to do a check that tp_dict is sane except in type_module() or PyDict_GetItem(). Now adding the NULL check in type_module() will fix this specific problem, but that seems like an ad-hoc patch. Why don't we check for NULL in PyDict_GetItem() and return NULL just like the PyDict_Check() test? I am sure the answer is "performance", but this is not PyDict_GETITEM(
[ python-Bugs-1627039 ] mention side-lists from python-dev description
Bugs item #1627039, was opened at 2007-01-03 15:06 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: mention side-lists from python-dev description Initial Comment: http://www.python.org/community/lists/ describes mailing lists for python, including python-dev. Change: """ Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python. """ to """ Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python. If you want to discuss larger changes, please use python-ideas instead. http://mail.python.org/mailman/listinfo/python-ideas """ -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:40 Message: Logged In: YES user_id=31392 Originator: NO http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets It would be better to file a web site bug report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1620945 ] minor inconsistency in socket.close
Bugs item #1620945, was opened at 2006-12-22 18:05 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: minor inconsistency in socket.close Initial Comment: In python 2.5 socket.close, all methods are delegated to _dummy, which raises an error. It would be more consistent to delegate each method to its counterpart in _closedsocket; in particular re-closing a closed socket is not intended to raise: def close(self): self._sock.close() self._sock = _closedsocket() for method in _delegate_methods: setattr(self, method, getattr(self._sock, method)) -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:48 Message: Logged In: YES user_id=31392 Originator: NO Re-closing a socket does not raise an exception. If there is something else in your bug report that I am missing, please re-open it. -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-20 01:51 Message: Logged In: YES user_id=1591633 Originator: NO On trunk: >>> import socket >>> s=socket.socket() >>> s.close() >>> s.close() >>> It also seems that the following line will make even that remapping not useful? Isn't it better just to avoid the layer of indirection and directly proceed with assigning to _dummy? line 145: send = recv = recv_into = sendto = recvfrom = recvfrom_into = _dummy -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 11:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 23:27
Message:
Logged In: YES
user_id=849994
Originator: NO
> >>> sys.getfilesystemencoding()
> 'UTF-8'
>
> so python is really dumb if print does not know my filesystemencoding,
but
> knows my terminal encoding.
the file system encoding is the encoding of file names, not of file
content.
> I though breaking the least surprising behaviour was not considered
> pythonic, and now you tell me that having a program running on console
but
> issuing an exception when redirected is intended. I would prefer an
> exception in both cases. Or, even better, using
> sys.getfilesystemencoding(), or allowing me to set defaultencoding()
I agree that using the terminal encoding is perhaps a bit too DWIMish, but
you
can always get consistent results if you *do not write Unicode strings
anywhere*.
> Do you mean that I need to say print unicode(whatever).encode('utf8'),
> like:
>
> >>> a = unicode('\xc3\xa1','utf8') # instead of 'á', easy to read and
> understand, even in files encoded as utf8. Assume this is a literal or
> input
No. You can directly put Unicode literals in your files, with u'...'.
For that to work, you need to tell Python the encoding your file has,
using the coding cookie (see the docs).
> ...
> >>> print unicode(a).encode('utf8') # because a could be a number, or a
> different object
>
> every time, instead of "a='á'; print a"
> Cool, I'm starting to really love it. Concise and pythonic
> Are you seriously meaning that there is no way to tell print to use a
> default encoding, and it will magically try to find it and fail for
> everything not being a terminal?
This is not magic. "print" looks for an "encoding" attribute on the file
it is printing to. This is the terminal encoding for sys.stdout and None
for
other files.
> Are you seriously telling me that this is not a bug? Even worse, that
it
> is "intended behaviour". BTW, jython acts differently about this, in
all
> the versions I tried.
It *is* not a bug. This was implemented as a simplification for terminal
output.
> And with -S I am allowed to change the encoding, which is crippled in
site
> for no known good reason.
> python -S -c "import sys; sys.setdefaultencoding('utf8'); print
> unicode('\xc3\xa1','utf8')" >test
> (works, test contains an accented a as intended
Because setdefaultencoding() affects *every* conversion from unicode to
string
and from string to unicode, which can be very confusing if you have to
handle
different encodings.
>>use Unicode everywhere inside the
>>program, and byte strings for input and output.
> Have you ever wondered that to use unicode everywhere inside the
program,
> one needs to decode literals (or input) to unicode (the next sentence
you
> complain about)?
Yes, you have to decode input (for files, you can do this automatically if
you
use codecs.open(), not builtin open()). No, you don't have to decode
literals as
Unicode literals exist.
> I follow this principle in my programming since about 6 years ago, so
I'm
> not a novice. I'm playing by the rules:
> a) "decodes it to unicode" is the first step to get it into processing.
> This is just a test case, so processing is zero.
> b) I refuse to believe that the only way to ensure something to be
printed
> right is wrapping every item into unicode(var).encode('utf8') [The
> redundant unicode call is because the var could be a number, or a
different
> object]
No, that is of course not the only way. An alternative is to use an
encoded file,
as the codecs module offers.
If you e.g. set
sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8')
you can print Unicode strings to stdout, and they will automaticall
[ python-Bugs-1667877 ] Install fails with no error
Bugs item #1667877, was opened at 2007-02-24 10:10 Message generated for change (Comment added) made by widgeteye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None >Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? -- >Comment By: larry (widgeteye) Date: 2007-02-26 00:10 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 16:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1667877 ] Install fails with no error
Bugs item #1667877, was opened at 2007-02-24 10:10 Message generated for change (Comment added) made by widgeteye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None >Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? -- >Comment By: larry (widgeteye) Date: 2007-02-26 00:11 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: larry (widgeteye) Date: 2007-02-26 00:10 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 16:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build
Bugs item #1668133, was opened at 2007-02-25 02:03 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: clemens fischer (inow) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build Initial Comment: 'uname -rms' FreeBSD 6.2-STABLE i386 'cc --version' cc (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. trying to build python-2.4.4 from ports/lang/python24, i get the following messages, where earlier versions have been compiled and installed w/o problems: "./configure" stage: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: see the Autoconf documentation configure: WARNING: ncurses.h: section "Present But Cannot Be Compiled" configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ncurses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for ncurses.h... yes the 'readline' extension builds fine, though: building 'readline' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so I also tried this command after noticing that freebsd needs some special define for wchars: $ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES' ===> Building for python24-2.4.4 case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 3) in /usr/local/include/db43 db.h: found (4, 4) in /usr/local/include/db44 db lib: using (4, 4) db-4.4 INFO: Can't locate Tcl/Tk libs and/or headers building 'nis' extension cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat': /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i
[ python-Bugs-1667877 ] Install fails with no error
Bugs item #1667877, was opened at 2007-02-24 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-26 07:21 Message: Logged In: YES user_id=21627 Originator: NO Can you reproduce the problem on your system? Can you give instructions on how to reproduce it on another system? If not, I see little chance to resolve this problem. -- Comment By: larry (widgeteye) Date: 2007-02-26 07:11 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: larry (widgeteye) Date: 2007-02-26 07:10 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 23:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
