[ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected

2007-04-12 Thread SourceForge.net 
Bugs item #162, was opened at 2006-12-23 13:03
Message generated for change (Comment added) made by mehum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&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.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Mick L (mehum)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE crashes on OS X 10.4 when "Preferences" selected

Initial Comment:
When I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'Configure IDLE' 
(IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon 
as the dialog box appears.

Terminal reports a "Segmentation fault" upon the crash.

My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and 
seems otherwise stable.  

IDLE also appears stable until I select this option.

The Python crash log is attached.

Please, can anyone suggest what may be causing this problem?  Thank you.



--

>Comment By: Mick L (mehum)
Date: 2007-04-12 17:27

Message:
Logged In: YES 
user_id=1674554
Originator: YES

OK... I followed your advice Ronald (moved the Tcl and Tk frameworks out
of Library), and it worked!  IDLE no longer crashes! Thank you so much!

With the frameworks moved, it apparently reverts to Tcl/Tk 8.4.7

The only oddity is that there is a _very_ long delay (beachball) when
opening preferences / configure IDLE; but now that the font is legibly
large, I doubt I shall need to go back there.

Thank you again,
Kind regards, Mick L

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-04-12 05:24

Message:
Logged In: YES 
user_id=580910
Originator: NO

It seems to be caused by Tcl/Tk, I cannot reproduce this with the system
version of Tk

This is on 10.4.8/intel, with python 2.5.1rc1. I don't think the change in
python version fixes this issue.

Mick: could you please test what happens when you temporarily move
/Library/Frameworks/Tcl.framework and /Library/Frameworks/Tk.framework to
another folder.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-12 02:12

Message:
Logged In: YES 
user_id=80475
Originator: NO

Bumping up the priority so this doesn't get lost.  My guess is that IDLE
is tickling some problem with the TkInter bindings.

--

Comment By: François Scholder (f_scholder)
Date: 2007-02-03 06:55

Message:
Logged In: YES 
user_id=1609867
Originator: NO

Erratum:

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors
are
observed depending on how many times one has clicked on the 'Ok' and/or
>'Apply'< buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is
resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

--

Comment By: François Scholder (f_scholder)
Date: 2007-02-03 06:48

Message:
Logged In: YES 
user_id=1609867
Originator: NO

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors are
observed depending on how many times one has clicked on the 'Ok' and/or
'Cancel' buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1697943 ] msgfmt cannot cope with BOM

2007-04-12 Thread SourceForge.net 
Bugs item #1697943, was opened at 2007-04-10 22:58
Message generated for change (Comment added) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697943&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: Demos and Tools
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christoph Zwerschke (cito)
Assigned to: Martin v. Löwis (loewis)
Summary: msgfmt cannot cope with BOM

Initial Comment:
If a .po file has a BOM (byte order mark) at the beginning, as is often the 
case for utf-8 files created on Windows, msgfmt.py complines about a syntax 
error.

The attached patch fixes this problem.

--

>Comment By: Christoph Zwerschke (cito)
Date: 2007-04-12 11:10

Message:
Logged In: YES 
user_id=193957
Originator: YES

It may well be that GNU gettext also chokes on a BOM, because they aren't
used under Linux. But I think as a Python tool it should be more
Windows-tolerant. The annoying thing is that you get a syntax error, but
everything looks right because the BOM is usually invisible. Such error
messages are really frustrating. Either the BOM should be silently ignored
(as in the patch) or the users should get a friendly error message asking
them to save the file without BOM. If GNU behaves badly to Windows users,
that's not an excuse to do the same. They are already suffering enough
because of their (or their bosses') bad choice of OS ;-)



--

Comment By: Martin v. Löwis (loewis)
Date: 2007-04-12 00:13

Message:
Logged In: YES 
user_id=21627
Originator: NO

It's my code, but I will need to establish first whether it's a bug. That
depends on what the PO specification says, and, if is it silent on the
matter, what GNU gettext does.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 18:07

Message:
Logged In: YES 
user_id=80475
Originator: NO

Martin, is this your code?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697943&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1613130 ] str.split creates new string even if pattern not found

2007-04-12 Thread SourceForge.net 
Bugs item #1613130, was opened at 2006-12-11 14:03
Message generated for change (Comment added) made by pitrou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&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: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Fredrik Lundh (effbot)
Summary: str.split creates new string even if pattern not found

Initial Comment:
Hello,

Several string methods avoid allocating a new string when the operation result 
is trivially the same as one of the parameters (e.g. replacing a non-existing 
substring). However, split() does not exhibit this optimization, it always 
constructs a new string even if no splitting occurs:

$ python
Python 2.5 (r25:51908, Oct  6 2006, 15:22:41) 
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "abcde" * 2
>>> id(s)
3084139400L
>>> id(str(s))
3084139400L
>>> id("" + s)
3084139400L
>>> id(s.strip())
3084139400L
>>> id(s.replace("g", "h"))
3084139400L
>>> [id(x) for x in s.partition("h")]
[3084139400L, 3084271768L, 3084271768L]
>>> [id(x) for x in s.split("h")]
[3084139360L]


--

>Comment By: Antoine Pitrou (pitrou)
Date: 2007-04-12 11:19

Message:
Logged In: YES 
user_id=133955
Originator: YES

Hi,

> Dropping the priority.  This pay-off is near zero and likely not worth
the
> cost of making the code more complex than it already is.

No problem!
The more interesting question actually was whether it made any sense to
factor out the split() implementation in "stringlib" so as to share the
implementation between str and unicode.

Also, as for the USE_FAST question you asked on python-dev, I may have an
answer: if you try to enable USE_FAST you'll see that some operations are
indeed faster on large strings (say 100s or 1000s of characters), but they
become slower on small strings because of the larger overhead of the search
algorithm. Thus USE_FAST could negatively impact Python programs which
process a lot of small strings.


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 19:09

Message:
Logged In: YES 
user_id=80475
Originator: NO

Dropping the priority.  This pay-off is near zero and likely not worth the
cost of making the code more complex than it already is.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-12-12 17:21

Message:
Logged In: YES 
user_id=849994
Originator: NO

Sounds like this is best assigned to Fredrik.

--

Comment By: Antoine Pitrou (pitrou)
Date: 2006-12-12 12:35

Message:
Logged In: YES 
user_id=133955
Originator: YES

Ok, I did a patch which partially adds the optimization (the patch is at
home, I can't post it right now). I have a few questions though:
 - there is a USE_FAST flag which can bring some speedups when a
multicharacter separator is used; however, it is not enabled by default, is
there a reason for this?
 - where and by whom is maintained stringbench.py, so that I can propose
additional tests for it (namely, tests for unmatched split())?
 - split() implementation is duplicated between str and unicode (the
unicode versions having less optimizations), would it be useful to
"stringlib'ify" split()?
 - rsplit() does quite similar things as split(), has anyone tried to
factor similar parts? do you see any caveats doing so?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1693753 ] Portability issue: os.rename behaves differently on win32

2007-04-12 Thread SourceForge.net 
Bugs item #1693753, was opened at 2007-04-03 12:17
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: cs_ (cs_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Portability issue: os.rename behaves differently on win32

Initial Comment:
os.rename(src, dst) fails on Windows if dst already exist and regular file. On 
Unixes, it does not fail, and silently overwrites dst. It's better to use 
MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under 
Win32 to make it behave consistent way.

--

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-12 12:35

Message:
Logged In: YES 
user_id=984087
Originator: NO


>From MSDN document and googling, it does look like
MOVEFILE_REPLACE_EXISTING guarantees atomicity for rename operation. I will
see if I can come up with a patch (I will first need to learn building
python on windows).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1697820 ] __getslice__ still used in built-in types

2007-04-12 Thread SourceForge.net 
Bugs item #1697820, was opened at 2007-04-10 12:06
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697820&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: Torsten Bronger (bronger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: __getslice__ still used in built-in types

Initial Comment:
In the Python language reference 
, after the sentence

"""Deprecated since release 2.0. Support slice objects as parameters to the 
__getitem__() method."""

I suggest the following addition:

"""However, built-in types in CPython currently still implement __getslice__.  
Therefore, you have to override it in derived classes when implementing 
slicing."""

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-12 13:34

Message:
Logged In: YES 
user_id=80475
Originator: NO

Sensible suggestion.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697820&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1699594 ] shlex fails to parse strings correctly

2007-04-12 Thread SourceForge.net 
Bugs item #1699594, was opened at 2007-04-12 18:49
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=1699594&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex fails to parse strings correctly

Initial Comment:
shlex fails to parse

"\!echo \"it's fine\""

and

 "\!echo \"it\'s fine\""

correctly. ValueError("No closing quotation") is raised incorrectly.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699594&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1699594 ] shlex fails to parse strings correctly

2007-04-12 Thread SourceForge.net 
Bugs item #1699594, was opened at 2007-04-12 18:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699594&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex fails to parse strings correctly

Initial Comment:
shlex fails to parse

"\!echo \"it's fine\""

and

 "\!echo \"it\'s fine\""

correctly. ValueError("No closing quotation") is raised incorrectly.

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-04-12 18:50

Message:
Logged In: YES 
user_id=1344176
Originator: YES

This should probably be fixed at the same time as #1521950.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699594&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com