Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I don't know what this Microsoft compiler is doing but both ostypeCount
and ostypeList are properly set at Tcl_ListObjGetElements, and if that
call fails it skips to the bottom of this function yo
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
If this needs approval of someone else, and such thing doesn't happen in
time then the earlier patch should be reverted.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
or not ? the indentation in this tkFileFilter.c is fooling me, the
Tcl_ListObjGetElements call is done in another block which is outside
that check, so the compiler seems to be right after all. It would be
good to report this problem a
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Well, beta3 was released and the problem remained there.
Robert, I believe MvL assigned this to you for a reason.. I'm a bit
stressed but what I'm trying to say is that you could have decided about
this issue yourself and you
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
keywords: +needs review -patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
keywords: +needs review -patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3573>
___
New submission from Guilherme Polo <[EMAIL PROTECTED]>:
Chooser._fixresult in the tkColorChooser module uses "if not result" to
check if user canceled the dialog, but nowadays Tk may return a cached
object that contains the result we are after, so, this object will not
simply e
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Can someone review the patch and apply please ? It is sad to leave
tkinter like this in py3k. Clearly there are not much people using it
there, but it is something very simple to fix.
--
keywords: +needs
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Committed r66215
I've applied this only in py3k since it doesn't affect python 2.6
--
resolution: accepted -> fixed
status: open -> closed
versions: -Python 2.6
___
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Python 2.6b2 was released with this bug, and got fixed later.
--
resolution: -> out of date
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I meant beta3, sorry.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3774>
___
__
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Oops, sorry, I misread the bug report, reopening it (let me go eat
something now).
--
keywords: -easy, needs review
resolution: out of date ->
status: closed -> open
___
Python tra
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
keywords: +easy, needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3774>
___
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
The patch attached is probably the most direct way to fix it, but, can
someone remind why we just don't call deletecommand (if there is a
command to delete) and let it try to remove the command from _tclCommand
then ? (note that
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Again, I meant the previously attached patch (the one by ocean-city) was
the most direct way.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
My patch already does what is proposed in your patch, except yours may
possibly not work. It is not guaranteed that "self.entrycget(i,
'command')" will return an empty string if the command associated to
that men
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
This "needcleanup" parameter indicates that the function added to
_tclCommands needs to (and will) be removed later. Nevertheless, I
believe the proper initialization of _tclCommands should be done elsewhere.
And about that
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Where is the test case ?
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
New patch, this one fixes the docstring previously mentioned and may set
_tclCommands to an empty list at BaseWidget.__init__
Added file: http://bugs.python.org/file11479/issue3774_2.diff
___
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I don't think I can reproduce this under Linux with the idlelib in
python-trunk.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
This bug was fixed after b3 was released (r65971). You should retry it
using python 2.6rc1 or update your sources for py3k.
--
nosy: +gpolo
resolution: -> out of date
status: open
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Did you mean "(event.state & 10) != 0" instead of "(event.state & 1) !=
0" ? Otherwise it won't work when event.state is 8.
I'm attaching a patch that does the same thing that is done on py3k
b
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Duplicate of issue3391
--
nosy: +gpolo
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I've just found some discussion about the problem here:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/577df9cfa39e6688/49484ac512f13693?lnk=gst&q=shift+backspace#49484ac512f13693
Hope this is enough to c
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Looks fine to me.
But I can't see the reason to keep this as a module function in python
2.6 so I would remove it there too.
--
nosy: +gpolo
___
Python tracker <[EMAIL PRO
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
title: tkinter.mainloop() is meanling less and crash: remove it ->
tkinter.mainloop() is meaningless and crash: remove it
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Can you check if it is not the itimer tests that are causing that ? I'm
interested in gathering some more info about the problem and hopefully
fixing it now. Take a look into issue2240 and verify if it is related to
your prob
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Uhm, is it caused only by the combination of tk 8.5.4 and py3k, or does
the same happen with tk 8.5.4 and python-trunk ? What about tk 8.5.3 (or
some other of tk 8.5 series) or even tk 8.4.16 and {python-trunk, py3k} ?
It would be g
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
The people in the nose list will receive emails each time a message is
sent to the issue.
Now back to your new problem.. the new problem you are reporting here
has been discussed at http://bugs.python.org/issue3628 (where you will
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
The problem is actually on Tkinter side, not really tcl/tk fault here.
Tkinter should be formatting that text option as "{text here}" when the
value contains one or more spaces (it is actually fine to use this tcl
formatting w
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1222721>
___
__
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1160383>
___
__
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue775309>
___
__
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1581476>
___
__
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
This was fixed in r38525
--
nosy: +gpolo
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
My bad, r39219 is the one.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1257772>
___
_
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I don't see the bug here. items in a Canvas may be named either as id or
as a tag. If you specify items by something that is actually accepted as
an integer ("123" for instance) then it is assumed to refer to a single
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Uhm, now I see.. Tkinter already formats it correctly, and you shouldn't
be using itemconfigure for this task. If you try it directly in tk, like
this:
canvas .c
.c create text 0 0 -text {a b}
.c itemconfigure 1 -text
Yo
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
tkButtonDown and co. are long gone, you shouldn't be relying on them. If
you get tk sources, you will see that tkButtonDown is called when you do
btn.event_generate('<1>').
The best thing to do here is actually rem
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Just reproduced the issue under python-trunk with tcl/tk 8.5.4 and 8.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
But it happens only if you don't build tcl/tk with --enable-threads =)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
If you remove the widget.config calls in GUI.ready you will notice the
problem "goes away", but note that this method is called from another
thread while you have a non-thread-safe tcl/tk lib (I'm assuming you
didn'
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
The patch attached checks for that when an interpreter is created, not
really at import time but should be enough.
But my real concern is that tkinter thinks it will work properly when
Python is using threads and Tcl wasn't co
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
--
priority: -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3835>
___
___
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Looks fine, doesn't break anything in Tkinter either.
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3851>
___
___
Python-bugs-list mailing list
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11483/issue_3851.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
The first part was already mentioned in issue3391, but not closing this
in favor of the second part of your message.
--
nosy: +gpolo
___
Python tracker <[EMAIL PROTECTED]>
<http://
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
When you say "interprocess signal test" do you actually mean ItimerTest
? Because I don't see the former failing, and the later hangs because
signals are not being delivered to it (SIGV
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Last time I checked many more would cause ItimerTest to not run
properly, these were: test_asynchat, test_asyncore, test_decimal,
text_docxmlrpc, test_ftplib, test_logging, test_poplib, test_queue,
test_smtplib, test_socket and all
New submission from Guilherme Polo <[EMAIL PROTECTED]>:
I see the comment in Include/pystate.h got fixed, but this other in
Docs/c-api/init.rst didn't
--
files: PyGILState_Acquire=>PyGILState_Ensure.diff
keywords: patch
messages: 74651
nosy: gpolo
severity: normal
stat
Guilherme Polo added the comment:
> Martin v. Löwis added the comment:
>
> I can reproduce the problem. The root cause is that the "event generate .nb
> " simply does not have any effect - neither through Python, nor
> through directly wish. Nor do any of the other k
Guilherme Polo added the comment:
When I run that alone I get the same effect, maybe there is something
else contributing to the previous result I saw.
focus_force did solve when testing it alone, and I think it is ok to
use focus_force when testing at least.
Here is the sample I tried
Changes by Guilherme Polo :
Removed file: http://bugs.python.org/file16818/p1.diff
___
Python tracker
<http://bugs.python.org/issue8204>
___
___
Python-bugs-list mailin
Guilherme Polo added the comment:
To make the situation worse, this Ubuntu buildbot passed all signal tests on
the next run.
--
___
Python tracker
<http://bugs.python.org/issue8
Guilherme Polo added the comment:
Wasn't the freebsd problem unrelated to this ?
--
___
Python tracker
<http://bugs.python.org/issue8424>
___
___
Pytho
Guilherme Polo added the comment:
Weird.. I was almost sure that was fixed at some point.
The patch is fine, but I would suggest adding some simple testcase(s).
This will probably require a new file (test_canvas.py) at
Lib/tkinter/test/test_tkinter
New submission from Guilherme Polo:
Wouldn't it be useful to add a "key" argument to some heapq functions ?
So you could construct a heap from dict items list based on the second
item of each tuple, for example.
--
components: Library (Lib)
messages: 61496
nosy: gpolo
s
Changes by Guilherme Polo:
--
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1883>
__
___
Python-bugs-list mailing list
Uns
Changes by Guilherme Polo:
--
type: behavior ->
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1883>
__
___
Python-bugs-list mailing list
Uns
Guilherme Polo added the comment:
Adding a simple patch that adds the "key" argument. To test this you
need to comment lines where it tries to import the C version of heapq.
Added file: http://bugs.python.org/file9260/heapq_key.py.patch
__
Track
Guilherme Polo added the comment:
Is this wanted at all ?
After checking
http://www.python.org/dev/summary/2006-06-01_2006-06-15/#inspect-isgenerator
that points to:
http://mail.python.org/pipermail/python-dev/2006-May/065334.html
http://mail.python.org/pipermail/python-dev/2006-June/065508
Guilherme Polo added the comment:
Isn't this fixed on trunk already ? Shouldn't this be marked as closed ?
--
nosy: +gpolo
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Guilherme Polo added the comment:
cgitb just creates a html document with a traceback, it doesn't send it
over network. I would like to take a look at this, but before it would
be good to know if the author of this bug found some other place that
this issue applies.
--
nosy: +
Guilherme Polo added the comment:
I tried Frederik's solution against trunk and it works. I compiled
python with ucs2 so it is surely setting SRE_CODE to unsigned long.
Before this change I got the same exception as pointed by Guido Ostkamp.
--
nosy: +
Guilherme Polo added the comment:
Maybe there should be two new functions then ? isgeneratorfunction and
isgenerator.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guilherme Polo added the comment:
I am attaching a patch that address this issue.
--
nosy: +gpolo
Added file: http://bugs.python.org/file9384/inspect.py.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Guilherme Polo added the comment:
I'm attaching a patch, it adds two new functions and removes some
constants defined in the code that can be retrieved from compiler.consts
Added file: http://bugs.python.org/file9380/inspect.py.diff
__
Tracker <[EMAIL P
Guilherme Polo added the comment:
Adding a patch that fixes inspect test and doc.
Added file: http://bugs.python.org/file9381/inspect_doc_and_test.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guilherme Polo added the comment:
I don't see the point of lines below that comment "# Scripts don't get
the current directory in their path by default.". I'm adding a patch
that removes those lines and makes use of pathdirs function instead of
using sys.path in serve fu
Guilherme Polo added the comment:
I'm attaching a patch. Is there some hidden problem that it may cause ?
By the way, this issue is a duplicate of http://bugs.python.org/issue993580
--
nosy: +gpolo
Added file: http://bugs.python.org/file9382/inspect.py
Guilherme Polo added the comment:
Have you read
http://docs.python.org/lib/optparse-standard-option-actions.html ?
If yes, what is the problem with store_true/store_false ?
--
nosy: +gpolo
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Guilherme Polo:
function generate_tokes at tokenize.py yields token OP (51) for colon,
while it should be token COLON (11). It probably affects other python
versions as well.
I'm attaching a minor sample that demonstrates this, running it returns
the following output:
Guilherme Polo added the comment:
I'm attaching a patch that solves this and updates tests.
Added file: http://bugs.python.org/file9459/tokenize_r60884.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guilherme Polo added the comment:
I believe it should say "STORE_FAST or STORE_GLOBAL" instead.
--
nosy: +gpolo
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
New submission from Guilherme Polo:
Right now Python misses a wrapper for setitimer and getitimer and I
believe it would be interesting to include them. I'm (almost) sure some
other people may find it useful too.
I'm attaching a standalone module, but if it gets to be included in
Guilherme Polo added the comment:
I forgot to remove an unwanted comment from it =)
Attaching new version.
Added file: http://bugs.python.org/file9611/py-itimer-0.1.2.tar.gz
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guilherme Polo added the comment:
Martin, thanks for supporting the idea.
I'm attaching a patch. It is against rev 61255, py3k branch.
It patches configure, configure.in, Modules/signalmodule.c and pyconfig.h.in
I wasn't sure if I should attach a diff for each file, so they are all
Guilherme Polo added the comment:
I noticed that I forgot to change setitimer and getitimer functions from
itimer_setitimer to signal_setitimer (same for getitimer).
I'm attaching a patch that should be applied after the previous one to
do this renaming.
Added file:
http://bugs.pytho
Guilherme Polo added the comment:
Thanks for the review, corrections and suggestions Georg.
For the first three items: I will be working on this later today.
For the last item: "which" is one of those three new constants added. I
believe if you pass something else setitimer/getit
Guilherme Polo added the comment:
I'm attaching another patch, this should be applied after the other ones
have been applied. It fixes what Georg mentioned.
I have chosen to let ItimerError inherit from IOError, and improved the
docstring of setitimer.
Added file:
http://bugs.pytho
Guilherme Polo added the comment:
Updated Doc/library/signal.rst, follows a patch.
Added file: http://bugs.python.org/file9620/setitimer_getitimer_wrapper_doc.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Guilherme Polo:
Added file:
http://bugs.python.org/file9622/setitimer_getitimer_wrapper_doc_update.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guilherme Polo added the comment:
I've done some tests for getitimer/setitimer, diff is attached.
Added file:
http://bugs.python.org/file9623/setitimer_getitimer_wrapper_test.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guilherme Polo added the comment:
I'm attaching a patch that fixes this, it was done for rev 61179 (trunk).
Note that is_cgi method is incorrectly documented, even more now. Only
the first line in its docstring is correct now, before this patch, last
paragraph was correc
Guilherme Polo added the comment:
oops, I was doing some tests in the last patch and left a bug in it. I'm
attaching a new one.
Added file: http://bugs.python.org/file9629/CGIHTTPServer_is_cgi_fix2.diff
__
Tracker <[EMAIL PROTECTED]>
<http://b
Guilherme Polo added the comment:
This corrects is_cgi docstring (maybe this should be done in a new
issue?). It also removes a part of it that I believe to not be
necessary, someone correct me if I'm wrong.
Added file: http://bugs.python.org/file9632/CGIHTTPServer_is_cgi_doc_fix
Guilherme Polo added the comment:
Complete patch attached
Added file: http://bugs.python.org/file9636/setitimer_getitimer.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guilherme Polo added the comment:
If you are going to backport it to 2.6, then the C wrapper should be
adapted to match Python 2.x C coding style. If the other parts don't
apply correctly, then you should update it aswell.
__
Tracker <[EMAIL PROTECTED
New submission from Guilherme Polo <[EMAIL PROTECTED]>:
Hi,
Doing (opts, args) = parser.parse_args(), supposing parser is an
OptionParser instance, gets you an instance of class Values into opts.
This patch adds the __iter__ method to the class Values so it is
possible to iterate ov
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9802/optparse_py3k__iter__.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue467384>
___
Python-bugs-list mailing list
Changes by Guilherme Polo <[EMAIL PROTECTED]>:
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue467384>
___
Python-bugs-list mailing list
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Sorry, but is the feature request related to constructing a safe
unpickler ? If yes, then I suppose this issue should be closed and an
appropriate one be created.
Nevertheless, reading the following comment at pickletools.py (trunk)
ma
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I see these multicall classes (including tests) in python-trunk, except
for the threaded one. So, should this remain open ? If yes, what has to
be done here ?
--
nosy: +gpolo
_
Tracker &
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
There is another patch regarding the use of HTTP/1.1 for xmlrpclib at
http://bugs.python.org/issue1767370. The other issue could be update
with some comments from this issue and then this issue could be closed,
I believe.
-
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
I have done some changes and did a patch against python-trunk
--
nosy: +gpolo
Added file: http://bugs.python.org/file9814/compiler.visitor_doc_update.diff
_
Tracker <[EMAIL PROTECTE
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Hi,
This patch makes Help dialog executes as nonmodal. I added a new button
at textView.py to demonstrate the behavior, also, I created a decorator
called _singledialog at EditorWindow so just one Help window executes at
a time, try
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
Someone should close this as it has been fixed already.
--
nosy: +gpolo
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guilherme Polo <[EMAIL PROTECTED]> added the comment:
You have some application installed that uses Python, be sure to check
that. If you believe that application is using way too much memory, be
sure to report it at the appropriate place.
If you have any other questions, python users mai
101 - 200 of 659 matches
Mail list logo
