[issue2124] xml.sax and xml.dom fetch DTDs by default

[Virgil Dupras]

Virgil Dupras added the comment:

The blog page talked about 503 responses. What about issuing a warning 
on these responses? Maybe it would be enough to make developers aware of 
the problem?

Or what about in-memory caching of the DTDs? Sure, it wouldn't be as 
good as a catalog or anything, but it might help for the worst cases?

--
nosy: +vdupras

__
Tracker <[EMAIL PROTECTED]>

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

[issue2123] ctypes pointer not always keeping target alive

[Armin Rigo]

Armin Rigo added the comment:

We're finding such bugs because we are trying to reimplement ctypes in PyPy.

I guess your last question was "is it impossible to construct this 'bug'
without *reading* .contents?".  The answer is that it doesn't change
much; you can replace all the reads from .contents with reads from [0],
and still see the issue.  See attached y.py, where I've put the
equivalent C code in comments.

Added file: http://bugs.python.org/file9438/y.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2120] broken links in advocacy HOWTO

[Georg Brandl]

Georg Brandl added the comment:

Fixed in r60855, thanks!

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2126] BaseHTTPServer.py

[June Kim]

Changes by June Kim:


--
components: Library (Lib)
nosy: juneaftn, rhettinger
severity: normal
status: open
title: BaseHTTPServer.py
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2126] BaseHTTPServer.py and long POST from IE

[June Kim]

New submission from June Kim:

http://bugs.python.org/issue430160
http://bugs.python.org/issue427345

These two issues refer to the same bug, which occurs when there is a
POST from an Internet Explorer and the POST's content is long enough.
The issue was resolved by changing the CGIHTTPServer.py to consume the
remaining garbage. However, the bug potentially remains with
BaseHTTPServer.py(and hence its descendants like SimpleHTTPServer, and
3rd party libraries like MoinMoin's stand alone server).

People should have the knowledge of the IE POST bug and put the code
for treating it everytime when they use BaseHTTPServer.

Simple way to solve this is inserting the garbage consuming code in
the "finish" method:

while select.select([self.rfile], [],[],0)[0]:
   if not self.rfile.read(1): break

--
title: BaseHTTPServer.py -> BaseHTTPServer.py and long POST from IE

__
Tracker <[EMAIL PROTECTED]>

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

[issue2126] BaseHTTPServer.py fails long POST from IE

[June Kim]

Changes by June Kim:


--
title: BaseHTTPServer.py and long POST from IE -> BaseHTTPServer.py fails long 
POST from IE

__
Tracker <[EMAIL PROTECTED]>

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

[issue2127] sqlite3 docs should mention utf8 requirement

[Damien Elmes]

New submission from Damien Elmes:

The docs on http://docs.python.org/lib/sqlite3-Module-Contents.html
should mention that the connection string should always be UTF-8,
regardless of the encoding system of the underlying filesystem. See the
'note to windows users' on 

http://www.sqlite.org/c3ref/open.html

--
components: Documentation
messages: 62456
nosy: resolve1
severity: normal
status: open
title: sqlite3 docs should mention utf8 requirement
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1124861] subprocess fails on GetStdHandle in interactive GUI

[Daniel Serodio]

Daniel Serodio added the comment:

Is there any chance of having this fixed for 2.5.2 ?

_
Tracker <[EMAIL PROTECTED]>

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

[issue2129] Link error of gethostbyaddr and gethostname in Python Manuals (the chm file)

[June Kim]

New submission from June Kim:

Finding gethostname and gethostbyaddr entities from the index tab and 
clicking them in Python25.chm results in showing up the wrong section 
of 14.1.1 Process Parameters, instead of the proper section 17.2 
socket.

--
components: Documentation
messages: 62459
nosy: juneaftn
severity: minor
status: open
title: Link error of gethostbyaddr and gethostname in Python Manuals (the chm 
file)
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2128] sys.argv is wrong for unicode strings

[Giovanni Bajo]

New submission from Giovanni Bajo:

Under Windows, sys.argv is created through the Windows ANSI API.

When you have a file/directory which can't be represented in the 
system encoding (eg: a japanese-named file or directory on a Western 
Windows), Windows will encode the filename to the system encoding using
what we call the "replace" policy, and thus sys.argv[] will contain an
entry like "c:\\foo\\??.dat".

My suggestion is that:

* At the Python level, we still expose a single sys.argv[], which will 
contain unicode strings. I think this exactly matches what Py3k does now. 

* At the C level, I believe it involves using GetCommandLineW() and 
CommandLineToArgvW() in WinMain.c, but should Py_Main/PySys_SetArgv() be 
changed to also accept wchar_t** arguments? Or is it better to allow for 
NULL to be passed (under Windows at least), so that the Windows
code-path in there can use GetCommandLineW()/CommandLineToArgvW() to get
the current process' arguments?

--
components: Interpreter Core
messages: 62458
nosy: giovannibajo
severity: normal
status: open
title: sys.argv is wrong for unicode strings
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2110] Implement __format__ for Decimal

[Facundo Batista]

Facundo Batista added the comment:

Please, be my guest!

Thanks!

__
Tracker <[EMAIL PROTECTED]>

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

[issue2128] sys.argv is wrong for unicode strings

[Christian Heimes]

Christian Heimes added the comment:

The issue is related to #1342

Since we have dropped support for older versions of Windows (9x, ME,
NT4) I like to get the Python interface to argv, env and files fixed.

--
components: +Windows
nosy: +tiran
priority:  -> high
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2066] Adding new CNS11643, a *huge* charset, support in cjkcodecs

[Giovanni Bajo]

Giovanni Bajo added the comment:

Making the standard Windows Python DLL larger is not only a problem of
disk size: it will make all packages produced by PyInstaller or py2exe
larger, and that means lots of wasted bandwidth.

I see that MvL is still -1 on simply splitting CJK codecs out, and vetos
it by asking for a generalization work of insane proportion (a
hard-to-define PEP, an entirely new build system for Windows, etc.).

I understand (and *agree*) that having a general rule would be a much
superior solution, but CJK is already almost 50% of the python.dll, so
it *is* already a special case by any means. And special cases like
these  could be handled with special-case decisions.

Thus, I still strongly disagree with MvL and would like CJK be split out
 of python.dll as soon as possible. I would not really ask this for any
other modules but CJK, and understand that further actions would really
require a PEP and a new build system for Windows.

So, I ask again MvL to soften his position and reconsider the CJK
splitting in all its singularity. Please!

(in case it's not clear, I would prepare a patch to split CJK out anyday
if there were hopes that it gets accepted)

--
nosy: +giovannibajo

__
Tracker <[EMAIL PROTECTED]>

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

[issue1813] Codec lookup failing under turkish locale

[Antoine Pitrou]

Antoine Pitrou added the comment:

The C library's tolower() and toupper() are used in a handful of source
files. It might make sense to replace some of those calls with
ascii-only versions of the corresponding functions.

Modules/_sre.c:return ((ch) < 256 ? (unsigned int)tolower((ch)) : ch);
Modules/_sqlite/cursor.c:*dst++ = tolower(*src++);
Modules/stropmodule.c:  *s_new = tolower(c);
Modules/stropmodule.c:  *s_new = toupper(c);
Modules/stropmodule.c:  *s_new = toupper(c);
Modules/stropmodule.c:  *s_new = tolower(c);
Modules/stropmodule.c:  *s_new = toupper(c);
Modules/stropmodule.c:  *s_new = tolower(c);
Modules/unicodedata.c:h = (h * scale) + (unsigned char)
toupper(Py_CHARMASK(s[i]));
Modules/unicodedata.c:if (toupper(Py_CHARMASK(name[i])) !=
buffer[i])
Modules/_tkinter.c: argv0[0] = tolower(Py_CHARMASK(argv0[0]));
Modules/binascii.c: c = tolower(c);
Objects/stringobject.c: s[i] = _tolower(c);
Objects/stringobject.c: s[i] = _toupper(c);
Objects/stringobject.c: c = toupper(c);
Objects/stringobject.c: c = tolower(c);
Objects/stringobject.c: *s_new = toupper(c);
Objects/stringobject.c: *s_new = tolower(c);
Objects/stringobject.c: *s_new = toupper(c);
Objects/stringobject.c: *s_new = tolower(c);
Parser/tokenizer.c: else buf[i] = tolower(c);
Python/codecs.c:ch = tolower(Py_CHARMASK(ch));
Python/dynload_win.c:   first  = tolower(*string1);
Python/dynload_win.c:   second = tolower(*string2);
Python/pystrcmp.c:  while ((--size > 0) && (tolower(*s1) == tolower(*s2))) {
Python/pystrcmp.c:  return tolower(*s1) - tolower(*s2);
Python/pystrcmp.c:  while (*s1 && (tolower(*s1++) == tolower(*s2++))) {
Python/pystrcmp.c:  return (tolower(*s1) - tolower(*s2));

__
Tracker <[EMAIL PROTECTED]>

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

[issue1813] Codec lookup failing under turkish locale

[Antoine Pitrou]

Antoine Pitrou added the comment:

As for the .upper() and .lower() methods, they are used in quite a bunch
of standard library modules :-/...

Lib/base64.py
Lib/BaseHTTPServer.py
Lib/bsddb/test/test_compare.py
Lib/bsddb/test/test_dbobj.py
Lib/CGIHTTPServer.py
Lib/cgi.py
Lib/compiler/ast.py
Lib/ConfigParser.py
Lib/cookielib.py
Lib/Cookie.py
Lib/csv.py
Lib/ctypes/test/test_byteswap.py
Lib/ctypes/util.py
Lib/decimal.py
Lib/distutils/command/bdist_rpm.py
Lib/distutils/command/bdist_wininst.py
Lib/distutils/command/register.py
Lib/distutils/msvc9compiler.py
Lib/distutils/msvccompiler.py
Lib/distutils/sysconfig.py
Lib/distutils/tests/test_dist.py
Lib/distutils/util.py
Lib/email/charset.py
Lib/email/encoders.py
Lib/email/header.py
Lib/email/__init__.py
Lib/email/message.py
Lib/email/_parseaddr.py
Lib/email/test/test_email.py
Lib/email/test/test_email_renamed.py
Lib/encodings/idna.py
Lib/encodings/punycode.py
Lib/formatter.py
Lib/ftplib.py
Lib/gettext.py
Lib/htmllib.py
Lib/HTMLParser.py
Lib/httplib.py
Lib/idlelib/configDialog.py
Lib/idlelib/EditorWindow.py
Lib/idlelib/IOBinding.py
Lib/idlelib/keybindingDialog.py
Lib/idlelib/PyShell.py
Lib/idlelib/SearchDialogBase.py
Lib/idlelib/tabbedpages.py
Lib/idlelib/TreeWidget.py
Lib/imaplib.py
Lib/inspect.py
Lib/lib-tk/turtle.py
Lib/locale.py
Lib/logging/handlers.py
Lib/logging/__init__.py
Lib/_LWPCookieJar.py
Lib/macpath.py
Lib/mailcap.py
Lib/markupbase.py
Lib/mhlib.py
Lib/mimetools.py
Lib/mimetypes.py
Lib/mimify.py
Lib/msilib/__init__.py
Lib/nntplib.py
Lib/ntpath.py
Lib/nturl2path.py
Lib/optparse.py
Lib/os2emxpath.py
Lib/os.py
Lib/pdb.py
Lib/plat-irix5/flp.py
Lib/plat-irix6/flp.py
Lib/plat-mac/buildtools.py
Lib/plat-mac/gensuitemodule.py
Lib/plat-riscos/riscospath.py
Lib/pyclbr.py
Lib/rfc822.py
Lib/robotparser.py
Lib/sgmllib.py
Lib/SimpleHTTPServer.py
Lib/smtpd.py
Lib/smtplib.py
Lib/socket.py
Lib/sqlite3/test/hooks.py
Lib/sre_constants.py
Lib/stringold.py
Lib/stringprep.py
Lib/string.py
Lib/_strptime.py
Lib/subprocess.py
Lib/test/regrtest.py
Lib/test/test_bigmem.py
Lib/test/test_codeccallbacks.py
Lib/test/test_codecs.py
Lib/test/test_cookielib.py
Lib/test/test_datetime.py
Lib/test/test_decimal.py
Lib/test/test_deque.py
Lib/test/test_descr.py
Lib/test/test_fileinput.py
Lib/test/test_grp.py
Lib/test/test_hmac.py
Lib/test/test_httplib.py
Lib/test/test_os.py
Lib/test/test_smtplib.py
Lib/test/test_sort.py
Lib/test/test_ssl.py
Lib/test/test_strop.py
Lib/test/test_strptime.py
Lib/test/test_support.py
Lib/test/test_ucn.py
Lib/test/test_unicodedata.py
Lib/test/test_urllib2.py
Lib/test/test_urllib.py
Lib/test/test_wsgiref.py
Lib/test/test_xmlrpc.py
Lib/urllib2.py
Lib/urllib.py
Lib/urlparse.py
Lib/UserString.py
Lib/uuid.py
Lib/warnings.py
Lib/webbrowser.py
Lib/wsgiref/handlers.py
Lib/wsgiref/headers.py
Lib/wsgiref/simple_server.py
Lib/wsgiref/util.py
Lib/wsgiref/validate.py
Lib/xml/dom/minidom.py
Lib/xml/dom/xmlbuilder.py
Lib/xmllib.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2061] IDLE - autocompletion to support alternate path separators

[Tal Einat]

Tal Einat added the comment:

Umm, that's me being silly and forgetting to remove some backwards
compatibility stuff.

Revised (simpler) version attached.

Added file: 
http://bugs.python.org/file9439/IDLE_AutoComplete_path_separators.080216.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1813] Codec lookup failing under turkish locale

[Antoine Pitrou]

Antoine Pitrou added the comment:

Even if we don't fix all uses of (?to)(lower|upper) in the source tree,
I think it's important that codec and locale lookup work properly when
the current locale defines non-latin case folding for latin characters.
Here is a patch.

Perhaps also the str type should grow ascii_lower() and ascii_upper()
methods, since many cases of using lower() and upper() actually assume
ascii semantics (e.g. for parsing of HTTP or SMTP headers).

Added file: http://bugs.python.org/file9440/turklocale.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1813] Codec lookup failing under turkish locale

[Antoine Pitrou]

Changes by Antoine Pitrou:


--
versions: +Python 2.6 -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is an updated patch, to comply with the introduction of the
PyUnicode_ClearFreeList() function.

Added file: http://bugs.python.org/file9441/unialloc3.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1220212] os.kill on windows

[Technologov]

Technologov added the comment:

Yes, this feature would be very important for me too...

Anybody knows, _when_ it will be integrated into Python ?

If this bugzilla supports email notifications, Please add me as "CC" for
this bug.

-Technologov

--
nosy: +Technologov

_
Tracker <[EMAIL PROTECTED]>

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

[issue2130] [feature-request] Please add bool data type to "optparse" module

[Technologov]

New submission from Technologov:

hi !

Currently "optparse" module lacks "bool" data type parsing. It would be
nice to add this feature.

-Technologov, 16.02.2008.

--
components: Extension Modules
messages: 62469
nosy: Technologov
severity: normal
status: open
title: [feature-request] Please add bool data type to "optparse" module
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2131] "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files

[Technologov]

New submission from Technologov:

"codecs" module on Windows writes incorrect end-of-line, making it
impossible to write Unicode files.

See below, how-to reproduce bug (Python 2.5.1 on Windows XP)
===

#buggy unicode support module:
import codecs
filewr=codecs.open('myfile.txt','w','utf-8')
filewr.write("abc"+"\n")
===
Now, try to open this 'myfile.txt' using Windows Notepad.
The bug is perfectly visible.

The code below, will give correct results however:
===

filewr=open('myfile.txt','w')

filewr.write("abc"+"\n")
===
Basically this bugs _prevents_ me from writing Unicode text files.

NOTE: I'm not sure, if this bug should relate to "Windows" or "Unicode"
component.
NOTE: This bug is reproducible, even without writing Unicode characters.

-Technologov, 16.02.2008.

--
components: Unicode
messages: 62470
nosy: Technologov
severity: normal
status: open
title: "codecs" module on Windows uses incorrect end-of-line, wiriting broken 
Unicode (UTF-8) files
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2131] "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Could explain what exactly is wrong with the end-of-line on Windows ?

Note that "Unicode text files" on Windows are generally interpreted as
UTF-16 encoded files. Perhaps that's what makes you think there's a bug.

--
nosy: +lemburg

__
Tracker <[EMAIL PROTECTED]>

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

[issue1813] Codec lookup failing under turkish locale

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I agree that it's a bit unfortunate that the 8-bit string APIs in Python
use the locale aware C functions per default (this should really be
reversed: there should be locale-aware .upper() and .lower() methods and
the the standard ones should work just like the Unicode ones - without
dependency on the locale, using ASCII mappings), but for historical
reasons this cannot easily be changed.

.lower() and .upper() for 8-bit strings were always locale dependent and
before the addition of Unicode, setting the locale was the most common
way to make an application understand different character sets.

In Python 3k the problem will probably go away, since .lower() and
.upper() will then no longer depend on the locale.

Perhaps we should just convert a few of the cases you found to using
Unicode strings instead of 8-bit strings in 2.6 ?! That would both make
the code more portable and also provide a clear statement of "this is a
text string", making porting to Py3k easier.

--
nosy: +lemburg

__
Tracker <[EMAIL PROTECTED]>

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

[issue2131] "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files

[Technologov]

Technologov added the comment:

OK: try
filewr.write("abc"+"\n"+"abc")

The file will be generated with 7 bytes in it (must be 8, because
Windows has two-byte line-end).

Without using "codecs" modules, everything works fine, and the file will
have 8-bytes in it. (see 2nd example)

Plus, the text will be corrupted when opened with Windows Notepad.

-Technologov

__
Tracker <[EMAIL PROTECTED]>

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

[issue2131] "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files

[Antoine Pitrou]

Antoine Pitrou added the comment:

As stated in the codecs.open() docstring: """Files are always opened in
binary mode, even if no binary mode was specified. This is done to avoid
data loss due to encodings using 8-bit values""". This certainly means
you have to insert "\r\n" yourself (instead of just "\n") if you want
the file contents to respect the end-of-line convention under Windows...

--
nosy: +pitrou

__
Tracker <[EMAIL PROTECTED]>

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

[issue2124] xml.sax and xml.dom fetch DTDs by default

[Paul Boddie]

Paul Boddie added the comment:

(Andrew, thanks for making a bug, and apologies for not reporting this
in a timely fashion.)

Although an in-memory caching solution might seem to be sufficient, if
one considers things like CGI programs, it's clear that such programs
aren't going to benefit from such a solution. It would be interesting to
know what widely deployed software does use the affected parsers,
though. A Google code search might be helpful.

I think that the nicest compatible solution would be to have some kind
of filesystem cache for the downloaded resources, but I don't recall any
standard library caching solution of this nature. Things like being able
to write to a known directory, perhaps using the temporary file APIs
which should work even as a "very unprivileged" user, would be useful
properties of such a solution.

--
nosy: +pboddie

__
Tracker <[EMAIL PROTECTED]>

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

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

[Lea Wiemann]

Lea Wiemann added the comment:

Is this really necessary?

I see that the sorting code gets a little simpler, but I believe that 
there are valid use cases for cmp out there, where using a key would at 
least be cumbersome.  So why remove it when it's useful?

For instance, if you have an algorithm to determine the order in which 
any two elements should occur (and for some reason the algorithm 
satisfies transitivity) then it's usable as the cmp function, but 
turning it into a key function may be complicated (and adversly affect 
performance); you might end up having to map each element to a number 
or tuple describing the ordering properties of the element, which can 
be non-trivial.  Besides, it can also be non-obvious.

--
nosy: +LeWiemann

__
Tracker <[EMAIL PROTECTED]>

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

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

[Lea Wiemann]

Lea Wiemann added the comment:

"Non-obvious" to the novice that this technique can be used, and non-
obvious to the reader of the program.

I'm envisioning key functions that return long sequences of -1/0/1 
integers, or numbers between 0 and 2**50...  Not good.

Instead of removing cmp, I'd suggest simply placing a note in the 
documentation saying that key is preferred over cmp, to encourage 
readability.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2124] xml.sax and xml.dom fetch DTDs by default

[A.M. Kuchling]

A.M. Kuchling added the comment:

What if we just tried to make the remote accesses apparent to the user,
by making a warning.warn() call in the default implementation that was
deactivated by a setFeature() call.  With a warning, code will continue
to run but the user will at least be aware they're hitting a remote
resource, and can think about it, even if they decide to suppress the
warning.

We should also modify the docs to point this out; it's not likely to
help very much, but it's still worth doing.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1762] Inheriting from ABCs makes classes slower.

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

I'd like a second opinion about whether it's a good idea to commit the
attached patch, which moves abc._Abstract into object. Its effect is to
speed

  ./python.exe -m timeit -s 'import abc' -s 'class Foo(object):
__metaclass__=abc.ABCMeta' 'Foo()'

up from 2.5us to 0.201us. For comparison:

  $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object): pass'
'Foo()'
  1000 loops, best of 3: 0.203 usec per loop
  $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object):' -s '
 def __new__(cls): return super(Foo, cls).__new__(cls)' 'Foo()'
  100 loops, best of 3: 1.18 usec per loop
  $ ./python.exe -m timeit -s 'import abc' -s 'from decimal import
Decimal' 'Decimal()'
  10 loops, best of 3: 9.51 usec per loop


After this patch, the only slowdown I can find is an extra .5us in
isinstance, so I think it'll be time to close this bug.

Added file: http://bugs.python.org/file9442/optimize_abc.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

[Raymond Hettinger]

Changes by Raymond Hettinger:


__
Tracker <[EMAIL PROTECTED]>

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

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

[Lea Wiemann]

Lea Wiemann added the comment:

I know, but I don't always want to define the comparison on the object 
itself, because it's not an intrinsic feature of the object.  It's just 
the way I happen to sort it right now.  (That's especially likely if 
the ordering algorithm is complex.)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, an object with a complex element-to-element comparison can define 
an __lt__() method and have it work with sort, min, max, etc.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1404925] subprocess.Popen inside thread locks the thread in some case

[Leonid Evdokimov]

Leonid Evdokimov added the comment:

I confirm the bug.

Deadlock at Linux 2.6 (^C does not work):
Python 2.4.4 (#1, Jan  8 2008, 23:42:40) 
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2

Sometimes work and sometimes fails with fatal error at FreeBSD 6.3:
Python 2.4.4 (#2, Oct 31 2007, 05:20:42) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6

before Popen
before first line
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in
file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)
after last line  

And sometimes it deadlocks and ^C shows same traceback Ralf Schmitt
already posted.

--
nosy: +darkk

_
Tracker <[EMAIL PROTECTED]>

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

[issue2124] xml.sax and xml.dom fetch DTDs by default

[Martin v. Löwis]

Martin v. Löwis added the comment:

-1 on issuing a warning. I really cannot see much of a problem in this
entire issue. XML was designed to "be straightforwardly usable over the
Internet" (XML rec., section 1.1), and this issue is a direct
consequence of that design decision. You might just as well warn people
against using XML in the first place.

__
Tracker <[EMAIL PROTECTED]>

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