[issue1207589] IDLE: Right Click Context Menu

[Todd Rovito]

Todd Rovito added the comment:

Changed the version to make it clear this issue as a patch for 3.4 and 2.7.

--
versions: +Python 3.4

___
Python tracker 

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

[issue1207589] IDLE: Right Click Context Menu

[Todd Rovito]

Todd Rovito added the comment:

I used taleinat's patch as the start for a patch that works with 2.7.  Lots of 
code was changed from 2010 to 2012 so I basically hand merged the patch into 
2.7.  This patch was tested with Python 2.7.3 on both Mac OS X and Linux.  As 
suggested by taleinat and Guilherme the shortcuts keys are not included in the 
context menu.

--
versions: +Python 2.7 -Python 3.4
Added file: 
http://bugs.python.org/file27616/RightClickContextMenuUpdatedFor2point7.patch

___
Python tracker 

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

[issue14255] tempfile.gettempdir() didn't return the path with correct case.

[James Teh]

James Teh added the comment:

This issue is much nastier than it seems when dealing with character sets that 
contain multi-byte characters in Python 2.7 on Windows. For example, on a 
Japanese system:
1. The ANSI code page is cp932 and Python 2.7 will return the TEMP environment 
variable as a str with this encoding.
2. If a user has a username containing the character \u5c71, this will be 
encoded as \x8eR, so the TEMP environment variable will include this character.
3. When normcase is called, \x8eR is converted to \x8er.
4. Because \x8eR is a multi-byte character, \x8er is an unrelated character; 
case insensitivity for "R" doesn't apply.
5. The result is that the correct temp directory is skipped. In fact, on most 
systems, IOError is raised because none of the other candidate directories are 
valid either.

--
nosy: +jteh

___
Python tracker 

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

[issue1207589] IDLE: Right Click Context Menu

[Todd Rovito]

Todd Rovito added the comment:

This time I ran make patchcheck on the patch and it corrected a single white 
space.

I used taleinat's patch as the start for a patch that works with 3.4.  Lots of 
code was changed from 2010 to 2012 so I basically hand merged the patch into 
3.4.  This patch was tested with Python 3.4.0a0 on both Mac OS X and Linux.  As 
suggested by taleinat and Guilherme the shortcuts keys are not included in the 
context menu.

--
Added file: 
http://bugs.python.org/file27615/RightClickContextMenuUpdatedFor3point4.patch

___
Python tracker 

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

[issue1207589] IDLE: Right Click Context Menu

[Todd Rovito]

Changes by Todd Rovito :


Removed file: 
http://bugs.python.org/file27614/RightClickContextMenuUpdatedFor3point4.patch

___
Python tracker 

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

[issue1207589] IDLE: Right Click Context Menu

[Todd Rovito]

Todd Rovito added the comment:

I used taleinat's patch as the start for a patch that works with 3.4.  Lots of 
code was changed from 2010 to 2012 so I basically hand merged the patch into 
3.4.  This patch was tested with Python 3.4.0a0 on both Mac OS X and Linux.  As 
suggested by taleinat and Guilherme the shortcuts keys are not included in the 
context menu.

--
Added file: 
http://bugs.python.org/file27614/RightClickContextMenuUpdatedFor3point4.patch

___
Python tracker 

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

[issue15392] Create a unittest framework for IDLE

[Ned Deily]

Ned Deily added the comment:

There is now one test available to be applied from Issue16226; see 
http://bugs.python.org/file27613/issue16226_test.patch.  It may need to be 
modified depending on where the tests are ultimately put in the source tree.

--
nosy: +ned.deily

___
Python tracker 

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

[issue16226] IDLE crashes on *File / Path browser*

[Ned Deily]

Ned Deily added the comment:

I've committed Roger's fix for release in 3.3.1 and 3.4.0.  Thanks, Roger.  I 
did not apply the proposed test since, as it stands, it would never be run by 
test.regrtest without establishing a idlelib test runner infrastructure as 
proposed by Issue15392.  I'm attaching the test as a separate patch and will 
add a comment to 15392 that the test should be added.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
Added file: http://bugs.python.org/file27613/issue16226_test.patch

___
Python tracker 

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

[issue16226] IDLE crashes on *File / Path browser*

[Roundup Robot]

Roundup Robot added the comment:

New changeset d369e50677a6 by Ned Deily in branch '3.3':
Issue #16226: Fix IDLE Path Browser crash.
http://hg.python.org/cpython/rev/d369e50677a6

New changeset 58f9523cf407 by Ned Deily in branch 'default':
Issue #16226: Fix IDLE Path Browser crash.
http://hg.python.org/cpython/rev/58f9523cf407

--
nosy: +python-dev

___
Python tracker 

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

[issue16281] TODO in tailmatch(): it does not support backward in all cases

[STINNER Victor]

New submission from STINNER Victor:

Oh oh, it looks like the implementation of tailmatch() was not finished:

/* If both are of the same kind, memcmp is sufficient */
if (kind_self == kind_sub) {
return ...;
}
/* otherwise we have to compare each character by first accesing it */
else {
/* We do not need to compare 0 and len(substring)-1 because
   the if statement above ensured already that they are equal
   when we end up here. */
/* TODO: honor direction and do a forward or backwards search */
for (i = 1; i < end_sub; ++i) {
if (PyUnicode_READ(kind_self, data_self, offset + i) !=
PyUnicode_READ(kind_sub, data_sub, i))
return 0;
}
return 1;
}

--
messages: 173301
nosy: haypo, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TODO in tailmatch(): it does not support backward in all cases
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue13884] IDLE: Remove tear-off menu feature

[Ned Deily]

Ned Deily added the comment:

Keep in mind that tear-off menus are not supported on IDLE on OS X when using 
Aqua Tk (either Carbon or Cocoa), the standard these days.  That's primarily 
because Aqua Tk uses native OS X menu bars which appear once at the top of the 
desktop, not in each window.  There are no dotted line menu bars there.  The 
desktop menu bar menu items change to reflect which window currently has 
keyboard focus.

--
nosy: +ned.deily

___
Python tracker 

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

[issue16262] srcdir != builddir builds fail, if hg is not installed

[Roumen Petrov]

Roumen Petrov added the comment:

issue 15819 is still open 

--
nosy: +rpetrov

___
Python tracker 

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

[issue16280] Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()

[Mark Dickinson]

Mark Dickinson added the comment:

Dropped the special case for 3.4.  I'm leaving the code as-is for the 
maintenance branches, as discussed in issue16277.

--
assignee:  -> mark.dickinson
resolution:  -> fixed
status: open -> closed
type: resource usage -> behavior

___
Python tracker 

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

[issue16280] Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5ae4ff03b35f by Mark Dickinson in branch 'default':
Issue 16280: Drop questionable special-casing of null pointer in 
PyLong_FromVoidPtr.
http://hg.python.org/cpython/rev/5ae4ff03b35f

--
nosy: +python-dev

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I close this issue as the main bug was fixed.

For incidental bug I open issue16280.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue16280] Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

This issue is taken out of the discussion of issue16277.

PyLong_FromVoidPtr() has special case which maps null pointer to zero integer.

On platforms where (uintptr_t)(void *)0 is 0, this code has no effect and is 
redundant.  But on hypothetic platforms where (uintptr_t)(void *)0 is not 0, 
PyLong_FromVoidPtr() maps NULL to 0 and then PyLong_AsVoidPtr() maps 0 to 
non-NULL. Also PyLong_FromVoidPtr() is multivalued, it maps to 0 NULL and may 
be some other pointer.

PyLong_FromVoidPtr() in 2.7 has special case only on platform where 
sizeof(void*) > sizeof(long). It commented as "optimize null pointers". In 3.x 
branch such optimization non needed because PyLong_FromUnsignedLongLong() 
already has special case for short integers.

The solution of this issue is getting rid of a special case, or adding a 
special case in PyLong_FromVoidPtr(). It is desirable to make it avoiding 
multivaluedity.

--
components: Interpreter Core
messages: 173295
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

Let's keep it simple and just drop the special case for 3.4.

--

___
Python tracker 

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

[issue13884] IDLE: Remove tear-off menu feature

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, please, make it a configuration feature (off by default). Tear-off menus 
useful for large and deeply nested menus. Do not forget about people with 
disabilities.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue16279] namedtuple should compare equality with field names taken into account

[Julian Berman]

New submission from Julian Berman:

I find the following to be unintuitive:

Python 3.3.0rc1 (default, Sep  6 2012, 16:02:32) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import namedtuple
>>> F = namedtuple("F", "x")
>>> G = namedtuple("G", "y")
>>> F(12) == G(12)
True

I'm OK with not taking the class name into account, that sounds reasonable, but 
I think field names should make those unequal.

--
components: Library (Lib)
messages: 173292
nosy: Julian, rhettinger
priority: normal
severity: normal
status: open
title: namedtuple should compare equality with field names taken into account
type: enhancement
versions: Python 3.4, Python 3.5

___
Python tracker 

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

[issue13884] IDLE: Remove tear-off menu feature

[Todd Rovito]

Todd Rovito added the comment:

Terry,
   I would not miss the feature at all this is very old school Unix like and 
most people find it confusing.  At my job I tend to provide Python support to 
my co-workers and have had many questions about it. In addition I think #13504 
meta issue provides even more evidence that removing the tear off menus would 
be a good thing.  Something to consider with IDLE is it is often the first 
thing a user sees when using Python and first impressions count in most 
circumstances. IDLE could be much improved and Roger Serwy has a good start on 
improvements with his IdleX project.  Thanks for the review and I for one would 
appreciate this patch getting committed.

--

___
Python tracker 

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

[issue15958] bytes.join() should allow arbitrary buffer objects

[Roundup Robot]

Roundup Robot added the comment:

New changeset 388e43bb519d by Antoine Pitrou in branch 'default':
Followup to issue #15958: add join.h to Makefile dependencies for byte strings
http://hg.python.org/cpython/rev/388e43bb519d

--

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> So maybe the fix should be to special case zero in PyLong_AsVoidPtr, and
> turn 0L back into NULL there?

Yes, of course. If we have a special case in PyLong_FromVoidPtr(), it is wrong 
that we do not have the special case in PyLong_AsVoidPtr(). But this will 
change the current (potentially buggy) behaviour. ;-)

The patch long_fromvoidptr_2.patch contains such changes (as you want).

But this changes are buggy too, because now PyLong_FromVoidPtr() and 
PyLong_AsVoidPtr() are multivalued. PyLong_FromVoidPtr() maps to 0 NULL and 
may be yet another pointer, PyLong_AsVoidPtr() maps to NULL 0 and may be yet 
another integer.

The patch long_fromvoidptr_3.patch is more consistent in this sense. Now both 
functions are univalued, 

> I think it's just too risky to change the current behaviour in 3.2 and 3.3,
> given the number of places that PyLong_FromVoidPtr is used.  

Buggy behaviour changed if we fix the bug.

> Unlike you, I
> don't have confidence that there are no current or future platforms that
> don't map NULL to 0.

I just want to say that I'm not sure whether to fix this bug. But if we fix it 
for purity, it should be fixed right.

--
Added file: http://bugs.python.org/file27611/long_fromvoidptr_2.patch
Added file: http://bugs.python.org/file27612/long_fromvoidptr_3.patch

___
Python tracker 

___diff -r a45cb181e4d0 Objects/longobject.c
--- a/Objects/longobject.c  Wed Oct 17 20:29:07 2012 -0700
+++ b/Objects/longobject.c  Thu Oct 18 22:18:07 2012 +0300
@@ -935,17 +935,20 @@
 PyObject *
 PyLong_FromVoidPtr(void *p)
 {
+/* special-case null pointer */
+if (!p)
+return PyLong_FromLong(0);
+#if SIZEOF_VOID_P <= SIZEOF_LONG
+return PyLong_FromUnsignedLong((unsigned long)(Py_uintptr_t)p);
+#else
 #ifndef HAVE_LONG_LONG
 #   error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long"
 #endif
 #if SIZEOF_LONG_LONG < SIZEOF_VOID_P
 #   error "PyLong_FromVoidPtr: sizeof(PY_LONG_LONG) < sizeof(void*)"
 #endif
-/* special-case null pointer */
-if (!p)
-return PyLong_FromLong(0);
 return PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)(Py_uintptr_t)p);
-
+#endif /* SIZEOF_VOID_P <= SIZEOF_LONG */
 }
 
 /* Get a C pointer from a long int object. */
@@ -977,6 +980,9 @@
 
 #endif /* SIZEOF_VOID_P <= SIZEOF_LONG */
 
+/* special-case null pointer */
+if (!x)
+return NULL;
 if (x == -1 && PyErr_Occurred())
 return NULL;
 return (void *)x;
diff -r a45cb181e4d0 Objects/longobject.c
--- a/Objects/longobject.c  Wed Oct 17 20:29:07 2012 -0700
+++ b/Objects/longobject.c  Thu Oct 18 22:03:11 2012 +0300
@@ -935,17 +935,19 @@
 PyObject *
 PyLong_FromVoidPtr(void *p)
 {
+/* always convert NULL to 0 */
+Py_uintptr_t x = (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL;
+#if SIZEOF_VOID_P <= SIZEOF_LONG
+return PyLong_FromUnsignedLong((unsigned long)x);
+#else
 #ifndef HAVE_LONG_LONG
 #   error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long"
 #endif
 #if SIZEOF_LONG_LONG < SIZEOF_VOID_P
 #   error "PyLong_FromVoidPtr: sizeof(PY_LONG_LONG) < sizeof(void*)"
 #endif
-/* special-case null pointer */
-if (!p)
-return PyLong_FromLong(0);
-return PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)(Py_uintptr_t)p);
-
+return PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)x);
+#endif /* SIZEOF_VOID_P <= SIZEOF_LONG */
 }
 
 /* Get a C pointer from a long int object. */
@@ -979,7 +981,8 @@
 
 if (x == -1 && PyErr_Occurred())
 return NULL;
-return (void *)x;
+/* always convert 0 to NULL */
+return (void *)((Py_uintptr_t)x + (Py_uintptr_t)(void *)NULL);
 }
 
 #ifdef HAVE_LONG_LONG
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

I've fixed the missing branch in 3.2, 3.3 and 3.4.

--
assignee:  -> mark.dickinson
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Jeremy Banks]

Changes by Jeremy Banks :


--
nosy: +Jeremy Banks

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Roundup Robot]

Roundup Robot added the comment:

New changeset bedb2903d71e by Mark Dickinson in branch '3.2':
Issue #16277: in PyLong_FromVoidPtr, add missing branch for sizeof(void*) <= 
sizeof(long).
http://hg.python.org/cpython/rev/bedb2903d71e

New changeset 8ce04be1321c by Mark Dickinson in branch '3.3':
Issue #16277: merge fix from 3.2
http://hg.python.org/cpython/rev/8ce04be1321c

New changeset 02e57069f43e by Mark Dickinson in branch 'default':
Issue #16277: merge fix from 3.3
http://hg.python.org/cpython/rev/02e57069f43e

--
nosy: +python-dev

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

> Undefined behavior (or may be just the wrong behavior), we obtain later, > 
> when 
> converting in PyLong_AsVoidPtr() zero integer back to pointer. On
> platforms 
> where converting NULL to an integer doesn't give zero it's a bug.

So maybe the fix should be to special case zero in PyLong_AsVoidPtr, and turn 
0L back into NULL there?

I think it's just too risky to change the current behaviour in 3.2 and 3.3, 
given the number of places that PyLong_FromVoidPtr is used.  Unlike you, I 
don't have confidence that there are no current or future platforms that don't 
map NULL to 0.  It might be reasonable to consider a change for 3.4.

> I mean using PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)
> ((Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL)) instead ...

Okay, thanks for explaining.

--

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
versions: +Python 3.2, Python 3.3 -Python 3.5

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[David Benjamin]

New submission from David Benjamin:

This is somewhat of a nitpick. os.rename's documentation says "If dst is a 
directory, OSError will be raised". On Unix, this isn't completely true. If the 
source is a directory and the destination is an empty directory, it'll 
overwrite the former with the latter. (Actually if the source is a directory 
the inverse is true; if dst is a file, OSError will be raised.)

In [1]: import os

In [2]: os.mkdir("aaa")

In [3]: open("aaa/blah", "w").close()

In [4]: os.mkdir("bbb")

In [5]: os.rename("aaa", "bbb")

In [6]: os.listdir("bbb")
Out[6]: ['blah']

--
assignee: docs@python
components: Documentation
messages: 173285
nosy: David.Benjamin, docs@python
priority: normal
severity: normal
status: open
title: os.rename documentation slightly inaccurate
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

[issue13884] IDLE: Remove tear-off menu feature

[Terry J. Reedy]

Terry J. Reedy added the comment:

I wonder if anyone uses this feature and would miss it if gone. Since it is a 
simple matter of passing 'tearoff=0/1' on menu creation, perhaps it should be a 
configuration feature.

--

___
Python tracker 

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

[issue13884] IDLE: Remove tear-off menu feature

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> patch review
title: IDLE 2.6.5 Recent Files undocks -> IDLE: Remove tear-off menu feature
type:  -> enhancement
versions: +Python 3.4 -Python 2.6

___
Python tracker 

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

[issue12686] argparse - document (and improve?) use of SUPPRESS with help=

[Steven Bethard]

Steven Bethard added the comment:

Yeah, looks like we can close this. If anyone finds a specific bug in the use 
of SUPPRESS, please open a new issue.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> document argparse's help=SUPPRESS

___
Python tracker 

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

[issue16267] order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)

[Darren Dale]

Darren Dale added the comment:

There is a very practical reason, which was the whole point of issue11610. 
Descriptors are should declare themselves abstract when they are composed of 
abstract methods. If you have a property with an concrete getter but an 
abstract setter, the property should declare itself abstract until such time as 
it is provided a concrete setter. If we allow __isabstractmethod__ to be 
settable by @abstractmethod, it undermines the whole scheme of descriptors 
delegating their abstractedness to the methods of which they are composed.

--

___
Python tracker 

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

[issue13504] Meta-issue for "Invent with Python" IDLE feedback

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue13884] IDLE 2.6.5 Recent Files undocks

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue11175] allow argparse FileType to accept encoding and errors arguments

[Petri Lehtinen]

Changes by Petri Lehtinen :


--
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue12686] argparse - document (and improve?) use of SUPPRESS with help=

[Petri Lehtinen]

Petri Lehtinen added the comment:

Can this be closed?

--
nosy: +petri.lehtinen

___
Python tracker 

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

[issue16267] order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)

[Eric Snow]

Eric Snow added the comment:

The catch is that when abstractmethod is the inner decorator, 
__isabstractmethod__ is set on the object that classmethod/staticmethod is 
wrapping.  When abstractmethod is the outer decorator, __isabstractmethod__ is 
set on the resulting classmethod/staticmethod object instead.  Unless there is 
some practical reason that the distinction matters, I'm +1 on letting 
__isabstractmethod__ be set on classmethods and staticmethods.

--

___
Python tracker 

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

[issue1516] make _ctypes work with non-gcc compilers

[Greg Couch]

Greg Couch added the comment:

On Thu, 18 Oct 2012, Trent Nelson wrote:

> Trent Nelson added the comment:
>
> Hi Greg,
>
>I realize it's been a good five years since you first raised this
>issue, but I was wondering if you ever ended up making any progress
>with it?
>
>In trying to get Python working on Snakebite UNIX boxes with vendor
>CCs, I'm running into all sorts of issues.
>
> --
>
> ___
> Python tracker 
> 
> ___

Hi Trent,

Sorry to say I don't have any more insight on how to get libffi working on 
more platforms.  Lucking ctypes isn't used in the Python core, so it's 
not required to get Python working.  I'm using supported compilers on all 
platforms now.

 Good luck,

 Greg

--

___
Python tracker 

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

[issue1207589] IDLE: Right Click Context Menu

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
title: Right Click Context Menu -> IDLE: Right Click Context Menu

___
Python tracker 

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

[issue10405] IDLE breakpoint facility undocumented

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue16248] Security bug in tkinter allows for untrusted, arbitrary code execution.

[Guilherme Polo]

Guilherme Polo added the comment:

For something that has been around for so long, I would be a little more 
careful.

My suggestion is: no longer declare readprofile as an internal function; remove 
the direct call to readprofile from Tk.__init__; tell users about the new 
behavior, and the need to call readprofile themselves if they wish to.

In some years we might be able to estimate if readprofile is used at all, and 
then decide about removing it. Since I haven't been active as a Python 
committer, I will let the final decision to someone else.

--

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Okay, but do you agree that (1) there's no undefined behaviour, and (2)
> removing this code has the potential to change results on platforms where
> converting NULL to an integer doesn't give zero?

Undefined behavior (or may be just the wrong behavior), we obtain later, when 
converting in PyLong_AsVoidPtr() zero integer back to pointer. On platforms 
where converting NULL to an integer doesn't give zero it's a bug.

> > I believe Python does not support platforms where it matters.
> What's your justification for this belief?

Can you show the contrexample? I can not. If such a platform existed, perhaps 
this bug has been already shown it.

> Sorry, but this is making no sense to me.  You wrote: "(Py_uintptr_t)p -
> (Py_uintptr_t)(void *)NULL".  Is that supposed to be existing code that
> you're proposing changing?  An example to prove some point (what point?) 
> Code you're proposing to add somewhere?  (If so, where are you proposing
> to add it?)  Why are you subtracting these two pointers?  What's p?  I'm
> finding it hard to make sense of what you're writing.

I mean using PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)
((Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL)) instead 
PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)(Py_uintptr_t)p). Of course 
PyLong_AsVoidPtr() should be changed to return (void *)(x + (Py_uintptr_t)
(void *)NULL) instead (void *)x.

--

___
Python tracker 

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

[issue1207589] Right Click Context Menu

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue1516] make _ctypes work with non-gcc compilers

[Trent Nelson]

Trent Nelson added the comment:

Hi Greg,

I realize it's been a good five years since you first raised this
issue, but I was wondering if you ever ended up making any progress
with it?

In trying to get Python working on Snakebite UNIX boxes with vendor
CCs, I'm running into all sorts of issues.

--

___
Python tracker 

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

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

On Thu, Oct 18, 2012 at 07:47:40AM -0700, Stefan Krah wrote:
> 
> Stefan Krah added the comment:
> 
> --with-system-ffi should probably solve some problems, see #12927.

This isn't an option on Solaris 10, as it doesn't ship with a
"system ffi", unfortunately.  (That being said, after building
the latest libffi with Sun C, I do use --with-system-ffi in
order to override the building of Modules/_ctypes/libffi.)
>
> The summary of that issue is that the unpatched libffi is not
> compatible with suncc and any issues should be reported upstream
> (at least that was Meador's and my own opinion).

Sun CC is supported by libffi for SPARC only.  You're right
regarding x86/x64 though; libffi explicitly doesn't support
using anything other than gcc on Solaris if it's x86.

(Unfortunately, my only SPARC boxes are running Solaris 9
 and 10.  I don't have new-enough SPARC CPUs that can run
 Solaris 11.  If I did, this would probably be moot, as I
 could just use the system libffi Sun provide.)

Side note: on my Solaris 11 x64 box, --with-system-ffi works
(once -I and -L are tweaked), but test_ctypes still fails if
you're building with Sun CC.

--
title: test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C 
compiler) -> test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10)(Sun C 
compiler)

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

> "0" lexeme is not 0 integer.

Ah yes, true.  C99 6.3.2.3 specifies an "integer *constant* expression".  So I 
was mistaken in thinking that converting an arbitrary integer-valued expression 
with value 0 to (void*) must always give a NULL pointer.

> I think it was wrong implementation, even if only in theoretical 
> considerations.

Okay, but do you agree that (1) there's no undefined behaviour, and (2) 
removing this code has the potential to change results on platforms where 
converting NULL to an integer doesn't give zero?

If you agree with those two things, then this is a behaviour change, not a 
bugfix, and you should open a new issue aimed at 3.4 for that.

> I believe Python does not support platforms where it matters.

What's your justification for this belief?

> This provides the invariant PyLong_FromVoidPtr(NULL) == PyLong_FromLong(0) 
> and 
does not cost anything on platforms where (Py_uintptr_t)(void *)NULL == 0.

Sorry, but this is making no sense to me.  You wrote: "(Py_uintptr_t)p - 
(Py_uintptr_t)(void *)NULL".  Is that supposed to be existing code that you're 
proposing changing?  An example to prove some point (what point?)  Code you're 
proposing to add somewhere?  (If so, where are you proposing to add it?)  Why 
are you subtracting these two pointers?  What's p?  I'm finding it hard to make 
sense of what you're writing.

--

___
Python tracker 

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

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

After an hour of fiddling with pre-requisites, I was able to run the libffi 
testsuite (for the Sun C build).  The results weren't ideal:

=== libffi Summary ===

# of expected passes1528
# of unexpected failures118
# of unsupported tests  55

And for the gcc 4.6 build:

=== libffi Summary ===

# of expected passes1659
# of unsupported tests  55

I'm giving up.  (For now.)

Hopefully I'll be able to rope the libffi folk onto Snakebite in the future.

--

___
Python tracker 

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

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Stefan Krah]

Stefan Krah added the comment:

--with-system-ffi should probably solve some problems, see #12927.

The summary of that issue is that the unpatched libffi is not
compatible with suncc and any issues should be reported upstream
(at least that was Meador's and my own opinion).

--
nosy: +skrah

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> This doesn't seem very likely, since then the C implementation wouldn't
> roundtrip when converting that other pointer to an integer and back to a
> pointer.  (C99 6.3.2.3 says that (void *)0 is a null pointer constant.)

"0" lexeme is not 0 integer. In expression "(void*)0" "0" means null pointer. 
You can't do printf("%p", 0), because in this case compiler does not know what 
0 you have in mind.

> The code you removed is not undefined behaviour, and is not just an
> optimization---removing it would change the semantics of
> PyLong_FromVoidPtr.  There may be code that depends on
> PyLong_FromVoidPtr(NULL) being 0.  I believe the code should stay.

I think it was wrong implementation, even if only in theoretical 
considerations. I believe Python does not support platforms where it matters. 
The removed code creates the impression that the problem is solved, but in 
fact it is not. Yes, we can leave it, but it doesn't make sense.

> > What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL?
> What about it?  What's the relevance to this issue?

This provides the invariant PyLong_FromVoidPtr(NULL) == PyLong_FromLong(0) and 
does not cost anything on platforms where (Py_uintptr_t)(void *)NULL == 0.

--

___
Python tracker 

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

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

With the latest build (from git) of libffi, tests still fail, but differently.

(These errors seem slightly less perverse than the ones pasted previously.)

==
FAIL: test_wchar_parm 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py", line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py", line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py", line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_bitfields.py", line 40, in 
test_ints
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 0)

First differing element 2:
-1
0

- ('A', 1, -1)
?  ^^

+ ('A', 1, 0)
?  ^


==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_bitfields.py", line 47, in 
test_shorts
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 0)

First differing element 2:
-1
0

- ('M', 1, -1)
?  ^^

+ ('M', 1, 0)
?  ^


==
FAIL: test_byte (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 36, in 
test_byte
self.check_type(c_byte, 42)
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 22, in 
check_type
self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

==
FAIL: test_char (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 91, in 
test_char
self.check_type(c_char, "x")
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 22, in 
check_type
self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: ('\x00',) != ('x',)

First differing element 0:

x

- ('\x00',)
?   - --

+ ('x',)

==
FAIL: test_double (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 83, in 
test_double
self.check_type(c_double, 3.14)
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 30, in 
check_type
self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 3.14) != (-3, 3.14)

First differing element 0:
0
-3

- (0, 3.14)
?  ^

+ (-3, 3.14)
?  ^^


==
FAIL: test_int (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 50, in 
test_int
self.check_type(c_int, 42)
  File "/home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py", line 30, in 
check_type
self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42) != (-3, 42)

First differing element 0:
0
-3

- (0, 42)
?  ^

+ (-3, 42)
?  ^^


=

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

> If on some platform (uintptr_t)NULL != 0, then some other address can be 
> reflected to 0.

This doesn't seem very likely, since then the C implementation wouldn't 
roundtrip when converting that other pointer to an integer and back to a 
pointer.  (C99 6.3.2.3 says that (void *)0 is a null pointer constant.)

The code you removed is not undefined behaviour, and is not just an 
optimization---removing it would change the semantics of PyLong_FromVoidPtr.  
There may be code that depends on PyLong_FromVoidPtr(NULL) being 0.  I believe 
the code should stay.

> What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL?

What about it?  What's the relevance to this issue?

--

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> For the second part, I don't see any undefined behaviour here.  Can you
> explain where the undefined behaviour comes from?  And are you sure that
> this is really just an optimization?  It looks as though it might be
> deliberately there to make sure that the conversion still produces a
> Python 0 even on systems where the NULL pointer *doesn't* give 0 when
> converted to an integer.

If on some platform (uintptr_t)NULL != 0, then some other address can be 
reflected to 0. In shuch case PyLong_FromVoidPtr() returns zero integer for 
both NULL and this non-NULL addresses. Of course this is a hypothetic 
situation.

What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL? Then we should change 
PyLong_AsVoidPtr() too.

--

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

Actually, I think that special case needs to be added to the first branch as 
well.

--

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Mark Dickinson]

Mark Dickinson added the comment:

First part of the patch looks fine to me.

For the second part, I don't see any undefined behaviour here.  Can you explain 
where the undefined behaviour comes from?  And are you sure that this is really 
just an optimization?  It looks as though it might be deliberately there to 
make sure that the conversion still produces a Python 0 even on systems where 
the NULL pointer *doesn't* give 0 when converted to an integer.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue16112] platform.architecture does not correctly escape argument to /usr/bin/file

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
>> The main reason for keeping the compatibility is that the module is
>> also being used outside the stdlib for Python versions starting from
>> 2.4 and later. I don't want to maintain two separate versions.
> 
> Which projects use their own copy of platform.py? Where does this file come 
> from?

It's originally from the mxCGIPython project I ran a few years ago
and which now lives on in form of the eGenix PyRun project. Since
the main purpose of platform.py is to identify the underlying Python
runtime and OS platform across multiple Python runtimes and OS platforms,
it's meant to always be used in latest version, even against older Python
versions.

> Using subprocess sounds safer than adding a (theorical) TOCTTOU issue:
> http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
> 
> If you are concerned about compatibility with Python 2.4, you should maintain 
> platform outside the stdlib. The stdlib is regulary updated to the most 
> recent syntax/modules. For example, "yield from" is now used in the stdlib of 
> Python 3.4.

The Python 2.4 compatibility requirement only applies to Python 2.x,
not Python 3.x.

Since Python 2.4 does ship with subprocess, I guess we could use
subprocess even in Python 2.7, but I'm not sure whether it's a good
idea to change the code in such a major way for a patch level release.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 18 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2012-09-27: Released eGenix PyRun 1.1.0 ...   http://egenix.com/go35
2012-09-26: Released mxODBC.Connect 2.0.1 ... http://egenix.com/go34
2012-09-25: Released mxODBC 3.2.1 ... http://egenix.com/go33
2012-10-23: Python Meeting Duesseldorf ...  5 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--

___
Python tracker 

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

[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

If an issue is a duplicate of another one it gets closed as a duplicate, and 
that's it basically.
This issue is still open and this is where the matter should be discussed.

--
nosy: +sbt

___
Python tracker 

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

[issue1516] make _ctypes work with non-gcc compilers

[Trent Nelson]

Changes by Trent Nelson :


--
nosy: +trent

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson added the comment:

And -1j.real is -(1j.real), of course, not (-1j).real.  My bad.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Indeed, -1j is not a literal:

>>> dis.dis(lambda :-1j.real)
  1   0 LOAD_CONST   0 (1j)
  3 LOAD_ATTR0 (real)
  6 UNARY_NEGATIVE  
  7 RETURN_VALUE

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson added the comment:

With the string, the minus sign applies only to the imaginary part;  with the 
expression '-1j', it applies to the whole complex number (both real and 
imaginary parts).

I don't see any sensible way to 'fix' the string to complex conversion; indeed, 
I think any change would make it worse than before.  It's a known issue with 
complex arithmetic that x + 1j*y doesn't give you complex(x, y);  the 
conversions from string and the complex(x, y) form are there to make it 
possible to carefully create a complex number with known real and imaginary 
parts.


> For example, in pypy we use the same code for parsing literals and
> converting strings, so you get -0.0 in both cases.

But -1j isn't a literal.  It's unary minus applied to a the complex number 
given by the literal '1j'.  Python's code *does* give the same results both for 
converting strings and parsing literals.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Antonio Cuni]

Antonio Cuni added the comment:

I would say that the complex-from-string constructor should be fixed to handle 
this special case "correctly".
I find very confusing that we get a different result whether we use a string 
literal or not.

For example, in pypy we use the same code for parsing literals and converting 
strings, so you get -0.0 in both cases.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson added the comment:

No, that's expected behaviour.

1j is complex(0.0, 1.0)
-1j is complex(-0.0, -1.0)

so -1j.real is -0.0.  There's not really any other sensible way to handle this.

The complex-from-string constructor, on the other hand, is more careful about 
interpreting signs.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Antonio Cuni]

Antonio Cuni added the comment:

there is still an inconsistency in handling negative imaginary literals:

>>> -1j.real
-0.0
>>> complex('-1j').real
0.0

--
nosy: +antocuni

___
Python tracker 

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

[issue16277] Objects/longobject.c not compiled without long long

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Preprocessor directives emit error in PyLong_FromVoidPtr:

PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long

if HAVE_LONG_LONG not defined.

Here is a patch which adds missing branch (lost somewhere in 2->3 translation). 
 Also removed non-needed optimization which can cause undefined behavior (C 
Standard not guarantee (long long)NULL == 0).

--
components: Interpreter Core
files: long_fromvoidptr.patch
keywords: patch
messages: 173257
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Objects/longobject.c not compiled without long long
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27610/long_fromvoidptr.patch

___
Python tracker 

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

[issue16235] Add python-config.sh for use during cross compilation.

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +doko
stage:  -> patch review

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

That backport wasn't appropriate -- it included new public members to asyncore 
that were introduced in 3.2.

I'll work on a less intrusive patch.

--

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2f0770cc6d3f by Trent Nelson in branch '2.7':
Issue #16274: revert r79813:90a46f8943d0 changes to asyncore/test_asyncore.
http://hg.python.org/cpython/rev/2f0770cc6d3f

--

___
Python tracker 

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

[issue15958] bytes.join() should allow arbitrary buffer objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yet one issue. You forgot to add join.h to BYTESTR_DEPS in Makefile.pre.in.

--

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Patch applied and everything passes, so closing for now.

--
status: open -> closed

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 90a46f8943d0 by Trent Nelson in branch '2.7':
Issue #16274: backport of 3.2's asyncore/test_asyncore to 2.7.
http://hg.python.org/cpython/rev/90a46f8943d0

--
nosy: +python-dev

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Ok, attached patch is a semantic backport matching 2.7 to 3.2.  All tests pass 
with this patch.

(I can't comment on whether or not the changes in 3.2 actually fix an 
underlying issue, or just hide it better.)

--
keywords: +patch
Added file: http://bugs.python.org/file27609/issue16274_asyncore.patch

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Yeah I've just backported the semantic changes between asyncore and 
test_asyncore from 3.2 -> 2.7.

I'll report back shortly with results.

--

___
Python tracker 

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

I notice there are some differences in sock_accept() (Modules/socketmodule.c) 
between 2.7 and 3.2.
Maybe a bugfix which wasn't backported to 2.7.

--

___
Python tracker 

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

[issue16276] OrderedDict constructor do not keep items order

[Ezio Melotti]

Ezio Melotti added the comment:

This is documented at 
http://docs.python.org/dev/library/collections#collections.OrderedDict:

"""The OrderedDict constructor and update() method both accept keyword 
arguments, but their order is lost because Python’s function call semantics 
pass-in keyword arguments using a regular unordered dictionary."""

--
nosy: +ezio.melotti
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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

3.2 appears fine.  This behavior only seems to happen on 2.7.

The affected tests are:

test_quick_connect (test.test_asyncore.TestAPI_UseSelect) 
test_quick_connect (test.test_asyncore.TestAPI_UsePoll) 

Doing some more digging.

--

___
Python tracker 

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

[issue16276] OrderedDict constructor do not keep items order

[Antoine Dechaume]

New submission from Antoine Dechaume:

Example:

from collections import OrderedDict
print OrderedDict(a=0,b=1,c=2)

I get
OrderedDict([('a', 0), ('c', 2), ('b', 1)])

I expected
OrderedDict([('a', 0), ('b', 1), ('c', 2)])

--
components: Library (Lib)
messages: 173247
nosy: ADechaume
priority: normal
severity: normal
status: open
title: OrderedDict constructor do not keep items order
type: behavior
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

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

New submission from Trent Nelson:

This should be a fun one to track down.

Relevant buildbot run: 
http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

When recompiled with gcc 4.6.3 (/opt/csw/bin/gcc), test_ctypes passes without 
issue (on 2.7 and 3.2).

Going to try a local build of libffi from git with Sun C and --with-system-ffi 
to see if that helps.

==
FAIL: test_struct_return_2H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 189, in test_struct_return_8H
(9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8412232, 9364168, 1, -4223016... != (18, 24, 
28, 30, 30, 28, 24, 1...

First differing element 0:
8412232
18

- (8412232, 9364168, 1, -4223016, -8, -32, -4222983, 5425288)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_wchar_parm 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 28, in test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_struct_return_2H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 189, in test_struct_return_8H
(9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8431512, 9370440, 1, -4223016... != (18, 24, 
28, 30, 30, 28, 24, 1...

First differing element 0:
8431512
18

- (8431512, 9370440, 1, -4223016, -8, -32, -4222983, 5425848)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 28, in test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_struct_return_2H (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File 
"/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py",
 line 189, in te

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

That is weird. accept() should never return None.
What about python 3.x?

--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue16262] srcdir != builddir builds fail, if hg is not installed

[Ezio Melotti]

Ezio Melotti added the comment:

I think you mean b23ad0a6cf87 (see #12273).

--
nosy: +ezio.melotti
type:  -> behavior

___
Python tracker 

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

[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"

[William Edwards]

William Edwards added the comment:

That was my fear; I raise an issue hurting my 2.x servers in
production, and its closed as duplicate instead of not-going-to-fix?

--

___
Python tracker 

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

[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

Not necessarily. It just means the other one was a duplicate.

--

___
Python tracker 

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

[issue16203] Proposal: add re.fullmatch() method

[Ezio Melotti]

Changes by Ezio Melotti :


--
components: +Regular Expressions
nosy: +ezio.melotti

___
Python tracker 

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

[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"

[William Edwards]

William Edwards added the comment:

Apologies, I meant:

issue 16269 has just been closed as a dup of this one.  Does this mean that 
this one will be fixed in Python 2.x too?

--

___
Python tracker 

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

[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"

[William Edwards]

William Edwards added the comment:

issue 16259 has just been closed as a dup of this one.  Does this mean that 
this one will be fixed in Python 2.x too?

--
nosy: +William.Edwards

___
Python tracker 

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

[issue13843] Python doesn't compile anymore on our Solaris buildbot: undefined libintl_* symbols

[Trent Nelson]

Trent Nelson added the comment:

I ran into this yesterday on my Solaris 10 box (nitrogen/s10), seemingly out of 
nowhere.

The problem is caused when a GNU libintl.h gets picked up via `#include 
` instead of the system one in /usr/include.

In my case, this was happening because I had set CPPFLAGS to 
"-I/opt/csw/include -I/opt/csw/include/ncurses -I/usr/include".

The fix is to order the includes as follows: "-I/opt/csw/include/ncurses 
-I/usr/include -I/opt/csw/include".

The order is important: you want the /opt/csw/include/ncurses to come first, 
otherwise _curses won't build from the curses.h in /usr/include.  However, for 
libintl.h, you want the /usr/include version, not the /opt/csw/include version.

(Side note: I briefly looked at the GNU libintl.h in /opt/csw/include.  The 
`libintl_` function prefix is driven by some #ifdef logic, so, presumably, if 
you really wanted to build with the GNU libintl, you could do some #define 
tweaking to disable the `libintl_` prefix.  The libintl shipped with Solaris 10 
seems to work fine, so I didn't bother with this.)

Closing as fixed.

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

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

New submission from Trent Nelson:

% ./python -m test.regrtest test_asyncore
test_asyncore
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/threading.py", line 552, in __bootstrap_inner
self.run()
  File "/home/cpython/hg/2.7/Lib/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 712, in 
t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 220, in loop
poll_fun(timeout, map)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 156, in poll
read(obj)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 87, in read
obj.handle_error()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 83, in read
obj.handle_read_event()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 443, in handle_read_event
self.handle_accept()
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 487, in 
handle_accept
sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

Exception in thread Thread-4:
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/threading.py", line 552, in __bootstrap_inner
self.run()
  File "/home/cpython/hg/2.7/Lib/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 712, in 
t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 220, in loop
poll_fun(timeout, map)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 156, in poll
read(obj)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 87, in read
obj.handle_error()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 83, in read
obj.handle_read_event()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 443, in handle_read_event
self.handle_accept()
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 487, in 
handle_accept
sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

1 test OK.
[43391 refs]

Sample buildbot run that failed: 
http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

Haven't investigated yet.

--
assignee: trent
messages: 173237
nosy: jcea, trent
priority: normal
severity: normal
status: open
title: test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)
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

[issue16273] f.tell() returning negative number on Windows build

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What tell() returns before any reading? What about non-buffered files?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue16166] Add PY_BYTE_ORDER macro to get endianess of platform

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> I've replaced the macros with PY_BIG_ENDIAN or PY_LITTLE_ENDIAN. Both are
> always defined and exactly one is set to 1, the other to 0.

It looks like a joke.

The programmer puts on the table by his bed two glasses. One with water, for 
the case of he will drink at night. Another empty, for the case of he will not 
drink.

--

___
Python tracker 

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