[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I think your patch is correct. (I couldn't check the behavior on error
condition itself, because I wasn't sure how, but I checked test_io run
on windows)

--

___
Python tracker 

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

[issue7387] More precise document on os.path.normpath()

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue7383] test_multiprocessing leaks

[R. David Murray]

R. David Murray  added the comment:

This started just after r76438, which is an additional test for
multiprocessing.  Given build delays this is only a correlation not a
definite cause, but it is suspicious.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7387] More precise document on os.path.normpath()

[pengyu.ut]

New submission from pengyu.ut :

os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.

I recommend document this feature.

--
assignee: georg.brandl
components: Documentation
messages: 95662
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
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

[issue7386] More precise document on os.path.normpath()

[pengyu.ut]

New submission from pengyu.ut :

os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.

I recommend document this feature.

--
assignee: georg.brandl
components: Documentation
messages: 95661
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
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

[issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails

[Pauli Virtanen]

New submission from Pauli Virtanen :

In Objects/memoryobject.c:PyMemoryView_FromObject there's a
_PyObject_GC_UNTRACK unpaired with corresponding _PyObject_GC_TRACK,
which seems to cause a segmentation fault. This can be triggered by
calling PyMemoryView_FromObject on an object whose bf_getbuffer returns
an error.

PyMemoryView_FromObject(PyObject *base) {
   ...
   if (PyObject_GetBuffer(base, &(mview->view), PyBUF_FULL_RO) < 0) {
   Py_DECREF(mview);
   return NULL;
   } 
   ...
   _PyObject_GC_TRACK(mview);
}
...
static void memory_dealloc(PyMemoryViewObject *self) {
   _PyObject_GC_UNTRACK(self); 
   
}

--
components: Interpreter Core
messages: 95660
nosy: pv
severity: normal
status: open
title: MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
versions: Python 3.1

___
Python tracker 

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

[issue7372] Regression in pstats

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

It would be fairly easy to change format before dumping stats to disk,
but unfortunately Profile does not encapsulate it's run-time data and
changing its format would be a mess.

Of course, one can hack around that by turning Profile.stats into a
computed property, but that's hardly an acceptable solution.

I think it is worthwhile fixing the on-disk format, but as a long-tem
solution one may consider adding common (possibly iterator-based) API
to both profile and cProfile that pstats can use instead of accessing
internal data structures.

Creating an ABC for a standard Python profiler, seems to be a
worthwhile project that in the future may simplify plugging in 3rd
party profilers, but I don't have expertise to undertake such a
project.  That would require experience with multiple Python profilers
that I don't have.

On Mon, Nov 23, 2009 at 3:31 PM, Georg Brandl  wrote:
>
> Georg Brandl  added the comment:
>
> Alexander, how hard would it be to change the profile output?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue7117] Backport py3k float repr to trunk

[Mark Dickinson]

Mark Dickinson  added the comment:

r76474: Remove %f -> %g switch.

--

___
Python tracker 

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

[issue7372] Regression in pstats

[Georg Brandl]

Georg Brandl  added the comment:

Alexander, how hard would it be to change the profile output?

--

___
Python tracker 

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

[issue7383] test_multiprocessing leaks

[Jesse Noller]

Jesse Noller  added the comment:

AFAIK; I haven't changed anything which would introduce refleaks in the 
code. So, it's going to be a matter of chasing down all of the changes 
since the refleaks popped up and see which one triggered it.

--

___
Python tracker 

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

[issue7128] cPickle looking for non-existent package copyreg

[Georg Brandl]

Georg Brandl  added the comment:

Patch looks ok to me, do you want to apply it?

--

___
Python tracker 

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

[issue644744] bdist_rpm fails when installing man pages

[Toshio Kuratomi]

Toshio Kuratomi  added the comment:

Agreed.  The substitution is still needed.

--

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[flox]

flox  added the comment:

Patch could be applied to Python 2.6 and trunk too.

--
versions: +Python 2.6, Python 2.7

___
Python tracker 

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

[issue7384] test_curses crash on FreeBSD buildbots

[Mark Dickinson]

New submission from Mark Dickinson :

test_curses is currently causing the test runs to abort on the FreeBSD 6.4 
and 7.2 buildbots.

I can reproduce this on a FreeBSD 7.2 /amd64 machine by doing

./python Lib/test/regrtest.py -uall test___all__ test_curses

This dumps core, and the traceback points at the call to delwin() in 
PyCursesWindow_Dealloc, but it's far from obvious (to me) what's going 
wrong.  wo->win is not NULL here, and appears to point to a valid WINDOW.  
However, stdscr is NULL!  As far as I can tell, this shouldn't happen.

test_curses by itself doesn't crash, unless I add an 'import readline' or 
'import rlcompleter' to the top of test_curses.py.

I expect to have access to the FreeBSD machine for a few more days.  Any 
hints about what to try next would be appreciated.

--
components: Extension Modules
keywords: buildbot
messages: 95652
nosy: mark.dickinson
severity: normal
status: open
title: test_curses crash on FreeBSD buildbots
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7345] calendar.TextCalendar().formatyear wrong argument list

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r76471.

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

___
Python tracker 

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

[issue6071] no longer possible to hash arrays

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> As for the checks for bf_releasebuffer: I still think they are
> necessary. If an object implements bf_releasebuffer, that means that the
> object may change the buffer underneath, unless proper locking and
> unlocking takes place.

I know, but the problem is that by switching some argument definitions
to "s*" and friends we have broken compatibility for the (admittedly
uncommon) use case of giving an array object to those functions. Since
we probably don't want to backout those changes perhaps adding support
for the new buffer API to the array object is the best course of action.

--

___
Python tracker 

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

[issue7383] test_multiprocessing leaks

[Antoine Pitrou]

New submission from Antoine Pitrou :

This has started a few days ago. I don't know if this was triggered by a
multiprocessing change or an unrelated one.
On trunk:

test_multiprocessing
beginning 6 repetitions
123456
..
test_multiprocessing leaked [277, 277, 277] references, sum=831

On py3k:

test_multiprocessing
beginning 6 repetitions
123456
..
test_multiprocessing leaked [229, 229, 229] references, sum=687

--
assignee: jnoller
components: Library (Lib), Tests
messages: 95649
nosy: jnoller, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_multiprocessing leaks
type: resource usage
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

[issue644744] bdist_rpm fails when installing man pages

[Thomas Vander Stichele]

Thomas Vander Stichele  added the comment:

Hi Toshio,

I'd probably also go for the wildcarding, but you'd still need to
'change' the INSTALLED_FILES file to do so, so you'd still use the same
mechanism.

--

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15391/issue7376_usage.diff

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[flox]

Changes by flox :


Added file: http://bugs.python.org/file15392/issue7376_usage.diff

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[flox]

flox  added the comment:

Patch proposed.

--
Added file: http://bugs.python.org/file15391/issue7376_usage.diff

___
Python tracker 

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

[issue1488943] difflib.Differ() doesn't always add hints for tab characters

[Senthil Kumaran]

Senthil Kumaran  added the comment:

fixed r76469 (py3k) and r76470(release31-maint). Closing the issue.

--
status: open -> closed

___
Python tracker 

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

[issue1488943] difflib.Differ() doesn't always add hints for tab characters

[Senthil Kumaran]

Senthil Kumaran  added the comment:

merged to 26-maint in revision 76468 and shall merge in py3k too.

--

___
Python tracker 

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

[issue7117] Backport py3k float repr to trunk

[Mark Dickinson]

Mark Dickinson  added the comment:

r76465 removes the fixed-length buffer for formatting floats, hence
removes the restriction on the precision.   This should make removal of 
the %f -> %g switch straightforward.

--

___
Python tracker 

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

[issue644744] bdist_rpm fails when installing man pages

[Toshio Kuratomi]

Toshio Kuratomi  added the comment:

sed is one of the programs we assume is always present when we build
packages in Fedora which is probably also what is wanted here.  (A
default install of Fedora will include sed but someone might be able to
create a minimal install that did not include it.) Note that within
Fedora we usually use a wildcard with man pages.  For example::

  %{_mandir}/man1/foo.1*

I'd suggest doing this rather than hardcoding ".gz".  Automatic
compression of manpages could be disabled on other distros, set to
bzip2, compress, or xz instead.  Wildcarding the suffix will catch all
of these cases and be more future-proof.

--

___
Python tracker 

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

[issue1488943] difflib.Differ() doesn't always add hints for tab characters

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Yes, I noticed the issue and found the patch to be good as well.
Unfortunate it was pending for a long time.
Fixed and Committed revision 76464 (trunk).

--
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +brian.curtin

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Michael Droettboom]

Michael Droettboom  added the comment:

Here's another patch against release25_maint for the benefit of those
still using Python 2.5.  It's different only in some whitespace changes.

--
Added file: http://bugs.python.org/file15390/py25_cxx_compiler.patch

___
Python tracker 

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

[issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15385/issue7380_uuid.diff

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Michael Droettboom]

Michael Droettboom  added the comment:

Attached is a patch against the release26-maint branch.  This works for
me on Sun Workshop 6.

Note that on Sun, the C compiler is 'cc' and the C++ compiler is 'CC',
but distutils uses 'cc' and 'c++'.  However, the CXX environment
variable now works (after applying the patch), so this is less of an
issue, if it can be considered a bug at all.

--
Added file: http://bugs.python.org/file15389/py26_cxx_compiler.patch

___
Python tracker 

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

[issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes

[flox]

flox  added the comment:

Patch with documentation included. (branches/py3k)

--
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
Added file: http://bugs.python.org/file15388/issue7380.diff

___
Python tracker 

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

[issue7371] Windows 64-bit build "skips" several projects in VS 2008

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

[...]
Step 6. Build Solution

The OS was 64-bit Windows XP (w/ Service Pack 2). Are you sure you were 
running a 64-bit operating system (i.e., not cross-compiling)?

--

___
Python tracker 

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

[issue7369] Fibonacci example does not include 0; section 4.6

[Mark Dickinson]

Mark Dickinson  added the comment:

Fixed in r76460 through r76463.

--
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

[flox]

flox  added the comment:

Forget the "python2.5 -m doctest /usr/lib/python2.5/subprocess.py" in
first message msg95625.
This command does not do what I guessed. And there's no doctest in the
Python2.5 "subprocess" module.


The attached patch may be enough to fix the docstring inconsistencies
with Python3.1.
It might not be mandatory to make the docstring 100% successful.
(I see no PEP which requires that).

--

___
Python tracker 

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

[issue7379] Docstring for fractions.Fraction.limit_denominator fails

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the report!  Fixed in r76456 through r76459.

--
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, Python 2.7 -Python 3.0

___
Python tracker 

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

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

[R. David Murray]

R. David Murray  added the comment:

Confirmed on py3k trunk.  We no longer do bug fixes in 3.0, which is why
I'm removing it from versions.

--
keywords: +easy
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Michael Droettboom]

Michael Droettboom  added the comment:

I'm testing this against release25_maint and release26_maint as we
speak.  I'll post new patches when that's done.

--

___
Python tracker 

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

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

[Sebastian Hagen]

New submission from Sebastian Hagen :

In either python 3.0, bytes instances cannot be copied, and (even
trivial) bytes subclasses cannot be unpickled unless they explicitly
override __getnewargs__() or __reduce_ex__().

Copy problem:
>>> import copy; copy.copy(b'foo')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.1/copy.py", line 96, in copy
return _reconstruct(x, rv, 0)
  File "/usr/lib/python3.1/copy.py", line 280, in _reconstruct
y = callable(*args)
  File "/usr/lib/python3.1/copyreg.py", line 88, in __newobj__
return cls.__new__(cls, *args)
TypeError: string argument without an encoding

Bytes subclass unpickle problem:
>>> class B(bytes):
...  pass
...
>>> import pickle; pickle.loads(pickle.dumps(B(b'foo')))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.1/pickle.py", line 1373, in loads
encoding=encoding, errors=errors).load()
TypeError: string argument without an encoding


AFAICT, the problem is that bytes.__getnewargs__() returns a tuple with
a single argument - a string - and bytes.__new__() refuses to
reconstruct the instance when called with in that manner. That is,
"bytes.__new__(bytes, *b'foo'.__getnewargs__())" fails with a TypeError.

This does not cause a problem for pickling bytes instances (as opposed
to instances of a subclass of bytes), because both the Python and C
versions of pickle shipped with Python 3.[01] have built-in magic
(_Pickler.save_bytes() and save_bytes(), respectively) to deal with
bytes instances, and therefore never call their __getnewargs__().

The pickle case, in particular, is highly irritating; the error message
doesn't indicate which object is causing the problem, and until you
actually try to load the pickle, there's nothing to indicate that
there's anything problematic about pickling an instance of a subclass of
bytes.

--
components: Library (Lib)
files: pickle_bytes_subclass.py
messages: 95632
nosy: sh
severity: normal
status: open
title: bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on 
bytes, and bytes subclasses can't be pickled by default
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15387/pickle_bytes_subclass.py

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Has someone tried to apply it with a recent Python ?

I can work on it but I'll need some help from someone matplotlib or Sage
I guess..

--
assignee:  -> tarek

___
Python tracker 

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

[issue7371] Windows 64-bit build "skips" several projects in VS 2008

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I can't reproduce this. If I do your steps 1 to 5, *nothing* is build -
not surprisingly, since these steps don't invoke a build at all.

When I then select, in the context menu of "Solution 'pcbuild'", the
menu item "Build solution", it builds everything.

Also, what operating system is "Windows 64-bit (SP2)"?

--
nosy: +loewis

___
Python tracker 

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

[issue1222585] C++ compilation support for distutils

[Michael Droettboom]

Michael Droettboom  added the comment:

This is a rather serious bug for matplotlib -- since the C++ compiler is
not correctly selected, it can't be built with many Unix compilers, such
as Sun Studio.

--
nosy: +mdboom

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[flox]

flox  added the comment:

I am ok with the proposal of removing the current "selftest" default
behavior.

And thank you for the tip.
I tried the command "python -m doctest Lib/*.py" and I found interesting
things:
 * #7379 about Lib/fractions.py
 * #7380 about Lib/uuid.py
 * #7381 about Lib/subprocess.py

;)

--

___
Python tracker 

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

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

[flox]

flox  added the comment:

It may be fixed with "# doctest: +ELLIPSIS" and "# doctest: +SKIP"
directives...
But it is probably platform-dependent.

I have tested only with Debian Lenny.

--

___
Python tracker 

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

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

[flox]

flox  added the comment:

I fixed the docstring inconsistency (see patch) and some obvious things.

But I still have errors.


~ $ python3 -m doctest py3_failed/subprocess.py
**
File "py3_failed/subprocess.py", line 139, in subprocess
Failed example:
subprocess.getstatusoutput('/bin/junk')
Expected:
(256, 'sh: /bin/junk: not found')
Got:
(32512, '/bin/sh: /bin/junk: No such file or directory')
**
File "py3_failed/subprocess.py", line 449, in subprocess.check_output
Failed example:
check_output(["ls", "-l", "/dev/null"])
Expected:
b'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'
Got:
b'crw-rw-rw- 1 root root 1, 3 Nov 15 17:41 /dev/null\n'
**
File "py3_failed/subprocess.py", line 455, in subprocess.check_output
Failed example:
check_output(["/bin/sh", "-c",
  "ls -l non_existent_file ; exit 0"],
  stderr=STDOUT)
Expected:
b'ls: non_existent_file: No such file or directory\n'
Got:
b'ls: cannot access non_existent_file: No such file or directory\n'
**
File "py3_failed/subprocess.py", line 559, in subprocess.getstatusoutput
Failed example:
subprocess.getstatusoutput('/bin/junk')
Expected:
(256, 'sh: /bin/junk: not found')
Got:
(32512, '/bin/sh: /bin/junk: No such file or directory')
**
3 items had failures:
   1 of   6 in subprocess
   2 of   2 in subprocess.check_output
   1 of   4 in subprocess.getstatusoutput
***Test Failed*** 4 failures.
~ $

--
keywords: +patch
Added file: http://bugs.python.org/file15386/issue7381_first.diff

___
Python tracker 

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

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

[flox]

New submission from flox :

I've tested the docstring of the module subprocess.
Python 2.5 is OK, but Python 3.1 fails.

~ $ python2.5 -m doctest /usr/lib/python2.5/subprocess.py
...
--
Ran 15 tests in 0.012s

OK
~ $ python3 -m doctest /usr/lib/python3.1/subprocess.py
Traceback (most recent call last):
  File "/usr/lib/python3.1/runpy.py", line 128, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.1/runpy.py", line 34, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.1/doctest.py", line 2637, in 
sys.exit(_test())
  File "/usr/lib/python3.1/doctest.py", line 2626, in _test
failures, _ = testmod(m)
  File "/usr/lib/python3.1/doctest.py", line 1847, in testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/usr/lib/python3.1/doctest.py", line 854, in find
self._find(tests, obj, name, module, source_lines, globs, {})
  File "/usr/lib/python3.1/doctest.py", line 908, in _find
globs, seen)
  File "/usr/lib/python3.1/doctest.py", line 896, in _find
test = self._get_test(obj, name, module, globs, source_lines)
  File "/usr/lib/python3.1/doctest.py", line 980, in _get_test
filename, lineno)
  File "/usr/lib/python3.1/doctest.py", line 590, in get_doctest
return DocTest(self.get_examples(string, name), globs,
  File "/usr/lib/python3.1/doctest.py", line 604, in get_examples
return [x for x in self.parse(string, name)
  File "/usr/lib/python3.1/doctest.py", line 566, in parse
self._parse_example(m, name, lineno)
  File "/usr/lib/python3.1/doctest.py", line 636, in _parse_example
lineno + len(source_lines))
  File "/usr/lib/python3.1/doctest.py", line 722, in _check_prefix
(lineno+i+1, name, line))
ValueError: line 11 of the docstring for subprocess.check_output has
inconsistent leading whitespace: "'"

--
components: Library (Lib), Tests
messages: 95625
nosy: flox
severity: normal
status: open
title: subprocess.check_output: "docstring has inconsistent leading whitespace"
versions: Python 3.1, Python 3.2

___
Python tracker 

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

[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Eric pointed me to this ticket after having raised the question on
python-dev: http://www.mail-archive.com/python-...@python.org/msg43841.html

I think the discussion should be continued there instead of on this ticket.

Just for completeness, I'm copying my reply to Martin's reply here
(http://www.mail-archive.com/python-...@python.org/msg43849.html):

"""
> For example, consider
> 
> if (PyInt_Check(o)){
>   long val = PyInt_AsLong(o);
>   // process
> } else if (PyLong_Check(o)) {
>   long long val = PyLong_AsLongLong(o);
>   // check for overflow
>   // process
> }
> 
> With intobject.h, this code would continue to compile, but work
> incorrectly, as the second case will never be executed. It would
> be better to port this as
> 
> #if Py2.x
> if (PyInt_Check(o)){
>   long val = PyInt_AsLong(o);
>   // process
> } else
> #endif
> if (PyLong_Check(o)) {
> 
> i.e. eliminating the int case altogether.

Sure, but that assumes that the original code already had support
for Python longs, which a lot of code doesn't.

In an ideal world, developers would add that code to their
extensions right away. In the real world, where developers only
have limited resources available, you'll get more 3.x ports
by making such ports as painless as possible while at the
same time not forcing them to alienate their 2.x user base.

The long support could then be added in later releases
of the extensions, giving the developers more time adapt.

> For another example,
> 
> long foo = PyInt_AsLong(Foo);
> 
> has a hidden error in 3.x, with intobject: PyLong_AsLong might
> overflow, which the 2.x case doesn't.

That's not quite true: PyInt_AsLong(obj) will try the
nb_int slot on non-integer objects which can return errors
(it returns -1 and sets the error message).

> So eliminating intobject.h likely helps avoiding subtle errors.

In the long run, yes. In the short run, other criteria are
more important, IMHO.
"""

IMO, it would be worthwhile collecting all Python 2.x compatibility C
APIs in two new files:

 * py2compat.h
 * py2compat.c

These could then be used in extensions and make the use of such
compatibility APIs explicit in the extension.

--
nosy: +lemburg

___
Python tracker 

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

[issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes

[flox]

flox  added the comment:

Attached patch gives coherence:
 * both UUID.bytes and UUID.bytes_le return a "bytes" object
 * the random tests are explicitly skipped

Then the documentation needs fixing, too.

--
keywords: +patch
Added file: http://bugs.python.org/file15385/issue7380_uuid.diff

___
Python tracker 

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

[issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes

[flox]

New submission from flox :

I've tried some experiments with module uuid, and I meet some
inconsistencies between the documentation, the docstring and the real
behavior of the module.

An interactive session is worth a thousand words:

>>> import uuid
>>> uuid.UUID(bytes='\x12\x34\x56\x78'*4)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.1/uuid.py", line 149, in __init__
assert isinstance(bytes, bytes_), repr(bytes)
AssertionError: '\x124Vx\x124Vx\x124Vx\x124Vx'
>>> uuid.UUID(bytes_le='\x78\x56\x34\x12\x34\x12\x78\x56' +
...'\x12\x34\x56\x78\x12\x34\x56\x78')
Traceback (most recent call last):
  File "", line 2, in 
  File "/usr/lib/python3.1/uuid.py", line 144, in __init__
bytes_(reversed(bytes_le[6:8])) +
TypeError: 'str' object cannot be interpreted as an integer
>>> 

Ok, the lines above are just parts of the documentation which need
update. But what is more confusing is the last example of the documentation.
http://docs.python.org/dev/py3k/library/uuid.html

Here is the interactive session:

>>> x = uuid.UUID('{00010203-0405-0607-0809-0a0b0c0d0e0f}')
>>> x.bytes
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
>>> x.bytes_le
b'\x03\x02\x01\x00\x05\x04\x07\x06\x08\t\n\x0b\x0c\r\x0e\x0f'
>>> 

Normally both attributes should get a "UUID as a 16-byte string",
according to the documentation. Only the endianness should do the
difference. I guess this one need a patch.


Finally, the docstring fails, too:

~ $ python3 -m doctest /usr/lib/python3.1/uuid.py
**
File "/usr/lib/python3.1/uuid.py", line 16, in uuid
Failed example:
uuid.uuid1()
Expected:
UUID('a8098c1a-f86e-11da-bd1a-00112444be1e')
Got:
UUID('e4bc8a38-d829-11de-9eee-0024e8bc58f0')
**
File "/usr/lib/python3.1/uuid.py", line 24, in uuid
Failed example:
uuid.uuid4()
Expected:
UUID('16fd2706-8baf-433b-82eb-8c7fada847da')
Got:
UUID('71588cf5-7a51-4d59-ad76-05fb6b932673')
**
File "/usr/lib/python3.1/uuid.py", line 39, in uuid
Failed example:
x.bytes
Expected:
b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f'
Got:
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**
File "/usr/lib/python3.1/uuid.py", line 43, in uuid
Failed example:
uuid.UUID(bytes=x.bytes)
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.1/doctest.py", line 1243, in __run
compileflags, 1), test.globs)
  File "", line 1, in 
uuid.UUID(bytes=x.bytes)
  File "/usr/lib/python3.1/uuid.py", line 149, in __init__
assert isinstance(bytes, bytes_), repr(bytes)
AssertionError:
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**
1 items had failures:
   4 of   9 in uuid
***Test Failed*** 4 failures.
~ $

--
components: Library (Lib)
messages: 95622
nosy: flox
severity: normal
status: open
title: uuid.UUID.bytes gives a bytearray() instead of bytes
versions: Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?

[Eric Smith]

Eric Smith  added the comment:

MvL made this comment in
http://www.mail-archive.com/python-...@python.org/msg43844.html

I'm copying it here so it doesn't get lost and because I think he makes
a good point that many people would miss (at least I didn't think of it).
---

The macros (unfortunately) allowed
to make non-obvious mistakes. Now that they are gone, people need to
really think of what precisely they want to do.

For example, consider

if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else if (PyLong_Check(o)) {
  long long val = PyLong_AsLongLong(o);
  // check for overflow
  // process
}

With intobject.h, this code would continue to compile, but work
incorrectly, as the second case will never be executed. It would
be better to port this as

#if Py2.x
if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else
#endif
if (PyLong_Check(o)) {

i.e. eliminating the int case altogether. For another example,

long foo = PyInt_AsLong(Foo);

has a hidden error in 3.x, with intobject: PyLong_AsLong might
overflow, which the 2.x case doesn't.

So eliminating intobject.h likely helps avoiding subtle errors.

Regards,
Martin

--
nosy: +eric.smith

___
Python tracker 

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

[issue7379] Docstring for fractions.Fraction.limit_denominator fails

[flox]

New submission from flox :

Yes, you can reduce the fraction 1234/5678.
Bad Luck :p

~ $  python3 -m doctest /usr/lib/python3.1/fractions.py
**
File "/usr/lib/python3.1/fractions.py", line 165, in
fractions.Fraction.limit_denominator
Failed example:
Fraction(1234, 5678).limit_denominator(1)
Expected:
Fraction(1234, 5678)
Got:
Fraction(617, 2839)
**
1 items had failures:
   1 of   3 in fractions.Fraction.limit_denominator
***Test Failed*** 1 failures.
~ $

--
components: Library (Lib), Tests
messages: 95620
nosy: flox
severity: normal
status: open
title: Docstring for fractions.Fraction.limit_denominator fails
versions: Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue644744] bdist_rpm fails when installing man pages

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I'd rather see sed called from within Distutils. But I am not sure how
to handle it after install has been called.

Do you know if sed is *always* present on a fresh Fedora ?

(I am nosying Toshio as well)

--
assignee:  -> tarek
nosy: +a.badger
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

[R. David Murray]

Changes by R. David Murray :


--
title: FAIL: Doctest: __main__.DebugRunner -> "python -m doctest" results in 
FAIL: Doctest: __main__.DebugRunner

___
Python tracker 

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

[issue7376] FAIL: Doctest: __main__.DebugRunner

[R. David Murray]

R. David Murray  added the comment:

python -m doctest does accept file arguments.  Running the self-test is
the default if no arguments are supplied.

python -m doctest Lib/doctest.py passes.

So perhaps we should just remove the default and instead issue an error
message about missing arguments.

--
nosy: +r.david.murray
priority:  -> low
type:  -> behavior

___
Python tracker 

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

[issue7378] unexpected truncation of traceback

[Greg Hewgill]

New submission from Greg Hewgill :

Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:

exec(compile("spam()", ".", "exec"))

and the output in Python 3.1 ("spam" is undefined):

$ python3.1 test.py
Traceback (most recent call last):
  File "test.py", line 1, in 
exec(compile("spam()", ".", "exec"))
  File ".", line 1, in 
$

This was bewildering until I realised that the traceback generator was
unable to read from the filename passed to compile() (my original
example was using a name other than "." that wasn't intended to be a
file name, but just happened to also be a directory name). I didn't
really mind the lack of source text, but the lack of the actual
exception message was most disturbing.

This appears to be a failure mode common to both traceback.c and
traceback.py, through slightly different mechanisms. In traceback.c, if
the source filename refers to a directory, the C open() succeeds but an
error occurs when trying to read from the directory handle. In 
traceback.py, the Python open() call fails with an IOError exception, 
and the exception wasn't handled gracefully.

I have attached a patch that creates the following output instead:

$ ./python.exe test.py
Traceback (most recent call last):
  File "test.py", line 1, in 
exec(compile("spam()", ".", "exec"))
  File ".", line 1, in 
[Errno 21] Is a directory: '.'
NameError: name 'spam' is not defined
$

I have tested the patch against Python 3.1, but it applies cleanly to 
the trunk (for some reason I couldn't make the trunk build, but that's 
unrelated). This patch may need some finesse for a Win32 build; I don't
have the ability to test that at the moment.

--
components: Interpreter Core, Library (Lib)
files: traceback.patch
keywords: patch
messages: 95617
nosy: ghewgill
severity: normal
status: open
title: unexpected truncation of traceback
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15384/traceback.patch

___
Python tracker 

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

[issue644744] bdist_rpm fails when installing man pages

[Thomas Vander Stichele]

Thomas Vander Stichele  added the comment:

Attaching a reworked patch of the patch attached in
http://bugs.python.org/issue1169193

This worked for me on f-11, with python 2.6

--
keywords: +patch
nosy: +thomasvs
Added file: http://bugs.python.org/file15383/distutils.bdist_rpm.patch

___
Python tracker 

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

[issue6071] no longer possible to hash arrays

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I think the error is really in _hashlib, not in the array object. It
should not require 3.x style buffers, but continue to support 2.x
readbuffers. Attached is a patch that takes this route to fixing the bug.

As for the checks for bf_releasebuffer: I still think they are
necessary. If an object implements bf_releasebuffer, that means that the
object may change the buffer underneath, unless proper locking and
unlocking takes place. Indeed, the array's getreadbuf operation is not
thread-safe. It might be possible to remove them if it is clarified that
anybody calling getreadbuffer must not release the GIL while they hold
on to the buffer.

--
Added file: http://bugs.python.org/file15382/hashlib.diff

___
Python tracker 

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