[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin
Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by jacek_poplawski
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin
Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.
When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576).
Using options stdin, stdout, stderr doesn't help.
I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded.
$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)
--
>Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-09-30 10:07
Message:
Logged In: YES
user_id=264913
Yes, I can run test_subprocess.py and all 38 tests are OK
(in 15 seconds).
Just like I wrote I can't reproduce that with any simple
command, so maybe problem is that subprocess.Popen locks
_if_ application does something specific - but what?
PS. But I can reproduce that on few different computers with
different Python installations so it is not just
installation problem.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 07:33
Message:
Logged In: YES
user_id=33168
Jason, any comments? Is this cygwin specific or a general
subprocess issue?
--
Comment By: Peter Åstrand (astrand)
Date: 2005-09-29 21:32
Message:
Logged In: YES
user_id=344921
Does the testsuite test_subprocess.py work correctly on this
platform?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- >Comment By: Michael Hudson (mwh) Date: 2005-09-30 09:20 Message: Logged In: YES user_id=6656 It's fixed now: Python/pystate.c revision 2.43 Python/pystate.c revision 2.38.2.4 -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:31 Message: Logged In: YES user_id=33168 Wasn't a fix for this checked in? Can this be closed? -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:04 Message: Logged In: YES user_id=6656 Can you try the attached? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 14:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Jeremy Friesner (jfriesne) Assigned to: Martin v. Löwis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- >Comment By: Michael Hudson (mwh) Date: 2005-09-30 09:44 Message: Logged In: YES user_id=6656 I'm not particularly convinced that this is a great idea. Python uses 'new' and 'class' as C identifiers which mean you can't compile it as C++ -- but Python isn't written in C++, so this is fine. Similarly, Python isn't designed to be fed to moc -- so why feed it to moc? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 21:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 21:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 21:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 17:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README
Bugs item #1306248, was opened at 2005-09-27 17:04 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-30 10:55 Message: Logged In: YES user_id=593130 Perhaps there should be a separate README64 file and a line in README "For 64 bit builds, also see README64". This would shrink README for most people while giving full system-specific details for those who need them. -- Comment By: John Stone (jestone) Date: 2005-09-29 12:41 Message: Logged In: YES user_id=48806 I understand your reluctance to add cruft to the README, but given that there's no "configure --64-bit --without-gcc" that works, I think that adding something to the docs would be helpful. There's already a history of documenting bugs/limitations of the Python build system in the README, so while I agree with your view that fixing the build system would be best, adding something to the README is a good short-term solution until the 64-bit build kinks are fixed up. I suggest adding something along the lines of what has already been done for AIX/HP-UX 64-bit builds, since those also require unusual steps. Keep it short like these?: AIX 5.3: To build a 64-bit version with IBM's compiler, I used the following: export PATH=/usr/bin:/usr/vacpp/bin ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64" make HP-UX: When using threading, you may have to add -D_REENTRANT to the OPT variable in the top-level Makefile; reported by Pat Knight, this seems to make a difference (at least for HP-UX 10.20) even though pyconfig.h defines it. This seems unnecessary when using HP/UX 11 and later - threading seems to work "out of the box". -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 12:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone <[EMAIL PROTECTED]> suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. -- Comment By: John Stone (jestone) Date: 2005-09-29 11:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use
[ python-Bugs-1309567 ] linechache module returns wrong results
Bugs item #1309567, was opened at 2005-09-30 16:57 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=1309567&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1309567 ] linechache module returns wrong results
Bugs item #1309567, was opened at 2005-09-30 16:57 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. -- >Comment By: Thomas Heller (theller) Date: 2005-09-30 17:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by jfriesne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Jeremy Friesner (jfriesne) Assigned to: Martin v. Löwis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- >Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-30 15:38 Message: Logged In: YES user_id=383828 On second thought, I believe mwh is right; most of those changes are unnecessary. (I made the changes a long time ago, so when I grepped for them the other day the memory for their motivation wasn't fresh). The Python .c files aren't fed to moc, so references to 'signals' and 'slots' in the .c files should compile okay. It's just the references to those identifiers in the Python .h files that cause a problem, if the .h files are #included in a Qt-using C++ program, after #including a Qt header. So I think probably just the original three changes are sufficient. -- Comment By: Michael Hudson (mwh) Date: 2005-09-30 08:44 Message: Logged In: YES user_id=6656 I'm not particularly convinced that this is a great idea. Python uses 'new' and 'class' as C identifiers which mean you can't compile it as C++ -- but Python isn't written in C++, so this is fine. Similarly, Python isn't designed to be fed to moc -- so why feed it to moc? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 20:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 16:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1309567 ] linechache module returns wrong results
Bugs item #1309567, was opened at 2005-09-30 10:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-30 12:24 Message: Logged In: YES user_id=6380 Radical indeed. But what about the use case of modules compiled on one system and moved to a different system? Is that use case important enough? There used to be a different use case, because bytecode files used to contain relative path names. I believe that's been fixed, if only by code in site.py that absolutizes sys.path. (Except the initial '' -- is that important?) -- Comment By: Thomas Heller (theller) Date: 2005-09-30 11:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1309676 ] Add os.path.relpath
Feature Requests item #1309676, was opened at 2005-09-30 20:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&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: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1309724 ] __getnewargs__ is in pickle docs but not in code
Bugs item #1309724, was opened at 2005-09-30 12:37
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309724&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: __getnewargs__ is in pickle docs but not in code
Initial Comment:
The pickle docs talk about __getnewargs__ for new style
classes
http://www.python.org/doc/2.3.5/lib/pickle-inst.html
But after examing pickle.py I see no ref to
__getnewargs__ in the code, nor could I get my example
code to work.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 19:57
Message:
Logged In: YES
user_id=33168
The code is buried in the C implementation of Objects. In
the doc you reference, this is the relative sentance:
New-style types can provide a __getnewargs__() method that
is used for protocol 2.
Note that last phrase about requiring protocol 2. Your
example works if you add a third parameter to pickle.dump()
with the value of 2. Version 2 is not default.
Hope this makes sense.
--
Comment By: Myers Carpenter (myers_carpenter)
Date: 2005-09-30 14:59
Message:
Logged In: YES
user_id=335935
Example code:
import pickle
class A(object):
def __new__(klass, *args):
print "__new__ %r" % (args,)
return object.__new__(klass, *args)
def __init__(self, *args):
print "__init__"
self.args = args
def __getnewargs__(self):
print "__getnewargs__"
return (self.args,)
print "object creation"
a = A("a", "b",)
print "pickle dump"
pickle.dump(a, file("pickle.gnatest", "w"))
del a
print "pickle load"
a = pickle.load(file("pickle.gnatest", "r"))
print a
Output:
object creation
__new__ ('a', 'b')
__init__
pickle dump
pickle load
<__main__.A object at 0x4022096c>
Expected:
"__getnewargs__" never printed, __new__ not called after
object load.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309724&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
