[issue1789] assumption about unsigned long byte size in struct module usage

[Gregory P. Smith]

Gregory P. Smith added the comment:

Anders J. Munch on python-dev correctly says:

You overlooked the words "Standard size and alignment are as follows"
that start the quoted paragraph.  It's a little confusing because
standard size is not the default.  The default is platform-specific
sizes.  Only if you start the format string with >, <, ! or = do you
get standard sizes.

The reference documentation is correct as it stands, and, I suspect,
so is the LP64 implementation.  Doesn't struct.pack('>l',42) produce a
4-byte string on LP64?

The tutorial at
http://docs.python.org/tut/node13.html#SECTION001330%3E
has a bug though: the format string should use '<'.

I believe zipfile.py correctly uses '<' throughout.

--
keywords: +easy -patch
priority: urgent -> normal
severity: major -> normal
versions:  -Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue1789] assumption about unsigned long byte size in struct module usage

[Gregory P. Smith]

Gregory P. Smith added the comment:

The giant patch was unnecessary, I misread what the struct module was
actually doing.  Auditing all uses of struct in the standard library the
only ones that look suspicious to me are:

Lib/posixfile.py
and all of the uses in Lib/plat-mac/

posixfile is probably fine, but it wouldn't surprise me if there are
bugs on some platforms in there due to using 'l' to decode off_t and 'h'
to decode pid_t within a fcntl structure.

The plat-mac stuff might break assuming those APIs are even available to
64bit programs.  I'll leave that up to the mac porting folks, as it is
its difficult if not impossible to even build a 64-bit Python under OS X.

Fixed in trunk r60234.

--
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

[issue1576] [Patch] Working post import hook and lazy modules

[Christian Heimes]

Christian Heimes added the comment:

The post import hook patch is in my pep 369 branch.

--
resolution:  -> out of date
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

[issue1795] PEP 754 update

[Christian Heimes]

Christian Heimes added the comment:

I've updated the PEP last week.

--
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

[issue1919] Backport of io.py

[Christian Heimes]

New submission from Christian Heimes:

I've started on a back port of Python 3.0's io.py to Python 2.6. First
results are promising.

cd trunk
svn cp ../py3k/Include/bytes_methods.h Include/
svn cp ../py3k/Objects/bytes_methods.c Objects/
svn cp ../py3k/Lib/io.py Lib/
svn cp ../py3k/Lib/test/test_io.py Lib/test/
svn cp ../py3k/Modules/_fileio.c Modules/
patch -p0 < trunk_io.patch

I'm not sure how to proceed with the missing bytearray type:

 * backport bytearray and the new buffer interface from 3.0
 * write a replacement for 2.6
 * replace the bytearray code with new code

--
components: Interpreter Core, Library (Lib)
files: trunk_io.patch
messages: 61626
nosy: tiran
priority: normal
severity: normal
status: open
title: Backport of io.py
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9277/trunk_io.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1326] "internal" zipimport.zipimporter feature untested

[Maciek Fijalkowski]

Maciek Fijalkowski added the comment:

There is another untested and undocumented attribute called prefix on
zipimporter objects.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1765140] logging: delay_fh option and configuration kwargs

[Vinay Sajip]

Vinay Sajip added the comment:

Added optional delay argument to FileHandler and subclasses.

--
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

[issue1920] while else loop seems to behave incorrectly

[Mark Summerfield]

New submission from Mark Summerfield:

I am using:

Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
IDLE 3.0a1 

This seems wrong:

>>> while False:
print("no")
else:
print("yes")


>>> 

I expected it to print "yes" because the docs say that the else suite is
executed if present and if the loop terminated normally (no break), and
this is the case here.

This works though:

>>> x = False
>>> while x:
print("no")
else:
print("yes")


yes
>>> 

So it seems that "while False" and "while variable" are giving different
behaviour.

--
components: Interpreter Core
messages: 61629
nosy: mark
severity: normal
status: open
title: while else loop seems to behave incorrectly
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

[issue1919] Backport of io.py

[Thomas Heller]

Thomas Heller added the comment:

> * backport bytearray and the new buffer interface from 3.0

backport of the new buffer interface is required for PEP 3118 which is
marked accepted:

"
It is intended that this PEP will be back-ported to Python 2.6 by adding
the C-API and the two functions to the existing buffer protocol.
"

--
nosy: +theller

__
Tracker <[EMAIL PROTECTED]>

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

[issue1921] Confusing Descrintro example

[Antti Rasinen]

New submission from Antti Rasinen:

Guido's document "Unifying types and classes in Python 2.2" (descrintro)
contains a confusing example for metaclass newbies. 


The example in question is autoprop, which uses the variable "name" in
three different contexts. First, it is the name of the class being
created. Second, it is used in a for loop to denote the keys of the
class dict. And thirdly, it is used to denote substrings of a subset of
those keys.

Upon my first encounter with the example, I found myself staring at the
getattr and setattr lines in disbelief. I associated "name" as the
parameter given to the __init__ function.

I'd propose changing the first for-loop name to "member" or similar
and the second to "propname" or "prop". 

Furthermore, a modern version of the same example could use sets and set
comprehensions instead of dict.keys():
props = {member[5:] for member in dict if member.startswith...}

--
components: Documentation
messages: 61631
nosy: arsatiki
severity: minor
status: open
title: Confusing Descrintro example
type: rfe
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, 
Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, 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

[issue1920] while else loop seems to behave incorrectly

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

python 2.5 has the same behaviour, if you use "while 0:" instead.
In compiler.c, there is code that optimizes away blocks like "if 0",
"while 0". 'if' correctly emit the else clause, 'while' does not...

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1923] meaningful whitespace can be lost in rfc822_escape

[Stephen Emslie]

New submission from Stephen Emslie:

distutils.util.rfc822_escape strips each line of its whitespace before
indenting, but this can mean losing meaningful whitespace, such as in
reStructuredText.


distutils uses rfc822_escape to escape fields in metadata, such as
PKG-INFO. This unfortunately means that you cant use reStructuredText
formatting in your long description (suggested in PEP345), or are
limited to a set that doesn't require indentation (no block quotes, etc.).

for example:

>>> rest = """
... a literal python block::
... >>> import this
... """
>>> print distutils.util.rfc822_escape(rest)

   a literal python block::
   >>> import this

I would be expecting this to look something like:

   a literal python block::
   >>> import this


It looks like this behavior was intentionally added in  rev 20099, but
that was about 7 years ago - before reStructuredText and eggs. I
wonder if it makes sense to re-think that implementation with this
sort of metadata in mind, assuming this behavior isn't required to be
rfc822 compliant. I think it would certainly be a shame to miss out on
a good thing like proper (renderable) reST in our metadata.

Is distutils being over-cautious in flattening out all whitespace? A
w3c discussion on multiple lines in rfc822 [1] seems to suggest that
whitespace can be 'unfolded' safely, so it seems a shame to be
throwing it away when it can have important meaning.

http://www.w3.org/Protocols/rfc822/3_Lexical.html

--
components: Library (Lib)
messages: 61633
nosy: stephenemslie
severity: normal
status: open
title: meaningful whitespace can be lost in rfc822_escape
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

[issue1920] while else loop seems to behave incorrectly

[Mark Dickinson]

Mark Dickinson added the comment:

This bug is also present in the trunk, with while 0 instead of while 
False.

This appears closely related to issue #1875.

In my opinion this is a serious bug in the core language.  I'm not sure 
whether it's serious enough to be considered a showstopper for 2.5.2.  
In any case, I'm raising the priority to get more eyes on this before 
2.5.2.

--
nosy: +marketdickinson
priority:  -> urgent
versions: +Python 2.5, 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

[issue1924] %i string format breaks for large floats (incomplete int conversion)

[David Goodger]

New submission from David Goodger:

I ran across this bug in some legacy production code when numbers got high:

>>> '%i' % 2e9
'20'
>>> '%i' % 3e9
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: int argument required

It looks like the float is being automatically converted to an int, but
floats > sys.maxint cause an error.  However,

>>> int(3e9)
30L

So the implicit float-to-int conversion is imperfect; large floats are
not being converted to long ints.

Same error in Python 2.3 through 2.6a0 (as of 2007-12-28).

In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to
convert".  The same error is triggered by int(3e9) though.

While it's arguably not-quite-sane to have code that triggers this
error, the inconsistency is what concerns me.

--
components: Interpreter Core
messages: 61635
nosy: goodger
severity: normal
status: open
title: %i string format breaks for large floats (incomplete int conversion)
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5, 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

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

Closed issue 1924 as duplicate of this one, but I'm copying here the
text from David, as it's very explanative:

"""
I ran across this bug in some legacy production code when numbers got high:

>>> '%i' % 2e9
'20'
>>> '%i' % 3e9
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: int argument required

It looks like the float is being automatically converted to an int, but
floats > sys.maxint cause an error.  However,

>>> int(3e9)
30L

So the implicit float-to-int conversion is imperfect; large floats are
not being converted to long ints.

Same error in Python 2.3 through 2.6a0 (as of 2007-12-28).

In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to
convert".  The same error is triggered by int(3e9) though.

While it's arguably not-quite-sane to have code that triggers this
error, the inconsistency is what concerns me.
"""

--
nosy: +goodger

_
Tracker <[EMAIL PROTECTED]>

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

[issue1924] %i string format breaks for large floats (incomplete int conversion)

[Facundo Batista]

Facundo Batista added the comment:

Duplicates #1742669 (copied this text to there)

--
nosy: +facundobatista
resolution:  -> duplicate
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

[issue1875] "if 0: return" not raising SyntaxError

[Mark Dickinson]

Mark Dickinson added the comment:

See also issue #1920

--
nosy: +marketdickinson

__
Tracker <[EMAIL PROTECTED]>

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

[issue1920] while else loop seems to behave incorrectly

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Here is a patch, made against py3k; it should apply cleanly to the trunk.

On the 2.5 branch, compile.c seems identical, but test_grammar.py looks
very different; the conversion should be easy.

Can someone review and apply it? I don't have svn access at the moment.

Added file: http://bugs.python.org/file9279/while.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1303614] Bypassing __dict__ readonlyness

[Guido van Rossum]

Guido van Rossum added the comment:

On Jan 23, 2008 11:12 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> Neal Norwitz added the comment:
>
> I looked at Guido's latest deldict.diff patch--the one to
> Objects/object.c only.  It seems good.  I can't convince myself either
> way about the change to Objects/typeobject.c.  I can't think of a way
> to cause a problem.  It seems safer to use Py_CLEAR in this case
> though.

Here's my reasoning: the object whose dict is being cleared itself has
a refcount of zero at this point. So it is truly unreachable from
Python code. So I'm not going to submit that part of the change.

> There are several other uses of _PyObject_GetDictPtr in
> Objects/typeobject.c.  It was pretty much the same--I can't convince
> myself either way.  Can Py_VISIT cause any Python code to execute that
> might lead to a problem?

The answer lies in the gc module which does all the visiting. A quick
scan of all the traverse() calls there indicates that none of them
call back into Python -- not a DECREF in sight.

> The other uses of _PyObject_GetDictPtr in
> Objects/typeobject.c seemed safer.  Not a very useful review.

I reviewed those too and found them safe.

I'll submit the change now.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1925] TypeError in deepcopy

[Egon Frerich]

New submission from Egon Frerich:

Traceback (most recent call last):
  File "/home/egon/Entwicklung/notes/gui/uicommand.py", line 645, in
doCommand
self.controller.copyItemID()
  File "/home/egon/Entwicklung/notes/gui/navicontroller.py", line 306,
in copyItemID
id_copy = self.Sammlung.kopiereEintrag(id)
  File "/home/egon/Entwicklung/notes/domain/note.py", line 185, in
kopiereEintrag
EintragKopie = copy.deepcopy(Eintrag)
  File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct
state = deepcopy(state, memo)
  File "/usr/lib/python2.5/copy.py", line 162, in deepcopy
y = copier(x, memo)
  File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct
state = deepcopy(state, memo)
  File "/usr/lib/python2.5/copy.py", line 162, in deepcopy
y = copier(x, memo)
  File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib/python2.5/copy.py", line 322, in _reconstruct
y = callable(*args)
  File "/usr/lib/python2.5/copy_reg.py", line 92, in __newobj__
return cls.__new__(cls, *args)
TypeError: object.__new__(PySwigObject) is not safe, use
PySwigObject.__new__()

--
components: Library (Lib)
messages: 61641
nosy: efrerich
severity: normal
status: open
title: TypeError in deepcopy
type: crash
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

[issue784443] test_repr failure on m68k-linux

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

Considering that there is no activity for long time, is it worthwhile to
keep this open?

--
nosy: +draghuram


Tracker <[EMAIL PROTECTED]>


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

[issue784443] test_repr failure on m68k-linux

[Facundo Batista]

Facundo Batista added the comment:

Can anybody reproduce this in 2.5? If yes, update the "version";
otherwise we can close it.

--
nosy: +facundobatista


Tracker <[EMAIL PROTECTED]>


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

[issue817920] select behavior undefined for empty lists

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

no activity. closing it.

--
nosy: +draghuram
resolution:  -> wont fix
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

[issue835338] [2.3.2] test_socket failure on IRIX 6.5

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

Please reopen if the problem can be reproduced with latest version.

--
nosy: +draghuram
resolution:  -> works for me
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

[issue1919] Backport of io.py

[Guido van Rossum]

Guido van Rossum added the comment:

Backporting bytearray should be relatively clean since it's a brand new
type right?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1925] TypeError in deepcopy

[Guido van Rossum]

Guido van Rossum added the comment:

Sorry, we're not able to help with SWIG errors in this bug tracker.

--
nosy: +gvanrossum
resolution:  -> rejected
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

[issue1926] NNTPS support in nntplib

[Ray Chason]

New submission from Ray Chason:

This patch adds SSL support to nntplib.  It is a followup to issue
#1535659 and addresses the objections raised in the comments to that
issue; it also changes the default port to 563 (nntps) rather than 119
if SSL is requested.

--
components: Library (Lib)
files: python-nntps-patch-1.txt
messages: 61648
nosy: chasonr
severity: normal
status: open
title: NNTPS support in nntplib
type: rfe
versions: Python 2.5
Added file: http://bugs.python.org/file9280/python-nntps-patch-1.txt

__
Tracker <[EMAIL PROTECTED]>

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

[issue1303614] Bypassing __dict__ readonlyness

[Guido van Rossum]

Guido van Rossum added the comment:

r60247 (2.5.2 branch), r60246 (2.6 trunk).

--
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

[issue1377858] segfaults when using __del__ and weakrefs

[Guido van Rossum]

Guido van Rossum added the comment:

This got fixed for classic classes in r60057,
and backported to 2.5.2 in 60056.

--
nosy: +gvanrossum

_
Tracker <[EMAIL PROTECTED]>

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

[issue1389051] imaplib causes excessive fragmentation for large documents

[Richard Cooper]

Richard Cooper added the comment:

I think I was just bitten by the non-SSL version of this bug on Python 2.5.1 
(r251:54863) on Mac 
OS 10.5. It manifested itself as a "malloc error: can't allocate region" while 
downloading a 
message using imaplib.

As suggested by effbot I changed "data = self._sock.recv(recv_size)" to "data = 
self._sock.recv(min(recv_size, 16384))" in both places that line appears in 
socket.py. Making 
that change fixed the problem for me.

Note that http://bugs.python.org/issue1092502 seems to be a duplicate of this 
issue. That issue 
contains a slightly different fix proposed by a_lauer, which I've not tried.

--
nosy: +rich

_
Tracker <[EMAIL PROTECTED]>

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

[issue1927] raw_input behavior incorrect if readline not enabled

[Skip Montanaro]

New submission from Skip Montanaro:

>From a thread on python-dev...

http://mail.python.org/pipermail/python-dev/2008-January/076446.html

Mike Kent mike.kent at sage.com
Thu Jan 24 16:33:47 CET 2008

Recently I was trying to debug an old python program who's maintenance I
inherited.  I was using the quick-and-dirty method of putting some 'print
>>sys.stderr' statements in the code, and then running the command with
'2>filename' appended to the end of the command line.  Imagine my surprise
to see that all of the prompt text from the program's raw_input calls were
also disappearing from the screen output, and appearing in the stderr
output routed to the file.

The latest documentation for raw_input states "If the prompt argument is
present, it is written to standard output without a trailing newline."
I posted a question regarding the observed behavior to comp.lang.python
and Gabriel Genellina (thanks Gabriel!) pointed out that despite the
documentation, raw_input was hard-coded to always output its prompt text
to stderr.

This raises two questions:
1. Shouldn't the current documentation be corrected to state that raw_input
writes its prompt to standard error?
2. Is this really the hard-coded behavior we want?  I don't think my
use-case is that odd; in fact, what I find very odd is that the prompt
output is send to stderr.  I mean, I'm printing the prompt for a question,
not some error message. Can there not at least be an optional parameter to
indicate that you want the output sent to stdout rather than stderr?

... after a few responses ...

Guido van Rossum guido at python.org
Thu Jan 24 21:09:12 CET 2008

On Jan 24, 2008 11:41 AM, Mike Kent  wrote:
...
> Interesting point about whether GNU readline is installed.  My setup
is RedHat
> Linux, with Python 2.5 that I built and installed myself.  GNU
readline is not,
> in fact, installed.  If you look at Python2.5/Parser/myreadline.c,
function
> PyOS_StdioReadline, line 125, you will see that prompt output is being
sent to
> stderr.  As best as my Python-fu can determine, this is the code used
to output
> a raw_input prompt (thanks again to Gabriel Genellina for pointing me
in the
> right direction.)
>
> It's entirely likely that the difference in what I am seeing and what
you guys
> are seeing is caused by my not having GNU readline installed. 
Nevertheless,
> the behavior without it seems wrong, and is certainly different from the
> documentation.

Agreed.

--
components: Interpreter Core
messages: 61652
nosy: skip.montanaro
severity: normal
status: open
title: raw_input behavior incorrect if readline not enabled
versions: Python 2.5, 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

[issue1927] raw_input behavior incorrect if readline not enabled

[Skip Montanaro]

Changes by Skip Montanaro:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue1927] raw_input behavior incorrect if readline not enabled

[Christian Heimes]

Changes by Christian Heimes:


--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1923] meaningful whitespace can be lost in rfc822_escape

[Christian Heimes]

Christian Heimes added the comment:

Can you provide a patch with doc updates and an unit test?

--
keywords: +easy
nosy: +tiran
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue1926] NNTPS support in nntplib

[Christian Heimes]

Christian Heimes added the comment:

I assign it to janssens. He is our SSL expert. I also set the version to
2.6. New features get into the next major release.

--
assignee:  -> janssen
keywords: +patch
nosy: +janssen, tiran
priority:  -> normal
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

[issue1921] Confusing Descrintro example

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +easy
priority:  -> low
versions:  -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, 
Python 2.2.3, Python 2.3, Python 2.4, 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

[issue1927] raw_input behavior incorrect if readline not enabled

[Gabriel Genellina]

Gabriel Genellina added the comment:

GNU readline is configured as to prompt the user using standard output, 
and read input from standard input; if this is the desired behavior it 
would be easy to provide a simple patch so input/raw_input behave that 
way even when readline is not used.

--
nosy: +gagenellina

__
Tracker <[EMAIL PROTECTED]>

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

[issue1577] shutil.move() does not use os.rename() if dst is a directory

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is a patch, which also contains additional unit tests for
shutil.move().
It would be nice if people tested it under various configurations, to
see if there are any problems.

Added file: http://bugs.python.org/file9281/shutilmove.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1928] test_urllib fails

[Guido van Rossum]

New submission from Guido van Rossum:

FAIL: test_read (__main__.urlopen_HttpTests)
--
Traceback (most recent call last):
 File "Lib/test/test_urllib.py", line 130, in test_read
   self.assertEqual(fp.getcode(), 200)
AssertionError: None != 200

It works in the trunk though.

Georg, didn't you touch this last, adding the code-getting API in the
trunk? Perhaps it's a merge glitch?

--
components: Library (Lib)
messages: 61657
nosy: gvanrossum
severity: normal
status: open
title: test_urllib fails
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

[issue1910] Document that with is slower than try/finally

[Benjamin Peterson]

Benjamin Peterson added the comment:

Ok, I see your reasoning. I'm going to start going to through the rest
of the library for places with should be used.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1929] httplib _read_chunked TypeError ||| i = line.find(";")

[Georgij Kondratjev]

New submission from Georgij Kondratjev:

(With current python3-svn)
While trying to response.read() got this:

---
  File "/usr/lib/python3.0/httplib.py", line 533, in read
return self._read_chunked(amt)
  File "/usr/lib/python3.0/httplib.py", line 573, in _read_chunked
i = line.find(";")
TypeError: expected an object with the buffer interface
---

To debug I did this:
---
 line = self.fp.readline()
+print(' ***', line)
 i = line.find(b";")
---
and got "*** b'2e6d\r\n'" followed by those TypeError exception.
I did this:
---
def _read_chunked(self, amt):
assert self.chunked != _UNKNOWN
chunk_left = self.chunk_left
-   value = ""
+   value = b""

if chunk_left is None:
line = self.fp.readline()
-   i = line.find(";")
+   i = line.find(b";")
---
And it seems to work.

--
components: Library (Lib)
messages: 61659
nosy: orivej
severity: normal
status: open
title: httplib _read_chunked TypeError ||| i = line.find(";")
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

[issue1929] httplib _read_chunked TypeError ||| i = line.find(";")

[Georgij Kondratjev]

Georgij Kondratjev added the comment:

Sorry, while debugging there was no 'b':
---
 line = self.fp.readline()
+print(' ***', line)
 i = line.find(";")
---

__
Tracker <[EMAIL PROTECTED]>

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

[issue1930] sys.maxint not found in Python 3.0a2

[Georgij Kondratjev]

Georgij Kondratjev added the comment:

Maybe it was not noted, but it is documented: 
http://docs.python.org/dev/3.0/library/sys.html

--
nosy: +orivej

__
Tracker <[EMAIL PROTECTED]>

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

[issue1930] sys.maxint not found in Python 3.0a2

[Robert Clark]

Robert Clark added the comment:

sys.maxint was changed to sys.maxsize, but this was not noted in the
documentation.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1931] NameError: global name 'basestring' is not defined

[Robert Clark]

New submission from Robert Clark:

File
"/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py",
line 1511, in __init__
if isinstance( expr, basestring ):
NameError: global name 'basestring' is not defined

--
messages: 61662
nosy: rclark
severity: normal
status: open
title: NameError: global name 'basestring' is not defined
type: compile error
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

[issue1930] sys.maxint not found in Python 3.0a2

[Robert Clark]

New submission from Robert Clark:

File
"/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py",
line 971, in __init__
self.maxLen = sys.maxint

AttributeError: 'module' object has no attribute 'maxint'

--
messages: 61661
nosy: rclark
severity: normal
status: open
title: sys.maxint not found in Python 3.0a2
type: compile error
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

[issue1931] NameError: global name 'basestring' is not defined

[Robert Clark]

Robert Clark added the comment:

basestring is in the builtins library for 2.5.1, but is not there in 3.0a2

Linux: RHEL40

__
Tracker <[EMAIL PROTECTED]>

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

[issue1930] sys.maxint not found in Python 3.0a2

[Guido van Rossum]

Changes by Guido van Rossum:


--
components: +Documentation

__
Tracker <[EMAIL PROTECTED]>

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

[issue1931] NameError: global name 'basestring' is not defined

[Guido van Rossum]

Guido van Rossum added the comment:

It's been deleted. Use 2to3; it will replace it with 'str'.

--
components: +Documentation
nosy: +gvanrossum
type: compile error -> 

__
Tracker <[EMAIL PROTECTED]>

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

[issue1926] NNTPS support in nntplib

[Bill Janssen]

Bill Janssen added the comment:

Unfortunately, it uses the deprecated socket.ssl calls.  Re-worked to
use the new SSL module, it would be OK.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1920] while else loop seems to behave incorrectly

[Mark Dickinson]

Mark Dickinson added the comment:

Looks like Amaury found his svn access.  Is it okay to close this now?

--
resolution:  -> accepted
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

[issue1932] Cosmetic patch to supress compiler warning

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto:

This is not compile error, but I cannot find more proper tag than this.

--
components: Build
files: const.patch
messages: 61669
nosy: ocean-city
severity: minor
status: open
title: Cosmetic patch to supress compiler warning
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file9282/const.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1920] while else loop seems to behave incorrectly

[Mark Dickinson]

Mark Dickinson added the comment:

Forgot to say:  Amaury checked his fix in in revision #60265 (trunk) and 
revision #60268 (Python 2.5).

Thanks for the bug report, Mark!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1930] sys.maxint not found in Python 3.0a2

[Martin v. Löwis]

Martin v. Löwis added the comment:

sys.maxint was *not* changed to sys.maxsize - it was simply removed.
pyparsing apparently hasn't been ported to Python 3; please bring this
up with the pyparsing authors (but then, Python 3 hasn't been released,
so they might decide not to take any action for several years, until,
say, Python 3.2).

sys.maxint used to indicate the maximum value that an int could have. In
Python 3, the int type has no maximum value anymore.

The only place where this might need some notice is the whatsnew text.

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1931] NameError: global name 'basestring' is not defined

[Martin v. Löwis]

Martin v. Löwis added the comment:

Robert, can you please explain why you consider this as a bug?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1932] Cosmetic patch to supress compiler warning

[Martin v. Löwis]

Martin v. Löwis added the comment:

Can you please explain what compiler you are using and what warning it
produces?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1932] Cosmetic patch to supress compiler warning

[Hirokazu Yamamoto]

Hirokazu Yamamoto added the comment:

VisualC++6 (this is only VC compiler I have)

Compiler Warning (level 1) C4090
'=' : different 'const' qualifiers

http://msdn2.microsoft.com/en-us/library/k77bkb8d(VS.71).aspx

__
Tracker <[EMAIL PROTECTED]>

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

[issue1928] test_urllib fails

[Georg Brandl]

Georg Brandl added the comment:

I'll fix that this weekend.

--
assignee:  -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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