[issue1067] test_smtplib failures (caused by asyncore)

[Thomas Wouters]

Changes by Thomas Wouters:


--
assignee: twouters -> nobody
nosy: +nobody

__
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

[Thomas Herve]

Thomas Herve added the comment:

I attach a patch adding a test and some documentation. This tries to
solve issue1325 too.

exarkun, does that fulfill your original request?

--
nosy: +therve
Added file: http://bugs.python.org/file8877/1326.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Doc/library/zipimport.rst
===
--- Doc/library/zipimport.rst   (revision 59333)
+++ Doc/library/zipimport.rst   (working copy)
@@ -71,11 +71,20 @@
 
 .. class:: zipimporter(archivepath)
 
-   Create a new zipimporter instance. *archivepath* must be a path to a 
zipfile.
+   Create a new zipimporter instance. *archivepath* must be a path to a
+   zipfile, or to a specific path inside a zipfile. For example, it can be
+   */tmp/myimport.zip*, or */tmp/myimport.zip/mydirectory*, if mydirectory is a
+   valid directory inside the archive.
+
:exc:`ZipImportError` is raised if *archivepath* doesn't point to a valid 
ZIP
archive.
 
 
+.. attribute:: zimporter.archive
+
+   The name of the zipfile targeted, without the subpath (read-only).
+
+
 .. method:: zipimporter.find_module(fullname[, path])
 
Search for a module specified by *fullname*. *fullname* must be the fully
Index: Lib/test/test_zipimport.py
===
--- Lib/test/test_zipimport.py  (revision 59333)
+++ Lib/test/test_zipimport.py  (working copy)
@@ -212,6 +212,7 @@
 z.close()
 
 zi = zipimport.zipimporter(TEMP_ZIP)
+self.assertEquals(zi.archive, TEMP_ZIP)
 self.assertEquals(zi.is_package(TESTPACK), True)
 zi.load_module(TESTPACK)
 
@@ -227,6 +228,36 @@
 z.close()
 os.remove(TEMP_ZIP)
 
+def testZipImporterMethodsInSubDirectory(self):
+packdir = TESTPACK + os.sep
+packdir2 = packdir + TESTPACK2 + os.sep
+files = {packdir2 + "__init__" + pyc_ext: (NOW, test_pyc),
+ packdir2 + TESTMOD + pyc_ext: (NOW, test_pyc)}
+
+z = ZipFile(TEMP_ZIP, "w")
+try:
+for name, (mtime, data) in files.items():
+zinfo = ZipInfo(name, time.localtime(mtime))
+zinfo.compress_type = self.compression
+z.writestr(zinfo, data)
+z.close()
+
+zi = zipimport.zipimporter(TEMP_ZIP + os.sep + packdir)
+self.assertEquals(zi.archive, TEMP_ZIP)
+self.assertEquals(zi.is_package(TESTPACK2), True)
+zi.load_module(TESTPACK2)
+
+self.assertEquals(zi.is_package(TESTPACK2 + os.sep + '__init__'), 
False)
+self.assertEquals(zi.is_package(TESTPACK2 + os.sep + TESTMOD), 
False)
+
+mod_name = TESTPACK2 + os.sep + TESTMOD
+mod = __import__(module_path_to_dotted_name(mod_name))
+self.assertEquals(zi.get_source(TESTPACK2), None)
+self.assertEquals(zi.get_source(mod_name), None)
+finally:
+z.close()
+os.remove(TEMP_ZIP)
+
 def testGetData(self):
 z = ZipFile(TEMP_ZIP, "w")
 z.compression = self.compression
Index: Modules/zipimport.c
===
--- Modules/zipimport.c (revision 59333)
+++ Modules/zipimport.c (working copy)
@@ -555,8 +555,15 @@
 "zipimporter(archivepath) -> zipimporter object\n\
 \n\
 Create a new zipimporter instance. 'archivepath' must be a path to\n\
-a zipfile. ZipImportError is raised if 'archivepath' doesn't point to\n\
-a valid Zip archive.");
+a zipfile, or to a specific path inside a zipfile. For example, it can be\n\
+'/tmp/myimport.zip', or '/tmp/myimport.zip/mydirectory', if mydirectory is a\n\
+valid directory inside the archive.\n\
+\n\
+'ZipImportError is raised if 'archivepath' doesn't point to a valid Zip\n\
+archive.\n\
+\n\
+The 'archive' attribute of zipimporter is a read-only copy of the\n\
+name of the zipfile targeted.");
 
 #define DEFERRED_ADDRESS(ADDR) 0
 
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1539] test_collections: failing refleak test

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I found indeed 2 problems in regrtest.py.
I don't have svn access for the moment, so I cannot provide a regular
patch, so here are the changes:

- The line
obj._abc_registry = abcs.get(obj, {}).copy()
incorrectly puts an empty dictionary in _abc_registry. It should be a set:
from weakref import WeakSet
obj._abc_registry = abcs.get(obj, WeakSet()).copy()

- This test in dash_R()
if not isinstance(abc, _Abstract):
is not correct. It should be 
if not issubclass(abc, _Abstract):
(Note that dash_R_cleanup contains the same line, but correctly)

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

[issue798876] windows sys.path contains nonexistant directory

[Quentin Gallet-Gilles]

Quentin Gallet-Gilles added the comment:

I'm able to reproduce it on 2.4, 2.5 and it's most likely still here in
the trunk. Is it still considered a bug ?


>>> import sys

>>> import os

>>> for file in sys.path:

... print "%s - %s" % (file, os.path.exists(file))

...

: False

C:\WINNT\system32\python25.zip : False

C:\PYTHON25 : True

C:\Python25\DLLs : True

C:\Python25\lib : True

C:\Python25\lib\plat-win : False

C:\Python25\lib\lib-tk : True

C:\Python25\lib\site-packages : True

--
nosy: +quentin.gallet-gilles
versions: +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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Guido van Rossum]

Guido van Rossum added the comment:

Hoping to draw Tim into this... He's the only one I know who truly
understands these issues...

--
assignee:  -> tim_one
nosy: +tim_one

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

Which Python version is this for?

--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1067] test_smtplib failures (caused by asyncore)

[Georg Brandl]

Changes by Georg Brandl:


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

[issue1067] test_smtplib failures (caused by asyncore)

[Guido van Rossum]

Guido van Rossum added the comment:

OK, closing.  I see plenty of mention of these two modules in the lists,
so maybe someone else wants to take a whack at it.  I'll post to python-dev.

--
keywords: +py3k
nosy:  -nobody
priority: high -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1336] subprocess.Popen hangs when child writes to stderr

[Guido van Rossum]

Guido van Rossum added the comment:

I'm sorry to ask you to do more work, but could you do me a favor and
send this in the form of a svn diff?  That file has evolved quite a bit
and it's unclear what version you used as a baseline.

--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1557] import distutils.msvccompiler hangs when the environment is too large

[Christian Heimes]

Changes by Christian Heimes:


--
assignee:  -> tiran
nosy: +tiran
priority:  -> urgent

__
Tracker <[EMAIL PROTECTED]>

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

[issue1558] x64 platform doesn't define _WIN64

[Christian Heimes]

New submission from Christian Heimes:

In VS 2008 the x64 platform doesn't define the _WIN64 macro. The _WIN64
macro defines the MS_WIN64 macro which sets several other macros and
changes some variables in pyconfig.h.

Question: Should we enforce MS_WIN64 for the x64 platform although
_WIN64 is not defined?
Question 2: WHY THE H... is the _WIN64 macro not defined? I'm googling now.

--
components: Interpreter Core
keywords: 64bit, py3k
messages: 58224
nosy: loewis, mhammond, tiran
priority: urgent
severity: urgent
status: open
title: x64 platform doesn't define _WIN64
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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Finally I found a potential problem with the garbage collector in a
specific case:
- Some object C participates in a reference cycle, and contains a
reference to another object X.
- X.__del__ 'resurrect' the object, by saving its 'self' somewhere else.
- X contains a reference to Y, which has a __del__ method.
When collecting all this, gc.garbage == [Y] !
This is not true garbage: if you clean gc.garbage, then the next
gc.collect() clears everything.


Now, try to follow my explanation (if I correctly understand the gc
internals):
- When the cycle is garbage collected, X and Y are detected as
'unreachable with finalizers', and put in a specific 'finalizers' list.
- the cycle is broken, C is deallocated. 
- This correctly triggers X.__del__. X is removed from the 'finalizers'
list.
- when X is resurrected, it comes back to the normal gc tracking list.
- At the end, 'finalizers' contains 3 objects: X.__dict__, Y and Y.__dict__.
- Y is then considered as garbage.

I join a script which reproduces the behaviour. Note that 2.4 and 2.5
are affected too.
In py3k, the 'resurrect' seems to be caused by a (caught) exception in
TextIOWrapper.close(): the exception contains a reference to the frame,
which references the self variable.

--
components: +Interpreter Core
nosy: +gvanrossum
Added file: http://bugs.python.org/file8880/gc_bug.py

__
Tracker <[EMAIL PROTECTED]>

__import gc
gc.set_debug(gc.DEBUG_UNCOLLECTABLE|gc.DEBUG_COLLECTABLE|gc.DEBUG_OBJECTS)

class Cycle:
def __init__(self):
self.c = self

class Immortal:
resurrected = []

def __del__(self):
self.resurrected.append(self)

class Finalizer:
def __del__(self):
pass

cycle = Cycle()
cycle.x = Immortal()
cycle.x.y = Finalizer()

print (gc.collect(), gc.garbage)
assert gc.garbage == []
# Nothing special so far

del cycle

print (gc.collect(), gc.garbage)
# 'Finalizer' instance appears in garbage.
# Not real garbage though:
del gc.garbage[0]
gc.collect()
assert gc.garbage == []
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1559] round() does not

[travelgirl]

New submission from travelgirl:

http://docs.python.org/tut/node5.html states, as an example, round(_, 2)
should round to the second decimal place.  makes sense.  when i
attempted it with different numbers, round() returned what looks like a
binary-coded decimal error (see the jpg enclosed), and did not return
just two digits, but 15 digits.  the same error was produced for
round(_, 3).  when the number was changed to 1 digit, the return result
rounded from another direction.

i'd guess this isn't a feature :)

--
components: Windows
files: python bug.jpg
messages: 58225
nosy: travelgirl
severity: normal
status: open
title: round() does not
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8882/python bug.jpg

__
Tracker <[EMAIL PROTECTED]>

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

[issue1559] round() does not

[Georg Brandl]

Georg Brandl added the comment:

Not really a feature, but not a bug. See
http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate
for an explanation.

--
nosy: +georg.brandl
resolution:  -> invalid
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

[issue1556] Failure when calling __str__ for MIMEBase(message, rfc822) objects

[Hendrik Spiegel]

New submission from Hendrik Spiegel:

When creating a MIMEBase object with message/rfc822 mimetype invoking
the objects __str__ method results in an exception. 
Even if this behaviour should be intended the error message "TypeError:
Expected list, got " is not helpful. 
To reproduce the problem run the attached script after creating the file
 'test.eml' in the script's directory.


mimetype = mimetypes.guess_type(filename)[0]
maintype, subtype = mimetype.split('/')
attachment = MIMEBase(maintype, subtype)
attachment.set_payload(file(filename).read( ))
print attachment

#python MimebaseError.py   
   
 [1]
message/rfc822
Traceback (most recent call last):
  File "MimebaseError.py", line 19, in 
main()
  File "MimebaseError.py", line 16, in main
print attachment
  File "email/message.py", line 116, in __str__
  File "email/message.py", line 131, in as_string
  File "email/generator.py", line 84, in flatten
  File "email/generator.py", line 109, in _write
  File "email/generator.py", line 135, in _dispatch
  File "email/generator.py", line 266, in _handle_message
  File "email/message.py", line 185, in get_payload
TypeError: Expected list, got 

--
components: Library (Lib)
files: MimebaseError.py
messages: 58216
nosy: hsp
severity: normal
status: open
title: Failure when calling __str__ for MIMEBase(message, rfc822) objects
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file8879/MimebaseError.py

__
Tracker <[EMAIL PROTECTED]>

__from email.MIMEBase import MIMEBase
from email.MIMEMultipart import MIMEMultipart
import mimetypes

#filename = 'MimebaseError.py'
filename = 'test.eml'

def main():
mimetype = mimetypes.guess_type(filename)[0]
print mimetype
maintype, subtype = mimetype.split('/')
attachment = MIMEBase(maintype, subtype)
attachment.set_payload(file(filename).read( ))
#attachment.get_payload()
#attachment.get_payload(0)
print attachment


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

[issue1559] round() does not

[Georg Brandl]

Georg Brandl added the comment:

round() does not return a string, but a floating point number, the best
approximation to the "real" result that is achievable with the limited
precision of binary floating point.

That result is then formatted to a string for display by the interactive
interpreter using the repr() function, which formats a float with (I
think) 17 decimal digits.

So, the point here is that repr() produces "too many" digits for your
liking ;) You can use str() to cut off at fewer digits, which will
produce the "correct" string in most cases.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1557] import distutils.msvccompiler hangs when the environment is too large

[Christian Heimes]

Christian Heimes added the comment:

Fixed in r59370 (trunk)
I'm going to merge the changes into py3k soon.

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

[issue1559] round() does not

[travelgirl]

travelgirl added the comment:

interesting, and expected as the BCD calculation.  however, the round function 
should be able to handle that correctly, dealing with the number in a string 
fashion as opposed a mathematical one, to display the requested decimal places. 
 slower, to be sure, but hella accurate.

that's what the bug was about.  i understand the issues with BCD.  i don't 
understand how a function to display a number can get the display so wrong, 
even when the BCD number itself "fails" to the 15th place.  round to 2 places, 
you should still display 14.78, not 14.7799x

just my take.  thanks for getting back to me.

00 caren
http://www.parkgallery.org
george davis creek, north fork

__
Tracker <[EMAIL PROTECTED]>

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

[issue1560] PATCH: Attribute lookup caching

[Neil Toronto]

New submission from Neil Toronto:

I've attached a patch to accelerate type and instance lookups using a
specialized cache. It includes a benchmarking script (fastattr_test.py)
that tests both successful and failing lookups on list, dict and tuple,
and a simple, deep hierarchy. Benchmark results are here:

http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIUpTm6QSG2gZg&hl=en_US

Everything tested in fastattr_test.py is faster except list.__init__ and
list().__init__ (and I haven't got a clue why, so some pointers would be
nice). Pybench is faster overall. TryRaiseExcept is faster for some
non-obvious reason. CreateNewInstances is a little slower, which I'll
discuss in a bit. Setting type attributes is slower, but I haven't
benchmarked that yet. It may not happen often enough that we care as
long as it's not noticeably slow in general usage.

In benchmarks the patch does a little slower, it may be in part because
I removed a manually inlined _PyType_Lookup from
PyObject_GenericGetAttr. Something like it can be put back if it needs
to be.

It works in a fairly obvious way. Every type has a tp_cache, which is a
custom dict type that caches the first value in a type dict in the MRO
for a given name. Lazy cached lookups are done via
_PyType_CachingLookup, which is a drop-in replacement for
_PyType_Lookup. The only way to set an attribute on a type is via its
setattr, so type's setattr notifies subclasses to invalidate specific
cache entries.

The cache dict is custom for two reasons:

1. The regular dict is a little slower because it's more general. The
custom dict is restricted to string-exact keys (types fall back to no
caching if this constraint is violated). Because it's internal to
typeobject.c, it's safe for lookups to return entry pointers rather than
values, so lookups only have to be done once, even on cache misses.

2. Caching missing attributes is crucial for speed on instance attribute
lookups. Both type and metatype instances check all the way through the
MRO for a descriptor before even trying to find an attribute. It's
usually missing. Having to go through the cache machinery to find a
missing attribute for every attribute lookup is expensive. However,
storing all missing attribute queries in the cache is bad - it can grow
unboundedly through hasattr(inst, ) calls.

What's needed is a dict that knows that some of its entries are
transient and doesn't copy them over on resize. It wasn't clear how to
implement that efficiently with a regular dict (I suspect it's not
possible), so I created a new dict type that considers entries transient
(meaning the attribute is missing) when me_value == NULL.

This is also very good for failing hasattr(...) calls and
try...inst.method()...except style duck typing.

Now, about the CreateNewInstances benchmark. It creates three classes
with __init__ methods that assign a few attributes. The missing
descriptors are cached, and then the cache is resized, which clears the
cached missing descriptors. Increasing the minimum cache size from 4 to
8 clears up the problem. However, for any class, SOME minimum cache size
will properly cache missing descriptors and some other one won't.

I have some solutions for this floating around in my head, which I'll
try shortly. (One idea is for missing attributes, if they're not missing
on the *instance*, to be permanent in the cache.) But I'd like to get
this patch off my hard drive and into other people's hands for testing,
poking, prodding, and getting feedback on what's going right and what's not.

--
components: Interpreter Core
files: fastattr-0.patch.txt
messages: 58229
nosy: ntoronto
severity: normal
status: open
title: PATCH: Attribute lookup caching
versions: Python 2.6
Added file: http://bugs.python.org/file8883/fastattr-0.patch.txt

__
Tracker <[EMAIL PROTECTED]>

__Index: Include/dictobject.h
===
--- Include/dictobject.h(revision 59362)
+++ Include/dictobject.h(working copy)
@@ -111,6 +111,8 @@
 PyAPI_FUNC(int) PyDict_Contains(PyObject *mp, PyObject *key);
 PyAPI_FUNC(int) _PyDict_Contains(PyObject *mp, PyObject *key, long hash);
 
+PyAPI_FUNC(int) PyDict_IsStringKeysOnly(PyObject *mp);
+
 /* PyDict_Update(mp, other) is equivalent to PyDict_Merge(mp, other, 1). */
 PyAPI_FUNC(int) PyDict_Update(PyObject *mp, PyObject *other);
 
Index: Include/object.h
===
--- Include/object.h(revision 59362)
+++ Include/object.h(working copy)
@@ -391,6 +391,7 @@
 PyAPI_FUNC(PyObject *) PyType_GenericNew(PyTypeObject *,
   PyObject *, PyObject *);
 PyAPI_FUNC(PyObject *) _PyType_Lookup(PyTypeObject *, PyObject *);
+PyAPI_FUNC(PyObject *) _PyType_CachingLookup(PyTypeObject *, PyObject *);
 
 /* Generic operations on objects */
 PyAPI_FUNC(int) 

[issue1326] "internal" zipimport.zipimporter feature untested

[Thomas Herve]

Thomas Herve added the comment:

The patch is against trunk.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1557] import distutils.msvccompiler hangs when the environment is too large

[Thomas Heller]

New submission from Thomas Heller:

'Python -c "import distutils.msvccompiler"' hangs when the environment
is too large.  This is because in Lib\distutils\msvc9compiler.py, line
258, popen.wait() does not return because the subprocess does not
terminate (probably because the stdout buffersize is too small).  This
causes the win64-buildbot to hang.

--
components: Distutils, Windows
keywords: py3k
messages: 58217
nosy: theller
severity: urgent
status: open
title: import distutils.msvccompiler hangs when the environment is too large
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

[issue1560] PATCH: Attribute lookup caching

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1554] [patch] socketmodule cleanups: allow the use of keywords in socket functions

[Thomas Herve]

Thomas Herve added the comment:

Here it is. There were several functions which didn't have any tests at
all, so I had to create some. These tests are likely to fail on some
platforms (like windows), but I didn't get any machine to test.

Added file: http://bugs.python.org/file8878/socket_keywords_2.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Lib/test/test_socket.py
===
--- Lib/test/test_socket.py (revision 59346)
+++ Lib/test/test_socket.py (working copy)
@@ -275,7 +275,66 @@
 fqhn = socket.getfqdn(ip)
 if not fqhn in all_host_names:
 self.fail("Error testing host resolution mechanisms. (fqdn: %s, 
all: %s)" % (fqhn, repr(all_host_names)))
+# Try call by named argument
+ip2 = socket.gethostbyname(host=hostname)
+self.assertEquals(ip, ip2)
+
+result2 = socket.gethostbyaddr(host=ip)
+self.assertEquals((hname, aliases, ipaddrs), result2)
 
+def testGetHostByNameEx(self):
+hostname = socket.gethostname()
+try:
+hostname, aliaslist, iplist = socket.gethostbyname_ex(hostname)
+except socket.error:
+# Probably name lookup wasn't set up right; skip this test
+return
+for ip in iplist:
+self.assert_(ip.find('.') >= 0, "Error resolving host to ip.")
+# Try call by named argument
+result2 = socket.gethostbyname_ex(host=hostname)
+self.assertEquals((hostname, aliaslist, iplist), result2)
+
+def testGetAddrInfo(self):
+# Find one service that exists, then check all the related interfaces.
+# I've ordered this by protocols that have both a tcp and udp
+# protocol, at least for modern Linuxes.
+if sys.platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
+'freebsd7', 'freebsd8', 'darwin'):
+# avoid the 'echo' service on this platform, as there is an
+# assumption breaking non-standard port/protocol entry
+services = ('daytime', 'qotd', 'domain')
+else:
+services = ('echo', 'daytime', 'domain')
+for service in services:
+try:
+port = socket.getservbyname(service, 'tcp')
+break
+except socket.error:
+pass
+else:
+raise socket.error
+
+hostname = socket.gethostname()
+result = socket.getaddrinfo(hostname, service)
+self.assert_(len(result) > 1)
+result = result[0]
+self.assertEquals(result[0], socket.AF_INET)
+ip = result[4][0]
+# It should be a valid ip address
+self.assert_(len(socket.inet_aton(ip)) > 0)
+port2 = result[4][1]
+self.assertEquals(port, port2)
+
+def testGetNameInfo(self):
+hostname = socket.gethostname()
+host, port = socket.getnameinfo((hostname, 1234), 0)
+self.assertEquals(port, '1234')
+
+# Try with named parameters
+result2 = socket.getnameinfo(sockaddr=(hostname, 1234), flags=0)
+self.assertEquals((host, port), result2)
+
 def testRefCountGetNameInfo(self):
 # Testing reference count for getnameinfo
 import sys
@@ -347,6 +406,10 @@
 # Try same call with optional protocol omitted
 port2 = socket.getservbyname(service)
 eq(port, port2)
+# Try same call with named arguments
+port3 = socket.getservbyname(servicename=service, protocolname='tcp')
+eq(port, port3)
+
 # Try udp, but don't barf it it doesn't exist
 try:
 udpport = socket.getservbyname(service, 'udp')
@@ -357,6 +420,8 @@
 # Now make sure the lookup by port returns the same service name
 eq(socket.getservbyport(port2), service)
 eq(socket.getservbyport(port, 'tcp'), service)
+# Try same call with named arguments
+eq(socket.getservbyport(port=port, protocolname='tcp'), service)
 if udpport is not None:
 eq(socket.getservbyport(udpport, 'udp'), service)
 
@@ -567,6 +632,19 @@
 def _testFromFd(self):
 self.serv_conn.send(MSG)
 
+def testFromFdNamedArguments(self):
+# Testing fromfd()
+if not hasattr(socket, "fromfd"):
+return # On Windows, this doesn't exist
+fd = self.cli_conn.fileno()
+sock = socket.fromfd(fd=fd, family=socket.AF_INET,
+ type=socket.SOCK_STREAM)
+msg = sock.recv(1024)
+self.assertEqual(msg, MSG)
+
+def _testFromFdNamedArguments(self):
+self.serv_conn.send(MSG)
+
 def testShutdown(self):
 # Testing shutdown()
 msg = self.cli_conn.recv(1024)
@@ -638,6 +716,14 @@
 msg = self.cli.recv(1024)
 self.assertEqual(msg, MSG)
 
+class So

[issue1553] An errornous __length_hint__ can make list() raise a SystemError

[Christian Heimes]

Christian Heimes added the comment:

I've backported the fix to 2.5 and trunk. They suffered from the same
problem.

--
nosy: +tiran
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

[issue1067] test_smtplib failures (caused by asyncore)

[Thomas Wouters]

Thomas Wouters added the comment:

I thought I already had, in my reply to Martin and the original comment:
he's right, but I don't care about asyncore or asynchat. I merely
perpetuated the fix that was already in place. The real 'fix' is to
teach both modules about unicode; have them handle in bytes, and add a
new API for strings (in which the user has to supply encodings.) But I
don't think asyncore and asynchat are worth keeping, let alone fixing,
so I'm not the right person to look at this.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1545] shutil fails when copying to NTFS in Linux

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

There is a mistake in the patch. The line "if WindowsError is not None
and isinstance(err, WindowsError):" in copytree() should use the name
'why' and not 'err'. Unfortunately I can't test on windows, but you
didn't get NameError when you tested copytree() on windows?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1558] x64 platform doesn't define _WIN64

[Christian Heimes]

Christian Heimes added the comment:

Sorry guys, it was false alarm.

>From r59375:
The macros _WIN32, _WIN64 and _M_X64 are defined by the compiler. The VS
2008 IDE doesn't know about (some) of the macros and can display wrong
information. In my case a section #ifdef _WIN64 was grayed out although
the platform was x64. I've added the macros to pyproject.vsprops and
x64.vsprops to avoid future confusion.

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

[issue1400] Py3k's print() flushing problem

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 59379.

This adds proper line_buffering behavior.

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

[issue1685986] Method cache

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'm working on this one this week.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1539] test_collections: failing refleak test

[Christian Heimes]

Christian Heimes added the comment:

Fixed in r59349
Good work Amaury! :)

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

[issue1559] round() does not

[Guido van Rossum]

Guido van Rossum added the comment:

travelgirl: the 'decimal' module is designed to deal with this. Note
that there's a difference between BCD (which can represent decimal
numbers exactly) and binary (which can't, in general).

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue614555] Rewrite _reduce and _reconstructor in C

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti:


--
nosy: +alexandre.vassalotti


Tracker <[EMAIL PROTECTED]>


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

[issue1471] ioctl doesn't work properly on 64-bit OpenBSD

[Mike Savory]

Changes by Mike Savory:


__
Tracker <[EMAIL PROTECTED]>

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

[issue1471] ioctl doesn't work properly on 64-bit OpenBSD

[Mike Savory]

Mike Savory added the comment:

Similar issue seen in 64 bit OSX 10.5

  File "./ajaxterm.py", line 418, in create
fcntl.ioctl(fd, 
struct.unpack('i',struct.pack('I',termios.TIOCSWINSZ))[0], 
struct.pack("",h,w,0,0))
IOError: [Errno 25] Inappropriate ioctl for device

$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

--
nosy: +msavory

__
Tracker <[EMAIL PROTECTED]>

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