[issue3288] float.as_integer_ratio method is not documented

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> Do we want to mention it in the tutorial?  If not,
> this issue could now be closed.

I think it might be worth mentioning both this and float.hex in the 
tutorial---it would fit well into the floating-point issues section.

Here's a patch.

Added file: http://bugs.python.org/file11494/tutorial_hex.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3690] sys.getsizeof wrong for Py3k bool objects

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> So how should this bug report be handled? Provide a patch to handle
> getsizeof correctly for small_ints? 'wont fix' because there are issues
> anyway? I would prefer the former and try to come up with a patch if you
> think it is worthwhile.

Fixing it for small_ints would be fine with me - there is specialized
code for long sizeof already. It's the explosion of boolobject that I
dislike.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3826] Self-reference in BaseHTTPRequestHandler descendants causes stuck connections

[romkyns]

romkyns <[EMAIL PROTECTED]> added the comment:

Someone suggested I test this in 2.6rc1. The problem does not exist in
2.6rc1, only in 3.0b2.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

It doesn't appear to me to be related to issue 2240, as my build linked
against libpthread:

$ ldd ./python
./python:
libutil.so.5 => /lib/libutil.so.5 (0x28187000)
libm.so.4 => /lib/libm.so.4 (0x28193000)
libpthread.so.2 => /lib/libpthread.so.2 (0x281a9000)
libc.so.6 => /lib/libc.so.6 (0x281ce000)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

I've briefly got a FreeBSD 7.0 amd64 setup available, and test_threading
passes in this environment.

Short term fix I'd suggest is to only disable this part of the test for
FreeBSD 6.x and earlier (ie platforms freebsd4, freebsd5, freebsd6).

I also checked my OS/2 EMX build and wasn't surprised to see it fail on
the same part of test_threading - fork() on OS/2 EMX is fragile enough
without threads in the mix.

If a disabler is added for FreeBSD as above, 'os2emx' should be in the
same list.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3872] Tix ComboBox error

[Dominique Wahli]

New submission from Dominique Wahli <[EMAIL PROTECTED]>:

Component ComboBox from Tix raise an error in Python 2.6rc1 (Windows XP):

Traceback (most recent call last):
  File "D:\PCE\Tools\PCSUpdate\test_combotix.py", line 11, in 
app = TestTix()
  File "D:\PCE\Tools\PCSUpdate\test_combotix.py", line 6, in __init__
w = ComboBox(self)
  File "C:\Python26\lib\lib-tk\Tix.py", line 579, in __init__
cnf, kw)
  File "C:\Python26\lib\lib-tk\Tix.py", line 307, in __init__
self.tk.call(widgetName, self._w, *extra)
_tkinter.TclError: unknown color name "{#c3c3c3}"

--
components: Tkinter
files: test_combotix.py
messages: 73249
nosy: dwahli
severity: normal
status: open
title: Tix ComboBox error
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file11493/test_combotix.py

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3690] sys.getsizeof wrong for Py3k bool objects

[Robert Schuppenies]

Robert Schuppenies <[EMAIL PROTECTED]> added the comment:

> What's the actual difference that this change makes?

It would provide more accurate results, even in the light of being not
perfect.

> [..] each small_int takes a complete PyLongObject. If that was also
> considered in long_sizeof, the computation would happen to be
> completely correct for bool also.

So how should this bug report be handled? Provide a patch to handle
getsizeof correctly for small_ints? 'wont fix' because there are issues
anyway? I would prefer the former and try to come up with a patch if you
think it is worthwhile.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Jeffrey C. Jacobs]

Jeffrey C. Jacobs <[EMAIL PROTECTED]> added the comment:

Well, I implemented this months ago, but have been busy with other
things so I haven't updated in a while.  I noticed that the current
version is missing my patches for Atomic Grouping / Possessive
Qualifiers and a number of other patches I added in #2636 , but I do
have working test cases and documentation updates for all the features
I've so far implemented as well as splitting my work into separate
sub-issues to make individual selection easier -- though with a number
of my modifications, I found that there are SO MANY co-dependencies
between, say, an engine modification (item 9) and adding Atomic Grouping
/ Possessive Qualifiers (item 1) and using shared Engine Constants (item
10) that I need a branch for Atomic, a branch for Atomic + Engine Mod 1,
Atomic + Engine Mod 2, Atomic + Shared Constants, Atomic + Engine Mod 1
+ Shared Constants AND Atomic + Engine Mod 2 + Shared Constants, and
those were just THREE item co-dependencies.  My code is all off of the
trunk line for 2.6 and is currently available via my Bazaar repository
under https://code.launchpad.net/~timehorse, where you can access any
source tree via the bazaar version control client.  The main reason I
got stumped in my development which might otherwise have implemented ALL
the issues I intended by now is that very situation I just described
where development of new features is NOT mutually independent.  You can
see by all my branches that the multiplicity of A or B or C is just
nightmarish, but what had to be done to keep issues independent.

Anyway, I'm looking forward to having a look at your suggestions and
think we may take best advantage with combining our work visa vi these
things; after all, there's no point re-inventing the wheel.

Thanks again for your contribution, Matthew!

--
nosy: +timehorse

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3862] test_array fails on FreeBSD7 amd64

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

I've temporarily got a 7.0 amd64 system running and can confirm what you
see.  I checked out the 2.5.2 port patches you mentioned, but all the
ones that seemed related are already in the 2.6rc1 sources.

On a hunch, I used ulimit -v is used to set a process virtual memory
size limit, and the test completed satisfactorily (I set it to 1048756,
ie 1GB).

I'm as yet none the wiser as to what to do with this info...

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3862] test_array fails on FreeBSD7 amd64

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

On FreeBSD 7.0 i386, test_array passes without ulimit -v needing to be
set (ie its still the default "unlimited".

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

test_threading also passes on FreeBSD 7.0 i386.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3835] tkinter goes into an infinite loop (pydoc.gui)

[Helmut Jarausch]

Helmut Jarausch <[EMAIL PROTECTED]> added the comment:

I'm using Tcl/Tk  8.5.4  here

print(":::")
print(_flatten((self._w, cmd)) + self._options(cnf))

produces:
:::
('.3073836300', 'configure', '-yscrollcommand', '3077632332set')
:::
('.3073835564.3073835660', 'configure', '-text', 'Python documentation 
server at\nhttp://localhost:7464/')
>>> Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/threading.py", line 507, in 
_bootstrap_inner
self.run()
  File "/usr/local/lib/python3.0/threading.py", line 462, in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/pydoc.py", line 1989, in serve
DocServer(port, callback).serve_until_quit()
  File "/usr/local/lib/python3.0/pydoc.py", line 1971, in __init__
self.base.__init__(self, self.address, self.handler)
  File "/usr/local/lib/python3.0/socketserver.py", line 401, in __init__
self.server_activate()
  File "/usr/local/lib/python3.0/pydoc.py", line 1982, in 
server_activate
if self.callback: self.callback(self)
  File "/usr/local/lib/python3.0/pydoc.py", line 2072, in ready
text='Python documentation server at\n' + server.url)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1201, in 
configure
return self._configure('configure', cnf, kw)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1192, in 
_configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: out of stack space (infinite loop?)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386

[Andrew I MacIntyre]

Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:

I've attached a simple patch which deactivates
test_3_join_in_forked_from_thread on FreeBSD 6.x and earlier, and also
OS/2 EMX.  With this patch, test_threading completes but...

$ ./python -E -tt Lib/test/regrtest.py test_threading
test_threading
1 test OK.
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

--
keywords: +patch
Added file: http://bugs.python.org/file11495/test_threading_fbsd6.py.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Matthew Barnett]

Matthew Barnett <[EMAIL PROTECTED]> added the comment:

I know what you mean about the dependencies!

My current problem is that now I'm working with the current trunk, which
means using Visual C++ Express 2008 instead of 2005. When debugging it's
behaving like the debug info is out of date (showing the wrong values
for variables in the debugger, single-stepping to the wrong line, etc).
Rebuilding doesn't fix it. This might take a while. :-(

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

If you use Visual C++ Express 2005, you can build python from the
PC\VS8.0 directory.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3

[Mitchell Model]

Mitchell Model <[EMAIL PROTECTED]> added the comment:

Theis the first time I've submitted bug reports to Python.org's 
development efforts, though I've been using Python for many years.  I 
don't know what the procedures are for followup to emails like you 
sent me, and given that the address is [EMAIL PROTECTED], I'm 
not even sure who -- if anyone -- reads a response like this.  Please 
tell me how to follow up and anything else you'd like to suggest 
about how I could help more effectively.

I retried IDLE it with Python 2.6rc1 and  got a very helpful and 
elaborate error message about not being able to start the subprocess, 
what port it was trying to connect to, and a pointer to information 
about running it without a subprocess.  I had my Mac's Security 
Firewall set to allow all incoming connections, so I don't know why 
it was refusing this one, but I changed the settings to "Set access 
for specific services and applications" and added idle26 and idle30. 
IDLE 2.6rc1 now works.

However, I checked out 3.0 sources from the Subversion repository 
yesterday, but am still getting a problem, though a different one, 
with IDLE30:

Traceback (most recent call last):
   File "", line 1, in 
   File "/usrlocal/lib/python3.0/idlelib/run.py", line 76, in main
 sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

Should I just assume that the development problem will be taking care 
of things like this, or is it helpful for me to report them when I 
encounter them?

Thanks for your response.

--- Mitchell

>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 -> closed
>
>___
>Python tracker <[EMAIL PROTECTED]>
>
>___

Added file: http://bugs.python.org/file11496/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___
Re: [issue3856] IDLE fails on startup on Mac 10.5
for 2.6b
Theis the first time I've submitted bug reports to Python.org's
development efforts, though I've been using Python for many years. 
I don't know what the procedures are for followup to emails like you
sent me, and given that the address is [EMAIL PROTECTED], I'm
not even sure who -- if anyone -- reads a response like this. 
Please tell me how to follow up and anything else you'd like to
suggest about how I could help more effectively.

I retried IDLE it with Python 2.6rc1 and  got a very helpful
and elaborate error message about not being able to start the
subprocess, what port it was trying to connect to, and a pointer to
information about running it without a subprocess.  I had my
Mac's Security Firewall set to allow all incoming connections, so I
don't know why it was refusing this one, but I changed the settings to
"Set access for specific services and applications" and
added idle26 and idle30.  IDLE 2.6rc1 now works.

However, I checked out 3.0 sources from the Subversion repository
yesterday, but am still getting a problem, though a different one,
with IDLE30:

Traceback (most recent call last):
  File "", line 1, in

  File
"/usrlocal/lib/python3.0/idlelib/run.py", line 76, in
main
   
sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute
'set_daemon'

Should I just assume that the development problem will be taking
care of things like this, or is it helpful for me to report them when
I encounter them?

Thanks for your response.

    ---
Mitchell



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 -> closed

___
Python tracker
<[EMAIL PROTECTED]>
;
___



___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3835] tkinter goes into an infinite loop (pydoc.gui)

[Guilherme Polo]

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 good if you could test some other combination, specially
because I can't reproduce it here with other versions (but I'm compiling
8.5.4 here now).

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Sorry for the silence:  new country + new job + no internet connection 
outside work = not many opportunities to spend time on this (or any 
other part of Python) at the moment.

I do now have a version 0.2 of the deccoeff type, and more importantly a 
version of decimal.py that's adapted to use it;  all tests in 
test_decimal.py pass, which is a start.  But there's significant work to 
be done tidying up the code, identifying speed-critical bits, and moving 
those bits from Python to C.

I'm wondering where to post the code;  I could post a tarball here but 
it's a bit unwieldy.  Perhaps it would be worth creating a new branch to 
work on this?

This definitely seems like a (>=) two-person task;  any help would be 
much appreciated!  Thanks Facundo and Nick for comments so far.  I also 
wonder whether there are alternative approaches that might do better.

If we follow this approach, I'm doubtful about doing this for 3.0.1; 
even though the API is unchanged, this seems like too big a change for a 
bugfix release, with too great a risk of breakage.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3

[Guilherme Polo]

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
find a solution).

And your final question.. It is very nice if people report any problems
they find, they all will be noticed but some will receive more attention
than others. In your specific bug report, it happened to be already
fixed in the current development version so I just sent a "standard
message". So, finishing up, it is always good to search for issues that
may be the one you are reporting so duplicates are not created.
Sometimes you won't be able to find them, that is fine, but if you find
one be sure to add something to it (if you have something to add) or
don't create a duplicate.

Sorry if this response is too dry.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3782] os.write accepts unicode strings

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Here is a patch. I've covered all direct uses of os.write() in the
standard library, but perhaps there are indirect uses. Please review.

--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11498/oswrite.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3873] Unpickling is really slow

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Do the numbers vary if you read the whole file at once and then unpickle
the resulting bytes string?
Large parts of the IO library are written in Python in 3.0, which might
explain the discrepancy.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1602742] itemconfigure returns incorrect text property of text items

[Guilherme Polo]

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 when there are no spaces either).

To try this yourself, just change text to:
text = "{sample text with spaces}"

I can't look at Tkinter source right now to propose a correct solution,
but will do later (today hopefully).

--
nosy: +gpolo
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3873] Unpickling is really slow

[Hagen Fürstenau]

Hagen Fürstenau <[EMAIL PROTECTED]> added the comment:

Yes, it gets much better, but even so (first reading file and timing
only "loads") unpickling takes four times as long in Python 3.0 as with
the old cPickle module:

[EMAIL PROTECTED] hagenf]$ python pickletst2.py
0.0744678974152
0.0514161586761
[EMAIL PROTECTED] hagenf]$ python3.0 pickletst3.py
0.0911619663239
0.208593845367

But I guess this can still be blamed on the BytesIO implementation...

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Matthew Barnett]

Matthew Barnett <[EMAIL PROTECTED]> added the comment:

Used Visual C++ Express 2005 and the PC\VS8.0 directory. Same problem.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3873] Unpickling is really slow

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Indeed. If I replace the file with 
f = io.BytesIO(open("tst", "rb").read())
timings are divided by 20...

After quick profiling, it seems that PyLong_New would benefit from a
free list. len(bytearray) is called very often.
To stay simple, it would be enough to only store longs of length 1 (<2**15).

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3873] Unpickling is really slow

[Hagen Fürstenau]

New submission from Hagen Fürstenau <[EMAIL PROTECTED]>:

Unpickling e.g. a large list seems to be really slow in Python 3.0.

The attached test script gives the following results for pickling and
unpickling a list of 1M zeros, showing that although the C
implementation seems to be used in Python 3.0, unpickling is even slower
than with the "pickle" module of Python 2.6!

[EMAIL PROTECTED] hagenf]$ python pickletst.py
2.71067500114
2.77484893799
[EMAIL PROTECTED] hagenf]$ python3.0 pickletst.py
0.0925059318542
5.76121616364

--
components: Library (Lib)
files: pickletst.py
messages: 73267
nosy: hagen
severity: normal
status: open
title: Unpickling is really slow
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file11497/pickletst.py

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Do you have some big source files, of more than 1 lines?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1222721] tk + setlocale problems...

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3873] Unpickling is really slow

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Gregory had patches for a freelist of long objects in #2013.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1160383] digit-only tag values are mishandled in Tkinter

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue775309] button methods tkButtonDown, etc don't work

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1581476] Text search gives bad count if called from variable trace

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1257772] tkapp read-only attributes

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

This was fixed in r38525

--
nosy: +gpolo
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1257772] tkapp read-only attributes

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

My bad, r39219 is the one.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2138] Add a factorial function

[maix]

maix <[EMAIL PROTECTED]> added the comment:

I think the unit test is wrong, or at least not as is intended:

You put some numbers in values and shuffle them. But you don't use them
but just range(10) for testing.

--
nosy: +maix

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Matthew Barnett]

Matthew Barnett <[EMAIL PROTECTED]> added the comment:

_sre.c is over 6000, but it does contain macros. I didn't have this
problem when based on Python 2.5.2 in Express 2005.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3825] Major reworking of Python 2.5.2 re module

[Jeffrey C. Jacobs]

Jeffrey C. Jacobs <[EMAIL PROTECTED]> added the comment:

I have uploaded my test cases for Atomic Grouping / Possessive
Qualifier, which is the common code we seem to have developed, as this
may be of use to you.  I also have documentation, but for now, would you
mind running these tests against your code to see what the test outputs
and also, how did you come up with the 2x result?  Was that running the
test suite?  Usually, the regexp module is benchmarked against its test
suite and there are timings built into that, so it may be useful if you
could run the unmodified Lib/test/test_re.py you got from the trunk
against the original code before modification and your modification, and
do so a few times to get a good average result on multi-tasking systems,
and post the results here so we can get a good statistical feel for how
your new engine improves efficiency.  Certainly, I support any Engine
that works faster, as I myself have tried to make it faster but ended up
with something 8% slower instead, alas.

Also, good thinking on fixing the Negative Look-behind variable-width
issue; I wish I'd thought of that, but I am curious about something: did
you remove the optimization for fixed-width look-behind?  The old code
only allowed fixed with because that test can be done quickly; I noticed
your code adds a lot of new REV opcodes to handle back-tracking and I
assume look-behind logic for variable-width look-behind.  It would be
handy if the compiler and engine would be able to differentiate between
fixed-width look-behind (optimized as was originally) and variable-width
(using your advanced code).

Thanks to AMK for some of these suggestions.  Your changes are quite
radical though so I am still trying to wade through them all and I still
don't have a full-picture of how you've changed things, but there are
some good ideas here, IMHO, especially if you do indeed get 2x speedup.

Added file: http://bugs.python.org/file11499/test_re.py

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

This is the kind of project where the sandbox is useful - Facundo's
original decimal work was done there, as was the attempt at a complete
rewrite of the decimal module in C (which turned out to be a less than
optimal approach to the speed problem).

So I would suggest either a new directory in the sandbox, or re-using
Facundo's original directory (which includes the telco benchmark)

http://svn.python.org/view/sandbox/trunk/decimal

And I agree that it is far more sensible to target 2.7/3.1 at this stage
- the 3.0 slowdown, while real, actually isn't as bad as I expected, and
even if it's large enough to be unacceptable to heavy users of Decimal,
the only consequence is that they will have to hold off on migrating to
3.x for 12-18 months.

Should we add something specific to the 3.0 release notes pointing out
that there is approximately a 25% slowdown in the decimal module
relative to 2.x?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3874] documentation bug: HTMLParser needs to document unknown_decl

[jeff]

New submission from jeff <[EMAIL PROTECTED]>:

the unknown_decl function is critical to dealing with MS Office
generated HTML files. There's no documentation of that. The default
behavior of the function is to error, which is reasonable, but it should
be stated in the documentation.

--
components: Library (Lib)
messages: 73282
nosy: freyley
severity: normal
status: open
title: documentation bug: HTMLParser needs to document unknown_decl
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3782] os.write accepts unicode strings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Assuming you've run the test suite, go ahead and apply.

--
keywords:  -needs review
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3875] provide a "cmem" role

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

This would be a useful counterpart to the cmember directive.

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 73284
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: provide a "cmem" role
type: feature request

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3782] os.write accepts unicode strings

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Thanks, committed in r66469.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Nick said:

> So I would suggest either a new directory in the sandbox, or 
> re-using Facundo's original directory (which includes the 
> telco benchmark)

+1


> And I agree that it is far more sensible to target 2.7/3.1 at 
> this stage - the 3.0 slowdown, while real, actually isn't as bad 
> as I expected, and even if it's large enough to be unacceptable 
> to heavy users of Decimal, the only consequence is that they will 

I'm not seeing this job as a way to solve the 3.0 slowdown, but more as
the way to slowly, but steadily, replace parts of Decimal from Python to
C as needed.

So, I'm +1 to target this to 3.1, and I'm -0 to register the slowdown in
the releases notes (those who use Decimal aren't really in it for speed...).

Thank you!!

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3829] Tuple comparison masking exception

[Gary Poster]

Changes by Gary Poster <[EMAIL PROTECTED]>:


--
nosy: +gary

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1160383] digit-only tag values are mishandled in Tkinter

[Guilherme Polo]

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
item with id 123.

In your case you have an item with id "1", and when you do: 

c.find_withtag("123")

Tk tries to find an item with that id, which doesn't exist and returns
an empty tuple.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1602742] itemconfigure returns incorrect text property of text items

[Guilherme Polo]

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

You would get something like this:

-text {} {} {} {a b}

While

.c itemcget 1 -text

Will return the same as Python: "a b"

Now what remains is to see how useful is to use itemconfigure for this,
and if it is worth making canvas.itemconfigure(id)['text'][-1] return "a
b" instead of ("a", "b"). Changing Misc._configure is too risky given
there are no tests for Tkinter (and I find it weird sometimes, someone
will still have to explain me why Tkinter plays with cnf and kw all the
time), the other option involves leaving these special needings in Text
and is something I dislike because other widgets could use these new
things that would be added. 
Yet another option would be to start writing unit tests for Tkinter and
much of these bugs would end up being caught and hopefully fixed properly.

--
resolution: accepted -> 

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue775309] button methods tkButtonDown, etc don't work

[Guilherme Polo]

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 remove these methods that call
commands that shouldn't be used anymore and are not directly available.

--
priority: normal -> low

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2619] Document PEP 3118

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

The bulk of the C-API is in r66476. Somebody definitely needs to review
it; I mostly extracted it directly from the PEP, and I understand that's
a little different from reality here. I'll lower priority, and we can
close it after some looks at my changes. Thanks!

--
priority: deferred blocker -> normal

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3876] multiprocessing does not compile on *BSD and potentialy other systems

[Henry Precheur]

New submission from Henry Precheur <[EMAIL PROTECTED]>:

Compiling `multiprocessing` on OpenBSD fails. `iovec` is not declared.

Adding the following line to multiprocessing.c solves the problem:
#include 

But right after I got:
./python:build/lib.openbsd-4.4-amd64-2.6/_multiprocessing.so: undefined
symbol 'sem_timedwait'

It looks like multiprocessing is using a function that is not defined in
OpenBSD and very likely on other BSD's (FreeBSD & NetBSD don't have a
man page for this function)

According to this page, some other systems don't have this function:
http://www.gnu.org/software/gnulib/manual/html_node/sem_005ftimedwait.html

--
components: Extension Modules
messages: 73291
nosy: henry.precheur
severity: normal
status: open
title: multiprocessing does not compile on *BSD and potentialy other systems
type: compile error
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3877] test_fileio fails on OpenBSD 4.4

[Henry Precheur]

New submission from Henry Precheur <[EMAIL PROTECTED]>:

test_fileio
test test_fileio failed -- Traceback (most recent call last):
  File "/home/henry/compile/python2.6/Lib/test/test_fileio.py", line
155, in testAbles
self.assertEquals(f.seekable(), False)
AssertionError: True != False

Apparently it is expected to "fail" for *BSD systems since darwin,
freebsd and sunos / solaris are not expected to pass this test:

if sys.platform != "darwin" and \
   not sys.platform.startswith('freebsd') and \
   not sys.platform.startswith('sunos'):
# Somehow /dev/tty appears seekable on some BSDs
self.assertEquals(f.seekable(), False)

I just added openbsd to the list and the test works. I would also
suggest to add netbsd, since it is very very likely to have the same
behavior.

--
components: Extension Modules
files: test_fileio_openbsd.diff
keywords: patch
messages: 73292
nosy: henry.precheur
severity: normal
status: open
title: test_fileio fails on OpenBSD 4.4
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11500/test_fileio_openbsd.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com