[issue7361] importlib not checking bytecode length

2010-02-03 Thread Brett Cannon

Brett Cannon  added the comment:

I can't reproduce the failure as running test_multiprocessing and then 
test_importlib does not show any left over stuff in the interpreter what would 
lead to importlib being used for __import__. But as the IndexError part is a 
valid issue I am renaming the issue.

--
title: Strange importlib error during test_multiprocessing failure -> importlib 
not checking bytecode length

___
Python tracker 

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



[issue7829] dis module documentation gives no indication of the dangers of bytecode inspection

2010-02-03 Thread Brett Cannon

Changes by Brett Cannon :


--
priority:  -> low
stage:  -> needs patch

___
Python tracker 

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



[issue2874] Remove use of the stat module in the stdlib

2010-02-03 Thread Brett Cannon

Brett Cannon  added the comment:

OK, this ain't ever going to happen, so I am just going to close this issue.

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

___
Python tracker 

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



[issue7838] Undocumented subprocess functions on Windows

2010-02-03 Thread Georg Brandl

Georg Brandl  added the comment:

I agree.  Docstrings never hurt.

--

___
Python tracker 

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



[issue7844] Add -3 warning for absolute imports.

2010-02-03 Thread Mark Dickinson

New submission from Mark Dickinson :

It would be good to have a -3 warning for any use of import in 2.7 whose 
semantics change in 3.x, as a result of the absolute imports PEP (PEP 328).

--
components: Interpreter Core
messages: 98781
nosy: mark.dickinson
severity: normal
status: open
title: Add -3 warning for absolute imports.
versions: Python 2.7

___
Python tracker 

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



[issue5677] Serious interpreter crash and/or arbitrary memory leak using .read() on writable file

2010-02-03 Thread Stefan Krah

Stefan Krah  added the comment:

The new patch takes over the logic from fileio.c. Tested on Linux, Windows 
x86/x64 and OpenSolaris.

--
Added file: http://bugs.python.org/file16115/add-readable-writable.patch

___
Python tracker 

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



[issue7845] complex.__lt__ should return NotImplemented instead of raising TypeError

2010-02-03 Thread Mark Dickinson

New submission from Mark Dickinson :

Currently in py3k, order comparisons for complex numbers raise a TypeError.  
This was necessary in Python 2.x in order to make a complex <-> complex 
comparison raise an exception.  In 3.x, it's no longer necessary, since if both 
sides of a comparison return NotImplemented the result of the comparison is a 
TypeError (in 2.x the result is a value based on comparing the ids).

In py3k, complex.__lt__ could be changed to always return NotImplemented.  This 
would allow a custom class to implement its own comparisons with complex, and 
would remove an unnecessary special case.

--
assignee: mark.dickinson
components: Interpreter Core
messages: 98783
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: complex.__lt__ should return NotImplemented instead of raising TypeError
type: behavior
versions: Python 3.2

___
Python tracker 

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



[issue7845] complex.__lt__ should return NotImplemented instead of raising TypeError

2010-02-03 Thread Mark Dickinson

Changes by Mark Dickinson :


--
stage:  -> needs patch

___
Python tracker 

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



[issue7844] Add -3 warning for absolute imports.

2010-02-03 Thread Eric Smith

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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



[issue5211] Fix complex type to avoid coercion in 2.7.

2010-02-03 Thread Mark Dickinson

Mark Dickinson  added the comment:

Yes, I'd certainly be interested in reviewing a patch.  Though the current 
behaviour is at most a minor wart, and since it's gone in Python 3.x the 
motivation to fix it isn't huge. :)

> Where as I think gumtree wants the xcomplex case to behave as
> the xfloat case, e.g. ...

Yes, that was what I was proposing.  But as you point out, the new behaviour 
wouldn't even match the behaviour of Python 3.x, so it really wouldn't be a 
terribly useful change.

> However, if we are going to do that then we might as well just
> backport the whole removal of coercion.

That's not really an option:  it has the potential to break existing code that 
uses coercion.  Removing coercion in Python 2.x would require at least a PEP 
plus one version's worth of DeprecationWarning.  And given that it currently 
looks as though Python 2.8 isn't likely to happen at all, that would likely be 
a wasted effort.

--

___
Python tracker 

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



[issue7788] segfault when deleting from a list using slice with very big `step' value

2010-02-03 Thread Mark Dickinson

Mark Dickinson  added the comment:

This patch is producing warnings about signed <-> unsigned comparisons on the 
Windows buildbots;  these should be fixed.  See:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.6/builds/781/steps/compile/logs/warnings

--
priority: release blocker -> normal
status: closed -> open

___
Python tracker 

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



[issue7846] Fnmatch cache is never cleared during usage

2010-02-03 Thread Andrew Clegg

New submission from Andrew Clegg :

The fnmatch module has a cache of translation between glob patterns and 
compiled regular expressions. However this cache is never emptied; only added 
to. I am writing a python program which as part of its execution checks 
millions of unique globs - this causes the fnmatch cache to grow enormous.

Attached is a patch to limit the size of the fnmatch cache to 100 (chosen to be 
the same size as the re module).

--
components: Library (Lib)
files: fnmatch.patch
keywords: patch
messages: 98786
nosy: andrewclegg
severity: normal
status: open
title: Fnmatch cache is never cleared during usage
versions: Python 2.5
Added file: http://bugs.python.org/file16116/fnmatch.patch

___
Python tracker 

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



[issue7846] Fnmatch cache is never cleared during usage

2010-02-03 Thread Brian Curtin

Changes by Brian Curtin :


--
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

___
Python tracker 

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



[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6

2010-02-03 Thread Fred L. Drake, Jr.

Changes by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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



[issue7838] Undocumented subprocess functions on Windows

2010-02-03 Thread Brian Curtin

Brian Curtin  added the comment:

Here's a patch which keeps docstrings, and explicitly qualifies the Windows 
specific functions from _subprocess rather than using import * (which causes a 
couple of lines just over 79 chars). Now the functions are more hidden than 
before.

Ran the tests to be sure I got each change, nothing seems to have slipped by.

--
Added file: http://bugs.python.org/file16117/issue7838_v2.diff

___
Python tracker 

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



[issue6716] Windows install error when choosing to compile .py files

2010-02-03 Thread Brian Curtin

Brian Curtin  added the comment:

I just saw this today while installing the 3.1.1 final MSI on a Server 2003 box.

--
components: +Windows
nosy: +brian.curtin
priority:  -> high
stage:  -> needs patch
type: compile error -> behavior

___
Python tracker 

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



[issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE

2010-02-03 Thread Stefan Krah

Stefan Krah  added the comment:

I tested bsd3.diff on OpenBSD-4.4/py3k and it works fine. ncurses
doesn't build and I get a libssl assertion failure in test_ftplib,
but without the patch I can't build py3k at all.
 
This is a significant improvement, so +1 for applying the patch.

--
nosy: +skrah

___
Python tracker 

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



[issue7845] complex.__lt__ should return NotImplemented instead of raising TypeError

2010-02-03 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

+1

--
nosy: +rhettinger

___
Python tracker 

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



[issue7847] Remove 'python -U' or document it

2010-02-03 Thread Barry A. Warsaw

New submission from Barry A. Warsaw :

Python 2.x supports a -U flag which has the effect largely the same as 'from 
__future__ import unicode_literals'.  However -U is undocumented anywhere 
except import.c.  We should either remove -U support from Python 2.7 or 
document it (and indicate in that documentation that the future import is 
preferred).

--
messages: 98791
nosy: barry
severity: normal
status: open
title: Remove 'python -U' or document it
versions: Python 2.7

___
Python tracker 

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



[issue7847] Remove 'python -U' or document it

2010-02-03 Thread Georg Brandl

Changes by Georg Brandl :


--
assignee:  -> loewis
nosy: +loewis

___
Python tracker 

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



[issue7847] Remove 'python -U' or document it

2010-02-03 Thread Marc-Andre Lemburg

Marc-Andre Lemburg  added the comment:

Barry A. Warsaw wrote:
> 
> New submission from Barry A. Warsaw :
> 
> Python 2.x supports a -U flag which has the effect largely the same as 'from 
> __future__ import unicode_literals'.  However -U is undocumented anywhere 
> except import.c.  We should either remove -U support from Python 2.7 or 
> document it (and indicate in that documentation that the future import is 
> preferred).

+1 on removing it.

It has been deliberately been undocumented since Python 2.2
in order to be able to phase out its use and finally remove it.

--
nosy: +lemburg

___
Python tracker 

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



[issue7848] copy.copy corrupts objects that return false value from __getstate__

2010-02-03 Thread Albertas Agejevas

New submission from Albertas Agejevas :

When copy.copy is used on an object whose __getstate__ returns 0, it can 
produce a corrupt copy of an object:

>>> import copy
>>> class Foo(object):
... def __init__(self):
...self.value = 0
... def __getstate__(self):
...return self.value
... def __setstate__(self, v):
...self.value = v
... 
>>> one = Foo()
>>> two = copy.copy(one)
>>> two.value
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Foo' object has no attribute 'value'

Pickling/unpickling works fine for this object, so this appears to be a bug in 
copy._reconstruct.

This is not a contrived example, BTrees.Length.Length from ZODB uses such a 
__getstate__.

--
components: Library (Lib)
messages: 98793
nosy: alga
severity: normal
status: open
title: copy.copy corrupts objects that return false value from __getstate__
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

___
Python tracker 

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



[issue6715] xz compressor support

2010-02-03 Thread Arkadiusz Miskiewicz Arkadiusz Miskiewicz

Arkadiusz MiskiewiczArkadiusz Miskiewicz 
 added the comment:

About why xz is important. 

gnu.org, tug.org started publishing sources in xz format, quick grep:

autoconf/autoconf.spec:Source0: 
http://ftp.gnu.org/gnu/autoconf/%{name}-%{version}.tar.xz
coreutils/coreutils.spec:Source0:   
http://ftp.gnu.org/gnu/coreutils/%{name}-%{version}.tar.xz
libpng12/libpng12.spec:Source0: 
http://downloads.sourceforge.net/libpng/libpng-%{version}.tar.xz
libpng/libpng.spec:Source0: 
http://downloads.sourceforge.net/libpng/%{name}-%{version}.tar.xz
parted/parted.spec:Source0: 
http://ftp.gnu.org/gnu/parted/%{name}-%{version}.tar.xz
texlive-texmf/texlive-texmf.spec:Source0:   
ftp://tug.org/texlive/historic/%{year}/texlive-%{version}-texmf.tar.xz

xz is also supported by automake as dist target.

--
nosy: +arekm

___
Python tracker 

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



[issue7847] Remove 'python -U' or document it

2010-02-03 Thread Martin v . Löwis

Martin v. Löwis  added the comment:

I fail to see the point. This bug was fixed in Python 3. Why risk breaking 
something in the last 2.x release?

--

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

New submission from Florent Xicluna :

Currently this context manager is used in 3 different situations:
 - to silence standard warnings
 - to record warnings in a list, in order to verify them
 - to silence py3k warnings

But it does not accept any parameter, and it does not *check* if the filter is 
obsolete. It silence *all* warnings, blindly.

I would like to propose an enhancement of this function, which accepts a list 
of filters as parameters, and which verifies that there's really something to 
catch.
An optional boolean argument "lazy" can be used to disable the check.
  check_warnings([filter[, ...[, lazy=False]]])

Additionnally, a sister function will filter only the py3k warnings:
  check_py3k_warnings([filter[, ...[, lazy=False]]])

See the patch and its docstring for details.

Note: this context manager could be used to fix the last part of #7092

--
components: Tests
messages: 98796
nosy: ezio.melotti, flox
priority: high
severity: normal
status: open
title: Improve "test_support.check_warnings()"
type: feature request
versions: Python 2.7

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

Changes by Florent Xicluna :


--
keywords: +patch
Added file: http://bugs.python.org/file16118/issue7849_check_warnings.diff

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

Florent Xicluna  added the comment:

Patch for the context managers.
Patch to fix the stdlib.

--
Added file: http://bugs.python.org/file16119/issue7849_lib_fixes.diff

___
Python tracker 

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



[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled

2010-02-03 Thread Florent Xicluna

Changes by Florent Xicluna :


--
dependencies: +Improve "test_support.check_warnings()"

___
Python tracker 

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



[issue5211] Fix complex type to avoid coercion in 2.7.

2010-02-03 Thread Blair

Blair  added the comment:

I also agree that this bug was never more than a small wart. However, I'm now 
curious. 

If Python 3 does not support coercion, I think that it will not be possible to 
write something like my xfloat class, derived from float (i.e., some binary 
operations between an xfloat and a float would return a float instead of an 
xfloat). 

If I am correct in think that it would seem to be a step backward.

Will Python 3 deal with mixed types in some other way, or has this problem been 
abandoned altogether? If it is the latter, I think it is a pity.

--

___
Python tracker 

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



[issue7845] complex.__lt__ should return NotImplemented instead of raising TypeError

2010-02-03 Thread Ezio Melotti

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Brett Cannon

Brett Cannon  added the comment:

In other words you want a way to limit what the context manager catches and 
records while allowing all other warnings to propagate. That seems fine.

I didn't do much of a code review, but there is a grammatical error in the 
docstring: change "a filter catch nothing" to "a filter catches nothing".

--
nosy: +brett.cannon

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

Florent Xicluna  added the comment:

Actually this patch enhances check_warnings() in other ways too:
 - it verifies if the warning is effectively raised
 - it deals with "py3k" warnings separately

It could be used instead of warnings.filterwarnings() with some benefits.

--

___
Python tracker 

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



[issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX

2010-02-03 Thread Ronald Oussoren

New submission from Ronald Oussoren :

The output of platform.system() should IMO be "macosx" on OSX to ensure that 
platform.platform() is consistent with distutils.util.get_platform().

The same is true for sys.platform, although it is unclear how much code that 
would break.

There are two reasons for wanting these changes. First of all the values tend 
to end up at locations where less sophistated users might see them unless we're 
careful (tests for 'sys.platform' in scripts, platform names in distributions, 
...) and 'darwin' is not obviously related to MacOSX unless you're already 
quite technical.   The other reason is slightly nit picking: "Darwin" is the 
name of the kernel and a stand-alone unix based on that, which MacOSX is the 
name of the entire system which includes much more beyond basic unix stuff.


BTW. I know why sys.platform is "darwin" on OSX, that doesn't mean I have to 
like it ;-)

--
components: Library (Lib)
messages: 98801
nosy: ronaldoussoren
severity: normal
status: open
title: platform.system() should be "macosx" instead of "Darwin" on OSX
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

Changes by Florent Xicluna :


Removed file: http://bugs.python.org/file16118/issue7849_check_warnings.diff

___
Python tracker 

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



[issue7849] Improve "test_support.check_warnings()"

2010-02-03 Thread Florent Xicluna

Florent Xicluna  added the comment:

Fixed. Tested with different options: "-Wd", "-3"

--
Added file: http://bugs.python.org/file16120/issue7849_check_warnings_v2.diff

___
Python tracker 

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



[issue7851] WatchedFileHandler needs to be references as handlers.WatchedFileHandler in conf files

2010-02-03 Thread Tom Aratyn

New submission from Tom Aratyn :

The documentation on using logging configuration files 
(http://docs.python.org/library/logging.html#configuring-logging) doesn't 
mention that the WatchedFileHandler needs to be referenced as 
"handlers.WatchedFileHandler". This behavior is different from most handlers 
(like FileHandler) which can be referenced without the package prefix. 

This surprise was experienced on python 2.6.4 on Ubuntu 9.10.

--
assignee: georg.brandl
components: Documentation
messages: 98803
nosy: Tom.Aratyn, georg.brandl
severity: normal
status: open
title: WatchedFileHandler needs to be references as handlers.WatchedFileHandler 
in conf files
versions: Python 2.6

___
Python tracker 

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



[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled

2010-02-03 Thread Florent Xicluna

Florent Xicluna  added the comment:

The enhancement proposed on #7849 should be considered before reviewing the 
last 2 patches.

If #7849 is accepted, these patches will need update.

--

___
Python tracker 

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



[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

2010-02-03 Thread Christoph Gohlke

Christoph Gohlke  added the comment:

I thought one conclusion of the discussion on issue4120 was that any 
executable, which embeds Python and imports MSVCR9 dependent extensions, must 
now provide the manifest for the MSVCR9 runtimes, either embedded or as a 
separate file. See  and responses. 
Why shouldn't this apply to wininst executables?

Another observation: importing the winsound extension in the postinstall script 
works even though it also depends on MSVCR90.DLL. Winsound.pyd does not have an 
embedded manifest. It is linked with /MANIFEST:NO. Apparently there is a 
difference between an "empty" manifest and no manifest. 

How about a patch that does:

1) not embed any manifest into PYD files if the manifest contains only a single 
MSVCR90 dependentAssembly element. 

2) remove the MSVCR90 dependentAssembly element from manifests embedded into 
PYD files if the manifest defines additional dependentAssembly elements (e.g. 
for MFC or Common Controls). This is essentially what the 
msvc9compiler_stripruntimes patch does now.

3) not embed manifests into any file (EXE, PYD, or DLL) if '/MANIFEST:NO' is 
defined in extra_link_args. Extension developers can then provide external 
manifest files.

4) not touch the default manifests embedded into EXE and DLL files. The 
msvc9compiler_stripruntimes currently produces DLLs that can not be used 
standalone, such as pythoncom26.dll from the pywin32 package (I can file a 
separate bug if requested). Pythoncom26.dll is meant to be placed in the 
system32 folder and to be used outside of a Python environment, i.e. from the 
Windows Scripting Host. Several pywin32 tests fail with the pythoncom26.dll 
built with the msvc9compiler_stripruntimes patch. Placing a MSVCR9 manifest 
file into the system32 folder next to the pythoncom26.dll is not an option.


A tentative patch against the Python 2.6 branch is attached. I will test it 
further.

(1) and (4) will solve the original pywin32 wininstaller problem without 
changing wininst.exe.

As it is now the installer and some functionality of the pywin32 package will 
likely break if pywin32 is built on Python 2.6.5.

--
Added file: 
http://bugs.python.org/file16121/msvc9compiler_stripruntimes_revised.patch

___
Python tracker 

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



[issue6715] xz compressor support

2010-02-03 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

We all agree that lzma/xz is important, what is needed is a patch.

--

___
Python tracker 

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



[issue1225769] Proposal to implement comment rows in csv module

2010-02-03 Thread Senthil Kumaran

Senthil Kumaran  added the comment:

Here is another -1 for this proposed feature. Having a comments in the csv 
fields and providing a way to deal will complicate matters more than required. 
Different suggestions of how to accomplish it has been suggested here. As 
others, I too recommend closing it. (It is assigned to andewmcnamara, so I 
guess, he would close it).

--
nosy: +orsenthil

___
Python tracker 

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



[issue1225769] Proposal to implement comment rows in csv module

2010-02-03 Thread Andrew McNamara

Andrew McNamara  added the comment:

Okay, while I am sympathetic to the points raised by the people asking for this 
enhancement, I'm persuaded to reject it by the arguments that the potential 
benefit is outweighed by the increase in complexity (code and documentation).

While the attached patch from Iain requires relatively minor and innocuous 
changes to the state machine, it only satisfies a limited subset of users, and 
the effect of complexity is geometric. In other words, to understand the state 
machine, you need to understand the relation of each state to every other 
state, etc.

As to why the core of the module is implemented in C, the sort of stateful 
parsing done by the module is one area where python does not excel (Ha!). 
Stripping comments, on the other hand, CAN be done with reasonable efficiency 
from python (and considerably more flexibility). Also, it has been my 
experience that CSV files that use comments typically have other non-standard 
features as well, requiring additional pre- and post-processing in any case.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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



[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

2010-02-03 Thread Matthew Barnett

Matthew Barnett  added the comment:

issue2636-20100204.zip is a new version of the regex module.

I've added splititer and added a build for Python 3.1.

--
versions: +Python 3.1
Added file: http://bugs.python.org/file16122/issue2636-20100204.zip

___
Python tracker 

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



[issue5211] Fix complex type to avoid coercion in 2.7.

2010-02-03 Thread Meador Inge

Meador Inge  added the comment:

> Mark
>
> Yes, that was what I was proposing.

As you pointed out in issue 3734, the patch is basically:

===
--- Objects/complexobject.c (revision 77909)
+++ Objects/complexobject.c (working copy)
@@ -1282,7 +1282,8 @@
PyObject_GenericGetAttr,/* tp_getattro */
0,  /* tp_setattro */
0,  /* tp_as_buffer */
-   Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* tp_flags */
+   Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES 
+| Py_TPFLAGS_BASETYPE,  /* tp_flags */
complex_doc,/* tp_doc */
0,  /* tp_traverse */
0,  /* tp_clear */

plus the relevant test cases and documentation changes.

> Mark
>
> That's not really an option:  it has the potential to break existing 
> code that uses coercion.  Removing coercion in Python 2.x would 
> require at least a PEP plus one version's worth of DeprecationWarning.

Ah, good point.  In that case I am -1 on changing the behavior at all.  For the 
sole reason that cases like Blair originally reported would not work as 
expected in version < 2.7, then would work in 2.7, and then would break again 
in > 3.0.  I think explaining and documenting the change in behavior would be 
really confusing.

> Blair
>
> If I am correct in think that it would seem to be a step backward.

I disagree.  I think type coercion (or implicit conversions) is hard to follow 
and understand.  I say this from many years of C and C++ programming.  I see 
bugs all of the time in these languages due to conversions silently happening 
that the programmer was not aware of.  Yes the feature is convenient, but 
documenting and explaining these rules to programmers becomes very tedious and 
requires that most programmers have deep understanding of the languages typing 
rules.  This typically leads to books like "Effective C++" that catalog a list 
of things *not* to do in a language.  The relevant case for C++ being to avoid 
user defined conversions and use explicit constructers.  As such, I am 
definitely +1 on removing coercion.

--

___
Python tracker 

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



[issue5211] Fix complex type to avoid coercion in 2.7.

2010-02-03 Thread Blair

Blair  added the comment:

OK. I have gone back to the beginning to refresh my memory and I see a possible 
point of misunderstanding. I am not sure that we are really talking about the 
problem that prompted my initial report (msg72169, issue 3734). 

Immediately following my message, Daniel Diniz confirmed the bug and expanded 
on my code with an xfloat class of his own that uses __coerce__. 

In fact, if I had submitted an xfloat class it would have been the following 

class xfloat( float ):

def __new__(cls,*args,**kwargs):
return float.__new__(cls,*args,**kwargs)

def __add__(self,x):
return xfloat( float.__add__(self,x) )

def __radd__(self,x):
return xfloat( float.__radd__(self,x) )

My xfloat works fine in 2.6.4 and it was my wish, at the time, to write a class 
for xcomplex that behaved in a similar way. According to the Python manual, 
that should have been possible, but it wasn't.

So, I guess coercion is not really the problem. 

However, there does seem to be something wrong with the complex type.

I have looked at the manual for Python 3 and see that the same rules apply for 
classes that emulate numeric types, namely:

"If the right operand’s type is a subclass of the left operand’s type and that 
subclass provides the reflected method for the operation, this method will be 
called before the left operand’s non-reflected method. This behavior allows 
subclasses to override their ancestors’ operations."

The question I have then is will the following work in Python 3 (it doesn't in 
2.6.4)?

class xcomplex( complex ):

def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)

##def __coerce__(self,other):
##t = complex.__coerce__(self,other)
##try:
##return (self,xcomplex(t[1]))
##except TypeError:
##return t

def __add__(self,x):
return xcomplex( complex.__add__(self,x) )

def __radd__(self,x):
return xcomplex( complex.__radd__(self,x) )

xz = xcomplex(1+2j)
xy = float(10.0)
z = complex(10+1j)

print "would like xcomplex type each time"
print type(xz + z)  
print type(xz + xy) 
print type(xz + 10) 
print type(xy + xz) 
print type(10 + xz) 
print type(z + xz)

--

___
Python tracker 

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



[issue1225769] Proposal to implement comment rows in csv module

2010-02-03 Thread Andrew McNamara

Andrew McNamara  added the comment:

Note that there is one case that cannot easily be addressed via pre-processing: 
where the comment character coincidently appears at the start of a line within 
a multi-line quoted field. For example:

# This is a comment
1, 2, "This is field^M
#3"

What this should produce is debatable, but it would be hard to make it produce:

  ["1", "2", "This is field^M#3"]

without implementing it within the parser.

--

___
Python tracker 

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



[issue1005895] curses for win32

2010-02-03 Thread anatoly techtonik

anatoly techtonik  added the comment:

Can this be considered a duplicate of issue 2889?

--
versions: +Python 2.7 -Python 2.6

___
Python tracker 

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



[issue7728] test_timeout should use "find_unused_port" helper

2010-02-03 Thread Florent Xicluna

Florent Xicluna  added the comment:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20trunk/builds/387

--

___
Python tracker 

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