[ python-Bugs-1248658 ] dir should accept dirproxies for __dict__
Bugs item #1248658, was opened at 2005-07-31 15:21 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=1248658&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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: dir should accept dirproxies for __dict__ Initial Comment: PyObject_Dir checks if the __dict__ of an object is a dict, if not it is ignored. It should also accept dictproxies. My usecase is an object that doesn't have a real dict, but looks up attributes in another datastructure. When someone asks for the __dict__ of this object I'm dynamicly building a new dictionary. I'd like the __dict__ property to be a immutable value because changing it won't (and shouldn't) affect the underlying object. However, when I return the result of a call to PyDict_NewProxy the builtin function dir will no longer use the contents of the __dict__ attribute, which is counterproductive because supporting dict is a major usecase for supporting a __dict__ attribute in the first place! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248658 ] dir should accept dirproxies for __dict__
Bugs item #1248658, was opened at 2005-07-31 15:21 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: dir should accept dirproxies for __dict__ Initial Comment: PyObject_Dir checks if the __dict__ of an object is a dict, if not it is ignored. It should also accept dictproxies. My usecase is an object that doesn't have a real dict, but looks up attributes in another datastructure. When someone asks for the __dict__ of this object I'm dynamicly building a new dictionary. I'd like the __dict__ property to be a immutable value because changing it won't (and shouldn't) affect the underlying object. However, when I return the result of a call to PyDict_NewProxy the builtin function dir will no longer use the contents of the __dict__ attribute, which is counterproductive because supporting dict is a major usecase for supporting a __dict__ attribute in the first place! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1123727 ] gensuitemodule.processfile fails
Bugs item #1123727, was opened at 2005-02-16 08:17
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&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: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: gensuitemodule.processfile fails
Initial Comment:
gensuitemodule.processfile fails for an application as trivial as
Safari, while the same procedure works OK on version 2.3.
On version 2.3:
>>> from gensuitemodule import processfile; processfile('/
Applications/Safari.app')
[lots of dialogs]
On version 2.4, same machine:
>>> from gensuitemodule import processfile; processfile('/
Applications/Safari.app')
Traceback (most recent call last):
File "", line 1, in ?
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/plat-mac/gensuitemodule.py", line 222, in processfile
verbose=verbose)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete
creatorsignature, dummy = MacOS.GetCreatorAndType(fname)
Error: (-43, 'File not found')
I'm pretty conviced the application did not move in the 20 seconds
between those two invocations :-)
Any suggestions?
- Jurjen
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-07-31 15:33
Message:
Logged In: YES
user_id=580910
Integration with the standard library should not be considered to be the holy
grail. Libraries outside of the standard library can be developed on a faster
pace than Python itself.
I wouldn't mind if the standard libary docs mentioned appscript as a better
solution than gensuitemodule :-)
--
Comment By: has (hhas)
Date: 2005-02-25 18:20
Message:
Logged In: YES
user_id=996627
> When will appscript be incorporated into the standard libraries?
Dunno. It should be finished in the next few months. You'd need to ask
Jack what the next entry point into the standard library would be.
has
--
Comment By: Jurjen N.E. Bos (jneb)
Date: 2005-02-25 12:22
Message:
Logged In: YES
user_id=446428
Yep, you're right. On both 2.3, and 2.4, I get:
>>> import MacOS
>>> print MacOS.GetCreatorAndType('/Applications/TextEdit.app')
Traceback (most recent call last):
File "", line 1, in ?
Error: (-43, 'File not found')
When will appscript be incorporated into the standard libraries?
- Jurjen
--
Comment By: has (hhas)
Date: 2005-02-24 01:53
Message:
Logged In: YES
user_id=996627
I think the MacOS extension is broken. The gensuitemodule error you
observe on Python 2.4 is probably being masked on Python 2.3 by other
bugs that have since been cleaned up.
e.g. The following errors OMM (OS10.2.8, Python 2.3.3):
print MacOS.GetCreatorAndType('/Applications/TextEdit.app')
--> MacOS.Error: (-43, 'File not found')
Seems to work on non bundle-based applications, but not bundle-based
ones. Maybe you could check this and file a new report on the MacOS
extension if you can confirm it.
has
p.s. Note that gensuitemodule and friends are obsolete. See appscript:
http://freespace.virgin.net/hamish.sanderson/appscript.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed
Bugs item #1248997, was opened at 2005-07-31 17:04 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=1248997&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: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Martin v. Löwis (loewis) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248127 ] set of pdb breakpoint fails
Bugs item #1248127, was opened at 2005-07-30 14:29
Message generated for change (Comment added) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&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: Joseph Heled (pepster)
Assigned to: Nobody/Anonymous (nobody)
Summary: set of pdb breakpoint fails
Initial Comment:
I can't set any pdb breakpoint. I try the command,
(Pdb) break a:847
Breakpoint 4 at /home/joseph/743/rod/a.py:847
I get the message,
"pdbtrack: Traceback cue not found"
The breakpoint is never activated.
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-31 13:22
Message:
Logged In: YES
user_id=971153
This does not seem like a bug in python.
It might be a bug in emacs' python-mode..
(http://sourceforge.net/projects/python-mode/)
However, even that is not clear..
C-cC-c in emacs runs py-execute-buffer which seems to make a
copy of the current buffer and run python on that
copy...Which would obviosly impact handling of filenames
I think the mainstream way to run pdb under Emacs is the
pdb-mode. (M-x pdb)
My suggestion would be to close this bug.
--
Comment By: Joseph Heled (pepster)
Date: 2005-07-30 23:30
Message:
Logged In: YES
user_id=86677
I tried a simple example outside emacs and it worked.
Here is how it fails in emacs -
visit a python buffer
Do C-cC-c (py-execute-buffer)
run pdb.run("some code")
Try to set a breakpoint - get the "pdbtrack: Traceback cue
not found"
, and breakpoint never executed.
I am not sure if it is supposed to work or not.
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-30 17:07
Message:
Logged In: YES
user_id=971153
Could you provide an example (if possible a small one)?
There are many reasons why a breakpoint may not be reachable..
Also it seems like you are running pdb under emacs, is it
correct?
Can you reproduce the problem outside of emacs?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension
Bugs item #1248119, was opened at 2005-07-30 14:12
Message generated for change (Comment added) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&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: Joseph Heled (pepster)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'next' does not skip list comprehension
Initial Comment:
pdb next command forces you to step over each list element.
This seem to be a reincarnation of this old bug.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470
Version:
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-31 13:48
Message:
Logged In: YES
user_id=971153
> you would realize what a serious bummer this is.
I agree: this is a definite inconvenience. But I don't see
how it is different from having to step through any other
loop. However, I think there is a way to solve both problems
at once..See below
> Giving a 'next N' is nice, but will not be a real solution.
> Somethims it is not easy to know how many iterations there
> are. And when they are nested etc.
Actually, I did not mean "next N" to skip N iterations, what
I meant
to have 'next N' (or at least next 1) to skip next N lines
of code.
I.e stop only when
line>=line_where_next_N_happened+N
is reached...
So it seems like we are talking about the same thing...Right?
There are a couple of corner cases which would have to be
handled, (e.g keeping track of the current frame, etc)
Also "next N" would allow to easily skip over any loops (not
just list comprehensions), which I think would be a useful
feature...
What do you think?
--
Comment By: Joseph Heled (pepster)
Date: 2005-07-30 23:02
Message:
Logged In: YES
user_id=86677
You probably never use pdb in a real program, otherwise you
would realize what a serious bummer this is.
Giving a 'next N' is nice, but will not be a real solution.
Somethims it is not easy to know how many iterations there
are. And when they are nested etc.
If you are convinced this is the desired and reasonable
behaviour for next (a point of view I don't share), at least
have a different command to skip to the next line. I am
sorry but I have no idea if this is easy or hard.
Thanks, Joseph
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-30 20:20
Message:
Logged In: YES
user_id=971153
While this behaviour indeed feels like a bug I'm starting to
think that it is not..
Observation1: 'step' should stop at every iteration of a
list comprehension
Observation2: the only difference between 'step' and 'next'
is that 'step' steps into function calls (which is not the
case here)
So, it seems like 'next' should also stop at every iteration
of a list comprehenstion. Ie current behaviour is not a bug...
Would supporting a numeric argument for the 'next' command
make sense?
So that 'next 1' would mean "stop when actual line number
increases by at least 1"...
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-30 17:59
Message:
Logged In: YES
user_id=971153
A bit more information. I looked into what happens in
ceval.c and apparently the current behaviour is intentional..
Looks like this piece of code:
else if (frame->f_lasti <= *instr_prev) {
/* jumping back in the same line forces a trace event */
result = call_trace(func, obj, frame,
PyTrace_LINE, Py_None);
}
in maybe_call_line_trace() is responsible for the extra
"line" events..
Seems like this piece of code was added to fix bug #765624.
in ceval.c:2.386
So, should this (1248119) bug be dealt with by skipping
extra line events in bdb?
Any thoughts? Or am I totally lost?
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-30 17:33
Message:
Logged In: YES
user_id=971153
I changed bdb.py to print the kind of event it receives as
well as as line numbers and here is a session which
illustrates the bug...
bagira:~/python/dist/src/bug-next1248119> cat t
#../python
y=[1,2,3,4]
x=[ i+1 for i in y]
print x
bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t
event: call; line 1, file
event: line; line 1, file
event: call; line 2, file t
event: line; line 2, file t
> /home/ilya/python/dist/src/bug-next1248119/t(2)?()
-> y=[1,2,3,4]
(Pdb) n
event: line; l
[ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension
Bugs item #1248119, was opened at 2005-07-31 09:12
Message generated for change (Comment added) made by pepster
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&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: Joseph Heled (pepster)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'next' does not skip list comprehension
Initial Comment:
pdb next command forces you to step over each list element.
This seem to be a reincarnation of this old bug.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470
Version:
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
--
>Comment By: Joseph Heled (pepster)
Date: 2005-08-01 14:25
Message:
Logged In: YES
user_id=86677
I think this will be wonderfull
The only viable workaround now is to wrap the code in a
temporary function (i.e. lambda : ...). ugly.
-Thanks, JOseph
--
Comment By: Ilya Sandler (isandler)
Date: 2005-08-01 08:48
Message:
Logged In: YES
user_id=971153
> you would realize what a serious bummer this is.
I agree: this is a definite inconvenience. But I don't see
how it is different from having to step through any other
loop. However, I think there is a way to solve both problems
at once..See below
> Giving a 'next N' is nice, but will not be a real solution.
> Somethims it is not easy to know how many iterations there
> are. And when they are nested etc.
Actually, I did not mean "next N" to skip N iterations, what
I meant
to have 'next N' (or at least next 1) to skip next N lines
of code.
I.e stop only when
line>=line_where_next_N_happened+N
is reached...
So it seems like we are talking about the same thing...Right?
There are a couple of corner cases which would have to be
handled, (e.g keeping track of the current frame, etc)
Also "next N" would allow to easily skip over any loops (not
just list comprehensions), which I think would be a useful
feature...
What do you think?
--
Comment By: Joseph Heled (pepster)
Date: 2005-07-31 18:02
Message:
Logged In: YES
user_id=86677
You probably never use pdb in a real program, otherwise you
would realize what a serious bummer this is.
Giving a 'next N' is nice, but will not be a real solution.
Somethims it is not easy to know how many iterations there
are. And when they are nested etc.
If you are convinced this is the desired and reasonable
behaviour for next (a point of view I don't share), at least
have a different command to skip to the next line. I am
sorry but I have no idea if this is easy or hard.
Thanks, Joseph
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-31 15:20
Message:
Logged In: YES
user_id=971153
While this behaviour indeed feels like a bug I'm starting to
think that it is not..
Observation1: 'step' should stop at every iteration of a
list comprehension
Observation2: the only difference between 'step' and 'next'
is that 'step' steps into function calls (which is not the
case here)
So, it seems like 'next' should also stop at every iteration
of a list comprehenstion. Ie current behaviour is not a bug...
Would supporting a numeric argument for the 'next' command
make sense?
So that 'next 1' would mean "stop when actual line number
increases by at least 1"...
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-31 12:59
Message:
Logged In: YES
user_id=971153
A bit more information. I looked into what happens in
ceval.c and apparently the current behaviour is intentional..
Looks like this piece of code:
else if (frame->f_lasti <= *instr_prev) {
/* jumping back in the same line forces a trace event */
result = call_trace(func, obj, frame,
PyTrace_LINE, Py_None);
}
in maybe_call_line_trace() is responsible for the extra
"line" events..
Seems like this piece of code was added to fix bug #765624.
in ceval.c:2.386
So, should this (1248119) bug be dealt with by skipping
extra line events in bdb?
Any thoughts? Or am I totally lost?
--
Comment By: Ilya Sandler (isandler)
Date: 2005-07-31 12:33
Message:
Logged In: YES
user_id=971153
I changed bdb.py to print the kind of event it receives as
well as as line numbers and here is a session which
illustrates the bug...
bagira:~/python/dist/src/bug-next1248119> ca
