[ python-Bugs-1228830 ] update to 7.15 zlib & 7.18.1 ZipFile Objects docs
Bugs item #1228830, was opened at 2005-06-28 03:53 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=1228830&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: Open Resolution: None Priority: 5 Submitted By: Brian vdB (brianvanden) Assigned to: Nobody/Anonymous (nobody) Summary: update to 7.15 zlib & 7.18.1 ZipFile Objects docs Initial Comment: At present, the zlib docs say: "1.1.3 has a security vulnerability, so we recommend using 1.1.4 or later." http://docs.python.org/lib/module-zlib.html But, the zlib home page says: "Version 1.2.2 eliminates a potential security vulnerability in zlib 1.2.1, so all users of 1.2.1 should upgrade immediately. The following important fixes are provided in zlib 1.2.2" http://www.gzip.org/zlib/ So, I suggest the text of the Python docs should be altered to read: Version 1.2.1 has a security vulnerability, so we recommend using 1.2.2 or later. NB I only know what I read on the zlib home page, so I've no particuliar domain knowledge. While I am at it, the docs for both zlib and zipfile.Zipfile could be a bit more explicit that zlib is a 3rd party module not included with Python and unlikely to present on a Windows box. I suggest that the current zlib docs "For applications that require data compression, the functions in this module allow compression and decompression, using the zlib library. The zlib library has its own home page at http://www.gzip.org/zlib/."; http://docs.python.org/lib/module-zlib.html be changed to: For applications that require data compression, the functions in this module allow compression and decompression, using the third-party zlib library. The zlib library can be downloaded from http://www.gzip.org/zlib/. and the Zipfile docs: "If ZIP_DEFLATED is specified but the zlib module is not available, RuntimeError is also raised." http://docs.python.org/lib/zipfile-objects.html be changed to: If ZIP_DEFLATED is specified and the third-party zlib module is not available, RuntimeError is also raised. Thanks, and best, Brian vdB -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228830&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames
Bugs item #767645, was opened at 2003-07-08 11:42
Message generated for change (Comment added) made by jvr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&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 2.3
Status: Open
Resolution: Later
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect os.path.supports_unicode_filenames
Initial Comment:
At least on OSX, unicode file names are pretty much fully
supported, yet os.path.supports_unicode_filenames is False
(it comes from posixpath.py, which hard codes it). What
would be a proper way to detect unicode filename support
for posix platforms?
--
>Comment By: Just van Rossum (jvr)
Date: 2005-06-28 11:46
Message:
Logged In: YES
user_id=92689
Hmm, two years later and this still hasn't been resolved. Is anyone
interested to take a stab at it? It would be nice if it could be fixed for 2.5.
(Btw. the only code using os.path.supports_unicode_filenames that I'm
aware of is Jason Orendorff's path module.)
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-17 18:21
Message:
Logged In: YES
user_id=92689
(forgot to mention: my checkin was backed out)
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-17 18:20
Message:
Logged In: YES
user_id=92689
Reopeing as the fix I checked in caused problems in
test_pep277.py. Postpone work on this until after 2.3 is released.
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-11 09:48
Message:
Logged In: YES
user_id=92689
Done in rev. 1.61 of posixpath.py.
(Actually, OSX does complain when you feed open() a non-valid
utf-8 string (albeit with a misleading error message). The OS also
makes sure the name is converted to its preferred form, eg. if I
create a file named u'\xc7', I can also open it as u'C\u0327', and
os.listdir() will always show the latter, no matter how you created
the file.)
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-11 00:34
Message:
Logged In: YES
user_id=21627
>I'm not 100% sure, but I think the OS corrects that
I'm relatively sure that the OS doesn't. The OS won't
complain if you pass a file name that isn't UTF-8 at all -
Finder will then fail to display the file correctly. There
are CoreFoundationsBasicServicesSomething functions that you
are supposed to call to correct that; Python does not use them.
If you think setting the flag for darwin is fine in
posixpath, just go ahead.
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-10 23:13
Message:
Logged In: YES
user_id=92689
> On OSX, the situation is somewhat different from POSIX, as
> you have additional functions to open files (which Python
> apparently does not use, though), and because OSX specifies
> that the byte strings have to be NFD UTF-8 (which Python
> violates AFAICT).
(I'm not 100% sure, but I think the OS corrects that)
> True if arbitrary Unicode strings can be used as file names
> (within limitations imposed by the file system), and if
> \function{os.listdir()} returns Unicode strings for a Unicode
> argument.
>
> While the first part is true for OSX, I don't think the
> second part is.
It is, we had a long discussion about that back when I
implemented that ;-)
> If that ever gets corrected (or verified),
> no further detection is necessary - just set
> macpath.supports_unicode_filenames for darwin (assuming you
> use macpath.py on that system).
Darwin is a posix platform, so I'll have to add a switch to
posixpath.py. Unless you object to that, I will do that.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-10 23:05
Message:
Logged In: YES
user_id=21627
Brett: As for "writing Unicode to an ASCII file system":
there is no such thing. POSIX file systems accept arbitrary
bytes, and don't interpret them except by looking at the
path separator (in ASCII).
So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc
all on a single file system, and people actually do that.
The convention is that bytes in file names are interpreted
according to the locale's encoding. This is just a
convention, and it has some significant flaws. Python
follows that convention, meaning that you can use arbitrary
Unicode strings in open(), as long as they are supported in
the locale's encoding.
--
C
[ python-Bugs-1228904 ] weakref example broken
Bugs item #1228904, was opened at 2005-06-28 10:32 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=1228904&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: 5 Submitted By: paolo veronelli (paolo_veronelli) Assigned to: Nobody/Anonymous (nobody) Summary: weakref example broken Initial Comment: Surely the example in python2.4/lib/weakref-objects.html is untested .Bad story. Attached a working version which I suppose correct it . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Bugs item #1212703, was opened at 2005-06-01 15:05
Message generated for change (Comment added) made by ranma
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&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
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?
Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])
Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC
(...)
creating Makefile
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
--
>Comment By: Vincent Jamart (ranma)
Date: 2005-06-28 17:05
Message:
Logged In: YES
user_id=150220
This is how we managed to solve the problem here, but it's
not a clean solution:
#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
M
[ python-Bugs-1228830 ] update to 7.15 zlib & 7.18.1 ZipFile Objects docs
Bugs item #1228830, was opened at 2005-06-28 03:53 Message generated for change (Comment added) made by brianvanden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228830&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: Open Resolution: None Priority: 5 Submitted By: Brian vdB (brianvanden) Assigned to: Nobody/Anonymous (nobody) Summary: update to 7.15 zlib & 7.18.1 ZipFile Objects docs Initial Comment: At present, the zlib docs say: "1.1.3 has a security vulnerability, so we recommend using 1.1.4 or later." http://docs.python.org/lib/module-zlib.html But, the zlib home page says: "Version 1.2.2 eliminates a potential security vulnerability in zlib 1.2.1, so all users of 1.2.1 should upgrade immediately. The following important fixes are provided in zlib 1.2.2" http://www.gzip.org/zlib/ So, I suggest the text of the Python docs should be altered to read: Version 1.2.1 has a security vulnerability, so we recommend using 1.2.2 or later. NB I only know what I read on the zlib home page, so I've no particuliar domain knowledge. While I am at it, the docs for both zlib and zipfile.Zipfile could be a bit more explicit that zlib is a 3rd party module not included with Python and unlikely to present on a Windows box. I suggest that the current zlib docs "For applications that require data compression, the functions in this module allow compression and decompression, using the zlib library. The zlib library has its own home page at http://www.gzip.org/zlib/."; http://docs.python.org/lib/module-zlib.html be changed to: For applications that require data compression, the functions in this module allow compression and decompression, using the third-party zlib library. The zlib library can be downloaded from http://www.gzip.org/zlib/. and the Zipfile docs: "If ZIP_DEFLATED is specified but the zlib module is not available, RuntimeError is also raised." http://docs.python.org/lib/zipfile-objects.html be changed to: If ZIP_DEFLATED is specified and the third-party zlib module is not available, RuntimeError is also raised. Thanks, and best, Brian vdB -- >Comment By: Brian vdB (brianvanden) Date: 2005-06-28 11:24 Message: Logged In: YES user_id=1015686 Apologies. I was evidently confused with my idea that zlib was third-party. Please close the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228830&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1228830 ] update to 7.15 zlib & 7.18.1 ZipFile Objects docs
Bugs item #1228830, was opened at 2005-06-28 02:53 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228830&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 Submitted By: Brian vdB (brianvanden) Assigned to: Nobody/Anonymous (nobody) Summary: update to 7.15 zlib & 7.18.1 ZipFile Objects docs Initial Comment: At present, the zlib docs say: "1.1.3 has a security vulnerability, so we recommend using 1.1.4 or later." http://docs.python.org/lib/module-zlib.html But, the zlib home page says: "Version 1.2.2 eliminates a potential security vulnerability in zlib 1.2.1, so all users of 1.2.1 should upgrade immediately. The following important fixes are provided in zlib 1.2.2" http://www.gzip.org/zlib/ So, I suggest the text of the Python docs should be altered to read: Version 1.2.1 has a security vulnerability, so we recommend using 1.2.2 or later. NB I only know what I read on the zlib home page, so I've no particuliar domain knowledge. While I am at it, the docs for both zlib and zipfile.Zipfile could be a bit more explicit that zlib is a 3rd party module not included with Python and unlikely to present on a Windows box. I suggest that the current zlib docs "For applications that require data compression, the functions in this module allow compression and decompression, using the zlib library. The zlib library has its own home page at http://www.gzip.org/zlib/."; http://docs.python.org/lib/module-zlib.html be changed to: For applications that require data compression, the functions in this module allow compression and decompression, using the third-party zlib library. The zlib library can be downloaded from http://www.gzip.org/zlib/. and the Zipfile docs: "If ZIP_DEFLATED is specified but the zlib module is not available, RuntimeError is also raised." http://docs.python.org/lib/zipfile-objects.html be changed to: If ZIP_DEFLATED is specified and the third-party zlib module is not available, RuntimeError is also raised. Thanks, and best, Brian vdB -- Comment By: Brian vdB (brianvanden) Date: 2005-06-28 10:24 Message: Logged In: YES user_id=1015686 Apologies. I was evidently confused with my idea that zlib was third-party. Please close the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228830&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227748 ] subprocess: inheritance of std descriptors inconsistent
Bugs item #1227748, was opened at 2005-06-26 08:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&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 2.4 Status: Open Resolution: None Priority: 5 Submitted By: André Malo (ndparker) >Assigned to: Peter Åstrand (astrand) Summary: subprocess: inheritance of std descriptors inconsistent Initial Comment: The inheritance of std descriptors is inconsistent between Unix and Windows implementations. If one calls Popen with stdin = stdout = stderr = None, the caller's std descriptors are inherited on *x, but not on Windows, because of the following optimization (from subprocess.py r1.20): 655 def _get_handles(self, stdin, stdout, stderr): 656 """Construct and return tupel with IO objects: 657 p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite 658 """ 659 if stdin is None and stdout is None and stderr is None: 660 return (None, None, None, None, None, None) 661 I suggest to just remove those lines 659 and 660. The current workaround is to duplicate the handles by the application and supply an own STARTUPINFO structure. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229264 ] error whit dict working whith class
Bugs item #1229264, was opened at 2005-06-28 15:47
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=1229264&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: ST2015 (st2015)
Assigned to: Nobody/Anonymous (nobody)
Summary: error whit dict working whith class
Initial Comment:
se follow code:
"""
class my_class:
a={}
def __init__(self, n):
self.a = n
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
"""
must show:
a1= {'a': 1, 'b': 1}
a2= {'a': 1, 'b': 1}
a1= {'a': 2, 'b': 1}
but show:
a1= {'a': 1, 'b': 1}
a2= {'a': 2, 'b': 1}
a1= {'a': 2, 'b': 1}
This error happend only whit dicts, y only when de dict
atributte is defined before of the __init__ of the class
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229264 ] error whit dict working whith class
Bugs item #1229264, was opened at 2005-06-28 15:47
Message generated for change (Comment added) made by st2015
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: ST2015 (st2015)
Assigned to: Nobody/Anonymous (nobody)
Summary: error whit dict working whith class
Initial Comment:
se follow code:
"""
class my_class:
a={}
def __init__(self, n):
self.a = n
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
"""
must show:
a1= {'a': 1, 'b': 1}
a2= {'a': 1, 'b': 1}
a1= {'a': 2, 'b': 1}
but show:
a1= {'a': 1, 'b': 1}
a2= {'a': 2, 'b': 1}
a1= {'a': 2, 'b': 1}
This error happend only whit dicts, y only when de dict
atributte is defined before of the __init__ of the class
--
>Comment By: ST2015 (st2015)
Date: 2005-06-28 15:54
Message:
Logged In: YES
user_id=1304338
sorry the code is the folowing:
class my_class:
a={}
def __init__(self, n):
for i in n:
self.a[i] = n[i]
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229264 ] error whit dict working whith class
Bugs item #1229264, was opened at 2005-06-28 15:47
Message generated for change (Comment added) made by st2015
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: ST2015 (st2015)
Assigned to: Nobody/Anonymous (nobody)
Summary: error whit dict working whith class
Initial Comment:
se follow code:
"""
class my_class:
a={}
def __init__(self, n):
self.a = n
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
"""
must show:
a1= {'a': 1, 'b': 1}
a2= {'a': 1, 'b': 1}
a1= {'a': 2, 'b': 1}
but show:
a1= {'a': 1, 'b': 1}
a2= {'a': 2, 'b': 1}
a1= {'a': 2, 'b': 1}
This error happend only whit dicts, y only when de dict
atributte is defined before of the __init__ of the class
--
>Comment By: ST2015 (st2015)
Date: 2005-06-28 15:54
Message:
Logged In: YES
user_id=1304338
sorry the code is the folowing:
class my_class:
a={}
def __init__(self, n):
for i in n:
self.a[i] = n[i]
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
--
Comment By: ST2015 (st2015)
Date: 2005-06-28 15:54
Message:
Logged In: YES
user_id=1304338
sorry the code is the folowing:
class my_class:
a={}
def __init__(self, n):
for i in n:
self.a[i] = n[i]
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229264 ] error whit dict working whith class
Bugs item #1229264, was opened at 2005-06-28 21:47
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&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.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ST2015 (st2015)
Assigned to: Nobody/Anonymous (nobody)
Summary: error whit dict working whith class
Initial Comment:
se follow code:
"""
class my_class:
a={}
def __init__(self, n):
self.a = n
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
"""
must show:
a1= {'a': 1, 'b': 1}
a2= {'a': 1, 'b': 1}
a1= {'a': 2, 'b': 1}
but show:
a1= {'a': 1, 'b': 1}
a2= {'a': 2, 'b': 1}
a1= {'a': 2, 'b': 1}
This error happend only whit dicts, y only when de dict
atributte is defined before of the __init__ of the class
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-28 22:01
Message:
Logged In: YES
user_id=1188172
Then this is no bug.
You are never assigning to self.a, thus the "a" you
reference in the class's methods is the one defined as a
class attribute and therefore shared between instances.
--
Comment By: ST2015 (st2015)
Date: 2005-06-28 21:54
Message:
Logged In: YES
user_id=1304338
sorry the code is the folowing:
class my_class:
a={}
def __init__(self, n):
for i in n:
self.a[i] = n[i]
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
--
Comment By: ST2015 (st2015)
Date: 2005-06-28 21:54
Message:
Logged In: YES
user_id=1304338
sorry the code is the folowing:
class my_class:
a={}
def __init__(self, n):
for i in n:
self.a[i] = n[i]
def hola(self, b):
self.a["a"] = b
a1 = my_class({"a":1, "b":1})
print "a1=", a1.a
a2 = my_class({"a":1, "b":1})
a1.hola(2)
print "a2=", a2.a
print "a1=", a1.a
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames
Bugs item #767645, was opened at 2003-07-08 11:42
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&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 2.3
Status: Open
Resolution: Later
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect os.path.supports_unicode_filenames
Initial Comment:
At least on OSX, unicode file names are pretty much fully
supported, yet os.path.supports_unicode_filenames is False
(it comes from posixpath.py, which hard codes it). What
would be a proper way to detect unicode filename support
for posix platforms?
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-06-28 23:04
Message:
Logged In: YES
user_id=21627
I don't care about this issue, as I think
supports_unicode_filenames is a pretty useless property
these days. If somebody changes the current value from False
to True, just make sure that the testsuite still passes.
--
Comment By: Just van Rossum (jvr)
Date: 2005-06-28 11:46
Message:
Logged In: YES
user_id=92689
Hmm, two years later and this still hasn't been resolved. Is anyone
interested to take a stab at it? It would be nice if it could be fixed for 2.5.
(Btw. the only code using os.path.supports_unicode_filenames that I'm
aware of is Jason Orendorff's path module.)
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-17 18:21
Message:
Logged In: YES
user_id=92689
(forgot to mention: my checkin was backed out)
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-17 18:20
Message:
Logged In: YES
user_id=92689
Reopeing as the fix I checked in caused problems in
test_pep277.py. Postpone work on this until after 2.3 is released.
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-11 09:48
Message:
Logged In: YES
user_id=92689
Done in rev. 1.61 of posixpath.py.
(Actually, OSX does complain when you feed open() a non-valid
utf-8 string (albeit with a misleading error message). The OS also
makes sure the name is converted to its preferred form, eg. if I
create a file named u'\xc7', I can also open it as u'C\u0327', and
os.listdir() will always show the latter, no matter how you created
the file.)
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-11 00:34
Message:
Logged In: YES
user_id=21627
>I'm not 100% sure, but I think the OS corrects that
I'm relatively sure that the OS doesn't. The OS won't
complain if you pass a file name that isn't UTF-8 at all -
Finder will then fail to display the file correctly. There
are CoreFoundationsBasicServicesSomething functions that you
are supposed to call to correct that; Python does not use them.
If you think setting the flag for darwin is fine in
posixpath, just go ahead.
--
Comment By: Just van Rossum (jvr)
Date: 2003-07-10 23:13
Message:
Logged In: YES
user_id=92689
> On OSX, the situation is somewhat different from POSIX, as
> you have additional functions to open files (which Python
> apparently does not use, though), and because OSX specifies
> that the byte strings have to be NFD UTF-8 (which Python
> violates AFAICT).
(I'm not 100% sure, but I think the OS corrects that)
> True if arbitrary Unicode strings can be used as file names
> (within limitations imposed by the file system), and if
> \function{os.listdir()} returns Unicode strings for a Unicode
> argument.
>
> While the first part is true for OSX, I don't think the
> second part is.
It is, we had a long discussion about that back when I
implemented that ;-)
> If that ever gets corrected (or verified),
> no further detection is necessary - just set
> macpath.supports_unicode_filenames for darwin (assuming you
> use macpath.py on that system).
Darwin is a posix platform, so I'll have to add a switch to
posixpath.py. Unless you object to that, I will do that.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-10 23:05
Message:
Logged In: YES
user_id=21627
Brett: As for "writing Unicode to an ASCII file system":
there is no such thing. POSIX file systems accept arbitrary
bytes, and don't interpret them except by looking at the
path separator (in ASCII).
So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc
all on a single file system, and people actual
[ python-Bugs-1229380 ] No struct.pack exception for some out of range integers
Bugs item #1229380, was opened at 2005-06-29 02:30
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=1229380&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 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: No struct.pack exception for some out of range integers
Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.
But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod
Bugs item #1229429, was opened at 2005-06-28 22:18 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=1229429&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 Submitted By: Gary (gdray-1) Assigned to: Nobody/Anonymous (nobody) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&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 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:35 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&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 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:46 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:35 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&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 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:50 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:46 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:35 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&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 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:51 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:50 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:46 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:35 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&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 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:53 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:51 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:50 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:46 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:35 Message: Logged In: YES user_id=81797 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC
Bugs item #1222790, was opened at 2005-06-17 17:18 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&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: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Winfried Harbecke (wharbecke) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html -- >Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:55 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC
Bugs item #1222790, was opened at 2005-06-17 17:18 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&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: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Winfried Harbecke (wharbecke) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html -- >Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:56 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:55 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC
Bugs item #1222790, was opened at 2005-06-17 17:18 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&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: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Winfried Harbecke (wharbecke) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html -- >Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:58 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:56 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- Comment By: Sean Reifschneider (jafo) Date: 2005-06-29 02:55 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak
Bugs item #1208304, was opened at 2005-05-25 09:20
Message generated for change (Comment added) made by jafo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Petr Toman (manekcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2's urlopen() method causes a memory leak
Initial Comment:
It seems that the urlopen(url) methd of the urllib2 module
leaves some undestroyable objects in memory.
Please try the following code:
==
if __name__ == '__main__':
import urllib2
a = urllib2.urlopen('http://www.google.com')
del a # or a = None or del(a)
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
for it in gc.garbage:
print it
==
In our code, we're using lots of urlopens in a loop and
the number of unreachable objects grows beyond all
limits :) We also tried a.close() but it didn't help.
You can also try the following:
==
def print_unreachable_len():
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
unreachableL = []
for it in gc.garbage:
unreachableL.append(it)
return len(str(unreachableL))
if __name__ == '__main__':
print "at the beginning", print_unreachable_len()
import urllib2
print "after import of urllib2", print_unreachable_len()
a = urllib2.urlopen('http://www.google.com')
print 'after urllib2.urlopen', print_unreachable_len()
del a
print 'after del', print_unreachable_len()
==
We're using WindowsXP with latest patches, Python 2.4
(ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310
32 bit (Intel)] on win32).
--
>Comment By: Sean Reifschneider (jafo)
Date: 2005-06-29 03:27
Message:
Logged In: YES
user_id=81797
I can reproduce this in both the python.org 2.4 RPM and in a
freshly built copy from CVS. If I run a few thousand
urlopen()s, I get:
Traceback (most recent call last):
File "/tmp/mt", line 26, in ?
File "/tmp/python/dist/src/Lib/urllib2.py", line 130, in
urlopen
File "/tmp/python/dist/src/Lib/urllib2.py", line 361, in open
File "/tmp/python/dist/src/Lib/urllib2.py", line 379, in _open
File "/tmp/python/dist/src/Lib/urllib2.py", line 340, in
_call_chain
File "/tmp/python/dist/src/Lib/urllib2.py", line 1026, in
http_open
File "/tmp/python/dist/src/Lib/urllib2.py", line 1001, in
do_open
urllib2.URLError:
Even if I do a a.close(). I'll investigate a bit further.
Sean
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-01 23:13
Message:
Logged In: YES
user_id=11375
Confirmed. The objects involved seem to be an HTTPResponse and the
socket._fileobject wrapper; the assignment 'r.recv=r.read' around line 1013
of urllib2.py seems to be critical to creating the cycle.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak
Bugs item #1208304, was opened at 2005-05-25 09:20
Message generated for change (Comment added) made by jafo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Petr Toman (manekcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2's urlopen() method causes a memory leak
Initial Comment:
It seems that the urlopen(url) methd of the urllib2 module
leaves some undestroyable objects in memory.
Please try the following code:
==
if __name__ == '__main__':
import urllib2
a = urllib2.urlopen('http://www.google.com')
del a # or a = None or del(a)
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
for it in gc.garbage:
print it
==
In our code, we're using lots of urlopens in a loop and
the number of unreachable objects grows beyond all
limits :) We also tried a.close() but it didn't help.
You can also try the following:
==
def print_unreachable_len():
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
unreachableL = []
for it in gc.garbage:
unreachableL.append(it)
return len(str(unreachableL))
if __name__ == '__main__':
print "at the beginning", print_unreachable_len()
import urllib2
print "after import of urllib2", print_unreachable_len()
a = urllib2.urlopen('http://www.google.com')
print 'after urllib2.urlopen', print_unreachable_len()
del a
print 'after del', print_unreachable_len()
==
We're using WindowsXP with latest patches, Python 2.4
(ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310
32 bit (Intel)] on win32).
--
>Comment By: Sean Reifschneider (jafo)
Date: 2005-06-29 03:52
Message:
Logged In: YES
user_id=81797
I give up, this code is kind of a maze of twisty little
passages. I did try doing "a.fp.close()" and that didn't
seem to help at all. Couldn't really make any progress on
that though. I also tried doing a "if a.headers.fp:
a.headers.fp.close()", which didn't do anything noticable.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-06-29 03:27
Message:
Logged In: YES
user_id=81797
I can reproduce this in both the python.org 2.4 RPM and in a
freshly built copy from CVS. If I run a few thousand
urlopen()s, I get:
Traceback (most recent call last):
File "/tmp/mt", line 26, in ?
File "/tmp/python/dist/src/Lib/urllib2.py", line 130, in
urlopen
File "/tmp/python/dist/src/Lib/urllib2.py", line 361, in open
File "/tmp/python/dist/src/Lib/urllib2.py", line 379, in _open
File "/tmp/python/dist/src/Lib/urllib2.py", line 340, in
_call_chain
File "/tmp/python/dist/src/Lib/urllib2.py", line 1026, in
http_open
File "/tmp/python/dist/src/Lib/urllib2.py", line 1001, in
do_open
urllib2.URLError:
Even if I do a a.close(). I'll investigate a bit further.
Sean
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-01 23:13
Message:
Logged In: YES
user_id=11375
Confirmed. The objects involved seem to be an HTTPResponse and the
socket._fileobject wrapper; the assignment 'r.recv=r.read' around line 1013
of urllib2.py seems to be critical to creating the cycle.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Bugs item #1212703, was opened at 2005-06-01 15:05
Message generated for change (Comment added) made by ranma
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&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
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?
Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])
Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC
(...)
creating Makefile
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
--
>Comment By: Vincent Jamart (ranma)
Date: 2005-06-29 08:50
Message:
Logged In: YES
user_id=150220
This is how we managed to solve the problem here, but it's
not a clean solution:
#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
M
