[ python-Bugs-1568120 ] Encoding bug

[SourceForge.net]

Bugs item #1568120, was opened at 2006-09-30 00:12
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568120&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: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: �mer FADIL USTA (usta)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Encoding bug

Initial Comment:
The problem easily shown in photo which have been
attached with this bug and also at
http://img147.imageshack.us/img147/3717/pythonte4.jpg

thx

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:18

Message:
Logged In: YES 
user_id=849994

This is the same issue as #1193061.

--

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

[ python-Bugs-1193061 ] Python and Turkish Locale

[SourceForge.net]

Bugs item #1193061, was opened at 2005-04-30 17:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&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: Unicode
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: S.�ağlar Onur (caglar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python and Turkish Locale

Initial Comment:
On behalf of this thread;

http://mail.python.org/pipermail/python-dev/2005-April/052968.html

As described in
http://www.i18nguy.com/unicode/turkish-i18n.html [ How
Applications Fail With Turkish Language
] , Turkish has 4 "i" in their alphabet. 

Without --with-wctype-functions support Python convert
these characters locare-independent manner in
tr_TR.UTF-8 locale. So all conversitons maps to "i" or
"I" which is wrong in Turkish locale. 

So if Python Developers will remove the wctype
functions from Python, then there must be a
locale-dependent upper/lower funtion to handle these
characters properly.


--

Comment By: Eray Ozkural (exa)
Date: 2005-10-11 21:36

Message:
Logged In: YES 
user_id=1454

The better solution is to use an optional locale argument for 
upper/lower functions and other language-dependent text 
processing functions. 
 

--

Comment By: S.�ağlar Onur (caglar)
Date: 2005-05-02 08:45

Message:
Logged In: YES 
user_id=858447

No, im not. These rules defined in
http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and
http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt.
Note that there is a comments says;

# T: special case for uppercase I and dotted uppercase I
#- For non-Turkic languages, this mapping is normally
not used.
#- For Turkic languages (tr, az), this mapping can be
used instead of the normal mapping for these characters.
#  Note that the Turkic mappings do not maintain
canonical equivalence without additional processing.
#  See the discussions of case mapping in the Unicode
Standard for more information.

So without wctype functions support, python can't convert
these. This _is_ the problem. As a side effect of this,
another huge problem occurs, keywords can't be locale
dependent. If Python compiled with wctype support functions,
all "i".upper() turns into "İ" which is wrong for keyword
comparision ( like quit v.s QUİT )

So i suggest implement two new functions like
localeAwareLower()/localeAwareUpper() for python and let
lower()/upper() locale independent. And as you wrote locale
module may be a perfect home for these :)



--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-05-02 08:00

Message:
Logged In: YES 
user_id=38388

I'm not sure I understand: are you saying that the Unicode
mappings for upper and lower case are wrong in the standard ?

Note that removing the wctype functions will only remove the
possibility to use these functions for case mapping of
Unicode characters instead of using the builtin Unicode
character database. This was originally meant as
optimization to avoid having to load the Unicode database -
nowadays the database is always included, so the
optimization is no longer needed. Even worse: the wctype
functions sometimes behave differently than the mappings in
the Unicode database (due to differences in the Unicode
database version or implementation s).

Now, since the string .lower() and .upper() methods are
locale dependent (due to their reliance on the C functions
toupper() and tolower() - not by intent), while the Unicode
versions are not, we have a rather annoying situation where
switching from strings to Unicode cause semantic differences.

Ideally, both string and Unicode methods should do case
mapping in an locale independent way. The support for
differences in locale dependent case mapping, collation,
etc. should be moved to an external module, e.g. the locale
module.


--

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

[ python-Bugs-1567375 ] False sentence about formatted print in tutorial section 7.1

[SourceForge.net]

Bugs item #1567375, was opened at 2006-09-28 23:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567375&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Benbennick (dbenbenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: False sentence about formatted print in tutorial section 7.1

Initial Comment:
The line:

(Note that one space between each column was added by
the way print works: it always adds spaces between its
arguments.)

in section 7.1 of the tutorial
(http://docs.python.org/dev/tut/node9.html), is false.
 It refers to the command

print '%2d %3d %4d' % (x, x*x, x*x*x)

which produces (if x == 10)

10 100 1000

The two spaces in that output are NOT "added by the way
print works".  Instead, they come from the format
string itself.  If you use

print '%2d%3d%4d' % (x, x*x, x*x*x)

you get

101001000

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:25

Message:
Logged In: YES 
user_id=849994

The sentence refers to the example above the one you quoted,
which uses the print statement. I made that clear in rev
52053, 52054 (2.4), 52055 (2.5).

--

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

[ python-Bugs-1565661 ] webbrowser on gnome runs wrong browser

[SourceForge.net]

Bugs item #1565661, was opened at 2006-09-26 11:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: kangabroo (kangabroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser on gnome runs wrong browser

Initial Comment:
Epiphany is set as system default, but Firefox runs
when webbrowser.open is called.

in webbrowser.py - register_X_browsers():
'gconftool-2 -g
/desktop/gnome/url-handlers/http/command 2>/dev/null'
returns 'epiphany %s'

A BackgroundBrowser with a name of 'epiphany %s' is
created.

later on open(), 
subprocess.Popen(['epiphany %s', url], ) is called.

This throws an exception:
OSError: [Errno 2] No such file or directory
which is caught, and False is returned

Solution:
in webbrowser.py function register_X_browsers(), change:
register("gnome", None, BackgroundBrowser(commd))
to
register("gnome", None, BackgroundBrowser(commd.split()))


System: Python 2.5, Linux 2.6.17, Gnome 2.14.2.




--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:32

Message:
Logged In: YES 
user_id=849994

Thanks for the report, fixed in rev. 52056, 52057 (2.5).

--

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

[ python-Bugs-1565087 ] Misbehaviour in zipfile

[SourceForge.net]

Bugs item #1565087, was opened at 2006-09-25 13:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565087&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Richard Philips (rphilips)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misbehaviour in zipfile

Initial Comment:
Python 2.5

In library module zipfile, a ZipFile object has method
write( filename[, arcname[, compress_type]])

If arcname is not specified, it defaults to the
pathname of filename without a drive letter and with
leading path separators removed.

That is OK.

But if arcname is explicitely specified, the drive
letter and leading path separators are also removed.

I think that is not OK.


thanks,

Richard Philips

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:40

Message:
Logged In: YES 
user_id=849994

It is, since the Zip specification doesn't allow paths with
drive letters or absolute paths for files inside the zip.

See bug #1413790.

--

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

[ python-Bugs-1568075 ] GUI scripts always return to an interpreter

[SourceForge.net]

Bugs item #1568075, was opened at 2006-09-29 23:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: Pending
Resolution: None
Priority: 5
Submitted By: jjackson (jejackson)
Assigned to: Jack Jansen (jackjansen)
Summary: GUI scripts always return to an interpreter

Initial Comment:
I installed the latest version of 2.5 from the web last night:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

When I run a wxPython script, using something like

pythonw myScript.py

from the Terminal, I find myself in an interpreter after I use the quit 
menu. The menubar becomes a single, hung python menu, and a shell 
window pops up with an interpreter prompt. Cntrl-D kills the interpreter.

It's as if python was stuck in "-i" mode:

pythonw -i myScript.py

gives the same results.

(python and pythonw give the same results. It appears from comments on 
the web that they are now the same. They appear so from a diff. If so, why 
not a symlink?)

Running the lastest wxPython demo gives this warning in the console, 

2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: 
_wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there 
are no autorelease pools in the stack.

which may or may not be related.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:47

Message:
Logged In: YES 
user_id=849994

Did you (or someone else) perhaps set the PYTHONINSPECT
environment variable? I can't imagine another cause for this
problem.

--

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

[ python-Bugs-1566800 ] urllib doesn't raise IOError correctly with new IOError

[SourceForge.net]

Bugs item #1566800, was opened at 2006-09-28 05:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566800&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Arthibus Gissehel (gissehel)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib doesn't raise IOError correctly with new IOError

Initial Comment:
The version I used is :

>>> sys.version
'2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 
bit (Intel)]'

On Windows XP SP2.

While I think every python 2.5 releases are concerned.

On line 357 of urllib.py from 2.5 release, there is a 
raise of an IOError with 4 arguments. It look like it 
was fine with python 2.4 but it hang up with a 
"TypeError: EnvironmentError expected at most 3 
arguments, got 4"

Concretly, when you hit a page with a "redirect" using 
error 302 for exemple, instead of raising an IOError, 
it raise a TypeError, so it break code which expect an 
IOError here (as a "normal" behavior for 302 codes)

It look like IOError is totally different between 
Python 2.4 and Python 2.5 (it was a class, it's now a 
type)

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 09:04

Message:
Logged In: YES 
user_id=849994

Thanks for the report, IOError can now again take any number
of arguments. rev.  52061, 52062 (2.5).

--

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

[ python-Bugs-1566663 ] Library Reference Section 5.1.8.1 is wrong.

[SourceForge.net]

Bugs item #153, was opened at 2006-09-27 21:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=153&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Connett (cconnett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Library Reference Section 5.1.8.1 is wrong.

Initial Comment:
The examples section of the datetime doc is out of
date.  The example says that the datetime class doesn't
support strptime directly, but as of Python 2.5, it does.

I think the whole example is obsolete, and should
probably be deleted.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 09:07

Message:
Logged In: YES 
user_id=849994

Thanks for the report, fixed in rev. 52063, 52064 (2.5).

--

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

[ python-Bugs-1566602 ] test_posixpath failure

[SourceForge.net]

Bugs item #1566602, was opened at 2006-09-27 20:12
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566602&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: WallsRSolid (wallsrsolid)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_posixpath failure

Initial Comment:
On a compile from the Python 2.5 Final tarball in Linux
on a 64-bit, dual Opteron system, "make test" reports
one failure:
test test_posixpath failed -- Traceback (most recent
call last):
  File
"/archive/home/nvf/temp/Python-2.5/Lib/test/test_posixpath.py",
line 353, in test_expanduser
posixpath.expanduser("~/")
AssertionError: '/archive/home/nvf//' !=
'/archive/home/nvf/'

In searching the bug database, I see that failures used
to happen on Tru64 and MacOS9, but there was no mention
of failure on a Linux system.

Versions:
python -V: Python 2.5
gcc -v:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada
--enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 09:13

Message:
Logged In: YES 
user_id=849994

Thanks for the report, that is now fixed in rev. 52065,
52066 (2.4), 52067 (2.5).

--

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

[ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows

[SourceForge.net]

Bugs item #1568240, was opened at 2006-09-30 12:19
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=1568240&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tix is not included in 2.5 for Windows

Initial Comment:
(I hope "Build" is more precise than "Extension
Modules" and "Tkinter" for this specific bug.)

At least the following files are missing from 2.5 for
Windows:

DLLs\tix8184.dll
tcl\tix8184.lib
tcl\tix8.1\*

--

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

[ python-Bugs-1568243 ] init_types

[SourceForge.net]

Bugs item #1568243, was opened at 2006-09-30 11:34
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=1568243&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bosko Vukov (bvukov)
Assigned to: Nobody/Anonymous (nobody)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) 
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


--

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

[ python-Bugs-1412580 ] locale.format gives wrong exception on some erroneous input

[SourceForge.net]

Bugs item #1412580, was opened at 2006-01-23 07:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412580&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Tim Diggins (tdiggins)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.format gives wrong exception on some erroneous input

Initial Comment:
using '2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)]' on WinXpPro SP2


locale.format(formatString, val, grouping) when passed
a formatString of the wrong type, ought to raise a
TypeError (as some erroneous input does)

Example: locale.format(2.3, 2.3) passes through
AttributeError ("float has no  attribute 'split'").

I thought perhaps the body of the method should be
wrapped in a try:except block, and if any error is
caught, then the arguments should be rigorously tested
for type and lucid exceptions raised. See attachment
for suggestion (with tests).

I'm not clear whether if the format string is erroneous
(bad syntax, or has too many/no %-s, the raised error
should be ValueError (contractually correct) or 
conceivably whatever StringInterpolation raises
(parallelism). I've put tests for both in - currently
ValueError wins.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 10:27

Message:
Logged In: YES 
user_id=849994

format() has been overhauled in 2.5. This doesn't apply anymore.

--

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

[ python-Bugs-1566719 ] site-packages isn't created before install_egg_info

[SourceForge.net]

Bugs item #1566719, was opened at 2006-09-28 00:34
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&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: Distutils
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Submitted By: James Oakley (jfunk)
Assigned to: Nobody/Anonymous (nobody)
Summary: site-packages isn't created before install_egg_info

Initial Comment:
install_egg_info is called without creating the site-packages 
directory when only a script is specified. This can break 
RPM builds since the site-packages directory isn't present 
beforehand.

Here's an setup.py that causes this problem::

from distutils.core import setup
setup(name='dot2tex',
  version='1.0.1',
  description = 'A Graphviz to LaTeX converter',
  author = 'Kjell Magne Fauske',
  author_email = '[EMAIL PROTECTED]',
  url = "http://www.fauskes.net/code/dot2tex/";,
  download_url 
= "http://www.fauskes.net/code/dot2tex/download/";,
  scripts=['dot2tex/dot2tex.py']
  )

Here's the build output::

+ python setup.py 
install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES
running install
running build
running build_scripts
running install_scripts
creating /var/tmp/dot2tex-buildroot
creating /var/tmp/dot2tex-buildroot/usr
creating /var/tmp/dot2tex-buildroot/usr/bin
copying 
build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin
changing mode 
of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755
running install_egg_info
Writing 
/var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info
error: 
/var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info:
 
No such file or directory


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-09-28 03:26

Message:
Logged In: YES 
user_id=21627

How can there not be a site-packages directory? It is
created with the installation of Python itself, so it is
always there.

--

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

[ python-Bugs-1457823 ] cgi.FormContentDict constructor should support parse options

[SourceForge.net]

Bugs item #1457823, was opened at 2006-03-24 16:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Belmonte (jbelmonte)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FormContentDict constructor should support parse options

Initial Comment:
cgi.FormContentDict (and cgi.SvFormContentDict) should
take optional keep_blank_values and strict_parsing args
and pass them on to cgi.parse().  In my use case
neither of the parse defaults is what I want, so I'm
faced with having to hack or re-implement
SvFormContentDict.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 10:58

Message:
Logged In: YES 
user_id=849994

Added in rev. 52068 for Python 2.6.

--

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

[ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)):

[SourceForge.net]

Bugs item #1459159, was opened at 2006-03-27 09:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getargspec() is wrong for def foo((x)):

Initial Comment:
See my recent checkin on HEAD for fixing def foo((x)):
in the AST compiler.  I had to modify test_inspect
because the above signature should not do tuple
unpacking.  inspect thinkgs it does though.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:00

Message:
Logged In: YES 
user_id=849994

Yes, it seems so.

--

Comment By: �iga Seilnacht (zseil)
Date: 2006-06-02 02:02

Message:
Logged In: YES 
user_id=1326842

Can this bug be closed? It seems that the only problem
was test_inspect relying on the old behavior.


--

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 11:39

Message:
Logged In: YES 
user_id=849994

This at least explains why test_inspect didn't fail for 2.5
after you had fixed the bug and modified the test.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 11:38

Message:
Logged In: YES 
user_id=849994

That's a bit odd. Following defs:

def bar((x)): pass
def foo(x): pass

In 2.4:

>>> dis.dis(bar)
  1   0 LOAD_FAST0 (.0)
  3 STORE_FAST   1 (x)
  6 LOAD_CONST   0 (None)
  9 RETURN_VALUE
>>> dis.dis(foo)
  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE

In 2.5:

>>> dis.dis(bar)
  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE
>>> dis.dis(foo)
  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE


--

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

[ python-Bugs-1156179 ] Calls from VBScript clobber passed args

[SourceForge.net]

Bugs item #1156179, was opened at 2005-03-03 20:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&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: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Erik Rose (grincheroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calls from VBScript clobber passed args

Initial Comment:
I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:01

Message:
Logged In: YES 
user_id=849994

Agreed.

--

Comment By: Roger Upole (rupole)
Date: 2006-09-01 21:08

Message:
Logged In: YES 
user_id=771074

I think this is actually a vbscript behaviour.  If not, 
it's a bug in Pywin32's Active Scripting implementation.  
Either way, this shoud probably be closed as third-party.


--

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 15:41

Message:
Logged In: YES 
user_id=12

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

--

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 15:39

Message:
Logged In: YES 
user_id=12

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

--

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 15:39

Message:
Logged In: YES 
user_id=12

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

--

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

[ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars

[SourceForge.net]

Bugs item #1556784, was opened at 2006-09-12 02:43
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime's strftime limits strings to 127 chars

Initial Comment:
[I'm putting this in category Python Library, because I
assume Extensions Modules is for problems in the
Extensions Module plumbing.]


datetime.date and datetime.time's strftime() methods
call wrap_strftime(), which limits the length of the
format string to 127 chars before calling time.strftime().

This can be seen in the examples below.  Note that in
the third example, time.strftime() does not have a
problem with a 128 character format string.


>>> import datetime
>>> datetime.date.today().strftime('x'*128)
Traceback (most recent call last):
  File "", line 1, in 
MemoryError


>>> import datetime
>>> datetime.date.today().strftime('x'*256)
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/stringobject.c:4077: bad argument
to internal function


>>> import time
>>> time.strftime('x'*128)
''


Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:18

Message:
Logged In: YES 
user_id=849994

Thanks for the report, fixed in rev. 52072, 52073 (2.4),
52074 (2.5).

--

Comment By: Eric V. Smith (ericvsmith)
Date: 2006-09-12 22:12

Message:
Logged In: YES 
user_id=411198

See patch http://python.org/sf/1557390


--

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

[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError

[SourceForge.net]

Bugs item #1446043, was opened at 2006-03-09 00:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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: Unicode
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: osvenskan (osvenskan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:22

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52075, 52076 (2.4), 52077 (2.5).

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 19:17

Message:
Logged In: YES 
user_id=849994

I'd say that this should be fixed before 2.5 final.

Attached patch (the modname that's used for import may not
contain a dot anymore...)

--

Comment By: osvenskan (osvenskan)
Date: 2006-04-06 14:45

Message:
Logged In: YES 
user_id=1119995

I noticed that the documentation for unicode() says, "if the
encoding is not known, LookupError is raised". Regarding the
3rd parameter ("errors") to unicode(), the docs say, "Error
handling is done according to errors; this specifies the
treatment of characters which are invalid in the input
encoding. If errors is 'strict' (the default), a ValueError
is raised on errors..."
ref: http://docs.python.org/lib/built-in-funcs.html

That makes the code's current behavior doubly confusing
because a the documentation says that a ValueError is
reserved for indicating an undecodable byte sequence, not an
unknown encoding name.


--

Comment By: osvenskan (osvenskan)
Date: 2006-03-09 15:04

Message:
Logged In: YES 
user_id=1119995

There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot. 

Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report. 

Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.

Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level. 

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:16

Message:
Logged In: YES 
user_id=849994

Is it possible for an encoding name to contain dots at all?

If not, this would do too:
if '.' in modname: continue

--

Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 08:12

Message:
Logged In: YES 
user_id=89016

The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:

if ".".join(filter(None, modname.split("."))) != modname:
   return None


--

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

[ python-Bugs-1568243 ] init_types

[SourceForge.net]

Bugs item #1568243, was opened at 2006-09-30 09:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Submitted By: Bosko Vukov (bvukov)
>Assigned to: Martin v. Löwis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) 
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

--

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

[ python-Bugs-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount

[SourceForge.net]

Bugs item #1567331, was opened at 2006-09-28 21:36
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567331&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.RotatingFileHandler has no "infinite" backupCount

Initial Comment:
It seems to me that logging.RotatingFileHandler should
have a way to spell "never delete old log files".  This
is useful in situations where you want an external
process (manual or automatic) make decisions about
deleting log files.


--

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

[ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers

[SourceForge.net]

Bugs item #1483963, was opened at 2006-05-08 17:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('>> struct.unpack('=d', s)
(inf,)


--

Comment By: Michael Hudson (mwh)
Date: 2006-05-10 14:30

Message:
Logged In: YES 
user_id=6656

I'm glad my fix worked.  I'm not personally inclined to port the fixes to the 
2.4 
branch, as they are indeed fairly involved.

--

Comment By: Christian Hudon (chrish42)
Date: 2006-05-10 14:24

Message:
Logged In: YES 
user_id=980271

I had tried with 2.3.5 and 2.4.1 and the bug was present in
both versions. I just tried with svn HEAD, and the bug is
fixed there (at least in the revision that I tried). 

It'd be nice if this bug fix could be included in the next
2.4 point release, assuming the fix is not too complicated.
Is there a process for nominating bugfixes for the main-2.4
branch?

--

Comment By: Michael Hudson (mwh)
Date: 2006-05-10 12:17

Message:
Logged In: YES 
user_id=6656

Can you try Python from svn HEAD?  Or did you?

--

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

[ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources

[SourceForge.net]

Bugs item #1484556, was opened at 2006-05-09 10:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&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: Miki Tebeka (tebeka)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:34

Message:
Logged In: YES 
user_id=849994

Have all KlocWork issues been fixed now, Neal?

--

Comment By: Miki Tebeka (tebeka)
Date: 2006-06-04 09:53

Message:
Logged In: YES 
user_id=358087

I'll try to see if I can sneak it in, can't promise anything
though

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 14:26

Message:
Logged In: YES 
user_id=11375

The Coverity scans also probably report some of the same
bugs, so many of these problems may be fixed in the 2.5 trunk.  

If you're still evaluating, you could try running the tool
on the 2.5 trunk (snapshot available from
http://svn.python.org/snapshots/) and see if the results are
shorter.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-10 04:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

--

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

[ python-Feature Requests-1518621 ] optparse.parse_args() ret value seems to be a dict but isn't

[SourceForge.net]

Feature Requests item #1518621, was opened at 2006-07-07 09:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1518621&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: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: rhunger (rhunger)
Assigned to: Greg Ward (gward)
Summary: optparse.parse_args() ret value seems to be a dict but isn't

Initial Comment:
...
from optparse import OptionParser
parser = OptionParser()
...
(options, args) = parser.parse_args()
print options
...

options seems to be a dict but isn't. So it's not possible to use e.g.

print "Option 1: %(firstOption)s" % options

Here it's easy to use "options.firstOption" but with a larger number of program 
options it would be nice to be able to use "options" as a dict directly.

(patch attached)

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:46

Message:
Logged In: YES 
user_id=849994

In any case, this is a feature request.

--

Comment By: Greg Ward (gward)
Date: 2006-07-26 02:38

Message:
Logged In: YES 
user_id=14422

Don't believe __str__(): believe the docs.  In particular,
section 6.21.3.7 of the Python Library Reference is pretty
clear that options is not a dict.  See 
 
http://www.python.org/doc/2.4.3/lib/optparse-parsing-arguments.html

If you want a dict, no need to modify optparse: just use
vars(options).


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 04:06

Message:
Logged In: YES 
user_id=33168

Greg, are you using the Python tracker or only optik tracker?

--

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

[ python-Bugs-1545836 ] Incomplete info in 7.18.1 ZipFile Objects

[SourceForge.net]

Bugs item #1545836, was opened at 2006-08-24 09:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545836&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Taco (tacotortilla)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete info in 7.18.1 ZipFile Objects

Initial Comment:
Documentation: Python Library Reference 2.4.3

7.18.1 ZipFile Objects

The description for class ZipFile(file[, mode[,
compression]])
states the possible values for the parameter
"compression", but does not give any details on what
they do.
A nice table like this one would be prudent:

ZIP_STORED   Files stored with no compression
ZIP_DEFLATED Files stored with zlib "deflate" compression


Cheers

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:59

Message:
Logged In: YES 
user_id=849994

ZIP_STORED and ZIP_DEFLATED are explained on the zipfile
overview page.

--

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

[ python-Bugs-1546052 ] PyString_FromString() clarification

[SourceForge.net]

Bugs item #1546052, was opened at 2006-08-24 15:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546052&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Walther (cwalther)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyString_FromString() clarification

Initial Comment:
The documentation for PyObject* PyString_FromString(
const char *v) in the "Python/C API Reference Manual,
29 March 2006, Release 2.4.3", section 7.3.1 "String
Objects"
, does
not mention whether this function makes a copy of the
passed C string or just keeps the pointer.

Google provides some posts on various mailing lists and
forums that seem to indicate that it indeed does copy
the string (which is the right thing to do, of course).

Could something like to following be added to the
documentation?

"This function makes a copy of the string pointed to by
v, so you may modify or deallocate it afterwards
without affecting the Python object created by this
function."

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 12:04

Message:
Logged In: YES 
user_id=849994

Thanks for the suggestion! Added clarification in rev.
52078, 52079 (2.5).

--

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

[ python-Bugs-1559142 ] some section links (previous, up, next) missing last word

[SourceForge.net]

Bugs item #1559142, was opened at 2006-09-15 08:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Smith (thimsmith)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: some section links (previous, up, next) missing last word

Initial Comment:
The Previous, Up and Next links in the Library
Reference are often missing the last word.

Examples:

http://www.python.org/doc/current/lib/module-operator.html
"""Previous: 3.9 UserString Up: 3. Python Runtime
Services Next: 3.10.1 Mapping Operators to """

(Next link missing last word "Functions".)


http://www.python.org/doc/current/lib/weakref-example.html
"""Previous: 3.3.1 Weak Reference Objects Up: 3.3
weakref Next: 3.3.3 Weak References in """

(Next link missing last two words "Extension Types".)


There are *many* examples of this.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 12:10

Message:
Logged In: YES 
user_id=849994

This seems to be a "feature" of LaTeX2html. It limits the
links to three words.

--

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

[ python-Bugs-1193061 ] Python and Turkish Locale

[SourceForge.net]

Bugs item #1193061, was opened at 2005-04-30 20:37
Message generated for change (Comment added) made by usta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: S.�ağlar Onur (caglar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python and Turkish Locale

Initial Comment:
On behalf of this thread;

http://mail.python.org/pipermail/python-dev/2005-April/052968.html

As described in
http://www.i18nguy.com/unicode/turkish-i18n.html [ How
Applications Fail With Turkish Language
] , Turkish has 4 "i" in their alphabet. 

Without --with-wctype-functions support Python convert
these characters locare-independent manner in
tr_TR.UTF-8 locale. So all conversitons maps to "i" or
"I" which is wrong in Turkish locale. 

So if Python Developers will remove the wctype
functions from Python, then there must be a
locale-dependent upper/lower funtion to handle these
characters properly.


--

Comment By: �mer FADIL USTA (usta)
Date: 2006-09-30 18:58

Message:
Logged In: YES 
user_id=278064

http://img147.imageshack.us/img147/3717/pythonte4.jpg
I think this photo summarize the bug which is related to 
upper() in Turkish encoding.

--

Comment By: Eray Ozkural (exa)
Date: 2005-10-12 00:36

Message:
Logged In: YES 
user_id=1454

The better solution is to use an optional locale argument for 
upper/lower functions and other language-dependent text 
processing functions. 
 

--

Comment By: S.�ağlar Onur (caglar)
Date: 2005-05-02 11:45

Message:
Logged In: YES 
user_id=858447

No, im not. These rules defined in
http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and
http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt.
Note that there is a comments says;

# T: special case for uppercase I and dotted uppercase I
#- For non-Turkic languages, this mapping is normally
not used.
#- For Turkic languages (tr, az), this mapping can be
used instead of the normal mapping for these characters.
#  Note that the Turkic mappings do not maintain
canonical equivalence without additional processing.
#  See the discussions of case mapping in the Unicode
Standard for more information.

So without wctype functions support, python can't convert
these. This _is_ the problem. As a side effect of this,
another huge problem occurs, keywords can't be locale
dependent. If Python compiled with wctype support functions,
all "i".upper() turns into "İ" which is wrong for keyword
comparision ( like quit v.s QUİT )

So i suggest implement two new functions like
localeAwareLower()/localeAwareUpper() for python and let
lower()/upper() locale independent. And as you wrote locale
module may be a perfect home for these :)



--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-05-02 11:00

Message:
Logged In: YES 
user_id=38388

I'm not sure I understand: are you saying that the Unicode
mappings for upper and lower case are wrong in the standard ?

Note that removing the wctype functions will only remove the
possibility to use these functions for case mapping of
Unicode characters instead of using the builtin Unicode
character database. This was originally meant as
optimization to avoid having to load the Unicode database -
nowadays the database is always included, so the
optimization is no longer needed. Even worse: the wctype
functions sometimes behave differently than the mappings in
the Unicode database (due to differences in the Unicode
database version or implementation s).

Now, since the string .lower() and .upper() methods are
locale dependent (due to their reliance on the C functions
toupper() and tolower() - not by intent), while the Unicode
versions are not, we have a rather annoying situation where
switching from strings to Unicode cause semantic differences.

Ideally, both string and Unicode methods should do case
mapping in an locale independent way. The support for
differences in locale dependent case mapping, collation,
etc. should be moved to an external module, e.g. the locale
module.


--

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

[ python-Bugs-1568243 ] init_types

[SourceForge.net]

Bugs item #1568243, was opened at 2006-09-30 11:34
Message generated for change (Comment added) made by bvukov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Martin v. Löwis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) 
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


--

>Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 19:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 13:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

--

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

[ python-Bugs-1568075 ] GUI scripts always return to an interpreter

[SourceForge.net]

Bugs item #1568075, was opened at 2006-09-29 16:00
Message generated for change (Comment added) made by jejackson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: 5
Submitted By: jjackson (jejackson)
Assigned to: Jack Jansen (jackjansen)
Summary: GUI scripts always return to an interpreter

Initial Comment:
I installed the latest version of 2.5 from the web last night:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

When I run a wxPython script, using something like

pythonw myScript.py

from the Terminal, I find myself in an interpreter after I use the quit 
menu. The menubar becomes a single, hung python menu, and a shell 
window pops up with an interpreter prompt. Cntrl-D kills the interpreter.

It's as if python was stuck in "-i" mode:

pythonw -i myScript.py

gives the same results.

(python and pythonw give the same results. It appears from comments on 
the web that they are now the same. They appear so from a diff. If so, why 
not a symlink?)

Running the lastest wxPython demo gives this warning in the console, 

2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: 
_wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there 
are no autorelease pools in the stack.

which may or may not be related.


--

>Comment By: jjackson (jejackson)
Date: 2006-09-30 10:55

Message:
Logged In: YES 
user_id=1497873

No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by 
something else.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 00:47

Message:
Logged In: YES 
user_id=849994

Did you (or someone else) perhaps set the PYTHONINSPECT
environment variable? I can't imagine another cause for this
problem.

--

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

[ python-Bugs-1568075 ] GUI scripts always return to an interpreter

[SourceForge.net]

Bugs item #1568075, was opened at 2006-09-29 23:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: 5
Submitted By: jjackson (jejackson)
Assigned to: Jack Jansen (jackjansen)
Summary: GUI scripts always return to an interpreter

Initial Comment:
I installed the latest version of 2.5 from the web last night:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

When I run a wxPython script, using something like

pythonw myScript.py

from the Terminal, I find myself in an interpreter after I use the quit 
menu. The menubar becomes a single, hung python menu, and a shell 
window pops up with an interpreter prompt. Cntrl-D kills the interpreter.

It's as if python was stuck in "-i" mode:

pythonw -i myScript.py

gives the same results.

(python and pythonw give the same results. It appears from comments on 
the web that they are now the same. They appear so from a diff. If so, why 
not a symlink?)

Running the lastest wxPython demo gives this warning in the console, 

2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: 
_wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there 
are no autorelease pools in the stack.

which may or may not be related.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 18:24

Message:
Logged In: YES 
user_id=849994

Could you check if it is set? (using
echo $PYTHONINSPECT in a console?)

--

Comment By: jjackson (jejackson)
Date: 2006-09-30 17:55

Message:
Logged In: YES 
user_id=1497873

No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by 
something else.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 07:47

Message:
Logged In: YES 
user_id=849994

Did you (or someone else) perhaps set the PYTHONINSPECT
environment variable? I can't imagine another cause for this
problem.

--

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

[ python-Bugs-1568429 ] broken info files generation

[SourceForge.net]

Bugs item #1568429, was opened at 2006-09-30 20: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=1568429&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
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken info files generation

Initial Comment:
Hi,

Currently make -C Doc/info will not work. There are bugs 
in *.tex files which prevent py2texinfo from working. 
Also even after fixing these there are some weird 
constructs which later make makeinfo go mad.

Take a look at
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python-
info.patch
which has some fixes for that.

This one is important:
-level=1\optional{, parent\optional\{, 
directory\optional{,
-attributes=0
+level=1\optional{, parent\optional{, 
directory\optional{,
+attributes=0}


- unmatched {} + one wrongly quoted {

The other thing is using quote enviroment which is 
unknown to py2texinfo - change it to quotation.



--

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

[ python-Bugs-1568075 ] GUI scripts always return to an interpreter

[SourceForge.net]

Bugs item #1568075, was opened at 2006-09-29 16:00
Message generated for change (Comment added) made by jejackson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: 5
Submitted By: jjackson (jejackson)
Assigned to: Jack Jansen (jackjansen)
Summary: GUI scripts always return to an interpreter

Initial Comment:
I installed the latest version of 2.5 from the web last night:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

When I run a wxPython script, using something like

pythonw myScript.py

from the Terminal, I find myself in an interpreter after I use the quit 
menu. The menubar becomes a single, hung python menu, and a shell 
window pops up with an interpreter prompt. Cntrl-D kills the interpreter.

It's as if python was stuck in "-i" mode:

pythonw -i myScript.py

gives the same results.

(python and pythonw give the same results. It appears from comments on 
the web that they are now the same. They appear so from a diff. If so, why 
not a symlink?)

Running the lastest wxPython demo gives this warning in the console, 

2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: 
_wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there 
are no autorelease pools in the stack.

which may or may not be related.


--

>Comment By: jjackson (jejackson)
Date: 2006-09-30 14:48

Message:
Logged In: YES 
user_id=1497873

I tried:

Olivos:~ jj$ echo $PYTHONINSPECT

Olivos:~ jj$ 

Looks like it isn't set. 

However, this might be a wxPython bug. I tried a tcl/tk app from the demos:
Applications/MacPython 2.5/Extras/Demo/tkinter/guido/solitaire.py.

Quitting it worked fine. 

I'll post something on the wxPython mac list.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:24

Message:
Logged In: YES 
user_id=849994

Could you check if it is set? (using
echo $PYTHONINSPECT in a console?)

--

Comment By: jjackson (jejackson)
Date: 2006-09-30 10:55

Message:
Logged In: YES 
user_id=1497873

No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by 
something else.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 00:47

Message:
Logged In: YES 
user_id=849994

Did you (or someone else) perhaps set the PYTHONINSPECT
environment variable? I can't imagine another cause for this
problem.

--

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

[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems

[SourceForge.net]

Bugs item #1563630, was opened at 2006-09-22 13:19
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&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: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut  + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 22:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

--

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 17:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

--

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

[ python-Bugs-1563981 ] IDLE invokes completion even when running code

[SourceForge.net]

Bugs item #1563981, was opened at 2006-09-23 07:23
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563981&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: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE invokes completion even when running code

Initial Comment:
When you do

raw_input()
A

instead of putting the tab character into the input
buffer, IDLE opens the completion window. It should not
do this, since the user is interacting with its
application, not with the Python interpreter at this point.

--

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

[ python-Bugs-1567450 ] tabs missing in idle options configure

[SourceForge.net]

Bugs item #1567450, was opened at 2006-09-28 23:34
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&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: IDLE
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: jrgutierrez (jrgutierrez)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: tabs missing in idle options configure

Initial Comment:
1)The option to select indentation type (insert 
spaces or tabs) is missing
2) The indented width is ignored 

As a result IDLE 2.5 always indents inserting tabs, 
width 8

Sources edited in IDLE 2.4 cannot be corrected with 
IDLE 2.5:

The tabbing errors cannot be corrected with IDLE 2.5. 
You must revert to IDLE 2.4 


--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:39

Message:
Logged In: YES 
user_id=149084

See IDLE NEWS for 1.2a1.

The ability to configure tab insertion as a default
didn't work, and was removed.  You can set the default
by changing config-main.def:  [Indent] use-spaces=0
but Python policy is to strongly encourage spaces 
instead of tabs.

For any edit window, you can switch to tab indentation
by using the Format / Toggle Tabs menu selection.  When
using Tabs in an edit window, the indent width must be
eight spaces because of Tk limitations.

If a file uses tabs, you have to toggle tabs 'on' before
you start editing it.  IDLE doesn't yet have the ability to
detect whether a file uses tabs or spaces.  (A TAB indicator
in the status line would be useful.)

Note that Tabs are always used in the Shell window.

I'm not sure what you mean by "cannot be corrected".
The Format menu has Tabify and Untabify.  I suspect it
might be clearer if the dialog asking for 'tab width'
was changed to ask for 'indent width'.  I am able to
change back and forth between tabs and spaces in any
region, but it does take some care.

--

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