Logged In: YES 
user_id=987664

It's disappointing that after all that the fix that was
checked in eventually wasn't as complete as the patch I
provided (i.e. does not deal with Martin's complaint of not
catching e.g. CC=/usr/bin/icc).

Logged In: YES 
user_id=21627

Would you like to rework your patch so it applies to the
current configure.in? I'll apply it then right away
(although I still would like to see a patch that recognizes
icc by feature, not by name)

Logged In: YES 
user_id=987664

I don't have svn installed yet, so it would be a lot of
doing at the moment. That's on my list of things to do but
don't have time right now and I doubt anyone else has time
for this trivial thing. So I guess just forget it, sorry
about the frustration.

Closed related bug 1162001 as fixed.

Bug 1158313 (requesting functions for heap iteration)
was rejected, one of the reasons being that iteration
does not fit well with the module design providing
helper functions.

Here is an implementation of a Heap class for that
module that encapsulates a list. It supports iteration
as well as the usual keyword arguments passed to sort()
or sorted(): key, cmp, reversed. It further supports
skipping the heapify step (heapify=True/False) when
constructing the heap as well as copying the list if
unnecessary (copy=True/False). The latter is generally
discouraged and not the default. It is, however, useful
for one-shot sequence generation as in

>>> h = Heap([ random() for i in range(1000) ], copy=False)

A further feature (somewhat obvious for heaps) is that
iteration is not interrupted by items being pushed on
the heap, they are simply integrated.

"heapreplace" is supported by a "pushpop" function as
initially proposed by R. Hettinger. It always returns
the smallest item, also considering the one being pushed.

This implementation is complementary to the existing
functions that work on arbitrary (mutable) sequences.
Both have their use cases and both make sense in the
module. The Heap class has the additional advantage of
encapsulating the list and thus allowing to support
special item comparisons in a consistent way.

There is not yet any documentation or unit tests, but
they should be easy to write once the Heap class is
actually considered for integration.

Logged In: YES 
user_id=313935

Forgot undecoration in __getitem__ method. Updated patch.

Logged In: YES 
user_id=313935

The semantics of combining cmp and key are not specified in
the Python documentation and my last implementation differed
from the semantics of sort() and sorted() in that regard.
The new patch fixes this and does some clean up. It also
introduces a method iter_clone() that returns an independent
iterator.

Logged In: YES 
user_id=313935

assigned to rhettinger

Logged In: YES 
user_id=313935

The things that pychecker doesn't tell you ...

Can you please provide patches to Doc/lib/libheapq.tex and Lib/test/test_heapq.py? Please also put doc strings into the class.

Please drop the type assertions in __init__. I find it quite magical that it will silently turn copy on if the iterator doesn't support len or indexing.

Why is iteration through the heap destructive? No other container has that feature.

Putting the sanity checks into the module isn't necessary - just use the regular test suite for that.

I can't comment further - lack of comments in the patch prevents me from actually understanding it. In the current form, I recommend rejection.

Unassigning Raymond.

This small patch makes it possible to display a path including non-
ASCII chars as the title of Editor Window.  See the screen shots of 
original IDLE and patched one.

Logged In: YES 
user_id=21627

I think the patch is wrong/not general enough:
- if decoding fails for some reason, it should continue anyway
- I'm not sure where the title comes from, but it might be
that it is a file name. If so, it should use
sys.getfilesystemencoding() instead of IOBinding.encoding.
This matters only on systems where these might differ, e.g.
MacOSX.

Logged In: YES 
user_id=495142

Thank you for your comment.

First, indeed some titles may fail to be decoded, but it will be sufficient to 
use 'ignore' as the error handling scheme.  At least it gives more readable 
titles than the present "mojibake'd" ones.

Second, the title comes from either sys.argv or tkFileDialog.  tkFileDialog 
calls tk_getOpenFile and tk_getSaveFile of Tck/Tk.  So you are right.  It 
would be better to use sys.getfilesystemencoding().  Note that the patch 
does not affect any unicode titles.

As for OSX, it seems that tk_getOpenFile sometimes returns a broken 
string unless you set LANG so as to use UTF-8 (en_US.UTF-8, 
ja_JP.UTF-8 etc.).  You can see it as follows:

$ LANG=ja_JP.SJIS wish8.4
% tk_getOpenFile

For a folder name of Japanese characters, you will get a broken result; it is 
neither UTF-8 nor SJIS.  The same problem applies to eucJP.  It is a bug 
of Tcl/Tk (I found it in Aqua Tcl/Tk 8.4.9) and affects the original IDLE, too.

All in all, it would be the most reasonable to use 
sys.getfilesystemencoding() and 'ignore' scheme for now.

Logged In: YES 
user_id=21627

Hmm. When the string comes from sys.argv, it should be in
the user's preferred encoding, not in the file system
encoding, which would suggest that the current code is right.

When the string comes from tk_getOpenFile, I would expect to
get a Unicode string back instead of a byte string. I can
believe that Tk fails for OSX here: it relies on Tcl's glob
command, which apparently assumes that "encoding system" is
used for the file system; try

 >>> [unicode(x) for x in t.tk.call(('glob','*'))]

There are more issues OSX glob, e.g. for Latin characters,
it processes the decomposed form inconveniently, see

http://sourceforge.net/tracker/?func=detail&aid=823330&group_id=10894&atid=110894

So I think it is fine to display question marks on OSX if
necessary;in general, it now seems that the locale's
encoding should be used indeed.

Logged In: YES 
user_id=495142

I'm sorry, but the previous patches are insufficient to handle non-ASCII file 
names.
The menu "Recent Files" in "File" in the menu-bar does not display such 
names correctly.
In addition, when updating the "Recent Files" menu, UnicodeDecodeError 
raises in _implicit_ conversion of unicode filename given by tkFileDialog to 
ASCII string.

So I made a new patch.  Do not use the previous patches, please.
The new patch converts every multi-byte file name into unicode early in 
IOBinding; thus the file path is correctly displayed in the title bar.  
And it converts every unicode name into multi-byte string explicitly when 
updating the menu.
Note that IDLE writes the recent file names as a text file.  Conversion into 
string is necessary anyway.

Logged In: YES 
user_id=495142

In the typical usage of IDLE, sys.argv[] are given to "pythonw" command
by the window system.  Thus, in almost all cases, they are in the
filesystem encoding.

I believe IDLE with the last patch will run well on OS X (as well as on
Windows etc.) if the Tcl/Tk bug of OS X is fixed someday, or the
environment variable LANG is set to use UTF-8 for now.

Logged In: YES 
user_id=21627

On what operating system is sys.argv in file system encoding
(i.e. in the encoding that open(2) expects), and not in the
locale's encoding? AFAIK, both Linux and Windows use the
locale's encoding for sys.argv (but then, they also use the
same encoding for the file system).

Logged In: YES 
user_id=495142

When you install Python in Windows, you will get 
"Edit with IDLE" entry in the context menu for *.py file.
The entry launches the pythonw.exe with the name of
*.py file as one of the sys.argv[] parameters.

See the registry: 
HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE\command

There you will see:
"C:\Python24\pythonw.exe" "C:\Python24\Lib\idlelib\idle.pyw"
-n -e "%1"

I thought the file name given here as "%1" would be what
open(2) accepts.

Logged In: YES 
user_id=21627

On Windows, both argv and file names are encoded as "mbcs",
which is both the locale's encoding, and the file system
encoding. The interesting question is: how are command line
arguments encoded on OSX (which is the only system which has
a file system encoding independent of the locale)?

Logged In: YES 
user_id=495142

On OS X, any command line which you type in is encoded
to what Terminal.app specifies.

If it is other than UTF-8, you will see broken display for
non-ASCII file names when listing them in Terminal.app.

If does not match with LANG, line editing in bash will be
somewhat useless for multi-byte characters.

In Japan, seasoned Unix users tend to use EUC-JP on
OS X, and they also tend to restrict their file names to
ASCII.  They use EUC-JP in their program sources,
LaTeX files, command messages, etc.  It has been a
long tradition how you use Unix in Japan since circa
1990.  Thus the broken display for non-ASCII file names
does not bother them.

Some newfangled Unix users use UTF-8 characters in
command line on OS X.  And many other OS X users,
who use national characters for their file names natullay,
do not use command line at all.

In theory, you can use some non-UTF8 encoding for a
non-ASCII file name in your command line.  However,
in practice for now, it seems very unlikely on OS X.

Logged In: YES 
user_id=21627

Yes, IMO it is really said that there is no programmatic way
to determine the encoding of Terminal.app (an ioctl would be
nice).

Logged In: YES 
user_id=149084

I'm monitoring :-)
Martin knows far more than I do about these things.

Logged In: YES 
user_id=495142

I was afraid you might not notice that the patch has
to do with freezing of IDLE.  Indeed my IDLE on
Windows XP has been very freeze-free since applying it.

Logged In: YES 
user_id=495142

I have revised the patch so that any
unicode results from tkFileDialog are
always converted to strings.  Now it is
more conservative in that unicodes are
used minimally for file names.

Logged In: YES 
user_id=21627

Thanks for the patch. Committed as r41551.

The POSIX spec states that these may be defined as (-1) to state 
non-compliance.  Python doesn't respect that.  This patch (against 
2.4.1rc1, CVS is borked) fixes that.

Without this patch, Python will not work on "some operating 
systems" unless threading is disabled entirely.

Logged In: YES 
user_id=21627

The attached file appears not to be a patch file, but a file
containing a single line

/Volumes/Crack/download/posix_semaphores-2.4.1rc1.patch

Logged In: YES 
user_id=139309

uh oh, must be another bug in the OS I'm using (or sourceforge)...

Hopefully this is suitable for now, the patch is near trivial anyway:

--- Python-2.4.1c1/Python/thread_pthread.h  2004-07-07 
13:44:12.000000000 -0400
+++ /Users/bob/src/Python-2.4.1c1/Python/thread_pthread.h   
2005-03-14 14:54:00.000000000 -0500
@@ -16,9 +16,13 @@
    family of functions must indicate this by defining
    _POSIX_SEMAPHORES. */
 #ifdef _POSIX_SEMAPHORES
+#if _POSIX_SEMAPHORES == -1
+#define HAVE_BROKEN_POSIX_SEMAPHORES
+#else
 #include <semaphore.h>
 #include <errno.h>
 #endif
+#endif

 #if !defined(pthread_attr_default)
 #  define pthread_attr_default ((pthread_attr_t *)NULL)

Logged In: YES 
user_id=29957

Checked in on the 2.4 branch and the trunk. Thanks for the
patch!

Go to <http://python.org/Quotes.html>.
Click "See also this list of other Python users."
See <http://www.python-in-business.org/success/> is broken:
  	
Site Error

An error was encountered while publishing this resource.

KeyError
Sorry, a site error occurred.

Traceback (innermost last):

    * Module ZPublisher.Publish, line 150, in
publish_module
    * Module
Products.PlacelessTranslationService.PatchStringIO,
line 51, in new_publish
    * Module ZPublisher.Publish, line 114, in publish
    * Module Zope.App.startup, line 202, in
zpublisher_exception_hook
    * Module ZPublisher.Publish, line 98, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 39, in call_object
    * Module Products.CMFCore.PortalContent, line 116,
in __call__
    * Module Shared.DC.Scripts.Bindings, line 306, in
__call__
    * Module Shared.DC.Scripts.Bindings, line 343, in
_bindAndExec
    * Module Products.CMFCore.FSPageTemplate, line 191,
in _exec
    * Module Products.CMFCore.FSPageTemplate, line 124,
in pt_render
    * Module Products.PageTemplates.PageTemplate, line
95, in pt_render
      <FSPageTemplate at /pbf/document_view used for
/pbf/success/index_html>
    * Module TAL.TALInterpreter, line 200, in __call__
    * Module TAL.TALInterpreter, line 244, in interpret
    * Module TAL.TALInterpreter, line 703, in do_useMacro
    * Module TAL.TALInterpreter, line 244, in interpret
    * Module TAL.TALInterpreter, line 703, in do_useMacro
    * Module TAL.TALInterpreter, line 244, in interpret
    * Module TAL.TALInterpreter, line 473, in
do_setLocal_tal
    * Module Products.PageTemplates.TALES, line 220, in
evaluate
      URL: /pbf/main_template
      Line 15, Column 4
      Expression: standard:'portal_properties/title'
      Names:

{'container': <PloneSite instance at 9ec2250>,
 'default': <Products.PageTemplates.TALES.Default
instance at 0x8742924>,
 'here': <Document at /pbf/success/index_html>,
 'loop': <SafeMapping instance at 92e2760>,
 'modules':
<Products.PageTemplates.ZRPythonExpr._SecureModuleImporter
instance at 0x8728f34>,
 'nothing': None,
 'options': {'args': ()},
 'repeat': <SafeMapping instance at 92e2760>,
 'request': <HTTPRequest,
URL=http://localhost:9683/pbf/success/index_html>,
 'root': <Application instance at 9ff2d90>,
 'template': <FSPageTemplate at /pbf/document_view used
for /pbf/success/index_html>,
 'traverse_subpath': [],
 'user': Anonymous User}

    * Module Products.PageTemplates.Expressions, line
201, in __call__
    * Module Products.PageTemplates.Expressions, line
189, in _eval
    * Module Products.PageTemplates.Expressions, line
141, in _eval
      __traceback_info__: portal_properties

KeyError: portal_properties (Also, an error occurred
while attempting to render the standard error message.)

Troubleshooting Suggestions

    * The URL may be incorrect.
    * The parameters passed to this resource may be
incorrect.
    * A resource that this resource relies on may be
encountering an error.

For more detailed information about the error, please
refer to the error log.

If the error persists please contact the site
maintainer. Thank you for your patience. 

Logged In: YES 
user_id=30164

Crap, this is a bug, not a patch.  Sorry about that.  If
you'd like, I can resubmit it as a bug :(

Logged In: YES 
user_id=488897

You are right that the link is broken, but this is not a
Python bug. It's better to write to the web master at
webmaster@python.org to get this link fixed.
--Michiel.

Logged In: YES 
user_id=21627

I also mailed the webmaster of python-in-business.org; maybe
the site can be fixed.

I the course of looking at bug 1153075 (which is a nastier problem) I 
found a couple of sillies: no checking was done that a user defined 
mro() function returns a sequence or that said sequence contains 
types or classes.  This patch fixes this, at least, and I'd like to get it 
into 2.4.1.

Logged In: YES 
user_id=6656

Argh, this is what I meant to upload.

Logged In: YES 
user_id=80475

Are you sure to want to backport this directly to a release
candidate without it having lived on the head for a while? 
Seems a little dangerous at this stage for something that is
arguably not actually broken right now.

Logged In: YES 
user_id=6656

Well, possibly I'm rushing unecessarily.

OTOH "arguably not actually broken" is simply not true.

Logged In: YES 
user_id=80475

If I read it correctly, you're adding useful argument
checking that is helpful when the user does something wrong.
 However, nothing is currently preventing them from using it
correctly.

Unless it is a critical fix, it should probably go on the
head and ultimately into Py2.4.2.

Logged In: YES 
user_id=6656

You have appreciated that these are crash bugs? I think it's
a little bit more than "useful argument checking".

OTOH, essentially noone defines mro() functions so it's not
that big a deal.

This was committed as r41845, as part of #1153075, AFAICT. mwh, if you think there are still changes pending, please resubmit.

ConfigParser is module which parses commonly used 
INI files. It gets sections from file and values from 
sections. By now, it gets from file key and value divided 
by symbol ":" or "=".

For FTN application, a want to use FTN addresses as 
keys. FTN address looks like "2:5020/12000". So if I try 
to use it as key, ConfigParser considers "2" as key 
and "5020/12000 = ..." as value. 

I made patch, which allows to use any set of symbols 
(or '=' and ':' by default for compatibility) as delimitier 
between key and value in INI file.

Note: delimmap doesn't look like it's needed.  Should be able to just check if vi in self.delim.  (Although I'm kinda tired and don't feel like thinking too hard, so maybe that's just bs.).

I think the basis of this patch is a good one; I think 'delimiter' should be plural as delimiters, but that might be all picky. :)

I don't think "self.delimmap = map(lambda x: x, self.delim)" should be done; map and lambda aren't needed here. Wouldn't it be cleaner to just accept a list and join it instead? More Pythonic? Since delimiter=":=" to me looks like you want the string ":=" to be a delimiter, but I might be having pascal flashbacks. To me its more clear.

E.g.:

def __init__(self, defaults=None, delimiters=(':', '=')):
    self._delimiters = ''.join(delimiters)

As stated below, you don't need delimmap; "if vi in self.delim" will work fine.

Anyways, all that aside (and that's just opinions, but--):
  1) The patch no longer applies cleanly to the HEAD. I believe it would be very straightforward to fix the patch up though.
  2) It needs documentation, and
  3) It definitely needs tests added to test_cfgparser.

It actually turns out this patch would make *my* life easier, so instead of leaving it to the original submitter to make current and add stuff to,  I modified it and added docs and tests as 1682942.

This patch is (a first draft of) an attempt to make
Python properly use size_t where necessary. This work
is triggered by compilation on Win64 (where the
compiler warns about potential truncation errors a
lot). The rationale for the patch is that size_t might
be larger than int, in particular on 64-bit platforms,
and that the size of a memory chunk cannot reliably be
measured with an int.

It turns out that using size_t is not enough, since
values can sometimes also be negative. For these cases,
a "signed" size_t is used, which is called Py_ssize_t
and is a define for ssize_t if the compiler supports
the latter.

The guideline for converting int to size_t used in this
patch is this:
- if the variable is meant to store the number of
bytes, and is always guaranteed to be positive, and
could get arbitrarily large, use size_t
- if the value could be negative also, use ssize_t
- if the value is meant to store a number of "things",
but this directly translates into size_t (e.g. number
of pointers, number of characters), also use size_t/ssize_t
- if the value is in a range limited to 32-bit int
(e.g. the number of characters in a path name), convert
the size_t to int, after asserting that the value
really is in the range.

This version is work in progress, and needs review. I
hope to work on it during the sprints at PyConDC.

Logged In: YES 
user_id=21627

Second version of the patch attached (PyCon version). It turns out that 
changing everything from signed to unsigned breaks too many things, so 
this version of the patch uses Py_ssize_t in nearly all places.

Logged In: YES 
user_id=21627

This patch is now maintained in

http://svn.python.org/projects/python/branches/ssize_t/

Logged In: YES 
user_id=21627

And now it is part of the trunk.

Ok, this is the result of last discussion in python-dev.

I changed _convert_other() to make it return
NotImplemented, and check in every place where it's
called to pass back the NotImplemented (something
similar suggested Michael Hudson in the discussion: he
passed back "other", but I think is cleaner just to
pass the signal, and let the architecture to do
whatever it should).

The tests runs ok, seeing a +1.8% in test_decimal time.

I'm sending this to you, because I...

- Don't get to understand from the discussion if this
is something that should be fixed at this level or at
another.

- Don't really know if this solution is as clean as it
seems.

Thanks! 

.    Facundo

Logged In: YES 
user_id=80475

I had checked in my own patch for the rop issue.  Please cross-
check these two patches to see if one did something that the 
other had not.

Logged In: YES 
user_id=752496

Yours is slightly better, :).