[ python-Bugs-1658959 ] os.wait child process fail when under stress
Bugs item #1658959, was opened at 2007-02-13 14:44 Message generated for change (Comment added) made by thegroff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.6 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: The Groff (thegroff) Assigned to: Nobody/Anonymous (nobody) Summary: os.wait child process fail when under stress Initial Comment: when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work. -- >Comment By: The Groff (thegroff) Date: 2007-02-26 09:23 Message: Logged In: YES user_id=770948 Originator: YES We were using linux kernel 2.4.21-37. I can then be a bug in the os. I'll try to look deeper into it. Thanks -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 23:19 Message: Logged In: YES user_id=33168 Originator: NO Note that on some versions of Linux 2.4, calling wait() can return ECHILD even when there is a child. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 16:57 Message: Logged In: YES user_id=21627 Originator: NO What operating system are you using? Why do you think this is a bug in Python and not in your operating system? Are you sure there are any unwaited-for children when ECHILD is returned? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Armin Rigo (arigo) Date: 2007-02-26 08:23 Message: Logged In: YES user_id=4771 Originator: YES 456? Now that's interesting. Not 579? I'm not sure if I ever thought about what the expected answer should be, but I'd say that you are correct: 'x.__dict__' should be empty in the end. Actually I don't really see how it manages *not* to be empty in IronPython; looks like either a very minor detail or a deeper bug... -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:36 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:23 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:05 Message: Logged In: YES user_id=4771 Well, try making an "empty" class Foo(object): pass, and see what magically shows up in Foo.__dict__.keys(). Here is the __dict__ descriptor used for instances of Foo. This descriptor is connected to subtype_dict() and subtype_setdict() in typeobject.c. INCREF/DECREFs are in theory missing around every use of the dictionary returned by _PyObject_GetDictPtr(), because more or less any such use could remove the dict from the object from which _PyObject_GetDictPtr() returned from, and so decref the dict - while it's used. This might require some timing, to check the performance impact. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 01:14 Message: Logged In: YES user_id=357491 OK, then I am going to need a little guidance to dive into this more since this is going into some murky waters for me. =) For the normal, non-evil case of an empty Python class (``class Foo(object): pass``), I would think that accessing __dict__ would fall through to the tp_getset for object, and then fall to the same slot for type. Now that is obviously not happening since you get a straight dict back for that attribute access and not a dict proxy as would be suggested based on my logic listed above. So, my question is, where is the code that handles fetching Foo().__dict__? And if you have an inkling of where I should be looking in terms of possible refcounting additions that would be great as well. -- Comment By: Armin Rigo (arigo) Date: 2006-06-29 21:19 Message: Logged In: YES user_id=4771 Brett: I think you're approaching the problem from the wrong angle. The problem is being allowed to freely tamper with the dict stored in objects. Getting NULL errors here and there is only a symptom. As I explain, the '__dict__' descriptor object needs to do some more checks, and to be fully safe some Py_INCREF/Py_DECREF are needed in some critical places. -- Comment By: Brett Cannon (bcannon) Date:
[ python-Bugs-1068268 ] subprocess is not EINTR-safe
Bugs item #1068268, was opened at 2004-11-17 22:07 Message generated for change (Comment added) made by mpitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&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: 3 Private: No Submitted By: Peter Åstrand (astrand) Assigned to: Peter Åstrand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. -- Comment By: Martin Pitt (mpitt) Date: 2007-02-26 13:15 Message: Logged In: YES user_id=80975 Originator: NO I just got two different Ubuntu bug reports about this problem as well, and I'm unsure how to circumvent this at the application level. http://librarian.launchpad.net/6514580/Traceback.txt http://librarian.launchpad.net/6527195/Traceback.txt (from https://launchpad.net/bugs/87292 and its duplicate) -- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-22 08:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R -- Comment By: Peter Åstrand (astrand) Date: 2004-11-17 22:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669182 ] PyErr_WriteUnraisable lacks exception type check
Bugs item #1669182, was opened at 2007-02-26 12:00 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=1669182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Becedillas (gbeced) Assigned to: Nobody/Anonymous (nobody) Summary: PyErr_WriteUnraisable lacks exception type check Initial Comment: I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. I'd hit the bug embedding Python 2.5 and raising a string instance via PyThreadState_SetAsyncExc but I could also reproduce the crash with this sample code: class Foo: def __del__(self): raise "pum" a = Foo() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Mattias Engdeg�rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
>Comment By: Mattias Engdeg�rd (yorick)
Date: 2007-02-26 16:28
Message:
Logged In: YES
user_id=432579
Originator: YES
That is quite correct; standard Scheme does not have the ability to eval
expressions in a lexical environment. There are of course good performance
reasons for that (we don't want to keep all lexical environments around in
symbolic form, just in case someone would EVAL an expression referring to a
name inside one of them).
It would be fine for Python to have a similar rule, but now it's just
weirdly inconsistent.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 17:22
Message:
Logged In: YES
user_id=31392
Originator: NO
I guess I should get back to this bug report at least once a year. I'm
trying to understand how Scheme handles eval. If I look at R5RS or R6RS, I
see that the eval procedure takes an environment as an argument. The
procedures that create environment all seem to create variants of the
top-level environment (an empty environment, the interactive environment,
etc.). I don't see any way to create an environment that contains the
bindings visible in a particular region of code. Am I missing something?
--
Comment By: Mattias Engdeg�rd (yorick)
Date: 2006-04-03 19:36
Message:
Logged In: YES
user_id=432579
Lest my last comment be interpreted as overly arrogant,
please be assured that it was not meant as anything other
than an explanation of why I reported this as a bug in the
first place. I do understand that Python works the way it
does; I just want it to be even better. :-)
--
Comment By: Mattias Engdeg�rd (yorick)
Date: 2006-04-03 19:12
Message:
Logged In: YES
user_id=432579
>The source of the problem is that scoping decisions are made
>statically.
No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:
Q: In what environment is the eval() argument evaluated?
typically in one of three ways:
A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.
Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.
Observe that none of the answers depend on what the
expression looks like.
Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions
1) x
and
2) lambda: x
should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.
In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.
Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:
A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing varia
[ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs
Bugs item #1669304, was opened at 2007-02-26 10:26 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=1669304&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PyMem_Realloc and PyMem_Resize docs Initial Comment: This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs
Bugs item #1669304, was opened at 2007-02-26 10:26 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PyMem_Realloc and PyMem_Resize docs Initial Comment: This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails. -- >Comment By: Steven Bethard (bediviere) Date: 2007-02-26 10:26 Message: Logged In: YES user_id=945502 Originator: YES File Added: pymem_realloc.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1665333 ] Documentation missing for OptionGroup class in optparse
Bugs item #1665333, was opened at 2007-02-21 08:40 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&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 Private: No Submitted By: LunarYorn (lunar_yorn) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation missing for OptionGroup class in optparse Initial Comment: Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul. In detail documentation of the following classes and methods in optparse is missing: - OptionGroup - OptionParser.add_option_group - OptionParser.get_option_group These classes and methods also lack docstrings. I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug. -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 10:37 Message: Logged In: YES user_id=945502 Originator: NO The docstrings need to be modified in the Optik package (from which the stdlib optparse module is derived). I've filed you an appropriate patch there: http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097. I'll see what I can do about adding some documentation. My preference is only to document OptionParser.add_option_group -- I think making the OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc. APIs public was). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1665333 ] Documentation missing for OptionGroup class in optparse
Bugs item #1665333, was opened at 2007-02-21 08:40 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&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 Private: No Submitted By: LunarYorn (lunar_yorn) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation missing for OptionGroup class in optparse Initial Comment: Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul. In detail documentation of the following classes and methods in optparse is missing: - OptionGroup - OptionParser.add_option_group - OptionParser.get_option_group These classes and methods also lack docstrings. I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug. -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 10:39 Message: Logged In: YES user_id=945502 Originator: NO Looks like the optparse docs are also auto-generated from optik. Here's the first line of liboptparse.tex: % THIS FILE IS AUTO-GENERATED! DO NOT EDIT! So I guess this needs to be handled in the optparse bugs. -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 10:37 Message: Logged In: YES user_id=945502 Originator: NO The docstrings need to be modified in the Optik package (from which the stdlib optparse module is derived). I've filed you an appropriate patch there: http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097. I'll see what I can do about adding some documentation. My preference is only to document OptionParser.add_option_group -- I think making the OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc. APIs public was). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1665333 ] Documentation missing for OptionGroup class in optparse
Bugs item #1665333, was opened at 2007-02-21 16:40 Message generated for change (Comment added) made by lunar_yorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&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 Private: No Submitted By: LunarYorn (lunar_yorn) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation missing for OptionGroup class in optparse Initial Comment: Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul. In detail documentation of the following classes and methods in optparse is missing: - OptionGroup - OptionParser.add_option_group - OptionParser.get_option_group These classes and methods also lack docstrings. I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug. -- >Comment By: LunarYorn (lunar_yorn) Date: 2007-02-26 18:45 Message: Logged In: YES user_id=1485244 Originator: YES Thanks for filing the patch there! I didn't know, that optparse is developt outside of Python... Anyway I think you're right not to comment the whole api. I did not intend that. I would be content with a little note in the docs quickly explains OptionGroups and how to create them. More shouldn't be told, since they are only useful for formatting help output. I just needed such a thing for my recent project and was short of overwriting the OptionParser and HelpFormatter classes. For that purpose I looked into the sources, where I found the OptionGroup capabilities. A little note would have shortened the development of the option parsing code quite a bit... ;) -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 18:39 Message: Logged In: YES user_id=945502 Originator: NO Looks like the optparse docs are also auto-generated from optik. Here's the first line of liboptparse.tex: % THIS FILE IS AUTO-GENERATED! DO NOT EDIT! So I guess this needs to be handled in the optparse bugs. -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 18:37 Message: Logged In: YES user_id=945502 Originator: NO The docstrings need to be modified in the Optik package (from which the stdlib optparse module is derived). I've filed you an appropriate patch there: http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097. I'll see what I can do about adding some documentation. My preference is only to document OptionParser.add_option_group -- I think making the OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc. APIs public was). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669331 ] document that shutil.copyfileobj does not seek()
Bugs item #1669331, was opened at 2007-02-26 10: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=1669331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: document that shutil.copyfileobj does not seek() Initial Comment: This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669331 ] document that shutil.copyfileobj does not seek()
Bugs item #1669331, was opened at 2007-02-26 10:53 Message generated for change (Settings changed) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: document that shutil.copyfileobj does not seek() Initial Comment: This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669349 ] make install fails if no previous Python installation
Bugs item #1669349, was opened at 2007-02-26 19:22
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=1669349&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias S. Benkmann (mbenkmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails if no previous Python installation
Initial Comment:
When installing Python 2.5 on a completely Python-less system 'make install'
failed. The error that caused the failure was
Compiling /usr/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata
module)",)
[snip]
Compiling /usr/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1
'find -name unicodedata.so' showed me that the library did not exist in the
build tree. However, after a 'make -i install' to force make to continue
despite the error, unicodedata.so was there. So apparently the library is not
built until a later stage of make install. And indeed, subsequent 'make
install' calls without -i were successful.
It is important to note that if you have a previous Python installation (at
least of the same version), 'make install' will go through, because it'll load
the library from there. So if you want to reproduce the issue you will have to
install from a freshly unpacked tarball on a system with no Python installation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-26 18:41
Message:
Logged In: YES
user_id=31392
Originator: NO
Fixed in rev. 53954. Not sure if this should be backported.
--
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:23
Message:
Logged In: YES
user_id=366566
Originator: NO
Ahem.
Code coverage tools run afoul of this bug as well. A common case is to
run coverage tools using a test suite. If this bug is triggered, then the
resulting coverage data isn't valid.
--
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:21
Message:
Logged In: YES
user_id=366566
Originator: NO
Code coverage tools run afoul
--
Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:53
Message:
Logged In: YES
user_id=22785
This could & probably should be fixed, at the cost of making
the core debugger support more complicated. The current
version of TurboGears has code that triggers the same bug.
That said, I don't have a patch to fix the core...
--
Comment By: applebucks (scott_marks)
Date: 2006-10-08 23:54
Message:
Logged In: YES
user_id=120857
I didn't say Python is lame. I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it. That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.
Not to mention it makes my debugging tough. :)
More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 16:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
--
Comment By: applebucks (scott_marks)
Date: 2006-10-04 02:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and als
[ python-Bugs-810714 ] nested variables in 'class:' statements
Bugs item #810714, was opened at 2003-09-22 17:05 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: nested variables in 'class:' statements Initial Comment: from the user's point of view, variables originating from nested scopes could erratically become bound in the 'class' statement. The 'class:' statements works by capturing all locals() after executing the body; however, this is not exactly the same as what an explicit call to locals() would return because of the missing PyFrame_FastToLocals() call in the implementation of LOAD_LOCALS in ceval.c. It was thought that PyFrame_FastToLocals() was unnecessary at that point because the class body bytecode only uses LOAD_NAME/STORE_NAME and not fast locals -- but this is no longer true with nested scopes. See attached examples. -- >Comment By: Jeremy Hylton (jhylton) Date: 2007-02-26 18:45 Message: Logged In: YES user_id=31392 Originator: NO Committed revision 53954. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:36 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:35 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Armin Rigo (arigo) Date: 2004-01-08 17:13 Message: Logged In: YES user_id=4771 Attached is a draft. I am not sure that I understand all the implications of nested variables in the presence of class bodies, so please don't check in this patch. -- Comment By: Armin Rigo (arigo) Date: 2003-09-24 12:47 Message: Logged In: YES user_id=4771 I'm not sure how to solve this. I could make a patch to LOAD_LOCALS to prevent free variables from showing up in the class.__dict__. For the 2nd problem I'm not familiar enough with compile.c to know how to make the binding 'b="foo"' sufficient to prevent 'b' from also being considered free in the class definition (which is what occurs). Note also that bare 'exec' statements should then be forbidden in class definitions in the presence of free variables, for the same reason as it is forbidden in functions: you cannot tell whether a variable is free or local. As an example of this, if in the attached example we replace b="foo" with exec 'b="foo"' then the last print correctly outputs 'foo' instead of 6 but what actually occurs is that the value of the argument b in f(a,b) was modified by the class definition -- it is a way to change the binding of a variable in an enclosing frame, which should not be possible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 19:16 Message: Logged In: YES user_id=80475 Do you have a proposed patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669498, was opened at 2007-02-26 15: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=1669498&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
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669182 ] PyErr_WriteUnraisable lacks exception type check
Bugs item #1669182, was opened at 2007-02-26 07:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Gabriel Becedillas (gbeced) >Assigned to: Neal Norwitz (nnorwitz) Summary: PyErr_WriteUnraisable lacks exception type check Initial Comment: I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. I'd hit the bug embedding Python 2.5 and raising a string instance via PyThreadState_SetAsyncExc but I could also reproduce the crash with this sample code: class Foo: def __del__(self): raise "pum" a = Foo() -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-26 15:50 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. The print is kinda crappy, but it shouldn't crash. Committed revision 53974. (2.5) Committed revision 53975. (2.6) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669578 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669578, was opened at 2007-02-26 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=1669578&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
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Bugs item #1669637, was opened at 2007-02-27 12:14 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=1669637&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Some Compiler Warnings on VC6 Initial Comment: I got some warnings on VC6. Probably these are not so problematic, but anyway I reported. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined. ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield' E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Bugs item #1669637, was opened at 2007-02-27 12:14 Message generated for change (Settings changed) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None >Priority: 2 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Some Compiler Warnings on VC6 Initial Comment: I got some warnings on VC6. Probably these are not so problematic, but anyway I reported. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined. ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield' E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669646 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669646, was opened at 2007-02-26 20:28
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=1669646&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
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669646 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669646, was opened at 2007-02-26 19:28
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&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: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 21:41
Message:
Logged In: YES
user_id=33168
Originator: NO
Dupe of 1669498.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669578 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669578, was opened at 2007-02-26 15:57
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&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: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 21:42
Message:
Logged In: YES
user_id=33168
Originator: NO
Dupe of 1669498.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-810714 ] nested variables in 'class:' statements
Bugs item #810714, was opened at 2003-09-22 17:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: nested variables in 'class:' statements Initial Comment: from the user's point of view, variables originating from nested scopes could erratically become bound in the 'class' statement. The 'class:' statements works by capturing all locals() after executing the body; however, this is not exactly the same as what an explicit call to locals() would return because of the missing PyFrame_FastToLocals() call in the implementation of LOAD_LOCALS in ceval.c. It was thought that PyFrame_FastToLocals() was unnecessary at that point because the class body bytecode only uses LOAD_NAME/STORE_NAME and not fast locals -- but this is no longer true with nested scopes. See attached examples. -- >Comment By: Armin Rigo (arigo) Date: 2007-02-27 07:23 Message: Logged In: YES user_id=4771 Originator: YES Jeremy, you inserted many spaces instead of tabs in frameobject.c. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-26 18:45 Message: Logged In: YES user_id=31392 Originator: NO Committed revision 53954. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:36 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:35 Message: Logged In: YES user_id=31392 Originator: NO I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. -- Comment By: Armin Rigo (arigo) Date: 2004-01-08 17:13 Message: Logged In: YES user_id=4771 Attached is a draft. I am not sure that I understand all the implications of nested variables in the presence of class bodies, so please don't check in this patch. -- Comment By: Armin Rigo (arigo) Date: 2003-09-24 12:47 Message: Logged In: YES user_id=4771 I'm not sure how to solve this. I could make a patch to LOAD_LOCALS to prevent free variables from showing up in the class.__dict__. For the 2nd problem I'm not familiar enough with compile.c to know how to make the binding 'b="foo"' sufficient to prevent 'b' from also being considered free in the class definition (which is what occurs). Note also that bare 'exec' statements should then be forbidden in class definitions in the presence of free variables, for the same reason as it is forbidden in functions: you cannot tell whether a variable is free or local. As an example of this, if in the attached example we replace b="foo" with exec 'b="foo"' then the last print correctly outputs 'foo' instead of 6 but what actually occurs is that the value of the argument b in f(a,b) was modified by the class definition -- it is a way to change the binding of a variable in an enclosing frame, which should not be possible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 19:16 Message: Logged In: YES user_id=80475 Do you have a proposed patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=
[ python-Bugs-1669743 ] Python needs a way to detect implementation
Bugs item #1669743, was opened at 2007-02-27 08: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=1669743&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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
