[issue7891] add links to SVN for documentation developers

[Georg Brandl]

Georg Brandl  added the comment:

Added a link to the checkout FAQ in r12861.

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

[issue7961] Py3k: decoding empty bytestring with invalid encoding throws no error

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson  added the comment:
> 
> Thanks for the patch.
> 
> Rather than remove that optimization entirely, I'd consider pushing it into 
> PyUnicode_Decode.
> 
> All tests (whether for the standard library or for the core) go into 
> Lib/test, so that would be the right place.  test_codecs_errors in 
> Lib/test/test_unicode.py looks appropriate.
> 
> Adding Marc-André to the nosy list:  this is much more his domain than mine.

I think this is a case for "practicality beats purity": an empty
encoded object will in all practical cases result in an empty Unicode
object when decoded, regardless of which encoding is used.

It's not a 100% clean approach, but does help performance a lot since
you avoid the intermediate conversions, lookups, etc.

If you want to check whether an encoding is registered or not,
you should normally use the codecs.lookup() function.

In which specific case did you find the problem you mentioned ?

--

___
Python tracker 

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

[issue7963] Misleading error message from object(arg)

[Georg Brandl]

Georg Brandl  added the comment:

The latter is no inconsistency; tuples are immutable, lists are not.  
Therefore, for lists, __init__ is the initializer, not __new__.  In order not 
to duplicate argument checking, __new__ does nothing special with them.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue7961] Py3k: decoding empty bytestring with invalid encoding throws no error

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ori Avtalion wrote:
> 
> Ori Avtalion  added the comment:
> 
> Ignoring the custom utf-8/latin-8 conversion functions, the actual checking 
> if a codec exists is done in Python/codecs.c's PyCodec_Decode.
> 
> Is that where I should move the aforementioned optimization to?

That's not a good idea, since codecs that are not used for decoding
into Unicode may very well return something other than an empty
string if passed an empty string on input, e.g.

'x\x9c\x03\x00\x00\x00\x00\x01'

> Is it safe to assume that the decoded object is always a string/bytestring?

No, that's not safe, esp. not in the codecs module. Codecs
can return arbitrary types. It's up to the codecs to decide
what type combinations they support.

In Python 3.x we check the types in the unicode.encode()/
bytes.decode() methods, but that's only a specific use case
in those helper methods, not a general limitation of the
codec architecture.

It's planned to add new .transform()/.untransform() methods
to unicode and bytes which will then provide access to
same-type codecs.

--

___
Python tracker 

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

[issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files

[Michael Newman]

New submission from Michael Newman :

Attached is a version checking script. When you run it normally, it produces 
output such as:

E:\notes\Programming\python3>c:\Python26\python.exe version_check.py
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]

E:\notes\Programming\python3>c:\Python31\python.exe version_check.py
3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]

I wanted to test using "-m pdb" on this script. It works okay for Python 2.6:

E:\notes\Programming\python3>c:\Python26\python.exe -m pdb version_check.py
> e:\notes\programming\python3\version_check.py(4)()
-> Last Updated: 2008-12-21"""
(Pdb) c
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
The program finished and will be restarted
> e:\notes\programming\python3\version_check.py(4)()
-> Last Updated: 2008-12-21"""
(Pdb) q

However, if I try it on Python 3.1 I get a SyntaxError:

# --- Begin Python 3.1 Example with "\r\n" source code --- #

E:\notes\Programming\python3>c:\Python31\python.exe -m pdb version_check.py
SyntaxError: ('invalid syntax', ('e:\\notes\\programming\\python3\\version_check
.py', 4, 132, '"""Check what version of python is running.\r\n\r\nWritten by: Mi
chael Newman \r\nLast Updated: 2008-12-21"""\r\n'))
> (1)()
(Pdb) c
Traceback (most recent call last):
  File "c:\Python31\lib\pdb.py", line 1297, in main
pdb._runscript(mainpyfile)
  File "c:\Python31\lib\pdb.py", line 1216, in _runscript
self.run(statement)
  File "c:\Python31\lib\bdb.py", line 378, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "e:\notes\programming\python3\version_check.py", line 4
"""Check what version of python is running.

Written by: Michael Newman 
Last Updated: 2008-12-21"""



^
SyntaxError: invalid syntax
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> (1)()
(Pdb) q
Post mortem debugger finished. The version_check.py will be restarted
SyntaxError: ('invalid syntax', ('e:\\notes\\programming\\python3\\version_check
.py', 4, 132, '"""Check what version of python is running.\r\n\r\nWritten by: Mi
chael Newman \r\nLast Updated: 2008-12-21"""\r\n'))
> (1)()
(Pdb) q

# --- End Python 3.1 Example with "\r\n" source code --- #

As a hunch, my program is has Windows style line endings "\r\n", so I saved the 
file to another file name and converted it to Unix style "\n" line endings... 
and this version does work:

# --- Begin Python 3.1 Example using "\n" source code --- #

E:\notes\Programming\python3>copy version_check.py version_check_unix.py
1 file(s) copied.

E:\notes\Programming\python3>which d2u
C:\Program Files\GnuWin32\bin\d2u.EXE

E:\notes\Programming\python3>d2u version_check_unix.py
version_check_unix.py: done.

E:\notes\Programming\python3>py31 -m pdb version_check_unix.py
> e:\notes\programming\python3\version_check_unix.py(4)()
-> Last Updated: 2008-12-21"""
(Pdb) c
3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]
The program finished and will be restarted
> e:\notes\programming\python3\version_check_unix.py(4)()
-> Last Updated: 2008-12-21"""
(Pdb) q

# --- End Python 3.1 Example using "\n" source code --- #

Is "\r\n" not officially supported by "-m pdb"? Or is this a bug?

--
components: Library (Lib)
files: version_check.py
messages: 99570
nosy: mnewman
severity: normal
status: open
title: "-m pdb" SyntaxError for "\r\n" formatted py files
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16256/version_check.py

___
Python tracker 

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

[issue7966] mhlib uses deprecated module

[Shashwat Anand]

Shashwat Anand  added the comment:

There is a discussion going on python-dev too, the author being sjoerd.
http://mail.python.org/pipermail/python-dev/2010-February/097772.html
GvR reply : 
http://mail.python.org/pipermail/python-dev/2010-February/097774.html

--
nosy: +l0nwlf

___
Python tracker 

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

[issue5930] Transient error in multiprocessing

[Florent Xicluna]

Florent Xicluna  added the comment:

Again, but with more details:
http://www.python.org/dev/buildbot/all/builders/i386%20Ubuntu%203.1/builds/302

test_multiprocessing
Process Process-49:
Traceback (most recent call last):
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/process.py",
 line 233, in _bootstrap
self.run()
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/process.py",
 line 88, in run
self._target(*self._args, **self._kwargs)
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/test/test_multiprocessing.py",
 line 616, in f
woken.release()
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py",
 line 962, in release
return self._callmethod('release')
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py",
 line 750, in _callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---
Traceback (most recent call last):
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py",
 line 219, in serve_client
obj, exposed, gettypeid = id_to_obj[ident]
KeyError: 'cc9dc3c'
---
test test_multiprocessing failed -- Traceback (most recent call last):
  File 
"/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/test/test_multiprocessing.py",
 line 1077, in test_number_of_objects
self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 9 != 1

--
keywords: +buildbot

___
Python tracker 

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

[issue7966] mhlib uses deprecated module

[R. David Murray]

R. David Murray  added the comment:

The outcome of that discussion is that what this implies is that there is 
insufficient test coverage of mhlib, such that no one noticed that mhlib was 
generating deprecation messages.

mhlib is itself effectively deprecated, since it no longer exists in py3k.  If 
someone wants to propose patches to fix mhlib that's fine, but this is a very 
low priority issue.

--
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
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

[issue7966] mhlib uses deprecated module

[Sjoerd Mullender]

Sjoerd Mullender  added the comment:

What's difficult about just doing:

import mhlib

?  That's all it takes to get the warning.

--

___
Python tracker 

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

[issue7966] mhlib does not emit deprecation warning

[R. David Murray]

R. David Murray  added the comment:

Hmm.  Apparently the actual bug is that mhlib itself does not produce a 
deprecated message.  The test was explicitly changed to mark the module as one 
that is deprecated.

--
title: mhlib uses deprecated module -> mhlib does not emit deprecation warning

___
Python tracker 

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

[issue7962] Demo/ directory needs to be tested and pruned

[Georg Brandl]

Georg Brandl  added the comment:

There's only so much free time developers can spend on Python.  Also, most 
demos still work in 2.x, even if they are unmaintained, ugly or demonstrate old 
concepts.  In contrast, most demos weren't tested after porting to 3.x, so many 
of them don't even run there (and nobody runs them, otherwise we'd have got at 
least some reports in the tracker).

--
nosy: +georg.brandl

___
Python tracker 

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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Amaury-- I think that will work.  I put together a small patch that seems to 
pass all the tests, but it too messy.  We need some care to make sure we don't 
spin forever if there's some degenerate case where we never escape GC.

--

___
Python tracker 

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

[issue7962] Demo/ directory needs to be tested and pruned

[Georg Brandl]

Georg Brandl  added the comment:

Well, these demos are not meant to demonstrate the fastest algorithms, but to 
demonstrate how easy and readable simple algorithms can be written in Python.

That said, if you can write better versions that are also very readable, 
they'll make a good addition.

--

___
Python tracker 

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

[issue7967] PyXML is dead

[Florent Xicluna]

Florent Xicluna  added the comment:

Maybe the PyXML hack can be removed, too?
http://svn.python.org/view/python/trunk/Lib/xml/__init__.py?view=markup

--
nosy: +flox
priority:  -> normal

___
Python tracker 

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

[issue7968] __dict__ Exception using class attributes

[Andrew Shuiu]

New submission from Andrew Shuiu :

Interpreter do not fill in __dict__ attribute of a class which has atributes. 
dir() shows them, but not __dict__. It works only when attributes are created 
dynamically at runtime, such as class.attribute = value, not in class 
definition.
Behaviour is the same on py2.6.4 and py3.1.

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyClass:
... myattr = 0
...
>>> inst = MyClass()
>>> print(inst.__dict__["myattr"])
Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'myattr'
>>>

but in this code it works fine:

class MyClass:
 myattr = 0
inst = MyClass()
inst.myattr = 1
print(inst.__dict__["myattr"])

So __dict__ do not contain the attributes of an instantiated object, as it 
should be, according to documentation.

--
components: Build, Windows
messages: 99595
nosy: asuiu
severity: normal
status: open
title: __dict__ Exception using class attributes
type: behavior
versions: 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

[issue7968] __dict__ Exception using class attributes

[R. David Murray]

R. David Murray  added the comment:

That's because the attribute values don't exist in the instance until you make 
an assignment to them.  Before that the exist only as class attributes.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/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

[issue7969] shutil.copytree error handling non-standard and partially broken

[Shawn]

New submission from Shawn :

The error handling present in the implementation of shutil.copytree in python 
2.6.4 (and perhaps other versions) is non-standard and partially broken.

In particular, I'm unable to find any pydoc documentation that indicates that 
when copytree raises shutil.Error, that the error instead of the standard 
2-tuple or 3-tuple was initialised with a list of entries.

This means that callers catching EnvironmentError will be in for a surprise 
whenever they check e.args and find a tuple containing a list instead of just a 
tuple.

Callers will also be disappointed to find that the entries in the list may be 
tuples or strings due to what looks like a bug in copystat error handling (it's 
using extend instead of append).

I could possibly live with this behaviour somewhat if it was actually 
documented and consistent since shutil.Error can be caught specifically instead.

It's also really unfortunate that the tuples that are stored here aren't the 
actual exception objects of the errors encountered so callers cannot perform 
more granular error handling (permissions exceptions, etc.).

I'd like to request that this function:

* be fixed to append copystat errors correctly

* have shutil.Error documentation indicate the special args format and explain 
how it might be parsed

* consider having it record the exception objects instead of the exception 
message

* suggest that the default str() output for shutil.Error be improved

--
components: Library (Lib)
messages: 99597
nosy: swalker
severity: normal
status: open
title: shutil.copytree error handling non-standard and partially broken
type: behavior
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

[issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files

[R. David Murray]

R. David Murray  added the comment:

It's a bug, and the bug is fixed (indirectly) in py3k trunk via improvements to 
the 'compile' function.  That fix can't be backported because it is a behavior 
change, so fixing this in 3.1 would require fixing pdb to deal with universal 
new lines.  I don't think that is worth it, but if someone wants to propose a 
patch I'll reopen the issue.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/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

Re: [issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

I don't think the HTTPConnection class was designed to work with
sockets that don't follow the Python socket API.  If you want to use a
different socket, you should create some wrapper that emulates the
Python socket ref count behavior.

Jeremy

On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz  wrote:
>
> Robert Buchholz  added the comment:
>
> An example cannot be constructed using the standard python socket class. As 
> you point out, the response.will_close attribute is set correctly: The client 
> is supposed to close to connect after completion of the request (as does the 
> server). However, when the HTTPConnection object calls close() on the socket, 
> reading the request is not completed -- the request object merely created a 
> file-like object representing the socket.
>
> The reason why this is not an issue is that the Python socket library does 
> reference counting to determine when to close a socket object. When the 
> HTTPConnection calls close(), its own socket object is destroyed and 
> unreferenced. However, the file-like object in the HTTPResponse still has a 
> copy of the socket.
>
> In alternative socket implementations (like Paramiko SOCKS-proxied sockets), 
> this poses a problem: When the socket user calls close(), they actually close 
> the socket -- as the original socket API documentation describes:
>
>    close()
>    Close the socket.  It cannot be used after this call.
>
>    makefile([mode[, bufsize]]) -> file object
>    Return a regular file object corresponding to the socket.  The mode
>    and bufsize arguments are as for the built-in open() function.
>
> Consequently, I do not consider this to be a bug in Paramiko and reported it 
> for the httplib. I can present example code using a paramiko tunneled socket 
> (client and server) if you like.
>
> --
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files

[R. David Murray]

R. David Murray  added the comment:

It's a bug, and the bug is fixed (indirectly) in py3k trunk via improvements to 
the 'compile' function.  That fix can't be backported because it is a behavior 
change.

On the other hand, it appears as though the fix is to change the open statement 
from using 'rb' to using 'r'.  I'm not at all sure why it is opened in 'rb' 
mode, and it's possible it should be changed in trunk as well.

--
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[R. David Murray]

R. David Murray  added the comment:

But a goal is for the standard library to work with Python implementations 
other than CPython, and the reference counting behavior described won't happen 
in non-reference counting implementations.  So I don't think that requiring 
emulation of ref-counting behavior is valid.

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

[issue7968] __dict__ Exception using class attributes

[Andrew Shuiu]

Andrew Shuiu  added the comment:

Hello Murray,
That seems a little strange to me, because if an object is instance of
a class, it should inherit all of it attributes.

Is it an optimization issue? because I observed that all
instances of a class that has such "static" attributes, shares that
attributes for less memory using.

Anyway, thank you for explications.

Saturday, February 20, 2010, 12:03:46 AM, you wrote:

> R. David Murray  added the comment:

> That's because the attribute values don't exist in the instance
> until you make an assignment to them.  Before that the exist only as class 
> attributes.

priority:  ->> normal
resolution:  ->> invalid
stage:  ->> committed/rejected
status: open ->> closed

> ___
> Python tracker 
> 
> ___

-- 
Best regards,
Andrei SUIU
Virus Researcher, BitDefender
  as...@bitdefender.com  mailto:as...@bitdefender.com

Phone : +40 232 232 222
www.bitdefender.com

The content of this message and attachments are confidential and are 
classified as BitDefender's Proprietary Information. The content of 
this message is intended solely for the use of the individual or entity 
to whom it is addressed and others authorized to receive it. If you are 
not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action based on this information are 
strictly prohibited and may be precluded by law. If you have received 
this message in error, please notify us immediately and then delete it 
from your system. BitDefender SRL is neither liable for the proper and 
complete transmission of the information contained in this message nor 
for any delay in its receipt.

--

___
Python tracker 

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

[issue7970] email.Generator fails to flatten message parsed by email.Parser

[Charles Cazabon]

New submission from Charles Cazabon :

email.Generator fails to flatten a message parsed by email.Parser; it throws an 
exception with an odd (but apparently legal) message.  First, the exception:

  File "/usr/local/lib/python2.6/email/generator.py", line 84, in flatten
self._write(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 109, in _write
self._dispatch(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 135, in _dispatch
meth(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 266, in 
_handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
  File "/usr/local/lib/python2.6/email/message.py", line 189, in get_payload
raise TypeError('Expected list, got %s' % type(self._payload))
TypeError: Expected list, got 

The oddity of the message its handling is that it's a single-part MIME message, 
where the content-type is declared as message/rfc822.  Most MUAs, when 
forwarding message, create a multipart MIME message with a single attachment 
part, and have the attachment be message/rfc822.  But Groupwise, when 
configured to forward messages to another address (without specifying an 
additional text to insert with the forwarded message) creates these slightly 
odd messages.

I've not seen them before, but a couple of getmail users have run into this 
issue.  I've confirmed the problem is the same in Python 2.3, 2.4, 2.5, and 
2.6, and I presume it's the same in 2.7 but haven't tested yet.

I'll attach a minimal test script and a datafile which is a minimal message 
showing the problem.

--
components: Library (Lib)
files: testcase.py
messages: 99606
nosy: charlesc
severity: normal
status: open
title: email.Generator fails to flatten message parsed by email.Parser
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file16262/testcase.py

___
Python tracker 

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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Fri, Feb 19, 2010 at 6:22 PM, R. David Murray  wrote:
>
> R. David Murray  added the comment:
>
> But a goal is for the standard library to work with Python implementations 
> other than CPython, and the reference counting behavior described won't 
> happen in non-reference counting implementations.  So I don't think that 
> requiring emulation of ref-counting behavior is valid.

I don't think an implementation of Python sockets would be considered
correct unless it supported this behavior.  CPython goes to elaborate
lengths to make it work across platforms.

Jeremy

> --
> nosy: +r.david.murray
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue7970] email.Generator fails to flatten message parsed by email.Parser

[R. David Murray]

R. David Murray  added the comment:

The problem only arises with HeaderParser.  The full parser turns the body into 
a list containing a Message object, because that's how the email package models 
the message structure.  HeaderParser treats the body as a single string.  All 
that is fine, but generator's flatten method has special handlers for certain 
mime types, and message/rfc822 is one of them.  It is looking for what it 
"knows" the message/rfc822 body looks like (a list containing a Message), but 
what it finds is a string.

The fix is probably to special case get_payload returning a string inside the 
_handle_message.  I've attached a patch that adds your test file as a unit test 
and provides that fix.

--
assignee:  -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review

___
Python tracker 

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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[R. David Murray]

R. David Murray  added the comment:

But the docs (which presumably describe the API) say that the socket is 
unusable after the call to close, which argues that the paramiko sockets are 
following the documented API.  Do the docs need to be corrected?

--

___
Python tracker 

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

[issue7971] hidraw Linux module

[Danny Milosavljevic]

Danny Milosavljevic  added the comment:

Usage example:

>>>import hidraw
>>>import os
>>>hidraw.get_info(os.open("/dev/hidraw0", os.O_RDONLY))
hidraw.Info(3, 0x0E20, 0x0200)

--

___
Python tracker 

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

[issue7898] rlcompleter add "real tab" when text is empty feature

[zhou wei]

zhou wei  added the comment:

Pitrou,

I think you are right on "On the other hand, it will appear quite bizarre to 
people who have another, dedicated key for auto-completion." If I assign 
another key for auto-completion, the behavior becomes really strange.  It 
happens in ipython too.

But I guess most people just use tab as the default key for auto-completion, 
and the readline module document say:"
get_begidx( ) 
Get the beginning index of the readline tab-completion scope. 
get_endidx( ) 
Get the ending index of the readline tab-completion scope. 
set_completer_delims( string) 
Set the readline word delimiters for tab-completion. 
get_completer_delims( ) 
Get the readline word delimiters for tab-completion. 
"
And now, I think the problem becomes:convenience for the majority or protection 
for the minority. If we decide to protect the minority, I think I can submit 
another patch for the readline module document, to make the document constant, 
so, the document looks like:
get_endidx( ) 
Get the ending index of the readline auto-completion scope. 

PS: Is there a way to find out the current key-binding on auto-completion? If 
we can find this, I think we can "if else" this behavior to satisfy everybody.

--

___
Python tracker 

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