From report at bugs.python.org  Sat Nov  1 00:04:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 31 Oct 2008 23:04:47 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>
Message-ID: <1225494287.05.0.301680108057.issue4243@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Benjamin: Thanks for asking your teacher! It's curious that all the
foreigners have no problems with the formulation, and all the native
speakers do... There is clearly something to the English language that
we haven't mastered yet.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 00:09:00 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 31 Oct 2008 23:09:00 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1225494540.6.0.753081644133.issue4242@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My idea above won't really support Armin's idea of being able to exclude
certain known-broken implementations. The check function would need to
be handled differently to support that use case:

# In test_support.py
vm = platform.python_implementation().lower()
reference_vm = "cpython"

def check_impl_detail(implemented=(reference_vm,), broken=()):
  # Skip known broken implementations
  if broken:
    broken = [vm.lower() for vm in broken]
    if vm in broken:
      return False
  # Only check named implementations
  if implemented:
    implemented = [vm.lower() for vm in implemented]
    return vm in implemented
  # No specific implementations named, so expect it to
  # work on implementations that are not known to be broken
  return True
  
def impl_detail(implemented=(reference_vm,), broken=(), msg=''):
  if check_impl_detail(implemented, broken):
    # Test the implementation detail
  else:
    # Skip this test (incude 'msg' in the skip message)

It would be pretty easy to build cpython_only, jython_only, pypy_only
etc checks and decorators on top of that kind of infrastructure.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Sat Nov  1 02:12:24 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Nov 2008 01:12:24 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225501944.02.0.867759198908.issue4233@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@christian: Your patch doesn't work: if close() if called twice, the 
file is really closed :-/

Here is a new patch:
 - _FileIO.close() sets self->fd to -1 but don't show a warning anymore 
because the operation is valid: it does really close the _FileIO object
 - add two tests for two problems: read is now blocked if the file is 
closed, and the warning displayed by FileIO.__del__

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11921/fileio_closefd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Sat Nov  1 02:28:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Nov 2008 01:28:13 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225502893.35.0.257968775778.issue4233@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

christian just told me that my svn repos was old. Here is an updated 
version of my patch. I now use io.open() instead of io.BufferedReader() 
in the tests.

Added file: http://bugs.python.org/file11922/fileio_closefd-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Sat Nov  1 02:28:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Nov 2008 01:28:22 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225502902.23.0.599960067086.issue4233@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11921/fileio_closefd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Sat Nov  1 02:44:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 01 Nov 2008 01:44:59 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225503899.45.0.233074906081.issue4233@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Another patch based on Victor's patch. It adds some additional tests and
exposes the internal attribute closefd.

Added file: http://bugs.python.org/file11923/fileio_closefd3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Sat Nov  1 07:42:11 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2008 06:42:11 +0000
Subject: [issue4220] Builtins treated as free variables?
In-Reply-To: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za>
Message-ID: <1225521731.08.0.382870294994.issue4220@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The request as stated is invalid.
'Int' and 'long' are built-in names, not keywords.

The context of the cited sentence is
"If a name is bound in a block, it is a local variable of that block,
unless declared as nonlocal. If a name is bound at the module level, it
is a global variable. (The variables of the module code block are local
and global.) If a variable is used in a code block but not defined
there, it is a free variable."

Built-in names are not defined in the code block.  Therefore, they are
free names (variables).  However, there is NO mention of builtins in
this chapter up to this point*, so I can see how one could miss that.  
* The previous 'identifiers' chapter has only this:
"The special identifier _ is used in the interactive interpreter to
store the result of the last evaluation; it is stored in the builtins
module."

So something like the following could be added:
"Free variables include the names of built-in objects."

where *built-in objects* is linked to that section near the top of the
Library manual.  (The references later in the chapter are to the Lib
manual entry on the builtins module, which pretty much repeats what is
said later in the chapter.)

----------
nosy: +tjreedy
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4220>
_______________________________________

From report at bugs.python.org  Sat Nov  1 07:43:15 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2008 06:43:15 +0000
Subject: [issue4220] Builtins treated as free variables?
In-Reply-To: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za>
Message-ID: <1225521795.16.0.531339659526.issue4220@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4220>
_______________________________________

From report at bugs.python.org  Sat Nov  1 08:10:42 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2008 07:10:42 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1225523442.81.0.225108844012.issue4221@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You tested on 2.5.2 but marked this for 2.6.  3.0 gives
>>> int('\0')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    int('\0')
UnicodeEncodeError: 'decimal' codec can't encode character '\x00' in
position 0: invalid decimal Unicode string

>>> int('\1')
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    int('\1')
ValueError: invalid literal for int() with base 10: '\x01'

>>> int('\1',256)
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    int('\1',256)
ValueError: int() arg 2 must be >= 2 and <= 36

The 3.0 doc on string inputs
"A string must be a base-radix integer literal optionally preceded by
?+? or ?-? (with no space in between) and optionally surrounded by
whitespace. A base-n literal consists of the digits 0 to n-1, with ?a?
to ?z? (or ?A? to ?Z?) having values 10 to 35."

in much clearer than the 2.6 doc
"If the argument is a string, it must contain a possibly signed decimal
number representable as a Python integer, possibly embedded in whitespace."

Even so, I do not see any inconsistency.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Sat Nov  1 09:09:32 2008
From: report at bugs.python.org (zaur)
Date: Sat, 01 Nov 2008 08:09:32 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1225526972.8.0.219558376407.issue4230@psf.upfronthosting.co.za>


zaur <szport at gmail.com> added the comment:

It's the issue for python 3.0 too

----------
nosy: +zaur

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Sat Nov  1 15:59:31 2008
From: report at bugs.python.org (robwolfe)
Date: Sat, 01 Nov 2008 14:59:31 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>


New submission from robwolfe <rw at smsnet.pl>:

I'd like to propose adding some complete example regarding scopes and
bindings resolving to execution model description.
There is no week on pl.comp.lang.python without a question about
UnboundLocalError problem. I'm getting tired answering that. ;-)
It does not have to look so verbose as my (attached) example, but please
add some example, which will clarify this issue.

----------
assignee: georg.brandl
components: Documentation
files: scopes.py
messages: 75441
nosy: georg.brandl, robwolfe
severity: normal
status: open
title: execution model - clear and complete example in documentation
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11924/scopes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Sat Nov  1 16:29:54 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 01 Nov 2008 15:29:54 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1225553394.62.0.302495068792.issue4221@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

2.6 exhibits the same behavior as 2.5 in this case.  3.0 exhibits
similar behavior, but with a slightly different exception in the NUL
case.  The examples included showing the Python 3 behavior don't cover
the same cases as the examples I included in my initial comment.

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Sat Nov  1 17:08:43 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2008 16:08:43 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>
Message-ID: <1225555723.6.0.490301249622.issue4243@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Benjamin: I thank you too for verifying that I was not crazy.

Martin: I noticed native/non-native split too, and chalked it up to a
subtle difference between German and English.

For future reference, the problem with the original, as I see it now, is
a subtle interaction between syntax and semantics.  The original
sentence combined two thoughts about has_key.  The two should be either
coordinate (parallel in form) or one should be clearly subordinate.  A
subordinate modifier should generally be closer to the subject,
especially if it is much shorter.  Making that so was one of my
suggestions.  The coordinate form would be 'but it is deprecated'.  But
this does not work because 'it' would be somewhat ambiguous because of
the particular first modifier.  

The following pair of sentences illustrate what I am trying to say.
  Guido was once a Nederlander, but he moved to America.
  Guido was once a student of Professor X, but he moved to America.
In English, the second 'he' is ambiguous because of the particular first
modifier.

So, to me, 'but deprecated' at the end of the sentence reads as either a
misplaced subordinate form or as an abbreviated coordinate form that is
at least somewhat ambiguous because of the meaning of the other modifier.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 18:45:12 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 01 Nov 2008 17:45:12 +0000
Subject: [issue4100] xml.etree.ElementTree does not read xml-text over page
	bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1225561512.68.0.847732271872.issue4100@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
assignee:  -> effbot
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4100>
_______________________________________

From report at bugs.python.org  Sat Nov  1 19:07:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 01 Nov 2008 18:07:16 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225555723.6.0.490301249622.issue4243@psf.upfronthosting.co.za>
Message-ID: <490C9AD1.9060400@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The following pair of sentences illustrate what I am trying to say.
>   Guido was once a Nederlander, but he moved to America.
>   Guido was once a student of Professor X, but he moved to America.
> In English, the second 'he' is ambiguous because of the particular first
> modifier.

Ah - thanks for the explanation. I now recall that native speakers
typically associate "it" (or "he") with the *last* thing/person being
mentioned. If this is the case, it's indeed different from German;
the literal translation of the second sentence would not usually be
considered ambiguous:

   Guido war fr?her Student von Professor X,
   (er) ist aber nach Amerika umgezogen.

If we wanted to express that it is X who moved, we would say

   Guido war fr?her Student von Professor X,
   der/welcher aber nach Amerika umgezogen ist.

which translates to

   Guido was once a student of Professor X, who moved
   to America, though. (couldn't figure out how to put the
   "but" into that sentence)

So in German, it seems, backward references go typically to
the subject of the main phrase.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 19:14:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Nov 2008 18:14:32 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>
Message-ID: <1225563272.02.0.0253881409764.issue4243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Forgive me for playing stupid here, but I want to understand English
better. I would fully understand the confusion had the sentence been

"dict.has_key(key) is equivalent to key in d, but it is deprecated."

Terry's and Martin' example sentences are transferable to that. However,
the actual sentence was

"dict.has_key(key) is equivalent to key in d, but deprecated."

Let me try to construct a similar sentence:

"Guido was once a colleague of Joe, but much smarter."

Can the "but" clause really be taken as referring to Joe? Or is it
simply not an English sentence? ;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 19:24:49 2008
From: report at bugs.python.org (D'Arcy J.M. Cain)
Date: Sat, 01 Nov 2008 18:24:49 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>
Message-ID: <1225563889.18.0.243889564865.issue4243@psf.upfronthosting.co.za>


D'Arcy J.M. Cain <darcy at druid.net> added the comment:

I think a clarification is in order.  The sentence being changed was
perfectly and mathematically correct.  If you laid it out on a
blackboard and parsed it (remember those days?) you could prove that it
said the correct thing.  No one is disputing that I think.  The change
is simply to make it easier on the guy who is reading the manual in a
rush, under a deadline and who might misread it.  His fault but there is
no harm in protecting him a little.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 19:31:55 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 01 Nov 2008 18:31:55 +0000
Subject: [issue4100] xml.etree.ElementTree does not read xml-text over page
	bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1225564315.96.0.0794572257176.issue4100@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Roland's right - "iterparse" only guarantees that it has seen the ">" 
character of a starting tag when it emits a "start" event, so the 
attributes are defined, but the contents of the text and tail attributes 
are undefined at that point.  The same applies to the element children; 
they may or may not be present.

If you need a fully populated element, look for "end" events instead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4100>
_______________________________________

From report at bugs.python.org  Sat Nov  1 20:25:23 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 01 Nov 2008 19:25:23 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1225567523.79.0.379662693275.issue1309567@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This is still relevant.  It makes linecache (and therefore some other
things, like inspect.getsource) almost useless in many cases.  For
example, because of this, sometimes inspect.getsource will raise an
IOError and sometimes it will return garbage data.  If the source file
isn't around, it'd be much better to fail all the time.  Rummaging
around in the filesystem hoping to get lucky and find another file with
the same name which contains the correct contents is insane.  This may
have made sense when relative path names were being used, but it makes
no sense anymore.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Sat Nov  1 20:42:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 01 Nov 2008 19:42:02 +0000
Subject: [issue4243] has_key doc could be clearer
In-Reply-To: <1225563889.18.0.243889564865.issue4243@psf.upfronthosting.co.za>
Message-ID: <490CB108.8070905@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Terry's and Martin' example sentences are transferable to that.
>> However, the actual sentence was
>> "dict.has_key(key) is equivalent to key in d, but deprecated."

> The sentence being changed was perfectly and mathematically correct.

I'm not so sure about that anymore. Reading the post in

http://www.englishforums.com/English/RepetitionSubjectPronoun/cqjlw/post.htm

it now seems to me that the part after the comma is a separate sentence,
and both the subject pronoun and the verb are omitted (as an ellipsis).
So the full sentence would indeed read

"dict.has_key(key) is equivalent to key in d, but it is deprecated."

which then would be ambiguous as discussed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4243>
_______________________________________

From report at bugs.python.org  Sat Nov  1 22:57:29 2008
From: report at bugs.python.org (Nick Martin)
Date: Sat, 01 Nov 2008 21:57:29 +0000
Subject: [issue1109963] bdist_wininst ignores build_lib from build command
Message-ID: <1225576649.03.0.904304161943.issue1109963@psf.upfronthosting.co.za>


Nick Martin <nick at ishere.org> added the comment:

This is exactly the same problem I was having with bdist_msi.

----------
nosy: +nick.martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109963>
_______________________________________

From report at bugs.python.org  Sun Nov  2 01:00:01 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 02 Nov 2008 00:00:01 +0000
Subject: [issue4100] xml.etree.ElementTree does not read xml-text over page
	bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1225584001.33.0.282434654766.issue4100@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4100>
_______________________________________

From report at bugs.python.org  Sun Nov  2 01:18:24 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 02 Nov 2008 00:18:24 +0000
Subject: [issue4100] xml.etree.ElementTree does not read xml-text over page
	bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1225585104.39.0.152339429077.issue4100@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I propose to note this behavior on document. I'll attach the patch. (I
just inserted your comment into document)

----------
components: +Documentation -Library (Lib), XML
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file11925/ElementTree_iterparse_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4100>
_______________________________________

From report at bugs.python.org  Sun Nov  2 03:16:03 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 02 Nov 2008 02:16:03 +0000
Subject: [issue4247] Docs: Provide some examples of "pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

I'm giving a Python tutorial to a bunch of local people and have decided
to use the Python.org tutorial to go by.  One of the things I found I
wanted in the section on the "pass" statement was more information about
it's use.  But I also think it's worth mentioning using the
NotImplementedError if pass is used for stubbing out code.

This patch to the tutorial includes some example use cases, and also a
reference to NotImplementedError.  I would appreciate some review
however, as I'm not sure this discussion is appropriate.

Included below is the patch, for ease of reading, but it's also attached as
a patch (taken against trunk today).

Sean
===========

Index: Doc/tutorial/controlflow.rst
===================================================================
--- Doc/tutorial/controlflow.rst	(revision 67072)
+++ Doc/tutorial/controlflow.rst	(working copy)
@@ -166,7 +166,36 @@
    ...     pass  # Busy-wait for keyboard interrupt (Ctrl+C)
    ... 
 
+This is commonly used for creating minimal classes like with exceptions, or
+for skipping unwanted exceptions::
 
+   >>> class ParserError(Exception):
+   ...     pass
+   ... 
+   >>> try:
+   ...     import audioop
+   ... except ImportError:
+   ...     pass
+   ... 
+
+Another place it can be used is as a place-holder for a function or
+conditional body when you are working on new code, allowing you to keep
+thinking at a more abstract level.  However, as :keyword:`pass` is silently
+ignored, a better choice may be to raise a :exc:`NotImplementedError`
+exception::
+
+   >>> def initlog(*args):
+   ...     raise NotImplementedError   # Open logfile if not already open
+   ...     if not logfp:
+   ...         raise NotImplementedError  # Set up dummy log back-end
+   ...     raise NotImplementedError  # Call log initialization handler
+   ... 
+
+If :keyword:`pass` were used here and you later ran tests, they may fail
+without indicating why.  Using :exc:`NotImplementedError` causes this code
+to raise an exception, allowing you to tell exactly where code that you
+need to complete is.
+
 .. _tut-functions:
 
 Defining Functions

----------
assignee: fdrake
components: Documentation
files: pass-examples.patch
keywords: easy, needs review, patch, patch
messages: 75452
nosy: fdrake, jafo
priority: normal
severity: normal
status: open
title: Docs: Provide some examples of "pass" use in the tutorial.
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11926/pass-examples.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________

From report at bugs.python.org  Sun Nov  2 05:32:24 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 02 Nov 2008 04:32:24 +0000
Subject: [issue4248] "class in None" in html help keyword
In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
Message-ID: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed built-in class `set` uses "set (class in None)" as index
keyword. Please see attached file "snapshot.png".

I think "set (builtin class)" or something is better.

----------
assignee: georg.brandl
components: Documentation, Windows
files: snapshot.png
messages: 75453
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: "class in None" in html help keyword
versions: Python 2.6
Added file: http://bugs.python.org/file11927/snapshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4248>
_______________________________________

From report at bugs.python.org  Sun Nov  2 07:24:30 2008
From: report at bugs.python.org (Brad Hall)
Date: Sun, 02 Nov 2008 06:24:30 +0000
Subject: [issue4194] Miserable subprocess.Popen performance
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1225607070.35.0.579212977414.issue4194@psf.upfronthosting.co.za>


Changes by Brad Hall <bhall at eng.sun.com>:


----------
nosy: +bgh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Sun Nov  2 15:56:55 2008
From: report at bugs.python.org (Jon Perez)
Date: Sun, 02 Nov 2008 14:56:55 +0000
Subject: [issue4249] HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za>
Message-ID: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za>


New submission from Jon Perez <jbperez808 at yahoo.com>:

In http_response in HTTPErrorProcessor, the following line

code, msg, hdrs = response.code, response.msg, response.info()

results in an error because response.code is not a valid
attribute, changing it to response.status works, but is
this the correct bug fix?



See
http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/

Traceback (most recent call last):
File "/usr/bin/yum", line 30, in <module>
yummain.main(sys.argv[1:])
File "/usr/share/yum/yummain.py", line 233, in main
clientStuff.get_package_info_from_servers(serverlist, HeaderInfo)
File "/usr/share/yum/clientStuff.py", line 846, in
get_package_info_from_servers
progress_obj=None)
File "/usr/share/yum/clientStuff.py", line 1327, in grab
bandwidth, conf.retries, retrycodes, checkfunc)
File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab
progress_obj, throttle, bandwidth)
File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab
fo = urllib2.urlopen(url)
File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 487, in http_response
code, msg, hdrs = response.code, response.msg, response.info()
AttributeError: HTTPResponse instance has no attribute 'code'

----------
components: Library (Lib)
messages: 75454
nosy: jbperz808
severity: normal
status: open
title: HTTPResponse instance has no attribute 'code'
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4249>
_______________________________________

From report at bugs.python.org  Sun Nov  2 15:57:17 2008
From: report at bugs.python.org (Jon Perez)
Date: Sun, 02 Nov 2008 14:57:17 +0000
Subject: [issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
Message-ID: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>


New submission from Jon Perez <jbperez808 at yahoo.com>:

In http_response() in HTTPErrorProcessor in urllib2.py, the following line

code, msg, hdrs = response.code, response.msg, response.info()

results in an error because response.code is not a valid
attribute, changing it to response.status works, but is
this the correct bug fix?



See
http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/

Traceback (most recent call last):
File "/usr/bin/yum", line 30, in <module>
yummain.main(sys.argv[1:])
File "/usr/share/yum/yummain.py", line 233, in main
clientStuff.get_package_info_from_servers(serverlist, HeaderInfo)
File "/usr/share/yum/clientStuff.py", line 846, in
get_package_info_from_servers
progress_obj=None)
File "/usr/share/yum/clientStuff.py", line 1327, in grab
bandwidth, conf.retries, retrycodes, checkfunc)
File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab
progress_obj, throttle, bandwidth)
File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab
fo = urllib2.urlopen(url)
File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 487, in http_response
code, msg, hdrs = response.code, response.msg, response.info()
AttributeError: HTTPResponse instance has no attribute 'code'

----------
components: Library (Lib)
messages: 75455
nosy: jbperz808
severity: normal
status: open
title: urllib2.py: HTTPResponse instance has no attribute 'code'
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4250>
_______________________________________

From report at bugs.python.org  Sun Nov  2 22:51:45 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 02 Nov 2008 21:51:45 +0000
Subject: [issue4251] library.pdf documentation: "See also: Module <xxx>" does
	not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

I take chapter "19.12 base64?RFC 3548: Base16, Base32, Base64 Data
Encodings" (Python 2.6) as an example. At the bottom of the chapter, you
find references to other resouces, in this case:

See Also:
Module binascii Support module containing ASCII-to-binary and
binary-to-ASCII conversions.
RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Section 5.2,
?Base64 Content-Transfer-Encoding,? provides the definition of the
base64 encoding.

Interestingly enough RFC 1521 points to a web page (the link has been
removed in the current HTML documentation).

However "Module binascii" does not link to binascii in the library.pdf,
whereas the HTML documentation nicely links to
http://docs.python.org/library/binascii.html.

The file base64.rst IMO indicates that a link should be produced:
.. seealso::

   Module :mod:`binascii`
      Support module containing ASCII-to-binary and binary-to-ASCII
conversions.

   :rfc:`1521` - MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Internet Message
Bodies
      Section 5.2, "Base64 Content-Transfer-Encoding," provides the
definition of the
      base64 encoding.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75456
nosy: georg.brandl, wplappert
severity: normal
status: open
title: library.pdf documentation: "See also: Module <xxx>" does not link to xxx inside the PDF File
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________

From report at bugs.python.org  Sun Nov  2 22:52:37 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 02 Nov 2008 21:52:37 +0000
Subject: [issue4251] library.pdf documentation: "See also: Module <xxx>" does
	not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1225662757.56.0.720802445004.issue4251@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________

From report at bugs.python.org  Mon Nov  3 00:23:48 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 02 Nov 2008 23:23:48 +0000
Subject: [issue4247] Docs: Provide some examples of "pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225668228.56.0.679542852933.issue4247@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I'd change the exceptions, replace comment with string.
Instead of

raise NotImplementedError  # Set up dummy log back-end

write

raise NotImplementedError('Set up dummy log back-end')

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________

From report at bugs.python.org  Mon Nov  3 01:55:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 00:55:42 +0000
Subject: [issue4248] "class in None" in html help keyword
In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
Message-ID: <1225673742.87.0.373516593892.issue4248@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've received checkin-mail to notify
http://svn.python.org/projects/doctools is outdated, but I don't have
Mercurial now, so I'll submit a patch for outdated repo. (I hope not so
outdated just now) Sorry for inconvenience.

----------
keywords: +patch
Added file: http://bugs.python.org/file11928/sphinx_class_in_none.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4248>
_______________________________________

From report at bugs.python.org  Mon Nov  3 02:10:11 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 01:10:11 +0000
Subject: [issue4248] "class in None" in html help keyword
In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
Message-ID: <1225674611.75.0.212112754059.issue4248@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
components: +Documentation tools (Sphinx) -Documentation, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4248>
_______________________________________

From report at bugs.python.org  Mon Nov  3 02:44:27 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 01:44:27 +0000
Subject: [issue4252] inactive item not shown in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Please see index_on_firefox.png and index_on_htmlhelp.png. "and" is
inactive item not linking to any page, but this item is not shown in
htmlhelp.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: index_on_firefox.png
messages: 75459
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: inactive item not shown in html help index pane
versions: Python 2.6
Added file: http://bugs.python.org/file11929/index_on_firefox.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov  3 02:44:41 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 01:44:41 +0000
Subject: [issue4252] inactive item not shown in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1225676681.52.0.455321787759.issue4252@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file11930/index_on_htmlhelp.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov  3 02:53:02 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 01:53:02 +0000
Subject: [issue4252] inactive item not shown in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1225677182.33.0.459856753043.issue4252@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope this can be fixed by attached patch. I learned this technique to
create inactive link from HTML Help Workshop document.

http://msdn.microsoft.com/en-us/library/ms669985.aspx
http://go.microsoft.com/fwlink/?linkid=14581 # direct link to HelpDocs.zip

And please enter keyword "index files, creating inactive links".

----------
keywords: +patch
Added file: http://bugs.python.org/file11931/sphinx_inactive_index_item.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov  3 05:38:42 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 03 Nov 2008 04:38:42 +0000
Subject: [issue4247] Docs: Provide some examples of "pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225687122.26.0.377841844749.issue4247@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I originally had that, but then I realized that if I make it a comment I
can then do something like "dw." on that line when I start filling in
the code to keep the comment around.  Because I find that when I fill in
the high level comments they make nice comments to keep around for that
code block.

I'm open to the exception string, but I deliberately switched from the
string to comment.

Sean

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________

From report at bugs.python.org  Mon Nov  3 08:03:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Nov 2008 07:03:44 +0000
Subject: [issue4248] "class in None" in html help keyword
In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
Message-ID: <1225695824.93.0.972838124908.issue4248@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed as changeset 693fa9bb3b39.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4248>
_______________________________________

From report at bugs.python.org  Mon Nov  3 09:18:44 2008
From: report at bugs.python.org (Marcus CM)
Date: Mon, 03 Nov 2008 08:18:44 +0000
Subject: [issue4253] Maildir dumpmessage on
In-Reply-To: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za>
Message-ID: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za>


New submission from Marcus CM <marcus at internetnowasp.net>:

When using maildir on windows, the maildir._dump_message erronously 
added "\r\n" to "\r\r\n" : in mailbox.py

target.write(buffer.read().replace('\n', os.linesep))

----------
components: Library (Lib)
messages: 75463
nosy: marcus at internetnowasp.net
severity: normal
status: open
title: Maildir dumpmessage on
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4253>
_______________________________________

From report at bugs.python.org  Mon Nov  3 16:02:10 2008
From: report at bugs.python.org (Roland Brickl)
Date: Mon, 03 Nov 2008 15:02:10 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>


New submission from Roland Brickl <nemesis at bluesunset.de>:

curses.update_lines.cols() are normally usable within c programs. With
this change, it can now be used too. It only calls the preexisting
function that where only used internally. The cast in the return
statement are possibly false? But it works.
Because this aren't a big change, it would apply to some more
python-versions.

----------
components: Extension Modules
files: _curses.diff
keywords: patch
messages: 75464
nosy: nemesis
severity: normal
status: open
title: _cursesmodule.c callable update_lines_cols()
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file11932/_curses.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Mon Nov  3 16:15:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2008 15:15:07 +0000
Subject: [issue4048] parsermodule won't validate relative imports
In-Reply-To: <1223244920.43.0.0525505327115.issue4048@psf.upfronthosting.co.za>
Message-ID: <1225725307.34.0.0495580631116.issue4048@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! Fixed in r67077.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4048>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:03:03 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 03 Nov 2008 16:03:03 +0000
Subject: [issue4255] timing module refers to non-existent documentation
In-Reply-To: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>
Message-ID: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

import timing
help(timing) 
=> MODULE DOCS
    http://www.python.org/doc/current/lib/module-timing.html

but there doesn't appear to be any such page: the URL gives Error 404: 
File Not Found. Searching the reference library for "timing" doesn't 
find anything that looks relevant.

----------
assignee: georg.brandl
components: Documentation
messages: 75466
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: timing module refers to non-existent documentation
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4255>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:10:13 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 03 Nov 2008 16:10:13 +0000
Subject: [issue4255] timing module refers to non-existent documentation
In-Reply-To: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>
Message-ID: <1225728613.0.0.252144361257.issue4255@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Well, it's listed in "Undocumented modules":
http://docs.python.org/library/undoc.html#obsolete
so I wouldn't call this a bug.

----------
nosy: +mishok13

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4255>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:18:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Nov 2008 16:18:10 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1225729090.12.0.854094925669.issue4254@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Your function PyCurses_update_lines_cols() has no documentation. Can 
you add it?

Can you also give an use case of update_lines_cols()? The function is 
already called by curses.resizeterm() and curses.resize_term().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:30:55 2008
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 03 Nov 2008 16:30:55 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

optparse is a great option parser, but one thing that would make it even
greater would be if it provided a standard option (cf. --help) which
lists all the available options in a parseable form. Something prefixed
with --help, e.g. --help-options would be ideal since it doesn't clutter
the option namespace.

This would provide a simple command-line hook for e.g. bash completion
customisation with complete/compgen, which could then easily and
maintainably obtain the list of available switches via the
--help-options flag rather than hard-coding the option names or
attempting to grep the output of --help

It would also be good if the OptionParser provided a simple Python API
way to obtain the names of all option switches, rather than having to
loop over OptionGroups, calling the unadvertised 'option_list' and
'get_option_name' methods!

----------
components: Library (Lib)
messages: 75469
nosy: andybuckley
severity: normal
status: open
title: optparse: provide a simple way to get a programmatically useful list of options
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:36:05 2008
From: report at bugs.python.org (Roland Brickl)
Date: Mon, 03 Nov 2008 16:36:05 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1225730165.77.0.551671726874.issue4254@psf.upfronthosting.co.za>


Roland Brickl <nemesis at bluesunset.de> added the comment:

Hi Victor,

i use this to get updated versions of curses.COLS and curses.LINES in 
the fact of an curses.KEY_RESIZE event.
So i can use curses within python even without to have panels.
It seems that curses.panel are the prefered way to deal with terminal 
resizes.
The curses.resize[_]term() are only to change the terminal manualy.
What i also found in PyTone is more or less this functionality from 
update_lines_cols():

def getmaxyx(self):
    # taken from http://dag.wieers.com/home-made/dstat/
    try:
        h, w = int(os.environ["LINES"]), int(os.environ["COLUMNS"])
    except KeyError:
        try:
            h, w = curses.tigetnum('lines'), curses.tigetnum('cols')
        except:
            try:
                s = struct.pack('HHHH', 0, 0, 0, 0)
                x = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ,
s)
                h, w = struct.unpack('HHHH', x)[:2]
            except:
                h, w = 25, 80

And please excuse me for the missing documentation. English aren't my 
native language so i would document it like:
Updates curses.LINES and curses.COLS :)

It's my first day here on the issue tracker.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:36:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2008 16:36:17 +0000
Subject: [issue4255] timing module refers to non-existent documentation
In-Reply-To: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>
Message-ID: <1225730177.87.0.374525117053.issue4255@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Agreed. This is a deprecated module and is gone in Python 3.0.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4255>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:53:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Nov 2008 16:53:15 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225730165.77.0.551671726874.issue4254@psf.upfronthosting.co.za>
Message-ID: <200811031752.55395.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> i use this to get updated versions of curses.COLS and curses.LINES in
> the fact of an curses.KEY_RESIZE event.

I didn't know this event. Is a key in a special keyboard? Or an event raised 
by some curses internals?

> Updates curses.LINES and curses.COLS

Your documentation is incomplete. You may reused this comment:

/* Internal helper used for updating curses.LINES, curses.COLS, 
 * _curses.LINES and _curses.COLS */

Oh I just realized that _curses functions have no documentation, great :-/

> It's my first day here on the issue tracker.

Welcome on the tracker ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Mon Nov  3 17:56:48 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 03 Nov 2008 16:56:48 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1225731408.82.0.391992399729.issue4256@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


----------
nosy: +wplappert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon Nov  3 18:01:36 2008
From: report at bugs.python.org (Roland Brickl)
Date: Mon, 03 Nov 2008 17:01:36 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1225731696.04.0.0846484347808.issue4254@psf.upfronthosting.co.za>


Roland Brickl <nemesis at bluesunset.de> added the comment:

>> i use this to get updated versions of curses.COLS and curses.LINES in
>> the fact of an curses.KEY_RESIZE event.

>I didn't know this event. Is a key in a special keyboard? Or an event 
>raised 
>by some curses internals?
Internal curses event.

>Oh I just realized that _curses functions have no documentation, 
>great :-/
Thats why python_curses should be more compatible to the existing 
c_curses documentations.

>> It's my first day here on the issue tracker.

Welcome on the tracker ;-)
Thanks.

Any questions? :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Mon Nov  3 18:08:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Nov 2008 17:08:08 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1225732088.48.0.828875165539.issue4194@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Miserable subprocess.Popen performance -> default subprocess.Popen buffer size

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov  3 18:14:48 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Nov 2008 17:14:48 +0000
Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in
	multi-threads environment in linux.
In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za>
Message-ID: <1225732488.56.0.571791495963.issue1978@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file9346/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1978>
_______________________________________

From report at bugs.python.org  Mon Nov  3 18:17:18 2008
From: report at bugs.python.org (Dan OD)
Date: Mon, 03 Nov 2008 17:17:18 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1225732638.85.0.728928242539.issue3774@psf.upfronthosting.co.za>


Dan OD <djo35 at cam.ac.uk> added the comment:

Sorry to drag this up again, but if no-one has any complaints it would be 
a huge help if gpolo's patch could be checked in. Thanks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Mon Nov  3 19:20:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 18:20:28 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1225736428.94.0.866311194432.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r67082(trunk), r67083(release26-maint), r67084(release25-maint).

----------
keywords:  -needs review
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Mon Nov  3 20:46:40 2008
From: report at bugs.python.org (Roy Smith)
Date: Mon, 03 Nov 2008 19:46:40 +0000
Subject: [issue4257] Documentation for socket.gethostname() needs tweaking
In-Reply-To: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za>
Message-ID: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs say:

Return a string containing the hostname of the machine where the Python 
interpreter is currently executing. If you want to know the current 
machine's IP address, you may want to use gethostbyname(gethostname()). 
This operation assumes...

It is not clear what the referent of "This" is.  Are you saying that 
gethostname() itself makes that assumption, or the use of gethostbyname() 
to turn what gethostname() returns into an address makes that assumption?  
I think it's the latter, but the sentence should be reworded to make it 
clear.

----------
assignee: georg.brandl
components: Documentation
messages: 75476
nosy: georg.brandl, roysmith
severity: normal
status: open
title: Documentation for socket.gethostname() needs tweaking
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4257>
_______________________________________

From report at bugs.python.org  Mon Nov  3 21:44:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2008 20:44:11 +0000
Subject: [issue4257] Documentation for socket.gethostname() needs tweaking
In-Reply-To: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za>
Message-ID: <1225745051.52.0.830850782917.issue4257@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the suggestion fixed in r67089.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4257>
_______________________________________

From report at bugs.python.org  Mon Nov  3 21:44:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2008 20:44:58 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1225745098.4.0.551268148879.issue3774@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Could you port this to 3.0, please?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Mon Nov  3 23:06:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 03 Nov 2008 22:06:03 +0000
Subject: [issue4211] frozen packages set an improper __path__ value
In-Reply-To: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>
Message-ID: <1225749963.73.0.689348832622.issue4211@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4211>
_______________________________________

From report at bugs.python.org  Tue Nov  4 00:59:01 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 03 Nov 2008 23:59:01 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225756741.79.0.475131328087.issue1210@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The assertion on line 813 is indented incorrectly.  Please fix that.

I'm concerned we really need better test coverage for this code, but
it's doubtful we'll get that before 3.0 final is released.  I think this
is the best we're going to do, and nothing else about the code jumps out
at me.

Go ahead and land it after that minor fix.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:03:41 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 Nov 2008 00:03:41 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1225757021.7.0.550616242013.issue3727@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Benjamin's reviewed this and the only thing that jumps out at me is some
funky indentation at about line 331.  If you fix that, you can land this
patch.

----------
keywords:  -needs review
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:08:25 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 Nov 2008 00:08:25 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1225757305.51.0.975352421849.issue3714@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please fix the test as Benjamin suggests ("network").  While I'd prefer
a more fleshed out test suite, I think in time you can add that.  For
now, this is still an improvement and likely the best we're going to get
before 3.0.  Thanks for working on this.

Go ahead and make the suggested change and land the code.

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:10:16 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 Nov 2008 00:10:16 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1225757416.57.0.997153311377.issue4236@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Can you add some tests for this problem?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:13:57 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 Nov 2008 00:13:57 +0000
Subject: [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1225757637.46.0.629528681546.issue4204@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Christian, if you like the patch go ahead and land it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4204>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:17:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Nov 2008 00:17:14 +0000
Subject: [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1225757834.89.0.913102760004.issue4204@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I don't fully grasp the details of the configure.in change. I don't have
the means to test the change on Mac and BSD. How should we pursue it?
The rest is fine with me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4204>
_______________________________________

From report at bugs.python.org  Tue Nov  4 01:28:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Nov 2008 00:28:31 +0000
Subject: [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1225758511.42.0.23376429946.issue4204@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Martin, can you please review the configure.in change? Barry and I
agreed that you a most probably the best person for the job. :]

----------
assignee: barry -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4204>
_______________________________________

From report at bugs.python.org  Tue Nov  4 02:01:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 01:01:19 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225760479.66.0.27481862549.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I updated my patch against Python3 trunk. I fixed my patch to pass 
most long and struct tests:
 - fix byte array import/export
 - check for overflow
 - compute exponent in conversion to a float (use PyLong_SHIFT=1)
 - fix formating to support 0b, 0o, 0x or custom base (XX#...)

You have to add "-lgmp" to LIBS variable of the Makefile.

There are still some issues about (unsigned) long long: overflow is 
not detected. mashal is broken for long.

diffstat py3k-long_gmp-v3.patch
 Include/longintrepr.h |   49
 Include/longobject.h  |    3
 Modules/mathmodule.c  |    6
 Objects/boolobject.c  |   12
 Objects/longobject.c  | 3053 
+++++---------------------------------------------
 Python/marshal.c      |    9
 Python/mystrtoul.c    |   26
 7 files changed, 376 insertions(+), 2782 deletions(-)

----------
nosy: +haypo
Added file: http://bugs.python.org/file11933/py3k-long_gmp-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 02:21:24 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 01:21:24 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225761684.86.0.340903201831.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

And Now for Something Completely Different. Benchmarks!
 - python3 rev67089.
 - Pentium4 @ 3.0 GHz (integer = 32 bits)
 - GCC 4.1.3 (Ubuntu Gutsy)

gcc -O0:
  builtin: 20920.5 pystones/second
  GMP: 17985.6 pystones/second

gcc -O3:
  builtin: 30120.5 pystones/second
  GMP: 25641.0 pystones/second

(I took the biggest value of 3 runs)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 02:24:41 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 04 Nov 2008 01:24:41 +0000
Subject: [issue416670] MatchObjects not deepcopy()able
Message-ID: <1225761881.01.0.261617904104.issue416670@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

One reason why this issue has been having less impact is that a bug in 
some versions of the copy.py code meant it was ignoring the 
__deepcopy__ stubs and using the pickle logic to copy _sre objects - 
so, if you run the right python version, compiled regular expressions 
and match objects deepcopy without problems.

On the 2.4 branch (release24-maint), changeset 38430 introduced the bug 
that prevents the class __deepcopy__ exception-raising stubs being 
found.

As an aside, I don't understand why the _sre objects should be 
pickleable, but not deepcopy-able.

----------
nosy: +andrewmcnamara
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue416670>
_______________________________________

From report at bugs.python.org  Tue Nov  4 03:41:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 04 Nov 2008 02:41:35 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225766495.79.0.275977056731.issue1210@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Nov  4 03:48:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 04 Nov 2008 02:48:37 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1225766917.63.0.9028816509.issue3727@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________

From report at bugs.python.org  Tue Nov  4 03:48:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 04 Nov 2008 02:48:54 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1225766934.09.0.622925955894.issue3714@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Tue Nov  4 04:22:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 03:22:13 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225768933.07.0.811712132287.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch using short integer for long_add, long_sub, 
long_mul, etc. New benchmark with -0O : 20161.3 pystones/second 
(versus 20920.5 for the vanilla version). The overhead is now -3,6% 
(yes, it's slower with GMP).

Added file: http://bugs.python.org/file11934/py3k-long_gmp-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 04:22:25 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 03:22:25 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225768945.28.0.817640649305.issue1814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file9141/py3k-long_gmp-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 04:22:27 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 03:22:27 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225768947.95.0.0809096702988.issue1814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11933/py3k-long_gmp-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 07:28:20 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 04 Nov 2008 06:28:20 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1225780100.08.0.974886534581.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Done. Fixed in r67095(py3k).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Tue Nov  4 11:45:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 10:45:12 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's an experimental patch, against the py3k branch, that makes Python 
represent its long integers internally in base 2**30 instead of base 
2**15, on platforms that have 32-bit and 64-bit integers available.

On platforms for which autoconf is unable to find both 32-bit and 64-bit 
integers, the representation falls back to the usual one.


See also issue 1814 (GMP for longs), and the discussion at

http://mail.python.org/pipermail/python-dev/2008-November/083315.html

(note particularly Tim Peter's message at:

http://mail.python.org/pipermail/python-dev/2008-November/083355.html
)

----------
components: Interpreter Core
files: 30bit_longdigit.patch
keywords: patch
messages: 75491
nosy: marketdickinson
severity: normal
status: open
title: Use 30-bit digits instead of 15-bit digits for Python integers.
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file11935/30bit_longdigit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov  4 12:04:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 11:04:17 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225796657.11.0.267644056954.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Note that to avoid "bad marshal data" errors, you'll probably need to do a 
'make distclean' before rebuilding with this patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov  4 15:27:38 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Tue, 04 Nov 2008 14:27:38 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1225808858.04.0.212099711848.issue3588@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

I confirm this issue, some handy workaround available?

----------
nosy: +naufraghi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Nov  4 16:29:03 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 15:29:03 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225812543.69.0.355265535027.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated patch, with the following changes from the original:

- make the size of a digit (both the conceptual size
in bits and actual size in bytes) available to Python
via a new structseq sys.int_info.  This information
is useful for the sys.getsizeof tests.

- fix a missing cast in long_hash

- better fast path for 1-by-1 multiplication that
doesn't go via PyLong_FromLongLong.

Added file: http://bugs.python.org/file11936/30bit_longdigit2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov  4 16:37:56 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 15:37:56 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1225813076.42.0.335183613096.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've opened a separate issue (issue 4258) for the idea of using 30-bit
long digits instead of 15-bit ones.  I'll remove the patch from this 
issue.

Pernici Mario's idea applies even better to base 2**30 longs:  one can
clump together 16 (!) of the multiplications at once, essentially
eliminating the overhead of shifts almost completely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Nov  4 16:38:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 15:38:13 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1225813093.8.0.088481158173.issue3944@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file11724/30bit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Nov  4 18:27:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 17:27:58 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225819678.01.0.258276838713.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch, changes:
 - fix mashal module
 - fix all conversion from/to small integer (long, unsigned long, long 
long, unsigned long long, size_t, ssize_t)
 - create numbits() method for the long type (see also issue #3439)
 - catch memory allocation failure
 - fix many other bugs to fix most tests

Failing tests:
 - decimal: long_hash() is broken (doesn't use MSB)
 - io, pickle, pickletools, sqlite, tarfile: null byte in argument for 
int()
 - random: use old files from pickle whih contains '2147483648L\n' 
(trailing L)
 - sys: sizeof is invalid

To do: 
- raise OverflowError in numbits() for integer 2**(2**k) where 2**k
doesn't fit in an integer
- fix last tests

This version is slower than previous version, but it has less bugs :-)

Added file: http://bugs.python.org/file11937/py3k-long_gmp-v11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 18:28:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 17:28:59 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1225819739.61.0.981301901647.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since it's hard to compare patches, I will now attach the 
longobject.c. But it would be better to use a DVCS with a branch to 
test it...

Added file: http://bugs.python.org/file11938/longobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:16:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:16:00 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1225822560.71.0.903135284864.issue3439@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It would be nicer if the OverflowError from _PyLong_NumBits 
> were propagated, so that the second case raises OverflowError
> instead of giving an incorrect result

Why not, but I prefer your second proposition: return a long integer. 
Attached patch implements this solution.

>>> x=1<<(2**31-1)
>>> n=x.numbits(); n, n.numbits()
(2147483648L, 32L)
>>> x<<=(2**31-1)
>>> n=x.numbits(); n, n.numbits()
(4294967295L, 32L)
>>> x<<=1
>>> n=x.numbits(); n, n.numbits()
(4294967296L, 33L) # yeah!

With my patch, there are two functions:
 - _PyLong_NumBits(long)->size_t: may overflow
 - long_numbits(long)->long: don't raise overflow error, but may raise 
other errors like memory error

Added file: http://bugs.python.org/file11939/numbits-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:19:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:19:06 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1225822746.3.0.570399714308.issue3714@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11913/nntp-bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:23:36 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:23:36 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1225823016.12.0.907025401209.issue3727@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11813/poplib-bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:24:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:24:50 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1225757021.7.0.550616242013.issue3727@psf.upfronthosting.co.za>
Message-ID: <200811041924.22743.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Tuesday 04 November 2008 01:03:42 Barry A. Warsaw, vous avez ?crit?:
> Benjamin's reviewed this and the only thing that jumps out at me is some
> funky indentation at about line 331

It's not related to my patch (I did'nt change POP3_SSL comment). But well, as 
you want: a new patch re-indent the "See the methods of the parent (...)" 
line (331).

Added file: http://bugs.python.org/file11940/poplib-bytes-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: poplib-bytes-3.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081104/3ce263af/attachment.txt>

From report at bugs.python.org  Tue Nov  4 19:27:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:27:16 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225823236.97.0.575363815687.issue1210@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11796/imaplib_bytes-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:27:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:27:30 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1225757305.51.0.975352421849.issue3714@psf.upfronthosting.co.za>
Message-ID: <200811041921.08435.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Tuesday 04 November 2008 01:08:25 Barry A. Warsaw, vous avez ?crit?:
> Please fix the test as Benjamin suggests ("network")

Done: see new attached patch.

Added file: http://bugs.python.org/file11941/nntp-bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nntp-bytes-2.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081104/2ed88b45/attachment-0001.txt>

From report at bugs.python.org  Tue Nov  4 19:29:07 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 04 Nov 2008 18:29:07 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225823347.78.0.915439722361.issue1210@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy:  -exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:30:11 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 04 Nov 2008 18:30:11 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225823411.72.0.702577640785.issue1210@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy:  -draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Nov  4 19:34:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 18:34:04 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1225756741.79.0.475131328087.issue1210@psf.upfronthosting.co.za>
Message-ID: <200811041930.00677.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Tuesday 04 November 2008 00:59:02 Barry A. Warsaw, vous avez ?crit?:
> The assertion on line 813 is indented incorrectly. Please fix that.

Ooops. I'm using the following command because my editor is configured to 
remove the trailing spaces:
   svn diff --diff-cmd="/usr/bin/diff" -x "-ub"

The line 813 was an assertion. I added many assertions to check types (for 
easier debug) but there are not needed anymore (my code is bugfreee, haha, no 
it's a joke). The new attached patch has no more assertion.

Added file: http://bugs.python.org/file11942/imaplib_bytes-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imaplib_bytes-4.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081104/03b3c7b2/attachment.txt>

From report at bugs.python.org  Tue Nov  4 21:44:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:44:01 +0000
Subject: [issue4189] Tilde compression isn't applied in TOC
In-Reply-To: <1224796033.71.0.204844693671.issue4189@psf.upfronthosting.co.za>
Message-ID: <1225831441.02.0.451419249292.issue4189@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/31.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4189>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:45:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:45:22 +0000
Subject: [issue4203] adapt sphinx-quickstart for windows
In-Reply-To: <1224950286.79.0.54626272369.issue4203@psf.upfronthosting.co.za>
Message-ID: <1225831522.52.0.130184042393.issue4203@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/32.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4203>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:46:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:46:30 +0000
Subject: [issue2608] manpages for sphinx-build & sphinx-quickstart
In-Reply-To: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>
Message-ID: <1225831590.57.0.309782520542.issue2608@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/33.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2608>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:47:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:47:09 +0000
Subject: [issue4203] adapt sphinx-quickstart for windows
In-Reply-To: <1224950286.79.0.54626272369.issue4203@psf.upfronthosting.co.za>
Message-ID: <1225831629.02.0.41820211017.issue4203@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4203>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:47:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 04 Nov 2008 20:47:47 +0000
Subject: [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1225831667.57.0.958005100018.issue4204@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r67098, r67099, and r67100.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4204>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:49:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:49:44 +0000
Subject: [issue4167] Inline Markup :const: shows up in Documentation
In-Reply-To: <1224657555.02.0.872283376667.issue4167@psf.upfronthosting.co.za>
Message-ID: <1225831784.14.0.892848318456.issue4167@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r67101.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4167>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:50:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:50:44 +0000
Subject: [issue4166] extra "\fi" in sphinx.sty, line 62
In-Reply-To: <1224626362.8.0.706164926632.issue4166@psf.upfronthosting.co.za>
Message-ID: <1225831844.8.0.764149655439.issue4166@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already tracked in
http://www.bitbucket.org/birkenfeld/sphinx/issue/26/sphinxsty-incompatible-with-texlive-sphinx.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4166>
_______________________________________

From report at bugs.python.org  Tue Nov  4 21:51:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2008 20:51:13 +0000
Subject: [issue3203] sphinx - table of contents doesn't render correctly (html)
In-Reply-To: <1214426188.21.0.172463487619.issue3203@psf.upfronthosting.co.za>
Message-ID: <1225831873.74.0.238159976321.issue3203@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Now tracked in
http://www.bitbucket.org/birkenfeld/sphinx/issue/6/fix-html-generation-for-tocs.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3203>
_______________________________________

From report at bugs.python.org  Tue Nov  4 22:34:08 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 04 Nov 2008 21:34:08 +0000
Subject: [issue4259] Update pydoc URLs
In-Reply-To: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za>
Message-ID: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The URL for module documentation generated by pydoc is no longer valid.
 The attached patch corrects it for Python 2.5.3 by assembling the URL
using the Python version.

This patch shouldn't be forward-ported to 2.6 or 2.7; Sphinx changes the
URL pattern further, and 2.6 and 2.7 take this into account and get
their URLs correct.

----------
files: pydoc-patch.txt
messages: 75509
nosy: akuchling
severity: normal
status: open
title: Update pydoc URLs
versions: Python 2.5.3
Added file: http://bugs.python.org/file11943/pydoc-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4259>
_______________________________________

From report at bugs.python.org  Wed Nov  5 00:07:09 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 23:07:09 +0000
Subject: [issue3166] Make conversions from long to float correctly rounded.
In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>
Message-ID: <1225840029.68.0.794135054003.issue3166@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3166>
_______________________________________

From report at bugs.python.org  Wed Nov  5 00:17:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Nov 2008 23:17:59 +0000
Subject: [issue3166] Make conversions from long to float correctly rounded.
In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>
Message-ID: <1225840679.63.0.321401238701.issue3166@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You may use "if (nbits == (size_t)-1 && PyErr_Occurred())" to check 
_PyLong_NumBits() error (overflow). Well, "if (numbits > DBL_MAX_EXP)" 
should already catch overflow, but I prefer explicit test to check the 
error case.

Anyway, interresting patch! Python3 vanilla:
>>> n = 295147905179352891391; int(float(n)) - n
-65535

Python3 + your patch:
>>> int(float(n)) - n
1

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3166>
_______________________________________

From report at bugs.python.org  Wed Nov  5 01:06:39 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Wed, 05 Nov 2008 00:06:39 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1225843599.03.0.817356146321.issue3588@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

The solution I found is:

LINKFORSHARED = -u _PyMac_Error -framework Python

as in the Apple included Python Makefile

and

LDFLAGS += -F$(PYTHONFRAMEWORKPREFIX)

that makes linker use the right framework (not sure, but works with
MacPython installed)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Wed Nov  5 01:29:09 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 00:29:09 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225844949.84.0.32950005798.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Note that to avoid "bad marshal data" errors, 
> you'll probably need to do a 'make distclean' 
> before rebuilding with this patch.

I saw that you choosed to use the base 2^30 for marshal. For a better 
portability (be able to use .pyc generated without your patch), you 
may keep the base 2^15. I implemented that in my GMP patch (manual 
conversion from/to base 2^15).

If we change the marshal format of long, the magic number should be 
different (we might use a tag like the "full unicode" tag used in 
Python3 magic number) and/or the bytecode (actual bytecode is 'l'). 
The base should be independent of the implementation, like Python does 
with text: UTF-8 for files and UCS-4 in memory. We may use the base 
2^8 (256) or another power or 2^8 (2^16, 2^32, 2^64?). The base 256 
sounds interresting because any CPU is able to process 8 bits digits.

Cons: Use a different bases makes Python slower for loading/writing 
from/to .pyc.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 01:29:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 00:29:14 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225844954.91.0.893410827989.issue4258@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11935/30bit_longdigit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 01:39:16 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Wed, 05 Nov 2008 00:39:16 +0000
Subject: [issue416670] MatchObjects not deepcopy()able
Message-ID: <1225845556.61.0.932371460728.issue416670@psf.upfronthosting.co.za>


Changes by Andrew McNamara <andrewm at object-craft.com.au>:


----------
versions: +Python 2.5.3, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue416670>
_______________________________________

From report at bugs.python.org  Wed Nov  5 01:57:50 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 05 Nov 2008 00:57:50 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225846670.9.0.0995631982967.issue4258@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

oh yay, thanks.  it looks like you did approximately what i had started
working on testing a while back but have gone much further and added
autoconf magic to try and determine when which size should be used.  good.

(i haven't reviewed your autoconf stuff yet)

As for marhsalled data and pyc compatibility, yes that is important to
consider.

We should probably base the decision on which digit size to use
internally on benchmarks, not just if the platform can support 64bit
ints.  Many archs support 64bit numbers as a native C type but require
multiple instructions or are very slow when doing it.

(embedded arm, mips or ppc come to mind as obvious things to test that on)

----------
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 02:12:19 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 01:12:19 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225847539.32.0.403442653902.issue4258@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 02:24:12 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 01:24:12 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225848252.91.0.129196595105.issue4233@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Here is a new patch with doc and NEWS updates.

Added file: http://bugs.python.org/file11944/fileio_closefd4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Wed Nov  5 06:51:03 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 05 Nov 2008 05:51:03 +0000
Subject: [issue4260] ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
Message-ID: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/ctypes.html#callback-functions

ctypes.xFUNCTYPE are another opportunity to advertise decorators.  
Please consider inserting yet another qsort example written as a 
decorator, perhaps as follows.  Or---it could be that I'm slow and the 
average pythonista will figure this out on first read.


@CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
def py_cmp_func(*args):
    (a,b,) = (t[0] for t in args)
    print("py_cmp_func", a, b)
    return a-b

qsort(ia,len(ia),sizeof(c_int),py_cmp_func)

----------
assignee: georg.brandl
components: Documentation
messages: 75515
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: ctypes.xFUNCTYPE are decorators.
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4260>
_______________________________________

From report at bugs.python.org  Wed Nov  5 09:19:22 2008
From: report at bugs.python.org (=?utf-8?q?Peter_=C3=85strand?=)
Date: Wed, 05 Nov 2008 08:19:22 +0000
Subject: [issue4261] The pwd module doesn't distinguish between errors and no
	user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>


New submission from Peter ?strand <astrand at users.sourceforge.net>:

The getpwnam function in the pwd module does not correctly distinguish
between the case when the user does not exist and error
conditions. getpwnam() returns NULL in both cases, the the calling
code needs to check errno to determine if an error occured or not. 

This bug is problematic in conjunction with bug
https://bugzilla.redhat.com/show_bug.cgi?id=470003, since it means
that Pythons getpwnam() will sometimes raise KeyError even for valid
users. How to reproduce:

$ python
Python 2.4.3 (#1, Jan 14 2008, 18:32:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>
>>> pwd.getpwnam("astrand")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: 'getpwnam(): name not found: astrand'
>>>
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>

I was restarting the OpenLDAP server between the first successful call
and the traceback one.

----------
components: Library (Lib)
messages: 75516
nosy: astrand
severity: normal
status: open
title: The pwd module doesn't distinguish between errors and no user
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________

From report at bugs.python.org  Wed Nov  5 09:36:40 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Wed, 05 Nov 2008 08:36:40 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1225874200.62.0.894505267265.issue3588@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

I can add that providing the option:

-mmacosx-version-min=10.4

or setting the anv var

MACOSX_DEPLOYMENT_TARGET=10.4

is it possible to build an extension in MacPython.org too
(without that option there was a problem with some 10.5 libs)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Wed Nov  5 09:55:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 08:55:59 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225846670.9.0.0995631982967.issue4258@psf.upfronthosting.co.za>
Message-ID: <200811050955.31886.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> As for marhsalled data and pyc compatibility, yes that is important to
> consider.

The problem is also that with the 30-bit digit patch, some Python will use 15 
bits whereas some other will use 30 bits. The base in marshal should be the 
same in both cases.

And why 30 bits and not 31 bits, or 63 bits, or 120 bits? We may use other 
bases in the future. That's why I prefer to use a common base like base 256. 
And GMP has functions (mpz_import) to load data in base 256, but it's more 
complicate to load data in base 2^15.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 10:00:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 09:00:28 +0000
Subject: [issue4261] The pwd module doesn't distinguish between errors and no
	user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1225875628.12.0.240517882108.issue4261@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You're right. getpwnam() and getpwuid() have to check errno. A 
different error should be raised, something like:
   RuntimeError("getpwnam(%s) failure: %s" % (name, strerror(errno)))

The grp should also be affected.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________

From report at bugs.python.org  Wed Nov  5 11:54:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Nov 2008 10:54:51 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225882491.92.0.261829844236.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Victor Stinner]
> I saw that you choosed to use the base 2^30 for marshal. For a better 
> portability (be able to use .pyc generated without your patch), you 
> may keep the base 2^15. I implemented that in my GMP patch (manual 
> conversion from/to base 2^15).

Agreed.  I'll fix this so that the .pyc format is unchanged. Thanks!

> And why 30 bits and not 31 bits, or 63 bits, or 120 bits?

Mostly laziness: the change from 15 to 30 bits turned out to be extraordinarily easy.  Note that the longobject.c part of 
the patch does almost nothing except adding a bunch of casts here and there.

31 bits would involve rewriting the powering algorithm, which assumes that PyLong_SHIFT is divisible by 5.  It would gain 
very little over 30 bits, and if Pernici Mario's optimizations are considered (issue 3944) multiplication would likely be 
slower with 31-bit digits than with 30-bit digits.

63 (or 62, or 60) bits is simply too large right now:  you'd need access to a hardware 64 x 64 -> 128 bit multiply to make 
this worth it, and I'd guess there are many fewer platforms that make this easy, though I don't really know.  I know it's 
possible on gcc/x86_64 by making use of the (undocumented) __uint128_t type.  But even where this type is available, base 
2**63 might still be slower than base 2**30. I've done some experiments with multiprecision *decimal* arithmetic in C that 
showed that even on a 64-bit machine, using base 10**9 (i.e. approx 30 bits) was significantly faster than using base 
10**18.

120 bits?  Does GMP even go this far?  I guess part of the attraction is that it's a multiple of 8...

The other obvious choices to consider would be 32 bits (or 16 bits, or 64 bits).  This is possible, and may even be worth 
it, but it would be a *much* bigger effort; most of the algorithms would need to be rewritten.  One problem is again the 
mismatch between C and assembler:  detecting overflow when adding two 32-bit unsigned integers is trivial in x86 assembler, 
but it's not so obvious how to write portable C code that has a decent chance of being compiled optimally on a wide variety 
of compilers. 

I guess my feeling is simply that the 15-bit to 30-bit change seems incredibly easy and cheap: very little code change, and 
hence low risk of accidental breakage.  So if there are indeed significant efficiency benefits (still to be determined) then 
it looks like a clear win to me.

[Gregory Smith]
> (i haven't reviewed your autoconf stuff yet)

The changes to configure and pyconfig.h are just from rerunning autoconf and autoheader;  it's only configure.in that should 
need looking at.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 11:57:29 2008
From: report at bugs.python.org (Mark Seaborn)
Date: Wed, 05 Nov 2008 10:57:29 +0000
Subject: [issue4262] import and compile() do not treat trailing whitespace the
	same
In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
Message-ID: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>


New submission from Mark Seaborn <mseaborn at cmedresearch.com>:

compile() raises a SyntaxError if the source code it is given contains
trailing spaces or a trailing carriage return character, but this does
happen if the same source code is imported or executed.

import subprocess

data = "if True:\n  pass\n  "
filename = "/tmp/test.py"
fh = open(filename, "w")
fh.write(data)
fh.close()
subprocess.check_call(["python", filename])
subprocess.check_call(["python", "-c", "import test"], cwd="/tmp")
compile(data, filename, "exec")


This gives:

Traceback (most recent call last):
  File "whitespace.py", line 11, in <module>
    compile(data, filename, "exec")
  File "/tmp/test.py", line 3
    
SyntaxError: invalid syntax

This also happens if the data is changed to:
data = "if True:\n  pass\r"

----------
components: Interpreter Core
messages: 75521
nosy: mseaborn
severity: normal
status: open
title: import and compile() do not treat trailing whitespace the same
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4262>
_______________________________________

From report at bugs.python.org  Wed Nov  5 12:27:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 11:27:38 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225882491.92.0.261829844236.issue4258@psf.upfronthosting.co.za>
Message-ID: <200811051223.55454.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > And why 30 bits and not 31 bits, or 63 bits, or 120 bits?
>
> Mostly laziness (...)

It was an argument for changing the base used by the mashal :-)

> 31 bits would involve rewriting the powering algorithm, which assumes that
> PyLong_SHIFT is divisible by 5

Powering is an simple algorithm. If it was the division, it would be much 
harder :-) Python stores the sign of the number in the first digit. Because 
of that, we are limited to 15/30 bits. Storing the sign in the size (which 
size? no idea yet) would allows to use a bigger base (31 bits? 63 bits?).

> One problem is again the mismatch between C and assembler:  detecting
> overflow when adding two 32-bit unsigned integers is trivial in x86
> assembler, but it's not so obvious how to write portable C code that has a
> decent chance of being compiled optimally on a wide variety of compilers.

I wrote an example to detect overflows in C on the mailing list. Copy of my 
email:
------------------------------- 8< ----------------------
About 31, 32, 63 or 64 bits: I guess that you want to avoid integer overflow. 
Intel has an "overflow" flag, changed for all instructions. For other CPUs, 
you can use emulate this flag. Example with the type int that I used in my 
GMP patch:

Add:
  int a, b, sum;
  sum = a + b;
  exact = ((a < 0) ^ (b < 0)) || ((a < 0) == (sum < 0));

Substract:
  int a, b, diff;
  diff = a + b;
  exact = ((a < 0) == (b < 0)) || ((a < 0) == (diff < 0));

Multiply:
  int a, b, product;
  if (a == 0 || b == 0) {
     product = 0;  /* exact */
  } else if (a != INT_MIN || (b == 1)) {
     product = a * b;
     exact = (product / b) == a);
  } else {
     /* INT_MIN * -1 = -INT_MIN: overflow */
  }

Divide:
  int a, b, q;
  if (a != INT_MIN || b != -1) {
     q = a / b;   /* exact */
  } else {
     /* INT_MIN / -1 = -INT_MIN: overflow */
  }

Checking overflow may costs more than using a smaller base. Only a benchmark 
can answer ;-)
------------------------------- 8< ----------------------

> I guess my feeling is simply that the 15-bit to 30-bit change seems
> incredibly easy and cheap: very little code change, and hence low risk of
> accidental breakage.

Python has an amazing regression test suite! I used it to fix my GMP patch. We 
can experiment new bases using this suite.

Anyway, i love the idea of using 30 bits instead of 15! Most computer are now 
32 or 64 bits! But it's safe to keep the 15 bits version to support older 
computers or buggy compilers.

I started to work with GIT. You may be interrested to work together on GIT. 
It's much easier to exchanges changeset and play with branches. I will try to 
publish my GIT tree somewhere.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Wed Nov  5 19:23:29 2008
From: report at bugs.python.org (Banesiu Sever)
Date: Wed, 05 Nov 2008 18:23:29 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>


New submission from Banesiu Sever <banesiu.sever at gmail.com>:

In some corner cases io.BufferedWriter raises an io.BlockingIOError
"lying" about the number of characters written.
I've added some tests and a small change to fix this issue.

----------
components: Library (Lib)
files: bw_overage.diff
keywords: patch
messages: 75523
nosy: banesiu.sever
severity: normal
status: open
title: BufferedWriter non-blocking overage
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11945/bw_overage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:29:05 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 Nov 2008 19:29:05 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225913345.11.0.948870608518.issue4233@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Small typo, conveyed to Crys_ in irc.

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:31:33 2008
From: report at bugs.python.org (David Turner)
Date: Wed, 05 Nov 2008 19:31:33 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>


New submission from David Turner <novalis at novalis.org>:

This is a patch to Tom Lee's AST optimization branch.

Python bytecode includes at least one operation which is not directly
accessible from Python code: LIST_APPEND, which pops a value and a list
off the stack and appends the value to the list. This is used in
generating code for list comprehensions:

[x for x in somelist]

generates the following code for the body of the loop:

...
LOAD_FAST 1#a local is generated to hold the new list
LOAD_FAST 2 #the iteration variable, x
LIST_APPEND
...

Whereas if you were to try to write the comprehension directly, you
would get:

LOAD_FAST 1
LOAD_ATTR 0 #an index into the constant table: ?append?
LOAD_FAST 2
CALL_FUNCTION 1 #remove x and the append function from the top of the
stack and push the result of the call
POP_TOP

This is much slower. In part, it?s the cost of doing the attribute
lookup each time, which is why it?s common to see code like a = [] ap =
a.append for x in ?..: ap(x + ?) return a But the function call is
naturally slower than the simpler LIST_APPEND operation. The attached
patch tries to determine statically if a local is all circumstances
holds a list, and if so, generates LIST_APPEND whenever user code would
call local.append.  It?s not perfect ? in particular, I could track
local types on a more fine-grained level than per-function. But it?s a
start.

----------
files: tlee-ast-optimize-appends.diff
keywords: patch
messages: 75525
nosy: novalis_dt
severity: normal
status: open
title: Patch: optimize code to use LIST_APPEND instead of calling list.append
Added file: http://bugs.python.org/file11946/tlee-ast-optimize-appends.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:33:13 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 19:33:13 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225913593.23.0.0312114109551.issue4233@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Applied in r67106 (py3k)

The patch must be backported to 2.6 and 2.7.

----------
assignee:  -> christian.heimes
resolution: accepted -> fixed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:33:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 19:33:45 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225913625.48.0.68408602069.issue4233@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
priority: release blocker -> high
versions: +Python 2.6, Python 2.7 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:41:11 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 19:41:11 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1225914071.44.0.49034922685.issue1210@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Committed in r67107

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:45:46 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 19:45:46 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1225914346.51.0.931827874009.issue3714@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Applied in revision r67108

----------
nosy: +christian.heimes
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Wed Nov  5 20:49:54 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 19:49:54 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1225914594.29.0.203506902442.issue3727@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Patch applied in r67109

----------
nosy: +christian.heimes
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________

From report at bugs.python.org  Wed Nov  5 21:26:18 2008
From: report at bugs.python.org (Ammon Riley)
Date: Wed, 05 Nov 2008 20:26:18 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>


New submission from Ammon Riley <ammon.riley at gmail.com>:

If the disk fills up during the copy operation, shutil.copyfile() leaks
file descriptors. 

The problem is the order of the close() statements in the finally block.
In the event the copy operation runs out of disk space, the fdst.close()
call triggers an IOError, which prevents the fsrc.close() call from being
called. 

Swapping the two calls, so that fsrc is closed first prevents this issue,
though it doesn't solve the underlying problem that IOErrors raised during
the close() operation will prevent the second close() from being called.

A probably better solution:

    def copyfile(src, dst):
        """Copy data from src to dst"""
        if _samefile(src, dst):
            raise Error, "`%s` and `%s` are the same file" % (src, dst)

        fsrc = None
        fdst = None
        try:
            fsrc = open(src, 'rb')
            fdst = open(dst, 'wb')
            copyfileobj(fsrc, fdst)
        finally:
            try:
                if fsrc:
                    fsrc.close()
            finally:
                if fdst:
                    fdst.close()

----------
components: Library (Lib)
messages: 75530
nosy: ammon_riley
severity: normal
status: open
title: shutil.copyfile() leaks file descriptors when disk fills
type: resource usage
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4265>
_______________________________________

From report at bugs.python.org  Wed Nov  5 22:07:27 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Nov 2008 21:07:27 +0000
Subject: [issue4211] frozen packages set an improper __path__ value
In-Reply-To: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>
Message-ID: <1225919247.59.0.351582416918.issue4211@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, I agree with the idea of fixing it for 3.0 and leaving it in for 2.x.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4211>
_______________________________________

From report at bugs.python.org  Wed Nov  5 22:07:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 Nov 2008 21:07:39 +0000
Subject: [issue4262] import and compile() do not treat trailing whitespace the
	same
In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
Message-ID: <1225919259.49.0.281115179595.issue4262@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4262>
_______________________________________

From report at bugs.python.org  Wed Nov  5 22:30:23 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Nov 2008 21:30:23 +0000
Subject: [issue4211] frozen packages set an improper __path__ value
In-Reply-To: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>
Message-ID: <1225920623.16.0.676483942482.issue4211@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I approve of the API change. It's 3.0, dammit!

----------
nosy: +gvanrossum
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4211>
_______________________________________

From report at bugs.python.org  Wed Nov  5 23:49:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 Nov 2008 22:49:44 +0000
Subject: [issue4211] frozen packages set an improper __path__ value
In-Reply-To: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>
Message-ID: <1225925384.95.0.558779765079.issue4211@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67112.

----------
nosy: +benjamin.peterson
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4211>
_______________________________________

From report at bugs.python.org  Thu Nov  6 00:04:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Nov 2008 23:04:44 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225926284.86.0.330951814213.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Following Victor's suggestion, here's an updated patch; same as before, 
except that marshal now uses base 2**15 for reading and writing, 
independently of whether PyLong_SHIFT is 15 or 30.

Added file: http://bugs.python.org/file11947/30bit_longdigit3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 00:09:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 23:09:22 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225926562.11.0.841085978946.issue4258@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11936/30bit_longdigit2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 00:12:11 2008
From: report at bugs.python.org (Kevin Watters)
Date: Wed, 05 Nov 2008 23:12:11 +0000
Subject: [issue4260] ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
Message-ID: <1225926731.76.0.649556386111.issue4260@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

As far as I know, the above code will fail randomly in release mode if 
you have multiple threads running Python, because when ctypes calls out 
to CFUNCTYPE functions, it releases the GIL.

For decorating a python function to give to qsort, maybe you can use 
PYFUNCTYPE?

----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4260>
_______________________________________

From report at bugs.python.org  Thu Nov  6 00:13:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2008 23:13:28 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225926808.5.0.75815096771.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Mark: would it be possible to keep the "2 digits" hack in 
PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 
15". The base 2^15 slow, so don't make it slower :-)

-	/* 2 digits */
-	if (!(ival >> 2*PyLong_SHIFT)) {
-		v = _PyLong_New(2);
-		if (v) {
-			Py_SIZE(v) = 2*sign;
-			v->ob_digit[0] = (digit)ival & PyLong_MASK;
-			v->ob_digit[1] = ival >> PyLong_SHIFT;
-		}
-		return (PyObject*)v;
-	}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 00:21:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Nov 2008 23:21:08 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1225927268.68.0.115206044256.issue3799@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The patch causes three errors:

======================================================================
ERROR: test_anydbm_access (test.test_dbm.TestCase-dbm.dumb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 92, in
test_anydbm_access
    f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
    raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

======================================================================
ERROR: test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 86, in
test_anydbm_keys
    f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
    raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

======================================================================
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.dumb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 80, in
test_anydbm_read
    f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
    raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

----------------------------------------------------------------------
Ran 16 tests in 0.429s

FAILED (errors=3)

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov  6 01:11:06 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Thu, 06 Nov 2008 00:11:06 +0000
Subject: [issue4247] Docs: Provide some examples of "pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225930266.16.0.497825786225.issue4247@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I'm attaching a new version here, which addresses the object call type
comments.

Added file: http://bugs.python.org/file11948/pass-examples-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________

From report at bugs.python.org  Thu Nov  6 02:35:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Nov 2008 01:35:20 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225935320.59.0.330357485173.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> marshal now uses base 2**15 for reading and writing

Yes, it uses base 2**15 but it's not the correct conversion to base 
2**15. You convert each PyLong digit to base 2**15 but not the whole 
number. As a result, the format is different than the current mashal 
version.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 03:32:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Nov 2008 02:32:20 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225938740.06.0.158546795037.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyLong_FromLong() doesn't go into the 1 digit special case for 
negative number. You should use:
	/* Fast path for single-digits ints */
	if (!(abs_ival>>PyLong_SHIFT)) {
		v = _PyLong_New(1);
		if (v) {
			Py_SIZE(v) = sign;
			v->ob_digit[0] = abs_ival;
		}
		return (PyObject*)v;
	}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 04:07:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2008 03:07:51 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1225940871.32.0.729511392065.issue3799@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I don't see enough progress on this issue, and I'm not going to hold up
3.0rc2 for it, so I'm deferring.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov  6 04:14:13 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2008 03:14:13 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1225941253.02.0.251510973304.issue4236@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This seems like a corner case to me.  We should fix it before the final
release, but I don't think it's worth holding up 3.0rc2 for it.  Deferring.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Thu Nov  6 04:18:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Nov 2008 03:18:27 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1225941507.81.0.728628251663.issue2744@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
_______________________________________

From report at bugs.python.org  Thu Nov  6 04:18:42 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2008 03:18:42 +0000
Subject: [issue3775] Update RELNOTES file
In-Reply-To: <1220536018.76.0.0823799232176.issue3775@psf.upfronthosting.co.za>
Message-ID: <1225941522.74.0.631355533792.issue3775@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This is really done, so closing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3775>
_______________________________________

From report at bugs.python.org  Thu Nov  6 04:28:08 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 06 Nov 2008 03:28:08 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1225942088.11.0.133435321706.issue3799@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov  6 05:14:55 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2008 04:14:55 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

The Python 3.0 documentation is broken.  This is blocking the 3.0rc2
release.
I'm too tired right now to figure out what the base problem is.

This was during the ".../release.py --export 3.0rc2" build phase.

pdflatex 'c-api.tex'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./c-api.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(./manual.cls
Document Class: manual 2008/10/18 Document class (Sphinx manual)
(/opt/local/share/texmf-dist/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX document class
(/opt/local/share/texmf-dist/tex/latex/base/size10.clo)))
(/opt/local/share/texmf-dist/tex/latex/base/inputenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/utf8.def
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/ot1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/omsenc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/base/fontenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.def))
(/opt/local/share/texmf-dist/tex/generic/babel/babel.sty
(/opt/local/share/texmf-dist/tex/generic/babel/english.ldf
(/opt/local/share/texmf-dist/tex/generic/babel/babel.def)))
(/opt/local/share/texmf-dist/tex/latex/psnfss/times.sty) (./fncychap.sty)
(./sphinx.sty (/opt/local/share/texmf-dist/tex/latex/base/textcomp.sty
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.def
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/opt/local/share/texmf-dist/tex/latex/fancybox/fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/opt/local/share/texmf-dist/tex/latex/titlesec/titlesec.sty)
(./tabulary.sty
(/opt/local/share/texmf-dist/tex/latex/tools/array.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/opt/local/share/texmf-dist/tex/latex/amsmath/amstext.sty
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/opt/local/share/texmf-dist/tex/latex/base/makeidx.sty)
(/opt/local/share/texmf-dist/tex/latex/framed/framed.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/color.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/color.cfg)
(/opt/local/share/texmf-dist/tex/latex/graphics/pdftex.def))
(/opt/local/share/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
Style option: `fancyvrb' v2.6, with DG/SPQR fixes <1998/07/17> (tvz)
(/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty)
No file fancyvrb.cfg.
) (/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg)))
(/opt/local/share/texmf-dist/tex/plain/pdfcolor/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi
           
?

----------
assignee: georg.brandl
components: Documentation
messages: 75544
nosy: barry, georg.brandl
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python 3.0 docs are broken.
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 06:28:22 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 05:28:22 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225949301.88.0.72938647696.issue4266@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

This is a simple one to fix: remove the second \fi on the incriminated
line in sphinx.sty, line 62. I just checked out Sphinx version 67115 and
retested. With my fix = removal of the second \fi, the make process works.  

The issue also applies to Python 2.6.

----------
nosy: +wplappert
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 08:37:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 07:37:02 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225957022.45.0.612928925798.issue4266@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The issue is not as "easy" as it seems (or at least that's what I believe).

Barry, if you install the xetex package, the build should run fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 08:45:52 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Thu, 06 Nov 2008 07:45:52 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1225957552.34.0.532210895597.issue4264@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Interesting approach.  I was surprised to see the change to the AST, but
I understand why you did it.  I think if the AST optimization approach
works out well, we will want to have some more general mechanism to
communicate these optimization (or other!) hints to the compiler.  It
would suck to have to modify the AST each time we wanted to add a new
optimization.  You and Tom might have better ideas for how best to
achieve that.

I'll make some comments that would need to be addressed, but you might
want to wait making any changes depending on what approach you decide to
take.

The most important missing piece is tests to show that the new code works.

There are various whitespace issues.  Both whitespace only changes that
should be avoided and indentation inconsistencies with the existing code
(or so it appears).  The latter could be the way I'm viewing the file or
existing problems with tabs.

In Python/optimize.c, you need to handle the case where the PyDict_New()
calls fail.  It looks like currently an undetected error can happen in
during construction.  And on destruction it will crash because the
objects will be NULL when calling Py_DECREF.

All calls like PyDict_SetItem(), PyInt_FromLong(), etc need to handle
errors.

I'll need to study the code a lot more to see how well it behaves. 
Tests would help a lot with that.

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Thu Nov  6 08:48:17 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 06 Nov 2008 07:48:17 +0000
Subject: [issue4267] sqlite3 documentation
In-Reply-To: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za>
Message-ID: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Three small changes to sqlite3 documentation:

1) (mostly cosmetic) In the second example, changed what was "a tuple 
of tuples" to "a list of tuples" to follow common practice.

2) "DEFERRED", "IMMEDIATE" and "EXLUSIVE" (possible values for 
Connection.isolation_level) are strings, not module constants, so 
should be surrounded with quotes.

2) The iterdump example is not well written. Currently says:

       con = sqlite3.connect('existing_db.db')
       full_dump = os.linesep.join(con.iterdump())
       f = open('dump.sql', 'w')
       f.writelines(full_dump)
       f.close()

Using os.linesep to join lines to be written to a text file has strange 
results in non-Unix systems; joining the *whole* database dump into a 
big string isn't a good idea; and finally, writelines(some_string) will 
write the text one char at a time (!). 
I've rewritten it as:

       with open('dump.sql', 'w') as f:
           for line in con.iterdump():
               f.write('%s\n' % line)

to take advantage of iterdump's lazy nature.

----------
assignee: georg.brandl
components: Documentation
files: sqlite3.diff
keywords: patch
messages: 75548
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: sqlite3 documentation
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11949/sqlite3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4267>
_______________________________________

From report at bugs.python.org  Thu Nov  6 09:40:26 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 08:40:26 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225960826.61.0.110383376428.issue4266@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

In other words, the various *Tex packages cannot agree on a common syntax?

MiKTeX-pdfTeX 2.7.3147 (1.40.9) (MiKTeX 2.7) also complains about the
double \fi.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 09:54:34 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 08:54:34 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225961674.03.0.638658735219.issue4266@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

And Ubuntu Linux pdflatex complains as well:
/usr/bin/pdflatex from package texlive-latex-base.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 10:01:56 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Nov 2008 09:01:56 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225962116.13.0.309106210293.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Yes, it uses base 2**15 but it's not the correct conversion to base 
> 2**15. You convert each PyLong digit to base 2**15 but not the whole 
> number.

I don't understand:  yes, each base 2**30 digit is converted to a pair 
of base 2**15 digits, and if necessary (i.e., if the top 15 bits of the 
most significant base 2**30 digit are zero) the size is adjusted.  How 
is this not converting the whole number?

> As a result, the format is different than the current mashal version.

Can you give an example of an integer n such that marshal.dumps(n) gives 
you different results with and without the patch?  As far as I can tell, 
I'm getting the same marshal results both with the unpatched version and 
with the patch applied.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 10:11:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 09:11:16 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225962676.24.0.343991563098.issue4266@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> In other words, the various *Tex packages cannot agree on a common syntax?

No, syntax has nothing to do with it. It was a mistake of some sort on
my part. It depends on whether the "ifxetex" latex package is present,
because that already defines the \ifxetex command.

I've now fixed it in Sphinx tip, and copied it to SVN so that Barry
needn't do anything except "make update" before trying to build the docs
again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 10:11:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 09:11:28 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225962688.44.0.975894814487.issue4266@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Thu Nov  6 10:21:04 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Nov 2008 09:21:04 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225963264.66.0.0406834544318.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Other responses...
> It was an argument for changing the base used by the mashal :-)

Ah.  I think I'm with you now.  You're saying that ideally, marshal 
shouldn't have to care about how Python stores its longs:  it should 
just ask some function in longobject.c to provide an already-converted-
to-base-256 representation.  Is that right?

I also find the idea of making the marshal representation base 256 quite 
attractive.  There are already functions in longobject.c that could be 
used for this: _PyLong_{From,As}ByteArray.  And then you wouldn't need 
to touch marshal.c when swapping the GMP version of longobject.c in and 
out.

> Python stores the sign of the number in the first digit. Because 
> of that, we are limited to 15/30 bits.

No: the sign is stored in the size:  if v is a PyLongObject then 
ABS(Py_SIZE(v)) gives the number of digits in the absolute value of the 
integer represented by v, and the sign of Py_SIZE(v) gives the sign of 
the integer.

> would it be possible to keep the "2 digits" hack in 
> PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 
> 15". The base 2^15 slow, so don't make it slower :-)

Why don't we leave this kind of micro-optimization out until we've got 
some benchmarks.  (I'm also tempted to get rid of the long_mul fast path 
for now.)

> PyLong_FromLong() doesn't go into the 1 digit special case for 
> negative number.

Well spotted!  Yes, this should be fixed.  I have a nasty feeling that I 
was responsible for introducing this bug some time ago...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 10:48:12 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 06 Nov 2008 09:48:12 +0000
Subject: [issue4268] functions in email package listed under wrong module
In-Reply-To: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za>
Message-ID: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Functions message_from_string and message_from_file are documented as 
belonging to the email.parser module, but in fact they live at the top 
of the email package.

The .rst source looks fine, but the rendered html says  
`email.parser.message_from_string`. 
http://docs.python.org/library/email.parser.html#parser-class-api

Perhaps it's the `module:: email.parser` directive at the top?

A similar problem is in email.mime.rst; all the documented classes are 
exposed at the top of the email package (i.e. should be email.MIMEBase, 
not email.mime.MIMEBase)

----------
assignee: georg.brandl
components: Documentation
messages: 75554
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: functions in email package listed under wrong module
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4268>
_______________________________________

From report at bugs.python.org  Thu Nov  6 11:18:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 10:18:14 +0000
Subject: [issue4268] functions in email package listed under wrong module
In-Reply-To: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za>
Message-ID: <1225966694.26.0.618320658046.issue4268@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r67117.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4268>
_______________________________________

From report at bugs.python.org  Thu Nov  6 11:19:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 10:19:18 +0000
Subject: [issue4267] sqlite3 documentation
In-Reply-To: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za>
Message-ID: <1225966758.24.0.919679526843.issue4267@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r67118.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4267>
_______________________________________

From report at bugs.python.org  Thu Nov  6 11:21:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 10:21:00 +0000
Subject: [issue4245] threading documentation: reorder sections
In-Reply-To: <1225472614.88.0.0607016795949.issue4245@psf.upfronthosting.co.za>
Message-ID: <1225966860.4.0.792258004915.issue4245@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree -- fixed in r67119.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4245>
_______________________________________

From report at bugs.python.org  Thu Nov  6 11:39:40 2008
From: report at bugs.python.org (Berend-Jan Wever)
Date: Thu, 06 Nov 2008 10:39:40 +0000
Subject: [issue4269] Spaces not showing correctly in "split()" documentation
	on http://www.python.org/doc/2.5.2/lib/string-methods.html
In-Reply-To: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za>
Message-ID: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za>


New submission from Berend-Jan Wever <berendjanwever at gmail.com>:

Part of the text of the online documentation for the string.split() method:

<snip>
If sep is not specified or is None, a different splitting algorithm is
applied. First, whitespace characters (spaces, tabs, newlines, returns,
and formfeeds) are stripped from both ends. Then, words are separated by
arbitrary length strings of whitespace characters. Consecutive
whitespace delimiters are treated as a single delimiter ("'1 2
3'.split()" returns "['1', '2', '3']"). Splitting an empty string or a
string consisting of just whitespace returns an empty list.
</snip>

As you may have noticed, there should be multiple spaces in ("'1 2
3'.split()". If you look at the HTML source you will see that they are
there. However, because browsers rendering HTML by default replace
multiple space with a single space, they are not visible in the
documentation. This should be addressed by either using <PRE></PRE>
around the text to preserve formatting or by replacing all instances of
multiple spaces with instances of "&nbsp;". I suspect this problem may
be elsewhere in the documentation as well.

----------
assignee: georg.brandl
components: Documentation
messages: 75558
nosy: SkyLined, georg.brandl
severity: normal
status: open
title: Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4269>
_______________________________________

From report at bugs.python.org  Thu Nov  6 12:17:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Nov 2008 11:17:33 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225970253.25.0.0148451521317.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a pybench comparison, on OS X 10.5/Core 2 Duo/gcc 4.0.1 (32-bit 
non-debug build of the py3k branch).  I got this by doing:

[create clean build of py3k branch]
dickinsm$ ./python.exe Tools/pybench/pybench.py -f bench_unpatched
[apply 30bit patch and rebuild]
dickinsm$ ./python.exe Tools/pybench/pybench.py -c bench_unpatched

Highlights: SimpleLongArithmetic: around 10% faster.
            SimpleComplexArithmetic: around 16% slower!
            CompareFloatsIntegers: around 20% slower.

I'll investigate the slowdowns.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 12:29:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Nov 2008 11:29:05 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225970945.5.0.275685497518.issue4258@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Added file: http://bugs.python.org/file11950/pybench_results.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 12:30:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Nov 2008 11:30:58 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225971058.89.0.4974679456.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'll investigate the slowdowns

The problem may comes from int64_t on 32 bits CPU. 32x32 -> 64 may be 
emulated on your CPU and so it's slower. I improved your patch to make 
it faster, but I lost all my work because of a misuse of GIT... As I 
remember:
 - I fixed PyLong_FromLong() for small negative integer
 - I unrolled the loop in PyLong_FromLong(): the loop is at least 
called twice (the number has 2 digits or more)
 - I added special code for operations on two numbers of 1 digit 
(each) for long_add(), long_mul(), long_div(), long_bitwise(), etc.
 - and I don't remember the other changes...

Oh, I have an old patch. I will attach it to this message. About 
speed, it was:
 * unpatched: 20600..20900 pystones
 * your patch: 19900..20100 pystones
 * + my changes: 20200..20400 pytones

Added file: http://bugs.python.org/file11951/optimize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 13:47:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Nov 2008 12:47:19 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225971058.89.0.4974679456.issue4258@psf.upfronthosting.co.za>
Message-ID: <200811061346.45179.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I wrote a patch to compute stat about PyLong function calls.

make (use setup.py):

PyLong_FromLong: 168572 calls, min=( 0,  ), avg=(1.4,    ), max=(  3,    )
long_bool:        48682 calls, min=( 0,  ), avg=(0.2,    ), max=(  2,    )
long_add:         39527 calls, min=( 0, 0), avg=(0.9, 1.0), max=(  2,   3)
long_compare:     39145 calls, min=( 0, 0), avg=(1.2, 1.1), max=(  3,   3)
PyLong_AsLong:    33689 calls, min=( 0,  ), avg=(0.9,    ), max=( 45,    )
long_sub:         13091 calls, min=( 0, 0), avg=(0.9, 0.8), max=(  1,   1)
long_bitwise:      4636 calls, min=( 0, 0), avg=(0.8, 0.6), max=(  2,   2)
long_hash:         1097 calls, min=( 0,  ), avg=(0.9,    ), max=(  3,    )
long_mul:           221 calls, min=( 0, 0), avg=(0.8, 1.1), max=(  2,   2)
long_invert:        204 calls, min=( 0,  ), avg=(1.0,    ), max=(  1,    )
long_neg:            35 calls, min=( 1,  ), avg=(1.0,    ), max=(  1,    )
long_format:          3 calls, min=( 0,  ), avg=(0.7,    ), max=(  1,    )
long_mod:             3 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)
long_pow:             1 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)

pystone:

PyLong_FromLong:1587652 calls, min=( 0,  ), avg=(1.0,    ), max=(  3,    )
long_add:        902487 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  2,   2)
long_compare:    651165 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  3,   3)
PyLong_AsLong:   252476 calls, min=( 0,  ), avg=(1.0,    ), max=(  2,    )
long_sub:        250032 calls, min=( 1, 0), avg=(1.0, 1.0), max=(  1,   1)
long_bool:       102655 calls, min=( 0,  ), avg=(0.5,    ), max=(  1,    )
long_mul:        100015 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  1,   2)
long_div:         50000 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)
long_hash:          382 calls, min=( 0,  ), avg=(1.1,    ), max=(  2,    )
long_bitwise:       117 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  1,   2)
long_format:          1 calls, min=( 2,  ), avg=(2.0,    ), max=(  2,    )

min/avg/max are the integer digit count (minimum, average, maximum).

What can we learn from this numbers?

PyLong_FromLong(), long_add() and long_compare() are the 3 most common 
operations on integers. 

Except PyLong_FromLong(), long_compare() and long_format(), arguments of the 
functions are mostly in range [-2^15; 2^15].

Biggest number is a number of 45 digits: maybe just one call to long_add(). 
Except this number/call, the biggest numbers have between 2 and 3 digits. 

long_bool() is never called with number bigger than 2 digits.

long_sub() is never called with number bigger than 1 digit!

Added file: http://bugs.python.org/file11952/long_stat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: long_stat.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081106/d885ed00/attachment.txt>

From report at bugs.python.org  Thu Nov  6 14:24:25 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Nov 2008 13:24:25 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <200811061346.45179.victor.stinner@haypocalc.com>
Message-ID: <200811061423.54059.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

And now the stat of Python patched with 30bit_longdigit3.patch.

min/avg/max are now the number of bits which gives better 
informations. "bigger" is the number of arguments which are bigger than 1 
digit (not in range [-2^30; 2^30]).

make
====

_FromLong:   169734 calls, min=( 0,  ), avg=(11.6,     ), max=(  32,     )
  \--> bigger=31086
long_bool:    48772 calls, min=( 0,  ), avg=( 0.3,     ), max=(  24,     )
long_add:     39685 calls, min=( 0, 0), avg=( 6.5,  3.5), max=(  19,   32)
  \--> bigger=1
long_compare: 39445 calls, min=( 0, 0), avg=( 9.3,  8.4), max=(  31,   33)
  \--> bigger=10438
_AsLong:      33726 calls, min=( 0,  ), avg=( 4.9,     ), max=(1321,     )
  \--> bigger=10
long_sub:     13285 calls, min=( 0, 0), avg=( 7.6,  5.6), max=(  13,   13)
long_bitwise:  4690 calls, min=( 0, 0), avg=( 1.7,  1.9), max=(  16,   16)
long_hash:     1097 calls, min=( 0,  ), avg=( 8.1,     ), max=(  33,     )
  \--> bigger=4
long_mul:       236 calls, min=( 0, 0), avg=( 1.3,  5.4), max=(  17,   17)
long_invert:    204 calls, min=( 0,  ), avg=( 2.4,     ), max=(   3,     )
long_neg:        35 calls, min=( 1,  ), avg=( 4.3,     ), max=(   7,     )
long_format:      3 calls, min=( 0,  ), avg=( 2.0,     ), max=(   4,     )
long_mod:         3 calls, min=( 1, 2), avg=( 1.7,  2.0), max=(   2,    2)
long_pow:         1 calls, min=( 2, 6), avg=( 2.0,  6.0), max=(   2,    6)

Notes about make:
 - PyLong_FromLong(), long_compare(), PyLong_AsLong() and long_hash() 
   gets integers not in [-2^30; 2^30] which means that all other functions
   are only called with arguments of 1 digit!
 - PyLong_FromLong() gets ~30.000 (18%) integers of 32 bits
 - global average integer size is between 0.3 and 11.6 (~6.0 bits?)
 - There are 41.500 (12%) big integers on ~350.000 integers

pystone
=======

_FromLong:   1504983 calls, min=( 0,  ), avg=( 5.1,     ), max=(  31,     )
  \--> bigger=14
long_add:     902487 calls, min=( 0, 0), avg=( 3.9,  2.4), max=(  17,   17)
long_compare: 651165 calls, min=( 0, 0), avg=( 1.7,  1.4), max=(  31,   31)
  \--> bigger=27
_AsLong:      252477 calls, min=( 0,  ), avg=( 4.6,     ), max=(  16,     )
long_sub:     250032 calls, min=( 1, 0), avg=( 4.0,  1.6), max=(   7,    7)
long_bool:    102655 calls, min=( 0,  ), avg=( 0.5,     ), max=(   7,     )
long_mul:     100015 calls, min=( 0, 0), avg=( 2.5,  2.0), max=(   4,   16)
long_truediv:  50000 calls, min=( 4, 2), avg=( 4.0,  2.0), max=(   4,    2)
long_hash:       382 calls, min=( 0,  ), avg=( 8.1,     ), max=(  28,     )
long_bitwise:    117 calls, min=( 0, 0), avg=( 6.7,  6.6), max=(  15,   16)
long_format:       1 calls, min=(16,  ), avg=(16.0,     ), max=(  16,     )

Notes about pystone:
 - very very few numbers are bigger than one digit: 41 / ~4.000.000
 - global average integer size is between 0.5 and 6.7 (~3.0 bits?)
 - the biggest number has only 31 bits (see long_compare)

Short summary:
 - pystone doesn't use big integer (1 big integer for 100.000 integers)
   => don't use pystone!
 - the average integer size is around 3 or 6 bits, which means that most
   integers can be stored in 8 bits (-255..255)
   => we need to focus on the very small numbers
   => base 2^30 doesn't help for common Python code, it only helps programs
      using really big numbers (128 bits or more?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Thu Nov  6 14:34:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Nov 2008 13:34:51 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225978491.66.0.626111845294.issue4263@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good. 

I was first surprised by the fact that e.characters_written is not used
in the write() method; but _flush_unlocked() already adjusts the
_write_buf according to the original e.characters_written raised by the
underlying raw file. Everything is fine.

I suggest however to add some tests around the first "except
BlockingIOError". This would answer the question:
    # XXX Why not just let the exception pass through?
For example, I modified a function in your patch:

    def testWriteNonBlockingOverage(self):
        raw = MockNonBlockWriterIO((-1, -2))
        [...]

        # Subsequent calls to write() try to flush the raw file.
        try:
            bufio.write(b"x")
        except io.BlockingIOError as e:
            # Two more chars were written at the raw level
            self.assertEqual(bufio._write_buf, write_buf[2:])
            # But write() did not accept anything.
            self.assertEqual(e.characters_written, 0)
        else:
            self.fail("BlockingIOError not raised")

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Thu Nov  6 16:05:51 2008
From: report at bugs.python.org (Banesiu Sever)
Date: Thu, 06 Nov 2008 15:05:51 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225983951.75.0.702782836364.issue4263@psf.upfronthosting.co.za>


Banesiu Sever <banesiu.sever at gmail.com> added the comment:

Thanks for your review, here's a new patch.
I've added a new test for the pre-flush condition and made the comments
less cryptic.

Added file: http://bugs.python.org/file11953/bw_overage2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Thu Nov  6 17:05:25 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 06 Nov 2008 16:05:25 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225987525.39.0.794777661979.issue4263@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

We have discussed this bug in the python developer chat yesterday. I
decided to wait until after the 3.0.0 release. The problem is not
critical enough for 3.0.0. I like to keep the amount of changes during
the RC phase to a minimum.

----------
nosy: +christian.heimes
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Thu Nov  6 17:43:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Nov 2008 16:43:17 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225989797.59.0.214042609727.issue4263@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I do concur with the desire to restrict changes during RC phase. Do this
also mean that merges from trunk will be reduced to the strict minimum?
No global merge, only on a revision basis after review.

In this case we could apply the patch to the trunk, and let a future
global merge propagate the change to py3k.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:25:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 06 Nov 2008 17:25:05 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1225992305.63.0.0978224547155.issue4120@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Should this patch be applied to 3.0 before the next RC lands? Barry
hasn't released RC2 yet.

----------
nosy: +christian.heimes
type:  -> compile error
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:30:34 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Nov 2008 17:30:34 +0000
Subject: [issue3166] Make conversions from long to float correctly rounded.
In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>
Message-ID: <1225992634.77.0.711663565833.issue3166@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

I noticed that you replaced a call to _PyLong_AsScaledDouble with your 
round to nearest algorithm.  I wonder if _PyLong_AsScaledDouble itself 
would benefit from your change.  Currently it is used in PyLong_AsDouble 
and long_true_divide.  I would think that long_true_divide would be more 
accurate if longs were rounded to the nearest float.

I also wonder whether round to nearest float can be implemented without 
floating point arithmetics.  I would think round towards zero should be 
a simple matter of extracting an appropriate number of bits from the 
long and round to nearest would at most require a long addition.

I believe _PyLong_AsScaledDouble is written the way it is to support 
non-IEEE floating formats, but I am not sure that your algorithm would 
always return the nearest float on an arbitrary non-IEEE platform.

Maybe it would be worthwhile to provide a simple IEEE specific code with   
well specified semantics for both PyLong_AsDouble and long_true_divide, 
but fall back to the current code on non-IEEE platforms.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3166>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:30:44 2008
From: report at bugs.python.org (Mikhail Terekhov)
Date: Thu, 06 Nov 2008 17:30:44 +0000
Subject: [issue4270] struct module: pack/unpack and byte order on x86_64
In-Reply-To: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za>
Message-ID: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov <termim at gmail.com>:

pack/unpack behavior changes unexpectedly depending on the byte order:

l:/tmp >uname -pmiovs
Linux #1 SMP 2008-10-14 22:17:43 +0200 x86_64 x86_64 x86_64 GNU/Linux
l:/tmp >python
python
Python 2.5.1 (r251:54863, Aug  1 2008, 00:35:20) 
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
import struct
>>> struct.pack(">L",0xdeadbeef)
struct.pack(">L",0xdeadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0xdeadbeef)
struct.pack("L",0xdeadbeef)
'\xef\xbe\xad\xde\x00\x00\x00\x00'
>>> struct.pack("<L",0xdeadbeef)
struct.pack("<L",0xdeadbeef)
'\xef\xbe\xad\xde'
>>> 

The length of the result above is 8 when no byte order is specified
and 4 when it is.

Another example:

>>> struct.pack("L",0xdeadbeef00000000)
'\x00\x00\x00\x00\xef\xbe\xad\xde'
>>> struct.pack("<L",0xdeadbeef00000000)
'\x00\x00\x00\x00'
>>> struct.pack("!L",0xdeadbeef00000000)
'\x00\x00\x00\x00'
>>> struct.pack("!L",0x12345678deadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0x12345678deadbeef)
'\xef\xbe\xad\xdexV4\x12'
>>> 

Last results look strange.

----------
components: Library (Lib)
messages: 75569
nosy: mmm77
severity: normal
status: open
title: struct module: pack/unpack and byte order on x86_64
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4270>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:31:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 06 Nov 2008 17:31:18 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1225992678.73.0.476084213371.issue4120@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed Python-2.6-no.manifest.in.pyd.diff as r67120,
r67121, and r67122. Thanks for the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:31:52 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 17:31:52 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

I tried to check the tracker for an existing issue with the conversion
tool, but I could not find one. I am using the "python2.6
Python2.6/Tools/scripts/2to3 -w -v ." command to convert existing Python
scripts to Python3.0.

I made two observations:

1. Tkinter
   from Tkinter import (N, E, ...) does NOT get translated to
   from tkinter import (N, E, ...)

2. 2to3 produces relative imports for stuff which lives in the same
directory, but trying to compile the stuff, I get the error:

org: from global_stuff                import *
2t3: from .global_stuff                import *
ValueError: Attempted relative import in non-package

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 75571
nosy: wplappert
severity: normal
status: open
title: conversion tool does not fix "from Tkinter import N,E"
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Thu Nov  6 18:59:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Nov 2008 17:59:33 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225994373.24.0.963609813757.issue4271@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The relative import problem has been fixed that will be released in 2.6.1.

----------
nosy: +benjamin.peterson
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:04:45 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 18:04:45 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225994685.18.0.684402708405.issue4271@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

and it is also fixed in 3.0rc1: I reran the conversion, but issue 2
still persists,

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:05:55 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 18:05:55 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225994755.89.0.497730101008.issue4271@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

Sorry, issue 1 still persists: 
>From Tkinter import (bla,blah, blahh)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:06:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Nov 2008 18:06:41 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225994801.83.0.80933795566.issue4271@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:15:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 18:15:12 +0000
Subject: [issue4269] Spaces not showing correctly in "split()" documentation
	on http://www.python.org/doc/2.5.2/lib/string-methods.html
In-Reply-To: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za>
Message-ID: <1225995312.36.0.698972888339.issue4269@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is fixed in the new docs, see
<http://docs.python.org/library/stdtypes#str.split>.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4269>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:21:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 06 Nov 2008 18:21:04 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1225995664.87.0.811651002413.issue4236@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

PyModule_Create2 might be new, but the warning certainly is not - for
2.x, it lives in Py_InitModule4. Indeed, I can reproduce the problem
with 2.7a0, replacing the import of warnings with an import of imp.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:48:31 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 06 Nov 2008 18:48:31 +0000
Subject: [issue4260] ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225926731.76.0.649556386111.issue4260@psf.upfronthosting.co.za>
Message-ID: <49133BFD.9070101@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

[David Lambert]
> > @CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
> > def py_cmp_func(*args):
> >     (a,b,) = (t[0] for t in args)
> >     print("py_cmp_func", a, b)
> >     return a-b
> > 
> > qsort(ia,len(ia),sizeof(c_int),py_cmp_func)

[Kevin Watters]
> > As far as I know, the above code will fail randomly in release mode if 
> > you have multiple threads running Python, because when ctypes calls out 
> > to CFUNCTYPE functions, it releases the GIL.
> > 
> > For decorating a python function to give to qsort, maybe you can use 
> > PYFUNCTYPE?

Kevin is wrong - the code is perfect!  Sure does calling a CFUNCTYPE instance
release the GIL, but ctypes aquires the GIL again before executing the python
code in the wrapped py_cmp_func above.

I guess that using PYFUNCTYPE instead would possibly crash because the call to
'qsort' releases the GIL, and the PYFUNCTYPE instance assumes the GIL but does not
acquire it.

But I have no time to work on the docs, sorry.

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4260>
_______________________________________

From report at bugs.python.org  Thu Nov  6 19:49:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2008 18:49:44 +0000
Subject: [issue4247] Docs: Provide some examples of "pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225997384.16.0.736283395711.issue4247@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r67123. Thanks!

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________

From report at bugs.python.org  Thu Nov  6 20:49:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 06 Nov 2008 19:49:52 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1226000992.11.0.111911907018.issue4120@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In r67125, r67126, r67127, r67128, r67129, I removed the mt.exe
invocation from tcl and tk, and removed the DLLs CRT manifest from the
installer.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Nov  6 21:47:10 2008
From: report at bugs.python.org (Jacques Frechet)
Date: Thu, 06 Nov 2008 20:47:10 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>


New submission from Jacques Frechet <jfrechet at users.sourceforge.net>:

The gzip header defined in RFC 1952 includes a mandatory "MTIME" field,
originally intended to contain the modification time of the original
uncompressed file.  It is often ignored when decompressing, though
gunzip (for example) uses it to set the modification time of the output
file if applicable.

The Python gzip module always sets the MTIME field to the current time,
and always discards MTIME when decompressing.  As a result, compressing
the same string using gzip produces different output every time.  For
certain applications, especially those involving comparisons or
cryprographic signing of binary files, these spurious changes can be
quite inconvenient.  Aside from the MTIME field, the gzip module already
produces entirely deterministic output.

I'm attaching a patch which adds an optional "mtime" argument to the
GzipFile class, giving the caller the option of providing a timestamp
when compressing.  Default behavior is unchanged.  I've included updated
documentation and three new test cases in the patch.

In order to facilitate testing, the patch also includes code to set the
"mtime" member of the GzipFile instance when decompressing.  The first
test case uses the new member to ensure that the timestamp given to the
GzipFile constructor is preserved correctly.  The second test checks for
specific values in the entire gzip header (not just the MTIME field) by
reading the compressed file directly, examining individual fields in a
(relatively) flexible way.  The third compares the entire compressed
stream against a predetermined sequence of bytes in a relatively
inflexible way.  All tests pass on my AMD64 box, and I expect them all
to pass on all supported platforms without any problems.  However, If
anybody is concerned that any of the tests sound like they might be too
brittle, I'm certainly not overly attached to them.

If anyone has any further suggestions, I'd be delighted to submit a new
patch.

Thanks!

Jacques

----------
components: Library (Lib)
files: gzip-mtime-py3k.patch
keywords: patch
messages: 75580
nosy: jfrechet
severity: normal
status: open
title: set timestamp in gzip stream
type: feature request
Added file: http://bugs.python.org/file11954/gzip-mtime-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Thu Nov  6 21:49:09 2008
From: report at bugs.python.org (Jacques Frechet)
Date: Thu, 06 Nov 2008 20:49:09 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226004549.31.0.70548545291.issue4272@psf.upfronthosting.co.za>


Changes by Jacques Frechet <jfrechet at users.sourceforge.net>:


Added file: http://bugs.python.org/file11955/gzip-mtime-2.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Thu Nov  6 22:23:30 2008
From: report at bugs.python.org (Jacques Frechet)
Date: Thu, 06 Nov 2008 21:23:30 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226006610.08.0.791622059044.issue4272@psf.upfronthosting.co.za>


Jacques Frechet <jfrechet at users.sourceforge.net> added the comment:

This discussion of the problem and possible workarounds might also be of
interest:

 
http://stackoverflow.com/questions/264224/setting-the-gzip-timestamp-from-python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Thu Nov  6 23:00:03 2008
From: report at bugs.python.org (darrenr)
Date: Thu, 06 Nov 2008 22:00:03 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>


New submission from darrenr <python-roundup at dranalli.com>:

The profile module creates a reference cycle. See attached session.

----------
components: Library (Lib)
files: profile_cycle.txt
messages: 75582
nosy: darrenr
severity: normal
status: open
title: cycle created by profile.run
type: resource usage
versions: Python 2.4
Added file: http://bugs.python.org/file11956/profile_cycle.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Thu Nov  6 23:05:34 2008
From: report at bugs.python.org (darrenr)
Date: Thu, 06 Nov 2008 22:05:34 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226009134.58.0.594644499564.issue4273@psf.upfronthosting.co.za>


darrenr <python-roundup at dranalli.com> added the comment:

The profile module creates a reference cycle. See attached session.

Note: cycle can be broken by deleting reference to 'dispatcher' on 
profile.Profile() instance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Thu Nov  6 23:30:42 2008
From: report at bugs.python.org (David Turner)
Date: Thu, 06 Nov 2008 22:30:42 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226010642.84.0.95617643843.issue4264@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

Neal Norwitz <nnorwitz at gmail.com> added the comment:
> 
> Interesting approach.  I was surprised to see the change to the AST, 
> but I understand why you did it.  I think if the AST optimization 
> approach works out well, we will want to have some more general 
> mechanism to communicate these optimization (or other!) hints to the 
> compiler.  It would suck to have to modify the AST each time we 
> wanted to add a new optimization.  You and Tom might have better 
> ideas for how best to achieve that.

I really didn't want to have to change the AST.  The problem was that
there was a feature of the Python bytecode which was not representable
in Python source code.  I don't anticipate future optimizations
requiring changes to the AST, because I now believe every important
feature of the bytecode is representable in the AST.  The one exception
might be if we have a need for arbitrary jumps.  I don't think that
would be useful, but it might conceivably.  In that case, we would need
Goto and Label AST nodes.  

The thing that struck me as ugly was the idea that there's one object
(the optimizer) that knows everything about all optimization operations.
 This seems like a great case for the visitor pattern.  The optimizer
ought to have a list of functions to call for each type of AST node,
each with some private storage space.  But I didn't want to make that
kind of dramatic change without consulting with Tom.

> I'll make some comments that would need to be addressed, but you might
> want to wait making any changes depending on what approach you decide 
> to take.
> 
> The most important missing piece is tests to show that the new code 
> works.

> There are various whitespace issues.  Both whitespace only changes 
> that should be avoided and indentation inconsistencies with the 
> existing code (or so it appears).  The latter could be the way I'm 
> viewing the file or existing problems with tabs.

Fixed, I think.  The original code appears to be somewhat inconsistent
between files in its uses of spaces/tabs, but I think I have now matched
the style of each file.

> In Python/optimize.c, you need to handle the case where the 
> PyDict_New() calls fail.  It looks like currently an undetected error
> can happen during construction.  And on destruction it will crash 
> because the objects will be NULL when calling Py_DECREF.
 
Fixed.  

> All calls like PyDict_SetItem(), PyInt_FromLong(), etc need to handle
> errors.

I'm not exactly sure which "etc" need to handle errors.  Py*_As*? 
Anyway, I changed the ones you mentioned.

> I'll need to study the code a lot more to see how well it behaves. 
> Tests would help a lot with that.

I've added a few.

Added file: http://bugs.python.org/file11957/tlee-ast-optimize-appends-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 00:28:19 2008
From: report at bugs.python.org (David Turner)
Date: Thu, 06 Nov 2008 23:28:19 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226014099.34.0.0149277801862.issue4264@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

Actually, I just noticed a case where the code would do the wrong thing.
 I fixed it and added a test for it.

Added file: http://bugs.python.org/file11958/tlee-ast-optimize-appends-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 01:19:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Nov 2008 00:19:18 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226017158.56.0.019596081759.issue4272@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I considered using a datetime.datetime object instead. But it make more 
sense to use a time_t number, like os.stat() and time.time().

About the tests on the gzip format details: I am not an expert of the 
gzip format, but are we sure that the compressed data will always be the 
same?
Otherwise the patch is fine.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Fri Nov  7 01:28:43 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Nov 2008 00:28:43 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226017723.34.0.143247909323.issue4264@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> I really didn't want to have to change the AST.  The problem was that
> there was a feature of the Python bytecode which was not representable
> in Python source code. 

FWIW, I see exposing bytecodes as an anti-pattern that locks in a
particular implementation in a way that makes it hard to change and hard
to port to other Python implementations.  The current bound method
approach works fine.  Don't really see enough payoff to justify the
extra code and maintenance.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 02:26:37 2008
From: report at bugs.python.org (Jacques Frechet)
Date: Fri, 07 Nov 2008 01:26:37 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226021197.3.0.19541982011.issue4272@psf.upfronthosting.co.za>


Jacques Frechet <jfrechet at users.sourceforge.net> added the comment:

I'm no expert either.  The output certainly seems to be deterministic
for a given version of zlib, and I'm not aware of any prior versions of
zlib that produce different compressed output.  However, my
understanding is that there is more than one possible compressed
representation of a given uncompressed input, so it's entirely possible
that a past or future version of zlib might produce compressed output
that is different while remaining interoperable.  I have no idea whether
the zlib people care specifically about producing identical compressed
output across versions or not.  It might be a big deal to them, or they
might have other priorities.

I included the third test because I am guessing that the compressed
output probably won't change very soon, and that if it does, it might be
interesting to know that it changed.  If that sounds to you like it
might be more trouble than it's worth, then I think the right thing to
do would be to simply get rid of the third test and keep the first two.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Fri Nov  7 02:48:25 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Nov 2008 01:48:25 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1226022505.33.0.480862133361.issue4236@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Strange, I can't reproduce the problem with any Python version. Even
py3k doesn't crash with either "import imp" and "import warnings".

$ cat ../issue4236.py
class Crasher(object):
    def __del__(self):
        print("__del__ called")
        import imp

crasher = Crasher()

$ python2.4 issue4236.py
__del__ called
Exception exceptions.ImportError: 'No module named imp' in <bound method
Crasher.__del__ of <__main__.Crasher object at 0x7f0e6c4e44d0>> ignored

$ python2.5 issue4236.py
__del__ called
Exception exceptions.ImportError: 'No module named imp' in <bound method
Crasher.__del__ of <__main__.Crasher object at 0x7fbbde5ef1d0>> ignored

$ python2.6 issue4236.py
__del__ called
Exception ImportError: 'No module named imp' in <bound method
Crasher.__del__ of <__main__.Crasher object at 0x7f3d810dbf90>> ignored

$ py3k/python issue4236.py
__del__ called
Exception ImportError: 'No module named imp' in <bound method
Crasher.__del__ of <__main__.Crasher object at 0x9ab3e0>> ignored

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Fri Nov  7 03:07:41 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 02:07:41 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1226023661.23.0.284260932168.issue4266@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Sorry, but this is still not fixed:

tnow using/cmdline Exception occurred:
  File
"/private/tmp/py3k/dist/Python-3.0rc2/Doc/tools/docutils/parsers/rst/states.py",
line 2055, in run_directive
    % (type_name, i, result[i]))
AssertionError: Directive "seealso" returned non-Node object (index 0):
[<system_message: <paragraph...><literal_block...>>, <paragraph:
<pending_xref...>>]
The full traceback has been saved in
/var/folders/by/bycjwwYpGcm-aejnq3kFc++++TI/-Tmp-/sphinx-err-uh9riS.log,
if you want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-dev at googlegroups.com. Thanks!
make[1]: *** [build] Error 1
make: *** [dist] Error 2


Verified on both OS X and Ubuntu Intrepid.  Verified on irc by Christian
Heimes.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:07:26 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 03:07:26 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1226027246.44.0.635240169785.issue4266@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r67136 is a workaround found by Christian.  We'll go with this for the
3.9rc2 release and make this a deferred blocker for a proper fix for the
next rc.

----------
priority: release blocker -> deferred blocker
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:13:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Nov 2008 03:13:52 +0000
Subject: [issue4274] Finish what's new in 3.0
In-Reply-To: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za>
Message-ID: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The what's new section of the 3.0 docs need lots of extra care. It's
short and it doesn't list all PEPs and important changes. Since lot's of
people are coming from 2.5 it may also be a wise idea to list relevant
2.5->2.6 changes.

----------
assignee: akuchling
components: Documentation
messages: 75592
nosy: akuchling, barry, christian.heimes, georg.brandl, gvanrossum
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Finish what's new in 3.0
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4274>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:14:25 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 03:14:25 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1226027665.77.0.091916032771.issue2306@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Raising to deferred blocker.  This will definitely block 3.0rc3.

----------
nosy: +barry
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:19:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Nov 2008 03:19:52 +0000
Subject: [issue4274] Finish what's new in 3.0
In-Reply-To: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za>
Message-ID: <1226027992.39.0.1100161927.issue4274@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

See #2306.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4274>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:29:48 2008
From: report at bugs.python.org (Don MacMillen)
Date: Fri, 07 Nov 2008 03:29:48 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>


New submission from Don MacMillen <don at macmillen.net>:

code examples in socketserver do not run in py3k
Obvious errors with print stmt (not function call)
Less obvious errors with socket.send that does not
accept str type (bytearray works fine). Client example
below shows problems.

import socket
import sys

HOST, PORT = "localhost", 9999
data = " ".join(sys.argv[1:])

# Create a socket (SOCK_STREAM means a TCP socket)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Connect to server and send data
sock.connect((HOST, PORT))
sock.send(data + "\n")

# Receive data from the server and shut down
received = sock.recv(1024)
sock.close()

print "Sent:     %s" % data
print "Received: %s" % received

----------
messages: 75595
nosy: macd
severity: normal
status: open
title: socketserver example code not correctly ported to py3k
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:51:42 2008
From: report at bugs.python.org (Jan Schreuder)
Date: Fri, 07 Nov 2008 03:51:42 +0000
Subject: [issue4276] IDLE in 2.6 fails to launch
In-Reply-To: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za>
Message-ID: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za>


New submission from Jan Schreuder <jan9447 at mac.com>:

I downloaded and installed Python 2.6 for Mac OSX 10.4. It installed
Build Applet, Extras, IDLE and Python Launcher in a Python 2.6 folder in
the Applications folder. However, IDLE will not launch. I have Python
2.5 installed. That IDLE version works.

----------
components: IDLE
messages: 75596
nosy: JanKarel
severity: normal
status: open
title: IDLE in 2.6 fails to launch
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4276>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:54:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Nov 2008 03:54:00 +0000
Subject: [issue4276] IDLE in 2.6 fails to launch
In-Reply-To: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za>
Message-ID: <1226030040.43.0.702500537435.issue4276@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Duplicate of #4017.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4276>
_______________________________________

From report at bugs.python.org  Fri Nov  7 04:59:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Nov 2008 03:59:20 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226030360.99.0.485212152059.issue4275@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Fri Nov  7 08:34:53 2008
From: report at bugs.python.org (Thomas Lee)
Date: Fri, 07 Nov 2008 07:34:53 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226043293.31.0.328876681641.issue4264@psf.upfronthosting.co.za>


Thomas Lee <tom at vector-seven.com> added the comment:

Neal said:
> I was surprised to see the change to the AST, but I understand why you
did it.

The problems David ran into here sound like an argument for arbitrary
AST annotations -- an idea that I was toying with around the time
"Const" was introduced. That way the optimizer could provide "hints"
rather than explicitly manipulating the AST in certain cases. The
compiler could then look for those hints and generate code accordingly.

For example, in place of the Const node, we might have a "const"
annotation that's applied to the top-level expression.

I think I went with the Const node because it was less work, but I don't
remember the details. I'll try to dig up the appropriate emails if I
haven't lost them.

David said:
> Fixed, I think.  The original code appears to be somewhat 
> inconsistent between files in its uses of spaces/tabs, ...

Yes, they are inconsistent with tabs/spaces. And it sucks. :)

> The thing that struck me as ugly was the idea that there's one
> object (the optimizer) that knows everything about all
> optimization operations.

That's right, but this is no different from the compiler. Conversely, a
visitor pattern would probably work for both the optimizer and the compiler.

Having said that, I couldn't justify making the AST optimizer a huge
departure from the rest of the code base for the sake of design purity.
I'm not even really sure that it's "design purity" when you do things
inconsistently from one component to the next.

Obviously if there's another sufficiently good argument for the visitor
approach, I'm all ears. But again, if we do that I think we should do it
for the compiler as well. I'm not sure how much support such a change
would have.

----------
nosy: +thomas.lee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 09:13:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Nov 2008 08:13:22 +0000
Subject: [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1226045602.98.0.491507534875.issue4266@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Actually, that the build doesn't work is almost OK, because that seealso
directive was invalid markup syntax (until very recently) :)

Anyway, should be fixed now after a "make update".

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________

From report at bugs.python.org  Fri Nov  7 10:12:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Nov 2008 09:12:16 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1226049136.35.0.268993123807.issue4236@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Christian,
The initial example only works in interactive mode.
To make your script crash, you have to set
    __builtins__._ = Crasher()

There are several other places where Crasher() will crash on shutdown:
     sys.argv.insert(0, Crasher())
     sys.ps1 = Crasher()
     sys.last_type = Crasher()
     sys.path_hooks.append(Crasher())
     sys.path_importer_cache[''] = Crasher()
But
     sys.meta_path.append(Crasher())
does not crash.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Fri Nov  7 13:15:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Nov 2008 12:15:53 +0000
Subject: [issue4277] asynchat's handle_error inconsistency
In-Reply-To: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>
Message-ID: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

Suppose you have tow sockets handled by two asynchat.async_chat class
instances and from class1 you want to send some data through class2:

class1(asynchat.async_chat):
    
   ...
   
   def mymethod(self):
       class2_instance.push_with_producer(producer)


Since push_with_producer automatically calls initiate_send() if an error
occurs while class2 reads the first chunk of data from the producer,
class1's handle_error gets called.
If the error occurs when reading the next chunks of data class2's
handle_error will be called instead.
This is an inconsistency that should be fixed so that always class2's
handle_error gets called.

The patch in attachment does that.

----------
components: Library (Lib)
files: asynchat.patch
keywords: patch
messages: 75601
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asynchat's handle_error inconsistency
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file11959/asynchat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4277>
_______________________________________

From report at bugs.python.org  Fri Nov  7 13:17:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Nov 2008 12:17:53 +0000
Subject: [issue4277] asynchat's handle_error inconsistency
In-Reply-To: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>
Message-ID: <1226060273.69.0.855025404679.issue4277@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4277>
_______________________________________

From report at bugs.python.org  Fri Nov  7 14:13:55 2008
From: report at bugs.python.org (Keith Briggs)
Date: Fri, 07 Nov 2008 13:13:55 +0000
Subject: [issue4278] optparse quirks
In-Reply-To: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za>
Message-ID: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za>


New submission from Keith Briggs <kbriggs at users.sourceforge.net>:

I got the message:

optparse.OptionError: invalid long option string '-T0': must start with
--, followed by non-dash

This is bad - the real error was that I gave a short option which did
not have a single letter.

Also, it seems that add_option('--height-of-plot','-h') is not allowed,
because -h can only go with --help.   How do I override this?

Keith

----------
components: Extension Modules
messages: 75602
nosy: kbriggs
severity: normal
status: open
title: optparse quirks
type: behavior
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4278>
_______________________________________

From report at bugs.python.org  Fri Nov  7 14:30:55 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 13:30:55 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1226064655.59.0.56230625163.issue3799@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov  7 14:31:09 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 13:31:09 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1226064669.4.0.439032211435.issue2306@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov  7 14:31:21 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Nov 2008 13:31:21 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1226064681.9.0.299245954898.issue4236@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Fri Nov  7 14:58:20 2008
From: report at bugs.python.org (Andy)
Date: Fri, 07 Nov 2008 13:58:20 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>


New submission from Andy <flossyfriend at hotmail.com>:

With a clean checkout of the py3k source it fails to build the Parser 
exension module (based on Modules/parsermodule.c) when building against 
a cygwin target.

This appears to be related to the movement of the symbol 
_PyParser_Grammar from graminit.c to Parser\metagrammar.c. (At least 
this is where it was going by the code comments)

Because of this the module now requires Parser\metagrammar.c to get 
this information via Py_meta_grammar.

The patch modifies setup.py to add the required file and modifies 
parsermodule.c to use the accessor function.

(This fails on a clean trunk build in the same way as well - which 
makes me very suspicious that this is not a "real" issue as the 
buildbots seem to be green.)

My gut feeling is that my modification to setup.py for the module is 
incorrect - it just looks messy. So I await the inevitable: "That's not 
how to fix it...." :-)

----------
components: Extension Modules
files: parsermodule_fix.diff
keywords: patch
messages: 75603
nosy: kirkshorts
severity: normal
status: open
title: Module 'parser' fails to build
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file11960/parsermodule_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Fri Nov  7 15:48:04 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 07 Nov 2008 14:48:04 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226069284.07.0.767956049972.issue4273@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I tested profile_cycle.txt on both Python 2.5.2 and Python 2.6. The
cycle you are showing for release 2.4.1 cannot be seen on both releases.
Why dont't you try and upgrade to Python 2.6?

----------
nosy: +wplappert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Fri Nov  7 15:58:01 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 07 Nov 2008 14:58:01 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226069881.98.0.243074798746.issue4279@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Fri Nov  7 17:25:26 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 07 Nov 2008 16:25:26 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226075126.58.0.994295575207.issue4264@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

> FWIW, I see exposing bytecodes as an anti-pattern that locks in a
> particular implementation in a way that makes it hard to change and 
> hard to port to other Python implementations.  The current bound 
> method approach works fine.  Don't really see enough payoff to 
> justify the extra code and maintenance.

Bytecodes aren't exposed at the language level -- just during
compilation.  As far as I know, other implementations don't use any of
the Python compiler mechanics, so there's no portability problem.  If
another compiler did use the Python AST, they could just compile the
Append node kind to a method call with no loss of speed or clarity.  Or
they could just not use this optimization, if we refactor the ast
optimizer as I propose to use the strategy pattern.

As for the payoff, microbenchmarks show a big win.  Also, appending to a
list is a fairly common pattern.  Our Plone-based codebase shows tens of
thousands of instances of append.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 18:17:11 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Nov 2008 17:17:11 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1226078231.15.0.923115759485.issue2306@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"PEP 352: Exceptions must derive from BaseException. This is the root 
of the 
exception hierarchy."
   I prefer to derive from Exception to be able to use 
   "exept Exception as: ..." which doesn't catch SystemExit 
   nor KeyboardInterrupt.

"PEP 3134: Exception chaining. (The __context__ feature from the PEP 
hasn?t 
been implemented yet in 3.0a2.)"
   The feature is now implemented!

"PEP 237: long renamed to int. (...) sys.maxint was also removed since 
the int 
type has no maximum value anymore."
   What about the new sys.maxsize constant? Oh, it's written at the 
bottom, 
   "Removed sys.maxint. Use sys.maxsize." Both paragraphs should be 
merged.

"Optimizations (...) 33% slower (...) we expect to be optimizing 
string and 
integer operations significantly before the final 3.0 release!"
   I don't expect "significant" changes before the final release. I 
worked on
   some patches about the int type (use base 2^30 instead of 2^15, 
GMP, etc.),
   but all patches optimize large integer (more than 1 digit, or more 
than 20
   digits) whereas most integers in Python are very small.

   About str=>unicode, I also don't expect changes. On character in 
now 
   4 bytes (or 2 bytes), whereas Python2 used 1 byte. This introduce 
an
   overhead. Most functions at C level use an conversion from byte
   string (ASCII) to Unicode (eg. PyErr_SetString). We should directly 
use
   wide string (eg. PyErr_SetWideString?).

"Porting to Python 3.0"
   This section is very small and gives few informations. There is 
nothing
   about 2to3 (just two references in the document). I also read 
somewhere
   that someone wrote a document explaining how to port a C extension 
to
   Python3.

What about a link to the "What's new in Python 2.6" document? Most 
people are 
still using Python 2.4 or 2.5. And Python3 is Python 2.5 + <changes in 
Python 
2.6> + <changes in Python 3.0)>.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov  7 18:25:29 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 07 Nov 2008 17:25:29 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1226078729.03.0.184974760649.issue4264@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

> Obviously if there's another sufficiently good argument for the visitor
> approach, I'm all ears. But again, if we do that I think we should do 
> it for the compiler as well. I'm not sure how much support such a 
> change would have.

The argument is that it would be possible to enable or disable
individual optimizations this way.  For the compiler, there's no need
for this, because there's only one thing to do per node type (although I
suppose we could just pass that set of things into the node walker). 

Another argument against is that it would be harder to combine
optimizations when that's relevant.

I don't think it's worth worrying about until there are a dozen or so
AST-level optimizations.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Fri Nov  7 18:53:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Nov 2008 17:53:46 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226080426.65.0.43705973044.issue4273@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Let's mark this as out of date then.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Fri Nov  7 19:35:29 2008
From: report at bugs.python.org (darrenr)
Date: Fri, 07 Nov 2008 18:35:29 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226082929.81.0.764193687176.issue4273@psf.upfronthosting.co.za>


darrenr <python-roundup at dranalli.com> added the comment:

Issue also occurs in 2.6. Note that it only shows up if gc is set to
save all cycles.

----------
versions: +Python 2.6
Added file: http://bugs.python.org/file11961/profile_cycle_26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Fri Nov  7 19:39:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Nov 2008 18:39:57 +0000
Subject: [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226083197.19.0.0275253035606.issue4273@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy:  -benjamin.peterson
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________

From report at bugs.python.org  Fri Nov  7 19:57:30 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 07 Nov 2008 18:57:30 +0000
Subject: [issue1656675] Drop-Handler for Python files
Message-ID: <1226084250.34.0.773503244088.issue1656675@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now added a drop handler in r67149, r67150, and r67151. However,
I chose the wsh handler ({60254CA5-953B-11CF-8C96-00AA00B8708C}) instead
of the batch file one, as the wsh handler provides long file names,
whereas the batch file handler passes 8.3 names.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1656675>
_______________________________________

From report at bugs.python.org  Fri Nov  7 20:55:02 2008
From: report at bugs.python.org (Colin J. Williams)
Date: Fri, 07 Nov 2008 19:55:02 +0000
Subject: [issue4280] Version Checker
In-Reply-To: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>
Message-ID: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>


New submission from Colin J. Williams <cjw at ncf.ca>:

Versions 2.5, 2.6 and 3.0 contain a Version Checker in the Tools directory.

This appears to no longer serve a useful purpose.

Perhaps it can be dropped from the distribution.

Colin W

----------
components: Tests
files: pyversioncheck.py
messages: 75611
nosy: cjw
severity: normal
status: open
title: Version Checker
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11962/pyversioncheck.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4280>
_______________________________________

From report at bugs.python.org  Fri Nov  7 21:03:30 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 07 Nov 2008 20:03:30 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226088210.32.0.535354123773.issue4275@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

I found a similar problem in the Demo/sockets/unixclient.py code.

from socket import *

FILE = 'unix-socket'
s = socket(AF_UNIX, SOCK_STREAM)
s.connect(FILE)
s.send('Hello, world')
data = s.recv(1024)
s.close()
print('Received', repr(data))

Produces the following error message:

Traceback (most recent call last):
  File "unixclient.py", line 9, in <module>
    s.send('Hello, world')
TypeError: send() argument 1 must be string or buffer, not str

My question is around whether the examples are wrong and 'Hello, World'
should simply be wrapped with bytearray('Hello, World','utf8')   or
whether the underlying socket implementation is wrong.  Judging by the
error message above it looks like the implementation is catching just
this kind of error and the example should be changed.  But, this must
break backward compatibility all over the place.  And since the bug has
release blocker it makes me think the socket implementation should be
changed.

----------
nosy: +bmiller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Fri Nov  7 21:32:00 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 07 Nov 2008 20:32:00 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

While experimenting with the new unicodedata for version 5.1 (many 
thanks for it!) I discovered some strange behaviour of Idle with regard 
to a character not available in any font on my system, namely Latin 
capital letter sharp s - U+1E9E.
Cf. the following sessions:

Python 3.0rc2 (r30rc2:67141, Nov  7 2008, 11:43:46) [MSC v.1500 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
...    
IDLE 3.0rc2      

>>> print("\N{LATIN CAPITAL LETTER SHARP S}")
?
>>> print("\N{LATIN CAPITAL LETTER S WITH CEDILLA}")
?
>>> print("\N{PHAGS-PA LETTER KA}")
?
>>> print("\ufff0")
?
>>> hex(ord("?"))
'0x1e9e'
>>> hex(ord("?"))
'0x15e'
>>> 

Of course, the exact view cannot be copied, but basically I see very 
similar glyphs for the first two characters, while I had expected a 
"square"-sign or something for the first one; this is what I get with 
other surely unavailable glyph as well as a non existent character. See 
the attached screenshot.

However, the characters remain clearly distinguished, as can be seen 
e.g. after copying them as a parameter of ord(...).

Python 2.6 behaves the same way:
=======================
Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
...    
IDLE 2.6      
>>> print u"\N{LATIN CAPITAL LETTER SHARP S}"
?
>>> 

...
==============================================

Not that it is much important, but I found it a bit surprising. I'm 
using WinXPh SP3 Czech.

----------
components: IDLE, Tkinter, Unicode
files: idle-capital-sharp-s.jpg
messages: 75613
nosy: vbr
severity: normal
status: open
title: Idle - incorrectly displaying a character (Latin capital letter sharp s)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11963/idle-capital-sharp-s.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Fri Nov  7 21:38:33 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2008 20:38:33 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1226090313.4.0.724721784804.issue4246@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your example seem too verbose and diffuse.  Perhaps something more
focused on what people do wrong would be more helpful.  I presume you
mean something like this -- with or without x=2 before the def.

>>> def f():
	print (x)
	x = 1

>>> f()
Traceback (most recent call last):
  File "<pyshell#31>", line 1, in <module>
    f()
  File "<pyshell#30>", line 2, in f
    print (x)
UnboundLocalError: local variable 'x' referenced before assignment

What are the other ways people get the error.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Fri Nov  7 21:47:48 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2008 20:47:48 +0000
Subject: [issue4249] HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za>
Message-ID: <1226090868.53.0.950655104283.issue4249@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You should have edited the title and added a note here instead of
opening a new issue to clarify that the problem is in urllib2.py. 
Anyway, closing this in favor of issue 4250

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> urllib2.py: HTTPResponse instance has no attribute 'code'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4249>
_______________________________________

From report at bugs.python.org  Fri Nov  7 22:01:17 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2008 21:01:17 +0000
Subject: [issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
Message-ID: <1226091677.74.0.750641555234.issue4250@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be a duplicate of #1507166, with essentially the same
title.  I found it by searching all issues for "response.code
HTTPResponse".  That was closed because "The problem came from an
external module (urlgrabber) which aparently was not up to date."

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4250>
_______________________________________

From report at bugs.python.org  Fri Nov  7 22:47:57 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2008 21:47:57 +0000
Subject: [issue4262] import and compile() do not treat trailing whitespace the
	same
In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
Message-ID: <1226094477.75.0.746379071574.issue4262@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Both differences are covered in the 2.x docs:

"When compiling multi-line statements, two caveats apply: line endings
must be represented by a single newline character ('\n'), and the input
must be terminated by at least one newline character.

The \r difference is not really a difference because \r is replaced by
\n before import starts compiling.  I suspect that EOF effectively gets
converted to \n also.  The doc issue is that 'must be terminated...' is
not always true.

This caveat is missing in 3.0, even though the limitation is the same. 
see #4118.

I thought this was discussed in a c.l.p thread.

----------
nosy: +tjreedy
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4262>
_______________________________________

From report at bugs.python.org  Fri Nov  7 22:49:02 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2008 21:49:02 +0000
Subject: [issue4118] Built-in compile() and ast module doc issues
In-Reply-To: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>
Message-ID: <1226094542.37.0.0980580567258.issue4118@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It appears that blanks on the last line also triggers a syntax error.
See #4262.  So the situation seems to be that the input must *sometimes*
be terminated by .... .  So adding 'sometimes' is the only change I
would make, besides restoring the warning to the 3.0 docs.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4118>
_______________________________________

From report at bugs.python.org  Fri Nov  7 23:18:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Nov 2008 22:18:45 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226096325.83.0.957209675546.issue4281@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Idle seems indeed to do a hard job to find a font that can display the 
character.
On my machine (WinXP sp3, French) there are many fonts, but only "Myriad 
Web" can display \N{LATIN CAPITAL LETTER SHARP S}.

I was surprised that the "Character Map" application does not display 
it. To find which font was used to display this character, I used 
Microsoft Word: paste the character (from Idle), select the text, open 
the Font chooser dialog box, and scroll through the polices until it 
displays correctly in the "Preview" pane.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Fri Nov  7 23:49:03 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 07 Nov 2008 22:49:03 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226098143.59.0.194592195845.issue4275@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

After looking at the socket documentation pointed to from another issue
it looks like the right solution is to convert to a byte array.

I've attached a patch with fixes for all the examples in
socketserver.rst  there were several other problems that I think were
unrelated to Python 3.0 that I cleaned up in the process.

----------
keywords: +patch
Added file: http://bugs.python.org/file11964/socketserverdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Fri Nov  7 23:55:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 07 Nov 2008 22:55:21 +0000
Subject: [issue4280] Version Checker
In-Reply-To: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>
Message-ID: <1226098521.51.0.122446389247.issue4280@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4280>
_______________________________________

From report at bugs.python.org  Sat Nov  8 00:04:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 07 Nov 2008 23:04:44 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226099084.75.0.706032356655.issue4281@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IDLE, in itself, doesn't do anything special to render that character.
It passes it on to Tk.

I don't know how precisely Tk works in this case, but it might be that
it doesn't do anything special with the character *either*, but passes
it on to Windows.

FWIW, in this bug report, Firefox/Iceweasel, on Debian, renders the
character as a small sharp s. This rendition appears to be correct, as
the letter is supposed to look like the small letter, in principle.

I can't see why Amaury says it works for him (there is surely something
odd in the OP's system), I'm fairly confident that there is no bug in
Python here. In particular, the unicodedata module has nothing to do
with it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 00:15:43 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Nov 2008 23:15:43 +0000
Subject: [issue1429539] pdb: fix for  1326406 (import  __main__ pdb failure)
Message-ID: <1226099743.12.0.65318970933.issue1429539@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am not sure whether it is appropriate to comment on a closed issue, 
but if the tracker will take this comment, hopefully it will find the 
right audience.

I have recently stumbled on this bug running python 2.5.  While tracking 
the problem down, I've noticed that some of the script running logic in 
pdb and runpy is replicated in some aspects and slightly different in 
others.

Thus both pdb and runpy pop sys.argv[0], but (after this patch) pdb 
cleans __main__.__dict__ and repopulates it by executing the script 
while runpy replaces sys.modules['__main__'] with a fresh module and 
uses that module's namespace to run the script in.

Furthemore, runpy injects __loader__ in the "main" namespace while pdb 
does not.

While I cannot point out any specific problems (other than inability to 
debug applications in zipped packages with python -m pdb app.zip), I 
believe pdb should use the same logic and preferably the same code as 
runpy.  

Finally a nit: why does _runscript use run("execfile(filename)") instead 
of runcall(execfile, filename, gloabals_, locals_)?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429539>
_______________________________________

From report at bugs.python.org  Sat Nov  8 00:29:23 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Nov 2008 23:29:23 +0000
Subject: [issue4118] Built-in compile() and ast module doc issues
In-Reply-To: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>
Message-ID: <1226100563.37.0.0843922574484.issue4118@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

General comment:

Stylistically, the docs should mostly be stated in a positive manner,
stating what a tool does, how it should be used, and what is left
undefined.  IMO, it is harmful to fill the docs with CAVEATS and WARNINGS.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4118>
_______________________________________

From report at bugs.python.org  Sat Nov  8 01:12:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 08 Nov 2008 00:12:03 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226103123.82.0.941527525427.issue4281@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

My mistake, I did not know that "SHARP S" stands for the "Eszett" German 
letter.

There is a font (Myriad Web on my system) that proposes a (wrong) glyph 
for this code point. According to
http://www.tcl.tk/software/tcltk/whatsnew.tml#i18n
"""
Tk guarantees to find a way to display any Unicode character regardless 
of the font you selected, as long as there is some font in the system 
that contains the Unicode character
"""
but Tk does not guarantee that the font will display the correct 
character...

----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 01:23:11 2008
From: report at bugs.python.org (Trent Mick)
Date: Sat, 08 Nov 2008 00:23:11 +0000
Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with
	whitespace
In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>
Message-ID: <1226103791.37.0.160793246664.issue3073@psf.upfronthosting.co.za>


Changes by Trent Mick <trentm at gmail.com>:


----------
nosy: +trentm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3073>
_______________________________________

From report at bugs.python.org  Sat Nov  8 01:44:35 2008
From: report at bugs.python.org (mixedpuppy)
Date: Sat, 08 Nov 2008 00:44:35 +0000
Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with
	whitespace
In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>
Message-ID: <1226105075.83.0.521667156298.issue3073@psf.upfronthosting.co.za>


mixedpuppy <shanec at activestate.com> added the comment:

The problem is that spaces are not allowed in the attribute values. 
Here is a work around

# hack fix of Cookie.BasicCookie
import Cookie
import re
_LegalCharsPatt  = r"\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\="
_FixedCookiePattern = re.compile(
    r"(?x)"                       # This is a Verbose pattern
    r"(?P<key>"                   # Start of group 'key'
    "["+ _LegalCharsPatt +"]+?"     # Any word of at least one letter,
nongreedy
    r")"                          # End of group 'key'
    r"\s*=\s*"                    # Equal Sign
    r"(?P<val>"                   # Start of group 'val'
    r'"(?:[^\\"]|\\.)*"'            # Any doublequoted string
    r"|"                            # or
    "["+ _LegalCharsPatt +"\ ]*"        # Any word or empty string
    r")"                          # End of group 'val'
    r"\s*;?"                      # Probably ending in a semi-colon
    )

class FixedCookie(Cookie.SimpleCookie):
    def load(self, rawdata):
        """Load cookies from a string (presumably HTTP_COOKIE) or
        from a dictionary.  Loading cookies from a dictionary 'd'
        is equivalent to calling:
            map(Cookie.__setitem__, d.keys(), d.values())
        """
        if type(rawdata) == type(""):
            self._BaseCookie__ParseString(rawdata, _FixedCookiePattern)
        else:
            self.update(rawdata)
        return

----------
nosy: +mixedpuppy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3073>
_______________________________________

From report at bugs.python.org  Sat Nov  8 03:47:53 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Nov 2008 02:47:53 +0000
Subject: [issue4118] Built-in compile() and ast module doc issues
In-Reply-To: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>
Message-ID: <1226112473.51.0.652862570625.issue4118@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The 2.6 sentence that got deleted in 3.0:

I at least somewhat agree.

"When compiling a string with multi-line statements, two caveats apply:
line endings must be represented by a single newline character ('\n'),
and the input must be terminated by at least one newline character."

could have "two caveats apply" deleted to be more positive.  I would
prefer the following simpler, direct use instruction.

"When compiling a string with multi-line statements, terminate all lines
with a single newline character ('\n')."

This issue came up both in c.l.p discussion and again in invalid #4262
(whose author apparently missed the current sentence).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4118>
_______________________________________

From report at bugs.python.org  Sat Nov  8 03:49:32 2008
From: report at bugs.python.org (Takafumi SHIDO)
Date: Sat, 08 Nov 2008 02:49:32 +0000
Subject: [issue4282] (Python3) The profile module deesn't understand the
	character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>


New submission from Takafumi SHIDO <takafumi at shido.info>:

The profile module of Python3 deesn't understand the character set of
the script.

When a profile is executed (like $python -m profile -o prof.dat foo.py)
on a code (say foo.py) which defines its character set in the second
line (like #coding:utf-8),
the profile crashes with an error message like:
"SyntaxError: unknown encoding: utf-8"

----------
messages: 75627
nosy: shidot
severity: normal
status: open
title: (Python3) The profile module deesn't understand the character set definition
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Sat Nov  8 04:49:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 08 Nov 2008 03:49:46 +0000
Subject: [issue4071] ntpath.abspath fails for long str paths
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1226116186.89.0.716928611559.issue4071@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed unicode issue in r67154(trunk). I'm not sure how to handle long
str, so I didn't touch it for now.

----------
versions: +Python 2.5.3, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4071>
_______________________________________

From report at bugs.python.org  Sat Nov  8 09:16:10 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 08 Nov 2008 08:16:10 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226132170.73.0.471247954887.issue4281@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I'm aware, that it isn't an issue of unicodedata, it was just the way I 
came to try such a "modern" unicode character.
I also see, that tk works pretty well in finding an appropriate font 
(e.g. compared to wx, which I use more often) - it took me quite some 
time to find another clearly unavailable character - PHAGS-PA 
LETTER ... :-), which however behaves like I'd expect - a square is 
displayed.

Regarding capital eszet/sharp s missing in windows' charmap, this isn't 
anything special, as its character database seems to be quite ancient 
(acording to http://www.babelstone.co.uk/Software/BabelMap.html it 
might be Unicode 2.0, instead of the current 5.1). Capital sharp s was 
added in this last version of the Unicode standard - 5.1. (The 
mentioned tool also has a tool to find a font containing a given 
unicode block.)
In the unicode database, there is a "crossreference" to the small sharp 
s, but I'm not sure, how this info should be interpretted, it's a 
different item than the plain lower/capital pair.

However, is there something to look into to check, what might be 
misconfigured on my system?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 12:48:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Nov 2008 11:48:06 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226144886.45.0.112956982013.issue4275@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why not using bytes() instead of bytearray()? Eg. replace 
s.send('Hello, world') by s.send(b'Hello, world').

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Sat Nov  8 12:50:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Nov 2008 11:50:19 +0000
Subject: [issue2433] Merge  audio modules
In-Reply-To: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
Message-ID: <1226145019.76.0.717193257904.issue2433@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Which modules? And where is the patch? :-)

----------
nosy: +haypo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2433>
_______________________________________

From report at bugs.python.org  Sat Nov  8 13:15:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 08 Nov 2008 12:15:42 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226146542.99.0.131028102938.issue4281@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

On my system, a square box is drawn indeed.

First, I would like to confirm that this is not a bug in Python. Can you
please install Tcl 8.5 separately, run wish, and execute

   label .l -text "\u1e9e"
   pack .l

IIUC, Tk will try to find a font that contains the character. First,
there is a list of fallback fonts per family. If none supports the
character, there is a global fallback list. If the character is still
not found, it will enumerate all fonts in the system, and invokes
GetFontData, asking for the resource 0x636d6170 - this should give the
list of all characters supported in the font.

It would be useful to find out what specific font Tk has chosen.
Unfortunately, there seems to be no direct way to find out. In the
Tktest Tcl extension, there is a command "testfont subfonts <fontname>"
which you can use to find out what subfonts have been loaded; this might
give a clue what subfont was used.

If you are willing to recompile Tk, you can augment
tkWinFont.c:FindSubFontForChar to print a message when this specific
char gets looked up, and what the resulting subfont was.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 13:55:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Nov 2008 12:55:52 +0000
Subject: [issue4251] library.pdf documentation: "See also: Module <xxx>" does
	not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1226148952.83.0.692634841066.issue4251@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in Sphinx rev 735:a4019921bdf4.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________

From report at bugs.python.org  Sat Nov  8 13:56:30 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 08 Nov 2008 12:56:30 +0000
Subject: [issue4283] "python3.0 setup.py install --user" raises AttributeError
In-Reply-To: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za>
Message-ID: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

A simple left-over "dict.iteritems". Patch is attached.

----------
components: Distutils
files: distutils.patch
keywords: patch
messages: 75634
nosy: hagen
severity: normal
status: open
title: "python3.0 setup.py install --user" raises AttributeError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11965/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4283>
_______________________________________

From report at bugs.python.org  Sat Nov  8 14:06:51 2008
From: report at bugs.python.org (robwolfe)
Date: Sat, 08 Nov 2008 13:06:51 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1226149611.97.0.574320655579.issue4246@psf.upfronthosting.co.za>


robwolfe <rw at smsnet.pl> added the comment:

People seem to understand that they can not use variable before
definition. But this dramatically change when they come across nested
functions. They don't understand when variable can be resolved from
outer scope and when can not, e.g:

def outer():
    x = 1
    def inner1():
        print(x)
    def inner2():
        print(x)
        # [... some instructions (maybe a lot) ...]
        x = 1

They are always confused why `inner1` works but `inner2` doesn't.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Sat Nov  8 14:19:06 2008
From: report at bugs.python.org (Brad Miller)
Date: Sat, 08 Nov 2008 13:19:06 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226144886.45.0.112956982013.issue4275@psf.upfronthosting.co.za>
Message-ID: <e45086040811080519u310b171dj45405c59189e9c26@mail.gmail.com>


Brad Miller <bonelake at gmail.com> added the comment:

For the example in unixclient.py using b'Hello World' works fine.  But for
the example in the socketserver documentation the strings to convert come
from argv[1:]

On Sat, Nov 8, 2008 at 5:48 AM, STINNER Victor <report at bugs.python.org>wrote:

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Why not using bytes() instead of bytearray()? Eg. replace
> s.send('Hello, world') by s.send(b'Hello, world').
>
> ----------
> nosy: +haypo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4275>
> _______________________________________
>

Added file: http://bugs.python.org/file11966/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081108/cfdf71cf/attachment.txt>

From report at bugs.python.org  Sat Nov  8 14:47:29 2008
From: report at bugs.python.org (Brad Miller)
Date: Sat, 08 Nov 2008 13:47:29 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226152049.61.0.317454190487.issue4275@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Here's a combined patch that fixes:

Doc/library/socketserver.rst  examples tested and working
Demo/sockets/udpecho.py
Demo/sockets/unixclient.py

Added file: http://bugs.python.org/file11967/socketpatches.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Sat Nov  8 16:16:04 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Nov 2008 15:16:04 +0000
Subject: [issue4283] "python3.0 setup.py install --user" raises AttributeError
In-Reply-To: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za>
Message-ID: <1226157364.95.0.19500966839.issue4283@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r67160.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4283>
_______________________________________

From report at bugs.python.org  Sat Nov  8 17:56:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Nov 2008 16:56:03 +0000
Subject: [issue4118] Built-in compile() and ast module doc issues
In-Reply-To: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>
Message-ID: <1226163363.21.0.884993532432.issue4118@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the suggestions! Changed in r67162.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4118>
_______________________________________

From report at bugs.python.org  Sat Nov  8 18:24:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Nov 2008 17:24:44 +0000
Subject: [issue4275] socketserver example code not correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226165084.46.0.75005333644.issue4275@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r67168.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________

From report at bugs.python.org  Sat Nov  8 18:27:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Nov 2008 17:27:55 +0000
Subject: [issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
Message-ID: <1226165275.99.0.712478209171.issue4250@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4250>
_______________________________________

From report at bugs.python.org  Sat Nov  8 18:28:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Nov 2008 17:28:12 +0000
Subject: [issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
Message-ID: <1226165292.37.0.234509922667.issue4250@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4250>
_______________________________________

From report at bugs.python.org  Sat Nov  8 19:23:54 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 08 Nov 2008 18:23:54 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226168634.45.0.899850501607.issue4281@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I can confirm, that TCL displays the same character as Idle, hence it 
itsn't a bug in Python (cf. the screenshot).
Unfortunately, I couldn't identify the font used here; I'm not able to 
modify and recompile Tk, as suggested, but I tried to check the 
possible serif fonts visually.
None of the fonts listed in Word is identical to the one used for 
capital sharp s in tcl (I created a simple app with Tkinter Label-s 
showing the pairs of the characters in question using the potentially 
similar fonts; while some are really close, in all cases there are 
various differences in glyphs; )

In any case, I guess this isn't a problem in python, which would have 
to be further examined; I have quite a lot of fonts installed, probably 
with some of them behaving in some "non-standard" ways

Added file: http://bugs.python.org/file11968/capital-sharp-s-TCL-Idle.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 19:29:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Nov 2008 18:29:06 +0000
Subject: [issue4271] conversion tool does not fix "from Tkinter import N,E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1226168946.68.0.640101870227.issue4271@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The other problem is fixed in r67170.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________

From report at bugs.python.org  Sat Nov  8 19:38:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 08 Nov 2008 18:38:01 +0000
Subject: [issue4281] Idle - incorrectly displaying a character (Latin capital
	letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226169481.43.0.1093527207.issue4281@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> works for me
status: open -> closed
versions: +3rd party -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________

From report at bugs.python.org  Sat Nov  8 20:09:50 2008
From: report at bugs.python.org (Anthony Awtrey)
Date: Sat, 08 Nov 2008 19:09:50 +0000
Subject: [issue4284] Python 2.6 64-bit + Vista 64 = Bad MSVCRT
In-Reply-To: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>
Message-ID: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>


New submission from Anthony Awtrey <tony at awtrey.com>:

Here is the reproduction process. Get Windows box running Vista 64-bit.
Download the Python 2.6 64-bit version. Write a script that imports
escape from saxutils. See this:

C:\Python26>python.exe example_xml_script.py > out.xml
Traceback (most recent call last):
  File "example_xml_script.py", line 11, in <module>
    from xml.sax.saxutils import escape
  File "C:\Python26\lib\xml\sax\saxutils.py", line 6, in <module>
    import os, urlparse, urllib, types
  File "C:\Python26\lib\urllib.py", line 26, in <module>
    import socket
  File "C:\Python26\lib\socket.py", line 46, in <module>
    import _socket
ImportError: DLL load failed: The application has failed to start
because its side-by-side configuration is incorrect. Please see the
application event log for more detail.

EventViewer says:

Activation context generation failed for "C:\Python26\DLLs\_socket.pyd".
Error in manifest or policy file
"C:\Python26DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12. 
The value "../msvcr90.dll" of attribute "name" in element
"urn:schemas-microsoft-com:asm.v1^file" is invalid.

Go download the MSVCRT directly and install it:

http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

Then the problem goes away.

This issue is particular only to the Python 2.6 64-bit version, as the
32-bit version runs just fine.

----------
components: Windows
messages: 75643
nosy: DaGoodBoy
severity: normal
status: open
title: Python 2.6 64-bit + Vista 64 = Bad MSVCRT
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4284>
_______________________________________

From report at bugs.python.org  Sat Nov  8 20:16:20 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 08 Nov 2008 19:16:20 +0000
Subject: [issue4251] library.pdf documentation: "See also: Module <xxx>" does
	not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1226171780.78.0.650047345883.issue4251@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

Hi, I just checked out sphinx version 67171. It still seems not to
procduce a link to the module. How does Sphinx rev 735:a4019921bdf4
translate into a Python revision?

This is what I did:
 $ make update
svn update tools/sphinx
At revision 67171.
svn update tools/docutils
At revision 67171.
svn update tools/jinja
At revision 67171.
svn update tools/pygments
At revision 67171.
...

make latex; cd build/latex; make

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________

From report at bugs.python.org  Sat Nov  8 20:20:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Nov 2008 19:20:39 +0000
Subject: [issue4251] library.pdf documentation: "See also: Module <xxx>" does
	not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1226172039.25.0.469270115735.issue4251@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It doesn't directly translate. I'm going to switch the Python docs'
build setup to checkout from Hg soon.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________

From report at bugs.python.org  Sat Nov  8 20:29:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 08 Nov 2008 19:29:17 +0000
Subject: [issue4284] Python 2.6 64-bit + Vista 64 = Bad MSVCRT
In-Reply-To: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>
Message-ID: <1226172557.92.0.32655296904.issue4284@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of Issue4018. You need to install Python "for all
users"; "just for me" installation is not supported.

----------
nosy: +loewis
resolution:  -> duplicate
superseder:  -> "for me" installer problem on x64 Vista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4284>
_______________________________________

From report at bugs.python.org  Sat Nov  8 20:29:22 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 08 Nov 2008 19:29:22 +0000
Subject: [issue4284] Python 2.6 64-bit + Vista 64 = Bad MSVCRT
In-Reply-To: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>
Message-ID: <1226172562.7.0.344575327086.issue4284@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4284>
_______________________________________

From report at bugs.python.org  Sun Nov  9 01:04:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 Nov 2008 00:04:52 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

sys.version_info is just asking for a named tuple consisting of major,
minor, micro, releaselevel, and serial.

This is assuming, of course, that bootstrapping doesn't get in the way.

----------
assignee: brett.cannon
components: Extension Modules
keywords: easy
messages: 75647
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Use a named tuple for sys.version_info
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Nov  9 02:28:25 2008
From: report at bugs.python.org (dlfjessup)
Date: Sun, 09 Nov 2008 01:28:25 +0000
Subject: [issue4286] Discrepancy in format string documentation
In-Reply-To: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za>
Message-ID: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za>


New submission from dlfjessup <dljessup at gmail.com>:

In the documentation for Format Strings
(http://docs.python.org/dev/3.0/library/string.html#formatstrings), the
grammar has the following rule:

> conversion        ::=  "r" | "s"

However, the documentation later reads:

> Three conversion flags are currently supported: '!s' which calls str()
on the value, '!r' which calls repr() and '!a' which calls ascii().

This implies that the correct rule for the grammar is:

> conversion        ::=  "a" | "r" | "s"

----------
assignee: georg.brandl
components: Documentation
messages: 75648
nosy: dlfjessup, georg.brandl
severity: normal
status: open
title: Discrepancy in format string documentation
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4286>
_______________________________________

From report at bugs.python.org  Sun Nov  9 02:33:59 2008
From: report at bugs.python.org (Fernando Correia)
Date: Sun, 09 Nov 2008 01:33:59 +0000
Subject: [issue4287] Broken URL in documentation style guide
In-Reply-To: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za>
Message-ID: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za>


New submission from Fernando Correia <fernandoacorreia at gmail.com>:

The documentation Style Guide
[http://docs.python.org/dev/documenting/style.html] has a broken link to
http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/AppleStyleGuide2006.pdf.
This link should be updated to:

http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2008.pdf

----------
assignee: georg.brandl
components: Documentation
messages: 75649
nosy: facorreia, georg.brandl
severity: normal
status: open
title: Broken URL in documentation style guide
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4287>
_______________________________________

From report at bugs.python.org  Sun Nov  9 02:43:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 09 Nov 2008 01:43:16 +0000
Subject: [issue4286] Discrepancy in format string documentation
In-Reply-To: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za>
Message-ID: <1226194996.46.0.369140604755.issue4286@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the report! Fixed in r67174.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4286>
_______________________________________

From report at bugs.python.org  Sun Nov  9 02:45:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 09 Nov 2008 01:45:22 +0000
Subject: [issue4287] Broken URL in documentation style guide
In-Reply-To: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za>
Message-ID: <1226195122.29.0.363159575609.issue4287@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r67175.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4287>
_______________________________________

From report at bugs.python.org  Sun Nov  9 13:34:30 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 09 Nov 2008 12:34:30 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

After synchronization of my mingw32 cross-compilation environment with
trunk some of tests fail. The reason is that parsermodule fail to link.

Please check build on officially supported platform: MSVC and cygwin.

The attached patch (parser-grammar.patch) solve issue in my environment.

----------
components: Build, Tests
files: parser-grammar.patch
keywords: patch
messages: 75652
nosy: rpetrov
severity: normal
status: open
title: parsermodule and grammar variable
versions: Python 2.6
Added file: http://bugs.python.org/file11969/parser-grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 13:54:34 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Sun, 09 Nov 2008 12:54:34 +0000
Subject: [issue4289] Python 2.6 installer crashes when selecting 'advanced'
	and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

When installing python-2.6.msi it crashes when doing the following steps
on a windows XP (32 bit).

I'm not sure if all those steps are needed, but that's how it crashed here:

- start python-2.6.msi
- check 'install just for me' 
- change the destination directory (d:\bin\Python26)
- click on 'advanced'
- click on cancel
- confirm cancel

At this point windows presents a message: to help protect your computer,
Windows has closed this program.

----------
components: Installation
messages: 75653
nosy: fabioz
severity: normal
status: open
title: Python 2.6 installer crashes when selecting 'advanced' and cancelling it
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________

From report at bugs.python.org  Sun Nov  9 16:10:30 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 15:10:30 +0000
Subject: [issue4289] Python 2.6 installer crashes when selecting 'advanced'
	and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1226243430.29.0.645142707411.issue4289@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> loewis
components: +Windows
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________

From report at bugs.python.org  Sun Nov  9 17:54:53 2008
From: report at bugs.python.org (Bryon Roche)
Date: Sun, 09 Nov 2008 16:54:53 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1226249693.94.0.249580901668.issue3741@psf.upfronthosting.co.za>


Bryon Roche <bryon at spideroak.com> added the comment:

This patch works in the build system I'm using as well.  Can we get this
in py2.6.epsilon?

----------
nosy: +broche
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Sun Nov  9 18:35:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 17:35:05 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1226252105.81.0.0426210162252.issue4285@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I concur that bootstrapping may be a problem. Using a NamedTuple also
increases the number of loaded modules by 4 (_collections.so, keyword.py
and operator.so).

But we could reimplement it with a PyStructSequence like I did for
sys.float_info. It's straight forward and easy to implement with the
example code in Object/floatobject.c:PyFloat_GetInfo().

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Nov  9 18:38:04 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 17:38:04 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1226252284.99.0.543389910858.issue3741@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'll take it from here.

----------
assignee:  -> christian.heimes
components: +Windows
nosy: +christian.heimes
priority:  -> deferred blocker
stage:  -> patch review
type: behavior -> compile error
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Sun Nov  9 18:39:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 17:39:21 +0000
Subject: [issue4282] (Python3) The profile module deesn't understand the
	character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226252361.72.0.170360648052.issue4282@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
components: +Library (Lib)
nosy: +christian.heimes
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Sun Nov  9 19:19:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 18:19:40 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226254780.6.0.385551611141.issue4288@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

As far as I know neither cygwin nor MinGW32 are falling under the
categoy of first class citizens. MinGW32 is only officially supported to
build extension modules. The compilers aren't used by our build bots, too.

In order to make both cygwin builds and MinGW32 compiler major platforms
somebody has to step up and constantly provides testing and patches.

----------
components: +Windows
nosy: +christian.heimes, loewis
priority:  -> normal
stage:  -> patch review
type:  -> compile error
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 19:51:01 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 18:51:01 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226256661.91.0.67614837112.issue4288@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

looks like it might be a similar root issue to the one I raised in #4279.

Looks like this patch breaks the data hiding that I think has been
attempted :-( though it doesn't mess with setup.py in the way mine does :-)

Don't know how Christian's comment affects either of our patches though
(still an uber newbie to the whole contributing to Python thing ;-) )

----------
nosy: +kirkshorts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:00:25 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 19:00:25 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226257225.97.0.294147736548.issue4288@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Andy:
Of course we like to support Cygwin and MinGW32. I wanted to make clear
that the platforms aren't top priority. They aren't regularly tested by
any of the core developers and build bots.

Regarding data hiding, you are correct. I'm more fond of your solution #4279

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:04:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 19:04:14 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226257454.6.0.542579407572.issue4288@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Oh, I retract everything I said about your patch. I didn't read your
patch carefully enough. With your patch the parser module wouldn't use
the same grammer as the rest of Python. That might be an issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:31:13 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 19:31:13 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226259073.06.0.867105346574.issue4288@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

Christian:

Cool, thanks for the feedback d00d - it took longer than i though to get
what I predicted :-) No worries on the whole "core target" platform
thing - I understand it perfectly, had the same issue for work related
things: too many platform and too few test resources :-( And sadly I am
in not a position to gift any to the cause - sorry.

Can I ask how it would mean that parser would get a different grammar?
In the interests of a newbie learning if you don't mind (maybe post the
reply to #4279 as I guess it is more relevant there than here)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:42:47 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 19:42:47 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226259767.36.0.344221444481.issue4288@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

Christian: sorry my 'find' kung fu is weak :-( :-$ I see why.

Will work on a better patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:49:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Nov 2008 19:49:32 +0000
Subject: [issue4189] Tilde compression isn't applied in TOC
In-Reply-To: <1224796033.71.0.204844693671.issue4189@psf.upfronthosting.co.za>
Message-ID: <1226260172.21.0.364241358719.issue4189@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FYI: This is now fixed in tip.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4189>
_______________________________________

From report at bugs.python.org  Sun Nov  9 20:58:25 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 19:58:25 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226260705.93.0.843088585027.issue4279@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

bah I *am* a idiot, #4288 and Christian's comments point out that I
can't use 'find' & 'xargs' properly :-(

Will modify patch to use the correct grammar file &c.

(and maybe one day I might actually say something sensible to do with
Python development :-) )

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Nov  9 21:06:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 09 Nov 2008 20:06:37 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226261197.03.0.230895788682.issue4279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Christian said in #4288: this links in a separate of metagrammar.c,
which is undesirable. However, I think you can fix this by exporting
Py_meta_grammar from pythonxy.dll.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Nov  9 22:07:16 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Sun, 09 Nov 2008 21:07:16 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1226264836.08.0.0481642655823.issue4171@psf.upfronthosting.co.za>


Changes by Todd Whiteman <twhitema at yahoo.com.au>:


----------
nosy: +twhitema

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Sun Nov  9 22:51:20 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 21:51:20 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226267480.15.0.0635233787568.issue4279@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

a new patch that will use the grammar definition from Python/graminit.c
- it is as of yet untested for Cygwin (can't get to that machine right
now). It follows the same pattern as the previous, i.e. it makes us of
an accessor function to get the grammar definition.

This has expanded the patch somewhat to include changes to:

 - setup.py for Cygwin environment.
 - Parser/pgenmain.c to write out the function body
 - Python/pythonrun.c to use the new function
 - Include/grammar.h to declare the new function
 - Modules/parsermodule.c to use the new function


All of which makes me think that the change to make the symbol "public"
and use it directly without hiding it is a better way to go.

Will look at this under my Cygwin environment tomorrow. (I have run a
configre - make - test cycle on Ubuntu (hardy heron) and it is OK [but
then its not broken there anyway :-) ] )

Added file: http://bugs.python.org/file11970/nu_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Nov  9 22:51:28 2008
From: report at bugs.python.org (Andy)
Date: Sun, 09 Nov 2008 21:51:28 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226267488.13.0.985523534779.issue4279@psf.upfronthosting.co.za>


Changes by Andy <flossyfriend at hotmail.com>:


Removed file: http://bugs.python.org/file11960/parsermodule_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Nov  9 23:10:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 09 Nov 2008 22:10:04 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226268604.05.0.575719317907.issue4279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That patch is too complicated. We already have meta_grammar and
Py_meta_grammar, and now you also add a third function
(get_PyParserGrammar) that does the same thing again. I don't see why
you can't call one of the existing functions, and I fail to see the need
to change pythonrun.c at all.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Nov  9 23:12:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 09 Nov 2008 22:12:42 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226268762.13.0.124114829757.issue4279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a style guide remark: drop the parentheses around the expression in
the return statement (return is a statement, not a function), and prefix
all global symbols with Py or _Py. See PEP 7 for further instructions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Mon Nov 10 00:04:13 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Sun, 09 Nov 2008 23:04:13 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>


New submission from Ondrej Certik <ondrej at certik.cz>:

Download my branch of sympy from here:

http://github.com/certik/sympy/tree/division3

and run the 2to3 tool with python2.5:

$ python2.5 ../2to3/2to3 sympy/
[...]
Traceback (most recent call last):
  File "../2to3/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/home/ondra/repos/2to3/lib2to3/main.py", line 126, in main
    rt.refactor(args, options.write, options.doctests_only)
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 194, in refactor
    self.refactor_dir(dir_or_file, write, doctests_only)
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 212, in
refactor_dir
    self.refactor_file(fullname, write, doctests_only)
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 235, in
refactor_file
    tree = self.refactor_string(input, filename)
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 260, in
refactor_string
    self.refactor_tree(tree, name)
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 299, in
refactor_tree
    self.traverse_by(self.post_order, tree.post_order())
  File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 323, in
traverse_by
    new = fixer.transform(node, results)
  File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line
148, in transform
    if not has_metaclass(node):
  File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 34,
in has_metaclass
    return has_metaclass(node)
  File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 39,
in has_metaclass
    if leaf_node.value == '__metaclass__':
AttributeError: 'Node' object has no attribute 'value'

----------
messages: 75669
nosy: certik
severity: normal
status: open
title: 2to3 fails with sympy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 00:12:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Nov 2008 23:12:31 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226272351.09.0.152157588006.issue4290@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> benjamin.peterson
components: +2to3 (2.x to 3.0 conversion tool)
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 00:57:55 2008
From: report at bugs.python.org (Jeremy Banks)
Date: Sun, 09 Nov 2008 23:57:55 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>


New submission from Jeremy Banks <jeremy at jeremybanks.ca>:

It would be convenient if it were possible to divide one
datetime.timedelta object by another to determine their relative durations.

Were the datetime module pure Python a crude solution would just be to
add two methods like this:

	def toMicroseconds(self):
		return ((self.days * 24 * 60) + self.seconds * 1000000) +
self.microseconds
	
	def __truediv__(self, other):
		return self.toMicroseconds() / other.toMicroseconds()

However, I don't understand know the Python C API well enough to know
how to patch the C module.

----------
components: Library (Lib)
messages: 75670
nosy: Jeremy Banks
severity: normal
status: open
title: Allow Division of datetime.timedelta Objects
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:02:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Nov 2008 00:02:55 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226275375.7.0.608546738732.issue4291@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

That's just too weird. A long time ago I suggested to implement __int__
and __float__ on timedelta objects: int(timedelta) -> seconds,
float(timedelta) -> seconds.micros. Then your use case could be written
as float(td1) / float(td2) which is far more obvious than td1 / td2.
Unfortunately I wasn't a core developer back in those days.

----------
nosy: +christian.heimes
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:10:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 00:10:55 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226275855.3.0.173235477764.issue4291@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand what do you expect with the divison. Can you give an
use case and/or examples?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:16:56 2008
From: report at bugs.python.org (Jeremy Banks)
Date: Mon, 10 Nov 2008 00:16:56 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226276216.99.0.188041922231.issue4291@psf.upfronthosting.co.za>


Jeremy Banks <jeremy at jeremybanks.ca> added the comment:

Sorry, allowing for conversion to int/float is probably a more sensible
solution.

This idea was brought to my mind when I was making a very very simple
script for a friend to display how far through a time range we currently
are. For example:

	elapsed = datetime.timedelta(hours=4, days=3)
	duration = datetime.timedelta(days=30)
	
	percentage = (100 * elapsed / duration)

In my case, precision wasn't important so I just divided elapsed.days by
duration.days, but it would be continent to have an accurate result by
just writing what I did above.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:25:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 00:25:55 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1226276755.83.0.701228737096.issue4171@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the bug on Python 3.0 svn trunk. Can you retry
with Python 3.0rc2 please?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:36:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 00:36:34 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1226277394.81.0.245186088999.issue4171@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(I tried your code on Linux and no exception is raised)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Nov 10 01:40:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 00:40:38 +0000
Subject: [issue4282] (Python3) The profile module deesn't understand the
	character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226277638.3.0.650599284594.issue4282@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

exec() doesn't work if the argument is an unicode string. Here is a
workaround for the profile module (open the file in binary mode), but it
doesn't fix the exec() problem.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11971/profile_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Mon Nov 10 02:03:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 01:03:30 +0000
Subject: [issue4282] (Python3) The profile module deesn't understand the
	character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226279009.92.0.547150221285.issue4282@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Exemple of the problem: exec('#header\n# encoding:
ISO-8859-1\nprint("h\xe9 h\xe9")\n')

exec(unicode) calls source_as_string() which converts unicode to bytes
using _PyUnicode_AsDefaultEncodedString() (UTF-8 charset). Then
PyRun_StringFlags() is called with the UTF-8 byte string with
PyCF_SOURCE_IS_UTF8 flag. But in the parser, get_coding_spec() recognize
the "#coding:" header and convert bytes to unicode using the specified
charset (which may be different than UTF-8).

The problem is in the function PyAST_FromNode(): the flag in not used in
the tokenizer but only in the AST parser. I also see:
    if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) {
        c.c_encoding = "utf-8";
        if (TYPE(n) == encoding_decl) {
#if 0
            ast_error(n, "encoding declaration in Unicode string");
            goto error;
#endif
            n = CHILD(n, 0);
        }
    } else if (TYPE(n) == encoding_decl) {
        c.c_encoding = STR(n);
        n = CHILD(n, 0);
    } else {
	/* PEP 3120 */
        c.c_encoding = "utf-8";
    }

The ast_error() may be uncommented.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Mon Nov 10 02:23:32 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 01:23:32 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226280212.16.0.683272051557.issue4291@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue #1673409 may help: delta1.toseconds() / delta2.toseconds().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 02:32:13 2008
From: report at bugs.python.org (Jeremy Banks)
Date: Mon, 10 Nov 2008 01:32:13 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226280733.68.0.937920776085.issue4291@psf.upfronthosting.co.za>


Jeremy Banks <jeremy at jeremybanks.ca> added the comment:

Thanks, I should have paid more attention to the results when I searched
for duplicates. I think that Christian's suggestion of enabling float()
and int() for timedeltas is worth having here, though.

----------
nosy:  -christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Mon Nov 10 04:59:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Nov 2008 03:59:39 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226289579.01.0.946962986424.issue4290@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I've fixed the first problem in r67177, but I found another one in
thirdparty/pyglet. Try running with "-x metaclass".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 05:59:18 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 10 Nov 2008 04:59:18 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1226293158.3.0.0289862053117.issue4171@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

Same thing on Python 3.0rc2:

C:\TEMP>python test.py
worked so far
Traceback (most recent call last):
  File "1.py", line 23, in <module>
    test_handshake(address, False)
  File "1.py", line 17, in test_handshake
    ssl.do_handshake()
  File "C:\Python30\lib\ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Nov 10 06:00:36 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 10 Nov 2008 05:00:36 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1226293236.63.0.374338675098.issue4171@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

1.py == test.py obviously :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Nov 10 08:03:55 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 07:03:55 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>


New submission from Ondrej Certik <ondrej at certik.cz>:

While converting the SymPy repo:


the 2to3 failed to convert stuff like:

from something import (a, b, c, )

Attached find the patch that I had to do by hand -- I think 2to3 should
be able to fix this as well.

----------
files: import.patch
keywords: patch
messages: 75683
nosy: certik
severity: normal
status: open
title: 2to3 fails to convert "from something import (a, b, c)"
Added file: http://bugs.python.org/file11972/import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 08:04:37 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 07:04:37 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226300677.84.0.130154800914.issue4290@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

Thanks, that was quick!

You can delete the thirdparty/pyglet, it's not imported by default. Then
the 2to3 passes. But I found another bug:

issue 4292

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:29:16 2008
From: report at bugs.python.org (Andy)
Date: Mon, 10 Nov 2008 09:29:16 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226309356.66.0.52246508444.issue4279@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

Martin:

Looking at it I agree with you 100% - the patch is too complicated for 
what it is intending to resolve. It simply does not need another 
accessor function to muddy the waters when making the symbol public as 
done in #4288 resolves the issue.

My personal preference is to try to hide such data structures - but 
that doesn't always mean its the correct thing to do :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:46:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 09:46:18 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226310378.14.0.41538238851.issue4290@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You would like to replace "from mptypes import ..." by "from .mptypes 
import ...". Is it really a bug? Python is unable to guess if mptypes, 
functions or settings are "global" modules or "relative" modules. Why 
don't you patch your original code since Python 2.5 also supports this 
syntax? Documentation:
http://www.python.org/doc/2.5.2/ref/import.html
http://docs.python.org/reference/simple_stmts.html#the-import-statement

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:46:37 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 09:46:37 +0000
Subject: [issue4282] (Python3) The profile module deesn't understand the
	character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226310397.7.0.259631858252.issue4282@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:48:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 09:48:00 +0000
Subject: [issue4282] exec(unicode): invalid charset when #coding:xxx spec is
	used
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226310480.1.0.792502275833.issue4282@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: (Python3) The profile module deesn't understand the character set definition -> exec(unicode): invalid charset when #coding:xxx spec is used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:56:06 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 09:56:06 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226310966.11.0.813886036421.issue4292@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

Author: STINNER Victor (haypo):

You would like to replace "from mptypes import ..." by "from .mptypes 
import ...". Is it really a bug? Python is unable to guess if mptypes, 
functions or settings are "global" modules or "relative" modules. Why 
don't you patch your original code since Python 2.5 also supports this 
syntax? Documentation:
http://www.python.org/doc/2.5.2/ref/import.html
http://docs.python.org/reference/simple_stmts.html#the-import-statement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:58:15 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 09:58:15 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226311095.31.0.130131877939.issue4292@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

> You would like to replace "from mptypes import ..." by "from .mptypes 
> import ...". 

Yes, exactly, see the patch where I did that.

> Is it really a bug? Python is unable to guess if mptypes,
> functions or settings are "global" modules or "relative" modules.

I think it is a bug, because 2to3 correctly fixed all the other import
statements, like "from something import a, b, c", but failed with "from
something import (a, b, c)".

> Why don't you patch your original code since Python 2.5 also
> supports this syntax? 

Because we need to support python2.4, a lot of people still use it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 10:59:00 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 09:59:00 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226311140.59.0.648693398664.issue4290@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

Hi Victor, thanks for the comments. I copied them to the issue 4292
where they belong and replied there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 11:45:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 10:45:18 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226313918.44.0.807450055125.issue4292@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, I replied to the wrong issue (#4292) :-p

My test was wrong: yes, 2to3 needs a patch. I wrote one (with no test 
yet).

----------
nosy: +haypo
Added file: http://bugs.python.org/file11973/2to3_fix_import.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:18:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 11:18:59 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1226315939.39.0.590188428951.issue3720@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:36:35 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 10 Nov 2008 11:36:35 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

At CCP We have started using the Py_AddPendingCall() mechanism to 
signal python about a completed IO operation.
However, we noticed that the existing mechanism was hoplelessly un-
thread safe.  This is bad, since on Windows at least, it is very 
convenient to have such callbacks happen on an arbitrary thread from 
the system's thread pool.
I submit a thread-safe implementation instead to be used if WITH_THREAD 
is defined.
This allows Py_AddPendingCall() to be called from any thread, from any 
context, even from a PendingCall callback itself.

----------
components: Interpreter Core
files: pendingalls.patch
keywords: needs review, patch, patch
messages: 75691
nosy: krisvale
priority: normal
severity: normal
status: open
title: Thread Safe Py_AddPendingCall
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file11974/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:53:27 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Nov 2008 11:53:27 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226318007.94.0.0515149133534.issue4293@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Your patch sounds like a useful addition. However I can comment on the
details because I haven't dealt with Py_AddPendingCall() yet.

Documentation updates and a unit test (Modules/_testcapimodule.c), that
shows the bug and verifies your patch, are welcome, too.

----------
keywords:  -needs review
nosy: +christian.heimes
stage:  -> patch review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:59:26 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 10 Nov 2008 11:59:26 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226318366.44.0.678789005914.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Good point.  I'll make a test using ctypes and _testcapimodule.c to try 
to make it as non-platform-specific as possible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:12:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 13:12:33 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It's hard to read Objects/longobject.c because the code depends to 
much on the implementation. I wrote macros to simplify the code:
 - PyLong_SIGN(x)
 - PyLong_EQUALS_ZERO(x)
 - PyLong_FITS_INT(x)
 - PyLong_GET_INT(x)
 - PyLong_NDIGITS(x)

Macros are declared in Include/longintrepr.h to be able to use them 
outside longobject.c. Eg. I used it in Modules/mathmodule.c.

The patch also contains extra changes:
 - create sdigit type (used by PyLong_GET_INT(x))
 - use memcpy() in _PyLong_Copy()
 - use stwodigits in long_mul()
 - replace many Py_SIZE() hacks by my macros (eg. see long_hash)

Using my patch, it will be easier to change long integer 
implementation, like:
 - Use 30-bit digits instead of 15-bit digits (issue #4258)
 - Use GMP for PyLong (issue #1814)

Example of changes:
	i = Py_SIZE(v);
	x = 0;
	if (i < 0) {
		PyErr_SetString(PyExc_OverflowError,
			   "can't convert negative value to unsigned 
int");
		return (unsigned long) -1;
	}
	switch (i) {
	case 0: return 0;
	case 1: return v->ob_digit[0];
	}
	while (--i >= 0) {
        ...
is replaced by:
	if (PyLong_SIGN(v) < 0) {
		PyErr_SetString(PyExc_OverflowError,
			   "can't convert negative value to unsigned 
int");
		return (unsigned long) -1;
	}
	if (PyLong_FITS_INT(v))
		return (unsigned long) PyLong_GET_INT(v);
	x = 0;
	i = PyLong_NDIGITS(v);
	while (--i >= 0) {
        ...

----------
files: pylong_macros.patch
keywords: patch
messages: 75694
nosy: haypo
severity: normal
status: open
title: Macros for PyLong: sign, number of digits, fits in an int
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11975/pylong_macros.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:13:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 13:13:06 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226322786.81.0.96963627875.issue4294@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +gregory.p.smith, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:34:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Nov 2008 13:34:22 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1226324062.3.0.918720526404.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a minor update to the patch, that does some extra cleanup:

- don't include longintrepr.h in Objects/abstract.c or 
Objects/boolobject.c --- it's not needed.

- fix several places in longobject.c where int should have been size_t 
or Py_ssize_t

- remove some unnecessary forward declarations in longobject.c.

- fix PyLong_FromLong for small negative integers

At some point I'll try to separate the pure bugfixes (missing casts, int 
vs Py_ssize_t, etc.) from the 15-bit to 30-bit conversion.

Added file: http://bugs.python.org/file11976/30bit_longdigit4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:37:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Nov 2008 13:37:33 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226324253.67.0.023608708799.issue4294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Interesting.

Incidentally, I'm already using sdigit for the signed version of digit---
this seems to fit with the current digit/twodigits/stwodigits typedefs.  

What's the purpose of your sdigit?  Do you really want it to be type 
'int'?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:48:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Nov 2008 13:48:48 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226324928.35.0.481351475791.issue4294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another thought:  macros that are going to be used elsewhere in Python 
(like the way you're using PyLong_SIGN in mathmodule.c) would probably
be better off in longobject.h.   The fewer places there are that have to 
include longintrepr.h, the easier it is to mess with the internal 
representation.

It's quite tempting to 'fix' _PyLong_AsScaledDouble to return e as the 
number of bits, rather than the number of digits;  then mathmodule.c 
wouldn't have to include longintrepr.h at all.

(And if marshal.c were also changed, to read and write integers as byte 
strings, we wouldn't need longintrepr.h anywhere any more!)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 14:50:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 13:50:58 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226325058.9.0.450220362322.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Second patch to optimize some PyLong operations:
 - Write special code for small (a, b) of long_true_div(), 
long_bitwise(), and l_divmod() (used by long_div(), long_mod() and 
long_divmod(), and long_pow())
 - PyLong_FromLong(): don't go to the while() for small *negative* 
integers

TODO: Write special code for small integers of long_rshift() and 
long_lshift()

Added file: http://bugs.python.org/file11977/pylong_optimize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:00:37 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 14:00:37 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226325637.46.0.605046973772.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What's the purpose of your sdigit?

The type sdigit should be able to store a signed digit, so a number in 
[-(2^15-1); 2^15-1]. short may be enough, but I think that the CPU 
prefers (CPU is faster with) an int because it doesn't have to 
truncate the MSB (eg. 32 bits (u)int => 16 bits (u)short). I also 
used "int" because Python was already using "int" (right?)

> would probably be better off in longobject.h

Right.

> It's quite tempting to 'fix' _PyLong_AsScaledDouble to 
> return e as the number of bits, rather than the number of digits

Good idea. But instead of writing a patch of 100.000 lines, I prefer 
to start with a small patch and then add new patches to improve it. It 
allows to apply only some patches but not all. Is 
_PyLong_AsScaledDouble() used by another module than mathmodule.c?

> marshal.c

Same: it's better to write a separated patch.

--

I opened a new issue because the GMP and 30-bits patchs are too big 
and it's not easy to review/commit them. The idea is to do small 
changes to allow bigger changes later.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:05:09 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 10 Nov 2008 14:05:09 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226325909.22.0.755993559564.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Okay, i add a new patch that includes tests.
I am unsure where I should add documentation for the Py_AddPendingCall
() function.  Any suggestions?

Added file: http://bugs.python.org/file11978/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:05:18 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 10 Nov 2008 14:05:18 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226325918.21.0.823164117551.issue4293@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


Removed file: http://bugs.python.org/file11974/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:34:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Nov 2008 14:34:05 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226327645.45.0.896012018526.issue4294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Same: it's better to write a separated patch.

Agreed.

Unfortunately, I think all of this is going to have to wait for Python 
3.0 to be released before we can consider committing anything.  The 
first step is to commit the pure bugfixes (missing casts, etc.).  I 
suppose we *could* do this for 2.6.1/2.7 now, but it seems safer to make 
all the changes in the 2.x and 3.x branches simultaneously.

By the way, I think we can also get rid of wdigit---it can be safely 
replaced by digit everywhere, as far as I can tell.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 16:47:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 15:47:17 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226332037.95.0.381418185883.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@marketdickinson: As you proposed, here is a patch for 
_PyLong_AsScaledDouble(): stores directly the number of bits in an 
unsigned int instead of the number of digits.

Added file: http://bugs.python.org/file11979/pylong_asscaleddouble.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 17:31:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Nov 2008 16:31:41 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226334701.05.0.838586678196.issue4294@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I like the idea, Victor

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 17:54:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 10 Nov 2008 16:54:42 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226336082.36.0.796756160564.issue4294@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 18:48:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Nov 2008 17:48:25 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226339305.76.0.334560889268.issue4292@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 19:55:26 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 18:55:26 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226343326.85.0.69989267572.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Other optimization for long_compare(), long_lshift() and 
long_rshift().

Note: with all my patches, Python is a little bit faster (but not 
slower, which is already a good thing ;-)).

Added file: http://bugs.python.org/file11980/pylong_shift.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 20:58:23 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 10 Nov 2008 19:58:23 +0000
Subject: [issue4244] ihooks incompatible with absolute_import feature
In-Reply-To: <1225459960.12.0.259014417715.issue4244@psf.upfronthosting.co.za>
Message-ID: <1226347103.66.0.995511792777.issue4244@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

This is an (extended) duplicate of issue4152.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4244>
_______________________________________

From report at bugs.python.org  Mon Nov 10 22:27:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Nov 2008 21:27:16 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226352436.96.0.416746124573.issue4290@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Second metaclass problem fixed in r67178.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 22:31:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Nov 2008 21:31:43 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226352703.9.0.920349292562.issue4292@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67179.

Ondrej, thanks for running 2to3 over sympy and finding all these tasty bugs!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:34:59 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 22:34:59 +0000
Subject: [issue4292] 2to3 fails to convert "from something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226356499.27.0.298064433293.issue4292@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

Benjamin, thanks for the fantastic work!

I discovered more bugs, but this time I reported to the py3000 list, as
I need more feedback on it. But it seems you'll get another tasty bug
for the 2to3, among other things. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:35:47 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 22:35:47 +0000
Subject: [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226356547.35.0.251967724514.issue4290@psf.upfronthosting.co.za>


Ondrej Certik <ondrej at certik.cz> added the comment:

I can confirm this is now fixed. Thanks very much!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:36:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 22:36:01 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226356561.22.0.0494208379559.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

More benchmark with py3k trunk on a Quad Core at 2.5 GHz (64 bits):

./python Lib/test/pystone.py 250000 (maximum value on 5 runs):
 - original: 58685.4 pystones/second
 - patched: 61274.5 pystones/second

Don't trust pystones, results are variables :-/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:57:12 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 10 Nov 2008 22:57:12 +0000
Subject: [issue4295] closing stdout in a child process on cygwin means that
	process doesn't receive bytes from stdin anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

When someone runs "bin/trial --reactor=select 
twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_
childConnectionLost" on cygwin, using the cygwin version of Python, 
either manually (which I've done on two cygwin installations), or from 
the twisted buildbot -- 
http://buildbot.twistedmatrix.com/builders/cygwin-py2.5-select -- then 
once the child process closes its fd #2, it subsequently receives no 
further bytes from its fd #1, even though the parent process has written 
some bytes to that pipe.

I can reproduce this by running the Twisted unit tests, like this:

step 1: get twisted:

svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted

step 2: cd into the top-level directory, and run trial:

cd twisted && python ./bin/trial --reactor=select 
twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_
childConnectionLost

On other platforms that cygwin (see the Twisted buildbot -- 
http://buildbot.twistedmatrix.com/supported?branch=trunk -- then this 
test exits quickly with success. On cygwin, using cygwin python.exe, 
this test instead enter an infinite loop as the child waits to receive 
further bytes on its stdin, and the parent waits for the child to 
respond to those bytes. (This doesn't happen on cygwin with the standard 
Win32 build of python.exe, of course, anymore than it happens on a 
Windows system without cygwin installed when using that executable.)

I've opened a ticket about this on the twisted issue tracker as well: 

http://twistedmatrix.com/trac/ticket/3529 # closing stdout in a child 
process on cygwin means that process doesn't receive bytes from stdin 
anymore. I think.

----------
components: Interpreter Core
messages: 75711
nosy: zooko
severity: normal
status: open
title: closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:19:32 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 10 Nov 2008 23:19:32 +0000
Subject: [issue4295] closing stdout in a child process on cygwin means that
	process doesn't receive bytes from stdin anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1226359172.36.0.483835178318.issue4295@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

I opened a ticket on the cygwin issue tracker:

http://sourceware.org/bugzilla/show_bug.cgi?id=7017 # closing stdout in a 
child python process means that process doesn't receive bytes from stdin 
anymore. I think.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:40:04 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Nov 2008 23:40:04 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226360404.68.0.711461628888.issue4294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There are so many things going on here it's getting difficult to keep 
track of them all!  Not only Victor's stuff, but also Mario's patches 
for faster multiplication, and for subquadratic division.  And it might 
be interesting to experiment with subquadratic int <-> str conversion as 
well.

I'm wondering whether it would be worth starting a new 
"py3k_long_optimization" branch, so that we can get some of the obvious 
stuff in and start experimenting properly with the rest.

Christian, you're the expert on this:  any thoughts?  Is it possible to 
set up a new svn branch so that it's easy to merge from the py3k branch, 
or is svn merging only really possible from the trunk?  I'm happy to set 
things up and take care of doing regular merges, if you can give me some 
pointers.

(If not, maybe it's time for me to learn how to use git/hg/bzr.  I've 
used darcs quite a bit before, so the concepts aren't totally alien to 
me, but I haven't found time to learn other systems yet.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:41:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 00:41:05 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226364065.36.0.813461738466.issue4294@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's probably easier to wait a couple of days until 3.0.0 is out. I
don't know how the new branches will look like. 

By the way your work fits nicely in my plans to work on optimizations
for 3.1. Go, Victor, go!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:38:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 01:38:33 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226367513.06.0.326241776187.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to use pystone nor pybench to compare all integers patches. 
So I wrote my own tool: bench_int.py. Don't use to compare different 
computers or Python versions, it's just useful to test if a patch is 
faster or slower.

Example (still the 64 bits CPU at 2.5 GHz):
-------------------------------
original     : 896.5 ms
 + macros    : 891.0 ms (+0.6%)
 ++ optimize : 884.3 ms (+1.4%)
 +++ shift   : 880.8 ms (+1.7%)
GMP          : 700.9 ms (+22%)
30 bits      : 659.9 ms (+26%)
-------------------------------

Result: my optimizations are useless, whereas mark's patch (#4258) is 
26% faster! My GMP patch is only 22% faster (and so slower than the 30 
bits patch). The GMP hack would only be useful for huge value whereas 
my benchmark tool use mostly small values (the biggest is near 
2**200).

I use it with "sync && ./python -OO bench_int.py", run the command 2 
or 3 times, and keep the smallest value.

Added file: http://bugs.python.org/file11981/bench_int.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:44:44 2008
From: report at bugs.python.org (Michael B Curtis)
Date: Tue, 11 Nov 2008 01:44:44 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>


New submission from Michael B Curtis <mikecurtis at gmail.com>:

Found in Python 2.4; not sure what other versions may be affected.

I noticed a contradiction with regards to equivalence when experimenting
with NaN, which has the special property that it "is" itself, but it
doesn't "==" itself:

>>> a = float('nan')
>>> a is a
True
>>> a == a
False
>>> b = [float('nan')]
>>> b is b
True
>>> b == b
True


I am not at all familiar with Python internals, but the issue appears to
be in PyObject_RichCompareBool of python/trunk/Objects/object.c

This method "Guarantees that identity implies equality".  However, this
doesn't "Gaurantee" this fact, but instead "Assumes" it, because it is
not something that is always True.  NaN is identical to itself, but not
equivalent to itself.

At a minimum, the contradiction introduced by this assumption should be
documented.  However, it may be possible to do better, by fixing it. 
The assumption appears to be made that identity should imply
equivalence, for the common case.  Would it therefore be possible to,
instead of having objects such as lists perform this optimization and
make this assumption, instead have the base object types implement this
assumption.  That is, for regular objects, when we evaluate equivalence,
we return True if the objects are identical.  Then, the optimization can
be removed from objects such as list, so that when they check the
equivalence of each object, the optimization is performed there.  NaN
can then override the default behavior, so that it always returns False
in equivalence comparisons.

----------
components: Interpreter Core
messages: 75716
nosy: mikecurtis
severity: normal
status: open
title: Python assumes identity implies equivalence; contradicts NaN
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:49:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 01:49:51 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226368191.63.0.843361017447.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Interesting, Python 3.0 behaves differently than Python 2.x. Nice catch! :)

Python 3.0rc2 (r30rc2:67177, Nov 10 2008, 12:12:09)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> nan = float("nan")
>>> nan is nan
True
>>> nan == nan
False
>>> lst = [nan]
>>> lst is lst
True
>>> lst == lst
False

Python 2.6 (r26:66714, Oct  2 2008, 16:17:49)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> nan = float("nan")
>>> lst = [nan]
>>> lst == lst
True
>>> lst is lst
True

----------
nosy: +christian.heimes, marketdickinson
priority:  -> normal
stage:  -> test needed
versions: +Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:55:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 01:55:15 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1226368515.53.0.873274032076.issue4258@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11947/30bit_longdigit3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:58:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 01:58:57 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1226368737.01.0.95399363951.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using 30bit_longdigit4.patch, I get this 
error: "Objects/longobject.c:700: erreur: "SIZE_T_MAX" undeclared 
(first use in this function)". You might use the type Py_ssize_t with 
PY_SSIZE_T_MAX. I used INT_MAX to compile the code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:03:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:03:28 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1226369008.23.0.809576245672.issue3944@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11567/longobject_diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:03:32 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:03:32 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1226369012.07.0.800586774893.issue3944@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11595/longobject1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:16:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:16:58 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226369818.63.0.935832912154.issue4294@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

More numbers!

------ 64 bits CPU -------
original:  885.0 ms
fast long: 746.8 ms (+16%) -- issue #3944 
--------------------------

+16% only with an optimized multiplicaton, great job Pernici :-)

------ 32 bits CPU -------
original: 1564.3 ms
30 bits: 1497.3 ms (+4%)
fast long: 1591.7 ms (-2%)
GMP: 1564.4 ms (=)
--------------------------

It looks like the operation 32 bits x 32 bits is slower on a 32 bits 
CPU, the gain is small (only +4%). fast long and a little bit slower, 
and GMP patch doesn't change anything.

----------
nosy: +pernici

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:24:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:24:18 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1226370258.1.0.546012744053.issue4258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I like the idea of sys.int_info, but I would prefer a "base" attribute 
than "bits_per_digit". A base different than 2^n might be used (eg. a 
base like 10^n for fast conversion from/to string).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:45:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:45:41 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226371541.35.0.00300134286384.issue3439@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:47:42 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:47:42 +0000
Subject: [issue4208] Make multiprocessing compatible with Python 2.4 and 2.5
In-Reply-To: <1225034474.82.0.458838457625.issue4208@psf.upfronthosting.co.za>
Message-ID: <1226371662.19.0.473918719293.issue4208@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See http://code.google.com/p/python-multiprocessing/ project.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4208>
_______________________________________

From report at bugs.python.org  Tue Nov 11 03:58:05 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 02:58:05 +0000
Subject: [issue2494] Can't round-trip datetimes<->timestamps prior to 1970 on
	Windows
In-Reply-To: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za>
Message-ID: <1226372285.13.0.391863078725.issue2494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you doesn't care to the time zone (UTC), use:
>>> datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=-86400)
datetime.datetime(1969, 12, 31, 0, 0)

This code is portable on Windows, Linux but also works with 
IronPython:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7269

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2494>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:12:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 03:12:39 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1226373159.01.0.064265633357.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue1673409

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:12:54 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 03:12:54 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1226373174.14.0.209846344051.issue1673409@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue2736

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:22:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 03:22:58 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1226373778.08.0.370558335076.issue1083@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The current behaviour is consistent with the integer divison:
>>> 21 // 10
2
>>> timedelta(microseconds=20) // 10
datetime.timedelta(0, 0, 2)

Whereas int/int gives float:
>>> 21 / 10
2.1000000000000001
>> timedelta(microseconds=20) / 1
...
TypeError: unsupported operand type(s) for /: ...

Now in the real world, it's hard to understand that the operator // 
should be used instead of /. So timedelta()/int might be an alias to 
timedelta()//int.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:25:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 03:25:28 +0000
Subject: [issue2173] Python fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1226373928.61.0.458216261986.issue2173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you retry with Python 3.0rc2?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:50:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 03:50:08 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1226375408.96.0.788075801501.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch doesn't work on Python3 because Python3 changes 
time.strftime() for year < 1900: if time.accept2dyear is not False (or 
not set), raise an error; otherwise convert 0..68 => 2000..2068, 
69..99 => 1968..1999, or raise an error.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Tue Nov 11 05:07:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 04:07:01 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1226376421.39.0.726116575609.issue1726687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch is correct. I tried to use errno, but errno is unchanged on 
error. Here is a new patch with regression tests.

----------
nosy: +haypo
versions: +Python 2.7, Python 3.1
Added file: http://bugs.python.org/file11982/mktime_fix_and_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 05:10:07 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 04:10:07 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1226376607.98.0.00871393822667.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also Issue1777412.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Tue Nov 11 05:10:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 04:10:14 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1226376614.54.0.717052298049.issue1777412@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Tue Nov 11 05:11:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 04:11:23 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1226376683.85.0.00158090493574.issue3173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue #1777412 has a working patch (for Python 2.6) which allows 
year < 1900 in time.strftime() and datetime.datetime.strftime().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Tue Nov 11 05:11:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 04:11:29 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1226376689.6.0.2412020078.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #3173.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Tue Nov 11 06:23:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2008 05:23:55 +0000
Subject: [issue1545463] New-style classes fail to cleanup attributes
Message-ID: <1226381035.64.0.602376638991.issue1545463@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

amaury> What if PyGC_Collect() is called just before?

That would work.  With the following patch:

===================================================================
--- Python/import.c	(revision 67183)
+++ Python/import.c	(working copy)
@@ -498,7 +498,10 @@
 			PyDict_SetItem(modules, key, Py_None);
 		}
 	}
-
+	/* Collect garbage remaining after deleting the
+	   modules. Mostly reference cycles created by new style
+	   classes. */
+ 	PyGC_Collect();
 	/* Next, delete sys and __builtin__ (in that order) */
 	value = PyDict_GetItemString(modules, "sys");
 	if (value != NULL && PyModule_Check(value)) {

$ ./python.exe x.py
creating X('new')
creating X('old')
deleting X('old')
deleting X('new')

----------
keywords: +patch
Added file: http://bugs.python.org/file11983/gc-import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545463>
_______________________________________

From report at bugs.python.org  Tue Nov 11 06:25:15 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2008 05:25:15 +0000
Subject: [issue1545463] New-style classes fail to cleanup attributes
Message-ID: <1226381115.32.0.171431078876.issue1545463@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 2.5.3, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545463>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:52:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 10:52:51 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226400771.83.0.777944698215.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is indeed interesting.  For what it's worth, I think
the Python 3.0 behaviour is the right one, here.  Perhaps
it's worth adding a test to Python 3.0 to make sure that
this behaviour doesn't accidentally disappear, or at least
to make sure that someone thinks about it before making
the behaviour disappear.

But in general I don't think the fact that NaNs are weird
should get in the way of optimizations.  In other words,
I'm not sure that Python should be asked to guarantee
anything more than "b == b" returning False when b is
a NaN.  It wouldn't seem unreasonable to consider
behaviour of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks.

There are other questionable things going on when NaNs
are put into containers.  For example:

>>> a = float('nan')
>>> b = [a]
>>> a in b
True

A strict reading of the definition of 'in' would say
that "a in b" should return False here, since a is not
equal to any element of b.  But I presume that the 'in'
operator does identity checks under the hood before
testing for equality.  'Fixing' this so that nans did
the right thing might slow down a lot of other code
just to handle one peculiar special case correctly.

Michael, is this adversely affecting real-world code?
If not, I'd be inclined to say that it's not worth
changing Python's behaviour here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:57:41 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 10:57:41 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226401061.75.0.0595105231096.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more data point:  in both 2.x and 3.x, sets behave like the 2.x 
lists:

Python 3.0rc2+ (py3k:67177M, Nov 10 2008, 16:06:34) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = {float('nan')}
>>> s == s
True
>>> s is s
True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 13:03:40 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Nov 2008 12:03:40 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226405020.17.0.154043645712.issue4296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm not happy with the 3.0 change.  IMO, the best behavior is the one
that allows code reviewers to correctly reason about the code by
assuming basic invariants.  In 2.6, all of the following are always true:

   assert a in [a]
   assert a in (a,)
   assert a in set([a])
   assert [a].count(a) == 1

This is especially important because it lets us maintain a consistent
meaning for "in" its two contexts:

    for a in container:
        assert a in container    # this should ALWAYS be true

This shows that "is" is essential in the interpretation of "in".  If you
loop over elements in a container, then by definition those exact
elements are IN the container.  If we break this, it will lead to hard
to find errors and language inconsistencies.  

The "identity implies equality" rule isn't just an optimization, it is a
deep assumption that pervades the language implementation.  Lots of
logic relies on it to maintain invariants.  It looks like the 3.0
changes are fighting this state of affairs.  IMO, those changes are
fighting an uphill battle and will introduce more oddities than they
eliminate.

----------
nosy: +rhettinger
versions: +Python 3.0 -Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 13:12:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 12:12:21 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226405541.92.0.0196480345142.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Oh h... Raymond, you are so right! I was too tired to think of all
implications related to the different semantic in 3.0, especially the
for in / is in invariant. I'm including Guido and Barry into the
discussion. This topic needs some attention from the gods of old. :)

----------
nosy: +barry, gvanrossum
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 13:21:43 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 12:21:43 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226406103.03.0.292635970874.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Raymond]
> assuming basic invariants.  In 2.6, all of the following are always
> true:
>
>   assert a in [a]
>   assert a in (a,)
>   assert a in set([a])
>   assert [a].count(a) == 1

And these are all still true in 3.0 as well, aren't they?

In any case, you've convinced me.  I withdraw my comment
about the Python 3.0 behaviour being the right one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 13:49:34 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 12:49:34 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226407774.02.0.516796647876.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Here is a tes case for 3.0

----------
keywords: +patch
Added file: http://bugs.python.org/file11984/issue4296_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 14:10:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Nov 2008 13:10:49 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226409049.8.0.998276133203.issue4296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

To be clear, I'm saying that PyObject_RichCompareBool() needs to
add-back the code:

	/* Quick result when objects are the same.
	   Guarantees that identity implies equality. */
	if (v == w) {
		if (op == Py_EQ)
			return 1;
		else if (op == Py_NE)
			return 0;
	}

When the above code was originally put in, there was discussion about it
on python-dev and time has proven it to be a successful choice.  

I don't know who took this out, but taking it out was a mistake in a
world that allows rich comparison functions to return anything they
want, possibly screwing-up the basic invariants everywhere we do
membership testing.  

Taking it out probably had something to do with NaNs, but this
discussion needs to avoid getting lost in NaN paradoxes and instead
focus on a notion of membership that is ALWAYS true given object
identity.  This is an essential pragmatism necessary for reasoning about
programs.

Consider that while PyObject_RichCompare() can return any object and can
be used in varied and sundry ways, the opposite is true for
PyObject_RichCompareBool().  The latter always returns a boolean and its
internal use cases are almost always ones that assume the traditional
properties of equality  -- a binary relation or predicate that is
reflexive, symmetric, and transitive.  We let the == operator violate
those properties, but the calls to PyObject_RichCompareBool() tend to
DEPEND on them.

---------------------------------------------------------------
P.S.  Mark, those Py2.6 invariants are not still true in Py3.0:

   IDLE 3.0rc2      
   >>> a = float('nan')
   >>> a in [a]
   False
   >>> a in (a,)
   False
   >>> a in set([a])
   True
   >>> [a].count(a)
   0
   >>> for x in container:
   	assert x in container
	
   AssertionError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 14:58:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 13:58:02 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226411882.88.0.0922170056437.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Taking it out probably had something to do with NaNs, but this
> discussion needs to avoid getting lost in NaN paradoxes and instead
> focus on a notion of membership that is ALWAYS true given object
> identity.  This is an essential pragmatism necessary for reasoning 
about
> programs.

I agree wholeheartedly.  NaN comparison weirdness isn't anywhere near
important enough to justify breaking these invariants.  Though I imagine 
that if 'x == x' started returning True for NaNs there might be some 
complaints.

> P.S.  Mark, those Py2.6 invariants are not still true in Py3.0:

You're right, of course.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 15:23:00 2008
From: report at bugs.python.org (Daniel Watkins)
Date: Tue, 11 Nov 2008 14:23:00 +0000
Subject: [issue4297] Add error_log attribute to optparse.OptionParser
In-Reply-To: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>
Message-ID: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>


New submission from Daniel Watkins <daniel at daniel-watkins.co.uk>:

I've recently had to subclass optparse.OptionParser, and copy-paste the
exit method, just to change where errors were printed to (I needed
stdout rather than stderr).  I've also had a request from a client to
log errors with command-line parsing to a file, rather than to stdout.

So, this patch adds an error_log parameter to OptionParser.__init__
which is used instead of stderr internally (and, of course, defaults to
stderr).

----------
components: Library (Lib)
files: optparse-error_log.patch
keywords: patch
messages: 75741
nosy: odd_bloke
severity: normal
status: open
title: Add error_log attribute to optparse.OptionParser
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11985/optparse-error_log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4297>
_______________________________________

From report at bugs.python.org  Tue Nov 11 15:35:42 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 11 Nov 2008 14:35:42 +0000
Subject: [issue4297] Add error_log attribute to optparse.OptionParser
In-Reply-To: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>
Message-ID: <1226414142.99.0.269874124052.issue4297@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4297>
_______________________________________

From report at bugs.python.org  Tue Nov 11 15:46:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 14:46:22 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226414782.5.0.513372553287.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With the lines Raymond mentions restored, all tests (including the extra 
tests Christian's posted here) pass for me, and I also get:

>>> a = [float('nan')]
>>> a == a
True

Incidentally, it looks as though the PyObject_RichCompareBool lines were 
removed in r51533.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:07:51 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 11 Nov 2008 15:07:51 +0000
Subject: [issue4298] pickle segfault or MemoryError on invalid input
In-Reply-To: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>
Message-ID: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

On a 64-bit build pickle.loads segfaults on the following bytes. (Same
for pickle.load on a corresponding file.) On a 32-bit build there is
only a MemoryError.

Python 3.0rc2 (r30rc2:67114, Nov 10 2008, 12:09:54)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.loads(bytes([0x58, 0, 0, 0, 0x54]))
Segmentation fault

----------
components: Library (Lib)
messages: 75743
nosy: hagen
severity: normal
status: open
title: pickle segfault or MemoryError on invalid input
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4298>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:19:57 2008
From: report at bugs.python.org (Gary VanHorn)
Date: Tue, 11 Nov 2008 15:19:57 +0000
Subject: [issue4299] 3.0rc2.msi Install Fails (Error Code 2755)
In-Reply-To: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>
Message-ID: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>


New submission from Gary VanHorn <support at toc247.com>:

Where can an error code resource be found?

----------
components: Installation
messages: 75744
nosy: sharksuit
severity: normal
status: open
title: 3.0rc2.msi Install Fails (Error Code 2755)
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4299>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:59:29 2008
From: report at bugs.python.org (Michael B Curtis)
Date: Tue, 11 Nov 2008 15:59:29 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226419169.26.0.883630840929.issue4296@psf.upfronthosting.co.za>


Michael B Curtis <mikecurtis at gmail.com> added the comment:

All,

Thank you for your rigorous analysis of this bug.  To answer the
question of the impact of this bug: the real issue that caused problems
for our application was Python deciding to silently cast NaN falues to
0L, as discussed here:

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

This would cause us to erroneously recognize 0s in our dataset when our
input was invalid, which caused various issues.  Per that thread, it
sounds like there is no intention to fix this for versions prior to 3.0,
so I decided to detect NaN values early on with the following:


def IsNan(x):
  return (x is x) and (x != x)


This is not the most rigorous check, but since our inputs are expected
to be restricted to N-dimensional lists of numeric and/or string values,
this was sufficient for our purposes.

However, I wanted to be clear as to what would happen if this were
handed a vector or matrix containing a NaN, so I did a quick check,
which led me to this bug.  My workaround is to manually avoid the
optimization, with the following code:


def IsNan(x):
  if isinstance(x, list) or isinstance(x, tuple) or isinstance(x, set):
    for i in x:
      if IsNan(i):
        return True
    return False
  else:
    return (x is x) and (x != x)


This isn't particularly pretty, but since our inputs are relatively
constrained, and since this isn't performance-critical code, it suffices
for our purposes.  For anyone working with large datasets, this would be
suboptimal.  (As an aside, if someone has a better solution for a
general-case NaN-checker, which I'm sure someone does, feel free to let
me know what it is).

Additionally, while I believe that it is most correct to say that a list
containing NaN is not equal to itself, I would hesitate to claim that it
is even what most applications would desire.  I could easily imagine
individuals who would only wish for the list to be considered NaN-like
if all of its values are NaN.  Of course, that wouldn't be solved by any
changes that might be made here.  Once one gets into that level of
detail, I think the programmer needs to implement the check manually to
guarantee any particular expected outcome.

Returning to the matter at hand: while I cringe to know that there is
this inconsistency in the language, as a realist I completely agree that
it would be unreasonable to remove the optimization to preserve this
very odd corner case.  For this reason, I proposed a minimal solution
here to be that this oddity merely be documented better.

Thanks again for your thoughts.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:31:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 16:31:00 +0000
Subject: [issue4258] Use 30-bit digits instead of 15-bit digits for Python
	integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1226421060.69.0.087682076799.issue4258@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a version of the 15-bit to 30-bit patch
that adds in a souped-up version of Mario Pernici's
faster multiplication.

I did some testing of 100x100 digit and 1000x1000 digit
multiplies.  On 32-bit x86:
  100 x 100 digits  : around 2.5 times faster
 1000 x 1000 digits : around 3 times faster.

On x86_64, I'm getting more spectacular results:
  100 x 100 digits : around 5 times faster
 1000 x 1000 digits: around 7 times faster!

The idea of the faster multiplication is quite simple:
with 30-bit digits, one can fit a sum of 16 30-bit by
30-bit products in a uint64_t.  This means that the
inner loop for the basecase grade-school multiplication
contains one fewer addition and no mask and shift.

[Victor, please don't delete the old longdigit4.patch!]

Added file: http://bugs.python.org/file11986/30bit_longdigit6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:44:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 16:44:54 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226421894.57.0.879652277509.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Michael]
> the real issue that caused problems [...] was Python deciding to
> silently cast NaN falues to 0L
> [...]
> it sounds like there is no intention to fix this for versions prior
> to 3.0,

Oh, <rude words> <rude words> <more rude words>!  Guido's message does
indeed say that that behaviour shouldn't be changed before 3.0.  And
if I'd managed to notice his message, I wouldn't have 'fixed' it for 
2.6. 

Python 2.7a0 (trunk:67115, Nov  6 2008, 08:37:21) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> int(float('nan'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot convert float NaN to integer

:-(.

[Imagine me looking extreeemely sheepish.]

I guess I owe apologies to Christian and Guido here.  Sorry, folks.  Is 
there any way I can make amends?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:45:43 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 11 Nov 2008 16:45:43 +0000
Subject: [issue4298] pickle segfault or MemoryError on invalid input
In-Reply-To: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>
Message-ID: <1226421943.67.0.042599007654.issue4298@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

See trunk/Modules/cPickle.c(609).

static Py_ssize_t
read_cStringIO(Unpicklerobject *self, char **s, Py_ssize_t  n)
{
	char *ptr;

	if (PycStringIO->cread((PyObject *)self->file, &ptr, n) != n) {
		PyErr_SetNone(PyExc_EOFError);
		return -1;
	}

	*s = ptr;

	return n;
}

It's checking the length of returned string and if not match, raises
EOFError. But there is no corresponding code in py3k.

I hope attached patch will fix this issue.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file11987/py3k_set_EOFError_when_invalid_result_size.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4298>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:54:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 16:54:00 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226422440.98.0.717293177646.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The issue with nan -> 0L was fixed in Python 2.6. I can't recall if I
fixed it or somebody else but I know it was discussed.

$ python2.6
>>> long(float("nan"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot convert float NaN to integer
>>> long(float("inf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot convert float infinity to integer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 18:12:04 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 17:12:04 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1226423524.24.0.889009376246.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See issue 4258 for a patch that combines 30-bit digits with
this multiplication optimization. The code is quite different
from the patch posted here, but the basic idea is the same.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Nov 11 18:15:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 17:15:52 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226423752.49.0.915616192202.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi, Victor!  Thanks for the updated patch.

Your patch still hangs on:

>>> from sys import maxint
>>> (-maxint-1).numbits()

on my 32-bit machine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Nov 11 18:37:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Nov 2008 17:37:15 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226425035.77.0.902893079435.issue4294@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I agree with Christian that we should wait until 3.0 is out.  Using A
DVCS should make this much easier if anyone needs an excuse to learn bzr.

I think we should aim to commit the 30bit change (a pretty clear win by
the looks of things) after 3.0 is released and py3k branch is unfrozen
and continue work from there to determine what to do with the others.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:15:43 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 18:15:43 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226427343.7.0.7641714888.issue3439@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (-maxint-1).numbits() hangs

Ooops, nice catch! It was an integer overflow, already present in 
fredrikj's original patch. The new patch fixes this bug but also 
included a documentation patch ;-)

Added file: http://bugs.python.org/file11988/numbits-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:15:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Nov 2008 18:15:50 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226427350.76.0.870610993942.issue3439@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11939/numbits-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:29:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2008 18:29:46 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1226428186.53.0.79783349869.issue1673409@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Chris> I keep needing to know the number of seconds that a timedelta
Chris> represents.

I propose an alternative approach that I believe will neatly solve 
fractional vs. whole seconds and multitude of conceivable toxxx methods:

Let's extend timedelta's div and floordiv methods to allow 

>>> (t - epoch) // timedelta(seconds=1)
--> whole seconds

and  

>>> (t - epoch) / timedelta(seconds=1)
--> fractional seconds

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:04:02 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Tue, 11 Nov 2008 19:04:02 +0000
Subject: [issue4300] error in multiprocessing logging docs
In-Reply-To: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za>
Message-ID: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za>


New submission from Brian D'Urso <dursobr at pitt.edu>:

the 2.6 docs for the multiprocessing module have a minor error in the
logging example which causes it to fail:

the documentation says to get the logger with
'multiprocessing.get_logger()' which works

but the example uses 'multiprocessing.getLogger()' which uses the
logging package method name and is not valid.

The full example in the docs is:

>>> import multiprocessing, logging
>>> logger = multiprocessing.getLogger()
>>> logger.setLevel(logging.INFO)
>>> logger.warning('doomed')
[WARNING/MainProcess] doomed
>>> m = multiprocessing.Manager()
[INFO/SyncManager-1] child process calling self.run()
[INFO/SyncManager-1] manager bound to '\\\\.\\pipe\\pyc-2776-0-lj0tfa'
>>> del m
[INFO/MainProcess] sending shutdown message to manager
[INFO/SyncManager-1] manager exiting with exitcode 0

----------
assignee: georg.brandl
components: Documentation
messages: 75755
nosy: dursobr, georg.brandl
severity: normal
status: open
title: error in multiprocessing logging docs
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4300>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:33:50 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Nov 2008 19:33:50 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226432030.39.0.744101618774.issue4296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, thanks for checking that all the tests still pass.  Please do add
back the missing lines in PyObject_RichCompareBool().  It seems that
their removal was not a necessary part of eliminating default sort-ordering.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:50:54 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Tue, 11 Nov 2008 19:50:54 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>


New submission from Brian D'Urso <dursobr at pitt.edu>:

logging in multiprocessing seems to give inconsistent results on Linux
and XP, but neither appears to match the documentation:

According to the docs, when first created "the logger has level
logging.NOTSET and has a handler which sends output to sys.stderr using
format '[%(levelname)s/%(processName)s] %(message)s'" The example in the
docs also does not work, but the full problem is more clearly
illustrated with the following:

This should print a message from the main process and the subprocess:

import multiprocessing, logging

def f():
    logger = multiprocessing.get_logger()
    logger.info('info from subprocess')

if __name__ == '__main__':
    logger = multiprocessing.get_logger()
    logger.setLevel(logging.INFO)
    logger.info('info from main process')
    p = multiprocessing.Process(target=f)
    p.start()
    p.join()

but, on Windows (XP) and Linux (ScientificLinux 5.2, python 2.6 compiled
from src) it outputs only:

No handlers could be found for logger "multiprocessing"

We can 'fix' this by specifying a handler, as in:

import multiprocessing, logging

def f():
    logger = multiprocessing.get_logger()
    logger.info('info from subprocess')

if __name__ == '__main__':
    logger = multiprocessing.get_logger()
    logger.setLevel(logging.INFO)
    handler = logging.StreamHandler()
    handler.setLevel(logging.INFO)
    formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
    handler.setFormatter(formatter)
    logger.addHandler(handler)
    logger.info('info from main process')
    p = multiprocessing.Process(target=f)
    p.start()
    p.join()

Then on Linux I get:

[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down

which looks better, but on Windows I get:

[INFO/MainProcess] info from main process
No handlers could be found for logger "multiprocessing"
[INFO/MainProcess] process shutting down

So, the logger is still not setup correctly in the subprocess on
Windows. We can again try to 'fix' this to:

import multiprocessing, logging

def f():
    logger = multiprocessing.get_logger()
    handler = logging.StreamHandler()
    handler.setLevel(logging.INFO)
    formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
    handler.setFormatter(formatter)
    logger.addHandler(handler)
    logger.info('info from subprocess')

if __name__ == '__main__':
    logger = multiprocessing.get_logger()
    logger.setLevel(logging.INFO)
    handler = logging.StreamHandler()
    handler.setLevel(logging.INFO)
    formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
    handler.setFormatter(formatter)
    logger.addHandler(handler)
    logger.info('info from main process')
    p = multiprocessing.Process(target=f)
    p.start()
    p.join()

Now, on Linux I get:

[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down

i.e. double output from the subprocess!
On Windows, I finally get:

[INFO/MainProcess] info from main process
No handlers could be found for logger "multiprocessing"
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down

which is almost OK, but the logger is getting set up too late to pick up
the subprocess self.run

It seems like the logger is not being setup correctly by
multiprocessing.get_logger() and the behavior is different in a
subprocess on Windows vs Linux.

----------
components: Library (Lib)
messages: 75757
nosy: dursobr
severity: normal
status: open
title: incorrect and inconsistent logging in multiprocessing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:05:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Nov 2008 20:05:39 +0000
Subject: [issue4298] pickle segfault or MemoryError on invalid input
In-Reply-To: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>
Message-ID: <1226433939.82.0.0393484287661.issue4298@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r67187. Thanks for the report, and for the patch!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4298>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:07:41 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 11 Nov 2008 20:07:41 +0000
Subject: [issue4185] re module treats raw strings as normal strings
In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za>
Message-ID: <1226434061.17.0.912596367558.issue4185@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4185>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:45:42 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 20:45:42 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226436342.4.0.0360218367388.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

(Comment for Michael, everybody else can safely ignore it.

Instead of writing:
    if isinstance(x, list) or isinstance(x, tuple) or isinstance(x, set):

you can write:
    if isinstance(x, (list, tuple, set)):

or even better:
    if hasattr(x, "__iter__"):

Starting with Python 2.6 you can use "from math import isnan", too.
)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:46:46 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 11 Nov 2008 20:46:46 +0000
Subject: [issue4185] re module treats raw strings as normal strings
In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za>
Message-ID: <1226436406.08.0.807524024883.issue4185@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Re-opening as a documentation bug; we should at least make the re.sub
docstring match the text documentation.

----------
assignee:  -> akuchling
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4185>
_______________________________________

From report at bugs.python.org  Tue Nov 11 22:34:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 21:34:26 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226439266.84.0.660982897132.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch incorporating Christian's tests, the missing lines from 
PyObject_RichCompareBool, and some additional tests to check that
[x] == [x] and the like remain True even when x is a NaN.  Oh, and a 
Misc/NEWS entry.

With this patch, all tests pass (debug and non-debug 32-bit builds) on OS 
X 10.5/Intel.

I think we should get the okay from Guido before committing this.  Maybe 
he remembers why he deleted these lines in the first place. :-)

----------
assignee:  -> gvanrossum
Added file: http://bugs.python.org/file11989/issue4296.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 22:54:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Nov 2008 21:54:16 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1226440456.53.0.953242043014.issue4301@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Tue Nov 11 22:56:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Nov 2008 21:56:24 +0000
Subject: [issue4300] error in multiprocessing logging docs
In-Reply-To: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za>
Message-ID: <1226440584.24.0.824632975566.issue4300@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the report! Fixed in r67189.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4300>
_______________________________________

From report at bugs.python.org  Tue Nov 11 23:01:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Nov 2008 22:01:08 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226440868.83.0.610568651392.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The tests are passing on Ubuntu Linux 64bit, too.

Good work everybody!

----------
assignee: gvanrossum -> barry
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Tue Nov 11 23:23:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Nov 2008 22:23:06 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1226442186.42.0.552342181941.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Raising to release blocker, just to trigger another review...

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Tue Nov 11 23:47:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Nov 2008 22:47:35 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1226443655.87.0.195171039002.issue3705@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Go ahead.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Tue Nov 11 23:59:36 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 11 Nov 2008 22:59:36 +0000
Subject: [issue1675] Race condition in os.makedirs
In-Reply-To: <1198180171.38.0.482360233935.issue1675@psf.upfronthosting.co.za>
Message-ID: <1226444376.44.0.64147057752.issue1675@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here's the version of this that I've been using for almost a decade now:

http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/fileutil.py?rev=127#L241

Actually I used to have a bigger version that could optionally require
certain things of the mode of the directory, but it turned out that I
wasn't going to need it.

def make_dirs(dirname, mode=0777):
    """
    An idempotent version of os.makedirs().  If the dir already exists, do
    nothing and return without raising an exception.  If this call
creates the
    dir, return without raising an exception.  If there is an error that
    prevents creation or if the directory gets deleted after make_dirs()
creates
    it and before make_dirs() checks that it exists, raise an exception.
    """
    tx = None
    try:
        os.makedirs(dirname, mode)
    except OSError, x:
        tx = x

    if not os.path.isdir(dirname):
        if tx:
            raise tx
        raise exceptions.IOError, "unknown error prevented creation of
directory, or deleted the directory immediately after creation: %s" %
dirname # careful not to construct an IOError with a 2-tuple, as that
has a special meaning...

----------
nosy: +zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675>
_______________________________________

From report at bugs.python.org  Wed Nov 12 00:00:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Nov 2008 23:00:17 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226444417.18.0.329650799396.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The latest patch from Victor looks good.  A few comments:

(1) the number of bits should be computed first directly using C 
arithmetic, and only recomputed using PyLong arithmetic if the C 
computations overflow.  For one thing, overflow is going to be very rare 
in practice;  for another, in the sort of applications that use 
.numbits(), speed of numbits() is often critical.

(2) Just as a matter of style, I think "if (x == NULL)" is preferable
to "if (!x)".  At any rate, the former style is much more common in
Python source.

(3) the reference counting all looks good.

(4) I quite like the idea of having numbits be a property rather than a 
method---might still be worth considering?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Wed Nov 12 00:05:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Nov 2008 23:05:34 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1226444734.95.0.410799280327.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed as r67190. Thanks for the review.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Wed Nov 12 00:26:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Nov 2008 23:26:24 +0000
Subject: [issue1328851] pclose raises spurious exception on win32
Message-ID: <1226445984.26.0.554207673825.issue1328851@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The subprocess module does return the correct exit code.
It should be used instead.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1328851>
_______________________________________

From report at bugs.python.org  Wed Nov 12 00:57:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Nov 2008 23:57:31 +0000
Subject: [issue1685] linecache .updatecache fails on utf8 encoded files
In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>
Message-ID: <1226447851.55.0.459931083863.issue1685@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
_______________________________________

From report at bugs.python.org  Wed Nov 12 01:02:51 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Wed, 12 Nov 2008 00:02:51 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1226448171.22.0.178245277672.issue3439@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

In stdtypes.rst, x.numbits should be listed in the table under
"Bit-string Operations on Integer Types" and not in the table of
operations supported by all numeric types.

> (1) the number of bits should be computed first directly using C 
> arithmetic, and only recomputed using PyLong arithmetic if the C 
> computations overflow.

+1

> (4) I quite like the idea of having numbits be a property rather than a 
> method---might still be worth considering?

I'm not against.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Wed Nov 12 01:33:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2008 00:33:12 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1226444417.18.0.329650799396.issue3439@psf.upfronthosting.co.za>
Message-ID: <200811120132.19260.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

[Mark Dickinson]
> (1) the number of bits should be computed first directly using ...

_PyLong_NumBits() : done. But the result type is always long.

> (2) Just as a matter of style, I think "if (x == NULL)" is preferable

done

> (4) I quite like the idea of having numbits be a property rather than a
> method---might still be worth considering?

I agree, so in the new patch, numbits is now a property.

[Fredrik Johansson]
> In stdtypes.rst, x.numbits should be listed in the table under
> "Bit-string Operations on Integer Types"

done

--

10
>>> x=1023L; x.numbits
10L
>>> x=2**(2**10); n=x.numbits; n, n.numbits
(1025L, 11L)

Added file: http://bugs.python.org/file11990/numbits-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: numbits-4.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081112/77372550/attachment.txt>

From report at bugs.python.org  Wed Nov 12 02:18:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 01:18:59 +0000
Subject: [issue3100] weakref subclass segfault
In-Reply-To: <1213327200.12.0.747745402104.issue3100@psf.upfronthosting.co.za>
Message-ID: <1226452739.49.0.189327591262.issue3100@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was fixed 4 months ago with r64309 (trunk, 2.6) and r64310 (2.5).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3100>
_______________________________________

From report at bugs.python.org  Wed Nov 12 02:22:06 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Nov 2008 01:22:06 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226452926.91.0.942054316293.issue4296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, the patch looks good.  Thanks.  Before committing, please add one
other test that verifies the relationship between "in" in membership
tests and "in" in a for-loop:


for constructor in list, tuple, dict.fromkeys, set, collections.deque:
    container = constructor([float('nan'), 1, None, 'abc'])
    for elem in container :
         self.assert_(elem in container)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Wed Nov 12 02:37:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 01:37:30 +0000
Subject: [issue1471243] Visual Studio 2005 CRT error handler
Message-ID: <1226453850.5.0.824521434119.issue1471243@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Already implemented, since r47223.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471243>
_______________________________________

From report at bugs.python.org  Wed Nov 12 02:59:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 01:59:35 +0000
Subject: [issue2971] test_zipfile64 fails
In-Reply-To: <1211778804.81.0.308743565458.issue2971@psf.upfronthosting.co.za>
Message-ID: <1226455175.66.0.782577035663.issue2971@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r67194.
Note that the test is now always skipped: too big!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2971>
_______________________________________

From report at bugs.python.org  Wed Nov 12 07:28:51 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 12 Nov 2008 06:28:51 +0000
Subject: [issue4079] new urllib2.Request 'timeout' attribute needs to have a
	default
In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za>
Message-ID: <20081112062837.GC5669@goofy>


Senthil <orsenthil at gmail.com> added the comment:

http://bugs.python.org/issue4079

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4079>
_______________________________________

From report at bugs.python.org  Wed Nov 12 09:17:20 2008
From: report at bugs.python.org (Piers Lauder)
Date: Wed, 12 Nov 2008 08:17:20 +0000
Subject: [issue4302] smtplib.py initialisation defect
In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
Message-ID: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>


New submission from Piers Lauder <piers at it.usyd.edu.au>:

smtplib does not initialise the valriable 'sock' in the case where
'host' is NULL on instantiation of smtplib.SMTP.

Eg:

% python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> client=smtplib.SMTP('')
>>> client.sendmail('from at home', 'to at home', 'test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/smtplib.py", line 676, in sendmail
    if not (200 <= self.ehlo()[0] <= 299):
  File "/usr/lib/python2.5/smtplib.py", line 397, in ehlo
    self.putcmd("ehlo", name or self.local_hostname)
  File "/usr/lib/python2.5/smtplib.py", line 333, in putcmd
    self.send(str)
  File "/usr/lib/python2.5/smtplib.py", line 318, in send
    if self.sock:
AttributeError: SMTP instance has no attribute 'sock'
>>>

The fix is to add "self.sock = None" in __init__ if host is not set,
and then the behaviour is much more helpful:

% python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> client=smtplib.SMTP('')
>>> client.sendmail('from at home', 'to at home', 'test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/smtplib.py", line 678, in sendmail
    if not (200 <= self.ehlo()[0] <= 299):
  File "/usr/lib/python2.5/smtplib.py", line 399, in ehlo
    self.putcmd("ehlo", name or self.local_hostname)
  File "/usr/lib/python2.5/smtplib.py", line 335, in putcmd
    self.send(str)
  File "/usr/lib/python2.5/smtplib.py", line 327, in send
    raise SMTPServerDisconnected('please run connect() first')
smtplib.SMTPServerDisconnected: please run connect() first
>>>

----------
components: Library (Lib)
files: smtplib-diff-c
messages: 75777
nosy: piers
severity: normal
status: open
title: smtplib.py initialisation defect
type: behavior
versions: Python 2.5.3
Added file: http://bugs.python.org/file11991/smtplib-diff-c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4302>
_______________________________________

From report at bugs.python.org  Wed Nov 12 09:53:43 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 12 Nov 2008 08:53:43 +0000
Subject: [issue4302] smtplib.py initialisation defect
In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
Message-ID: <1226480023.72.0.998562535038.issue4302@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This issue can be fixed by backporting r60975.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4302>
_______________________________________

From report at bugs.python.org  Wed Nov 12 10:00:54 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 09:00:54 +0000
Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu
In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>
Message-ID: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

ctypes fails to build on arm-linux-gnu, see
http://python.org/dev/buildbot/2.5/ARM Linux 2.5/builds/3/step-compile/0

gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/./Include
-Ibuild/temp.linux-armv5tel-2.5/libffi/include
-Ibuild/temp.linux-armv5tel-2.5/libffi
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/libffi/src
-I. -IInclude -I./Include -I/usr/local/include
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Include
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build -c
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c
-o
build/temp.linux-armv5tel-2.5/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.o
In file included from
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:127:
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/ctypes.h:72:
error: expected specifier-qualifier-list before 'ffi_closure'
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:
In function 'CFuncPtr_new':
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:2955:
error: 'CThunkObject' has no member named 'pcl'

this is a regression compared to 2.5.2. Not seen on 2.6 or 3.0. Please
consider a fix before 2.5.3 is released.

----------
messages: 75779
nosy: doko
priority: release blocker
severity: normal
status: open
title: [2.5 regression] ctypes fails to build on arm-linux-gnu
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4303>
_______________________________________

From report at bugs.python.org  Wed Nov 12 10:01:27 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 09:01:27 +0000
Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu
In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>
Message-ID: <1226480487.45.0.271651515465.issue4303@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
assignee:  -> theller
components: +ctypes
nosy: +theller
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4303>
_______________________________________

From report at bugs.python.org  Wed Nov 12 10:34:41 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 09:34:41 +0000
Subject: [issue4304] build mode which fails for build failures in extensions
In-Reply-To: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za>
Message-ID: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

as seen in issue4303, the buildbots don't complain about build failures
in extensions. it would be nice to have a mode, where the build fails
when an extension doesn't build, but is expected to build. exceptions to
this set of expected builds should be configurable.

----------
components: Build
messages: 75780
nosy: doko
severity: normal
status: open
title: build mode which fails for build failures in extensions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4304>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:00:01 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 10:00:01 +0000
Subject: [issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips
	instead of mipsel)
In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
Message-ID: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

seen on the mipsel buildbot

running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
  File "./setup.py", line 1880, in <module>
    main()
  File "./setup.py", line 1875, in main
    'Lib/smtpd.py']
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/core.py",
line 152, in setup
    dist.run_commands()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 975, in run_commands
    self.run_command(cmd)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
    cmd_obj.run()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build.py",
line 134, in run
    self.run_command(cmd_name)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
    cmd_obj.run()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 343, in run
    self.build_extensions()
  File "./setup.py", line 201, in build_extensions
    build_ext.build_extensions(self)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 469, in build_extensions
    self.build_extension(ext)
  File "./setup.py", line 234, in build_extension
    if not self.configure_ctypes(ext):
  File "./setup.py", line 1684, in configure_ctypes
    execfile(ffi_configfile, globals(), fficonfig)
  File "build/temp.linux-mips-2.7-pydebug/libffi/fficonfig.py", line 32,
in <module>
    ffi_sources += ffi_platforms['MIPS']
KeyError: 'MIPS'
[47349 refs]
make: *** [sharedmods] Error 1

----------
assignee: theller
components: ctypes
messages: 75781
nosy: doko, theller
severity: normal
status: open
title: ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4305>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:09:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 10:09:05 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226484545.64.0.747093740413.issue4293@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Py_AddPendingCall is used inside signal handlers.
It seems that there is a (tiny) chance that a signal interrupts the
program inside Py_MakePendingCalls, while the pendinglock is held.
Py_AddPendingCall would try to acquire this lock again and deadlock.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:13:11 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 12 Nov 2008 10:13:11 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226484791.23.0.12252454068.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Right.
Isn't the best way to avoid it to block signals just while we pop the 
queue?  I'll see if python has a portable sigaction thing to do that.
Otherwise we'd have to start to mess with a "volatile busy" flag again 
and possibly introduce tricky race conditions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Wed Nov 12 14:16:32 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2008 13:16:32 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I never used the email package, so my issue is maybe not a bug. I'm 
trying to send an email with diacritics in the subject and the body. 
I'm french so it's natural to use characters not in the ASCII range. I 
wrote this small program:

def main():
    # coding: utf8
    ADDRESS = 'victor.stinner at haypocalc.com'
    from email.mime.text import MIMEText
    msg = MIMEText('accent ???', 'plain', 'utf-8')
    msg['Subject'] = 'sujet ???'
    msg['From'] = ADDRESS
    msg['To'] = ADDRESS
    text = msg.as_string()
    print("--- FLATTEN ---")
    print(text)
    return
    import smtplib
    client=smtplib.SMTP('smtp.free.fr')
    client.sendmail(ADDRESS, ADDRESS, text)
    client.quit()
main()

(remove the "return" to really send the email)

The problem:
  (...)
  File "/home/haypo/prog/py3k/Lib/email/generator.py", line 141, in 
_write_headers
    header_name=h, continuation_ws='\t')
  File "/home/haypo/prog/py3k/Lib/email/header.py", line 189, in 
__init__
    self.append(s, charset, errors)
  File "/home/haypo/prog/py3k/Lib/email/header.py", line 262, in 
append
    input_bytes = s.encode(input_charset, errors)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
6-8: ordinal not in range(128)

I don't understand why it uses ASCII whereas I specified that I would 
like to use the UTF-8 charset.

My attached patch reused the message charset to encode the headers, 
but use ASCII if the header can be encoded as ASCII. The patch 
included an unit test.

----------
components: Library (Lib)
files: email_mime_unicode.patch
keywords: patch
messages: 75784
nosy: haypo
severity: normal
status: open
title: email package with unicode subject/body
versions: Python 3.0
Added file: http://bugs.python.org/file11992/email_mime_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Wed Nov 12 14:30:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2008 13:30:39 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1226496639.44.0.872023396099.issue4306@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The first email example (the one using a file in the library 
documentation) opens a text in binary mode and use the ASCII charset. 
It's quite strange because I expect an text to use only characters, 
something like:
   charset = 'ASCII'
   # Create a text/plain message
   with open(textfile, 'r', encoding=charset) as fp:
      msg = MIMEText(fp.read(), 'plain', charset)

... and the example doesn't work:
Traceback (most recent call last):
  File "y.py", line 11, in <module>
    msg = MIMEText(fp.read())
  File "/home/haypo/prog/py3k/Lib/email/mime/text.py", line 30, in 
__init__
    self.set_payload(_text, _charset)
  File "/home/haypo/prog/py3k/Lib/email/message.py", line 234, in 
set_payload
    self.set_charset(charset)
  File "/home/haypo/prog/py3k/Lib/email/message.py", line 269, in 
set_charset
    cte(self)
  File "/home/haypo/prog/py3k/Lib/email/encoders.py", line 60, in 
encode_7or8bit
    orig.encode('ascii')
AttributeError: 'bytes' object has no attribute 'encode'

Solutions:
 - Message.set_payload() have to block type different than str
   => or would it be possible to use bytes as payload???
 - Fix the example to use characters

The new attached patch fixes the example and check type in 
Message.set_payload().

Added file: http://bugs.python.org/file11993/email_example.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Wed Nov 12 15:24:53 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2008 14:24:53 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1226499893.97.0.783642289996.issue4306@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Please make this a release blocker and I will look at it this 
weekend.   -Barry"

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Wed Nov 12 16:19:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 15:19:04 +0000
Subject: [issue1949] test_ntpath.py converted to unittest
In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za>
Message-ID: <1226503144.54.0.151002845581.issue1949@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Done since r61926.

----------
nosy: +amaury.forgeotdarc
resolution: accepted -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1949>
_______________________________________

From report at bugs.python.org  Wed Nov 12 17:24:37 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 12 Nov 2008 16:24:37 +0000
Subject: [issue4307] inspect.FullArgSpec does not match the docs
In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
Message-ID: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The docs say that inspect.FullArgSpec is a named tuple

FullArgSpec(args, varargs, varkw, defaults, kwonlyargs, kwonlydefaults,
annotations)

However the implementation has "kwdefaults" instead of "kwonlydefaults".
The name in the docs seems to make more sense. A patch fixing this is
attached.

----------
components: Library (Lib)
files: inspect.patch
keywords: patch
messages: 75788
nosy: hagen
severity: normal
status: open
title: inspect.FullArgSpec does not match the docs
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11994/inspect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4307>
_______________________________________

From report at bugs.python.org  Wed Nov 12 17:27:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 16:27:31 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1226507251.63.0.523193987003.issue4306@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Wed Nov 12 17:41:21 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 12 Nov 2008 16:41:21 +0000
Subject: [issue4308] repr of httplib.IncompleteRead is stupid
In-Reply-To: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>
Message-ID: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

The repr of httplib.IncompleteRead contains all the data in the read so far.

This is stupid. Consider the download of a 100Mb file which fails after
30Mb. You end up with 90Mb of text in the log entry logged with the
python logging framework 
(eg: logger.error('Something bad happened',exc_info=True) )

----------
components: Library (Lib)
messages: 75789
nosy: cjw296
severity: normal
status: open
title: repr of httplib.IncompleteRead is stupid
type: resource usage
versions: Python 2.5, Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4308>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:57:36 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Nov 2008 17:57:36 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226512656.18.0.632371371591.issue4296@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file11989/issue4296.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:58:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Nov 2008 17:58:47 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226512727.05.0.453098480633.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Before committing, please add one
> other test that verifies the relationship between "in" in membership
> tests and "in" in a for-loop:

Added.  (To test_contains, since this seems like a more appropriate place 
than test_float.)

Added file: http://bugs.python.org/file11995/issue4296.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Wed Nov 12 19:36:15 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 12 Nov 2008 18:36:15 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226514975.18.0.266585256485.issue4111@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Nov 12 21:31:20 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 12 Nov 2008 20:31:20 +0000
Subject: [issue4226] Python core crashes with associated files.
In-Reply-To: <1225250600.04.0.735766094217.issue4226@psf.upfronthosting.co.za>
Message-ID: <1226521880.7.0.498798459607.issue4226@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

This problem was repaired by the python3.0 rc1+ of November 5 trunk
snapshot.  I suggest retirement of Issue4226.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4226>
_______________________________________

From report at bugs.python.org  Wed Nov 12 21:37:02 2008
From: report at bugs.python.org (And Clover)
Date: Wed, 12 Nov 2008 20:37:02 +0000
Subject: [issue2610] string representation of range and dictionary views
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1226522222.24.0.952879518163.issue2610@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

I would like to see something along the general lines of bmiller's patch
for dict views in a 3.x release... there are probably other iterators
that could do with chattier reprs also. (Range, on the other hand, is
fine as it is.)

It's not just at the interactive prompt that good reprs are useful, it's
also in debugging: debug-prints in scripts in general, web application
error pages that dump variable information, error detail logging to a
database for inspection long after the ability to inspect the value has
passed, and so on.

I think it's better to put the feature in repr than require all these
things - everything that might want to display values helpfully - to
implement detection and prettification for specific iterators.

Sure, you can apply list() if you know in advance you're going to need
to, but for beginners and debuggers getting the information out there
without having to ask for it is a real win. I certainly remember how
pleasantly surprised I was when learning Python 1.something and finding
it just told me what I wanted to know without having to ask for it - in
contrast to previous tedious languages that only ever said 'object' or
'[Array]'...

I can't really think of any advantage to having repr keep that
information hidden.

----------
nosy: +aclover

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
_______________________________________

From report at bugs.python.org  Wed Nov 12 21:53:15 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 12 Nov 2008 20:53:15 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

'''
    http://docs.python.org/dev/3.0/library/ctypes.html

    Where web page says

    >>> printf("An int %d, a double %f\n", 1234, c_double(3.14))
    Integer 1234, double 3.1400001049
    31
    >>>

    should instead read
 
    >>> printf(c_char_p("An int %d, a double %f\n"), 1234, c_double(3.14))
    An int 1234, a double 3.140000
    31

    Although the intent of the message is clear, it is inexact with
    regard to "An int" and "a double".  Core dump is bigger problem:


    Processor: Dual-Core AMD Opteron(tm) Processor 2218
    Python: Python 3.0rc1+ (py3k, Nov  5 2008, 14:44:46) 
            [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2

    core dumps by segmentation fault for all the printf examples without
    specifying c_char_p("string").
'''

# this program succeeds

from ctypes import *
libc = CDLL("libc.so.6")
print(libc.printf(c_char_p("An int %d, a double %f\n"), 1234,
c_double(3.14)))

----------
assignee: georg.brandl
components: Documentation
messages: 75793
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: ctypes documentation
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:07:26 2008
From: report at bugs.python.org (Kyle Brandt)
Date: Wed, 12 Nov 2008 21:07:26 +0000
Subject: [issue4310] Comparison of two ints returns wrong result
In-Reply-To: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za>
Message-ID: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za>


New submission from Kyle Brandt <kyle at kbrandt.com>:

The attached program returns a false result on one of my computers with
a Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz processor.  Is seems the
comparison of two int does not perform correctly.  I have python 2.5.2
and  2.6.27-7-generic kernel.

The lines of interest are 89-71:

print type(f_p),type(largest),f_p,largest
if f_p > largest:
     print 'foo'
     largest = f_p

When running this code:
# python id_11-2.py | grep 70600 
<type 'int'> <type 'int'> 70600674 51267216
# python id_11-2.py | grep foo #doesn't return anything

When I run the same code on another machine the end result of the
program is 70600674, whereas my current machine the end result is
51267216.

----------
files: id_11-2.py
messages: 75794
nosy: kbrandt
severity: normal
status: open
title: Comparison of two ints returns wrong result
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11996/id_11-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4310>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:17:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 21:17:21 +0000
Subject: [issue4226] Python core crashes with associated files.
In-Reply-To: <1225250600.04.0.735766094217.issue4226@psf.upfronthosting.co.za>
Message-ID: <1226524641.36.0.813022620819.issue4226@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4226>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:17:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 21:17:40 +0000
Subject: [issue2610] string representation of range and dictionary views
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1226524660.59.0.515634901158.issue2610@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It's going to have to be deferred to 3.1.

----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:20:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 21:20:47 +0000
Subject: [issue4308] repr of httplib.IncompleteRead is stupid
In-Reply-To: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>
Message-ID: <1226524847.38.0.824907854724.issue4308@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Would you like to work on a patch?

----------
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1 -Python 2.5, Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4308>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:24:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 21:24:14 +0000
Subject: [issue4307] inspect.FullArgSpec does not match the docs
In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
Message-ID: <1226525054.92.0.957113209284.issue4307@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This patch looks good.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4307>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:26:55 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Nov 2008 21:26:55 +0000
Subject: [issue4310] Comparison of two ints returns wrong result
In-Reply-To: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za>
Message-ID: <1226525215.22.0.399837901637.issue4310@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You're mixing tabs and spaces in your code.

The 'if f_p > largest' line occurs one indentation level further out
than the preceding print.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4310>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:32:11 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 12 Nov 2008 21:32:11 +0000
Subject: [issue4307] inspect.FullArgSpec does not match the docs
In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
Message-ID: <1226525531.12.0.111138199126.issue4307@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Agreed!

----------
nosy: +christian.heimes
priority:  -> normal
resolution:  -> accepted
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4307>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:39:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 21:39:20 +0000
Subject: [issue4307] inspect.FullArgSpec does not match the docs
In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
Message-ID: <1226525960.61.0.639722515344.issue4307@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! Fixed in r67203.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4307>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:46:57 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Nov 2008 21:46:57 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226526417.79.0.754955745111.issue4296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Reviewed the updated patch and all is well.  Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:53:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 12 Nov 2008 21:53:17 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226526797.32.0.29980339177.issue4296@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Mark, would you do the honor, please?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Wed Nov 12 23:19:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Nov 2008 22:19:46 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1226528386.92.0.947488206931.issue4233@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can this change be backported to 2.6 and 2.7?
r67106 says that it "Changed semantic of close() on file objects with 
closefd=False".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Wed Nov 12 23:35:25 2008
From: report at bugs.python.org (Alejandro)
Date: Wed, 12 Nov 2008 22:35:25 +0000
Subject: [issue4311] Race condition on Multiprocessing module documentation
In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
Message-ID: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>


New submission from Alejandro <alejolp at alejolp.com>:

The "devel" documentation of the "Multiprocessing" module at the
"Exchanging objects between processes" section has the following example
snippet:

from multiprocessing import Process, Queue

def f(q):
    q.put([42, None, 'hello'])

 if __name__ == '__main__':
     q = Queue()
     p = Process(target=f, args=(q,))
     p.start()
     print q.get()    # prints "[42, None, 'hello']"
     p.join()

The last two lines should be swapped to avoid a race condition:

     p.join()
     print q.get()    # prints "[42, None, 'hello']"

BTW, Nice work. Keep on going folks =)

----------
assignee: georg.brandl
components: Documentation
messages: 75804
nosy: alejolp, georg.brandl
severity: normal
status: open
title: Race condition on Multiprocessing module documentation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4311>
_______________________________________

From report at bugs.python.org  Wed Nov 12 23:38:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 22:38:23 +0000
Subject: [issue4311] Race condition on Multiprocessing module documentation
In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
Message-ID: <1226529503.16.0.859287886705.issue4311@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Why? The q.get() will block until an item is put on it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4311>
_______________________________________

From report at bugs.python.org  Wed Nov 12 23:39:23 2008
From: report at bugs.python.org (Alejandro)
Date: Wed, 12 Nov 2008 22:39:23 +0000
Subject: [issue4311] Race condition on Multiprocessing module documentation
In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
Message-ID: <1226529563.06.0.844161437251.issue4311@psf.upfronthosting.co.za>


Alejandro <alejolp at alejolp.com> added the comment:

Ups. My mistake. Sorry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4311>
_______________________________________

From report at bugs.python.org  Wed Nov 12 23:56:49 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 12 Nov 2008 22:56:49 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1226530609.17.0.211083668191.issue4233@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Yes, it should. I've lefted the bug open for this very reason.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Thu Nov 13 00:13:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2008 23:13:25 +0000
Subject: [issue4311] Race condition on Multiprocessing module documentation
In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
Message-ID: <1226531605.05.0.725517732946.issue4311@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4311>
_______________________________________

From report at bugs.python.org  Thu Nov 13 00:26:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Nov 2008 23:26:20 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226532380.45.0.705634496435.issue4296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed, r67204.  Thanks guys, and thanks especially to Michael for 
spotting this before 3.0 final.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Thu Nov 13 02:30:12 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 13 Nov 2008 01:30:12 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1226539812.91.0.313366002498.issue2054@psf.upfronthosting.co.za>


Changes by Todd Whiteman <twhitema at yahoo.com.au>:


----------
nosy: +twhitema

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Nov 13 03:16:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 13 Nov 2008 02:16:47 +0000
Subject: [issue4302] smtplib.py initialisation defect
In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
Message-ID: <1226542607.14.0.913385840709.issue4302@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file11997/smtplib_minor_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4302>
_______________________________________

From report at bugs.python.org  Thu Nov 13 03:26:51 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Nov 2008 02:26:51 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226543211.9.0.671458063734.issue4111@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 03:33:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Nov 2008 02:33:22 +0000
Subject: [issue4302] smtplib.py initialisation defect
In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
Message-ID: <1226543602.13.0.0755581183137.issue4302@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4302>
_______________________________________

From report at bugs.python.org  Thu Nov 13 03:45:06 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2008 02:45:06 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226544306.14.0.67517230732.issue4111@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

It appears that Apple has dtracified their Python exeutable in Leopard.
Any chance that they can be persuaded to release a patch?  I'm working
on a patch (based on some work from a friend at work), but it seems like
Apple already has a horse in the race.  It would be nice if we could
see what they have done.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 03:58:00 2008
From: report at bugs.python.org (Brett Hoerner)
Date: Thu, 13 Nov 2008 02:58:00 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226545080.87.0.96282157006.issue4111@psf.upfronthosting.co.za>


Brett Hoerner <bretthoerner at gmail.com> added the comment:

They have released the changes, that's what my patch (attached to the
issue) is based on.

It's working, it just needs to be cleaned up (it will fail, I believe,
for people on systems without DTrace - as I said I'm not very familiar
with Makefiles).

You can use it now against 2.6 and probably with very few changes
against 2.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 04:31:46 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2008 03:31:46 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1226545080.87.0.96282157006.issue4111@psf.upfronthosting.co.za>
Message-ID: <18715.40858.196198.259296@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Brett> They have released the changes, that's what my patch (attached to
    Brett> the issue) is based on.

I see the reference to Apple in your original post, but can't find anything
related to dtrace & python starting from the URL you gave.  Do you have
something more specific?

At this point Jeff's code does a fair bit more than simply tracing the
CALL_FUNCTION opcode but needs some work with the other CALL_FUNCTION_*
opodes.  It also has some obmalloc tracing which I've not yet tested.  I
would have thought Apple would more heavily instrument the interpreter than
it appears they have.

    Brett> It's working, it just needs to be cleaned up (it will fail, I
    Brett> believe, for people on systems without DTrace - as I said I'm not
    Brett> very familiar with Makefiles).

I took care of the configure.in/Makefile.pre.in stuff today.  The intent is
that you would configure using --enable-dtrace then not have to do anything
else to build a dtrace-aware interpreter.

    Brett> You can use it now against 2.6 and probably with very few changes
    Brett> against 2.5.  

We are using 2.4 at work and it works there.  I'm fairly certain we should
be able to get it working for the entire 2.x and 3.x series with only a
little effort.

(I still need to get approval to release it, but I don't think that will be
a big deal.  I've already alerted my boss and he's generally receptive to
such things.)

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 05:26:04 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Nov 2008 04:26:04 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1226550364.53.0.39048335955.issue1699259@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch no longer applies to trunk, but that would be trivial to fix.

Changes like these have been accepted with little resistance in the past 
(see e.g. issue651362), so I don't see why this patch has been pending 
for  so long.  (In general, I am -0 on adding const modifiers because 
they tend to trigger an avalanche of changes, but arguably this is the 
"right thing to do.")   

A few comments:

* Documentation needs to be updated in Doc/c-api/sys.rst. 

* Any reason why PySys_SetPath(char *) is left out?

* Same for PySys_SetArgv(int, char **)

* Similar changes are proposed in issue1772673.  Maybe these two issues 
can be dealt with together.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Thu Nov 13 07:12:56 2008
From: report at bugs.python.org (Wang Chun)
Date: Thu, 13 Nov 2008 06:12:56 +0000
Subject: [issue2173] Python fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1226556776.58.0.509613274614.issue2173@psf.upfronthosting.co.za>


Wang Chun <yaohua2000 at gmail.com> added the comment:

This issue remains unsolved in the latest python 3.0rc2+ subversion 
repository as of 2008-11-13.

----------
nosy: +wangchun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
_______________________________________

From report at bugs.python.org  Thu Nov 13 08:19:28 2008
From: report at bugs.python.org (Chris Withers)
Date: Thu, 13 Nov 2008 07:19:28 +0000
Subject: [issue4308] repr of httplib.IncompleteRead is stupid
In-Reply-To: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>
Message-ID: <1226560768.47.0.425729569118.issue4308@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Please find attached a patch against the trunk.
I'd really appreciate it if this could get merged to the 2.5 and 2.6
branches too, in case of a future release there.

----------
keywords: +patch
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file11998/incompleteread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4308>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:45:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 Nov 2008 10:45:17 +0000
Subject: [issue887237] Machine integers
Message-ID: <1226573117.75.0.490063479892.issue887237@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is it be feasible to add arithmetic operations
to the ctypes integer types?  Since ctypes is now
in the core, it would seem better to enhance ctypes
than provide a new module.

I think this would be valuable for rapid prototyping
of an algorithm in Python before translating it into
C.  In particular, it might help with detecting some
common C code bugs involving undefined behaviour---for
example, overflow in signed-integer arithmetic.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:18:16 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 13 Nov 2008 13:18:16 +0000
Subject: [issue4312] Unicode in distutils meta-data?
In-Reply-To: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>
Message-ID: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

http://docs.python.org/dev/3.0/distutils/setupscript.html#additional-meta-data

says "None of the string values may be Unicode.". How is this to be
interpreted (or changed) w.r.t. Python 3.0?

----------
assignee: georg.brandl
components: Documentation
messages: 75816
nosy: georg.brandl, hagen
severity: normal
status: open
title: Unicode in distutils meta-data?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4312>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:24:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 13:24:17 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

With Python 3.0 trunk on Ubuntu Gutsy, IDLE crashs at exit. gdb trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210763072 (LWP 9441)]
0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0
(gdb) where
#0  0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0
#1  0xb7a3cb36 in TkTextFreeTag () from /usr/lib/libtk8.4.so.0
#2  0xb7a2aef1 in ?? () from /usr/lib/libtk8.4.so.0
#3  0x084ade70 in ?? ()
#4  0x084b2410 in ?? ()
#5  0xbfecb248 in ?? ()
#6  0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0
#7  0xbfecb250 in ?? ()
#8  0x084ade84 in ?? ()
#9  0xbfecb268 in ?? ()
#10 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0
#11 0x084ade84 in ?? ()
#12 0x00000001 in ?? ()
#13 0x00000000 in ?? ()

----------
messages: 75817
nosy: haypo
severity: normal
status: open
title: IDLE segfault at exit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:25:54 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 13:25:54 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226582754.79.0.610947559586.issue4313@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The crash occurs when I close a window if a file was open. I can 
reproduce the crash on Debian Sid, so it's not a problem of an old 
library version.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:49:11 2008
From: report at bugs.python.org (Walter Doekes)
Date: Thu, 13 Nov 2008 13:49:11 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1226584151.95.0.821776085075.issue1222@psf.upfronthosting.co.za>


Changes by Walter Doekes <walter+python at wjd.nu>:


----------
nosy: +wdoekes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:58:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 13:58:22 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226584702.9.0.700784697651.issue4313@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug looks to be specific to Python3 but may comes from Tk and not 
directly from tkinter module. I recompiled Tk with debug symbols to get 
a better backtrace:
malformed bucket chain in Tcl_DeleteHashEntry

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e178c0 (LWP 23520)]
0xb7fd1424 in __kernel_vsyscall ()
(gdb) where
#0  0xb7fd1424 in __kernel_vsyscall ()
#1  0xb7e43640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7e45018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb78c2cff in Tcl_PanicVA () from /usr/lib/libtcl8.4.so.0
#4  0xb78c2d27 in Tcl_Panic () from /usr/lib/libtcl8.4.so.0
#5  0xb78a469d in Tcl_DeleteHashEntry () from /usr/lib/libtcl8.4.so.0
#6  0xb7922c33 in Tk_FreeColor (colorPtr=0x987cfb0)
    at /tmp/tk8.4-8.4.19/unix/../generic/tkColor.c:492
#7  0xb79166cd in Tk_Free3DBorder (border=0x985b830)
    at /tmp/tk8.4-8.4.19/unix/../generic/tk3d.c:440
#8  0xb7938a6e in Tk_FreeOptions (specs=0xb79df240, 
widgRec=0x986f9d8 "", display=0x9733c88,
    needFlags=0) 
at /tmp/tk8.4-8.4.19/unix/../generic/tkOldConfig.c:1039
#9  0xb79984bb in DestroyText (memPtr=0x986f9d8 "")
    at /tmp/tk8.4-8.4.19/unix/../generic/tkText.c:996
#10 0xb78ca115 in Tcl_EventuallyFree () from /usr/lib/libtcl8.4.so.0
#11 0xb7998bae in TextEventProc (clientData=0x986f9d8, 
eventPtr=0xbfcea6bc)
    at /tmp/tk8.4-8.4.19/unix/../generic/tkText.c:1270
#12 0xb7928026 in Tk_HandleEvent (eventPtr=0xbfcea6bc)
    at /tmp/tk8.4-8.4.19/unix/../generic/tkEvent.c:1037
#13 0xb7945c1c in Tk_DestroyWindow (tkwin=0x987d9b0)
    at /tmp/tk8.4-8.4.19/unix/../generic/tkWindow.c:1423
#14 0xb7920020 in Tk_DestroyObjCmd (clientData=0x9735210, 
interp=0x961ea80, objc=2,
    objv=0xbfcea910) at /tmp/tk8.4-8.4.19/unix/../generic/tkCmds.c:471
#15 0xb786e926 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#16 0xb786eb79 in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
#17 0xb7b7cc0d in Tkapp_Call (selfptr=0xb7c97918, args=0xb6da1e4c)
    at /home/haypo/prog/py3k/Modules/_tkinter.c:1241
#18 0x0812121d in PyCFunction_Call (func=0xb7bfc6cc, arg=0xb6da1e4c, 
kw=0x0)
    at Objects/methodobject.c:81
#19 0x080942e4 in call_function (pp_stack=0xbfceab38, oparg=2) at 
Python/ceval.c:3398
#20 0x08091027 in PyEval_EvalFrameEx (f=0x9a4f6dc, throwflag=0) at 
Python/ceval.c:2205
(...)

And the Python backtrace:
(gdb) pystack
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1929): destroy
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
/home/haypo/prog/py3k/Lib/idlelib/WindowList.py (70): destroy
/home/haypo/prog/py3k/Lib/idlelib/EditorWindow.py (887): _close
/home/haypo/prog/py3k/Lib/idlelib/PyShell.py (260): _close
/home/haypo/prog/py3k/Lib/idlelib/FileList.py (41): open
/home/haypo/prog/py3k/Lib/idlelib/PyShell.py (1382): main
Tools/scripts/idle (5): <module>

So if I add the source code to the trace:
---------------------------------------------------------------
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1929): destroy
    def destroy(self):
        """Destroy this and all descendants widgets."""
        for c in list(self.children.values()): c.destroy()
        self.tk.call('destroy', self._w)
        if self._name in self.master.children: <~~~ HERE
            del self.master.children[self._name]
        Misc.destroy(self)

/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
    def destroy(self):
        """Destroy this and all descendants widgets."""
        for c in list(self.children.values()): c.destroy()
        self.tk.call('destroy', self._w) <~~~ HERE
        if self._name in self.master.children:
            del self.master.children[self._name]
        Misc.destroy(self)

/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
    def destroy(self):
        """Destroy this and all descendants widgets."""
        for c in list(self.children.values()): c.destroy()
        self.tk.call('destroy', self._w) <~~~ HERE
        if self._name in self.master.children:
            del self.master.children[self._name]
        Misc.destroy(self)

/home/haypo/prog/py3k/Lib/idlelib/WindowList.py (70): destroy
    def destroy(self):
        registry.delete(self)
        Toplevel.destroy(self)
        # If this is Idle's last window then quit the mainloop
        # (Needed for clean exit on Windows 98)
        if not registry.dict:   <~~~ HERE
            self.quit()

/home/haypo/prog/py3k/Lib/idlelib/EditorWindow.py (887): _close
    def _close(self):
        (...)
        self.per.close()
        self.per = None
        self.top.destroy()
        if self.close_hook:   <~~~ HERE
            # unless override: unregister from flist, terminate if last 
window
            self.close_hook()

(...)
---------------------------------------------------------------

Hum, the Python line numbers are maybe invalid.

----------
components: +IDLE
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:08:47 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 13 Nov 2008 14:08:47 +0000
Subject: [issue4295] closing stdout in a child process on cygwin means that
	process doesn't receive bytes from stdin anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1226585327.38.0.794980950213.issue4295@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:39:38 2008
From: report at bugs.python.org (ZooKeeper)
Date: Thu, 13 Nov 2008 14:39:38 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>


New submission from ZooKeeper <zooregs at mail.ru>:

This may be a little tricky to recreate but here it is:

q = u'??????'
q.isalpha()
True

foo = u'?'
foo.isalpha()
False

So the Russian character u'?' and u'?' as well as a bunch of others is
not recognized by isalpha as a alphabetic character, which it is a
matter of fact.
This applies to both capital and regular versions of the letters.

http://en.wikipedia.org/wiki/%D0%81
http://en.wikipedia.org/wiki/Che_(Cyrillic)

Using: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32

----------
components: Extension Modules, Unicode
messages: 75820
nosy: ZooKeeper
severity: normal
status: open
title: isalpha bug
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:46:09 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2008 14:46:09 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587569.05.0.169684357049.issue4314@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Are you sure that you've used the right source code encoding for writing
these characters ?

Note that the Unicode .isalpha() method relies entirely on what the
Unicode database provides as code point information. If a character is
marked as not being alphanumeric (ie. is not in one of the categories
'Ll', 'Lu', 'Lt', 'Lo' or 'Lm'), it will return False.

----------
components:  -Extension Modules
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:48:19 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2008 14:48:19 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587699.26.0.805556078029.issue4314@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

FWIW: I get the following in Python 2.5:

>>> print u'\u0401'
?
>>> print u'\u0451'
?
>>> print u'\u0401'.isalpha()
True
>>> print u'\u0451'.isalpha()
True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:49:54 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2008 14:49:54 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587794.45.0.272743542042.issue4314@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

... and for the other character:

>>> print u'\u0427'
?
>>> print u'\u0447'
?
>>> print u'\u0427'.isalpha()
True
>>> print u'\u0447'.isalpha()
True

Looks fine.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:52:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 14:52:33 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587953.29.0.697513980235.issue4314@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Results on Linux:

With Python 2.7 trunk:
>>> print(', '.join('%s:%s' % (c, c.isalpha()) for c in u'???????'))
?:True, ?:True, ?:True, ?:True, ?:True, ?:True, ?:True

With Python 2.5.1:
>>> print(', '.join('%s:%s' % (c, c.isalpha()) for c in u'???????'))
?:True, ?:True, ?:True, ?:True, ?:True, ?:True, ?:True

With Python 3.0 trunk:
>>> print(', '.join('%s:%s' % (c, c.isalpha()) for c in '???????'))
?:True, ?:True, ?:True, ?:True, ?:True, ?:True, ?:True

Are you sure that you really typed the character "?"? Can you retry 
using unichr(0x447).isalpha()?

Test with Python3:
>>> print(' - '.join((r"\u%04x" % x) for x in range(0x400, 0x4ff+1) if 
not chr(x).isalpha()))
\u0482 - \u0483 - \u0484 - \u0485 - \u0486 - \u0487 - \u0488 - \u0489

Which means that Python thinks that all unicode character in range 
U+0400..U+04ff are letters except the range U+0482..U+0489 (thousands 
sign ? to million sign ?).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:09:43 2008
From: report at bugs.python.org (Brett Hoerner)
Date: Thu, 13 Nov 2008 15:09:43 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <18715.40858.196198.259296@montanaro-dyndns-org.local>
Message-ID: <e97e83a30811130709k66567781y40fd54806facf624@mail.gmail.com>


Brett Hoerner <bretthoerner at gmail.com> added the comment:

On Wed, Nov 12, 2008 at 9:31 PM, Skip Montanaro <report at bugs.python.org> wrote:
> I see the reference to Apple in your original post, but can't find anything
> related to dtrace & python starting from the URL you gave.  Do you have
> something more specific?

http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/

That isn't Python 3.0, that's what I guess they call Python "Apple
Version 30"?  Anyways, it's their Python 2.5.1 and their "patches"
against it are actually ed scripts, contained in fix/

That's where my patch comes from, it's just changing the .ed scripts
to a patch and applying it against 2.6

> At this point Jeff's code does a fair bit more than simply tracing the
> CALL_FUNCTION opcode but needs some work with the other CALL_FUNCTION_*
> opodes.  It also has some obmalloc tracing which I've not yet tested.  I
> would have thought Apple would more heavily instrument the interpreter than
> it appears they have.

Sun has released a patch against DTrace that probes more than just
function calls also.  At least, it provides line number and some other
information, http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff

I couldn't figure out why it broke the compile on OS X though, and
could only get it working on Solaris.

There's another problem (I think) with DTrace probes ... if the Apple
guys release Apple-Probe-Python.d and the Sun guys release
Sun-Probe-Python.d (just two scripts) and we setup our probes
differently, one or both will fail (because one may expect a probe for
foo while another expects a probe for bar).  Kind of sucks,
considering Sun was first and Apple chose to probe Python differently.
 Now we have to pick one or make a 3rd... I could be very mistaken
here, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:55:28 2008
From: report at bugs.python.org (ZooKeeper)
Date: Thu, 13 Nov 2008 15:55:28 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226591728.85.0.682524720308.issue4314@psf.upfronthosting.co.za>


ZooKeeper <zooregs at mail.ru> added the comment:

I'll investigate it in further shortly, but for now replicating the test.
print u'\u0451'
?
print u'\u0427'
?

Something must be going on here. Running Win XP.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:57:46 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 15:57:46 +0000
Subject: [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226591866.5.0.732158555989.issue4314@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

$ python
Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> print u'\u0451'
?
>>> print u'\u0427'
?

@ZooKeeper: Try Python 2.6, I guess that your bug is already fixed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:05:24 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2008 16:05:24 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <e97e83a30811130709k66567781y40fd54806facf624@mail.gmail.com>
Message-ID: <18716.20507.705271.554141@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Brett> http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/
    ...
    Brett> http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff

Thanks for the pointers.  I'll work on getting a uniform patch which
incorporates both.  (Though some of the comments in the OpenSolaris patch
are a bit scary.)

    Brett> There's another problem (I think) with DTrace probes ... if the
    Brett> Apple guys release Apple-Probe-Python.d and the Sun guys release
    Brett> Sun-Probe-Python.d (just two scripts) and we setup our probes
    Brett> differently, one or both will fail (because one may expect a
    Brett> probe for foo while another expects a probe for bar).  Kind of
    Brett> sucks, considering Sun was first and Apple chose to probe Python
    Brett> differently.

Yeah, that would suck.  It would be nice if they could agree on a common set
of probes.  I don't know that we have any contacts within the two
development communities but if we can scare some up maybe we can get them to
talk to each other. :-/

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:06:13 2008
From: report at bugs.python.org (Silas S. Brown)
Date: Thu, 13 Nov 2008 16:06:13 +0000
Subject: [issue4315] On some Python builds,
	exec in a function can't create shadows of variables if these are
	declared "global" in another function of the same module
In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
Message-ID: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>


New submission from Silas S. Brown <ssb22 at users.sourceforge.net>:

Here's the example code:

setting1 = "val1"
setting2 = "val2"

def dummy():
    global setting1

def f(x):
    d ={"setting1":setting1,"setting2":setting2}
    exec(x) in d
    return d['setting1'], d['setting2']

print f("setting1=setting2='new'")

Expected result: ('new', 'new')
Actual result: ('val1', 'new')

The presence of "global setting1" in a different function effectively
stops a shadowed setting1 from being created by the exec.

Workaround: Add a real assignment before the exec, i.e.:

def f(x):
    setting1 = 0
    exec(x)
    return setting1, setting2

or do the exec in a dictionary instead of in the current scope.

Observed in:

Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin
Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor
http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html )

Not observed in:

Python 2.5.1 (r251:54863, Aug  1 2008, 00:32:16) on SUSE Linux
Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM)
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu)

----------
components: None
messages: 75829
nosy: ssb22
severity: normal
status: open
title: On some Python builds, exec in a function can't create shadows of variables if these are declared "global" in another function of the same module
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4315>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:09:41 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 13 Nov 2008 16:09:41 +0000
Subject: [issue4295] closing stdout in a child process on cygwin means that
	process doesn't receive bytes from stdin anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1226592581.77.0.694978347817.issue4295@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Corinna Vinschen of cygwin requests a smaller test case:

http://www.cygwin.com/ml/cygwin/2008-11/msg00166.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:10:28 2008
From: report at bugs.python.org (Silas S. Brown)
Date: Thu, 13 Nov 2008 16:10:28 +0000
Subject: [issue4315] On some Python builds,
	exec in a function can't create shadows of variables if these are
	declared "global" in another function of the same module
In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
Message-ID: <1226592628.12.0.507067824651.issue4315@psf.upfronthosting.co.za>


Silas S. Brown <ssb22 at users.sourceforge.net> added the comment:

Sorry, I accidentally posted the workaround code instead of the bug
example.  This is what I should have posted:

setting1 = "val1"
setting2 = "val2"

def dummy():
    global setting1

def f(x):
    exec(x)
    return setting1,setting2

print f("setting1='new' ; setting2='new'")

Expected result: ('new', 'new')
Actual result: ('val1', 'new')

The presence of "global setting1" in a different function effectively
stops a shadowed setting1 from being created by the exec.

Workaround: Add a real assignment before the exec, i.e.:

def f(x):
    setting1 = 0
    exec(x)
    return setting1, setting2

or do the exec in a dictionary instead of in the current scope, i.e.:

def f(x):
    d ={"setting1":setting1,"setting2":setting2}
    exec(x) in d
    return d['setting1'], d['setting2']

Observed in:

Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin
Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor
http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html )

Not observed in:

Python 2.5.1 (r251:54863, Aug  1 2008, 00:32:16) on SUSE Linux
Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM)
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4315>
_______________________________________

From report at bugs.python.org  Thu Nov 13 18:09:37 2008
From: report at bugs.python.org (Russell Blau)
Date: Thu, 13 Nov 2008 17:09:37 +0000
Subject: [issue2996] IDLE "find in files" output not formatted optimally
In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za>
Message-ID: <1226596177.96.0.360702994054.issue2996@psf.upfronthosting.co.za>


Changes by Russell Blau <russblau at yahoo.com>:


----------
versions: +Python 2.5.3, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2996>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:00:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2008 18:00:52 +0000
Subject: [issue4315] On some Python builds,
	exec in a function can't create shadows of variables if these are
	declared "global" in another function of the same module
In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
Message-ID: <1226599252.0.0.0319161090745.issue4315@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4315>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:55:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 13 Nov 2008 18:55:34 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <18716.20507.705271.554141@montanaro-dyndns-org.local>
Message-ID: <bbaeab100811131055n1f528204o4e739015acd49f16@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Nov 13, 2008 at 08:05, Skip Montanaro <report at bugs.python.org> wrote:
>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Brett> http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/
>    ...
>    Brett> http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff
>
> Thanks for the pointers.  I'll work on getting a uniform patch which
> incorporates both.  (Though some of the comments in the OpenSolaris patch
> are a bit scary.)
>
>    Brett> There's another problem (I think) with DTrace probes ... if the
>    Brett> Apple guys release Apple-Probe-Python.d and the Sun guys release
>    Brett> Sun-Probe-Python.d (just two scripts) and we setup our probes
>    Brett> differently, one or both will fail (because one may expect a
>    Brett> probe for foo while another expects a probe for bar).  Kind of
>    Brett> sucks, considering Sun was first and Apple chose to probe Python
>    Brett> differently.
>
> Yeah, that would suck.  It would be nice if they could agree on a common set
> of probes.  I don't know that we have any contacts within the two
> development communities but if we can scare some up maybe we can get them to
> talk to each other. :-/
>

Obviously Ronald is the Apple insider to talk to. If you want Sun, you
might want to talk to Ted Leung and see who he can put you in touch
with.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 20:23:59 2008
From: report at bugs.python.org (Sebastian Ramacher)
Date: Thu, 13 Nov 2008 19:23:59 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1226604239.81.0.6046403613.issue1699259@psf.upfronthosting.co.za>


Sebastian Ramacher <sebastinas at users.sourceforge.net> added the comment:

At least a response, finally. 

> * Any reason why PySys_SetPath(char *) is left out?

I guess it I just missed it.
 
> * Same for PySys_SetArgv(int, char **)

That one is non-trivial and requires some rewriting of PySys_SetArgv.
And I didn't have the time to look into it any further.

I attached an updated patch.

Added file: http://bugs.python.org/file11999/sysmodule_const_char_r67215.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Thu Nov 13 20:59:02 2008
From: report at bugs.python.org (Ted Leung)
Date: Thu, 13 Nov 2008 19:59:02 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226606342.02.0.743973561529.issue4111@psf.upfronthosting.co.za>


Ted Leung <twl at sauria.com> added the comment:

And courtesy of Philip Jenvey, here I am.

I would *really* like to work to help make this happen.   Laszlo Peter
at Sun has been doing the ports of Python on Solaris, but we are not up
to 2.6 just yet.  I'm attaching a pointer to his patches against 2.5:

http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python25-07-dtrace.diff

These patches include John Levon's ustack provider, which if you care
about DTrace and Python, you want to have.

I've also had some conversations with people at Apple, and they have
agreed that they will pull DTrace probes from python.org if they got in
there.  That would solve the diverging probe problem.

I'd love to have a discussion about DTrace probe futures for CPython --
probably on python-dev.

----------
nosy: +twleung

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:28:10 2008
From: report at bugs.python.org (Soren jacobsen)
Date: Thu, 13 Nov 2008 20:28:10 +0000
Subject: [issue4316] Improper use of [] in configure.in leads to useless
	regexp in configure
In-Reply-To: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za>
Message-ID: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za>


New submission from Soren jacobsen <snj at NetBSD.org>:

"NetBSD/1.6[A-S]" is what is desired in configure, but the wrong 
configure.in goop is used, so "NetBSD/1.6A-S" is generated instead.

Apply the attached patch, commit configure.in, run autoreconf, commit 
configure.

----------
components: Build
files: netbsd-configure-in.diff
keywords: patch
messages: 75835
nosy: snj
severity: normal
status: open
title: Improper use of [] in configure.in leads to useless regexp in configure
type: compile error
Added file: http://bugs.python.org/file12000/netbsd-configure-in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4316>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:49:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 Nov 2008 20:49:51 +0000
Subject: [issue1716] String format operator '%i' fails for large floats
In-Reply-To: <1199155109.22.0.179885625842.issue1716@psf.upfronthosting.co.za>
Message-ID: <1226609391.8.0.527093817365.issue1716@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I think in 2.6 we can't change this,

I'm not sure when it happened, but it looks like this
*was* fixed for 2.6.

Closing.

----------
nosy: +marketdickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1716>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:51:00 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Nov 2008 20:51:00 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
In-Reply-To: <1226604239.81.0.6046403613.issue1699259@psf.upfronthosting.co.za>
Message-ID: <d38f5330811131250v1309b7d4iee27e72aa7959bfb@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The new patch looks fine to me.   It applies and compiles without
warnings and the changes are now reflected in the docs.  I guess
someone would need to write a NEWS entry because it is a public API
change, but otherwise I would say it should be applied.

"[U]nless 'C' has adopted overloading while I wasn't looking ...  it's
hard to imagine what kind of problems you could introduce in `C' code
by changing char* to char const* that wouldn't be caught at
compile-time." (Dave Abrahams in C++-sig)

http://mail.python.org/pipermail/cplusplus-sig/2005-December/009562.html

On Thu, Nov 13, 2008 at 2:24 PM, Sebastian Ramacher
<report at bugs.python.org> wrote:
..
>> * Same for PySys_SetArgv(int, char **)
>
> That one is non-trivial and requires some rewriting of PySys_SetArgv.
> And I didn't have the time to look into it any further.
>
I agree and I only tossed this one in to check if you are aware of the
char ** issues.  I believe it was agreed at some point that changing
char ** to const char ** is not a good idea (see revision 42596
reverting such change), but I could not find a clear explanation of
the associated problems.

In any case, +1 from me in favor of applying this patch and I will try
to add Jeremy Hylton to the "nosy" list since he is the developer who
made similar API changes in r41638 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:53:54 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Nov 2008 20:53:54 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1226609634.95.0.695966982997.issue1699259@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Thu Nov 13 22:26:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 21:26:17 +0000
Subject: [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1226611577.21.0.892880156239.issue1814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Notes:
- GNU Common LISP uses CLN, which uses GMP's low-level
functions (http://cvs.savannah.gnu.org/viewvc/gcl/gcl/gmp/)
- GHC (Haskell compiler, http://haskell.org/ghc/) uses (or  
used) GMP. But Haskell is a statically typed language, where one can  
choose between fixed sized types like Int, and variable sized  
integers.
(informations from the GMP mailing list)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
_______________________________________

From report at bugs.python.org  Thu Nov 13 22:29:36 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Nov 2008 21:29:36 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1226611776.56.0.508671215657.issue1699259@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Sorry, but it's too late to apply the patch. The issues don't count as
"critical" and it changes the API, too. Only critical and important bugs
are solved during the release candidate phase of 3.0. Python 2.6 is
already out.

I set the target version to 2.7 and 3.1.

----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Thu Nov 13 23:57:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2008 22:57:50 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The interpreter sometimes segfaults when running the test suite, in 
test_imageop.
A more reliable crasher is:

>>> import imageop
>>> s = "A" * 32000
>>> imageop.rgb2rgb8(s, 1, len(s))

The failure was recently introduced by r66689, a "security fix" :-(
and backported today in 2.4!

This is a 2.4 release blocker. Patch is attached, please review.

----------
files: rgbcrash.diff
keywords: needs review, patch
messages: 75840
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: Buffer overflow in imageop module
type: crash
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file12001/rgbcrash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:00:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 23:00:00 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226617200.76.0.062201107028.issue4317@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops. That's why I asked for one or more reviewers :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:01:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2008 23:01:31 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226617291.74.0.795499750712.issue4317@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file12001/rgbcrash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:02:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2008 23:02:00 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226617320.99.0.285713493029.issue4317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Of course I uploaded the wrong patch. Trying again.

Added file: http://bugs.python.org/file12002/rgbcrash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:05:20 2008
From: report at bugs.python.org (benny daon)
Date: Thu, 13 Nov 2008 23:05:20 +0000
Subject: [issue2869] Wrong doc for `calendar.Calendar.iterweekdays`
In-Reply-To: <1210875257.46.0.726174573952.issue2869@psf.upfronthosting.co.za>
Message-ID: <1226617520.24.0.167249274984.issue2869@psf.upfronthosting.co.za>


benny daon <bennydaon at gmail.com> added the comment:

It confused me. Got to this URL:
http://www.python.org/doc/2.5.2/lib/module-calendar.html

----------
nosy: +daonb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2869>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:45:51 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Nov 2008 23:45:51 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
In-Reply-To: <1226611776.56.0.508671215657.issue1699259@psf.upfronthosting.co.za>
Message-ID: <d38f5330811131545x54dfeb9qf18b63499f38ddbc@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While technically this is an API change, in reality it is unlikely to
break anyone's code because you can always pass char * to a function
that expects const char* and the ABI does not change.   (Also I cannot
think why anyone would want to use pointers to the affected functions,
which would be another potential breakage.)

In any case, I am not a big proponent of const correctness, but this
patch was forgotten for 1.5 years and
deferring it to 2.7 and 3.1 is virtually equivalent to closing with "won't fix".

Is it clear that  this patch is not a candidate for minor releases -
2.5.3 or 2.6.1?  As I explained, it is not *really* an API change.  If
it is a backport candidate, I would see benefit in committing it
sooner and blocking in py3k merge until 3.0 is out.

On Thu, Nov 13, 2008 at 4:29 PM, Christian Heimes
<report at bugs.python.org> wrote:
>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> Sorry, but it's too late to apply the patch. The issues don't count as
> "critical" and it changes the API, too. Only critical and important bugs
> are solved during the release candidate phase of 3.0. Python 2.6 is
> already out.
>
> I set the target version to 2.7 and 3.1.
>
> ----------
> stage:  -> patch review
> versions: +Python 2.7, Python 3.1 -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1699259>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:32:13 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:32:13 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1226622733.1.0.823659779263.issue1665333@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Re-opening, since Optik is no longer externally maintained.

----------
assignee:  -> akuchling
nosy: +akuchling
resolution: invalid -> 
status: closed -> open
title: Documentation missing for OptionGroup class in optparse  -> Documentation missing for OptionGroup class in optparse
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:37:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:37:45 +0000
Subject: [issue4318] optparse: formatting of help text/descriptions
In-Reply-To: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za>
Message-ID: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

(Copied from an anonymous submission 
in the Optik bug tracker.)

There have been some recent discussions on comp.lang.python about the
optparse/optik module, and Steve Bethard suggested you might be interested
in some of the work done there. I don't know if you'd find any of this
helpful for inclusion in Optik/optparse, but Steve says it's come up on
your mailing list too.

The problem at hand involves formatting help-strings so that they respect
newlines. Simply passing formatted help-strings off to the textwrap.*
methods mungs the newlines and loses them.

The original thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6df6e6
b541a15bc2/acf1d05cad60fc45?#acf1d05cad60fc45

My solution:
http://groups.google.com/group/comp.lang.python/msg/09f28e26af0699b1

Dan then asked about it, and took my solution and ran with it:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/e72dee
e779d9989b/4ec68cd2a35d52e1?hl=en#4ec68cd2a35d52e1

Feel free to do with it as you like.

----------
components: Library (Lib)
messages: 75846
nosy: akuchling
severity: normal
status: open
title: optparse: formatting of help text/descriptions
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4318>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:39:22 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:39:22 +0000
Subject: [issue4319] optparse and non-ascii help strings
In-Reply-To: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za>
Message-ID: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

(copied from the Optik bug tracker)

Related bug:
http://www.mail-archive.com/python-bugs-list at python.org/msg07227.html

Hi all,

It seems to me that the workaround to the above bug in optparse.py versio
1.5.3 introduces a new bug when help strings are byte strings (as opposed
to unicode) containing non-ascii characters. Consider the following
script:

$ cat test.py
#!/usr/bin/env python
# -*- coding:latin-1 -*-

import optparse
parser = optparse.OptionParser()
parser.add_option("--test",help="This does not work: ?")
parser.parse_args()

When called with "$ ./test.py --help", this script fails with the following
traceback:

$ ./test.py -h
Traceback (most recent call last):
File "./test.py", line 7, in <module>
parser.parse_args()
File "/usr/lib/python2.5/optparse.py", line 1385, in parse_args
stop = self._process_args(largs, rargs, values)
File "/usr/lib/python2.5/optparse.py", line 1429, in _process_args
self._process_short_opts(rargs, values)
File "/usr/lib/python2.5/optparse.py", line 1536, in _process_short_opts
option.process(opt, value, values, self)
File "/usr/lib/python2.5/optparse.py", line 782, in process
self.action, self.dest, opt, value, values, parser)
File "/usr/lib/python2.5/optparse.py", line 804, in take_action
parser.print_help()
File "/usr/lib/python2.5/optparse.py", line 1655, in print_help
file.write(self.format_help().encode(encoding, "replace"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 117:
ordinal not in range(128)

This behaviour can be reproduced with utf-8 encoded strings as well.

If I understand correctly, line 1655 of optparse.py only works if
format_help() returns an ascii byte string or a unicode string, but the
call to "encoding" fails when it is a byte string containing non-ascii
character.

I think this is either a bug and should be fixed, or very misleading (and
should be fixed too :).

I hope to have helped even a little.
Thanks for optparse, and keep up the good work!

Cheers,
Antoine

----------
components: Library (Lib)
messages: 75847
nosy: akuchling
severity: normal
status: open
title: optparse and non-ascii help strings
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4319>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:40:47 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:40:47 +0000
Subject: [issue4320] optparse: "1 2 3" should be seen as one string
In-Reply-To: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za>
Message-ID: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

(copied from the Optik bug tracker -- I haven't tried
to replicate this.)

----------
components: Library (Lib)
messages: 75848
nosy: akuchling
severity: normal
status: open
title: optparse: "1 2 3" should be seen as one string
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4320>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:03:01 2008
From: report at bugs.python.org (Laszlo (Laca) Peter)
Date: Fri, 14 Nov 2008 06:03:01 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1226642581.66.0.52916261638.issue4111@psf.upfronthosting.co.za>


Laszlo (Laca) Peter <laca at sun.com> added the comment:

I'm the python package maintainer at Sun.
We would really like to get the dtrace probes upstream, let me know how
I can help.

----------
nosy: +laca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:03:31 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 14 Nov 2008 06:03:31 +0000
Subject: [issue4321] unintended syntax error with decorators, parenthesis,
	and dots?
In-Reply-To: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>
Message-ID: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I believe I found an unintentional syntax error with a combination of 
decorators, parenthesis, and dots. Here's a demonstration:

class C:
    def prop(self, function):
        return property(function)

class F:
    @C().prop
    def foo(self):
        return 5

Which errors out with:

  File "foo.py", line 6
    @C().prop
        ^
SyntaxError: invalid syntax

I can't imagine why this would be desired, since these equivalent forms 
work:

class D:
    def foo(self):
        return 5
    foo = C().prop(foo)

class E:
    c = C()
    @c.prop
    def foo(self):
        return 5

----------
components: Interpreter Core
messages: 75850
nosy: erickt
severity: normal
status: open
title: unintended syntax error with decorators, parenthesis, and dots?
type: compile error
versions: Python 2.5.3, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4321>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:35:41 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 14 Nov 2008 06:35:41 +0000
Subject: [issue4191] urlparse normalize URL path
In-Reply-To: <1224834633.73.0.450098014303.issue4191@psf.upfronthosting.co.za>
Message-ID: <1226644541.68.0.268612231605.issue4191@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This report almost seems like a bug with urlparse, but it is not. We
have to consider certain cases here.

1) First of all, we cannot equate urlparsing, urlsplit, urljoin with
path normalization provided by posixpath.normalize. The reason is the
url syntax is strictly by RFCs which are different than Operating
system's file and directory naming syntaxes. So, the expectation that
urlparse() should return the same result as posixpath.normalize() is
wrong. What we can at most look is, does urlparse follow the guidelines
mentioned in the RFC1808 to start with and RFC3986 ( Current). 

2) Secondly, in a generic sense, it is better to follow the RFC defined
parsing rules for URLS than implementing browser behavior. Because, the
urlparse needs to parse urls of other schemes also say svn+ssh where a
valid url is svn+ssh://localhost///// and in this case '////' is the the
name of my directory where I have the source code. Quite possible,
right? So, it should not be converted to '/' which will be wrong.

3) And coming down to the more specific issues with the examples
presented in this report,
urlsplit considers the first '//' to follow the netloc
and a single '/' or '///' to be path '/'

>>> urlparse.urlsplit('//')
SplitResult(scheme='', netloc='', path='', query='', fragment='')
>>> urlparse.urlsplit('/')
SplitResult(scheme='', netloc='', path='/', query='', fragment='')
>>> urlparse.urlsplit('///')
SplitResult(scheme='', netloc='', path='/', query='', fragment='')

Having this in mind, follow the examples you have provided:

print urlparse.urljoin('http://www.example.com///', '//')
print urlparse.urljoin('http://www.example.com///', '/')
print urlparse.urljoin('http://www.example.com///', '')

You will find that they are according the parsing and joining rules as
defined in RFC 1808 (http://www.faqs.org/rfcs/rfc1808.html)

The same is with other examples, monk.e.boy. 

If you see that urlparse method has a problem, then please point me to
the section in the RFC1808/RFC3986, where it is not confirming, I shall
work on the patch to fix.

This report, is not a valid bug and can be closed.

----------
nosy: +orsenthil
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4191>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:44:16 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 14 Nov 2008 06:44:16 +0000
Subject: [issue4321] unintended syntax error with decorators, parenthesis,
	and dots?
In-Reply-To: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>
Message-ID: <1226645056.44.0.130562669616.issue4321@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Guido gets to choose.  Read

PEP:	318
Title:	Decorators for Functions and Methods

and "gut feeling"

http://mail.python.org/pipermail/python-dev/2004-August/046711.html

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4321>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:44:18 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 14 Nov 2008 06:44:18 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I ran into a case where I modified the __name__ attribute of a function 
and then didn't specify the right number of arguments, and I got a 
TypeError that used the original function name, as demonstrated here:

>>> def foo(): pass
... 
>>> foo.__name__ = 'bar'
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes no arguments (1 given)

I would have expected it to say "TypeError: bar() ...". I'm guessing 
that the interpreter isn't using the __name__ attribute in this case.

----------
components: Library (Lib)
messages: 75853
nosy: erickt
severity: normal
status: open
title: function with modified __name__ uses original name when there's an arg error
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4322>
_______________________________________

From report at bugs.python.org  Fri Nov 14 10:46:37 2008
From: report at bugs.python.org (Walter Doekes)
Date: Fri, 14 Nov 2008 09:46:37 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1226655997.98.0.831190416791.issue1222@psf.upfronthosting.co.za>


Walter Doekes <walter+python at wjd.nu> added the comment:

@Antoine Pitrou

Regarding "# XXX is the trailing space a bug?": I'm inclined to believe
that it is. Man 7 locale does not mention that p_sep_by_space should be
used for non-int currency symbols, nor that it shouldn't. However, it
does say:

""" char *int_curr_symbol; /* First three chars are a currency symbol
from ISO 4217.  Fourth char is the separator. Fifth char is ? ?. */ """

I haven't seen that fifth character, and in the libc sources I can't
find one either:

glibc-2.7/localedata/locales/nl_NL:66:int_curr_symbol
"<U0045><U0055><U0052><U0020>"

I do however see a separator.

In libc documentation I found here (
http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_19.html#SEC325
), it says the following:

""" In other words, treat all nonzero values alike in these members.
These members apply only to currency_symbol. When you use
int_curr_symbol, you never print an additional space, because
int_curr_symbol itself contains the appropriate separator. The POSIX
standard says that these two members apply to the int_curr_symbol as
well as the currency_symbol. But an example in the ANSI C standard
clearly implies that they should apply only to the
currency_symbol---that the int_curr_symbol contains any appropriate
separator, so you should never print an additional space. Based on what
we know now, we recommend you ignore these members when printing
international currency symbols, and print no extra space. """

This is probably not right either, because this forces you to use an
n_sign_posn and p_sign_posn that have the symbol on the same side of the
value. (Although that might not be such an awful assumption.) And, more
importantly, a grep through the sources reveal that no language has a
preceding space. (But they do, I assume, have *_sign_posn's that want a
trailing symbol.)

""" glibc-2.7/localedata/locales$ grep ^int_curr_symbol * | grep -vE
'(<U0020>| )"' | wc -l
0 """

That leaves us with two more options. Option three: the fourth character
is optional and defines what the separator is but not _where_ it should
be. I.e. you might have to move it according to what *_sign_posn says.

And finally, option four: international formatting should ignore all of
*_cs_precedes, *_sep_by_space and *_sign_posn. Locale(7) explicitly
mentions currency_symbol, not int_cur_symbol. Perhaps one should assume
that international notation is universal. (I would guess that most
common is:
<int_curr_symbol><space><optional_minus><num><mon_thousands_sep><num><mon_decimal_point><num>)


Personally I would go with option three. It has the least impact on
formatting because it only cleans up spaces. I'm guessing however that
option four is the Right One.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:03:15 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=)
Date: Fri, 14 Nov 2008 11:03:15 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>


New submission from Andr? <info at orlans-amo.be>:

When saving a source file with non-ascii characters from an IDLE window,
on Windows platform (XP and Server 2003 at least)
with locale English US  

  locale.getdefaultlocale()
  ('en_US', 'cp1252')

IDLE prompts in IOBinding.py with the message 
"non Ascii found, yet no encoding declared, Add a line like # -*- 
coding: cp1252 -*-"

If accepted, the file is saved with the wrong encoding.
Afterwards, it is read back by IDLE without any problem and it looks 
good in the IDLE window.

However, if a string with non-ascii characters is sent to another 
module (i.e. email  MIMEText)
the string is wrong.

The same source would be rejected by python in terminal mode and by 
IDLE on Linux.

----------
messages: 75855
nosy: andre
severity: normal
status: open
title: Wrong encoding in files saved from IDLE (3.0rc2 on Windows)
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:17:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 11:17:57 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226661477.79.0.446972312974.issue4323@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If accepted, the file is saved with the wrong encoding

"accept" means click on the "OK" button. You have to click on the 
biggest button "Edit my file" to create a valid file.

The problem here is the text in the dialog but also the possibility to 
create an invalid file. 

Two solutions:
 - don't ask user for a confirmation (always insert the header)
 - replace "OK" button by "Cancel" button: the user wants maybe an 
ASCII only file but inserted by error an unicode character (eg. non 
breaking space!)

----------
nosy: +haypo
Added file: http://bugs.python.org/file12003/idle_dialog.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:18:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 11:18:30 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226661510.03.0.899835437477.issue4323@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Quick but ugly solution: force the #coding: header without asking the 
user for that.

Added file: http://bugs.python.org/file12004/idle_remove_coding_dialog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:29:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 11:29:21 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226662161.11.0.6363113316.issue4323@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Implementation of the second solution: replace Ok button by a Cancel 
button. Escape key is Cancel, whereas Return key is the default 
action: edit the file.

----------
keywords: +patch
Added file: http://bugs.python.org/file12005/idle_coding_dialog_cancel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:46:27 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 11:46:27 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1226663187.48.0.176355231671.issue1673409@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>>> (t - epoch) // timedelta(seconds=1)

I don't like this syntax, because I can't guess the result unit:
  datetime - datetime -> timedelta
but:
  timedelta / timedelta -> seconds? days? nanoseconds?

If you example, you used timedelta(seconds=1), but what is the result 
unit if you use timedelta(hours=1)? or timedelta(days=1, 
microseconds=1)?

The problem is that timedelta has no unit (or has multiple units), 
whereas timedelta.toseconds() are seconds. So about your example:

>>> (t - epoch).toseconds()
--> fractional seconds
>>> int((t - epoch).toseconds())
--> whole seconds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Fri Nov 14 13:17:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Nov 2008 12:17:19 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1226665039.83.0.487658211061.issue1673409@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> timedelta / timedelta -> seconds? days? nanoseconds?

The quotient of two timedelta is a dimensionless number with no unit:
    timedelta(hours=1) / timedelta(minutes=5) == 12.0
This seems well defined, where is the ambiguity?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Fri Nov 14 14:28:31 2008
From: report at bugs.python.org (Kai Willadsen)
Date: Fri, 14 Nov 2008 13:28:31 +0000
Subject: [issue4324] locale documentation is inconsistent
In-Reply-To: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za>
Message-ID: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za>


New submission from Kai Willadsen <kai.willadsen at gmail.com>:

The documentation for locale.getlocale is not consistent with the
example given. The docs for getlocale([category]) say:
  "category may be one of the LC_* values except LC_ALL."
but the example at the bottom of the documentation starts with:
  >>> import locale
  >>> loc = locale.getlocale(locale.LC_ALL) # get current locale
  ...

----------
assignee: georg.brandl
components: Documentation
messages: 75861
nosy: georg.brandl, kaiw
severity: normal
status: open
title: locale documentation is inconsistent
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4324>
_______________________________________

From report at bugs.python.org  Fri Nov 14 15:55:37 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 14 Nov 2008 14:55:37 +0000
Subject: [issue4320] optparse: "1 2 3" should be seen as one string
In-Reply-To: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za>
Message-ID: <1226674537.01.0.0549390356426.issue4320@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

I had the same need in my small command line client (that uses Cmd.Cmd)
and I solved it by using shlex.split() instead of regular string split.
I haven't looked at optparse code lately and perhaps it can do the same.

----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4320>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:18:25 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 15:18:25 +0000
Subject: [issue1673409] datetime module missing some important methods
In-Reply-To: <1226665039.83.0.487658211061.issue1673409@psf.upfronthosting.co.za>
Message-ID: <d38f5330811140718i675f92fal98090abaa3b265fb@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I was going to say the same as Amaury: timedelta / timedelta is
dimensionless (time units cancel each other in division) and the
advantage of this notation is that you get a way to express
timedelta.toxxx for all units accepted in constructor and even toweeks
becomes simple d / timedelta(7).

I've started flashing out a patch and then recalled that I've seen one
at issue2706 .  So instead of attaching a new patch here, I am going
to review the one in issue2706 now.

There was also some related discussion at issue4291 .   Apparently it
has been suggested that timedelta to integer and float conversions
would be a better alternative to timedelta / timedelta division.   I
disagree.  Integer conversion is ambiguous - should it be to seconds,
to microseconds or to timedelta.resolution (whatever that will become
in the future)?  Floating point conversion may loose precision as Tim
pointed out in msg26266 .  That would lead users to scratching their
heads over what to use float(d1)/float(d2) or float(d1)/int(d2) or
even int(d1)/int(d2) with true division on.

This said, let's move this discussion to issue2706 now.

On Fri, Nov 14, 2008 at 7:17 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
>> timedelta / timedelta -> seconds? days? nanoseconds?
>
> The quotient of two timedelta is a dimensionless number with no unit:
>    timedelta(hours=1) / timedelta(minutes=5) == 12.0
> This seems well defined, where is the ambiguity?
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1673409>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:33:54 2008
From: report at bugs.python.org (Richard urwin)
Date: Fri, 14 Nov 2008 15:33:54 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1226676834.44.0.106446657024.issue1767933@psf.upfronthosting.co.za>


Richard urwin <richard.urwin at srhsystems.com> added the comment:

This is a bug in two halves.

1. Not all characters in the file are UTF-16. The initial xml header
isn't, and the individual < > etc characters are not. This is just a
matter of extending the methodology to encode all characters and not
just the textual bits. There is no work-around except a five-minute hack
of the ElementTree.write() method.

2. Every write has a BOM, so corrupting the file in a manner analogous
to bug 555360. This is a result of using string.encode() and is a
well-known feature. It can be worked around by using UTF-16LE or
UTF-16BE which do not prepend a BOM, but then the file doesn't have any
BOM. A complete solution would be to rewrite ElementTree.write() to use
a different encoding methodology such as StreamWriter.

I have made the above hack and work-around for my own use, and I can
report that it produces perfect UTF-16.

----------
nosy: +rurwin
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:40:14 2008
From: report at bugs.python.org (dreamlusion)
Date: Fri, 14 Nov 2008 15:40:14 +0000
Subject: [issue4325] Installer crash on cancel installation.
In-Reply-To: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>
Message-ID: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>


New submission from dreamlusion <dreamlusion at gmail.com>:

Steps to reproduce:

1. Start the installer (python-2.6.msi)
2. Choose install for all users, next.
3. Select default directory, next.
4. Click "Advanced".
5. Click "Cancel" and confirm (click yes).
Bang.

----------
components: Installation
messages: 75865
nosy: dreamlusion
severity: normal
status: open
title: Installer crash on cancel installation.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4325>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:40:31 2008
From: report at bugs.python.org (dreamlusion)
Date: Fri, 14 Nov 2008 15:40:31 +0000
Subject: [issue4325] Installer crash on cancel installation.
In-Reply-To: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>
Message-ID: <1226677231.92.0.337039782598.issue4325@psf.upfronthosting.co.za>


Changes by dreamlusion <dreamlusion at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4325>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:48:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Nov 2008 15:48:21 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1226677701.3.0.076855673698.issue1767933@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Would you provide a patch?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:51:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Nov 2008 15:51:19 +0000
Subject: [issue4289] Python 2.6 installer crashes when selecting 'advanced'
	and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1226677879.44.0.190744638233.issue4289@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue4325 describes the same crash, except that the user chose "all
users" and did not change the destination directory.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:52:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Nov 2008 15:52:29 +0000
Subject: [issue4325] Installer crash on cancel installation.
In-Reply-To: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>
Message-ID: <1226677949.8.0.167067338763.issue4325@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's a duplicate of issue4289, with almost the same sequence.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python 2.6 installer crashes when selecting 'advanced' and cancelling it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4325>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:16:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 14 Nov 2008 16:16:26 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226679386.65.0.478221729436.issue4323@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The entire dialog should go away. The default source encoding is UTF-8
in Python 3.0, and IDLE should know that. The locale's encoding
shouldn't ever be considered.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:27:36 2008
From: report at bugs.python.org (dreamlusion)
Date: Fri, 14 Nov 2008 16:27:36 +0000
Subject: [issue4289] Python 2.6 installer crashes when selecting 'advanced'
	and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1226680056.21.0.643772237367.issue4289@psf.upfronthosting.co.za>


Changes by dreamlusion <dreamlusion at gmail.com>:


----------
nosy: +dreamlusion

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:37:22 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 14 Nov 2008 16:37:22 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226680642.62.0.449860870118.issue4313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

After long random investigation, I found idle_crash_1.py can reproduce
the crash. And I noticed in idle_crash_2.py WidgetRedirector#dispatch,
last element of args cannot be printed. Here is result.

10
0 -foreground
1 black
2 -selectforeground
3 black
4 -selectbackground
5 black
6 -background
7 black
8 -insertbackground
9 Traceback (most recent call last):
  File "c.py", line 52, in <module>
    selectbackground=color,
  File "e:\python-dev\py3k\lib\tkinter\__init__.py", line 1199, in configure
    return self._configure('configure', cnf, kw)
  File "e:\python-dev\py3k\lib\tkinter\__init__.py", line 1190, in
_configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError

And I found this crash can be fixed by reverting r57540. This revision
was applied to fix issue1028, but I think we should solve this issue in
different way.

----------
nosy: +ocean-city
type:  -> crash
Added file: http://bugs.python.org/file12006/idle_crash_1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:37:43 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 14 Nov 2008 16:37:43 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226680663.79.0.898580425353.issue4313@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file12007/idle_crash_2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:55:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 14 Nov 2008 16:55:28 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226681728.15.0.516563915987.issue4313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Can I revert r57540 and reopen issue1028?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Fri Nov 14 17:59:50 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 14 Nov 2008 16:59:50 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226681990.85.0.399265124686.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is a revised version.
Since there is no portable way to block signals, and no way at all on 
windows (apparently) the simplest way is to simply use NOWAIT_LOCK when 
adding a new pending call.  While this does not guarantee that we are 
always able to append a call (we may be unlucky in all our N tries and 
there is also no portable way to yield the thread timeslice between 
tries) such are also the semantics of the method.  Sometimes the buffer 
may be full, or we fail to get the lock in time, and a -1 is returned.  
It is up to the caller to respond appropriately, perhaps by trying again 
later.

Added file: http://bugs.python.org/file12008/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:06:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 17:06:20 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226682380.19.0.825371414076.issue4313@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can I revert r57540 and reopen issue1028?

Would it be possible to revert and fix the issue in the same 
commit? :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:13:20 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 14 Nov 2008 17:13:20 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226682800.26.0.397962958826.issue4313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I cannot reproduce the bug described in issue1028, so it's
difficult for me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:32:17 2008
From: report at bugs.python.org (Richard urwin)
Date: Fri, 14 Nov 2008 17:32:17 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1226683937.45.0.657283928936.issue1767933@psf.upfronthosting.co.za>


Richard urwin <richard.urwin at srhsystems.com> added the comment:

Here is a patch of my quick hack, more for interest than any suggestion
it gets used. Although it does produce good output so long as you avoid
the BOM.

The full solution is beyond my (very weak) Python skills. The character
encoding is tied in with XML character substitution (&amp; etc. and
hexadecimal representation of multibyte characters). I could disentangle
it, but I probably wouldn't produce optimal Python, or indeed anything
that wouldn't inspire mirth and/or incredulity.

NB. The workaround suggested by Fredrik Lundh doesn't solve our
particular problems, since the downsize to UTF-8 causes the multi-byte
characters to be represented in hex. Our software doesn't read those. (I
know that's our problem.)

Added file: http://bugs.python.org/file12009/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:43:47 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 17:43:47 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226684627.22.0.838216876725.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I attaching webograph's patch updated to revision 67223 where I added a 
few tests.

I am +1 on the floor divide changes (allowing timedelta // timedelta), 
but I am not sure how true division should work if at all.  For the sake 
of argument, let's assume from __future__ import division or py3k.  
Currently: 

>>> timedelta(1)/2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 
'int'
>>> timedelta(1)/timedelta(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 
'datetime.timedelta'

With this patch, timedelta(1)/2 is still unsupported, but

>>> timedelta(1)/timedelta(2)
0.5

Note that this is probably correct behavior because timedelta/int true 
division does not make much sense, but there is a proposal (see issue1083) to make timedelta/int equivalent to timedelta//int.  (I am 
against issue1083 proposal and for webograph's approach, but this needs 
to be further discussed.)

Also, I've added a test that demonstrates the following behavior:

>>> int(timedelta.min/(timedelta.min//3))
2

This is not a bug in webograph's patch, but rather a bug in long true 
division, but it shows that true division may not be as useful as it 
seems.

----------
nosy: +belopolsky
Added file: http://bugs.python.org/file12010/timedeltadiv.parch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:46:00 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 17:46:00 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226684760.04.0.411316320505.issue2706@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +amaury.forgeotdarc, jribbens
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:51:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 17:51:30 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226685090.07.0.981211056922.issue2706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why not also implementing divmod()? It's useful to split a timedelta 
into, for example, (hours, minutes, seconds):

def formatTimedelta(delta):
    """
    >>> formatTimedelta(timedelta(hours=1, minutes=24, seconds=19))
    '1h 24min 19sec'
    """
    hours, minutes = divmodTimedelta(delta, timedelta(hours=1))
    minutes, seconds = divmodTimedelta(minutes, timedelta(minutes=1))
    seconds, fraction = divmodTimedelta(seconds, timedelta(seconds=1))
    return "{0}h {1}min {2}sec".format(hours, minutes, seconds)

My implementation gives divmod(timedelta, timedelta) -> (long, 
timedelta). It's a little bit strange to get two different types in 
the result. The second return value is the remainder. My example works 
in the reverse order of the classical code:

def formatSeconds(seconds):
    """
    >>> formatTimedelta(1*3600 + 24*60 + 19)
    '1h 24min 19sec'
    """
    minutes, seconds = divmod(seconds, 60)
    hours, minutes = divmod(minutes, 60)
    return "{0}h {1}min {2}sec".format(hours, minutes, seconds)
    
About my new patch:
 - based on datetime_datetime_division_dupcode.patch
 - create divmod() operation on (timedelta, timedelta)
 - add unit tests for the division (floor and true division) and 
divmod
 - update the documentation for the true division and divmod

----------
nosy: +haypo
Added file: http://bugs.python.org/file12011/timedelta_true_divide_divmod.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:03:01 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 18:03:01 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1226685090.07.0.981211056922.issue2706@psf.upfronthosting.co.za>
Message-ID: <d38f5330811141002jcbc1c83o92cec251767dfc35@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 14, 2008 at 12:51 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Why not also implementing divmod()? It's useful to split a timedelta
> into, for example, (hours, minutes, seconds):

I agree and in this case mod should probably be implemented too.

With your patch:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'datetime.timedelta' and
'datetime.timedelta'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:06:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2008 18:06:44 +0000
Subject: [issue4321] unintended syntax error with decorators, parenthesis,
	and dots?
In-Reply-To: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>
Message-ID: <1226686004.24.0.531952550976.issue4321@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing; changing this will at least need a python-dev discussion, and
thorough motivation.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4321>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:15:02 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 18:15:02 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226686502.12.0.116749756505.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Also, why not

>>> divmod(timedelta(3), 2)
(datetime.timedelta(1), datetime.timedelta(1))

?

And where do we stop? :-)

On Fri, Nov 14, 2008 at 1:02 PM, Alexander Belopolsky
<belopolsky at users.sourceforge.net> wrote:
> On Fri, Nov 14, 2008 at 12:51 PM, STINNER Victor 
<report at bugs.python.org> wrote:
>>
>> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>>
>> Why not also implementing divmod()? It's useful to split a timedelta
>> into, for example, (hours, minutes, seconds):
>
> I agree and in this case mod should probably be implemented too.
>
> With your patch:
>
>>>> timedelta(3)%timedelta(2)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for %: 'datetime.timedelta' and
> 'datetime.timedelta'
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:28:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 18:28:41 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1226686502.12.0.116749756505.issue2706@psf.upfronthosting.co.za>
Message-ID: <200811141927.06978.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since timedelta(3) // 2 is already accepted, divmod should also accept 
integers (but not float).

With the last patch and "from __future__ import division", we support:
  timedelta // <timedelta or int>
  timedelta / timedelta
  divmod(timedelta, timedelta)

What do you think about:
  timedelta / <timedelta or int or float>  # only with __future__.divison
  timedelta // <timedelta or int>
  timedelta % <timedelta or int>
  divmod(timedelta, <timedelta or int>)
with:
  timedelta // int -> timedelta
  timedelta // timedelta -> int
  timedelta % int -> timedelta
  timedelta % timedelta -> int
  divmod(timedelta, int) -> (timedelta, timedelta)
  divmod(timedelta, timedelta) -> (int, timedelta)
  timedelta / <anything> -> float # __future__.divison

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:35:54 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 18:35:54 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1226685090.07.0.981211056922.issue2706@psf.upfronthosting.co.za>
Message-ID: <d38f5330811141035g14d54942ied933c737b057138@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While I agree that divmod may be useful, your particular use case is
not convincing. The same can be done easier without divmod:

def formatTimedelta(delta):
   return "{0}h {1}min {2}sec".format(*str(delta).split(':'))

or you can convert delta to time using an arbitrary anchor date and
extract hms that way:

(1, 24, 19)

(depending on your needs you may want to add delta.days*24 to the hours)

On Fri, Nov 14, 2008 at 12:51 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Why not also implementing divmod()? It's useful to split a timedelta
> into, for example, (hours, minutes, seconds):
>
> def formatTimedelta(delta):
>    """
>    >>> formatTimedelta(timedelta(hours=1, minutes=24, seconds=19))
>    '1h 24min 19sec'
>    """
>    hours, minutes = divmodTimedelta(delta, timedelta(hours=1))
>    minutes, seconds = divmodTimedelta(minutes, timedelta(minutes=1))
>    seconds, fraction = divmodTimedelta(seconds, timedelta(seconds=1))
>    return "{0}h {1}min {2}sec".format(hours, minutes, seconds)
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:52:13 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 18:52:13 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <200811141927.06978.victor.stinner@haypocalc.com>
Message-ID: <d38f5330811141052n79823377md53f376aeb1dfbfa@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 14, 2008 at 1:28 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> What do you think about:
>  timedelta / <timedelta or int or float>  # only with __future__.divison
>  timedelta // <timedelta or int>
>  timedelta % <timedelta or int>
>  divmod(timedelta, <timedelta or int>)
> with:
>  timedelta // int -> timedelta
already there

+1

+1

+1

timedelta % float -> timedelta (because int % float -> int works) ?

+1

+1

divmod(timedelta, float) -> (timedelta, timedelta) ?

-1

Only timedelta / timedelta should produce dimensionless numbers.
timedelta / <float or int> should be disallowed in true division mode.
 I am +0 on timedelta / timedelta -> float in true division mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:59:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 18:59:46 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226689186.95.0.209737649887.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Oops, the tracker ate some lines from e-mail.  Reposting through the 
web:

On Fri, Nov 14, 2008 at 1:28 PM, STINNER Victor <report at bugs.python.org> 
wrote:
..
> What do you think about:
>  timedelta / <timedelta or int or float>  # only with 
__future__.divison
>  timedelta // <timedelta or int>
>  timedelta % <timedelta or int>
>  divmod(timedelta, <timedelta or int>)
> with:
>  timedelta // int -> timedelta
already there

>  timedelta // timedelta -> int
+1

>  timedelta % int -> timedelta
+1

>  timedelta % timedelta -> int
+1

timedelta % float -> timedelta (because int % float -> int works) ?

>  divmod(timedelta, int) -> (timedelta, timedelta)
+1

>  divmod(timedelta, timedelta) -> (int, timedelta)
+1

divmod(timedelta, float) -> (timedelta, timedelta) ?

>  timedelta / <anything> -> float # __future__.divison
-1

Only timedelta / timedelta should produce dimensionless numbers.
timedelta / <float or int> should be disallowed in true division mode.
 I am +0 on timedelta / timedelta -> float in true division mode.
Reply
		
Forward

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:36:32 2008
From: report at bugs.python.org (chafporte)
Date: Fri, 14 Nov 2008 21:36:32 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>


New submission from chafporte <junk at ysengrin.com>:

from UserList import UserList
lu = UserList()
type(lu)

python2.6 prints: <class 'UserList.UserList'>
python2.5 prints: <type 'instance'>

----------
components: None
messages: 75885
nosy: chafporte
severity: normal
status: open
title: type of UserList instance returns class instead of instance
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:39:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Nov 2008 21:39:47 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1226698787.72.0.739849906379.issue4322@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is because these errors use the code object's name attribute
(f.func_code.co_name) for error messages.

----------
nosy: +benjamin.peterson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4322>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:41:14 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Nov 2008 21:41:14 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226698874.37.0.580196811642.issue4326@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That is because UserList is now a new-style class as a result of it
inheriting from the new abstract base classes.  I believe this is the
way Guido wanted it and do not see any deleterious impacts from the change.

Recommend closing as "won't fix" or "invalid".

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:44:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Nov 2008 21:44:31 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226699071.07.0.353318422091.issue4326@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Isn't policy to keep old-style classes around for compatibility in 2.x?
Especially one like UserList which is meant to be used as a base class.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:47:39 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 14 Nov 2008 21:47:39 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>


New submission from David Turner <novalis at novalis.org>:

This patch adds functionality to the optimizer to simplify complex
constant assignments like:

a, (b, c) = d, e = 1, (2, 3)

The simplification is:

a = 1
d = 1
b, c = e = 2, 3

Of course, the simplified version is semantically identical.  But the
bytecode generated is faster, because there is less need to unpack
tuples.  Naturally, this only works on constants:

a, b = 1, a is not the same as
a = 1
b = a

----------
files: tlee-ast-optimize-multiassign.diff
keywords: patch
messages: 75889
nosy: novalis_dt
severity: normal
status: open
title: Patch: simplify complex constant assignment statements
Added file: http://bugs.python.org/file12012/tlee-ast-optimize-multiassign.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:50:42 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 14 Nov 2008 21:50:42 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1226699442.61.0.370120120722.issue4327@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

Oh, and this also involved the creation of an additional statement type,
unfortunately. The statement type, Seq, represents a sequence of
statements.  This is so that we can replace a single assign with
multiple assigns.  If that's no good, then we could do an If with test=1
instead, since the compiler knows to optimize that out.  We could also
go into the parent statement and replace the body, but that would
require significant rejiggering of the optimizer, and significant
additional complexity.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:53:59 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Nov 2008 21:53:59 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226699639.89.0.817187126735.issue4326@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It has been the practice to not switch old-style to new-style just for
the hell of it.  However, we do switch as part of large PEP driven
efforts like the ABC backport.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:59:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 21:59:44 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <d38f5330811141035g14d54942ied933c737b057138@mail.gmail.com>
Message-ID: <200811142258.42863.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> def formatTimedelta(delta):
>    return "{0}h {1}min {2}sec".format(*str(delta).split(':'))

OMG, this is ugly! Conversion to string and reparse the formatted text :-/ 
Your code doesn't work with different units than hours, minutes or seconds:

['4 days, 1', '32', '01']
>>> str(timedelta(hours=1, minutes=32, seconds=1, microseconds=2)).split(":")
['1', '32', '01.000002']

> or you can convert delta to time using an arbitrary anchor date
> and extract hms that way:

How? I don't understand your suggestion.

> (depending on your needs you may want to add delta.days*24 to the hours)

The goal of the new operators (timedelta / timedelta, divmod(timedelta, 
timedelta), etc.) is to avoid the use of the timedelta "internals" (days, 
seconds and microseconds attributes) and give a new "natural" way to process 
time deltas.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:04:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Nov 2008 22:04:42 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226700282.37.0.0678260206636.issue4326@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fair enough.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:06:25 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2008 22:06:25 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226700385.98.0.844157085515.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

haypo> How? I don't understand your suggestion.

Sorry, another case of mail to tracker bug.  Here is what I wrote:

"""
.. you can convert delta to time using an arbitrary anchor date and
extract hms that way:

>>> x = datetime(1,1,1) + timedelta(hours=1, minutes=24, seconds=19)
>>> x.hour,x.minute,x.second
(1, 24, 19)

(depending on your needs you may want to add delta.days*24 to the hours)
"""

but tracker ate the '>>>' lines :-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:07:31 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Nov 2008 23:07:31 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226704051.54.0.556131661315.issue2706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@webograph: time_gmtime() and time_localtime() already use function 
pointer. I prefer function pointer than code duplication!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:15:06 2008
From: report at bugs.python.org (chafporte)
Date: Fri, 14 Nov 2008 23:15:06 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226704506.56.0.672667688457.issue4326@psf.upfronthosting.co.za>


chafporte <junk at ysengrin.com> added the comment:

but like that there is no way to detect if the object
is a class or an instance. type() says it's a class in both case !

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:23:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Nov 2008 23:23:01 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226704981.37.0.713993275875.issue4326@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>>> import inspect
>>> from UserList import UserList
>>> lu = UserList()
>>> inspect.isclass(UserList)
True
>>> inspect.isclass(lu)
False

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:54:53 2008
From: report at bugs.python.org (chafporte)
Date: Fri, 14 Nov 2008 23:54:53 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226706893.91.0.962403203412.issue4326@psf.upfronthosting.co.za>


chafporte <junk at ysengrin.com> added the comment:

but for a user define class we have:
>class AAA:
>...  pass
>
>a = AAA()
>type(a)
<type 'instance'>
and you can compare this with types.InstanceType
and it says True

where for the UserList instance the comparison with 
types.InstanceType says False

it is just not homogenous. and it make the comparison with
types.InstanceType unusable !!!

are you sure this is not breaking the API ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:33:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 00:33:12 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1226709192.97.0.629434977999.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I like the method, but I have some comments about the new method:
 - datetime_totimestamp() is not well indented
 - "PyObject *time" should be defined at the before the first 
instruction
 - why not using "if (time == NULL) return NULL;" directly instead of 
using a block in case of time is not NULL?
 - there are reference leaks: timetuple, timestamp and 
PyFloat_FromDouble()

I wrote a similar patch before reading 
add-datetime-totimestamp-method.diff which does exactly the same... I 
attach my patch but both should be merged.

Added file: http://bugs.python.org/file12013/datetime_totimestamp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:41:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 00:41:08 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1226709668.52.0.515045093594.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a merged patch of the three patches. Except the C 
implementation of datetime_totimestamp() (written by me), all code is 
written by hodgestar.

Added file: http://bugs.python.org/file12014/datetime_totimestamp-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:43:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 00:43:55 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1226709835.58.0.138087035103.issue1726687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can anyone review the last patch?

----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Sat Nov 15 02:15:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Nov 2008 01:15:29 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1226711729.86.0.312684878446.issue2736@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to voice my opposition the totimestamp method.

Representing time as a float is a really bad idea (originated at 
Microsoft as I have heard).  In addition to the usual numeric problems 
when dealing with the floating point, the resolution of the floating 
point timestamp varies from year to year making it impossible to 
represent high resolution historical data.

In my opinion both time.time() returning float and 
datetime.fromtimestamp() taking a float are both design mistakes and 
adding totimestamp that produces a float will further promote a bad 
practice.

I would not mind integer based to/from timestamp methods taking and 
producing seconds or even (second, microsecond) tuples, but I don't 
think changing fromtimestamp behavior is an option.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 02:37:45 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 01:37:45 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1226711729.86.0.312684878446.issue2736@psf.upfronthosting.co.za>
Message-ID: <200811150236.34185.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Saturday 15 November 2008 02:15:30 Alexander Belopolsky, vous avez ?crit?:
> I don't think changing fromtimestamp behavior is an option.

It's too late to break the API (Python3 is in RC stage ;-)), but we can create 
new methods like:
   datetime.fromepoch(seconds, microseconds=0)    # (int/long, int)
   datetime.toepoch() -> (seconds, microseconds)  # (int/long, int)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 04:17:49 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Nov 2008 03:17:49 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <200811150236.34185.victor.stinner@haypocalc.com>
Message-ID: <d38f5330811141917n609f8affr634b1b31c6e8c7ff@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 14, 2008 at 8:37 PM, STINNER Victor <report at bugs.python.org> wrote:
> .. but we can create new methods like:
>   datetime.fromepoch(seconds, microseconds=0)    # (int/long, int)

While 1970 is the most popular epoch, I've seen 1900, 2000 and even
2035 (!) being used as well.  Similarly, nanoseconds are used in high
resolution time sources at least as often as microseconds.  This makes
fromepoch() ambiguous and it is really unnecessary because it can be
written as epoch + timedelta(0, seconds, microseconds).

>   datetime.toepoch() -> (seconds, microseconds)  # (int/long, int)

I would much rather have divmod implemented as you suggested in
issue2706 .  Then toepoch is simply

def toepoch(d):
    x, y = divmod(d, timedellta(0, 1))
    return x, y.microseconds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 05:42:41 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Nov 2008 04:42:41 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1226724161.76.0.0140888360057.issue3679@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Sat Nov 15 08:40:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 15 Nov 2008 07:40:33 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226734832.99.0.20643267632.issue4313@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Sat Nov 15 09:06:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Nov 2008 08:06:33 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226736393.29.0.163691643092.issue4326@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What good is a comparison with InstanceType for? If you want to check
whether it's an instance of a custom class, you'll have to check for
instances of new-style classes anyway. If you want to check for UserList
instances, use isinstance().

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Sat Nov 15 09:08:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Nov 2008 08:08:19 +0000
Subject: [issue4312] Unicode in distutils meta-data?
In-Reply-To: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>
Message-ID: <1226736499.09.0.821894525404.issue4312@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4312>
_______________________________________

From report at bugs.python.org  Sat Nov 15 09:10:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Nov 2008 08:10:15 +0000
Subject: [issue4324] locale documentation is inconsistent
In-Reply-To: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za>
Message-ID: <1226736615.8.0.860547957499.issue4324@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r67224.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4324>
_______________________________________

From report at bugs.python.org  Sat Nov 15 10:27:24 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 15 Nov 2008 09:27:24 +0000
Subject: =?utf-8?q?[issue4328]_"=C3=A0"_in_u"foo"_raises_a_misleading_error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

With Python 2.x:
>>> '?' in u'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in <string>' requires string as left operand
>>> '?' in u'x?x'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in <string>' requires string as left operand

The error claims that "'in <string>' requires string as left operand"
when actually the left operand *is* a string.

With Python2.6 with unicode_literals:
>>> print(b'\x85')
?
>>> b'\x85' in 'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'in <string>' requires string as left operand

With Python3.x the error is slightly different:
TypeError: 'in <string>' requires string as left operand, not bytes

but then it works with:
>>> b'f' in 'foo'
True

This problem seems somehow related to the implicit decoding of '?'. I
guess that '?' in u'foo' should raise a UnicodeDecodeError ('xxx' codec
can't decode byte 0x85 ...), not a TypeError.

----------
components: Unicode
messages: 75907
nosy: ezio.melotti
severity: normal
status: open
title: "?" in u"foo" raises a misleading error
versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Sat Nov 15 11:08:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 Nov 2008 10:08:08 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226743688.74.0.0948911170249.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> timedelta / <float or int> should be disallowed in true division mode.

I don't understand this;  why should the division mode affect
division operations involving timedeltas at all?  The meaning
of "/" is unaffected by the division mode for float/float or
float/int;  why should timedeltas be any different?

I vote +1 for timedelta/timedelta and timedelta/float (regardless
of division mode).  timedelta / timedelta is the one obvious way
to find out 'how many A's in B', and the one that it's natural
to try first, before looking for (timedelta -> float) conversion
methods.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 11:26:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 Nov 2008 10:26:00 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1226744760.36.0.834431885725.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, I assume that any plan to add this division would also include 
adding the inverse operation:

timedelta * float -> timedelta.

It wouldn't make a whole lot of sense to have one without the other.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 11:47:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 Nov 2008 10:47:24 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226746044.03.0.0627787399159.issue4291@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Christian]
> float(td1) / float(td2) which is far more obvious than td1 / td2

To me, td1/td2 is more obvious that float(td1)/float(td2).

float(td) involves an arbitrary choice, to return time in *seconds* 
(rather than days, or milliseconds, or ...);  I think this violates 
EIBTI.  To me, the obvious and easy-to-read way to get the number
of seconds is to do the division:

seconds_in_td = td1 / timedelta(seconds = 1)

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Sat Nov 15 12:11:25 2008
From: report at bugs.python.org (Michael Becker)
Date: Sat, 15 Nov 2008 11:11:25 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>


New submission from Michael Becker <spammb at gmail.com>:

See below. unicode string causes exception. Explicitly converting it to
a regular string addresses the issue. I only noticed this because my
input string changed to unicode after updating python to 2.6 and django
to 1.0.

>>> import base64
>>>
a=u'aHR0cDovL3NvdXJjZWZvcmdlLm5ldC90cmFja2VyMi8_ZnVuYz1kZXRhaWwmYWlkPTIyNTg5MzUmZ3JvdXBfaWQ9MTI2OTQmYXRpZD0xMTI2OTQ='
>>> b=base64.urlsafe_b64decode(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/base64.py", line 112, in urlsafe_b64decode
    return b64decode(s, '-_')
  File "/usr/local/lib/python2.6/base64.py", line 71, in b64decode
    s = _translate(s, {altchars[0]: '+', altchars[1]: '/'})
  File "/usr/local/lib/python2.6/base64.py", line 36, in _translate
    return s.translate(''.join(translation))
TypeError: character mapping must return integer, None or unicode
>>> b=base64.urlsafe_b64decode(str(a))
>>> b
'http://sourceforge.net/tracker2/?func=detail&aid=2258935&group_id=12694&atid=112694'

----------
components: Unicode
messages: 75911
nosy: mbecker
severity: normal
status: open
title: base64 does not properly handle unicode strings
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:19:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 12:19:38 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <d38f5330811141917n609f8affr634b1b31c6e8c7ff@mail.gmail.com>
Message-ID: <200811151318.34629.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Saturday 15 November 2008 04:17:50 Alexander Belopolsky, vous avez ?crit?:
> it is really unnecessary because it can be
> written as epoch + timedelta(0, seconds, microseconds).

I tried yesterday and it doesn't work!

datetime.datetime(1970, 1, 1, 1, 0)
>>> t1 = epoch + timedelta(seconds=-1660000000)
>>> t2 = datetime.fromtimestamp(-1660000000)
>>> t2
datetime.datetime(1917, 5, 26, 1, 53, 20)
>>> t1 - t2
datetime.timedelta(0)
>>> t2 = datetime.fromtimestamp(-1670000000)
>>> t2
datetime.datetime(1917, 1, 30, 7, 6, 40)
>>> t1 = epoch + timedelta(seconds=-1670000000)
>>> t1 - t2
datetime.timedelta(0, 3600)

We lost an hour durint the 1st World War :-)

Whereas my implementation using mktime() works:

-1670000000.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:36:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2008 12:36:13 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1226744760.36.0.834431885725.issue2706@psf.upfronthosting.co.za>
Message-ID: <200811151335.04167.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some examples to help the choice (using the last patch).

int
---

2L
>>> print dt2 * 2
3:08:38
>>> print dt1 - dt2 * 2
0:51:22
>>> divmod(dt1, dt2)
(2L, datetime.timedelta(0, 3082))
>>> print timedelta(0, 3082)
0:51:22

In 4 hours, you can watch the movie twice, and then your have 51 minutes left.

Operations used:
 - timedelta // timedelta
 - timedelta * int
 - divmod(timedelta, timedelta)

float
-----

0.21258172822053367
>>> "Progress: %.1f%%" % ((dt1 / dt2) * 100.0)
'Progress: 21.3%'
>>> dt2 * 0.75
...
TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float'
>>> print (dt2 * 3) // 4
1:10:44.250000

If you are seen this movie since 20 minutes, you're at 21% of the total. If 
you want to jump to 75%, it will be at 1:10:44.

Note: timedelta * float is not implemented yet.

Operations used:
 - timedelta / timedelta
 - timedelta * int and timedelta // int (because timdelta / float is 
   not implemented yet)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 16:42:23 2008
From: report at bugs.python.org (Oleg Broytmann)
Date: Sat, 15 Nov 2008 15:42:23 +0000
Subject: [issue2666] webbrowser.py doesn't properly handle BROWSER env var
In-Reply-To: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>
Message-ID: <1226763743.82.0.690368849188.issue2666@psf.upfronthosting.co.za>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

Update the patch.

Added file: http://bugs.python.org/file12015/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2666>
_______________________________________

From report at bugs.python.org  Sat Nov 15 16:42:37 2008
From: report at bugs.python.org (Oleg Broytmann)
Date: Sat, 15 Nov 2008 15:42:37 +0000
Subject: [issue2666] webbrowser.py doesn't properly handle BROWSER env var
In-Reply-To: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>
Message-ID: <1226763757.64.0.042760755535.issue2666@psf.upfronthosting.co.za>


Changes by Oleg Broytmann <phd at phd.pp.ru>:


Removed file: http://bugs.python.org/file10072/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2666>
_______________________________________

From report at bugs.python.org  Sat Nov 15 18:37:46 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 15 Nov 2008 17:37:46 +0000
Subject: =?utf-8?q?[issue4328]_"=C3=A0"_in_u"foo"_raises_a_misleading_error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1226770666.07.0.601144946755.issue4328@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The left operand is a bytestring and the right operand is a unicode
string, so it makes sense that it raises an exception, although it would
be clearer if it said "'in <string>' requires unicode string as left
operand".

I agree that if it's going to do implicit decoding so that it'll accept
'f' in u'foo' then it should probably raise a UnicodeDecodeError when
that fails.

If it's reporting a /TypeError/ then it should also reject 'f' in u'foo'.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Sat Nov 15 19:28:09 2008
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 15 Nov 2008 18:28:09 +0000
Subject: [issue887237] Machine integers
Message-ID: <1226773689.19.0.864786710107.issue887237@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I wonder if a patch for ctypes like this (which is not yet complete)
could be used to implement this, or MUST it be implemented in C?

The patch contains a mixin class that implements the numeric methods. 
However, the actual operation takes place in Python; only the operands
are converted into ctypes types first, the operand is applied to the
value, and the result is converted to a ctypes instance again.

One difficulty with the patch is that the original ctypes code contained
a tp_as_number member where only the nb_nonzero slot was actually
implemented; this prevented the mixin class to do it's work (Python
didn't call the special methods.  I wonder if there is a bug somewhere...).

----------
keywords: +patch
Added file: http://bugs.python.org/file12016/ctypes-numbermixins.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:08:15 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Nov 2008 21:08:15 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1226743688.74.0.0948911170249.issue2706@psf.upfronthosting.co.za>
Message-ID: <d38f5330811151308gf7bfabye720a869b87e553@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 15, 2008 at 5:08 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> timedelta / <float or int> should be disallowed in true division mode.
>
> I don't understand this;  why should the division mode affect
> division operations involving timedeltas at all?

Here is how I think about this:  timedeltas are integers in units of
time.  For simplicity, let's assume we always express timedeltas in
microseconds (us), so timedeltas are things like 1us, 2us, etc.  As
with integers,  we can define true division (/) and floor division
(//) so that 3us/2us = 1.5 and 3us//2us = 1.  Note that the result is
dimensionless.  Similarly, you can divide timedeltas by  dimensionless
integers: 3us/2 = 1.5us and 3us//2 = 1us.  However in python you
cannot have a timedelta representing 1.5us, so timedelta(0, 0, 3)/2
should be en error.  In order to have a timedelta/int true division,
we would need to have another type floattimedelta which would be a
floating point number in units of time.

>  The meaning of "/" is unaffected by the division mode for float/float or
> float/int;  why should timedeltas be any different?

Because they are integers.  If we had a floattimedelta type that would
store timestamp as a float, its division would rightfully not be
affected by the division mode.

> I vote +1 for timedelta/timedelta and timedelta/float (regardless
> of division mode).

What do you vote  timedelta/timedelta should produce in floor division
mode: an int or a float? and what should  timedelta/float produce: a
timedelta or a float?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Nov 15 23:33:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 15 Nov 2008 22:33:48 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1226788428.61.0.855216132781.issue1726687@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

on Windows (with Visual Studio), mktime() also sets tm_wday only if 
successful.

But negative time_t are still not allowed by the Microsoft CRT, the 
tests fail.
There are workaround to this - for example python could use techniques 
similar to http://robertinventor.com/software/t64/
 
OTOH, the docs of the time module explicitly says that dates before the 
Epoch are not handled. Do you want to change this? in other words: is 
this a bug or a feature request?
http://docs.python.org/library/time.html

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Sun Nov 16 01:29:41 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 16 Nov 2008 00:29:41 +0000
Subject: [issue4291] Allow Division of datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226795381.43.0.832586501866.issue4291@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

@Christian

Adding a __float__ method to datetime was entertained back in 2003, but 
was rejected.  The same reasons apply to timedelta:

"""
- A C double doesn't have enough precision for roundtrip guarantees.

- Does it really need to be automatic?  I.e., does it really need to
  be __float__()?  I'd be less against this if it was an explicit
  method, e.g. dt.asposixtime().

--Guido van Rossum (home page: http://www.python.org/~guido/)
"""

http://mail.python.org/pipermail/python-dev/2003-January/032166.html

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________

From report at bugs.python.org  Sun Nov 16 01:43:04 2008
From: report at bugs.python.org (Ian Bicking)
Date: Sun, 16 Nov 2008 00:43:04 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>


New submission from Ian Bicking <ianb at colorstudy.com>:

The method wsgiref.validate:InputWrapper.readline doesn't take any
arguments.  It should take an optional size argument.  Though this isn't
part of the WSGI specification, the cgi module uses this argument when
parsing the body, and in practice no applications that use
cgi.FieldStorage (which is most applications) are compatible with
wsgiref.validate as a result.  Simply adding a *args that is passed to
the underlying file fixes this.

----------
components: Library (Lib)
messages: 75920
nosy: ianb
severity: normal
status: open
title: wsgiref.validate doesn't accept arguments to readline
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 01:44:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Nov 2008 00:44:28 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226796268.91.0.798600558894.issue4330@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> pje
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:06:39 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 16 Nov 2008 03:06:39 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226804799.24.0.386089737062.issue4330@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

No, it shouldn't.  The purpose of wsgiref.validate is to validate spec
compliance, and the use of a readline() argument means that the program
doing the invocation is not valid, per the spec.  wsgiref.validate is
correctly reporting the failure of compliance.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:12:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Nov 2008 03:12:20 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226805140.53.0.127134441729.issue4330@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:12:37 2008
From: report at bugs.python.org (Ian Bicking)
Date: Sun, 16 Nov 2008 03:12:37 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226805157.43.0.652451153297.issue4330@psf.upfronthosting.co.za>


Ian Bicking <ianb at colorstudy.com> added the comment:

This renders wsgiref.validate.validator completely useless, because it
cannot be used with any existing code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:21:44 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 16 Nov 2008 03:21:44 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226805157.43.0.652451153297.issue4330@psf.upfronthosting. co.za>
Message-ID: <20081116032140.082453A40A8@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Uh, Ian, do you not remember being the person who *wrote* this code a 
few years ago?  This is the old paste.lint with a little 
renaming.  Of course it can be used with existing code -- code that 
complies with the WSGI spec.

It's the cgi module that changed, not wsgiref.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:23:55 2008
From: report at bugs.python.org (Ian Bicking)
Date: Sun, 16 Nov 2008 03:23:55 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226805835.75.0.886577865468.issue4330@psf.upfronthosting.co.za>


Ian Bicking <ianb at colorstudy.com> added the comment:

Yes, and I've wanted to deprecate paste.lint, but I can't because people
use it over wsgiref.validate because it had this change applied.  Yes,
cgi.FieldStorage changed, but now that it's changed wsgiref needs to be
compatible with it to be viable.

Mostly the WSGI spec has been wrong on this for some time, but we've
never gone through the process of updating it (though it has been
brought up several times on Web-SIG).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:46:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Nov 2008 03:46:11 +0000
Subject: [issue4040] ignored exceptions in generators (regression?)
In-Reply-To: <1223133689.63.0.365168051222.issue4040@psf.upfronthosting.co.za>
Message-ID: <1226807171.41.0.829009285328.issue4040@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Well, I'll just cross my fingers then. :)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4040>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:50:58 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 16 Nov 2008 03:50:58 +0000
Subject: =?utf-8?q?[issue4328]_"=C3=A0"_in_u"foo"_raises_a_misleading_error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1226807458.66.0.687569346274.issue4328@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Usually, when you do operations involving unicode and normal strings,
the latter are coerced to unicode using the default encoding. If the
codec is not able to decode the string a UnicodeDecodeError is raised. E.g.:
>>> '?' + u'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0x85 in position 0:
ordinal not in range(128)
The same error is raised with u'%s' % '?'.

I think that '?' in u'foo' should behave in the same way (i.e. try to
decode the string and possibly raise a UnicodeDecodeError). This is
probably the most coherent and backward-compatible solution, at least in
Python2.x. In Python2.x normal and unicode strings are often mixed and
having 'f' in u'foo' that raises a TypeError will probably break lot of
code.

In Python3.x it could make sense, the strings are unicode by default and
you are not supposed to mix byte strings and unicode strings so we may
require an explicit decoding.

The behavior should be consistent for all the operations, if we decide
to raise a TypeError with 'in' it should be raised with '+' and '%' (and
possibly others) as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Sun Nov 16 05:47:34 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 16 Nov 2008 04:47:34 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1226810854.74.0.484187659796.issue4309@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Conversely, if the documentation is correct then my ctypes is flawed.

"None, integers, byte strings and unicode strings are the only native 
Python objects that can directly be used as parameters in these function 
calls. None is passed as a C NULL pointer, byte strings and unicode 
strings are passed as pointer to the memory block that contains their 
data (char * or wchar_t *). Python integers are passed as the platforms 
default C int type, their value is masked to fit into the C type."

----------
components: +ctypes -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Sun Nov 16 07:33:00 2008
From: report at bugs.python.org (scott sadler)
Date: Sun, 16 Nov 2008 06:33:00 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>


New submission from scott sadler <ssadler at mashi.org>:

Calling a function created by _functools.partial as a method raises an
exception:

"TypeError: method_new() takes exactly n non-keyword arguments (0 given)"

Where method_new is the function passed into partial() and n is the
number of arguments it expects.

This does not happen when using a python version of partial().

Strangely, in the circumstance that I originally encountered the bug,
there was one instance that I was doing this and it _DID WORK_. The
function being passed into partial() was the same as in the place where
it was failing. The only significant difference that I could see was
that the input function to partial() was being imported, rather than
being defined in the same namespace as it was used I was unable to
reproduce it in my test case (attatched).

Tested on 2.6 and 2.5.2

----------
components: Extension Modules
files: partialbug.py
messages: 75928
nosy: ssadler
severity: normal
status: open
title: Can't use _functools.partial() created function as method
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12017/partialbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Sun Nov 16 07:57:56 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 06:57:56 +0000
Subject: [issue4090] Documenting set comparisons and operations
In-Reply-To: <1223569047.14.0.973921550653.issue4090@psf.upfronthosting.co.za>
Message-ID: <1226818676.11.0.953787658423.issue4090@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a proposed doc fix-up for this little can of worms (and for
issue 4087).

----------
keywords: +patch
Added file: http://bugs.python.org/file12018/expr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4090>
_______________________________________

From report at bugs.python.org  Sun Nov 16 09:00:26 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Nov 2008 08:00:26 +0000
Subject: [issue4316] Improper use of [] in configure.in leads to useless
	regexp in configure
In-Reply-To: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za>
Message-ID: <1226822426.95.0.575913444016.issue4316@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r67227.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4316>
_______________________________________

From report at bugs.python.org  Sun Nov 16 12:15:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 11:15:27 +0000
Subject: [issue1721812] A subclass of set doesn't always have __init__ called.
Message-ID: <1226834127.52.0.0992704493867.issue1721812@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Improved solution attached.

Added file: http://bugs.python.org/file12019/set.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721812>
_______________________________________

From report at bugs.python.org  Sun Nov 16 12:47:31 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 11:47:31 +0000
Subject: [issue1721812] A subclass of set doesn't always have __init__ called.
Message-ID: <1226836051.63.0.551772217047.issue1721812@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r67232.

Don't think this should be backported to the 2.x series as it may break
working code relying on the old behavior.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721812>
_______________________________________

From report at bugs.python.org  Sun Nov 16 13:25:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 12:25:25 +0000
Subject: [issue1694663] Overloading  int.__pow__ does not work
Message-ID: <1226838325.6.0.457434560645.issue1694663@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg, do you want to take a look at this patch.  I've neglected it
because I don't see why the argument signature matters (__neg__ and
__pow__ take a different number of arguments than the other magic
numeric methods that work just fine).

----------
assignee: rhettinger -> georg.brandl
nosy: +georg.brandl
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694663>
_______________________________________

From report at bugs.python.org  Sun Nov 16 13:51:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 12:51:49 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226839909.31.0.913319286192.issue2260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This looks fine to me.  Go ahead and uncomment the memcpy() line (I
presume you commented it out in order to demonstrate the basic
transformation without the dead code elimination).  Be sure to add a
testcase.

Antoine, the issue with JUMP_IF variants is that they interfere with
other existing byte code optimizations, resulting in a net loss.

BTW, don't expect much of a real-world speed-up from this patch.  The
JUMP_ABSOLUTE opcode is very fast.

----------
assignee: rhettinger -> 
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Sun Nov 16 14:08:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Nov 2008 13:08:42 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1226839909.31.0.913319286192.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226840917.10870.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, the issue with JUMP_IF variants is that they interfere with
> other existing byte code optimizations, resulting in a net loss.

Which other byte code optimizations does it interfere with?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Sun Nov 16 14:13:51 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 13:13:51 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226841231.12.0.364062578901.issue2260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am taking this one back.  May have a simpler approach.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:28:04 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 14:28:04 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226845684.76.0.0805815303949.issue2260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Adding a simpler approach.  It's a bit limited because some common cases
have the POP_TOP JUMP_FORWARD 1 pair split across two basic blocks. 
Those cases should not be optimized away on a first pass.

Added file: http://bugs.python.org/file12020/pop_peep.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:42:34 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 16 Nov 2008 14:42:34 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226805835.75.0.886577865468.issue4330@psf.upfronthosting. co.za>
Message-ID: <20081116144229.7E0B23A4092@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Then obviously it makes no sense to update wsgiref before the 
spec.  ISTM the correct way to deal with this is update the cgi 
module to include a WSGI-compatible API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 16:13:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 15:13:32 +0000
Subject: [issue3106] speedup some comparisons
In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za>
Message-ID: <1226848412.62.0.980605366134.issue3106@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You may get better timings if you more the types-are-equal test inside
the types-i-know test.  Instead of:
+		if (Py_TYPE(v) == Py_TYPE(w)) {
+			if (PyLong_CheckExact(v)) {
+				if (v == w)
+					break;
+				return PyLong_RichCompare(v, w, op);
+			}
+			if (PyUnicode_CheckExact(v)) {

Do something like:
+		if (PyLong_CheckExact(v)) {
+			if (Py_TYPE(v) == Py_TYPE(w)) {
+				if (v == w)
+					break;
+				return PyLong_RichCompare(v, w, op);
+			}
+		if (PyUnicode_CheckExact(v)) {
+			if (Py_TYPE(v) == Py_TYPE(w)) {

In general, I'm not too keen on adding this kind of dispatch code to
ceval.c.  It saves the time spent in PyObject_RichCompare() trying to
figure out where to delegate the work.  But it comes at the expense of
weighing down ALL of the other comparisons which haven't gotten a
short-cut specialization.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3106>
_______________________________________

From report at bugs.python.org  Sun Nov 16 19:03:19 2008
From: report at bugs.python.org (Ian Bicking)
Date: Sun, 16 Nov 2008 18:03:19 +0000
Subject: [issue4330] wsgiref.validate doesn't accept arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226858599.39.0.18529660943.issue4330@psf.upfronthosting.co.za>


Ian Bicking <ianb at colorstudy.com> added the comment:

cgi started using this argument due to the potential of a DoS attack
without the length limit.  So undoing this in cgi (even as an option)
would be a regression.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________

From report at bugs.python.org  Sun Nov 16 21:24:31 2008
From: report at bugs.python.org (scott sadler)
Date: Sun, 16 Nov 2008 20:24:31 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1226867071.9.0.183683741935.issue4331@psf.upfronthosting.co.za>


scott sadler <ssadler at mashi.org> added the comment:

A short update, I believe that the reason that it was working in one
instance was because of some abstractions by a base class (Django model,
get_absolute_url).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Sun Nov 16 21:37:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Nov 2008 20:37:12 +0000
Subject: [issue3106] speedup some comparisons
In-Reply-To: <1226848412.62.0.980605366134.issue3106@psf.upfronthosting.co.za>
Message-ID: <1226867823.10228.44.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> You may get better timings if you more the types-are-equal test inside
> the types-i-know test.

I get no discernable difference.

> In general, I'm not too keen on adding this kind of dispatch code to
> ceval.c.  It saves the time spent in PyObject_RichCompare() trying to
> figure out where to delegate the work.

Some minimal type testing is necessary if we want to implement the
identity-implies-equality optimization for some types without breaking
the fact that e.g. NaN != NaN. This optimization is important when
dealing with e.g. interned strings. There could be a special flag in the
type structure signaling that the optimization is safe.

I'm attaching a patch which reduces the additional dispatch to a
minimum. The speedup on pybench is smaller, but there is no significant
slowdown for "other" comparisons.

Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
                 CompareFloats:   176ms   173ms   +1.9%   180ms   175ms   +3.2%
         CompareFloatsIntegers:   237ms   234ms   +1.0%   251ms   240ms   +4.6%
               CompareIntegers:   266ms   276ms   -3.6%   266ms   278ms   -4.3%
        CompareInternedStrings:   160ms   261ms  -38.6%   161ms   261ms  -38.4%
                  CompareLongs:   156ms   166ms   -6.1%   156ms   167ms   -7.1%
                CompareStrings:   167ms   172ms   -2.9%   170ms   173ms   -1.9%
-------------------------------------------------------------------------------
Totals:                          1161ms  1281ms   -9.4%  1184ms  1295ms   -8.6%

Added file: http://bugs.python.org/file12021/cmps4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3106>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cmps4.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081116/a541b76f/attachment.txt>

From report at bugs.python.org  Sun Nov 16 22:13:11 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 21:13:11 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226869991.37.0.181894152337.issue2260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg, would you please give this a second review.  It passes the whole
test suite for me and triggers often.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Sun Nov 16 23:44:29 2008
From: report at bugs.python.org (Calvin Spealman)
Date: Sun, 16 Nov 2008 22:44:29 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1226875469.13.0.242027791032.issue4331@psf.upfronthosting.co.za>


Calvin Spealman <ironfroggy at users.sourceforge.net> added the comment:

I don't think this is any kind of bug, it is simply a product of only 
function objects being decorated automatically as methods. Your python 
version works because it is, in fact, a function. _functools.partial 
objects are not functions, but simply callable objects.

----------
nosy: +ironfroggy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Nov 17 00:03:11 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2008 23:03:11 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1226876591.52.0.869414528616.issue4331@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Reclassifying as a feature request.
A descriptor could be added to partial()
so that it too would have automatic
method binding just like pure python functions.

----------
nosy: +rhettinger
type: behavior -> feature request
versions: +Python 2.7, Python 3.0 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Nov 17 01:20:32 2008
From: report at bugs.python.org (Christian Becke)
Date: Mon, 17 Nov 2008 00:20:32 +0000
Subject: [issue4332] asyncore.file_dispatcher does not use dup()'ed fd
In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
Message-ID: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>


New submission from Christian Becke <christianbecke at gmail.com>:

asyncore.file_dispatcher stores the file descriptor passed to
asyncore.file_dispatcher.__init__ into the map, not the dup()'ed one
created by asyncore.file_wrapper. Because of this, a "select.error (9,
'Bad file descriptor')" is raised in asyncore.loop() if the fd passed to
asyncore.file_dispatcher.__init__ is closed while the loop is running.
Attached patch fixes the issue.

----------
components: Library (Lib)
files: asyncore_file_dispatcher_use_duped_fd.diff
keywords: patch
messages: 75947
nosy: christianbecke
severity: normal
status: open
title: asyncore.file_dispatcher does not use dup()'ed fd
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12022/asyncore_file_dispatcher_use_duped_fd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4332>
_______________________________________

From report at bugs.python.org  Mon Nov 17 01:23:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 17 Nov 2008 00:23:24 +0000
Subject: [issue4333] Reworked Dialog.py
In-Reply-To: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za>
Message-ID: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi,

I have changed the lib-tk/Dialog.py so it handles the cases where one
might receive a tuple as a result containing a Tcl_Obj. I've also
modified all the rest of it to make it "cleaner".

It is b/w compatible although I dislike the usage of cnf, but I guess
I'm too late to suggest this change even for py3k :/
A "more complete" description of the changes is in
http://svn.python.org/view?rev=67240&view=rev

----------
components: Tkinter
files: Dialog.diff
keywords: patch
messages: 75948
nosy: gpolo
severity: normal
status: open
title: Reworked Dialog.py
versions: Python 2.7
Added file: http://bugs.python.org/file12023/Dialog.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4333>
_______________________________________

From report at bugs.python.org  Mon Nov 17 01:25:24 2008
From: report at bugs.python.org (Noah Gift)
Date: Mon, 17 Nov 2008 00:25:24 +0000
Subject: [issue4334] Mac Build Script is broken for 2.6 release
In-Reply-To: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za>
Message-ID: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za>


New submission from Noah Gift <noah.gift at gmail.com>:

Just an FYI, the Mac Build script in:

Python-2.6 2/Mac/BuildScript/build-installer.py

contains broken download URLs for SQLite, and cause the build to fail.  
I fixed this myself, but noticed this appears to be fixed in the trunk, 
already.  Having a working build script is a fairly big deal for mac 
users, as they often need to have readline compiled properly with 
Python, which is a pain.  This might be nice to have fixed in the 
production release.

----------
components: Build
messages: 75949
nosy: ngift
severity: normal
status: open
title: Mac Build Script is broken for 2.6 release
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4334>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:25:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 02:25:15 +0000
Subject: [issue4334] Mac Build Script is broken for 2.6 release
In-Reply-To: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za>
Message-ID: <1226888715.57.0.0561980580283.issue4334@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has been backported and will be fixed in 2.6.1.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4334>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:31:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 02:31:53 +0000
Subject: [issue4332] asyncore.file_dispatcher does not use dup()'ed fd
In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
Message-ID: <1226889113.33.0.460183572589.issue4332@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4332>
_______________________________________

From report at bugs.python.org  Mon Nov 17 04:53:36 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 Nov 2008 03:53:36 +0000
Subject: [issue4332] asyncore.file_dispatcher does not use dup()'ed fd
In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
Message-ID: <1226894016.0.0.57055894152.issue4332@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4332>
_______________________________________

From report at bugs.python.org  Mon Nov 17 07:28:10 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 17 Nov 2008 06:28:10 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1226903290.66.0.280632836745.issue4252@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This describes second bug.

When multiple target was bound to same keyword, only first target could
be browsed.

In index_on_firefox.png, we can see "operator, [1], [2]". This [?] means
multiple targets are linked to same keyword and we can browse each
target in firefox. But from htmlhelp, we can only browse first target.

Attached patch "sphinx_multiple_targets.patch" will enable us to select
each targets in popup dialog. (They all have same title, I think it's
useless though)

Please apply this patch after applied sphinx_inactive_index_item.patch.

----------
title: inactive item not shown in html help index pane -> some missing links in html help index pane
Added file: http://bugs.python.org/file12024/sphinx_multiple_targets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov 17 07:32:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 17 Nov 2008 06:32:07 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1226903527.6.0.649099221088.issue4252@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file12025/resolved.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov 17 08:58:27 2008
From: report at bugs.python.org (Rafe Sacks)
Date: Mon, 17 Nov 2008 07:58:27 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1226908707.57.0.831193286573.issue1309567@psf.upfronthosting.co.za>


Rafe Sacks <rafesacks at gmail.com> added the comment:

This seems related to http://bugs.python.org/issue1218234 as well. 
This is my first bug report. I hope I do this right.
I posted this to comp.lang.python and was directed here. Here is a
chopped paste of that post:

I am getting an error on line 510 of inspect.py:

504    if iscode(object):
505        if not hasattr(object, 'co_firstlineno'):
506            raise IOError('could not find function definition')
507        lnum = object.co_firstlineno - 1
508        pat = re.compile(r'^(\s*def\s)|(.*(?<!\w)lambda(:|\s))|^(\s*@)')
509        while lnum > 0:
510            if pat.match(lines[lnum]): break
511            lnum = lnum - 1
512        return lines, lnum

I finally figured out that there was a caching problem. The function I
passed was changed, but the code lines (strings) retrieved by
linecache.getlines() (on lines 464 and 466) didn't update with the new
module contents... To get around this, I invoke linecache.clearcache()...

    linecache.clearcache()
    lines, n = inspect.getsourcelines(fn)


While inspect uses the cached module to get the text, the line number
used to find the block of source lines is retrieved from the passed
object. So, if I pass a function which reports that it starts on line
50, but in the cache it starts on line 40, an error isn't raised but the
lines of code returned are wrong. The error only occurs when the line
number is higher than the number of lines in the cached module.

Cheers,

- Rafe

----------
nosy: +RafeSacks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:09:11 2008
From: report at bugs.python.org (Rafe Sacks)
Date: Mon, 17 Nov 2008 08:09:11 +0000
Subject: [issue4335] inspect.getsourcelines ignores last line in module
In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za>
Message-ID: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za>


New submission from Rafe Sacks <rafesacks at gmail.com>:

Hi,

If the last line of the function is also the last line of the module, it
is ignored. To repro:

1) Create module 'repro'
<module>
def test():
    module_line_2 = None
    module_line_3 = None
    module_line_4 = None
    module_line_5 = None
<end module>

2) Run test:
>>> import repro
>>> import inspect
>>> inspect.getsourcelines(tmp.test)
(['def test():\n', '    module_line_2 = None\n', '    module_line_3 =
None\n', '    module_line_4 = None\n'], 1)

notice no module_line_5.


cheers,

- Rafe

----------
components: Library (Lib)
messages: 75953
nosy: RafeSacks
severity: normal
status: open
title: inspect.getsourcelines ignores last line in module
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4335>
_______________________________________

From report at bugs.python.org  Mon Nov 17 10:08:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 17 Nov 2008 09:08:21 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1226912901.48.0.136892277296.issue4252@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I found another problem on html help about case sensitivity.
Pleas e pend my patch...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov 17 12:37:02 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 11:37:02 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1226921822.2.0.0865402400091.issue1692335@psf.upfronthosting.co.za>


Ziga Seilnacht <zseil at users.sourceforge.net> added the comment:

Sorry for the long silence. I think that this patch is not relevant
anymore. The code that uses exception pickling already had to be adapted
to changes in Python 2.5, so there is no need to change the pickling
again and risk breaking user code. I'll close it in a few days if nobody
objects.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Mon Nov 17 12:42:22 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 17 Nov 2008 11:42:22 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1226922142.68.0.958226479575.issue4252@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Even if two bugs are solved, one weird problem remains. See
binary_index.png. "unicode, built-in function" should go under "unicode"
node, but it goes under "Unicode" node. This happens because  sitemap
format (hhk file) is *case insensitive*, and if binary index is turned
on, indexes are sorted and *merged* automatically.

I hope attached sphinx_index.patch will fix this problem. You don't have
to apply previous two patches. It should be applied to tip cleanly.

# Turning off binary index causes some change to look&feel of index
pane. For example, if you click inactive item, nothing happens instead
of alert dialog.

Added file: http://bugs.python.org/file12026/binary_index.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov 17 12:42:45 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 17 Nov 2008 11:42:45 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1226922165.39.0.979688700611.issue4252@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file12027/sphinx_index.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:24:15 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 12:24:15 +0000
Subject: [issue1694663] Overloading  int.__pow__ does not work
Message-ID: <1226924655.56.0.446118247885.issue1694663@psf.upfronthosting.co.za>


Ziga Seilnacht <zseil at users.sourceforge.net> added the comment:

Hi Raymond,

The signature matters because the current code in update_one_slot()
forgets to set the use_generic flag when slots have different wrappers.
This causes that the slot from the base class is left in the new type.
Slots have different wrappers when their signature differs.

I also found an old patch for this issue that fixes a few more corner
cases, but I can't remember if it is finished and it doesn't apply to
current trunk. I'll try to fix that soon, but here is the original
message and patch:

"""
Here is a new version of the patch.  It fixes another bug and
restores the optimization that was lost when dict.__getitem__
and list.__getitem__ became methods with a METH_COEXIST flag.

The bug that this patch fixes shows when a type has the wrong
__new__ method:

>>> class C(object):
...     __new__ = int.__new__
...
>>> C()            # should raise a TypeError, but doesn't
>>> C.__new__(C)   # raises a TypeError, as expected

This means that Guido should buy me a beer :).

Adding __getitem__ to dict's and list's methods slowed down the
corresponding operation for subclasses that don't overwrite
__getitem__.  update_one_slot() installs a generic wrapper when
a __special__ method is not a WrapperDescriptor.  As a consequence,
this code is slower:

>>> class MyList(list):
...     pass
...
>>> L = MyList([0])
>>> L[0]           # currently slower than without METH_COEXIST

set.__contains__ and dict.__contains__ have the same problem.
I'll attach a timeit script that shows the difference.

The basic idea of this patch is that when all of the __special__
methods for a particular slot are inherited from the same base,
we can safely use that base's slot for the subtype.  The patch
compares __special__ methods by identity, which eliminates all
of the problems listed in this bug report.  For more details,
see the comments in the patch.

The patch contains only the tests for the bugs reported here;
the old behavior is already thoroughly tested in test_descr's
dynamics(), overloading(), subclasspropagation() and other
functions.

The patch introduces a slight incompatibility with Python 2.4 and
2.5; code that calls PySequence_GetItem(dict_subclass, index) for
dict subclasses can now fail, because tp_as_sequence->sq_item gets
filled only if the subclass overwrites the __getitem__ method.

Here are the results of running the script on a trunk build:

 list test: 0.585701534692
 dict test: 0.562311969817
  set test: 0.468992008761
class test: 0.235781083909

and results of running the script with this patch applied:

 list test: 0.167487487935
 dict test: 0.149341885631
  set test: 0.153591029027
class test: 0.211393347479
"""

----------
keywords: +patch
Added file: http://bugs.python.org/file12028/slot_inheritance.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694663>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:26:54 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 12:26:54 +0000
Subject: [issue1694663] Overloading  int.__pow__ does not work
Message-ID: <1226924814.18.0.636270628031.issue1694663@psf.upfronthosting.co.za>


Changes by Ziga Seilnacht <zseil at users.sourceforge.net>:


Added file: http://bugs.python.org/file12029/time_slot_inheritance.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694663>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:48:47 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Nov 2008 12:48:47 +0000
Subject: [issue4022] 2.6 dependent on c:\python26\ on windows
In-Reply-To: <1222989342.94.0.529774628368.issue4022@psf.upfronthosting.co.za>
Message-ID: <1226926127.18.0.425628198425.issue4022@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

flomana: Have you tried installing Python in c:\python26\ ? If that
didn't help then it is better start a new issue.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4022>
_______________________________________

From report at bugs.python.org  Mon Nov 17 14:13:48 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Nov 2008 13:13:48 +0000
Subject: [issue973507] sys.stdout problems with pythonw.exe
Message-ID: <1226927628.68.0.522862280956.issue973507@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Duplicate of #706263

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue973507>
_______________________________________

From report at bugs.python.org  Mon Nov 17 14:32:06 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 Nov 2008 13:32:06 +0000
Subject: [issue973507] sys.stdout problems with pythonw.exe
Message-ID: <1226928726.29.0.252937843572.issue973507@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue973507>
_______________________________________

From report at bugs.python.org  Mon Nov 17 14:54:11 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Nov 2008 13:54:11 +0000
Subject: [issue453489] Using deiconify() hangs on exit
Message-ID: <1226930051.49.0.363270995345.issue453489@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

With Python 2.6 the support for Windows 95, 98, ME and NT4 has been
dropped. But it is not only that - I would advise closing as "won't fix"
for same reason as listed in aforementioned bug #216289 comment
http://bugs.python.org/msg1951

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue453489>
_______________________________________

From report at bugs.python.org  Mon Nov 17 15:10:23 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 14:10:23 +0000
Subject: [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1226931023.01.0.256490575436.issue3327@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

bump.
Is there any interest in this fix?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________

From report at bugs.python.org  Mon Nov 17 15:33:41 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 14:33:41 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

There are two performance problems in xmlrpclib.py:
POST requests use two send() calls, one to send the headers and one to 
send the data.  This can invoke the Nagle/Delayed ACK performance 
problem.  On many socket implementations (including some windows 
platforms) it can introduce delays of up to 200ms when talking over the 
wire (as opposed to localhost)
The second is the use of no buffering when reading the xmlrpc 
response.  It is done using the readline() call on a file-like object 
constructed from the socket.  When no buffering is in effect, this 
causes a separate recv() call for each character.

This patch fixes these issues separately:
1) We provide a new getheaderdata() function in httplib which just 
returns the data for the headers instead of sending it.  This can be 
used instead of endheaders() if the intention is to subsequently send 
more data.  xmlrpclib then uses this method of framing its POST 
messages.
2) We provide the named artgument bufsize=0 to the HTTPResponse class 
in httplib, and also so on for the HTTPConnection.getresponse() and 
HTTP.getreply(). xmlrpclib then passes bufsize=-1 to HTTP.getreply() to 
get default buffering for the response fileobject.

This patch focuses on fixing the problems with xmlrpclib.  but issue 1) 
above also has a number of other manifestations in the lib, there are 
other places where we can use getheaderdata() and send() instead of 
endheaders() to avoid possible Nagle/Ack problems, e.g. in urllib.py, 
distutils.py and loggin/handlers.py

----------
components: Extension Modules
files: xmlrpc.patch
keywords: easy, patch, patch
messages: 75962
nosy: krisvale
severity: normal
status: open
title: Fix performance issues in xmlrpclib
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12030/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Nov 17 15:52:39 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 14:52:39 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226933559.81.0.871255914606.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Small refinement:  Deadlock avoidance is only needed on the main thread 
since we only install signal handlers for the main thread.

Added file: http://bugs.python.org/file12031/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 17 16:25:52 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Nov 2008 15:25:52 +0000
Subject: [issue1173134] improvement of the script adaptation for the win32
	platform
Message-ID: <1226935552.54.0.62392605395.issue1173134@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The idea with "-x" option and renaming .py to .bat is nice, but if I
want to execute the script with another version of Python or manually
without -x option I may become confused.

Would it be better to provide separated .bat files to launch scripts?
See #4015

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1173134>
_______________________________________

From report at bugs.python.org  Mon Nov 17 16:54:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Nov 2008 15:54:36 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226937276.1.0.463190919932.issue4293@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Two comments about the patch:

- typo in a comment: "...change chat a signal..."

- PyThread_acquire_lock should not be called with a NULL lock: on win32
this does not matter (there is a test in thread_nt.h), but Unix
segfaults in thread_pthread.h if you hit Ctrl-C.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 17 16:54:36 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 17 Nov 2008 15:54:36 +0000
Subject: [issue4337] Iteration over a map object with list()
In-Reply-To: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>
Message-ID: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

win XP sp2, Py3.0c2

I had to face an annoying problem when iterating over a map object.

With a range class, this works

>>> r = range(5)
>>> list(r)
[0, 1, 2, 3, 4]

With dict_keys/values/items objects, the following works

>>> d = {1: 'a', 2:'b', 3:'c'}
>>> list(d.keys())
[1, 2, 3]
>>> list(d.values())
['a', 'b', 'c']
>>> list(d.items())
[(1, 'a'), (2, 'b'), (3, 'c')]

But with a map object...

>>> def plus(i):
        return i + 1

>>> a = list(range(3))
>>> a
[0, 1, 2]
>>> r = map(plus, a)
>>> r
<map object at 0x01371570>
>>> for e in r: print(e)

1
2
3
>>> list(r)
[]
>>> #empty list!

Bug or feature?

----------
components: None
messages: 75965
nosy: jmfauth
severity: normal
status: open
title: Iteration over a map object with list()
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4337>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:01:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Nov 2008 16:01:58 +0000
Subject: [issue453489] Using deiconify() hangs on exit
Message-ID: <1226937718.27.0.314919217925.issue453489@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Closing as suggested

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue453489>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:04:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 17 Nov 2008 16:04:49 +0000
Subject: [issue4312] Unicode in distutils meta-data?
In-Reply-To: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>
Message-ID: <1226937889.67.0.480640008299.issue4312@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. Fixed in r67241.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4312>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:06:05 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Nov 2008 16:06:05 +0000
Subject: [issue4337] Iteration over a map object with list()
In-Reply-To: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>
Message-ID: <1226937965.43.0.385534886464.issue4337@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Feature :-)

You will get the expected result if you skip the step where you ran the
for-loop over r before running list().  Either listing or for-looping
will exhaust the iterator.  This is how iterators work.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4337>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:19:31 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 16:19:31 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226938771.91.0.0403152578443.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I had forgotten that locks aren't initialized until PyEval_InitThreads
() is called.  Now we check for this case.  Also reinitialize when fork
() is called.
Is there any suggested place where I should add documentation to this?

Added file: http://bugs.python.org/file12032/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:22:23 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 16:22:23 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1226938943.68.0.100810204421.issue4230@psf.upfronthosting.co.za>


Ziga Seilnacht <zseil at users.sourceforge.net> added the comment:

Here is a patch for trunk and 2.5 version. It also contains a fix for
another crasher (see the tests). I only tested the 2.5 patch, because I
don't have the tools for the trunk installed.

----------
keywords: +patch
nosy: +zseil
Added file: http://bugs.python.org/file12033/getattr_hooks_25.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:22:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 17 Nov 2008 16:22:37 +0000
Subject: [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1226938957.29.0.515196088142.issue3327@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r67242

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:22:47 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 16:22:47 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1226938967.6.0.657612887775.issue4230@psf.upfronthosting.co.za>


Changes by Ziga Seilnacht <zseil at users.sourceforge.net>:


Added file: http://bugs.python.org/file12034/getattr_hooks_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:23:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Nov 2008 16:23:27 +0000
Subject: [issue973507] sys.stdout problems with pythonw.exe
Message-ID: <1226939007.26.0.771355125775.issue973507@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> print raises exception when no console available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue973507>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:25:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Nov 2008 16:25:34 +0000
Subject: [issue706263] print raises exception when no console available
Message-ID: <1226939134.45.0.700072145342.issue706263@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python 3.0 already discards the output in this case (see issue1415):
it sets sys.stdout=None and silently ignores prints to the None file.

I think this is the correct behavior, but I'm not sure this can be
backported to 2.7, because of compatibility issues.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706263>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:55:29 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 17 Nov 2008 16:55:29 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1226940929.69.0.407060713457.issue3640@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Will this be back-ported to 2.5.3? (please say yes...)

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Mon Nov 17 18:40:10 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 17 Nov 2008 17:40:10 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

"python3.0 setup.py upload" (on an otherwise sane setup script) results
in the following:


Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import py3setup
  File "/home/MP/hagenf/src/pyskein/py3setup.py", line 22, in <module>
    ext_modules=[ext])
  File "/home/MP/hagenf/local/lib/python3.0/distutils/core.py", line
149, in setup
    dist.run_commands()
  File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line
942, in run_commands
    self.run_command(cmd)
  File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line
962, in run_command
    cmd_obj.run()
  File
"/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line
55, in run
    self.upload_file(command, pyversion, filename)
  File
"/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line
116, in upload_file
    auth = "Basic " + base64.encodestring(self.username + ":" +
self.password).strip()
  File "/home/MP/hagenf/local/lib/python3.0/base64.py", line 338, in
encodestring
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str

----------
components: Distutils
messages: 75975
nosy: hagen
severity: normal
status: open
title: TypeError (bytes/str) in distutils command "upload"
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Mon Nov 17 18:46:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 17 Nov 2008 17:46:34 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1226943994.08.0.681669327929.issue1692335@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Mon Nov 17 20:00:51 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 19:00:51 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1226948451.4.0.323360213353.issue1982@psf.upfronthosting.co.za>


Ziga Seilnacht <zseil at users.sourceforge.net> added the comment:

Do you require millisecond support or would microsecond support be
enough? r61402, which is included in Python 2.6, added support for %f
format to datetime.strftime() and datetime.strptime(). See also #1158.

----------
nosy: +zseil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
_______________________________________

From report at bugs.python.org  Mon Nov 17 20:05:35 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 19:05:35 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226948735.11.0.115852253131.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I turns out that for SIGINT, windows creates a new thread.  So, the 
assumption that signals are delivered on the main thread are not valid 
in general.  Therefore, we must initialize the lock pending_lock 
independently of PyEval_InitThreads(), and also cannot assume that 
signals are deliverd on the main thread.

Added file: http://bugs.python.org/file12035/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Nov 17 20:36:50 2008
From: report at bugs.python.org (chafporte)
Date: Mon, 17 Nov 2008 19:36:50 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226950610.03.0.214511365122.issue4326@psf.upfronthosting.co.za>


chafporte <junk at ysengrin.com> added the comment:

but in python 2.5 you may do this:

if type(lInstance) == types.InstanceType:
    ...
else:
    ...

and I don't see an easy way to do this with python 2.6
(feel free to propose a solution if you have one)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Mon Nov 17 21:14:19 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2008 20:14:19 +0000
Subject: [issue4339] Fix set-like dictview doc
In-Reply-To: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za>
Message-ID: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I see two problems with the current (.rc2) doc on "Dictionary view
objects" that are set-like.

1. The first paragraph of the section ends with the fragment

"The keys and items views have a set-like character since their entries"

This is not only incomplete, but wrong.  Items views are set-like
(entries are unique and hashable) only if all values are hashable, as
revealed way at the end in a 'warning' that is only needed because of
the previous over-generalization.  I recommend that this fragment, the
one sentence after the 'x in dictview' entry, and the warning be
combined into one paragraph that tells the complete story at the
appropriate place, which is where the 'one sentence' is now.

"Keys views are set-like since their entries are unique and hashable. 
If all values are hashable, so that (key,value) pairs are unique and
hashable, then an items view is also set-like.  (Values views are not
treated as set-like since the entries are generally not unique.) Let
'set-view' and 'other' each be a set or set-like view.  Then the
following set operations are available."

This suggestion also addresses the second problem I see.  The set
operations are symmetric, but 'dictview op other' is not.  It excludes
the valid combination 'set op dictview'.  So I think all 4 ops should be
listed as 'set-view op other' instead, after the revised introduction above.

----------
assignee: georg.brandl
components: Documentation
messages: 75979
nosy: georg.brandl, tjreedy
severity: normal
stage: needs patch
status: open
title: Fix set-like dictview doc
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4339>
_______________________________________

From report at bugs.python.org  Mon Nov 17 21:55:59 2008
From: report at bugs.python.org (Mike Watkins)
Date: Mon, 17 Nov 2008 20:55:59 +0000
Subject: [issue4340] xmlrpc.client - default 'SlowParser' not defined
In-Reply-To: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>
Message-ID: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

Running example code from docs:

http://docs.python.org/dev/3.0/library/xmlrpc.client.html#example-of-
client-usage

z% python
Python 3.0rc2+ (py3k:67152, Nov  7 2008, 16:48:55) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> str(None)
'None'
>>> from xmlrpc.client import ServerProxy, Error
>>> server = ServerProxy("http://betty.userland.com")
>>> print(server)
<ServerProxy for betty.userland.com/RPC2>
>>> print(server)
<ServerProxy for betty.userland.com/RPC2>
>>> print(server.examples.getStateName(41))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1095, in 
__call__
    return self.__send(self.__name, args)
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1353, in 
__request
    verbose=self.__verbose
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1136, in 
request
    return self._parse_response(resp, None)
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1235, in 
_parse_response
    p, u = self.getparser()
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1145, in 
getparser
    return getparser(use_datetime=self._use_datetime)
  File "/usr/local/lib/python3.0/xmlrpc/client.py", line 975, in 
getparser
    parser = SlowParser(target)
NameError: global name 'SlowParser' is not defined


No definition of SlowParser in client.py:

/src/py3k/Lib/xmlrpc% grep -n SlowParser client.py
116:  SlowParser     Slow but safe standard parser (based on xmllib)
975:            parser = SlowParser(target)

----------
components: Library (Lib)
messages: 75980
nosy: mwatkins
severity: normal
status: open
title: xmlrpc.client - default 'SlowParser' not defined
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4340>
_______________________________________

From report at bugs.python.org  Mon Nov 17 21:57:09 2008
From: report at bugs.python.org (Andreas Balogh)
Date: Mon, 17 Nov 2008 20:57:09 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1226955429.17.0.877896538493.issue1982@psf.upfronthosting.co.za>


Andreas Balogh <andreas.balogh at gmx.de> added the comment:

Yes, microsecond support is fine. Elaborating on my initial comment.

The following should assert:

a_datetime = datetime.now()
a_datetime.replace(microsecond = 1)

iso_str = adatetime.isoformat()
b_datetime = datetime.strptime(iso_str, "%Y%m%dT%H%M%S.%f")

assert(a_datetime = b_datetime)

The datetime shall be an invariant. 

Fixed from my point of view, Andreas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
_______________________________________

From report at bugs.python.org  Mon Nov 17 21:59:52 2008
From: report at bugs.python.org (Andreas Balogh)
Date: Mon, 17 Nov 2008 20:59:52 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1226955592.56.0.167102219533.issue1982@psf.upfronthosting.co.za>


Andreas Balogh <andreas.balogh at gmx.de> added the comment:

Some typos corrected. Sorry for any inconvenience.

a_datetime = datetime.now()
a_datetime.replace(microsecond = 1)

iso_str = a_datetime.isoformat()
b_datetime = datetime.strptime(iso_str, "%Y-%m-%dT%H:%M:%S.%f")

assert(a_datetime = b_datetime)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:48:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 21:48:02 +0000
Subject: [issue4339] Fix set-like dictview doc
In-Reply-To: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za>
Message-ID: <1226958482.04.0.555320438938.issue4339@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r67244.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4339>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:48:35 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2008 21:48:35 +0000
Subject: [issue4341] Update __hash__ doc
In-Reply-To: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za>
Message-ID: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language/data model/special method names/ __hash__

Sentence 1: "Called for the key object for dictionary operations, and by
the built-in function hash()."

Also called for the members of set and frozenset (and any other hashed
based collection).

Suggestion 1: "Called by the built-in function hash() and for operations
on members or keys of hashed collections. These currently include the
built-in classes set, frozenset, and dict."

Corresponding future-proof changes later in the text:

>From "its instances will not be usable as dictionary keys"

to "its instances will not be usable as hashable members or keys".

>From "since the dictionary implementation requires"

to "since hashable collection implementations require"
==============================

Sentence 2: "Should return an integer usable as a hash value for
dictionary operations."

I am confused by the qualification 'usable....'.  If it does not
qualify, it is meaningless and should be removed.  If it does qualify,
it should be replaced by what it means.

My impression is that integers of any value are usable since 2.5.

It is also my impression that 2.x specifically requires an int or long.
If so, "Should return an int or long integer." would be clearer.

For 3.0, I don't know what the boundaries are.  A float works, even if
not integral. [bug?] A Fraction does not, even if integral, even though
int(Fraction(n,1)) returns n.

----------
assignee: georg.brandl
components: Documentation
messages: 75984
nosy: georg.brandl, tjreedy
severity: normal
stage: needs patch
status: open
title: Update __hash__ doc
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4341>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:03:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Nov 2008 22:03:55 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1226959435.96.0.684561212176.issue4338@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The username:password string should be encoded, but with which encoding?

----------
nosy: +amaury.forgeotdarc, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:05:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 22:05:30 +0000
Subject: [issue4341] Update __hash__ doc
In-Reply-To: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za>
Message-ID: <1226959530.61.0.92280141493.issue4341@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r67245.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4341>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:39:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 22:39:57 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1226961597.13.0.0336431056131.issue4230@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! Fixed in r67246.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:41:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 22:41:56 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226961716.44.0.317702435173.issue4317@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:55:52 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Nov 2008 22:55:52 +0000
Subject: [issue4090] Documenting set comparisons and operations
In-Reply-To: <1223569047.14.0.973921550653.issue4090@psf.upfronthosting.co.za>
Message-ID: <1226962552.47.0.542670824157.issue4090@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r67249

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4090>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:56:44 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Nov 2008 22:56:44 +0000
Subject: [issue4087] Document the effects of NotImplemented on == and !=
In-Reply-To: <1223559584.24.0.470688627133.issue4087@psf.upfronthosting.co.za>
Message-ID: <1226962604.15.0.644888266002.issue4087@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r67249

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4087>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:57:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 17 Nov 2008 22:57:49 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1226962669.16.0.41506989437.issue3640@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Tue Nov 18 00:14:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 17 Nov 2008 23:14:02 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1226963642.46.0.478314088195.issue4338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Encoding of basic auth has a loooong story. I keep forgetting the
details, but one interpretation is that the it needs to be MIME B or Q
encoded first (i.e. through a header encoding), which then needs to be
base64 encoded. For B or Q, you can chose any IANA-registered encoding.

This is not directly specified, but rather an implicit interpretation of
RFC2617, through reference to RFC2616 by using the TEXT production,
which is defined (in 2.2 of 2616) to be either Q or B encoded, unless it
is iso-8859-1 (which apparently can pass unencoded).

Another interpretation is that it should be UTF-8, based on the general
policy of RFC 2277 mandates UTF-8 for all new protocols.

Yet another interpretation is that RFC2617 just doesn't support
non-ASCII user names and passwords.

It is the latter interpretation that we should implement (perhaps with a
comment that this interpretation is debated). However, it does have the
advantage of being a subset of the two other interpretations (which
otherwise contradict each other). For PyPI, I believe it is safe to
assume that both usernames and passwords are restricted to ASCII.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Tue Nov 18 00:18:04 2008
From: report at bugs.python.org (Ziga Seilnacht)
Date: Mon, 17 Nov 2008 23:18:04 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1226963884.9.0.548962019159.issue4230@psf.upfronthosting.co.za>


Ziga Seilnacht <zseil at users.sourceforge.net> added the comment:

Here is another patch, for Python 2.4, which contains only the security
fix. Benjamin, will you also commit these backports?

Added file: http://bugs.python.org/file12036/getattr_hooks_24.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Tue Nov 18 00:35:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Nov 2008 23:35:32 +0000
Subject: [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1226964932.56.0.79079059097.issue4230@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Backported to 2.4 in r67250 and 2.5 in r67251.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4230>
_______________________________________

From report at bugs.python.org  Tue Nov 18 01:08:00 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Nov 2008 00:08:00 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1226966880.12.0.262021522952.issue2260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied simplified patch r67253 .

----------
assignee: georg.brandl -> 
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Tue Nov 18 01:41:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 00:41:33 +0000
Subject: [issue4342] (Tkinter) Please backport these
In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za>
Message-ID: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Please consider backporting r59653 and r59654 to release25-maint branch.

It may be of interest to backport r52688 too, also, r63776 together with
r63914 (without these last two I get segfault when passing a list as an
option value).

Finally there is this issue4333 which wasn't committed anywhere, but if
it gets committed I would like to see it getting backported too.

Thanks.

----------
components: Tkinter
messages: 75995
nosy: gpolo
severity: normal
status: open
title: (Tkinter) Please backport these
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4342>
_______________________________________

From report at bugs.python.org  Tue Nov 18 04:34:03 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 03:34:03 +0000
Subject: [issue3248] ScrolledText can't be placed in a PanedWindow
In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>
Message-ID: <1226979243.4.0.481703134314.issue3248@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

anyone ?

----------
versions: +Python 2.5.3, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3248>
_______________________________________

From report at bugs.python.org  Tue Nov 18 05:16:04 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 04:16:04 +0000
Subject: [issue3248] ScrolledText can't be placed in a PanedWindow
In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>
Message-ID: <1226981764.21.0.602532769931.issue3248@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've changed it a bit more now, this includes dropping support for cnf.
My wish is to actually remove the cnf usage all over Tkinter :)

Added file: http://bugs.python.org/file12037/ScrolledText.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3248>
_______________________________________

From report at bugs.python.org  Tue Nov 18 05:35:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 18 Nov 2008 04:35:36 +0000
Subject: [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226982936.87.0.512030532157.issue4313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r67256. I heard last RC will be released at this Wed, I think
segfault is not good for it.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________

From report at bugs.python.org  Tue Nov 18 05:38:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 18 Nov 2008 04:38:30 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1226983110.19.0.178024812481.issue1028@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I reverted r57540 because it caused segfault at IDLE exit. (See
issue4313) I reopened this issue.

----------
nosy: +ocean-city
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Tue Nov 18 06:48:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2008 05:48:39 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226987319.97.0.39690580591.issue4317@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

When I wrote my patch to fix division by zero (and detection of -n 
* -n overflow), I also wrote a script to test imageop module. I fixed 
the limit of the input string to 1024 bytes, and so the rgb crash was 
not detected. Here is my script with a limit of 2^20 bytes which raise 
the crash. With the patch, there are no more crash ;-)

Added file: http://bugs.python.org/file12038/test_imageop.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Tue Nov 18 08:35:24 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Tue, 18 Nov 2008 07:35:24 +0000
Subject: [issue4337] Iteration over a map object with list()
In-Reply-To: <1226937965.43.0.385534886464.issue4337@psf.upfronthosting.co.za>
Message-ID: <46fcc31b0811172335l95fa7b6q8c849d258c3acc1b@mail.gmail.com>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

2008/11/17 Raymond Hettinger <report at bugs.python.org>

>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> Feature :-)
>
> You will get the expected result if you skip the step where you ran the
> for-loop over r before running list().  Either listing or for-looping
> will exhaust the iterator.  This is how iterators work.
>
> ----------
> nosy: +rhettinger
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4337>
> _______________________________________
>

Thanks for the reply and sorry for the noise. Indeed, you are right and for
some "strange personal reasons" (bad habits?), I frequently fall in this
trap.

    return i + 1

[1, 2, 3, 4]
>>>

Regards

Added file: http://bugs.python.org/file12039/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4337>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081118/452453fc/attachment.txt>

From report at bugs.python.org  Tue Nov 18 09:00:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Nov 2008 08:00:45 +0000
Subject: [issue4326] type of UserList instance returns class instead of
	instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226995245.53.0.842481674878.issue4326@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I repeat, what is this "easy" condition good for?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________

From report at bugs.python.org  Tue Nov 18 09:03:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Nov 2008 08:03:27 +0000
Subject: [issue1694663] Overloading  int.__pow__ does not work
Message-ID: <1226995407.64.0.599495225301.issue1694663@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> zseil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694663>
_______________________________________

From report at bugs.python.org  Tue Nov 18 10:05:30 2008
From: report at bugs.python.org (Anders J. Munch)
Date: Tue, 18 Nov 2008 09:05:30 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1226999130.57.0.920224574506.issue2736@psf.upfronthosting.co.za>


Anders J. Munch <2007 at jmunch.dk> added the comment:

Any thoughts to time zone/DST handling for naive datetime objects? E.g.
suppose the datetime object was created by .utcnow or .utcfromtimestamp.

For aware datetime objects, I think the time.mktime(dt.timetuple())
approach doesn't work; the tz info is lost in the conversion to time tuple.

----------
nosy: +andersjm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Tue Nov 18 11:43:00 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 18 Nov 2008 10:43:00 +0000
Subject: [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1227004980.41.0.0111388531657.issue2029@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
_______________________________________

From report at bugs.python.org  Tue Nov 18 11:44:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 18 Nov 2008 10:44:23 +0000
Subject: [issue4082] python2.6 -m site doesn't run site._script() any more
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1227005063.69.0.373175632031.issue4082@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Christian, is this still a problem for you after the release or can we
close it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:39:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 12:39:19 +0000
Subject: [issue4343] New function in Tkinter.py: setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi,

I've added a new function called setup_master. 

This function is responsible for returning an usable master to the
caller, or fail and say so. The function is useful for any wrapper
basically, since all them has to set up a master sometime (or maybe
always require a master, but that is not very nice) and will usually do
it half wrong. The half wrong is about relying on _default_root being
available in Tkinter, which is not the case if support for default root
has been disabled.

There are two patches, the first adds the function, the second applies
it self where necessary in Tkinter. The later also adds some new
behaviour in Tkinter, previously Variable class and subclasses wouldn't
work properly without prior creation of a master (there are similar
problems in other parts too).

----------
components: Tkinter
files: setup_master.diff
keywords: patch
messages: 76005
nosy: gpolo
severity: normal
status: open
title: New function in Tkinter.py: setup_master
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12040/setup_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:39:36 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 12:39:36 +0000
Subject: [issue4343] New function in Tkinter.py: setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1227011976.47.0.274275930088.issue4343@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Added file: http://bugs.python.org/file12041/applying_setup_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:45:47 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 12:45:47 +0000
Subject: [issue4343] New function in Tkinter.py: setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1227012347.19.0.575819509713.issue4343@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file12040/setup_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:45:59 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 12:45:59 +0000
Subject: [issue4343] New function in Tkinter.py: setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1227012359.61.0.272484399231.issue4343@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Added file: http://bugs.python.org/file12042/setup_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:49:41 2008
From: report at bugs.python.org (kasper)
Date: Tue, 18 Nov 2008 12:49:41 +0000
Subject: [issue4344] crash upon launch
In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
Message-ID: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>


New submission from kasper <kr_900 at hotmail.com>:

Hi 

I'm new at programming and have chosen to start with python, and so I
have installed python 2.6, and played around with it a little. 
However, a problem has occured: yesterday when i tried to run the
program - pythonwin editor 2.6.0 - a crash occured immediately upon
launch. All i do is start up the program, and while trying to open, the
program crashes, and a windows error window pops up, telling me that
'the program has encountered an error, and will now exit' - not telling
me anything useful about what kind of error has occured, or why. As
usual, the windows errorreport is of no use. And so I have little idea
of what causes the crash, but I do have a suspicion that the .dll
mfc90.dll might be a part of the problem, since it is mentioned in the
beginning of the errorreport.

Looking forward to hear from you.

Kasper

----------
components: Windows
messages: 76006
nosy: source.mod
severity: normal
status: open
title: crash upon launch
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4344>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:01:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 13:01:22 +0000
Subject: [issue3767] tkColorChooser may fail if no color is selected
In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za>
Message-ID: <1227013282.37.0.361459515112.issue3767@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've noticed a problem with the previous patch, so this new one includes
a comment too so people can remember about the check being applied.

----------
versions: +Python 2.5.3, Python 2.7
Added file: http://bugs.python.org/file12043/tkColorChooser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3767>
_______________________________________

From report at bugs.python.org  Tue Nov 18 15:01:15 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 14:01:15 +0000
Subject: [issue4345] Implement nb_nonzero for PyTclObject
In-Reply-To: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za>
Message-ID: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Implementing it makes this "crazy" check in
http://bugs.python.org/issue3767
(http://bugs.python.org/file12043/tkColorChooser.diff) be no longer needed

----------
components: Tkinter
files: _tkinter__nonzero__.diff
keywords: patch
messages: 76008
nosy: gpolo
severity: normal
status: open
title: Implement nb_nonzero for PyTclObject
versions: Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12044/_tkinter__nonzero__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4345>
_______________________________________

From report at bugs.python.org  Tue Nov 18 15:15:20 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 14:15:20 +0000
Subject: [issue4346] PyObject_CallMethod changes the exception message already
	set by PyObject_GetAttr
In-Reply-To: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>
Message-ID: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Why is PyObject_CallMethod resetting the exception message that is
already set (if an exception happened, that is) by PyObject_Getattr ?

----------
components: Interpreter Core
files: abstract_dont_re_set_except_msg.diff
keywords: patch
messages: 76009
nosy: gpolo
severity: normal
status: open
title: PyObject_CallMethod changes the exception message already set by PyObject_GetAttr
versions: Python 2.7
Added file: http://bugs.python.org/file12045/abstract_dont_re_set_except_msg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4346>
_______________________________________

From report at bugs.python.org  Tue Nov 18 16:28:11 2008
From: report at bugs.python.org (Thomas Lee)
Date: Tue, 18 Nov 2008 15:28:11 +0000
Subject: [issue4347] Dependencies of graminit.h are not rebuilt when the file
	is regenerated
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>


New submission from Thomas Lee <tom at vector-seven.com>:

It's important that dependencies of grammar.h get rebuilt if graminit.h
is regenerated (e.g. the Grammar is modified). If these dependencies do
not get rebuilt, the constants associated with each type of parse node
will have inconsistent values between the different intermediate files.

The net result is that a program afflicted by this might build without
errors, but then crash unexpectedly at runtime due to the inconsistent
constant values.

The patch is quite simple and ensures that all files that currently
depend on graminit.h are rebuilt if it changes.

It also removes an unnecessary #include from Python/future.c.

I believe a similar situation might occur with Python-ast.h and the
*_kind enumerations, but have yet to run into such a specific issue.
I'll post a separate patch if I do find this to be a problem.

----------
components: Build
files: graminit-dependencies.patch
keywords: patch
messages: 76010
nosy: thomas.lee
severity: normal
status: open
title: Dependencies of graminit.h are not rebuilt when the file is regenerated
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12046/graminit-dependencies.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:13:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 18 Nov 2008 21:13:59 +0000
Subject: [issue4344] crash upon launch
In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
Message-ID: <1227042839.78.0.792692970527.issue4344@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What URL precisely did you download Python from? Where precisely did you
get pythonwin from?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4344>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:29:15 2008
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 18 Nov 2008 21:29:15 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

In 2.6 but not in 3.0 RC2:

x = bytearray(b'abc')
y = x.replace(b'abc', b'bar', 0)
id(x) == id(y)

In 2.6 and in 3.0 RC2:

t = bytearray()
for i in range(256): t.append(i)

x = bytearray(b'')
y = x.translate(t)
id(x) == id(y)

----------
messages: 76012
nosy: DinoV
severity: normal
status: open
title: bytearray methods returning self
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:33:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 21:33:14 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227043994.25.0.397323248902.issue4348@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:36:32 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 18 Nov 2008 21:36:32 +0000
Subject: [issue4349] sys.path includes extraneous junk
In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
Message-ID: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

With a recent build of the py3k branch, sys.path ends up with this element:

/home/exarkun/Projects/python/branches/py3k/Lib/plat-linux2 at EXTRAMACHDEPPATH@

which doesn't exist and doesn't look like it should exist.  plat-linux2,
which does exist, doesn't end up winth sys.path.

----------
components: Interpreter Core
messages: 76013
nosy: exarkun
severity: normal
status: open
title: sys.path includes extraneous junk
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4349>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:41:16 2008
From: report at bugs.python.org (kasper)
Date: Tue, 18 Nov 2008 21:41:16 +0000
Subject: [issue4344] crash upon launch
In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
Message-ID: <1227044476.69.0.0555631619602.issue4344@psf.upfronthosting.co.za>


kasper <kr_900 at hotmail.com> added the comment:

i got it from this URL, which i believe is indeed not phoney:
http://www.activestate.com/store/productdetail.aspx?prdGuid=b08b04e0-6872-4d9d-a722-7a0c2dea2758

it's their own homepage. 

would you happen to know why this happens? the problem occurs eventhough
i uninstall and reinstall the program. same error, only mentioning that
mfc90.dll.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4344>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:41:30 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Nov 2008 21:41:30 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227044490.15.0.117269199285.issue4348@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that the results for 3.0c2 are False (correct) and True (bug).
Guido today on pydev: this is a bug IMO and we should fix it in 2.6.1
and 3.0rc3

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:43:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Nov 2008 21:43:14 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227044594.85.0.699425691763.issue4348@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'll try to come up with some tests and a fix later.

----------
nosy: +christian.heimes
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:45:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 21:45:28 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227044728.92.0.259171826861.issue4348@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching patch.

----------
keywords: +needs review, patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file12047/make_sure_to_copy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:56:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 18 Nov 2008 21:56:26 +0000
Subject: [issue4344] crash upon launch
In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
Message-ID: <1227045386.28.0.925217262351.issue4344@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If this is a problem in ActivePython, please report it to ActiveState.
This bug tracker is for bugs in Python only as downloaded from
www.python.org.

----------
resolution:  -> invalid
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4344>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:59:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 21:59:02 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227045542.62.0.0853770775133.issue4348@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's another patch for 2.7/2.6 that handles the translation problem
correctly. It appears that the return_self problem isn't present in 3.0,
but that can be handled in the merge.

Added file: http://bugs.python.org/file12048/copies_when_no_change.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:06:08 2008
From: report at bugs.python.org (Eric Huss)
Date: Tue, 18 Nov 2008 22:06:08 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1227045968.08.0.15554996764.issue1692335@psf.upfronthosting.co.za>


Eric Huss <eric at huss.org> added the comment:

I'm disappointed to see this closed.  Exception pickling is still broken
in some cases in 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:17:05 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 18 Nov 2008 22:17:05 +0000
Subject: [issue4116] name conflict in ScrolledCanvas.__init__() in
	Lib/turtle.py
In-Reply-To: <1223938627.85.0.00676973039125.issue4116@psf.upfronthosting.co.za>
Message-ID: <1227046625.25.0.770059984491.issue4116@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I'd like to see this patch accepted and done for Python 2.6.1 and (at
the same time) python 3.0 before the last rc is released. So could you
dedicate a few minutes to reviewing it.

To demonstrate the nature of this issue (and also the nuisance it could
produce) I've constructed a minimal example to show the consequences of
the bug:

import turtle

s = turtle.Screen()

def changecolor():
    s.bgcolor(1.0, 0.5)  # needs 3 floats as arguments

s.ontimer(changecolor, 1000)
turtle.mainloop()

This should create an error message like this:
....
TurtleGraphicsError: bad color arguments: (100, 100)

Instead it results in:

Traceback (most recent call last):
  File "C:\_\provoke_error.py", line 11, in <module>
    turtle.mainloop()
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 325, in mainloop
    _default_root.tk.mainloop(n)
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1414, in __call__
    self.widget._report_exception()
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1175, in _report_exception
    root = self._root()
AttributeError: _Root instance has no __call__ method

because the _root() method defined in line 1105 of Tkinter.py is
overwritten by the _root attribute of ScrolledCanvas (lines 362 and
382). So in these (hopefully rare) cases where an error message is
directly provoked from the Tkinter module, this will fail letting the
user without clue about what happened. 

With the proposed patch applied, the above script produces the correct
error message.

Regards, Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4116>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:19:28 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 18 Nov 2008 22:19:28 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227046768.26.0.817155236704.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I'd also like to see this patch accepted and done for Python 2.6.1 and
(at the same time) python 3.0 before the last rc is released. So perhaps
you could you dedicate a few minutes to this one also.

Thanks for your efforts,
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:24:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 22:24:10 +0000
Subject: [issue4349] sys.path includes extraneous junk
In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
Message-ID: <1227047050.87.0.881632299525.issue4349@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a simple patch.

----------
keywords: +needs review, patch
nosy: +benjamin.peterson
priority:  -> release blocker
Added file: http://bugs.python.org/file12049/remove_old_cruft.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4349>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:32:50 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Nov 2008 22:32:50 +0000
Subject: [issue4349] sys.path includes extraneous junk
In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
Message-ID: <1227047570.92.0.0984292190231.issue4349@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Go on

----------
nosy: +christian.heimes
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4349>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:37:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 22:37:25 +0000
Subject: [issue4349] sys.path includes extraneous junk
In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
Message-ID: <1227047845.79.0.91039513438.issue4349@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67269.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4349>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:52:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Nov 2008 22:52:20 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1227048740.11.0.182731001733.issue1692335@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

OK, reopening. Can you post an example that fails today?

----------
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:54:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Nov 2008 22:54:39 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1227048879.65.0.421167500335.issue1692335@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy:  -benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:56:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 18 Nov 2008 22:56:22 +0000
Subject: [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1227048982.14.0.157193334495.issue4317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in revisions r67266, 67267, r67268, r67270: (trunk, 2.6, 2.5, 2.4)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________

From report at bugs.python.org  Wed Nov 19 00:07:22 2008
From: report at bugs.python.org (Eric Huss)
Date: Tue, 18 Nov 2008 23:07:22 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1227049642.42.0.973570146613.issue1692335@psf.upfronthosting.co.za>


Eric Huss <eric at huss.org> added the comment:

In the attached test_exception_pickle.py file, class C and D cannot be
unpickled (raises TypeError).

class C(Exception):
    """Extension with values, args not set."""
    def __init__(self, foo):
        self.foo = foo

class D(Exception):
    """Extension with values, init called with no args."""
    def __init__(self, foo):
        self.foo = foo
        Exception.__init__(self)

There are also some other exceptions that fail to be handled properly. 
See the exception_pickling_26.diff for some unittests.  In particular, I
see SlotedNaiveException failing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:05:06 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 00:05:06 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227053106.99.0.307169589875.issue4117@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Why are you using update instead of update_idletasks ? 
I'm not talking exactly about this line being added, but this ends up
calling TurtleScreenBase._update which calls self.cv.update(), cv being
a canvas. update_idletasks should be used exactly for performing the
kind of tasks expected here, display update and window layout
calculations, while calling update may also process other events or
pending errors.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:14:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 00:14:19 +0000
Subject: [issue4350] Remove dead code from Tkinter.py
In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za>
Message-ID: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

There are some methods (which call tk commands) that no longer exist,
for a long time now so this patch remove them.

There are also these "indices" functions, which do not belong to the
module space and now are gone too.

----------
files: remove_dead_code.diff
keywords: patch
messages: 76030
nosy: gpolo
severity: normal
status: open
title: Remove dead code from Tkinter.py
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12050/remove_dead_code.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4350>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:22:34 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 19 Nov 2008 00:22:34 +0000
Subject: [issue4351] [PATCH] Better stacklevel for GzipFile.filename
	DeprecationWarning
In-Reply-To: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za>
Message-ID: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

This should be a stacklevel of 2 so we're told who accessed the attribute

----------
components: Library (Lib)
files: gzip-deprecation_r67276.diff
keywords: patch
messages: 76031
nosy: pjenvey
severity: normal
status: open
title: [PATCH] Better stacklevel for GzipFile.filename DeprecationWarning
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12051/gzip-deprecation_r67276.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4351>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:34:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 00:34:19 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227054859.15.0.431945445925.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can reproduce it here with tk8.4, using tk8.5 doesn't cause this.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:57:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 00:57:00 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227056220.51.0.931284581808.issue4338@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I indeed tested that the PyPI user registration refuses non-ascii 
characters in both username and password.

But the reported error is only the first of a bytes/str mess.
See attached patch.

- I chose to encode package metadata with utf-8
- Since I did not set credentials in some .pypirc file, the submission 
fails; my first tests on a sample package returned a 401 error (normal) 
but now I only get 200 return codes. I hope my package will not show up 
in PyPI...

This needs more testing with a real package of a real developer.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file12052/distutils_upload.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 02:15:36 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 01:15:36 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227057336.74.0.351406698467.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Here is a patch that doesn't use magic numbers :P
I didn't hit the problem described in issue4313 with this one, and
PythonCmd should be doing this anyway, but ideally we should move to
Tcl_CreateObjCommand.

Added file: http://bugs.python.org/file12053/PythonCmd_check_for_utf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 02:19:15 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 01:19:15 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227057555.55.0.82457586192.issue1028@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file12053/PythonCmd_check_for_utf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 02:19:35 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 01:19:35 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227057575.65.0.585199103153.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Removed some repeated code in the patch

Added file: http://bugs.python.org/file12054/PythonCmd_check_for_utf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 03:52:53 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Nov 2008 02:52:53 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227063173.73.0.933091258763.issue4348@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since 3.0c2 bytearray.translate() *does* return self with no change, I
don't understand your first comment, unless you meant 'is' instead of
'is not'.  But I presume merging forward will fix it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Wed Nov 19 04:36:41 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 19 Nov 2008 03:36:41 +0000
Subject: [issue1108] Problem with doctest and decorated functions
In-Reply-To: <1188989604.95.0.0786142357028.issue1108@psf.upfronthosting.co.za>
Message-ID: <1227065801.35.0.353284922109.issue1108@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I applied this patch to my trunk sandbox.  It seems to solve the problem
I just encountered where doctests are hidden in decorated functions &
tests pass.  Checked in as r67277.  Should be backported to 2.6 and
forward ported to 3.0.

----------
assignee: tim_one -> skip.montanaro
nosy: +skip.montanaro
resolution:  -> accepted
stage:  -> patch review
status: open -> closed
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1108>
_______________________________________

From report at bugs.python.org  Wed Nov 19 04:38:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 19 Nov 2008 03:38:45 +0000
Subject: [issue1108] Problem with doctest and decorated functions
In-Reply-To: <1188989604.95.0.0786142357028.issue1108@psf.upfronthosting.co.za>
Message-ID: <1227065925.19.0.404098946438.issue1108@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1108>
_______________________________________

From report at bugs.python.org  Wed Nov 19 06:17:46 2008
From: report at bugs.python.org (Jukka Aho)
Date: Wed, 19 Nov 2008 05:17:46 +0000
Subject: [issue4352] imp.find_module() causes UnicodeDecodeError with
	non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>


New submission from Jukka Aho <jukka.aho at iki.fi>:

imp.find_module() seems to cause an UnicodeDecodeError when the path
list contains paths with non-ASCII names. Tested on Windows [1]; see the
attached test case which demonstrates the problem.

[1] Python 3.0rc2 (r30rc2:67141, Nov  7 2008, 11:43:46) [MSC v.1500 32
bit (Intel)] on win32

----------
components: Library (Lib), Unicode, Windows
files: find_module.py
messages: 76038
nosy: Jukka Aho
severity: normal
status: open
title: imp.find_module() causes UnicodeDecodeError with non-ASCII search paths
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12055/find_module.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Wed Nov 19 06:42:32 2008
From: report at bugs.python.org (Jukka Aho)
Date: Wed, 19 Nov 2008 05:42:32 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1227073352.49.0.077247444616.issue4352@psf.upfronthosting.co.za>


Changes by Jukka Aho <jukka.aho at iki.fi>:


----------
title: imp.find_module() causes UnicodeDecodeError with non-ASCII search paths -> imp.find_module() fails with a UnicodeDecodeError when called with non-ASCII search paths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Wed Nov 19 06:43:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 05:43:28 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227073408.29.0.0686570157613.issue4338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Hagen's strategy is about right: report one problem at a time.

Of course, it would speed up the process if Hagen would provide a patch
that fixes a number of such issues at one. Without such an effort, it is
likely that distutils in 3.0 just won't work. I don't see that as a
serious problem, since there will be a 3.0.1 release, and a 3.0.2
release, and so on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 06:55:20 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 05:55:20 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227074120.21.0.983635442437.issue4338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Your patch seems to contain a number of unrelated changes, such as
introducing an abbreviation for http.client, and using .reqest() instead
of putrequest/putheader/endheaders/send. What is the rationale for these
changes? If they are unrelated to this issue, they should be removed
from the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 07:01:22 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 19 Nov 2008 06:01:22 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227074482.96.0.683159097384.issue1028@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I confirmed PythonCmd_check_for_utf.diff worked on my machine. IDLE
didn't crash.

>I can reproduce it here with tk8.4, using tk8.5 doesn't cause this.

That is, this is a bug of tk8.4, and solved in tk8.5 which is already
stable release? If so, I feel python don't have to workaround this bug.

# I'm a little worry about performance because Tcl_NumUtfChars() will be
called for every command string.

By the way, I cannot reproduce this bug with tk8.4.12(on windows). What
is your tk version? Maybe older than that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 10:15:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 09:15:21 +0000
Subject: [issue4116] name conflict in ScrolledCanvas.__init__() in
	Lib/turtle.py
In-Reply-To: <1223938627.85.0.00676973039125.issue4116@psf.upfronthosting.co.za>
Message-ID: <1227086121.81.0.860688094779.issue4116@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r67279, r67280, and r67281.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4116>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:27:08 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 10:27:08 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227090428.47.0.398028989008.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

tk 8.4.19 here, but windows and linux almost surely uses different
window managers (you could run gnome and others under windows, but I'm
betting it is not the case).

Now, it is very hard to say that we shouldn't care about this bug here.
Tcl has it documented that its string arguments to Tcl_CmdProc are
encoded in normalized utf-8 since tcl 8.1 which was released almost 10
years ago. I guess we are just luck that this was the first time the bug
was noticed.

It also says that Tcl_CreateCommand shouldn't be used anymore, instead
Tcl_CreateObjCommand should be used like I said in the previous comment.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:00:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 12:00:22 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227096022.43.0.726815867466.issue4338@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To correct the reported problem, 3 lines are indeed enough.

I just wanted to test my changes, so I ran "setup.py bdist upload" on my
favourite package, even if I expect it to fail at the end because I
don't have a valid PyPI account.

Here are the problems I encountered:
- io.StringIO is used but "import io" is missing
- http = http.client.HTTPConnection() fails because the local variable
has the same name as the imported module
- the http body must be a bytes string

I agree that the change around http.request() is not needed.
Here is another patch with less changes.
It is also more correct that the previous one, now I receive a http 401
error which means that the request was at least understood by the server.

Added file: http://bugs.python.org/file12056/distutils_upload_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:11:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 12:11:16 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227096676.85.0.603890275138.issue4338@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file12056/distutils_upload_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:12:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 12:12:00 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227096720.68.0.237579054972.issue4338@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file12057/distutils_upload_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:13:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2008 13:13:18 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1227100398.16.0.169711676891.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The example works correctly on Linux (py3k trunk). The problem is maybe 
specific to Windows?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:31:48 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 19 Nov 2008 13:31:48 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227101508.39.0.96881720411.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I cannot call the Canvas method _update_idletasks() from within
_Screen.setup() becaus this would contradict to the architecture of the
module which isolates all direct references to Tkinter to
TurtleScreenBase. (The idea behind this is to make the module easily
portable, by porting only this class).

So if one followed your proposition one had to change TurtleScreenBase
which would result in a different (additional) patch.

For now I'd like to stick with the one proposed here - I worked a lot
with it, it works and I didn't experience unwanted side effects.

My question: I suppose to change the call self.cv.update() to
self.cv.update_idletasks() in TurtleScreenBase._update wouldn't work
properly so one had to add a new method to TurtleScreenBase - something
like TurtleScreenBase._update_idletasks. Originally I had the intention
to keep this interface as small as possible and use only things that are
really needed. Did you experience any problems or undesired behaviour
because of using unly cv.update? If so, please report it. Perhaps you
could also provide an example.

Regards,
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:43:07 2008
From: report at bugs.python.org (TJ Usiyan)
Date: Wed, 19 Nov 2008 13:43:07 +0000
Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1227102187.11.0.993223791626.issue4017@psf.upfronthosting.co.za>


TJ Usiyan <griotspeak at gmail.com> added the comment:

same here

----------
nosy: +TJ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4017>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:52:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 13:52:17 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1227102737.06.0.286595651841.issue4352@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed. It happens when the filesystem encoding is not utf-8.

I have several changes in my local workspace about this, which also deal
with zipimport and other places that import modules.
I suggest to let 3.0 go out and correct all this for 3.1.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:56:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 13:56:01 +0000
Subject: [issue4289] Python 2.6 installer crashes when selecting 'advanced'
	and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1227102961.66.0.0905073378225.issue4289@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. Fixed in r67283, r67284, and r67285.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________

From report at bugs.python.org  Wed Nov 19 15:21:08 2008
From: report at bugs.python.org (Thomas Lee)
Date: Wed, 19 Nov 2008 14:21:08 +0000
Subject: [issue4347] Dependencies of graminit.h are not rebuilt when the file
	is regenerated
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1227104468.7.0.345777422516.issue4347@psf.upfronthosting.co.za>


Thomas Lee <tom at vector-seven.com> added the comment:

Updating affected versions. Probably affects 3.x too.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:34:27 2008
From: report at bugs.python.org (rocky bernstein)
Date: Wed, 19 Nov 2008 15:34:27 +0000
Subject: [issue4353] Move description what a trace should should return to
	settrace from pdb section into sys.settrace section
In-Reply-To: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za>
Message-ID: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za>


New submission from rocky bernstein <rocky at gnu.org>:

This sentence:

  The local trace function should return a reference to itself (or to
another function for further tracing in that scope), or None to turn off
tracing in that scope. 

which appears under "How it [the debugger] Works" (http://docs.python.org
http://docs.python.org/library/pdb.html#debugger-hooks) should appear
under the description of (sys.settrace
http://docs.python.org/library/sys.html) since this really part of the
settrace interface and is not limited to the python debugger, pdb, or
debuggers in general.

----------
assignee: georg.brandl
components: Documentation
messages: 76051
nosy: georg.brandl, rocky
severity: normal
status: open
title: Move description what a trace should should return to settrace from pdb section into sys.settrace section
type: crash
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4353>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:38:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 15:38:47 +0000
Subject: [issue4008] IDLE: checksyntax() doesn't support Unicode?
In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>
Message-ID: <1227109127.86.0.795439202175.issue4008@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This patch has two problems:
1. saving files fails, since there is still a call left to the function
coding_spec, but that function is removed.
2. if saving would work: it doesn't preserve the line endings of the
original file when writing it back. If you open files with DOS line
endings on Unix, upon saving, they should still have DOS line endings.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4008>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:45:43 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 19 Nov 2008 15:45:43 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1227109543.53.0.246395536329.issue4309@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Changing the string to type byte

'Works'
from ctypes import *
libc = CDLL('libc.so.6')
libc.printf(b'hello')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:56:20 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 15:56:20 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227110180.11.0.484209564396.issue4338@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I just tested Amaury's patch and it seems to work fine.

There's a similar str/bytes issue with the "register" command, but I'll
open another issue for that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:11:59 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 16:11:59 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The distutils command "register" has two problems with Python 3.0:

1. The authentication dialog crashes because of a problem with the
functiopn raw_input defined there.

2. Uploading the data fails because of str/bytes confusion.

The attached patch addresses both problems.

----------
components: Distutils
files: distutils_register.patch
keywords: patch
messages: 76055
nosy: hagen
severity: normal
status: open
title: distutils.command.register is broken
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12058/distutils_register.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:19:54 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 16:19:54 +0000
Subject: [issue4355] Error in docs of urllib.request and urllib.parse
In-Reply-To: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za>
Message-ID: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The docs refer to urllib.urlencode instead of urllib.parse.urlencode. A
patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: doc_urlencode.patch
keywords: patch
messages: 76056
nosy: georg.brandl, hagen
severity: normal
status: open
title: Error in docs of urllib.request and urllib.parse
versions: Python 3.0
Added file: http://bugs.python.org/file12059/doc_urlencode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4355>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:57:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 16:57:09 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1227113829.01.0.939539205054.issue4323@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that removes the entire IDLE coding option machinery,
thus implementing PEP 3120.

----------
keywords: +needs review
Added file: http://bugs.python.org/file12060/remove_coding_option.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:59:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 16:59:59 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227113999.11.0.501632217412.issue4354@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good to me.
You can however remove the "import sys": it is not needed.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:13:51 2008
From: report at bugs.python.org (Mike Watkins)
Date: Wed, 19 Nov 2008 17:13:51 +0000
Subject: [issue4340] xmlrpc.client - default 'SlowParser' not defined
In-Reply-To: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>
Message-ID: <1227114831.32.0.944182526897.issue4340@psf.upfronthosting.co.za>


Mike Watkins <python at mikewatkins.ca> added the comment:

Running the same code today passes, despite the fact I'm still running 
the same svn version. Bizarre. 

However the core reported issue - SlowParser being undefined in the 
module, remains.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4340>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:17:28 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 19 Nov 2008 17:17:28 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

It'd be helpful of the functions in the "bisect" modules will have a
"key" argument just like "sort".

----------
messages: 76060
nosy: tebeka
severity: normal
status: open
title: Add "key" argument to "bisect" module functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:17:47 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 19 Nov 2008 17:17:47 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227115067.72.0.445974532776.issue4356@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
components: +Library (Lib)
type:  -> feature request
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:39:32 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 17:39:32 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227116372.37.0.242418081074.issue4354@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Attached new patch without "sys".

Added file: http://bugs.python.org/file12061/distutils_register_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:41:28 2008
From: report at bugs.python.org (Alex Samuel)
Date: Wed, 19 Nov 2008 17:41:28 +0000
Subject: [issue4357] frozen?set operations create incorrectly initialized
	instances of subclasses
In-Reply-To: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>
Message-ID: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>


New submission from Alex Samuel <alex at alexsamuel.net>:

Methods of set and frozenset that return new set or frozenset instances
return instances of subclasses, but these instances are not initialized
correctly.  In the attached code sample, z is an instance of MySet but
MySet.__new__ and MySet.__init__ are never called on it.  

It seems to me that such a method should return a fully-initialized
instance of the subclass.  Barring that, it should just return a set or
frozenset instance, not an instance of the subclass.

----------
assignee: theller
components: ctypes
files: fs.py
messages: 76062
nosy: alexhsamuel, theller
severity: normal
status: open
title: frozen?set operations create incorrectly initialized instances of subclasses
type: behavior
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file12062/fs.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4357>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:05:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Nov 2008 18:05:49 +0000
Subject: [issue4357] frozen?set operations create incorrectly initialized
	instances of subclasses
In-Reply-To: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>
Message-ID: <1227117949.36.0.00808140183672.issue4357@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The bug is that the set operations return instances of the subclass,
rather than instances of set.

This is already fixed for 3.0: see issue 1721812.  It was deemed too risky 
to backport the change to 2.x.

----------
assignee: theller -> 
components: +Interpreter Core -ctypes
nosy: +marketdickinson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4357>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:32:42 2008
From: report at bugs.python.org (Alex Samuel)
Date: Wed, 19 Nov 2008 18:32:42 +0000
Subject: [issue4357] frozen?set operations create incorrectly initialized
	instances of subclasses
In-Reply-To: <1227117949.36.0.00808140183672.issue4357@psf.upfronthosting.co.za>
Message-ID: <49245BC7.7090601@alexsamuel.net>


Alex Samuel <alex at alexsamuel.net> added the comment:

In the sample code I attached, z is an instance of MySet under 3.0rc2.  Is 
that expected?

Thanks,
Alex

Mark Dickinson wrote:
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> The bug is that the set operations return instances of the subclass,
> rather than instances of set.
> 
> This is already fixed for 3.0: see issue 1721812.  It was deemed too risky 
> to backport the change to 2.x.
> 
> ----------
> assignee: theller -> 
> components: +Interpreter Core -ctypes
> nosy: +marketdickinson
> resolution:  -> duplicate
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4357>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4357>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:33:30 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 19 Nov 2008 18:33:30 +0000
Subject: [issue4332] asyncore.file_dispatcher does not use dup()'ed fd
In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
Message-ID: <1227119610.75.0.641127614701.issue4332@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Oy.  You are right.  Fixed in Py3k in r67286, in trunk (2.7) in r67287, 
and 2.6-maintenance in r67288.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4332>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:34:30 2008
From: report at bugs.python.org (Farshad Khoshkhui)
Date: Wed, 19 Nov 2008 18:34:30 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>


New submission from Farshad Khoshkhui <farshadkh at gmail.com>:

I'm encountering random segfaults on multiple machines. By examining
core dumps, it's all happening  in stringobject.c (_PyString_Resize or
string_join). 
By using pyframev I figured out it's always happening inside
xmlrpclib.py (/usr/lib/python2.5/xmlrpclib.py (716): dump_struct or
/usr/lib/python2.5/xmlrpclib.py (627): dumps)

I'm using Python 2.5.2 on debian in a threaded environment with heavy
use of xmlrpc.

----------
assignee: theller
components: XML, ctypes
files: backtrace1
messages: 76066
nosy: farshad, theller
severity: normal
status: open
title: Segfault in stringobject.c
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12063/backtrace1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:35:20 2008
From: report at bugs.python.org (Farshad Khoshkhui)
Date: Wed, 19 Nov 2008 18:35:20 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227119720.06.0.209286527919.issue4358@psf.upfronthosting.co.za>


Farshad Khoshkhui <farshadkh at gmail.com> added the comment:

Another Backtrace. I have three other core dumps with exact same
backtrace on two different machines.

Added file: http://bugs.python.org/file12064/backtrace2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:35:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 18:35:45 +0000
Subject: [issue4357] frozen?set operations create incorrectly initialized
	instances of subclasses
In-Reply-To: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>
Message-ID: <1227119745.97.0.307210146527.issue4357@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, this was changed only three days ago.
Please wait for the next 3.0rc3...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4357>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:00:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 19 Nov 2008 19:00:32 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227121232.16.0.189853492128.issue4358@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Has nothing to do with ctypes (the package), unassigning.

----------
components:  -ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:19:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 19:19:31 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227122371.53.0.822925724393.issue4354@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:26:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 19:26:55 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227122815.23.0.701817777109.issue2306@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:50:59 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 19 Nov 2008 19:50:59 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227124259.71.0.0350494058195.issue4358@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
assignee: theller -> 
nosy:  -theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Wed Nov 19 21:35:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 20:35:07 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227126907.39.0.93162113932.issue4348@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

make_sure_to_copy.patch seems fine short of adding a comment to the test
referencing this issue.

----------
assignee:  -> benjamin.peterson
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Wed Nov 19 22:04:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 21:04:43 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1227101508.39.0.96881720411.issue4117@psf.upfronthosting.co.za>
Message-ID: <49247F65.30408@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I cannot call the Canvas method _update_idletasks() from within
> _Screen.setup() becaus this would contradict to the architecture of the
> module which isolates all direct references to Tkinter to
> TurtleScreenBase. (The idea behind this is to make the module easily
> portable, by porting only this class).

I find that desire misguided; this is (IMO) a case of false abstraction.
Is there any kind of proof that this design actually
works, i.e. can be ported to a different GUI library (like, say,
PythonWin? or AWT, when run in Jython?)

Unless such proof can be provided (and then integrated into the code),
I recommend to give up that objective, and start merging the base class
code into the subclasses where reasonable.

> Did you experience any problems or undesired behaviour
> because of using unly cv.update?

I agree with with gpolo: it's a general Tk programming principle to
defer updates whenever possible. This allows the event handler to return
more quickly, making the system more responsive. Each individual update
call will only contribute a small amount of time to the response time.
It's many of these which eventually make the entire system sluggish.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Wed Nov 19 22:22:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 Nov 2008 21:22:35 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227129755.45.0.0422917303918.issue4348@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Removed file: http://bugs.python.org/file12047/make_sure_to_copy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Wed Nov 19 22:29:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 21:29:20 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227130160.49.0.229101543017.issue4348@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And it turns out I should have looked at the other patch instead. =)

The missing comment from the test still holds. I also think you did not
need to cut out the fast path from translate as much as you did when
there is no deletion. It's still legitimate to goto 'done' if you put
back the work being done in the 'if' statement. You can see my attached
patch to see what I mean.

Otherwise it looks good.

Added file: http://bugs.python.org/file12065/issue4348.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Wed Nov 19 22:39:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Nov 2008 21:39:57 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227130797.59.0.305882766365.issue4356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This request has come up repeatedly (and been rejected) in the past.  See issues 2954, 3374, 1185383, 1462228, 1451588, 1619060.

Could you perhaps explain your particular use case for this?  A few truly 
convincing use-cases might increase the chances of this getting accepted.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Wed Nov 19 22:50:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 Nov 2008 21:50:58 +0000
Subject: [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227131458.58.0.229369405255.issue4348@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67291.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:08:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 22:08:17 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1227132497.72.0.63783678205.issue4236@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So if you look at Python/pythonrun.c, there is a comment from Tim Peters
(from r34776) where he explicitly points out that this is possibility
but that it has never been reported before. Oops. =)

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:27:23 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 22:27:23 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1227133643.92.0.106180277198.issue4236@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't think there is anything to fix here beyond the docs for __del__.
You should never expect anything to be working in __del__, and that
includes the import machinery. It should be bare-bones, not trying to
pull in new code!

I have attached a patch which tries to clarify this fact in the language
docs for __del__.

Added file: http://bugs.python.org/file12066/clarify___del__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:11:30 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 19 Nov 2008 23:11:30 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227136290.66.0.374277509383.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

> > I find that desire misguided; this is (IMO) a case of false abstraction.
> > Is there any kind of proof that this design actually
> > works, i.e. can be ported to a different GUI library (like, say,
> > PythonWin? or AWT, when run in Jython?)
   
Yes there is. I have a (nearly complete) port to Pygame. (The only 
exception is the ondrag method, which I will incorporate if I have time
for it.) It runs all of the turtle graphics example scripts (except
colormixer which uses ondrag) without problems.

> > Unless such proof can be provided (and then integrated into the code),
> > I recommend to give up that objective, and start merging the base class
> > code into the subclasses where reasonable.

Sorry, but I definitely shall not follow your recommendation.  I have
presented the architecture of the turtle module at Europython 2006  in a
talk which was visited also by Guido v. Rossum and later in Leipzig at a
workshop where you yourself, Martin, was present. On both of these
occasions I showed working prototypes of this port (along with another
one to VPython) and nobody had any objections nor were there any
objections by other useres who have used it up to now against this
design. You can find this also in the "Tagungsband" to the Leipzig
Python workshop together with some screenshots.

I'm very confident that this is a good design and I know (form the 
experience mentioned above) that it works. So instead I'll proceed with 
porting it to Jython and I for my part would consider it as an advantage
to have the same turtle module in both of these flavours of Python.

Two more remarks on this discussion, a specific one and a general one.

1. The bug I submitted a patch for is in the method setup() and in the 
__init__ method of _Screen, both of which usually will be called only 
once in a program.So in *this* case it cannot cause any performance 
problems. The bug  has annoying consequences and I found a simple 
remedy, which I consider appropriate for a bug-fix-release like 2.6.1. I
don't see any reason why to keep a known bug like this one in the code.
Acceptance of the patch will certainly not affect any more fundamental
amendments to follow (possibly). Moreover up to now I didn't hear of a
single complaint about the performance of the turtle module. I think
this is (i) because for beginning programmers this is no issue and (ii)
there are means (to call tracer() and also to call update() directly) to
control performance to a considerable extent. Shortly, my opinion is
that there are *good reasons* why the implementation is done like this,
seen from the educator's point of view.

2. Is it really fruitful to discuss  general design issues along with
(comparatively) small problems like this one - in the sense of
alternative ways to fix that problem? Implementations of redesigns like
the one you recommended wouldn't be accepted anyway for bug fix releases 
or releases in rc phase. I'm open to fundamental criticism also, but I 
think that should be led in Python-Dev or possibly comp.lang.python. And 
working out an amended concept would take some time and also it's 
implementation and it's testing. Moreover, to find co-workers to work on 
this would be an advantage.

Regards,
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:15:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Nov 2008 23:15:04 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227136504.32.0.564190405144.issue4358@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is difficult: the backtrace only show plain python operations.
Some hints though:

One backtrace shows a memory corruption in the obmalloc data. This may come from a 
buffer overrun.

You initially selected ctypes in "Components", does this mean that your program 
also use ctypes?
With ctypes it is easy to be caught with a python string converted to a (mutable) 
char* pointer.

For example, on Windows:
>>> import ctypes
>>> c = ctypes.CDLL('msvcrt')
>>> a = "    "
>>> c.strcpy(a, "X" * 50)
50
>>> a
'XXXX'
... and the crash is not far.

Another case of corruption in obmalloc is to try to allocate python objects while 
the GIL is not held. This may happen if you wrote a C function that uses the 
Python API, and call this with ctypes.

In any case, I suggest that you build and a use a debug-enabled version of python 
(configure with --with-pydebug). It catches some errors earlier and sometimes more 
reliably.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:29:01 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 19 Nov 2008 23:29:01 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1227137341.61.0.554408030056.issue3947@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I'm not sure that reported issue is openssl bug.
Just tested a GCC(mingw) build of test case reproduce.zip with
openssl(0.9.8i) and "pthreads-w32". The test run without problems on
nt5.1(xp).

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:33:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 23:33:58 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227137638.76.0.0845670368387.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If you look at the 2.7 code all it requires of keys and values in
__setitem__ is that they are strings; there is nothing about Latin-1 in
terms of specific encoding (must be a 3.0 addition to make the
str/unicode transition the easiest). That would suggest to me that
assuming that previous DBs were written in Latin-1 is somewhat bogus as
people could have passed in any str encoded in any format as a DB key or
value.

Thus I think going down the UTF-8 route is the right thing to do for
string arguments. A quick look at _gdbmmodule.c supports this as it just
converts its arguments through PyArg_Parse("s#") to get its keys and
thus uses UTF-8 as the default encoding.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:41:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Nov 2008 23:41:11 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1227136290.66.0.374277509383.issue4117@psf.upfronthosting.co.za>
Message-ID: <4924A414.2040509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 2. Is it really fruitful to discuss  general design issues along with
> (comparatively) small problems like this one - in the sense of
> alternative ways to fix that problem?

Most definitely. The module went into Python without any review
whatsoever. Nobody (but you) has ever looked at the code in detail.
Only now that I look at it I wonder whether the design of the code
is appropriate.

In this specific case, gpolo suggested a reasonable change to the
proposed patch. You opposed this change, pointing out that this
change contradicts the design behind it. As I think the change gpolo
requested is desirable, it *must* be the design that is wrong (as
it restricts us from doing what I think should be done).

So: if you bring up "the design" as a reason for doing things the
way they are done, expect the design to be challenged.

You might argue that with due process, review should have taken
place before the code was integrated. You might be right, but then
the new turtle module wouldn't have been part of Python 2.6.

Wrt. the specific design issue: I believe that attempts to provide
cross-platform GUI in a simple fashion are doomed to fail. Java
AWT is an extraordinary example of it, but many more libraries
exist that essentially prove that cross-platform GUI is a bad idea;
one may argue that Tk itself is also proof of that (although
it is fairly sophisticated, and not at all simple). The fact that
I have not objected to it earlier is simply because I must have
ignored any claims about cross-platform GUIs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:52:12 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2008 23:52:12 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227138732.18.0.42418151083.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, now I see why it is called 'dumb'; the thing literally just dumps
out the repr of two strings on each line for key/value pairs. To read it
just evals each line in the string. And whichdb detects this format by
looking for ' or " as the first character since that is what the repr
for str is. And that is why the Latin-1 decoding was used; it has the
proper repr for write-out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:52:18 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 19 Nov 2008 23:52:18 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

When using some distutils functions, distutils attempts to use buildtime
files like Makefile and pyconfig*.h as data sources.  For instance, this
snippet::

  from distutils.command.install import install
  from distutils.core import Distribution
  dist = Distribution({"name": "foopkg"})
  cmd = install(dist)
  cmd.ensure_finalized()

There's two reasons this should change.

1) Some Linux distributions separate the python runtime and buildtime
files and put the buildtime files in a -devel package.  Depending on
these buildtime files means that the -devel package can be needed for
running python scripts.  For instance, here's the traceback that occurs
when the previous commands are run without python-devel on Fedora Linux::

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.5/distutils/cmd.py", line 117, in
ensure_finalized
      self.finalize_options()
    File "/usr/lib/python2.5/distutils/command/install.py", line 273, in
finalize_options
      (prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix')
    File "/usr/lib/python2.5/distutils/sysconfig.py", line 493, in
get_config_vars
      func()
    File "/usr/lib/python2.5/distutils/sysconfig.py", line 352, in
_init_posix
      raise DistutilsPlatformError(my_msg)
  distutils.errors.DistutilsPlatformError: invalid Python installation:
unable to open /usr/lib/python2.5/config/Makefile (No such file or
directory)

2) keeping the information in a Makefile and *.h files and then having
regular expressions pull the information out is fragile and not what the
tools were meant for.  Using a defined data format is much better.

The variables necessary for building extensions should be placed in a
data file of some sort.  This can be built by the configure script at
the same time as it's substituting variables into the Makefile and
pyconfig files.

xml is good for interoperability and we have good modules in the std
library for that now.  .ini is less verbose and we have modules to deal
with that as well.

----------
components: Distutils
messages: 76083
nosy: a.badger
severity: normal
status: open
title: at runtime, distutils uses buildtime files
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Thu Nov 20 01:05:10 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Nov 2008 00:05:10 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227139510.59.0.891601230701.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Miki, the issue is that bisect calls tend to be made repeatedly, so the
key function can be called over and over again for the same argument. 
It is almost always a better design to simply decorate the list so the
key function never gets called more than once per element in the list. 
If we added key= to bisect, it would encourage bad design and steer
people after from better solutions.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 01:33:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Nov 2008 00:33:03 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227141183.72.0.605318804029.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have attached a file that does everything internally as UTF-8 but
reads and writes to disk as Latin-1. I added some unit tests to verify
that taking a character encoded in UTF-8 or as a string still works
properly regardless of whether one uses the string or bytes version of
the key.

Added file: http://bugs.python.org/file12067/dumb_to_utf8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov 20 02:18:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 01:18:02 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1227143882.13.0.276770655855.issue3947@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With cygwin, calling sem_wait() in the DLL_THREAD_DETACH section of a DllMain function 
can crash the program. 
See attached zip file, it contains two C files which only include pthread.h and 
semaphore.h (no python, no openssl). The resulting program crashes ~30% of the time.

If this pattern (in dll.c) is not allowed, it's a problem in the openssl code.
If it is allowed, it's a bug in cygwin's threads implementation.

We should really move this discussion to cygwin. This is no more a python issue.

Added file: http://bugs.python.org/file12068/cygwin_crash.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:13:51 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 20 Nov 2008 02:13:51 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227147231.76.0.721755381302.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

> Most definitely. The module went into Python without any review
> whatsoever. Nobody (but you) has ever looked at the code in detail.

That's not True! Brad Miller, for example, who also had submitted
patches to the pythontracker, coauthor of "Python Programming in
Context",  has used a predecessor of turtle.py as a main tool (swiss
army knife, as he says) in his book. He has contributed a few patches
(via private communication, before the module went into the Python
trunk), one of them directly concerning the update method. He had also
suggested some of the features, which I have added towards the end of
the development.

> You might argue that with due process, review should have taken
> place before the code was integrated. You might be right, but then
> the new turtle module wouldn't have been part of Python 2.6.

Rigth, more or less. At least I had expected, that someone reads the
doc-strings of the approx. 15 classes in the module. The one of
TurtleScreenBase reads like this:

"""Provide the basic graphics functionality.
Interface between Tkinter and turtle.py.

To port turtle.py to some different graphics toolkit
a corresponding TurtleScreenBase class has to be implemented.
"""

Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:52:03 2008
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 20 Nov 2008 02:52:03 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1227149523.0.0.776846266381.issue4309@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

When patching py3k/Doc/library/ctypes.rst or ctypes module tree please 
consider

  u"World!" produces a syntax error.

  These wide character formats produce unintelligible output:

    for n in range(3,6):
        code = 'utf_%s'%2**n
        print(code)
        printf(b"Hello, %S\n", 'world'.encode(code))

  http://mail.python.org/pipermail/python-3000/2008-November/015315.html

  And that early in the doc this is probably meant to be a simple, 
somewhat complete example.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Thu Nov 20 05:05:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Nov 2008 04:05:36 +0000
Subject: [issue4353] Move description what a trace should should return to
	settrace from pdb section into sys.settrace section
In-Reply-To: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za>
Message-ID: <1227153936.49.0.230544727109.issue4353@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the suggestion! Done in r67205.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4353>
_______________________________________

From report at bugs.python.org  Thu Nov 20 07:04:25 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 20 Nov 2008 06:04:25 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1227161065.42.0.129112186351.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, I'll close this entry, and I'll post message to cygwin ml about this
issue.
# I already posted it to openssl-dev, but there was no response.
http://www.nabble.com/Bug%3A-crash-on-cygwin-if-uses-CRYPTO_set_locking_callback-and-shared-library-to19699111.html#a19712690

----------
keywords:  -needs review
priority: critical -> 
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Thu Nov 20 08:00:11 2008
From: report at bugs.python.org (Farshad Khoshkhui)
Date: Thu, 20 Nov 2008 07:00:11 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227164411.94.0.509571836089.issue4358@psf.upfronthosting.co.za>


Farshad Khoshkhui <farshadkh at gmail.com> added the comment:

No, there isn't any custom made C extension, nor I'm using ctypes. (It
was a mistake selecting ctypes).
The application is a web service with postgresql backend, so it heavily
uses pyexpat and pygresql in a threaded environment. 
I'll recompile python with pydebug and get back with results.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:11:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Nov 2008 10:11:10 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227175870.76.0.0920267332822.issue4356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What about cases where performance is unimportant, or where the key 
function is fast (e.g. an attribute access)?  Then something like

bisect(a, x, key=attrgetter('size'))

is easy to write and read.  Mightn't this be considered good design,
from some perspectives?

Another thought:  if your list is a list of user-defined objects then a 
natural way to do the 'decorate' step of DSU might be to add a 'key' 
attribute to each object, rather than the usual method of constructing 
pairs.  (This has the advantage that you might not have to bother with the 
'undecorate' step.)  With a key argument, bisect could make use of this 
technique too.

Disclaimer: I haven't personally had any need for a key argument on 
bisect, so all this is hypothetical.  That's why I'm asking for real use-
cases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:29:20 2008
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Nov 2008 10:29:20 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>


New submission from kai zhu <davidbranniganz at gmail.com>:

################################
# super_closure.py
class A(object):
  def foo(self):
    return super()
    # remove the closure below
    # & SystemError goes away ???
    lambda: self
A().foo()
################################

when run on 3.0rc1 & 3.0rc2:

hpc-login2 3 ~/work/py3to2: python3.0 super_closure.py
Traceback (most recent call last):
  File "super_closure.py", line 9, in <module>
    A().foo()
  File "super_closure.py", line 5, in foo
    return super()
SystemError: super(): __class__ is not a type (A)

SystemError seems to b raised from typeobject.c (line6155):

static int
super_init(PyObject *self, PyObject *args, PyObject *kwds)
{...
        if (!PyType_Check(type)) {
            PyErr_Format(PyExc_SystemError,
              "super(): __class__ is not a type (%s)",
              Py_TYPE(type)->tp_name);
            return -1;
        }
        break;

----------
components: Build, Interpreter Core
messages: 76093
nosy: kaizhu
severity: normal
status: open
title: SystemError when method has both super() & closure
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:59:16 2008
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Nov 2008 10:59:16 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227178756.9.0.217959979234.issue4360@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

here's a printout of bytecode from script

>>>
>>> s = open("super_closure.py").read()
>>> c = compile(s, "super_closure.py", "exec")
>>> t = py3to2.codetree(c)
>>> print( t )
codetree(
co_argcount =     0,
co_cellvars =     (),
co_code =        
b'Gd\x00\x00\x84\x00\x00d\x01\x00e\x00\x00\x83\x03\x00Z\x01\x00e\x01\x00\x83\x00\x00j\x02\x00\x83\x00\x00\x01d\x02\x00S',
co_filename =     'super_closure.py',
co_firstlineno =  3,
co_flags =        64,
co_freevars =     (),
co_kwonlyargcount =0,
co_lnotab =       b'\x13\x06',
co_name =         '<module>',
co_names =        ('object', 'A', 'foo'),
co_nlocals =      0,
co_stacksize =    4,
co_varnames =     (),
depth =           0,
co_consts = (
 codetree(
 co_argcount =     1,
 co_cellvars =     ('__class__',),
 co_code =        
b'|\x00\x00Ee\x00\x00Z\x01\x00\x87\x00\x00f\x01\x00d\x00\x00\x86\x00\x00Z\x02\x00\x87\x00\x00S',
 co_filename =     'super_closure.py',
 co_firstlineno =  3,
 co_flags =        2,
 co_freevars =     (),
 co_kwonlyargcount =0,
 co_lnotab =       b'\n\x01',
 co_name =         'A',
 co_names =        ('__name__', '__module__', 'foo'),
 co_nlocals =      1,
 co_stacksize =    2,
 co_varnames =     ('__locals__',),
 depth =           1,
 co_consts = (
  codetree(
  co_argcount =     1,
  co_cellvars =     ('self',),
  co_code =        
b't\x00\x00\x83\x00\x00S\x87\x00\x00f\x01\x00d\x01\x00\x86\x00\x00\x01',
  co_filename =     'super_closure.py',
  co_firstlineno =  4,
  co_flags =        3,
  co_freevars =     ('__class__',),
  co_kwonlyargcount =0,
  co_lnotab =       b'\x00\x01\x07\x03',
  co_name =         'foo',
  co_names =        ('super',),
  co_nlocals =      1,
  co_stacksize =    2,
  co_varnames =     ('self',),
  depth =           2,
  co_consts = (
   None,
   codetree(
   co_argcount =     0,
   co_cellvars =     (),
   co_code =         b'\x88\x00\x00S',
   co_filename =     'super_closure.py',
   co_firstlineno =  8,
   co_flags =        19,
   co_freevars =     ('self',),
   co_kwonlyargcount =0,
   co_lnotab =       b'',
   co_name =         '<lambda>',
   co_names =        (),
   co_nlocals =      0,
   co_stacksize =    1,
   co_varnames =     (),
   depth =           3,
   co_consts = (
    )),
   )),
  )),
 A,
 None,
 ))
>>>

and disassembly:

>>>
>>> print( t.dis() )
  3           0 LOAD_BUILD_CLASS
              1 LOAD_CONST               0 (<code object A at
0x2a987af9b0, file "super_closure.py", line 3>)
              4 MAKE_FUNCTION            0
              7 LOAD_CONST               1 ('A')
             10 LOAD_NAME                0 (object)
             13 CALL_FUNCTION            3
             16 STORE_NAME               1 (A)

  9          19 LOAD_NAME                1 (A)
             22 CALL_FUNCTION            0
             25 LOAD_ATTR                2 (foo)
             28 CALL_FUNCTION            0
             31 POP_TOP
             32 LOAD_CONST               2 (None)
             35 RETURN_VALUE

      3           0 LOAD_FAST                0 (__locals__)
                  3 STORE_LOCALS
                  4 LOAD_NAME                0 (__name__)
                  7 STORE_NAME               1 (__module__)

      4          10 LOAD_CLOSURE             0 (__class__)
                 13 BUILD_TUPLE              1
                 16 LOAD_CONST               0 (<code object foo at
0x2a987afd30, file "super_closure.py", line 4>)
                 19 MAKE_CLOSURE             0
                 22 STORE_NAME               2 (foo)
                 25 LOAD_CLOSURE             0 (__class__)
                 28 RETURN_VALUE

          5           0 LOAD_GLOBAL              0 (super)
                      3 CALL_FUNCTION            0
                      6 RETURN_VALUE

          8           7 LOAD_CLOSURE             0 (self)
                     10 BUILD_TUPLE              1
                     13 LOAD_CONST               1 (<code object
<lambda> at 0x2a984c0530, file "super_closure.py", line 8>)
                     16 MAKE_CLOSURE             0
                     19 POP_TOP

              8           0 LOAD_DEREF               0 (self)
                          3 RETURN_VALUE

>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:10:30 2008
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Nov 2008 11:10:30 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227179430.7.0.097209096472.issue4360@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

same thing, except w/ closure commented out (& everything is happy)

################################
# super_ok.py
class A(object):
  def foo(self):
    return super()
    # comment the closure below
    # & SystemError goes away
    # lambda: self
A().foo()
################################

>>>
>>> s = open("super_ok.py").read()
>>> c = compile(s, "super_ok.py", "exec")
>>> t = py3to2.codetree(t)
>>> print( t )
codetree(
co_argcount =     0,
co_cellvars =     (),
co_code =        
b'Gd\x00\x00\x84\x00\x00d\x01\x00e\x00\x00\x83\x03\x00Z\x01\x00e\x01\x00\x83\x00\x00j\x02\x00\x83\x00\x00\x01d\x02\x00S',
co_filename =     'super_closure.py',
co_firstlineno =  3,
co_flags =        64,
co_freevars =     (),
co_kwonlyargcount =0,
co_lnotab =       b'\x13\x06',
co_name =         '<module>',
co_names =        ('object', 'A', 'foo'),
co_nlocals =      0,
co_stacksize =    4,
co_varnames =     (),
depth =           0,
co_consts = (
 codetree(
 co_argcount =     1,
 co_cellvars =     ('__class__',),
 co_code =        
b'|\x00\x00Ee\x00\x00Z\x01\x00\x87\x00\x00f\x01\x00d\x00\x00\x86\x00\x00Z\x02\x00\x87\x00\x00S',
 co_filename =     'super_closure.py',
 co_firstlineno =  3,
 co_flags =        2,
 co_freevars =     (),
 co_kwonlyargcount =0,
 co_lnotab =       b'\n\x01',
 co_name =         'A',
 co_names =        ('__name__', '__module__', 'foo'),
 co_nlocals =      1,
 co_stacksize =    2,
 co_varnames =     ('__locals__',),
 depth =           1,
 co_consts = (
  codetree(
  co_argcount =     1,
  co_cellvars =     ('self',),
  co_code =        
b't\x00\x00\x83\x00\x00S\x87\x00\x00f\x01\x00d\x01\x00\x86\x00\x00\x01',
  co_filename =     'super_closure.py',
  co_firstlineno =  4,
  co_flags =        3,
  co_freevars =     ('__class__',),
  co_kwonlyargcount =0,
  co_lnotab =       b'\x00\x01\x07\x03',
  co_name =         'foo',
  co_names =        ('super',),
  co_nlocals =      1,
  co_stacksize =    2,
  co_varnames =     ('self',),
  depth =           2,
  co_consts = (
   None,
   codetree(
   co_argcount =     0,
   co_cellvars =     (),
   co_code =         b'\x88\x00\x00S',
   co_filename =     'super_closure.py',
   co_firstlineno =  8,
   co_flags =        19,
   co_freevars =     ('self',),
   co_kwonlyargcount =0,
   co_lnotab =       b'',
   co_name =         '<lambda>',
   co_names =        (),
   co_nlocals =      0,
   co_stacksize =    1,
   co_varnames =     (),
   depth =           3,
   co_consts = (
    )),
   )),
  )),
 A,
 None,
 ))
>>>
>>> print( t.dis() )
  3           0 LOAD_BUILD_CLASS
              1 LOAD_CONST               0 (<code object A at
0x2a987af2b0, file "super_closure.py", line 3>)
              4 MAKE_FUNCTION            0
              7 LOAD_CONST               1 ('A')
             10 LOAD_NAME                0 (object)
             13 CALL_FUNCTION            3
             16 STORE_NAME               1 (A)

  9          19 LOAD_NAME                1 (A)
             22 CALL_FUNCTION            0
             25 LOAD_ATTR                2 (foo)
             28 CALL_FUNCTION            0
             31 POP_TOP
             32 LOAD_CONST               2 (None)
             35 RETURN_VALUE

      3           0 LOAD_FAST                0 (__locals__)
                  3 STORE_LOCALS
                  4 LOAD_NAME                0 (__name__)
                  7 STORE_NAME               1 (__module__)

      4          10 LOAD_CLOSURE             0 (__class__)
                 13 BUILD_TUPLE              1
                 16 LOAD_CONST               0 (<code object foo at
0x2a987af4b0, file "super_closure.py", line 4>)
                 19 MAKE_CLOSURE             0
                 22 STORE_NAME               2 (foo)
                 25 LOAD_CLOSURE             0 (__class__)
                 28 RETURN_VALUE

          5           0 LOAD_GLOBAL              0 (super)
                      3 CALL_FUNCTION            0
                      6 RETURN_VALUE

          8           7 LOAD_CLOSURE             0 (self)
                     10 BUILD_TUPLE              1
                     13 LOAD_CONST               1 (<code object
<lambda> at 0x2a987af5b0, file "super_closure.py", line 8>)
                     16 MAKE_CLOSURE             0
                     19 POP_TOP

              8           0 LOAD_DEREF               0 (self)
                          3 RETURN_VALUE

>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:18:51 2008
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Nov 2008 11:18:51 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227179931.17.0.196960556981.issue4360@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

oops, sorry reprinted the same code ^^;;; ignore previous post, & use
this: (sorry again for mucking up this page)

################################
# super_ok.py
class A(object):
  def foo(self):
    return super()
    # comment the closure below
    # & SystemError goes away
    # lambda: self
A().foo()
################################

>>> s = open("super_ok.py").read(); c = compile(s, "super_ok.py",
"exec"); t = py3to2.codetree(c)
>>> print( t )
codetree(
co_argcount =     0,
co_cellvars =     (),
co_code =        
b'Gd\x00\x00\x84\x00\x00d\x01\x00e\x00\x00\x83\x03\x00Z\x01\x00e\x01\x00\x83\x00\x00j\x02\x00\x83\x00\x00\x01d\x02\x00S',
co_filename =     'super_ok.py',
co_firstlineno =  3,
co_flags =        64,
co_freevars =     (),
co_kwonlyargcount =0,
co_lnotab =       b'\x13\x06',
co_name =         '<module>',
co_names =        ('object', 'A', 'foo'),
co_nlocals =      0,
co_stacksize =    4,
co_varnames =     (),
depth =           0,
co_consts = (
 codetree(
 co_argcount =     1,
 co_cellvars =     ('__class__',),
 co_code =        
b'|\x00\x00Ee\x00\x00Z\x01\x00\x87\x00\x00f\x01\x00d\x00\x00\x86\x00\x00Z\x02\x00\x87\x00\x00S',
 co_filename =     'super_ok.py',
 co_firstlineno =  3,
 co_flags =        2,
 co_freevars =     (),
 co_kwonlyargcount =0,
 co_lnotab =       b'\n\x01',
 co_name =         'A',
 co_names =        ('__name__', '__module__', 'foo'),
 co_nlocals =      1,
 co_stacksize =    2,
 co_varnames =     ('__locals__',),
 depth =           1,
 co_consts = (
  codetree(
  co_argcount =     1,
  co_cellvars =     (),
  co_code =         b't\x00\x00\x83\x00\x00S',
  co_filename =     'super_ok.py',
  co_firstlineno =  4,
  co_flags =        3,
  co_freevars =     ('__class__',),
  co_kwonlyargcount =0,
  co_lnotab =       b'\x00\x01',
  co_name =         'foo',
  co_names =        ('super',),
  co_nlocals =      1,
  co_stacksize =    1,
  co_varnames =     ('self',),
  depth =           2,
  co_consts = (
   None,
   )),
  )),
 A,
 None,
 ))
>>> print( t.dis() )
  3           0 LOAD_BUILD_CLASS
              1 LOAD_CONST               0 (<code object A at
0x2a987afd30, file "super_ok.py", line 3>)
              4 MAKE_FUNCTION            0
              7 LOAD_CONST               1 ('A')
             10 LOAD_NAME                0 (object)
             13 CALL_FUNCTION            3
             16 STORE_NAME               1 (A)

  9          19 LOAD_NAME                1 (A)
             22 CALL_FUNCTION            0
             25 LOAD_ATTR                2 (foo)
             28 CALL_FUNCTION            0
             31 POP_TOP
             32 LOAD_CONST               2 (None)
             35 RETURN_VALUE

      3           0 LOAD_FAST                0 (__locals__)
                  3 STORE_LOCALS
                  4 LOAD_NAME                0 (__name__)
                  7 STORE_NAME               1 (__module__)

      4          10 LOAD_CLOSURE             0 (__class__)
                 13 BUILD_TUPLE              1
                 16 LOAD_CONST               0 (<code object foo at
0x2a984c0530, file "super_ok.py", line 4>)
                 19 MAKE_CLOSURE             0
                 22 STORE_NAME               2 (foo)
                 25 LOAD_CLOSURE             0 (__class__)
                 28 RETURN_VALUE

          5           0 LOAD_GLOBAL              0 (super)
                      3 CALL_FUNCTION            0
                      6 RETURN_VALUE

>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 13:42:48 2008
From: report at bugs.python.org (thp)
Date: Thu, 20 Nov 2008 12:42:48 +0000
Subject: [issue4361] Docstring for "Lib/string.py" is outdated
In-Reply-To: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>
Message-ID: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>


New submission from thp <thp at thpinfo.com>:

The docstring in "Lib/string.py" in the source of "Python 3.0rc2" is
wrong. It currently says "lowercase", "uppercase" and "letters" where it
should say "ascii_lowercase", "ascii_uppercase" and "ascii_letters".

----------
assignee: georg.brandl
components: Documentation
files: Lib_string_py-docstring.patch
keywords: patch
messages: 76097
nosy: georg.brandl, thp
severity: normal
status: open
title: Docstring for "Lib/string.py" is outdated
versions: Python 3.0
Added file: http://bugs.python.org/file12069/Lib_string_py-docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4361>
_______________________________________

From report at bugs.python.org  Thu Nov 20 13:44:08 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Nov 2008 12:44:08 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227185048.63.0.777664249722.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I had said "almost always".  Sure, if you don't care about performance
or scalability, a key= argument would be a net win.

We're responsible for creating an API that steers most programmers in
the right direction (Tim sez "we read Knuth so you don't have to"). 
Algorithmically, the bisect functions are at the wrong level of
granularity for applying a key function.  

For user-defined objects, there is no need for a key-attribute since can
just supply a custom comparison method:

class UserDefined:
  . . .
  def cmp(self, other):
      return cmp(self.key, other.key)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 13:52:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Nov 2008 12:52:32 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227185552.17.0.36282074995.issue4356@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 13:58:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Nov 2008 12:58:08 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227185888.57.0.506134186382.issue4356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One case I've been thinking about is that of maintaining a list of Decimal 
objects that are sorted by absolute value.  For this, having to create a 
list of (abs(x), x) pairs just seems clumsy compared to using a key 
argument to bisect.

Perhaps this is a contrived use case, but it doesn't seem totally 
implausible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:18:28 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 20 Nov 2008 13:18:28 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The FileIO object defined in the new io library has "name" and "mode" 
properties.  However, attempts to access either value result in an 
AttributeError exception.   The C source code in _fileio.c doesn't even 
implement a name attribute and it uses a different name for mode ("mode" 
instead of "_mode" that the property is looking for).

Broken in 2.6 and 3.0rc2.

----------
components: Library (Lib)
messages: 76100
nosy: beazley
severity: normal
status: open
title: FileIO object in io module
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:25:33 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 20 Nov 2008 13:25:33 +0000
Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1227187533.04.0.988393291525.issue4017@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

Just a quick comment from the Python training universe--this bug makes it 
impossible to use Python 2.6 in any kind of Python teaching environment 
where IDLE tends to be used a lot.  I'm having to tell students to stick 
with Python-2.5.2.

----------
nosy: +beazley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4017>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:32:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 13:32:35 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227187955.21.0.432096100678.issue4362@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

This needs to be verified before the next rc gets out.

----------
nosy: +christian.heimes
priority:  -> release blocker
stage:  -> test needed
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:16:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 14:16:22 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227190582.66.0.316734424749.issue4360@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In a running frame, f->f_localplus is a vector composed of:
- the values of the local variables
- the cells containing variables used in a nested closure.
- the values of free variables defined in a outer scope.

super() needs to access the free var containing the enclosing class
object, but forgets to account for the number of cells...

The attached patch corrects the problem.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12070/super-withcell.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:19:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 14:19:35 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227190775.33.0.210190913201.issue4360@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Yet another release blocker for Barry. Good work, Amaury.

----------
assignee:  -> barry
components:  -Build
nosy: +barry, christian.heimes
priority:  -> release blocker
resolution:  -> accepted
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:24:02 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 14:24:02 +0000
Subject: [issue4082] python2.6 -m site doesn't run site._script() any more
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1227191042.24.0.927018903704.issue4082@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's still an issue and I like to get it resolved. The site module lets
users access information related to my uesr site package directory. In
2.6 the information isn't accessible: 

$ python3.0 -m site --user-site
/home/heimes/.local/lib/python3.0/site-packages
$ python2.6 -m site --user-site
$

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:25:33 2008
From: report at bugs.python.org (Weeble)
Date: Thu, 20 Nov 2008 14:25:33 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1227191133.51.0.772005401766.issue1529142@psf.upfronthosting.co.za>


Changes by Weeble <clockworksaint at gmail.com>:


----------
nosy: +weeble

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:25:57 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 14:25:57 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227191157.18.0.445587852534.issue4354@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The patch is fine with me.

----------
assignee:  -> barry
nosy: +barry, christian.heimes
priority:  -> release blocker
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:44:28 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Thu, 20 Nov 2008 14:44:28 +0000
Subject: [issue4363] Make uuid module functions usable without ctypes
In-Reply-To: <1227192268.71.0.69220527161.issue4363@psf.upfronthosting.co.za>
Message-ID: <1227192268.71.0.69220527161.issue4363@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

The attached patch removes dependency on ctypes from uuid.uuid1() and
uuid.uuid4() functions.

----------
components: Library (Lib)
files: uuid.patch
keywords: patch
messages: 76107
nosy: hdima
severity: normal
status: open
title: Make uuid module functions usable without ctypes
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12071/uuid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4363>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:19:26 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Thu, 20 Nov 2008 15:19:26 +0000
Subject: [issue4364] error in multiprocessing docs - rawvalue
In-Reply-To: <1227194366.84.0.640745575496.issue4364@psf.upfronthosting.co.za>
Message-ID: <1227194366.84.0.640745575496.issue4364@psf.upfronthosting.co.za>


New submission from Brian D'Urso <dursobr at pitt.edu>:

There is an error in the multiprocessing package documentation:
In the sentence:

'Note that an array of ctypes.c_char has value and rawvalue attributes
which allow one to use it to store and retrieve strings.'

The error is that 'rawvalue' should be 'raw'.
This sentence actually occurs in two places: under multiprocessing.Array
and just before multiprocessing.sharedctypes.Array. It looks to me like
the second occurrence of the sentence is in the wrong place - I think it
should be in the multiprocessing.sharedctypes.Array section instead of
just before it.


To see that the attribute name is 'raw', just do:

>>> import ctypes, multiprocessing
>>> dir(multiprocessing.Array(ctypes.c_char, 1))

==> ['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
'__getattribute__', '__getitem__', '__getslice__', '__hash__',
'__init__', '__len__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__setitem__',
'__setslice__', '__sizeof__', '__str__', '__subclasshook__',
'__weakref__', '_lock', '_obj', 'acquire', 'get_lock', 'get_obj', 'raw',
'release', 'value']

----------
assignee: georg.brandl
components: Documentation
messages: 76108
nosy: dursobr, georg.brandl
severity: normal
status: open
title: error in multiprocessing docs - rawvalue
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4364>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:31:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 15:31:07 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227195067.75.0.992780074304.issue4362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The attached patch is an attempt to set mode and name attributes to all
three objects in the IO stack.
For example, 
>>> f = open("foo", "U+")
>>> f.buffer.name, f.buffer.mode
('foo', 'r+')

See also the unit tests.


There is a little inconsistency that I don't know how to resolve: with
my patch, the mode does not round-trip: open(name, mode).mode is not
always equal to mode:
>>> f = open("foo", "rb")
>>> f.name, f.mode
('t', 'r')
The 'b' was removed because f is already a binary file returning bytes.

But it seems better than attaching the initial mode to the FileIO
object. Currently,
>>> io.open("foo", "Ub+", buffering=0)
_fileio._FileIO(3, 'r+')
>>> io.open("foo", "Ub+", buffering=0).mode
'Ub+'
Which is even more surprising IMO.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12072/fileio_attributes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:48:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 20 Nov 2008 15:48:14 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1227196094.39.0.967039271269.issue4236@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a test case (a.py) which produces a FatalError back to Python
2.4 at least)

Added file: http://bugs.python.org/file12073/a.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:53:35 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 20 Nov 2008 15:53:35 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227196415.5.0.763104188401.issue2306@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This will have to deferred to the final 3.0 release, I don't have time
today (dr's appt, internal release, blah, blah).

Sorry!

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:55:44 2008
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 20 Nov 2008 15:55:44 +0000
Subject: [issue4365] Add CRT version info in msvcrt module
In-Reply-To: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>
Message-ID: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

This patch if the first part to follow discussion on python-list
concerning problems when using distutils.config.try_run with mingw and
manifest problems on windows for python 2.6 (or any python built with
recent VS).

It simply adds strings constant got the msvcrt module, so that they can
be queried in distutils to generate manifest on the fly if needed. I
don't know which approach is best to deal with conditional compilation:
for now, I simply do not add the constants if the constants are not
defined at the C level, but this does not strike as a great idea to me.

----------
components: Windows
files: msvcrt_version_info.diff
keywords: patch
messages: 76112
nosy: cdavid
severity: normal
status: open
title: Add CRT version info in msvcrt module
versions: Python 2.7
Added file: http://bugs.python.org/file12074/msvcrt_version_info.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4365>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:02:56 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 16:02:56 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1227196976.74.0.0707640794476.issue4236@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

After consultation with MvL and Crys_ on irc, we've agreed that this
should be fixed someday but it's a pathological case that shouldn't hold
up the release.  I'm lowering to critical because I don't think it
should even hold up the final release.

----------
assignee:  -> brett.cannon
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:15:19 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 16:15:19 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1227197719.76.0.357206963859.issue4306@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This example works though, and it also works in earlier Pythons.


from email.header import Header

def main():
    # coding: utf8
    ADDRESS = 'victor.stinner at haypocalc.com'
    from email.mime.text import MIMEText
    msg = MIMEText('accent \xe9\xf4\u0142', 'plain', 'utf-8')
    msg['Subject'] = Header('sujet \xe9\xf4\u0142'.encode('utf-8'),
                            'utf-8')
    msg['From'] = ADDRESS
    msg['To'] = ADDRESS
    text = msg.as_string()
    print("--- FLATTEN ---")
    print(text)
    return

main()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:21:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 16:21:58 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1227198118.01.0.360873867638.issue4306@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm rejecting the patch because the old way of making this work still
works in Python 3.0.  Any larger changes to the API need to be made in
the context of redesigning the email package to be byte/str aware.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:26:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 20 Nov 2008 16:26:21 +0000
Subject: [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227198381.9.0.541775313725.issue4354@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r67298.

For some reason, the saved credentials won't be read back in. Not sure
whether this is specific to 3.0, though, or part of the new PyPIRC handling.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:28:43 2008
From: report at bugs.python.org (webograph)
Date: Thu, 20 Nov 2008 16:28:43 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1227198523.78.0.233101101774.issue1083@psf.upfronthosting.co.za>


Changes by webograph <webograph at eml.cc>:


----------
nosy: +webograph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:26:59 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:26:59 +0000
Subject: [issue4366] cannot find -lpython2.5 when buinding Python 2.5.2 on
	FreeBSD 4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

I get a number of "cannot find -lpython2.5" error when building Python
2.5.2 on FreeBSD 2.5.2 with gcc 2.95.4.
This problem is only occured when I build it with "--enable-shared"
configure option.

This is how you can reproduce this problem.

cd Python-2.5.2
configure --enable-shared
make

and you will get

gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_struct.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/_
struct.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
/home/build/dev/Python-2.5.2/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -lpython2.5 -o
build/lib.freebsd-4.11-RELEASE-i386-2.5/_ctypes.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEA
SE-i386-2.5/_ctypes_test.so
/usr/libexec/elf/ld: cannot find -lpython2.5 
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_weakref.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/
_weakref.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/arraymodule.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2
.5/array.so
/usr/libexec/elf/ld: cannot find -lpython2.5
......


You can workaround this by running  ./configure LDFLAGS="-L."
--enable-shared.

----------
components: Build
messages: 76117
nosy: akitada
severity: normal
status: open
title: cannot find -lpython2.5 when buinding Python 2.5.2 on FreeBSD 4.11
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:33:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 17:33:45 +0000
Subject: [issue4366] cannot find -lpython2.5 when buinding Python 2.5.2 on
	FreeBSD 4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227202425.08.0.355044633492.issue4366@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Please try this patch with a clean source tree. It adds the current
directory to the library search path.

Index: setup.py
===================================================================
--- setup.py    (revision 67295)
+++ setup.py    (working copy)
@@ -245,6 +245,7 @@
     def detect_modules(self):
         # Ensure that /usr/local is always used
         add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
+        add_dir_to_list(self.compiler.library_dirs, '.')
         add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

         # Add paths specified in the environment variables LDFLAGS and

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:36:07 2008
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Thu, 20 Nov 2008 17:36:07 +0000
Subject: [issue4367] Patch for segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>


New submission from Giuseppe Ottaviano <giuott at gmail.com>:

Hi all,
trying to compile Python 2.6 I got a segmentation fault while
byte-compiling the modules. 

The segmentation fault happened in ast_for_atom, parsing an Unicode
entity. I found out that another problem prevented unicodedata to be
imported, so unicode_decode raised an exception. I think the problem is
in the following lines:

            if (PyErr_ExceptionMatches(PyExc_UnicodeError)){
                PyObject *type, *value, *tback, *errstr;
                PyErr_Fetch(&type, &value, &tback);
                errstr = ((PyUnicodeErrorObject *)value)->reason;

I'm not an expert of CPython internals, but the exception is raised with
PyErr_SetString, so value is a PyStringObject, and that cast is invalid.
Changing the last line to 

                errstr = value;

everything works. 

The patch is attached.

----------
files: ast.patch
keywords: patch
messages: 76119
nosy: ot
severity: normal
status: open
title: Patch for segmentation fault in ast_for_atom
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12075/ast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:43:31 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:43:31 +0000
Subject: [issue4368] a bug in ncurses.h still exist in
Message-ID: <1227203011.0.0.217266498635.issue4368@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: akitada
severity: normal
status: open
title: a bug in ncurses.h still exist in

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:45:01 2008
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Thu, 20 Nov 2008 17:45:01 +0000
Subject: [issue4369] Error building to a nonstandard prefix (with patch)
In-Reply-To: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>
Message-ID: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>


New submission from Giuseppe Ottaviano <giuott at gmail.com>:

Hi all,
I am trying to compile python 2.6 using a user directory as prefix. In
the the byte-compiling step of install, compileall.py fails to load all
the .so modules (it fails for zlib.so and raises an exception for
unicodedata.so), so the build fails. I think it is because python is
invoked by the makefile with the env variables

	PYTHONPATH=$(DESTDIR)$(LIBDEST)

while the .so are in $(LIBDEST)/lib-dynload .

Setting PYTHONHOME instead of PYTHONPATH works for me (but i do not know
if it breaks anything else):

	PYTHONHOME=$(exec_prefix)

The patch is attached.

----------
components: Build
files: make.patch
keywords: patch
messages: 76120
nosy: ot
severity: normal
status: open
title: Error building to a nonstandard prefix (with patch)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12076/make.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4369>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:48:26 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:48:26 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Excerpt from configure.in

"""
# On FreeBSD 4.8 and MacOS X 10.2, a bug in ncurses.h means that
# it craps out if _XOPEN_EXTENDED_SOURCE is defined. Apparently,
# this is fixed in 10.3, which identifies itself as Darwin/7.*
# This should hopefully be fixed in FreeBSD 4.9
FreeBSD/4.8* | Darwin/6* )
"""

Unfotunately, this bug isn't fixed in FreeBSD 4.9 and even 4.1[01].
Attached patch fixes this.

Note that this fix is already included in trunk, 2.6 and 3k branches.
See also: Issue4204

----------
components: +Build
keywords: +patch
title: a bug in ncurses.h still exist in -> A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
type:  -> compile error
versions: +Python 2.5
Added file: http://bugs.python.org/file12077/configure.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:54:35 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:54:35 +0000
Subject: [issue4366] cannot find -lpython2.5 when buinding Python 2.5.2 on
	FreeBSD 4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227203675.87.0.288386974001.issue4366@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Christian's patch fixed this problem!
(tested on 4.11-RELEASE)

I'm not sure why the other platforms don't suffer this problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:20:40 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 18:20:40 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Some compilers don't understand "%zd" format specifer
and gcc 2.95.4 is one of them.
(You can find more on http://www.and.org/vstr/printf_comparison)

When building Python with such compilers, you will see a lot of
"warning: unknown conversion type character `z' in format" messages.
This is not a big issue but I think this can be fixed by using autoconf
right way because configure script seems checking availability of "zd".

  "checking for %zd printf() format support"

So I suppose there is a way to eliminate this warning completely.

----------
components: Build
messages: 76123
nosy: akitada
severity: normal
status: open
title: warning: unknown conversion type character `z' in format
type: compile error
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:26:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Nov 2008 18:26:02 +0000
Subject: [issue4367] Patch for segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227205562.2.0.246344866928.issue4367@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can you provide the code that caused the seg fault?

----------
nosy: +benjamin.peterson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:39:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 18:39:34 +0000
Subject: [issue4367] Patch for segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227206374.72.0.0450128006451.issue4367@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think I got the point: to decode strings like "\N{CHARACTER NAME}"
PyUnicode_DecodeUnicodeEscape imports the unicodedata module.
If this fails, PyErr_SetString(PyExc_UnicodeError, "some message")
is called.

The exception will eventually be caught by ast_for_atom (in
Python/ast.c), but the exception there is not normalized: type is
PyExc_UnicodeError when the value is a string. Hence the invalid cast.
The exception cannot be normalized there: UnicodeError.__init__ needs 5
arguments.

I think the error was to call PyErr_SetString in the first place.
The attached patch replaces it with PyErr_SetObject and a full
UnicodeDecodeError object.

This deserves a unit test, but I wonder how to reliably make the import
fail.

----------
keywords: +needs review
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12078/bad_unicodeerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:43:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Nov 2008 18:43:48 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227206628.3.0.569507522081.issue4370@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If you start at line 3652 in configure.in you fill find the check for
the %zd format specifier. Any patch to make it more robust would be
appreciated.

----------
nosy: +brett.cannon
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:44:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 20 Nov 2008 18:44:14 +0000
Subject: [issue4366] cannot find -lpython2.5 when buinding Python 2.5.2 on
	FreeBSD 4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227206654.08.0.780740076293.issue4366@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Since r53691, and issue 1600860, "." is added to library_dirs on Linux
and GNU systems. This probably should be extended to FreeBSD, and other
systems.

The critical point to notice is that the -L option is not only while
building Python itself, but also for extension modules (assuming Python
is installed into a non-standard location).

Now, the question is how to extend this approach to FreeBSD. For 2.5 and
2.6, I think it is safest to explicitly add freebsd to the list of
systems tested for.

For the trunk, and probably 3.0, I would try to add the library whenever
Py_ENABLE_SHARED is defined, and os.name is posix.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:44:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Nov 2008 18:44:17 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227206657.44.0.074520315357.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:45:35 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 20 Nov 2008 18:45:35 +0000
Subject: [issue1447222] tkinter Dialog fails when more than four buttons are
	used
Message-ID: <1227206735.7.0.170495308461.issue1447222@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

issue4333 fixes this too, btw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1447222>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:57:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Nov 2008 18:57:52 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227207472.24.0.937957586711.issue4360@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch looks good to me.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:58:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Nov 2008 18:58:06 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227207486.01.0.0844165799653.issue4360@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords:  -needs review
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 20:08:33 2008
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Thu, 20 Nov 2008 19:08:33 +0000
Subject: [issue4367] Patch for segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227208113.54.0.0224885751405.issue4367@psf.upfronthosting.co.za>


Giuseppe Ottaviano <giuott at gmail.com> added the comment:

@amaury: Yes, this is exactly what I noticed. I didn't know how to create 
an instance of a PyUnicodeErrorObject. BTW, isn't PyErr_SetString used 
throughout the code? Should all those calls replaced with PyErr_SetObject?

@benjamin: The bug can be easily reproduced:
brian:tmp ot$ echo 'raise Exception()' > unicodedata.py
brian:tmp ot$ python2.6 -c "print u'\N{SOFT HYPHEN}'"
Segmentation fault

I don't know if this can be used as an unit test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Thu Nov 20 20:57:56 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 20 Nov 2008 19:57:56 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227211076.08.0.246029847053.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

The attached file setup_bug_demo.py shows the bug of this issue. It's
taken out of a working game application and radically abridged to
concentrate on this issue.

Now the patch to fix the bug has to be changed a bit (because of the
changes of Martin's Singleton fix). A diff file follows immediately
(setup_patch.diff).

I tried out (in a simple straight forward way and in contradiction with
my ideas mentioned in a previous posting) 

(1) to replace the update() call by _Screen._canvas.update_idletasks() and
(2) to do a similar replacement in TurtleScreenBase._update()

Neither of these work. The second change even affects seriously the
working of the modules demo().

I'd like to mention that in the former turtle module upto 2.5 (remember:
the compatibility to it was a requirement for the new one) there are
also several Canvas.update() calls but no Canvas.update_idletasks() call.

I never noticed negative consequences of this and as far as I know,
neither concerning the old module nor the new one there were ever
complaints concerning bad ("sluggish") performance due to this (or any
other) fact.

Added file: http://bugs.python.org/file12079/setup_bug_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 20:59:04 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 20 Nov 2008 19:59:04 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227211144.88.0.904462051229.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Here the patch, updated

Added file: http://bugs.python.org/file12080/setup_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 21:02:18 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 20:02:18 +0000
Subject: [issue4360] SystemError when method has both super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227211338.54.0.200603259097.issue4360@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

patch applied; r67299

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________

From report at bugs.python.org  Thu Nov 20 21:07:29 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 20:07:29 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227211649.28.0.99333425848.issue4362@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm okay with the roundtrip not being supported.  One thing I don't
quite understand is in the third test, where you're using "w+" mode and
testing f.buffer.mode and f.buffer.raw.mode is "r+".  Why is that?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 21:14:09 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 20 Nov 2008 20:14:09 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1227212049.08.0.158670286154.issue4117@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Sorry, but there is a remain from testing different versions of the
turtle module in the demo file's import statement.

Should read (of course):

from turtle import Screen, Turtle, mainloop

A corrected version is attached

Sorry, again, for the inconvenience
Gregor

Added file: http://bugs.python.org/file12081/setup_bug_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Nov 20 21:16:31 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 20:16:31 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227212191.29.0.772640806635.issue4362@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r67300 (with after the fact whitespace normalization of
Lib/tests/test_io.py)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 21:43:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2008 20:43:23 +0000
Subject: [issue4082] python2.6 -m site doesn't run site._script() any more
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1227213803.93.0.803152779397.issue4082@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

So what could be different between my x86 system and your x86_64 system
that it works for me and not for you?

Could you try doing "python -i -m site" and poke around in the main
namespace (which is where the interactive session will start) a bit to
see if anything looks strange? __file__, __package__ and __name__ are
probably of particular interest.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:01:11 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Nov 2008 21:01:11 +0000
Subject: [issue4082] python2.6 -m site doesn't run site._script() any more
In-Reply-To: <1227213803.93.0.803152779397.issue4082@psf.upfronthosting.co.za>
Message-ID: <4925D015.4090102@cheimes.de>


Christian Heimes <lists at cheimes.de> added the comment:

Nick Coghlan wrote:
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
> 
> So what could be different between my x86 system and your x86_64 system
> that it works for me and not for you?
> 
> Could you try doing "python -i -m site" and poke around in the main
> namespace (which is where the interactive session will start) a bit to
> see if anything looks strange? __file__, __package__ and __name__ are
> probably of particular interest.

That didn't help much

$ ./python -i -m site
 >>> __name__
'__main__'
 >>> __package__
''
 >>> __file__
 >>> __file__ is None
True

However a pdb session has revealed some interesting things including the 
reason for the "bug".

$ ./python -m site
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(103)_run_module_as_main()
-> try:
(Pdb) w
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(103)_run_module_as_main()
-> try:
(Pdb) p mod_name, set_argv0
('site', 1)
(Pdb) n
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(104)_run_module_as_main()
-> loader, code, fname = _get_module_details(mod_name)
(Pdb) n
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(117)_run_module_as_main()
-> pkg_name = mod_name.rpartition('.')[0]
(Pdb) p loader, code, fname
(<zipimporter object 
"/usr/local/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg">, 
<code object <module> at 0x7fe765e95f30, file 
"build/bdist.linux-x86_64/egg/site.py", line 1>, None)
(Pdb) p code
<code object <module> at 0x7fe765e95f30, file 
"build/bdist.linux-x86_64/egg/site.py", line 1>

Solution for my issue:
$ sudo rm -rf /usr/local/lib/python2.6/site-packages/

Thanks for listening ... :/ I'm feeling embarrassed

Christian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:02:24 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 20 Nov 2008 21:02:24 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227214944.75.0.0366334789314.issue4368@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

You patch is out of date. The current case is for FreeBSD/4.* .

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:05:36 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 20 Nov 2008 21:05:36 +0000
Subject: [issue4369] Error building to a nonstandard prefix (with patch)
In-Reply-To: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>
Message-ID: <1227215136.13.0.86813095807.issue4369@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

No you can't remove $(DESTDIR)

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4369>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:07:15 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 20 Nov 2008 21:07:15 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227215235.49.0.275401509186.issue4368@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

missed target version sorry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:39:19 2008
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 20 Nov 2008 21:39:19 +0000
Subject: [issue4371] coerce gone---but not from docs
In-Reply-To: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>
Message-ID: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/glossary.html

Scanning the glossary reveals...


coercion

    The glossary needs rewritten to eliminate  "coerce builtin".

__future__
   
    Uses example import division, I'd replace it but I don't know what 
    the future holds.

integer division

    obvious.

view

    not defined in the glossary.  Please consider adding this concept.

----------
messages: 76142
nosy: LambertDW
severity: normal
status: open
title: coerce gone---but not from docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4371>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:02:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 22:02:19 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227218539.49.0.707669699472.issue4362@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:02:34 2008
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 20 Nov 2008 22:02:34 +0000
Subject: [issue4371] coerce gone---but not from docs
In-Reply-To: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>
Message-ID: <1227218554.37.0.884554497394.issue4371@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4371>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:07:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Nov 2008 22:07:52 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1227218872.16.0.665885351669.issue4306@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm rejecting the patch because the old way of making 
> this work still works in Python 3.0.

I checked the documentation and there is a section about "email: 
Internationalized headers". I didn't read this section. I just 
expected that Python uses the right encoding beacuse it was already 
specified in the MIMEText() constructor...

> Any larger changes to the API need to be made in
> the context of redesigning the email package to be byte/str aware.

Right.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:16:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2008 22:16:23 +0000
Subject: [issue4082] python2.6 -m site doesn't run site._script() any more
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1227219383.69.0.198004625405.issue4082@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That does remind me of another problem though - __main__.__file__ isn't
currently set correctly when runpy picks up the module to run from
inside a zipfile (zipimporter doesn't support runpy/pkgutil's
non-standard get_filename() extension to the PEP 302 importer API)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:48:06 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 22:48:06 +0000
Subject: [issue4306] email package with unicode subject/body
In-Reply-To: <1227218872.16.0.665885351669.issue4306@psf.upfronthosting.co.za>
Message-ID: <E26E97E2-88F9-41CC-B9AD-57E3A724D413@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 20, 2008, at 5:07 PM, STINNER Victor wrote:

> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> I'm rejecting the patch because the old way of making
>> this work still works in Python 3.0.
>
> I checked the documentation and there is a section about "email:
> Internationalized headers". I didn't read this section. I just
> expected that Python uses the right encoding beacuse it was already
> specified in the MIMEText() constructor...

Yes.  This is a stupid API (tm). :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSSXpJHEjvBPtnXfVAQKfOAP9G2BSPKIPTVTeo5k3rovqGbYSCB23SK+P
+YHInZY2NTikFUgJec4EvWvvuTkW77nb5kxVTb+MlQJMAN//AOy8xvHsFUae4F8Y
P9DsDMb3MhKokr/Y1gZyxlpHhXiK5r6aEh9+cWrujXbf9gwtYWmeiKl6MoZkOWYA
3H9gASFvuUI=
=mapP
-----END PGP SIGNATURE-----

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:48:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 22:48:22 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227221302.91.0.882153143664.issue4362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Reopening, since this causes failure in socket.makefile()

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Thu Nov 20 23:48:47 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 20 Nov 2008 22:48:47 +0000
Subject: [issue4372] __cmp__ removal not in What's New
In-Reply-To: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
Message-ID: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

What's New in Python 3.0/Common stumbling blocks
has this "builtin.sorted() and list.sort() no longer accept the cmp
argument providing a comparison function. Use the key argument instead."

Please add "The __cmp__ special method is no longer used for
comparisons. Use __lt__ for sorting, __eq__ with __hash__, and other
rich comparisons as needed."

People are already stumbling on this.

----------
assignee: georg.brandl
components: Documentation
messages: 76147
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: __cmp__ removal not in What's New
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4372>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:05:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 23:05:30 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227222330.21.0.632484635043.issue4362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This patch addresses the makefile() function and the SocketIO class.

Added file: http://bugs.python.org/file12082/socketio_attributes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:18:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 23:18:37 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227223117.09.0.699001694528.issue4338@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Martin, do you still have remarks about this patch?
Can we apply it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:37:34 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 23:37:34 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227224254.64.0.138413379669.issue4362@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:39:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 23:39:40 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1227224380.34.0.173659575047.issue4233@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Backported to trunk in r67307.

But -- do we really want to backport to 2.6? This changes the semantics 
of closefd, adds a new closefd attribute...
Did the rules change for 2.6.1?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:42:07 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Nov 2008 23:42:07 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227224527.56.0.525302830334.issue4362@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:49:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 20 Nov 2008 23:49:14 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227224954.01.0.0247379775341.issue4338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply.

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:53:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Nov 2008 23:53:47 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227225227.72.0.701653289833.issue4362@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch that makes FileIO accept and return 'b' in its mode string.

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file12083/fileio_always_binary.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Fri Nov 21 00:54:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Nov 2008 23:54:08 +0000
Subject: [issue4338] TypeError (bytes/str) in distutils command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1227225248.92.0.0322856231613.issue4338@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r67308.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:13:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 00:13:06 +0000
Subject: [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227226386.23.0.171209562815.issue4362@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Since, we don't really care about round-tripping, test_gzip was fixed in
r67309.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:18:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 00:18:17 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227226697.7.0.41384657156.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r67310 has the fix.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:53:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 00:53:59 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227228839.85.0.422201090902.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I am re-opening this as a deferred blocker with a patch to document that
dbm implementations write out and return bytes, but that strings are
accepted and implicitly converted.

----------
priority: release blocker -> deferred blocker
status: closed -> open
Added file: http://bugs.python.org/file12084/doc_dbm_strings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:28:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 01:28:17 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227230897.28.0.346921637462.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Have another patch that fixes all open() calls to specify the file
encoding in dbm.dumb. Also caught one spot in _addkey() where
decode("Latin-1") was not being called.

Added file: http://bugs.python.org/file12085/specify_open_encoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 03:28:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:28:59 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

A refleak test of r67311 py3k shows several leaks:

test_distutils leaked [142, 142, 142, 142] references, sum=568
test_httpservers leaked [0, 0, 0, 217] references, sum=217
test_multiprocessing leaked [0, 0, 24, 0] references, sum=24
test_pickle leaked [1, 1, 1, 1] references, sum=4
test_pickletools leaked [1, 1, 1, 1] references, sum=4
test_telnetlib leaked [-84, 84, 0, 0] references, sum=0
test_threadedtempfile leaked [94, -94, 0, 0] references, sum=0

----------
messages: 76158
nosy: christian.heimes
priority: deferred blocker
severity: normal
stage: test needed
status: open
title: Reference leaks in Python 3.0rc3
type: resource usage
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 03:40:44 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:40:44 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227235244.97.0.54552942694.issue4373@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Only distutils and pickle seem to have real leaks.

$ ./python Lib/test/regrtest.py -R:15: test_multiprocessing
test_multiprocessing
beginning 20 repetitions
12345678901234567890
....................
1 test OK.
[124096 refs]

$ ./python Lib/test/regrtest.py -R:15: test_distutils
test_distutils
beginning 20 repetitions
12345678901234567890
....................
test_distutils leaked [144, 144, 144, 144, 144, 144, 144, 144, 144, 144,
144, 144, 144, 144, 144] references, sum=2160
1 test OK.
[123507 refs]

$ ./python Lib/test/regrtest.py -R:15: test_httpservers
[...]
test_httpservers leaked [-217, 0, 198, 19, -35, 20, -202, 217, -217,
217, 0, 0, 0, 0, -33] references, sum=-33
1 test OK.
[96060 refs]

$ ./python Lib/test/regrtest.py -R:15: test_pickle
test_pickle
beginning 20 repetitions
12345678901234567890
....................
test_pickle leaked [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
references, sum=15
1 test OK.
[96783 refs]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 03:45:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:45:51 +0000
Subject: [issue4374] Pickle tests fail w/o _pickle extension
In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
Message-ID: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

$ rm build/lib.linux-x86_64-3.0-pydebug/_pickle.so
$ ./python Lib/test/regrtest.py -R:: test_pickle
test_pickle
test test_pickle failed -- Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/pickletester.py", line
1032, in test_bad_init
    self.assertRaises(pickle.PicklingError, BadPickler().dump, 0)
  File "/home/heimes/dev/python/py3k/Lib/unittest.py", line 311, in
failUnlessRaises
    callableObj(*args, **kwargs)
  File "/home/heimes/dev/python/py3k/Lib/pickle.py", line 225, in dump
    if self.proto >= 2:
AttributeError: 'BadPickler' object has no attribute 'proto'

1 test failed:
    test_pickle
[59279 refs]

----------
components: Extension Modules, Tests
messages: 76160
nosy: christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: Pickle tests fail w/o _pickle extension
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4374>
_______________________________________

From report at bugs.python.org  Fri Nov 21 03:50:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:50:08 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227235808.18.0.854453976679.issue4373@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

distutils.tests.test_build_ext leaks the references. I think it's
related to the xx module and totally harmless.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 03:59:19 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:59:19 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227236359.04.0.939515319031.issue4373@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

This simple patch doesn't load the 'xx' module more than once in ref
leak tests.

The problem may also be caused by the xxmodule itself. Somebody should
give it a proper review :)

----------
keywords: +patch
Added file: http://bugs.python.org/file12086/issue4373_build_ext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 04:42:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 03:42:50 +0000
Subject: [issue4367] Patch for segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227238970.47.0.897928601398.issue4367@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's an alternative patch which simply calls PyObject_Str on the value
of the exception. It also has a test.

Added file: http://bugs.python.org/file12087/use_PyObject_Str_and_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 04:48:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 03:48:07 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227239287.19.0.717028110929.issue4367@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
title: Patch for segmentation fault in ast_for_atom -> segmentation fault in ast_for_atom
Added file: http://bugs.python.org/file12088/use_PyObject_Str_and_test2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 09:19:12 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 21 Nov 2008 08:19:12 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227255552.37.0.943052959597.issue1028@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I suceeded to reproduce this issue with coLinux + UltraVNC on Win2000.

Yes, py3k claimed utf-8 error, so I tried trunk. Here is result.

*** event.keycode:  8
*** event.state:  0
*** event.char:  ''

*** event.keycode:  16
*** event.state:  4
*** event.char:  '\xc0\x80'

This '\xc0\x80' seems to be used in tcl as null byte '\0'. You can see
this magic value in tcl source and google.

I think we should convert this to '\x00' at python side. (shouldn't
treat this as utf-16)

I can see py3k + adhok.patch can output this result.

*** event.keycode:  8
*** event.state:  0
*** event.char:  ''

*** event.keycode:  16
*** event.state:  4
*** event.char:  '\x00'

Probably Tcl_GetUnicode does this conversion inside. (I'm not sure,
because I didn't look into source code so deeply) And I'm not sure why
this error doesn't happen with tk8.5.

Added file: http://bugs.python.org/file12089/adhok.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 09:21:54 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 21 Nov 2008 08:21:54 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227255714.84.0.808834215021.issue1028@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I did little modification to tkintertest.py. Please use this line.

    my_print("*** event.char: ", repr(event.char))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 09:39:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 08:39:16 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227256756.73.0.046857928114.issue4367@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, it's better to simply call str() on the exception. I was confused
by the fact that UnicodeError is a simple exception, with a single
message, unlike UnicodeDecodeError which has more attributes.

About the patch:
- The test does not work if test_ucn.py is run before: the unicodedata
module is imported only once on the first \N{} decoding. You could try
to run the test in a subprocess.

- In ast.c, errstr should be DECREF'd.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:07:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 09:07:49 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227258469.2.0.573760120835.issue4373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I have studied this some time ago. The xx module comes each time from a
different file (in a directory created with tempfile.mkdtemp).

Every instance of the module creates a new entry in the static
"extensions" dictionary in Python/import.c. This entry at least contains
a copy of the module dictionary, which explains the number of "leaked"
references.

I do not see any way to clear this dictionary. The proposed patch is
probably the best thing to do.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:30:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 Nov 2008 09:30:33 +0000
Subject: [issue4087] Document the effects of NotImplemented on == and !=
In-Reply-To: <1223559584.24.0.470688627133.issue4087@psf.upfronthosting.co.za>
Message-ID: <1227259833.46.0.572416420196.issue4087@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good.  Thanks, Raymond.

Minor typos:  "numberic" -> "numeric"
"the expression ``x in y`` equivalent to" -> 
"the expression ``x in y`` is equivalent to"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4087>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:48:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 09:48:16 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227260896.61.0.378873784377.issue4373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The refleak in test_pickle comes from unpickler_read(). The attached
patch corrects it.

Added file: http://bugs.python.org/file12090/pickle-leak2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:53:24 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 21 Nov 2008 09:53:24 +0000
Subject: [issue4375] inspect.getsource doesn't work with PYTHONPATH and source
	compiled from a different dir
In-Reply-To: <1227261204.44.0.0137459794576.issue4375@psf.upfronthosting.co.za>
Message-ID: <1227261204.44.0.0137459794576.issue4375@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I'm running into a similar problem as Jean-Paul in:

http://bugs.python.org/issue4223

But the patch in it doesn't work for me. My issue is also with files 
compiled already with python3.0, but then being accessed from a 
different location using PYTHONPATH. Here's a full example of the 
problem:

mkdir dir1
mkdir dir1/foo
mkdir dir2
echo 'def f(): pass' >  dir1/foo/__init__.py
cd dir1
python3.0 -c "import foo"
cd ../dir2
python3.0 -c "import inspect, sys; sys.path.append('../dir1'); import 
foo; print(inspect.getsource(foo.f))"

Which errors out with:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 691, in getsource
    lines, lnum = getsourcelines(object)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 680, in getsourcelines
    lines, lnum = findsource(object)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 528, in findsource
    raise IOError('could not get source code')
IOError: could not get source code


If I instrument inspect, it looks like what's happening is that 
linecache is being passed f.__code__.co_filename. However with the 
sys.path manipulation, that filename is baked into the .pyc file as 
"foo/__init__.py". This confuses linecache which can't find the file. 
Here's one suggestion of a fix.

--- /tmp/inspect.py	2008-11-21 01:34:56.000000000 -0800
+++ /opt/local/lib/python3.0/inspect.py	2008-11-21 01:35:28.000000000 -
0800
@@ -518,6 +518,7 @@
     is raised if the source code cannot be retrieved."""
     file = getsourcefile(object) or getfile(object)
     module = getmodule(object, file)
+    file = getsourcefile(module) or getfile(file)
     if module:
         lines = linecache.getlines(file, module.__dict__)
     else:

It looks like in most situations the module has an accurate __file__ 
that's updated from PYTHONPATH. I'm not sure if this works in every 
situation, but this, along with the other patch, work together to get 
the source printing working.

----------
components: Library (Lib)
messages: 76170
nosy: erickt
severity: normal
status: open
title: inspect.getsource doesn't work with PYTHONPATH and source compiled from a different dir
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4375>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:09:31 2008
From: report at bugs.python.org (Aaron Brady)
Date: Fri, 21 Nov 2008 10:09:31 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>


New submission from Aaron Brady <castironpi at gmail.com>:

Nested 'BigEndianStructure' fails in 2.5 and 2.6.:

TypeError: This type does not support other endian

Example and traceback in attached file.

----------
assignee: theller
components: ctypes
files: ng36.py
messages: 76171
nosy: castironpi, theller
severity: normal
status: open
title: Nested ctypes 'BigEndianStructure' fails
type: compile error
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12091/ng36.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:24:36 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 10:24:36 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227263076.27.0.272922920177.issue4373@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Good analysis Amaury! The new patch for build ext uses a single temp dir.

----------
nosy: +loewis
Added file: http://bugs.python.org/file12092/issue4373_build_ext2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:36:02 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Nov 2008 10:36:02 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227263762.52.0.0945326080674.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

You are missing the point on using Tcl_CreateObjCommand, I didn't mean
to just go and and do s/Tcl_CreateCommand/Tcl_CreateObjCommand/ because
if you are going to convert everything to unicode then there is no point
in using Tcl_CreateObjCommand.
Also, Tcl_ObjCmdProc should use Tcl_Obj *CONST objv[] instead of Tcl_Obj
*const objv[] because Tcl may define CONST as nothing, and it uses CONST
when defining Tcl_ObjCmdProc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:52:54 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 21 Nov 2008 10:52:54 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227264774.0.0.300756536942.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Just a thought here:
Maybe it would be better just to change socket._fileobject to always 
use a minimum of 8k readbuffer for readline() just as read() already 
does.  The read() documentation states that recv(1) is very 
inefficient, and so it is.
The intent, when calling makefile(bufsize=0) is probably to make sure 
that buffering for write() is disabled.
Any thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:57:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 10:57:34 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227265054.73.0.783313089939.issue4373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem is that on Windows (and cygwin) you cannot unlink a .pyd
that is currently loaded in memory.

I tried to use ctypes and call FreeLibrary. Now the .pyd can be removed,
but the interpreter crashes when it comes to free the module on shutdown.
I'm afraid that until python has a real support for dlclose() on dynamic
loaded module, the best is to skip this test during the refleak hunt.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 13:32:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 12:32:20 +0000
Subject: [issue4377] tokenize.detect_encoding() and Mac newline
In-Reply-To: <1227270739.29.0.218620905737.issue4377@psf.upfronthosting.co.za>
Message-ID: <1227270739.29.0.218620905737.issue4377@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I'm trying to fix IDLE to support Unicode (#4008 and #4323). Instead 
of IDLE builtin charset detection, I tried to use 
tokenize.detect_encoding() but this function doesn't work with script 
using Mac new line (b"\r").

Code to detect the encoding of a Python script:
----
def pythonEncoding(filename):
   with open(filename, 'rb') as fp:
      encoding, lines = detect_encoding(fp.readline)
   return encoding
----

Example to reproduce the problem with Mac script:
----
fp = BytesIO(b'# coding: ISO-8859-1\rprint("Bonjour ma ch\xe8re 
amie")\r')
encoding, lines = detect_encoding(fp.readline)
print(encoding, lines)
----

=> Result: utf-8 [b'# coding: ISO-8859-1\rprint("Bonjour ma ch\xe8re 
amie")\r']

The problem occurs at "line_string = line.decode('ascii')". 
Since "line" contains a non-ASCII character (b"\xe8"), the conversion 
fails.

----------
components: Library (Lib)
messages: 76176
nosy: haypo
severity: normal
status: open
title: tokenize.detect_encoding() and Mac newline
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4377>
_______________________________________

From report at bugs.python.org  Fri Nov 21 13:32:26 2008
From: report at bugs.python.org (Stephan Raue)
Date: Fri, 21 Nov 2008 12:32:26 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1227270746.3.0.427067552215.issue1597850@psf.upfronthosting.co.za>


Stephan Raue <stephan.raue at gmx.net> added the comment:

when i crosscompile Python 2.6 with Patch cross-2.6-0.7.diff which is 
based on cross-2.5.1.patch  i become follow error: 

ld -s -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I. -IInclude -I./Include build/temp.linux-i686-
2.5/home/stephan/OpenELEC/build.i386.uClibc/Python-
2.6/Modules/_multiprocessing/multiprocessing.o build/temp.linux-i686-
2.5/home/stephan/OpenELEC/build.i386.uClibc/Python-
2.6/Modules/_multiprocessing/socket_connection.o build/temp.linux-i686-
2.5/home/stephan/OpenELEC/build.i386.uClibc/Python-
2.6/Modules/_multiprocessing/semaphore.o -L/usr/lib -lpython2.5 -o 
build/lib.linux-i686-2.5/_multiprocessing.so
ld: unrecognized option '-DNDEBUG'
ld: use the --help option for usage information
creating build/temp.linux-i686-2.5/libffi
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... 
/home/stephan/OpenELEC/build.i386.uClibc/toolchain/bin/i686-geexbox-
linux-uclibc-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C 
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Failed to configure _ctypes module

what can i do libffi compiles with --host and --build

when i compile libffi standalone and run configure with --with-system-
ffi the error is the same.

----------
nosy: +sraue
versions: +Python 2.6 -Python 2.5
Added file: http://bugs.python.org/file12093/cross-2.6-0.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Nov 21 14:31:02 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 21 Nov 2008 13:31:02 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227274262.86.0.831797633791.issue1028@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12089/adhok.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 14:37:40 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Nov 2008 13:37:40 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227274660.86.0.923567935152.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I'm sorry if it sounded like I were bashing you, I was just pointing out
my view of the patch -- you didn't need to remove it. The patch I
submitted here can also be improved (although it "works"), but I'm
leaving it as a possible idea for someone else that might look into
this, since I can't invest much time into this right now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 14:40:06 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 21 Nov 2008 13:40:06 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1227274806.67.0.920598196839.issue1028@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>You are missing the point on using Tcl_CreateObjCommand, I didn't mean
>to just go and and do s/Tcl_CreateCommand/Tcl_CreateObjCommand/ because
>if you are going to convert everything to unicode then there is no
>point in using Tcl_CreateObjCommand.

I'm not tcl/tk expert, so probably missng many things. :-(
Can you explain how to solve this issue by moving to Tcl_CreateObjCommand?

>Also, Tcl_ObjCmdProc should use Tcl_Obj *CONST objv[] instead of
>Tcl_Obj *const objv[] because Tcl may define CONST as nothing, and it
>uses CONST when defining Tcl_ObjCmdProc.

I created adhok.patch just for explanation. This is not solution. I used
Tcl_CreateObjCommand + Tcl_GetUnicode to demonstrate Tcl converts
'\xc0\x80' to null byte. (adhok.patch contained Japanese characters, so
I'll repost that as just_for_explanation.patch)

Added file: http://bugs.python.org/file12094/just_for_explanation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:03:09 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Nov 2008 14:03:09 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1227274806.67.0.920598196839.issue1028@psf.upfronthosting.co.za>
Message-ID: <ac2200130811210603x4b984e19qb12e23b448c30af2@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Hirokazu Yamamoto added the comment:
>
>>You are missing the point on using Tcl_CreateObjCommand, I didn't mean
>>to just go and and do s/Tcl_CreateCommand/Tcl_CreateObjCommand/ because
>>if you are going to convert everything to unicode then there is no
>>point in using Tcl_CreateObjCommand.
>
> I'm not tcl/tk expert, so probably missng many things. :-(
> Can you explain how to solve this issue by moving to Tcl_CreateObjCommand?
>

By moving to Tcl_CreateObjCommand we would start using the FromObj
function present in _tkinter.c that is responsible for converting tcl
objects to python objects. Then what remains to be verified is how
compatible this would be with current tkinter code, and checking how
correct FromObj is nowadays.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:12:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 14:12:20 +0000
Subject: [issue4372] __cmp__ removal not in What's New
In-Reply-To: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
Message-ID: <1227276740.29.0.556067419658.issue4372@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate issue: see #4372. Anyway, an you write a patch?

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4372>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:12:25 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 14:12:25 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227276745.72.0.101714391043.issue2306@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Copy/paste of the issue #4372:
---
What's New in Python 3.0/Common stumbling blocks
has this "builtin.sorted() and list.sort() no longer accept the cmp
argument providing a comparison function. Use the key argument 
instead."

Please add "The __cmp__ special method is no longer used for
comparisons. Use __lt__ for sorting, __eq__ with __hash__, and other
rich comparisons as needed."

People are already stumbling on this.
---

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:16:11 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 14:16:11 +0000
Subject: [issue4372] __cmp__ removal not in What's New
In-Reply-To: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
Message-ID: <1227276971.91.0.513513776004.issue4372@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate issue: see #2306. Anyway, an you write a patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4372>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:16:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 14:16:15 +0000
Subject: [issue4372] __cmp__ removal not in What's New
In-Reply-To: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
Message-ID: <1227276975.92.0.406710480956.issue4372@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4372>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:23:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 14:23:18 +0000
Subject: [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227277398.76.0.13521260518.issue4358@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The application is a web service with postgresql backend, so it
> heavily uses pyexpat and pygresql in a threaded environment.

pyexpat or pygresql is maybe not thread safe. To catch such error, you 
have to use Valgrind. And to use Valgrind, you have to recompile 
Python with the define "Py_USING_MEMORY_DEBUGGER": read 
Misc/valgrind.supp (comments at the top). Then, 
use "valgrind --suppressions=Misc/valgrind.supp <your program> 
<arguments...>". You might also try 
helgrind: "valgrind --tool=helgrind --suppressions=Misc/valgrind.supp 
<your program> <arguments...>".

Note: remember me to translate this article to english!
http://www.haypocalc.com/blog/index.php/2008/08/22/160-deboguer-programme-python-avec-gdb

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:16:49 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:16:49 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1227280609.01.0.889566847929.issue3741@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:16:59 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:16:59 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1227280619.35.0.023896096583.issue3741@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:17:21 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:17:21 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227280641.99.0.122983191155.issue3799@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:17:43 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:17:43 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227280663.78.0.548001356453.issue4373@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:18:07 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:18:07 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227280687.53.0.28173276044.issue2306@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:18:52 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2008 15:18:52 +0000
Subject: [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu
In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>
Message-ID: <1227280732.86.0.333402484553.issue4303@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Deferring until 3.0 final is out.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4303>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:38:00 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 21 Nov 2008 15:38:00 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227281880.69.0.117991472127.issue2306@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:42:35 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 21 Nov 2008 15:42:35 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227282155.95.0.888971712181.issue3799@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

damn... my cc to report at bugs.python.org didn't work.  Here's the recap
(message to python-checkins):

    me> ... I thought Guido was of the opinion that the 3.0 version 
should
    me> be able to read dumb dbms written by earlier Python versions....

And write them.  From msg72963:

    (1) Be able to read databases written by Python 2.x.

    (1a) Write databases readable by Python 2.x.

Ah, but wait a minute.  I see your comment in msg76080:

    If you look at the 2.7 code all it requires of keys and values in
    __setitem__ is that they are strings; there is nothing about Latin-1 
in
    terms of specific encoding (must be a 3.0 addition to make the
    str/unicode transition the easiest).

The acid test.  I executed the attached mydb2write.py using Python 2.5 
then
executed the attached mydb3read.py using Python 3.0.  The output:

    % python2.5 mydb2write.py 
    1 abc
    2 [4, {4.2999999999999998: 12}]
    3 <__main__.C instance at 0x34bb70>
    % python3.0 mydb3read.py
    1 b'abc'
    2 [4, {4.2999999999999998: 12}]
    Traceback (most recent call last):
      File "mydb3read.py", line 13, in <module>
        print(3, pickle.loads(db['3']))
      File "/Users/skip/local/lib/python3.0/pickle.py", line 1329, in 
loads
        return Unpickler(file, encoding=encoding, errors=errors).load()
    _pickle.UnpicklingError: bad pickle data

so if the ability to read Python 2.x dumbdbm files is still a 
requirement I
think there's a little more work to do.

----------
nosy: +skip.montanaro
Added file: http://bugs.python.org/file12095/mydb2write.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:42:53 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 21 Nov 2008 15:42:53 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227282173.96.0.510238358456.issue3799@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Added file: http://bugs.python.org/file12096/mydb3read.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:44:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Nov 2008 15:44:57 +0000
Subject: [issue3799] Re: r67310 - in python/branches/py3k: Lib/dbm/dumb.py
	Lib/test/test_dbm_dumb.py Misc/NEWS
In-Reply-To: <18726.54633.145274.19866@montanaro-dyndns-org.local>
Message-ID: <ca471dc20811210744t74a4e458n8a6c336268bf9fe4@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I think the ability to read old files is essential. The ability to
write them is a mer nice-to-have.

On Fri, Nov 21, 2008 at 7:36 AM,  <skip at pobox.com> wrote:
>
>    me> ... I thought Guido was of the opinion that the 3.0 version should
>    me> be able to read dumb dbms written by earlier Python versions....
>
> And write them.  From msg72963:
>
>    (1) Be able to read databases written by Python 2.x.
>
>    (1a) Write databases readable by Python 2.x.
>
> Ah, but wait a minute.  I see your comment in msg76080:
>
>    If you look at the 2.7 code all it requires of keys and values in
>    __setitem__ is that they are strings; there is nothing about Latin-1 in
>    terms of specific encoding (must be a 3.0 addition to make the
>    str/unicode transition the easiest).
>
> The acid test.  I executed the attached mydb2write.py using Python 2.5 then
> executed the attached mydb3read.py using Python 3.0.  The output:
>
>    % python2.5 mydb2write.py
>    1 abc
>    2 [4, {4.2999999999999998: 12}]
>    3 <__main__.C instance at 0x34bb70>
>    % python3.0 mydb3read.py
>    1 b'abc'
>    2 [4, {4.2999999999999998: 12}]
>    Traceback (most recent call last):
>      File "mydb3read.py", line 13, in <module>
>        print(3, pickle.loads(db['3']))
>      File "/Users/skip/local/lib/python3.0/pickle.py", line 1329, in loads
>        return Unpickler(file, encoding=encoding, errors=errors).load()
>    _pickle.UnpicklingError: bad pickle data
>
> so if the ability to read Python 2.x dumbdbm files is still a requirement I
> think there's a little more work to do.
>
> cc'ing report at bugs.python.org to preserve the scripts with the ticket.
>
> Skip
>
>
> _______________________________________________
> Python-3000-checkins mailing list
> Python-3000-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-3000-checkins
>
>

----------
title: Byte/string inconsistencies between different dbm modules -> Re: r67310 - in python/branches/py3k: Lib/dbm/dumb.py Lib/test/test_dbm_dumb.py Misc/NEWS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:45:44 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Nov 2008 15:45:44 +0000
Subject: [issue3799] Re: r67310 - in python/branches/py3k: Lib/dbm/dumb.py
	Lib/test/test_dbm_dumb.py Misc/NEWS
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227282344.89.0.303642492028.issue3799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Reading old dumbdbm files is essential. Writing them is not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:48:13 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Nov 2008 15:48:13 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227282493.85.0.619005924696.issue3799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

[fix title]

----------
title: Re: r67310 - in python/branches/py3k: Lib/dbm/dumb.py Lib/test/test_dbm_dumb.py Misc/NEWS -> Byte/string inconsistencies between different dbm modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 17:45:58 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 21 Nov 2008 16:45:58 +0000
Subject: [issue4378] howto doc update
In-Reply-To: <1227285958.71.0.314109568339.issue4378@psf.upfronthosting.co.za>
Message-ID: <1227285958.71.0.314109568339.issue4378@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/howto/functional.html

Gone:

  itertools.ifilter
  itertools.imap
  itertools.izip

changed:

  itertools.ifilterfalse   -->   itertools.filterfalse

strange?

  functools.reduce is described, but not with functools.

The section requests comments be mailed directly to author.  Done.

----------
assignee: georg.brandl
components: Documentation
messages: 76190
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: howto doc update
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4378>
_______________________________________

From report at bugs.python.org  Fri Nov 21 17:47:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 16:47:21 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1227286041.09.0.593870953926.issue3926@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is already corrected by r66922 (issue3391), but the patches are
different and there are some things I don't like in the present
implementation:

- in idle_showwarning, the "file" argument is ignored and always
replaced by warning_stream.
- warnings.formatwarning is passed a "file" argument: this could fail,
but works only because the function is monkey-patched. But "file" is not
even used there!

The attached patch seems better, but does not apply cleanly any more.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Fri Nov 21 17:59:30 2008
From: report at bugs.python.org (Andrew Inglis)
Date: Fri, 21 Nov 2008 16:59:30 +0000
Subject: [issue1711800] SequenceMatcher bug with insert/delete block after
	"replace"
Message-ID: <1227286770.7.0.631821666369.issue1711800@psf.upfronthosting.co.za>


Andrew Inglis <tfaing at gmail.com> added the comment:

Are there any updates for this issue? I am having the same problem, or,
lack of feature, with SequenceMatcher. Gabriel, Differ doesn't seem to
have the functionality, or an easy way to patch it to get the
functionality, that Christian is talking about. Christian, what are
these "Any diffing program"[s] that you speak of that give the same
output of SequenceMatcher with this issue fixed? Any solutions you found
for python?

Thanks!

----------
nosy: +tfaing
type:  -> feature request
versions: +Python 2.5.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711800>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:20:07 2008
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 21 Nov 2008 17:20:07 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>


New submission from Kevin Watters <kevinwatters at gmail.com>:

After releasing a Py_DEBUG build to some users who were experiencing 
problems, I noticed a pattern in some of the crash reports I got back:

msvcr90d!_wassert+0xb64
python25_d!FILE_TIME_to_time_t_nsec+0xac
python25_d!attribute_data_to_stat+0x67
python25_d!win32_wstat+0x6f
python25_d!posix_do_stat+0x51
python25_d!posix_stat+0x24
python25_d!PyCFunction_Call+0x65
python25_d!call_function+0x34f
python25_d!PyEval_EvalFrameEx+0x4741

The only way I can see _wassert being hit in FILE_TIME_to_time_t_nsec is 
in the Py_SAFE_DOWNCAST used to downcast an __int64 to int. 
Py_SAFE_DOWNCAST checks that there is equality between the casted and 
non-casted values with Py_DEBUG enabled--maybe in this function we 
should remove Py_SAFE_DOWNCAST?

I can't find a way to see the actual value for "in" before the assert is 
hit--I'm unfamiliar with picking through minidumps with WinDbg, which 
for some reason will show me the stack for these dumps when Visual 
Studio won't. But if I need to investigate more about them I can.

----------
components: None
messages: 76193
nosy: kevinwatters
severity: normal
status: open
title: Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
type: behavior
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:58:19 2008
From: report at bugs.python.org (Akira Kitada)
Date: Fri, 21 Nov 2008 17:58:19 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227290299.37.0.70743157045.issue4368@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Yes, that change was not merged into 2.5 branch.
I Hope it's not yet been too late for 2.5.3.

I confirmed this fixes the problem on FreeBSD 4.11.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:24:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:24:53 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227291893.05.0.782182206807.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So the use of pickle is not fair as that doesn't round-trip if you
simply write out a file because py3k pickle doesn't like classic classes
and the new-style classes want copy_reg which is not in existence in
py3k since it was renamed. See pickle2write.py and pickle3read.py (which
are version-agnostic; just following Skip's naming) for the pickle failing.

Now if you skip that one use-case in the example of pickling a
user-defined class then everything works out. I have attached a
hacked-up version of Skip's scripts that take Unicode strings, encode
them in Latin-1 and UTF-8, and then decode them on the other side in
Py3K, all without issue.

In other words I think my solution works and pickle is the trouble-maker
in all of this.

----------
stage: commit review -> needs patch
Added file: http://bugs.python.org/file12097/pickle2write.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:25:16 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:25:16 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227291916.39.0.711491602213.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file12098/pickle3read.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:25:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:25:56 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227291956.57.0.920372033471.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file12099/mydb2write.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:26:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:26:22 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227291982.08.0.411813127842.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file12100/mydb3read.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:26:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:26:36 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227291996.88.0.442217033087.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:32:03 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 21 Nov 2008 18:32:03 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1227291893.05.0.782182206807.issue3799@psf.upfronthosting.co.za>
Message-ID: <18726.65175.814090.801557@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Brett> In other words I think my solution works and pickle is the
    Brett> trouble-maker in all of this.

I can buy that.  Should pickle map "copy_reg" to "copyreg"?  Is that the
only incompatibility?

Actually, it seems this ticket should be closed and another opened about
this pickle issue.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:40:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 18:40:03 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <18726.65175.814090.801557@montanaro-dyndns-org.local>
Message-ID: <bbaeab100811211040u630beafav7c22979c2f5039e2@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Nov 21, 2008 at 10:32, Skip Montanaro <report at bugs.python.org> wrote:
>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Brett> In other words I think my solution works and pickle is the
>    Brett> trouble-maker in all of this.
>
> I can buy that.  Should pickle map "copy_reg" to "copyreg"?  Is that the
> only incompatibility?
>
> Actually, it seems this ticket should be closed and another opened about
> this pickle issue.
>

Well, I still need a code review for my latest patch that changes the
docs, cleans up gdbm and ndbm exception messages, catches a place
where I didn't decode before write-out, and adds an 'encoding'
argument to all open() calls.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:01:44 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 21 Nov 2008 19:01:44 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <bbaeab100811211040u630beafav7c22979c2f5039e2@mail.gmail.com>
Message-ID: <18727.1425.957851.210536@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

One doc nit: There is still reference to ``gdbm`` and Dbm (or dbm) objects
when they should probably use ``dbm.gnu`` and ``dbm.ndbm``, respectively.

I'm confused by the encoding="Latin-1" args to _io.open for dbm.dumb.  I
thought the default enoding was going to be utf-8, and I see no way to
influence that.  Is that just to make sure all code points can be written
without error?

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:08:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 19:08:29 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227294509.69.0.279003451223.issue3799@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:54:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 19:54:15 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <18727.1425.957851.210536@montanaro-dyndns-org.local>
Message-ID: <bbaeab100811211154j115202d0j5083f75ef6ca8611@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Nov 21, 2008 at 11:01, Skip Montanaro <report at bugs.python.org> wrote:
>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> One doc nit: There is still reference to ``gdbm`` and Dbm (or dbm) objects
> when they should probably use ``dbm.gnu`` and ``dbm.ndbm``, respectively.
>

OK, I will fix that and upload a new patch at some point.

> I'm confused by the encoding="Latin-1" args to _io.open for dbm.dumb.  I
> thought the default enoding was going to be utf-8, and I see no way to
> influence that.  Is that just to make sure all code points can be written
> without error?
>

It's so that when writing out there won't be any errors. Since the
repr of strings are used instead of bytes the stuff passed in and
written to disk must be represented in an encoding that will never
complain about what bytes it gets. Latin-1 does this while UTF-8. And
since everything is being written and read in Latin-1 I figured I
might as well be thorough and specify the encoding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:20:48 2008
From: report at bugs.python.org (Kevin Fitch)
Date: Fri, 21 Nov 2008 20:20:48 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>


New submission from Kevin Fitch <kfitch42 at gmail.com>:

from functools import partial
from copy import deepcopy

p = partial("Hello world".replace, "world")
p("mom")
p2 = deepcopy(p)


The output I get is:
Hello mom

Followed by:
<type 'exceptions.TypeError'>             Traceback (most recent call last)

/home/kfitch/<ipython console> in <module>()

/usr/lib/python2.5/copy.py in deepcopy(x, memo, _nil)
    187                             raise Error(
    188                                 "un(deep)copyable object of type
%s" % cls)
--> 189                 y = _reconstruct(x, rv, 1, memo)
    190
    191     memo[d] = y

/usr/lib/python2.5/copy.py in _reconstruct(x, info, deep, memo)
    320     if deep:
    321         args = deepcopy(args, memo)
--> 322     y = callable(*args)
    323     memo[id(x)] = y
    324     if listiter is not None:

/usr/lib/python2.5/copy_reg.py in __newobj__(cls, *args)
     90
     91 def __newobj__(cls, *args):
---> 92     return cls.__new__(cls, *args)
     93
     94 def _slotnames(cls):

<type 'exceptions.TypeError'>: type 'partial' takes at least one argument



I am not entirely convinced that doing a deepcopy on a partial makes
sense, but I would expect one of:
1) An explicit exception saying it isn't allowed
2) Returning the original partial object
3) An actual copy (should the arguments its storing get deepcopied?)

P.S. This is with 2.5.2 under Linux (Ubuntu 8.04)

----------
messages: 76200
nosy: kfitch
severity: normal
status: open
title: Deepcopy of functools.partial gives wierd exception
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4380>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:29:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 20:29:37 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1227299377.39.0.549788038462.issue4379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You almost gave the answer in your question - the FILE_TIME is about to be 
converted to a time_t greater than 2**31.

in posixmodule.c::FILE_TIME_to_time_t_nsec(), a comment says:
/* XXX Win32 supports time stamps past 2038; we currently don't */
just before the assert()...

And indeed to reproduce the same crash it is enough to call os.stat() on a 
file with a creation date in 2050 for example.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:33:45 2008
From: report at bugs.python.org (Kevin Fitch)
Date: Fri, 21 Nov 2008 20:33:45 +0000
Subject: [issue4381] Cannot declare multiple classes via exec when inside a
	function.
In-Reply-To: <1227299625.55.0.683059455596.issue4381@psf.upfronthosting.co.za>
Message-ID: <1227299625.55.0.683059455596.issue4381@psf.upfronthosting.co.za>


New submission from Kevin Fitch <kfitch42 at gmail.com>:

codeText = """
class foo(object): pass
class bar(object):
  baz = foo()
"""

def doExec(text):
  exec text

### This works:
# Although if I do this before the doExec below, then the
# doExec doesn't fail.
# exec codeText

### But this does not:
doExec(codeText)


The output I get is:
---------------------------------------------------------------------------
<type 'exceptions.NameError'>             Traceback (most recent call last)

/home/kfitch/<ipython console> in <module>()

/home/kfitch/<ipython console> in doExec(text)

/home/kfitch/<string> in <module>()

/home/kfitch/<string> in bar()

<type 'exceptions.NameError'>: name 'foo' is not defined



I don't fully understand why the version in the function doesn't work,
but I suspect it is a bug related to scoping, since foo is really
doExec.foo (I think).

This is with python 2.5.2 under Linux (Ubuntu 8.04)

----------
messages: 76202
nosy: kfitch
severity: normal
status: open
title: Cannot declare multiple classes via exec when inside a function.
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4381>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:45:20 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 21 Nov 2008 20:45:20 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227300320.56.0.26201189374.issue4356@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I agree you can get around this with defining __cmp__, however same goes
to "sort" and it was added anyway.

My take on it is that sometimes I need to find something in a big list
of objects, and I don't like to do DSU and not add __cmp__ to the
objects (since some of the lists might be sorted by different attributes
- say one list for time and one line for price).

I'd prefer if we do implement "key" and add a warning in the docs it
might slow you down. Which what will happen in the case of __cmp__ anyway.

I don't see why the "key" function should be called all the time on
inserted item, it's very easy to cache this value

def bisect(a, x, lo=0, hi=None, key=lambda x: x):
    assert low >= 0, "low must be non-negative"
    hi = hi or len(a)

    x_key = key(x) 
    while lo < hi:
        mid = (lo+hi)//2
        if x_key < key(a[mid]): hi = mid
        else: lo = mid+1
    return lo

(I'd also wish for "identity" built in, however this is another subject :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Fri Nov 21 22:16:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 21:16:10 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1227302170.37.0.551216580211.issue4379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The attached patch corrects the problem: since VS2008 time_t is a 64bit 
integer; now os.stat() can return times after 2038 on Windows.

This prevents the crash, but the functionality is far from complete: 
os.utime() at least should accept 64bit times.

----------
keywords: +patch
Added file: http://bugs.python.org/file12101/time_t_64.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________

From report at bugs.python.org  Fri Nov 21 22:53:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 21:53:44 +0000
Subject: [issue4381] Cannot declare multiple classes via exec when inside a
	function.
In-Reply-To: <1227299625.55.0.683059455596.issue4381@psf.upfronthosting.co.za>
Message-ID: <1227304424.26.0.13912053096.issue4381@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree that it is confusing; in short: a bare exec() does not play well with closures;  
This is a consequence of the python execution model, and is unlikely to change.

Here, the class 'foo' is stored in the function's local variables.
But the execution of the body of the 'bar' class searches names in its local scope (the 
class body) and the global scope (the module level), and misses the function's 
locals...

I strongly suggest to avoid pure exec() statements; always specify a global and/or a 
local dictionary.

In your case, the following works:

def doExec(text):
  d = {}  # or:   d = dict(globals())
  exec text in d
  print d.keys()

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4381>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:04:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 22:04:08 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227305048.87.0.619844207859.issue4367@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This new patch address review issues.

Added file: http://bugs.python.org/file12102/use_PyObject_Str_and_test3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:08:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 22:08:48 +0000
Subject: [issue4363] Make uuid module functions usable without ctypes
In-Reply-To: <1227192268.71.0.69220527161.issue4363@psf.upfronthosting.co.za>
Message-ID: <1227305328.68.0.362320293668.issue4363@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r63718 (trunk) and r63719 (2.6)
Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4363>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:15:18 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Fri, 21 Nov 2008 22:15:18 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_dbm_dumb fails due to what appears to be a character encoding issue 
on Mac OS X:

Majestix:Python-3.0rc3 martina$ 
DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-3.0rc3: ./python.exe 
-E -bb ./Lib/test/regrtest.py -l test_dbm_dumbtest_dbm_dumb
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2550>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??', 
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method 
_Database.close of <dbm.dumb._Database object at 0x6a2550>> ignored
test test_dbm_dumb failed -- errors occurred; run in verbose mode for 
details
1 test failed:
    test_dbm_dumb

----------
components: Library (Lib), Macintosh, Tests
messages: 76208
nosy: oefe
severity: normal
status: open
title: test_dbm_dumb fails due to character encoding issue on Mac OS X
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:16:59 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Fri, 21 Nov 2008 22:16:59 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227305819.67.0.783855471149.issue4382@psf.upfronthosting.co.za>


Martina Oefelein <Martina at oefelein.de> added the comment:

Example of verbose output (other testcases are similar):

======================================================================
ERROR: test_dumbdbm_creation (test.test_dbm_dumb.DumbDBMTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-
3.0rc3/Lib/test/test_dbm_dumb.py", line 41, in test_dumbdbm_creation
    f.close()
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/dbm/dumb.py", line 
228, in close
    self._commit()
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/dbm/dumb.py", line 
116, in _commit
    f.write("%r, %r\n" % (key.decode('Latin-1'), pos_and_siz_pair))
  File "./Lib/io.py", line 1491, in write
    b = encoder.encode(s)
  File "./Lib/encodings/mac_roman.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\xbc' in 
position 2: character maps to <undefined>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:17:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 22:17:49 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227305869.76.0.922566088444.issue4382@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:21:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 22:21:24 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227306084.57.0.16890704082.issue4367@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Everything looks good.

(20 lines of a complex test for two simple lines of code that nobody 
will ever run... unit tests is a religion)

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:27:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 22:27:45 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227306084.57.0.16890704082.issue4367@psf.upfronthosting.co.za>
Message-ID: <1afaf6160811211427x67a9ec0fr1e9a40d480731b63@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Nov 21, 2008 at 4:21 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Everything looks good.

Thanks for the review. Fixed in r67320.

>
> (20 lines of a complex test for two simple lines of code that nobody
> will ever run... unit tests is a religion)

One can't say we didn't try. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:27:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 22:27:58 +0000
Subject: [issue4367] segmentation fault in ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227306478.54.0.478379539558.issue4367@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:28:45 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Fri, 21 Nov 2008 22:28:45 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227306525.21.0.780706181334.issue4382@psf.upfronthosting.co.za>


Martina Oefelein <Martina at oefelein.de> added the comment:

The Mac Roman encoding comes into play, because _commit opens _dirfile 
without explicitly specifying an encoding. io.open then gets the 
encoding via locale.getpreferredencoding, which returns mac-roman:

Majestix:Python-3.0rc3 martina$ 
DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-3.0rc3: ./python.exe 
-c "import locale;print(locale.getpreferredencoding())"
mac-roman

Two issues:
- since dumb.py handles encoding explicitly, shouldn't it specify the 
encoding for _dirfile as well? (or use a binary file; but this could 
cause new line-ending troubles...)
- is mac-roman really the appropriate choice for 
locale.getpreferredencoding? This is on Mac OS X 10.5, not Mac OS 9... 
The preferred encoding for Mac OS X should be utf-8, not some legacy 
encoding...

Seems to be related to r67310, which was intended to fix issue #3799
http://svn.python.org/view/python/branches/py3k/Lib/dbm/dumb.py?
rev=67310&r1=63662&r2=67310

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:42:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 22:42:48 +0000
Subject: [issue4383] UnboundLocalError when IDLE cannot connect to its
	subprocess
In-Reply-To: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>
Message-ID: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When IDLE cannot connect to its subprocess, it tries to display the 
socket.error. But since python 3.0 the exception variable is cleared 
after the "except:" block and unavailable for the displaying code.

Exception in thread SockThread:
Traceback (most recent call last):
  File "c:\dev\python\py3k\lib\threading.py", line 507, in 
_bootstrap_inner
    self.run()
  File "c:\dev\python\py3k\lib\threading.py", line 462, in run
    self._target(*self._args, **self._kwargs)
  File "c:\dev\python\py3k\lib\idlelib\run.py", line 125, in 
manage_socket
    show_socket_error(err, address)
UnboundLocalError: local variable 'err' referenced before assignment

Patch is attached.

----------
components: IDLE
files: idle_socketerror.patch
keywords: needs review, patch
messages: 76213
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: UnboundLocalError when IDLE cannot connect to its subprocess
versions: Python 3.0
Added file: http://bugs.python.org/file12103/idle_socketerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4383>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:45:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 22:45:33 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227307533.54.0.42288408545.issue4382@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Issue 3799 already has a patch that specifies the encoding upon opening
the file so this should be fixed by final. Can you test the patch
(specify_open_encoding.diff) and let me know if that solves your
problem, Martina?

----------
dependencies: +Byte/string inconsistencies between different dbm modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Fri Nov 21 23:53:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 22:53:18 +0000
Subject: [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on
	Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1227307998.09.0.63341776872.issue4323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good and does simplify things: the py3k conversion to 
unicode may have some advantages sometimes!

I suggest to also remove the remaining two occurrences of 
"frameEncoding" in configDialog.py. This will suppress the extra space 
between the last two blocks of the dialog.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:00:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 23:00:02 +0000
Subject: [issue4383] UnboundLocalError when IDLE cannot connect to its
	subprocess
In-Reply-To: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>
Message-ID: <1227308402.0.0.330139841393.issue4383@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4383>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:00:41 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Nov 2008 23:00:41 +0000
Subject: =?utf-8?q?[issue4328]_"=C3=A0"_in_u"foo"_raises_a_misleading_error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1227308441.4.0.716367480361.issue4328@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

| but then it works with:
| >>> b'f' in 'foo'
| True

Not True in 3.0rc3.  Same message as you quoted:
 'in <string>' requires string as left operand, not bytes

bytes + string fails too

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:07:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 23:07:03 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227308823.66.0.273110538.issue4329@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's not a bug. base64 is a codec to encode *bytes* and characters. 
You have to encode your unicode string to bytes using a charset
 Example (utf-8):
>>> from base64 import b64encode, b64decode
>>> b64encode(u'a\xe9'.encode("utf-8"))
'YcOp'
>>> unicode(b64decode('YcOp'), "utf-8")
u'a\xe9'

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:08:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 23:08:24 +0000
Subject: [issue4383] UnboundLocalError when IDLE cannot connect to its
	subprocess
In-Reply-To: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>
Message-ID: <1227308904.36.0.190271767846.issue4383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the fast review, fixed in r67323

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4383>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:11:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 23:11:42 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1227309102.42.0.950762274185.issue4380@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4380>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:12:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 23:12:03 +0000
Subject: [issue4374] Pickle tests fail w/o _pickle extension
In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
Message-ID: <1227309123.54.0.637917554264.issue4374@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> alexandre.vassalotti
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4374>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:18:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 23:18:22 +0000
Subject: [issue4374] Pickle tests fail w/o _pickle extension
In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
Message-ID: <1227309502.0.0.401187423804.issue4374@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The test could be skipped for the pure-python version of pickle: after 
all, it just tests that the interpreter does not segfault...
A simpler change is to change the expected exception into "Exception".

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4374>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:21:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 23:21:38 +0000
Subject: [issue4384] Add a warnings.showwarning replacement for logging
In-Reply-To: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>
Message-ID: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

It would be nice if the logging package provided a replacement for
warnings.showwarning() so that all warning redirect to the logging package.

----------
components: Library (Lib)
keywords: easy
messages: 76221
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a warnings.showwarning replacement for logging
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4384>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:23:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 23:23:44 +0000
Subject: [issue4371] coerce gone---but not from docs
In-Reply-To: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>
Message-ID: <1227309824.3.0.158197139926.issue4371@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the suggestions. Done in r67324 and r67311.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4371>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:24:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Nov 2008 23:24:11 +0000
Subject: [issue4384] Add a warnings.showwarning replacement for logging
In-Reply-To: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>
Message-ID: <1227309851.34.0.812671309307.issue4384@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> vsajip
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4384>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:30:46 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Nov 2008 23:30:46 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227310246.98.0.860632190695.issue4329@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"This module provides data encoding and decoding as specified in RFC
3548. This standard defines the Base16, Base32, and Base64 algorithms
for encoding and decoding arbitrary binary strings into text strings
that can be safely sent by email, used as parts of URLs, or included as
part of an HTTP POST request. "

In other words, arbitrary 8-bit byte strings <=> 'safe' byte strings
You have to encode unicode to bytes first, as you did.  Str works
because you only have ascii chars and str uses the ascii encoder by
default.  The bytes() constructor has no default and 'ascii' must be
supplied

The error message is correct even if backwards. Unicode.translate
requires a unicode mapping, whereas b64decode supplies a bytes mapping
because it requires bytes.

3.0 added an earlier type check, so the same code gives
TypeError: expected bytes, not str

I believe there was an explicit decision to leave low-level wire-
protocol byte functions as bytes/bytearray only.

The 3.0 manual needs updating in this respect, but I will start another
issue for that.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:31:27 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Nov 2008 23:31:27 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227310287.87.0.667589573918.issue4329@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution: fixed -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:44:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Nov 2008 23:44:02 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The memory layout of PyType object's changes in Py3k from the
*compiler's* point of view. This means PyObject_HEAD_INIT can no longer
be used to initialise PyVarObject type definitions.

However, the documentation doesn't point this out (or document
PyVarObject_HEAD_INIT at all), and the compiler warnings currently
generated are not clear. Suggestion is to remove PyObject_HEAD_INIT from
Py3k entirely so this becomes a compile error instead of a warning, and
then better document the situation so extension authors know how to
correctly initialise the affected C structs.

See mailing list thread at:
http://mail.python.org/pipermail/python-3000/2008-November/015241.html

----------
components: Interpreter Core
messages: 76224
nosy: ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Py_Object_HEAD_INIT in Py3k
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:13:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 00:13:19 +0000
Subject: [issue4386] A binary file should show "b" in its mode
In-Reply-To: <1227312799.3.0.532336276837.issue4386@psf.upfronthosting.co.za>
Message-ID: <1227312799.3.0.532336276837.issue4386@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The changes following r67300 introduced the .mode and .name attributes on all 
the file-like objects returned by the open() function.

This also changed the mode returned by a file opened in binary mode: it was 
"rb", now it is "r". The fact that the mode does not "round-trip" (i.e: open(f, 
mode).mode != mode) was considered not important.

But now it is difficult to see if some opened file was opened in text or binary 
mode; in test_gzip.py, a test had to be changed, and now it does not test 
anything at all: the intent of the test is just to verify that a zip file is 
always opened in binary mode.

Benjamin suggested to change the mode returned by FileIO objects, so that they 
always contain a 'b'. They also accept an extra 'b' on creation: it is just 
ignored.

Now, for a file opened in text mode:
>>> f = open('filename')
>>> assert f.mode            == 'r'
>>> assert f.buffer.mode     == 'rb'
>>> assert f.buffer.raw.mode == 'rb'

The mode attribute is now always consistent with the one passed to the open() 
function. This also avoid gratuitous breakage with python2.x.

Patch attached. All tests pass.

----------
assignee: benjamin.peterson
files: fileio_mode.patch
keywords: needs review, patch
messages: 76225
nosy: amaury.forgeotdarc, benjamin.peterson
priority: release blocker
severity: normal
stage: patch review
status: open
title: A binary file should show "b" in its mode
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12104/fileio_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4386>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:41:20 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2008 00:41:20 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Binascii b2a_xxx functions accept 'binary data' and return ascii-encoded
bytes.  The corresponding a2b_xxx functions turn the ascii-encoded bytes
back to 'binary data' (bytes).  If the binary data is bytes, these
should be inverses of each other.

Somewhat surprisingly to me (because the corresponding base64 module
functions raise "TypeError: expected bytes, not str") 3.0 strings
(unicode) are accepted as 'binary data', though they will not 'round-trip'.

Ascii chars almost do
>>> a='aaaa'
>>> c=b.b2a_base64(a)
>>> c
b'YWFhYQ==\n'
>>> d=b.a2b_base64(c)
>>> d
b'aaaa'

But general unicode chars generate nonsense.
>>> a='\u1000'
>>> c=b.b2a_base64(a)
>>> c
b'4YCA\n'
>>> d=b.a2b_base64(c)
>>> d
b'\xe1\x80\x80'

I also tried b2a_uu.

Is this a bug?

----------
components: Extension Modules
messages: 76226
nosy: tjreedy
severity: normal
status: open
title: binascii b2a functions accept strings (unicode) as data
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:42:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 Nov 2008 00:42:14 +0000
Subject: [issue4386] A binary file should show "b" in its mode
In-Reply-To: <1227312799.3.0.532336276837.issue4386@psf.upfronthosting.co.za>
Message-ID: <1227314534.12.0.0540373757523.issue4386@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Amaury, thanks for getting the tests to pass. Applied in r67325.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4386>
_______________________________________

From report at bugs.python.org  Sat Nov 22 02:10:44 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 22 Nov 2008 01:10:44 +0000
Subject: [issue4374] Pickle tests fail w/o _pickle extension
In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
Message-ID: <1227316244.39.0.588561982855.issue4374@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I think the best way to fix this is to add sanity checks similar to the
ones in _pickle. The checks are obviously useless in pickle.py, but I
think it is simpler than to try to skip tests, and it gives a nicer
error message to people who forget to call __init__ when subclassing.

----------
keywords: +patch
Added file: http://bugs.python.org/file12105/fix_issue4374.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4374>
_______________________________________

From report at bugs.python.org  Sat Nov 22 02:25:34 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2008 01:25:34 +0000
Subject: [issue4337] Iteration over a map object with list()
In-Reply-To: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>
Message-ID: <1227317134.95.0.860934255993.issue4337@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Dict views and range objects are *iterables* because they are based on
reusable information.  Map, filter, and similar objects are *iterators*
because they are based on iterables that could be once-through
iterators. The built-in function entries carefully specific which is which.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4337>
_______________________________________

From report at bugs.python.org  Sat Nov 22 03:30:04 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2008 02:30:04 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227321004.51.0.947425844791.issue4356@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Just a reminder that __cmp__ is gone in 3.0.
I presume bisect, like sort, only requires __lt__ and perhaps __eq__,
though I can find no doc of either.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Sat Nov 22 03:37:13 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2008 02:37:13 +0000
Subject: [issue4361] Docstring for "Lib/string.py" is outdated
In-Reply-To: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>
Message-ID: <1227321433.45.0.273360739595.issue4361@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In rc3 also: The problem is partial update:

DESCRIPTION
    Public module variables:
    
    whitespace -- a string containing all characters considered whitespace
    lowercase -- a string containing all characters considered lowercase
letters
    uppercase -- a string containing all characters considered uppercase
letters
    letters -- a string containing all characters considered letters
...
DATA
    ascii_letters = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
    ascii_lowercase = 'abcdefghijklmnopqrstuvwxyz'
    ascii_uppercase = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

The latter is indeed correct:
>>> dir(string)
[..., 'ascii_letters', 'ascii_lowercase', 'ascii_uppercase', ...]

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4361>
_______________________________________

From report at bugs.python.org  Sat Nov 22 05:54:41 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 22 Nov 2008 04:54:41 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

There is one test failure with Python 3.0rc3 built on MacOS X 10.4.11 
(Intel).  Test  test_cmd_line fails in the very last test as follows:

% python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
test_optimize (__main__.CmdLineTest) ... ok
test_q (__main__.CmdLineTest) ... ok
test_run_code (__main__.CmdLineTest) ... FAIL
test_run_module (__main__.CmdLineTest) ... ok
test_run_module_bug1764407 (__main__.CmdLineTest) ... ok
test_site_flag (__main__.CmdLineTest) ... ok
test_usage (__main__.CmdLineTest) ... ok
test_verbose (__main__.CmdLineTest) ... ok
test_version (__main__.CmdLineTest) ... ok

======================================================================
FAIL: test_run_code (__main__.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0

----------------------------------------------------------------------
Ran 10 tests in 2.074s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 151, in <module>
    test_main()
  File "Lib/test/test_cmd_line.py", line 147, in test_main
    test.support.run_unittest(CmdLineTest)
  File ".../Python-3.0rc3/Lib/test/support.py", line 698, in 
run_unittest
    _run_suite(suite)
  File ".../Python-3.0rc3/Lib/test/support.py", line 681, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0


The results for this code snippet:

        # Test handling of non-ascii data
        if sys.getfilesystemencoding() != 'ascii':
            command = "assert(ord('\xe9') == 0xe9)"
            self.assertEqual(
                self.exit_code('-c', command),
                0)

are:

% python.exe 
Python 3.0rc3 (r30rc3:67312, Nov 21 2008, 14:20:38) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getfilesystemencoding()
'utf-8'
>>> ord('\xe9') == 0xe9
True

----------
components: Tests
messages: 76232
nosy: MrJean1
severity: normal
status: open
title: test_cmd_line fails on MacOS X
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:16:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:16:41 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1227341801.56.0.0717638176281.issue4387@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I vote yes.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:27:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:27:31 +0000
Subject: [issue4378] howto doc update
In-Reply-To: <1227285958.71.0.314109568339.issue4378@psf.upfronthosting.co.za>
Message-ID: <1227342451.81.0.211857954926.issue4378@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r67328.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4378>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:31:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:31:20 +0000
Subject: [issue4361] Docstring for "Lib/string.py" is outdated
In-Reply-To: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>
Message-ID: <1227342680.3.0.655721570469.issue4361@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r67329.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4361>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:34:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:34:23 +0000
Subject: [issue4364] error in multiprocessing docs - rawvalue
In-Reply-To: <1227194366.84.0.640745575496.issue4364@psf.upfronthosting.co.za>
Message-ID: <1227342863.54.0.616544787857.issue4364@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r67330.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4364>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:36:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:36:29 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1227342989.7.0.0480625803049.issue2306@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added __cmp__ issue in r67331.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:51:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:51:49 +0000
Subject: [issue4206] multiprocessing docs
In-Reply-To: <1224987668.88.0.751751151091.issue4206@psf.upfronthosting.co.za>
Message-ID: <1227343909.46.0.675225017413.issue4206@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r67334.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4206>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:54:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:54:28 +0000
Subject: [issue4012] Minor errors in multiprocessing docs
In-Reply-To: <1222910620.56.0.617350560863.issue4012@psf.upfronthosting.co.za>
Message-ID: <1227344068.51.0.713378482538.issue4012@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed applyAsync and missing ] in r67335.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4012>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:55:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 08:55:01 +0000
Subject: [issue4193] Multiprocessing example
In-Reply-To: <1224867277.0.0.802822144442.issue4193@psf.upfronthosting.co.za>
Message-ID: <1227344101.83.0.0786942407653.issue4193@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4193>
_______________________________________

From report at bugs.python.org  Sat Nov 22 11:27:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 10:27:33 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1227349653.02.0.43990744332.issue4153@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for noting this! The most basic changes had been done, but I had
to revise some sections for changes. Done in r67338.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Sat Nov 22 12:14:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Nov 2008 11:14:09 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227352449.55.0.746205111834.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems to have something to do with the current locale.
On OS X 10.4.11/PPC I have:

$ echo $LANG
C

and the test fails.  On OS X 10.5.5:

$ echo $LANG
en_GB.UTF-8

and test_cmd_line.py passes.  Moreover, after doing:

$ export LANG=C

test_cmd_line.py fails on OS X 10.5 too in the same way.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 13:37:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Nov 2008 12:37:18 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227357438.29.0.284317754629.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a minimal failing example, which I believe captures the cause of 
the test_cmd_line failure.  After "export LANG=C", on OS X 10.5, I get:

Python 3.0rc3+ (py3k:67335, Nov 22 2008, 09:11:58) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, posix
>>> sys.getfilesystemencoding()
'utf-8'
>>> posix.execv(sys.executable, [sys.executable, '-c', "ord('\xe9')"])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found

Clearly the single '\xe9' character is being encoded in utf8 as
b'\xc3\xa9', and the python interpreter invoked by the execv ends up 
receiving two characters here instead of one.

The encoding happens at around line 2988 of posixmodule.c, in posix_execv.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 13:45:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Nov 2008 12:45:44 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227357944.85.0.0492247317297.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not competent enough in this area to judge how serious this bug is, or 
determine what to do about it, but it seems as though it might potentially 
be a release blocker.

Martin, would you be able to take a look?

----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 13:51:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 12:51:17 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227358277.84.0.798496274957.issue4388@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There is some inconsistency in the conversions with the "command line":
- on input, sys.argv decodes with mbstowcs
- on output, os.system uses utf-8, os.execv uses the 
FileSystemDefaultEncoding.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 14:22:26 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 22 Nov 2008 13:22:26 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227360146.98.0.626350031692.issue3799@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

py3k patched with specify_open_encoding.diff passes test_dbm_dumb on my
Mac (Leopard, Intel).  Might as well assign this to Brett.  He seems to
be doing all the heavy lifting anyway. ;-)

Skip

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sat Nov 22 15:17:52 2008
From: report at bugs.python.org (Retro)
Date: Sat, 22 Nov 2008 14:17:52 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

The uninstaller program of the Python interpreter lacks an icon. This
looks ackward in the Add/Remove Programs list on the Windows platform.
Please add an icon for the uninstaller.

----------
components: None
messages: 76246
nosy: Retro
severity: normal
status: open
title: Uninstaller Lacks an Icon
versions: Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 15:21:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 14:21:39 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227363699.81.0.703126945224.issue4389@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 15:22:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 14:22:42 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227363762.17.0.462487772613.issue4389@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What specific release are you referring to?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 15:26:39 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 22 Nov 2008 14:26:39 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1227363999.9.0.396308420192.issue2628@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

An actual test suite for ftplib is now available.
Should we reconsider revamping this issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
_______________________________________

From report at bugs.python.org  Sat Nov 22 15:28:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Nov 2008 14:28:55 +0000
Subject: [issue4252] some missing links in html help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1227364135.97.0.966424802242.issue4252@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, I applied your latest patch as changeset 970452b02e2e. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________

From report at bugs.python.org  Sat Nov 22 16:20:31 2008
From: report at bugs.python.org (Retro)
Date: Sat, 22 Nov 2008 15:20:31 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227367231.38.0.571724770848.issue4389@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

As far as I know, the uninstaller has never had an icon, but it
certainly needs one. The upcoming versions of Python could be equipped
with a neat little icon. Are you willing to implement it? That would be
very nice.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 16:57:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 15:57:08 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227369428.49.0.131867297939.issue4389@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't quite reproduce the problem. Both on "Uninstall Python" in the
start menu, and in "Add and remove programs", Windows displays an icon,
showing a computer and a cdrom, atleast on Windows XP. So where are you
missing the icon?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 17:51:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 16:51:44 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1227372704.37.0.762924253521.issue4385@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think PyObject_HEAD_INIT should be removed.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Sat Nov 22 18:01:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 17:01:04 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227373264.1.0.0544518621628.issue4388@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The locale machinery on OSX is flaky. The question is what people really
pass for command line arguments. It would be useful to find out what
happens in these two cases:

1. Somebody runs "a.py ???????" in a Terminal.app window. Most likely,
the terminal encoding is applied, which we should assume to be UTF-8
(although it might be different on some systems).

2. Somebody creates a file japanese_????? in the finder, then uses
shell completion to pass this to a Python script. Here I expect that
UTF-8 is used even if the terminal's encoding is not UTF-8.

I don't know whether it's possible to launch Python scripts from Finder,
for given files, if so, it would also be interesting to find out what
encoding will be used there.

Without actual testing, I would assume that command line arguments are
typically encoded in UTF-8 on OSX. We should use that for argument
processing, regardless of mbstowcs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 18:01:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 17:01:28 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227373288.56.0.601295396954.issue4388@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 18:09:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Nov 2008 17:09:42 +0000
Subject: [issue3996] PyOS_CheckStack does not work
In-Reply-To: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>
Message-ID: <1227373782.88.0.791100603807.issue3996@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply it to all versions from 2.6 to 3.0.

----------
assignee: loewis -> amaury.forgeotdarc
nosy: +krisvale
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3996>
_______________________________________

From report at bugs.python.org  Sat Nov 22 19:41:21 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Nov 2008 18:41:21 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227379281.41.0.0299352496239.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like your conjectures are right in both cases.

I tried adding a few lines to Modules/python.c to print out the argv 
entries as byte strings, before they're passed to mbstowcs.  Results
on OS X 10.5:

> 1. Somebody runs "a.py ???????" in a Terminal.app window. Most likely,
> the terminal encoding is applied, which we should assume to be UTF-8
> (although it might be different on some systems).

Yes, it appears that the terminal encoding is applied, if I'm reading 
the results right.  Trying

./python.exe a.py ?

with the terminal character encoding set to "Unicode (UTF-8)", Python 
receives the third argument as bytes([195, 169]).  With the terminal 
encoding set to "Western (ISO Latin 1)" instead, Python receives
bytes([233]).

> 2. Somebody creates a file japanese_????? in the finder, then uses
> shell completion to pass this to a Python script. Here I expect that
> UTF-8 is used even if the terminal's encoding is not UTF-8.

Yes.  Python seems to receive the same string regardless of terminal 
encoding.  (With the terminal encoding set to latin1, the tab-completed 
filename looks like garbage within Terminal, of course.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 22 20:14:17 2008
From: report at bugs.python.org (Retro)
Date: Sat, 22 Nov 2008 19:14:17 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227381257.71.0.583965840679.issue4389@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Oh, I guess I should have been more informative, sorry. My OS is Windows
Vista Business (64 bit) onto which I have installed the 32 bit
interpreter. And now when this 32 bit interpreter is installed on my 64
bit OS platform, I don't see the two-snakes-kind-of-like icon in the
Add/Remove Programs list; instead I see the default icon -- you know,
that squared box. The files python.exe and pythonw.exe both have that
two-snakes-kind-of-like icon, and even pressing Alt+Tab (when the
interpreter is running) displays the two-snakes-kind-of-like icon, but
this two-snakes-kind-of-like icon is not displayed in the Add/Remove
Programs list. So I find that a strange thing to be.

Anyway, this is a bug so I reported it. I really don't know why this bug
exists. This could be because of a 64 bit OS and a 32 bit interpreter
mix issue, but I doubt it.

This is probably an easy fix for you guys. I keep my fingers crossed for
this bug to be fixed. Oh, and I can make screenshots if you like.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:07:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 20:07:21 +0000
Subject: [issue3996] PyOS_CheckStack does not work
In-Reply-To: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>
Message-ID: <1227384441.63.0.209723531252.issue3996@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r67343 (trunk) and r67344 (release26-maint)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3996>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:28:04 2008
From: report at bugs.python.org (Krzysztof Pawlik)
Date: Sat, 22 Nov 2008 20:28:04 +0000
Subject: [issue4390] Using subprocess.STDOUT causes AttributeError
In-Reply-To: <1227385684.57.0.612346460574.issue4390@psf.upfronthosting.co.za>
Message-ID: <1227385684.57.0.612346460574.issue4390@psf.upfronthosting.co.za>


New submission from Krzysztof Pawlik <krzysiek.pawlik at people.pl>:

Using stderr=subprocess.STDOUT causes Python 3.0 (RC1 from Ubuntu 8.10)
to raise AttributeError, important code snippet (whole test program
attached):

proc = subprocess.Popen(['whoami'], stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
stdout, stderr = proc.communicate()


nelchael at nelchael-vbox ~$ python2.5 --version
Python 2.5.2
nelchael at nelchael-vbox ~$ python2.5 test-subprocess.py
('stdout:', 'nelchael\n')
('stderr:', None)
nelchael at nelchael-vbox ~$ python3 --version
Python 3.0rc1+
nelchael at nelchael-vbox ~$ python3 test-subprocess.py
Traceback (most recent call last):
  File "test-subprocess.py", line 4, in <module>
    stdout, stderr = proc.communicate()
  File "/usr/lib/python3.0/subprocess.py", line 663, in communicate
    stdout = self._fo_read_no_intr(self.stdout)
AttributeError: 'Popen' object has no attribute '_fo_read_no_intr'
nelchael at nelchael-vbox ~$

----------
components: Library (Lib)
files: test-subprocess.py
messages: 76258
nosy: nelchael
severity: normal
status: open
title: Using subprocess.STDOUT causes AttributeError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12106/test-subprocess.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4390>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:47:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 20:47:15 +0000
Subject: [issue4390] Using subprocess.STDOUT causes AttributeError
In-Reply-To: <1227385684.57.0.612346460574.issue4390@psf.upfronthosting.co.za>
Message-ID: <1227386835.81.0.367657288509.issue4390@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This "_fo_read_no_intr" method does not exist anywhere in the standard 
python code.

A quick Google search reveals that it certainly comes from a patch 
proposed by the Ubuntu maintainers:
http://patches.ubuntu.com/p/python2.5/extracted/subprocess-eintr-
safety.dpatch

It is very likely that this patch (for 2.5) did not apply correctly to 
the 3.0 source code.
In any case, this is not a Python problem.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4390>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:44:28 2008
From: report at bugs.python.org (Dwayne Bailey)
Date: Sat, 22 Nov 2008 21:44:28 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>


New submission from Dwayne Bailey <dwayne+pythonbugs at translate.org.za>:

The following code in optparse:

            if len(rargs) < nargs:
                if nargs == 1:
                    self.error(_("%s option requires an argument") % opt)
                else:
                    self.error(_("%s option requires %d arguments")
                               % (opt, nargs))

works for languages with plurals of n!=1 but will not work for many
others that have more sophisticated plurals.

I've created a patch that handles missing gettext and implements it
correctly if it is available. Be aware that I have not been able to test
the patch.

----------
components: Library (Lib)
files: optparse_proper_gettext_plurals.diff
keywords: patch
messages: 76260
nosy: dwayne
severity: normal
status: open
title: optparse: use proper gettext plurals forms
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12107/optparse_proper_gettext_plurals.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:54:20 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 22 Nov 2008 21:54:20 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1227390860.87.0.26616359814.issue4391@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

And while at it, replace "usage" with "Use".
"Usage" isn't a word.

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:10:25 2008
From: report at bugs.python.org (Dwayne Bailey)
Date: Sat, 22 Nov 2008 22:10:25 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1227391825.96.0.557615317428.issue4391@psf.upfronthosting.co.za>


Dwayne Bailey <dwayne+pythonbugs at translate.org.za> added the comment:

Mmm some problems with my head late at night.  This patch sorts things
out and makes sure strings can be extracted by xgettext

Added file: http://bugs.python.org/file12108/optparse_proper_gettext_plurals.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:46:57 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 22 Nov 2008 22:46:57 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227394017.15.0.0381838400729.issue4388@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

The test was originally run with

% echo $LANG
tcsh: LANG: Undefined variable.

The same failure occurs with LANG set to C 

% env LANG=C ../Python-3.0rc3/python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
....
FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 151, in <module>
    test_main()
  File "Lib/test/test_cmd_line.py", line 147, in test_main
    test.support.run_unittest(CmdLineTest)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
698, in run_unittest
    _run_suite(suite)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
681, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0


But the test passes in both these cases:

% env LANG=en_US.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py
Lib/test/test_cmd_line.py
....
test_run_code (__main__.CmdLineTest) ... ok
....
OK


% env LANG=en_GB.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py
....
test_run_code (__main__.CmdLineTest) ... ok
....
OK

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 23 00:21:53 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 22 Nov 2008 23:21:53 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227396113.29.0.0799909036884.issue4388@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

The results from this script

  import os, sys
  print('Python %s' % sys.version.split()[0])
  print('env[LANG]: %s' % os.environ.get('LANG', '<not set>'))
  print('default encoding: %s' % sys.getdefaultencoding())
  print('filesystem encoding: %s' % sys.getfilesystemencoding())

are with Python 3.0:

Python 3.0rc3
env[LANG]: <not set>
default encoding: utf-8
filesystem encoding: utf-8

but for Python 2.3 thru 2.6:

Python 2.6
env[LANG]: <not set>
default encoding: ascii
filesystem encoding: utf-8

All with Python built from source on MacOS X 10.4.11 (Intel).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 23 08:17:11 2008
From: report at bugs.python.org (none_00)
Date: Sun, 23 Nov 2008 07:17:11 +0000
Subject: [issue4392] incorrect parameter name for collections.namedtuple
In-Reply-To: <1227424631.44.0.100708165737.issue4392@psf.upfronthosting.co.za>
Message-ID: <1227424631.44.0.100708165737.issue4392@psf.upfronthosting.co.za>


New submission from none_00 <nanikata at gmail.com>:

http://docs.python.org/library/collections.html#collections.namedtuple
it is stated that the second parameter to namedtuple 
is "fieldnames", while in reality it is "field_names"

----------
assignee: georg.brandl
components: Documentation
messages: 76265
nosy: georg.brandl, none_00
severity: normal
status: open
title: incorrect parameter name for collections.namedtuple
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4392>
_______________________________________

From report at bugs.python.org  Sun Nov 23 11:42:25 2008
From: report at bugs.python.org (Retro)
Date: Sun, 23 Nov 2008 10:42:25 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227436945.06.0.744227065654.issue4389@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

So are you willing to fix this issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sun Nov 23 13:28:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Nov 2008 12:28:26 +0000
Subject: [issue4393] Portability fixes in longobject.c
In-Reply-To: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za>
Message-ID: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

This patch fixes 3 classes of bugs in Objects/longobject.c:

(1) declarations of a variable (usually a counter into the digits of
a PyLong) as int instead of Py_ssize_t.
(2) missing (twodigits) casts from multiplies and shifts.
(3) use of '<<' on negative values in _PyLong_AsByteArray.  This
may lead to undefined behaviour, according to the C standards.  (See C99, 
section 6.5.7, paragraph 4).

These bugs haven't manifested themselves in practice.  For (1), there's 
only a problem when dealing with huge integers (more than 2**31 digits).   
The bugs in (2) can only affect platform where the C 'int' type has fewer 
than 32 bits.  (3) could potentially conflict with future compiler 
optimizations, but doesn't seem to be a problem right now.

For these reasons I don't think these fixes should be backported to 2.5.3.

----------
components: Interpreter Core
files: longobject_casts.patch
keywords: patch
messages: 76267
nosy: marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Portability fixes in longobject.c
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12109/longobject_casts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4393>
_______________________________________

From report at bugs.python.org  Sun Nov 23 15:58:32 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 23 Nov 2008 14:58:32 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Right now you HAVE to store a clear text password in .pypirc.

But this should not be necessary since the "register" command does a
getpass.getpass call to get the password from the prompt and use it to
authenticate to pypi.

So what do we miss ? 

We miss a bit of persistency for the upload command to get that password
when register + upload have been called in the same command line, typically:

$ python setup.py register sdist upload

this patch does it, and adds a test for it.

I am wondering though if upload wouldn't be better not to depend on a 
previous call to register (basically by adding a getpass.getpass call
there too), but this can be a second patch.

----------
components: Distutils
files: no_password.patch
keywords: patch
messages: 76268
nosy: tarek
severity: normal
status: open
title: make the storage of the password optional in .pypirc (using the prompt)
type: feature request
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12110/no_password.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Sun Nov 23 18:51:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 23 Nov 2008 17:51:05 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227462665.08.0.482302496789.issue4394@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

According to my tests, something is hosed with password saving in the
register command for 3.0 already: the saved password doesn't seem to be
used. Before this patch is considered, the other problem should be
resolved (but isn't yet reported to roundup, AFAICT).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Sun Nov 23 19:21:33 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Nov 2008 18:21:33 +0000
Subject: [issue4395] Document auto __ne__ generation
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.0c3 doc (Basic customization) says
"There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected. "

In http://mail.python.org/pipermail/python-ideas/2008-October/002235.html
Guido says
"I should also note that part of George's proposal has already been
implemented: if you define __eq__, you get a complementary __ne__ for
free. However it doesn't work the other way around (defining __ne__
doesn't give you __eq__ for free), and there is no similar
relationship for the ordering operators."

And indeed, as Arnaud Delobelle posted on python-list
class A:
    def __init__(self, x):
        self.x = x
    def __eq__(self, other):
        return self.x == other.x

a, b, c = A(1), A(1), A(2)
print(a==b, b==c, c==a) # True, False, False
print(a!=b, b!=c, c!=a) # False, True, True

Suggested revision:
"There is one implied relationship among comparison operators: defining
__eq__ gives an automatic __ne__ (but not the other way).  There is no
similar relationship for the order comparisons.

----------
assignee: georg.brandl
components: Documentation
messages: 76270
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document auto __ne__ generation
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sun Nov 23 20:07:08 2008
From: report at bugs.python.org (David Binger)
Date: Sun, 23 Nov 2008 19:07:08 +0000
Subject: [issue4396] parser module fails to validate "with" statements.
In-Reply-To: <1227467228.52.0.497056133571.issue4396@psf.upfronthosting.co.za>
Message-ID: <1227467228.52.0.497056133571.issue4396@psf.upfronthosting.co.za>


New submission from David Binger <davidbinger at mac.com>:

The parser module validates node trees when they are built from sequences.
The validator must, unfortunately, be updated every time there is a change
in the grammar.  The current validator fails to validate "with"
statements.  This bug probably exists in earlier versions of python
that support "with", but I haven't checked.

Here is a patch with a unit test for py3k.
Files involved: parsermodule.c, test_parser.py.

----------
components: Library (Lib)
files: parsewith.diff
keywords: patch
messages: 76271
nosy: dbinger
severity: normal
status: open
title: parser module fails to validate "with" statements.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12111/parsewith.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4396>
_______________________________________

From report at bugs.python.org  Sun Nov 23 20:17:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Nov 2008 19:17:37 +0000
Subject: [issue4392] incorrect parameter name for collections.namedtuple
In-Reply-To: <1227424631.44.0.100708165737.issue4392@psf.upfronthosting.co.za>
Message-ID: <1227467857.09.0.338712442703.issue4392@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r67355.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4392>
_______________________________________

From report at bugs.python.org  Sun Nov 23 20:26:02 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 23 Nov 2008 19:26:02 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227468362.07.0.586182620359.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I looked into the code and found these warnings about 'z' were
not from printf family but PyString_FromFormat.
Apparently PyString_FromFormat handles the 'z' itself, without
delegating that to printf family.
Then why am I getting these warnings?
I could remove these by using PY_FORMAT_SIZE_T,
but it's not for them, according to http://bugs.python.org/issue3743
and the source code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sun Nov 23 20:40:38 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 23 Nov 2008 19:40:38 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227469238.24.0.993457626803.issue4382@psf.upfronthosting.co.za>


Martina Oefelein <Martina at oefelein.de> added the comment:

Yes, the patch fixes the issue for me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Sun Nov 23 21:21:07 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Nov 2008 20:21:07 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1227471667.8.0.815998321893.issue4391@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:05:25 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 23 Nov 2008 21:05:25 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1227474325.58.0.340349342179.issue4073@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd like to see this in 3.0. It will help people porting to 3.0 better.

----------
assignee:  -> barry
nosy: +barry
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:29:10 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 23 Nov 2008 21:29:10 +0000
Subject: [issue4397] test_socket fails occassionaly in teardown:
	AssertionError: [Errno 57] Socket is not connected
In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
Message-ID: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_socket fails randomly in about 1 of 50 iterations (MacOS X 10.5.5 
intel):

$ for ((;;)); do DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-
3.0rc3: ./python.exe -E -bb ./Lib/test/regrtest.py -l test_socket;done
test_socket
1 test OK.

...

test_socket
test test_socket failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/test/test_socket.py", 
line 121, in _tearDown
    self.fail(msg)
AssertionError: [Errno 57] Socket is not connected

1 test failed:
    test_socket
test_socket
1 test OK.

...

----------
components: Library (Lib), Macintosh, Tests
messages: 76276
nosy: oefe
severity: normal
status: open
title: test_socket fails occassionaly in teardown: AssertionError: [Errno 57] Socket is not connected
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4397>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:44:07 2008
From: report at bugs.python.org (Derek Hval)
Date: Sun, 23 Nov 2008 21:44:07 +0000
Subject: [issue4398] erewer
Message-ID: <1227476646.49.0.778751244258.issue4398@psf.upfronthosting.co.za>


Changes by Derek Hval <der74hva3 at yahoo.com>:


----------
files: aa.html
nosy: der74hva3
severity: normal
status: open
title: erewer
type: compile error
Added file: http://bugs.python.org/file12112/aa.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4398>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:55:29 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 23 Nov 2008 21:55:29 +0000
Subject: [issue4399] "shard" appears where "shared" intended
In-Reply-To: <1227477329.38.0.775674135763.issue4399@psf.upfronthosting.co.za>
Message-ID: <1227477329.38.0.775674135763.issue4399@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/ctypes.html

insert "e" into "shard".

Errors have dissimilar importance.  The manual is so good that this is 
the worst I can find today.

----------
assignee: georg.brandl
components: Documentation
messages: 76277
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: "shard" appears where "shared" intended
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4399>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:57:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Nov 2008 21:57:41 +0000
Subject: [issue4399] "shard" appears where "shared" intended
In-Reply-To: <1227477329.38.0.775674135763.issue4399@psf.upfronthosting.co.za>
Message-ID: <1227477461.56.0.590398309932.issue4399@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r67359, thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4399>
_______________________________________

From report at bugs.python.org  Sun Nov 23 23:02:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 23 Nov 2008 22:02:21 +0000
Subject: [issue4398] erewer
Message-ID: <1227477741.78.0.642184775443.issue4398@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4398>
_______________________________________

From report at bugs.python.org  Sun Nov 23 23:52:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 23 Nov 2008 22:52:54 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227480774.6.0.131017183487.issue4370@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You receive these messages because PyString_FromFormat is declared with 
a special directive __attribute__(format(printf, 1, 2)).
Gcc then takes the format string as a regular printf format and 
validates it against the passed arguments.

You can safely ignore these warnings.
Maybe python should disable this __attribute__ for old compilers.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:32:22 2008
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 23 Nov 2008 23:32:22 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1227483142.77.0.583450298946.issue3926@psf.upfronthosting.co.za>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

Attached parts.zip -- a zip of updates for Python 2.6 and Python 3.0
against the current source [zip has two 

For Python 2.6:
py26/diff_py26.txt  -- differ against python26-maint tree
py26/PyShell.py     -- Replacement file for .../Lib/idlelib/PyShell.py
py26/run.py         -- Replacement file for .../Lib/idlelib/run.py

For Python 3.0:
py30/py3k_diff.txt  -- differ against python3k tree
py30/PyShell.py     -- Replacement file for .../Lib/idlelib/PyShell.py
py30/run.py         -- Replacement file for .../Lib/idlelib/run.py

Added file: http://bugs.python.org/file12113/parts.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:43:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2008 23:43:06 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227483786.27.0.622526317856.issue4006@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:44:46 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 23 Nov 2008 23:44:46 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227483886.26.0.914751909013.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

can you provide me a scenario to reproduce it ? 

-> did you have a .pypirc already with no password, or no .pypirc, etc..

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:49:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2008 23:49:00 +0000
Subject: [issue2433] Merge  audio modules
In-Reply-To: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
Message-ID: <1227484140.82.0.769531983038.issue2433@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

2.6 and 3.0rc3 are released. It's too late to change the standard 
library. So I prefer to close the bug. Reopen it if you want to work 
on that.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2433>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:52:27 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2008 23:52:27 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227484347.93.0.859706999527.issue1755388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't know how to fix the bug and it looks like nobody cares about 
it. So I prefer to close it. Reopen it if you get the same error.

Added file: http://bugs.python.org/file12114/hostname.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:52:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2008 23:52:40 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227484360.5.0.586194937501.issue1755388@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:09:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 00:09:15 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227485355.83.0.76382264915.issue4394@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is what I did:
1. I started with no pypirc
2. I ran register, it asked me for username, password
3. I chose to save it, it created a .pypirc
4. I ran register again, it asked me again for username, password, even
though this was saved already.

Looking at the code, it seems the problem is that the pypirc has a
section pypirc that lists the server, but the code reading it wants a
section distutils.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:39:04 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 24 Nov 2008 00:39:04 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227487144.79.0.506787980495.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I could reproduce it under 2.6, 

the problem is located at distutils.config.DEFAULT_PYPIRC

the default structure is wrong there, I'll add a ticket with a patch
and a test right away

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:54:46 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 24 Nov 2008 00:54:46 +0000
Subject: [issue4400] pypirc default is not at the right format
In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za>
Message-ID: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

when generated the default pypirc format is wrong, this patch fixes it
(could be backported in 2.6)

----------
components: Distutils
files: fix_pypirc_default.diff
keywords: patch
messages: 76286
nosy: tarek
severity: normal
status: open
title: pypirc default is not at the right format
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12115/fix_pypirc_default.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4400>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:55:42 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 24 Nov 2008 00:55:42 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227488142.71.0.893936938462.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok, I wrote a patch for the problem you mentioned in 

http://bugs.python.org/issue4400

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:59:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 00:59:17 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1227488357.87.0.501494241414.issue4194@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About Python3, os.popen() is more than two times faster (0.20 sec vs 
0.50 sec) than subprocess.Popen()! It's amazing because popen() opens 
the standard output as unicode file whereas Popen() creates a binary 
file! Another funny thing: os.popen() calls subprocess.Popen() :-) The 
difference is just this instruction:
   stdout = io.TextIOWrapper(stdout)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:08:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2008 01:08:40 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1227488920.26.0.904539595571.issue4073@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Review:

1. Since RefactoringTool no longer writes backup files, write_file
doesn't need to be overridden.

2. Don't worry about **kwds on log_error. It's not used at the moment.

3. It might be nice to let users pick which fixers they do or do not
want. Using only needed fixers can boost performance immensely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:24:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Nov 2008 01:24:51 +0000
Subject: [issue4401] os.extsep status? doc or os bug?
In-Reply-To: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za>
Message-ID: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.0c3 Manual (as with 2.x):
os.extsep 
The character which separates the base filename from the extension; for
example, the '.' in os.py. Also available via os.path.

3.0c3
>>> import os
>>> os.extsep
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'extsep'
>>> os.path.extsep
'.'

os.extsep apparently was present in 2.x
Mention of os.extsep was also present in 2.x docstring and removed in
3.0 docstring, so perhaps this was intentional, but it does not make
much sense, so I am provisionally marking this as a library bug.

----------
components: Library (Lib)
messages: 76290
nosy: tjreedy
severity: normal
status: open
title: os.extsep status? doc or os bug?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4401>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:30:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 01:30:34 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1227490234.24.0.850149076459.issue4194@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Summary of unchanged Python (2.4 .. 2.7):
 * Mac: subprocess is 25 .. 50 times SLOWER than os.popen
 * Solaris : subprocess is 13 times SLOWER than os.popen
 * Windows XP : subprocess is 1.5 times FASTER than os.popen
 * Linux : (results are very close)

With a different buffer size:
 * Solaris : Popen(bufsize=-1) is FASTER than os.popen()
 * Mac : Popen(bufsize=1) and Popen(bufsize=8192) are a little bit 
slower than os.popen(), but much FASTER than Popen(bufsize=0)

Notes:
 - PyFile_SetBufSize(bufsize) does nothing if bufsize < 0: keep system 
default (buffer of BUFSIZE bytes)
 - On Ubuntu Gutsy, system default (BUFSIZ) is 8192 bytes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:47:41 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Nov 2008 01:47:41 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1227491261.59.0.959745447264.issue4194@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

If anything for 2.6 lets just highlight this in the docs and mention
that bufsize needs to be set to non-zero for good performance on many
platforms such as Mac OS X and Solaris.

We can consider changing the default for 2.7/3.1.

3.x having poor performance is pretty much another issue entirely of its
own..

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:54:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Nov 2008 01:54:35 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1227491675.91.0.283752408237.issue2628@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

sure go for it, i haven't had time to look at the latest patch myself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:21:01 2008
From: report at bugs.python.org (=?utf-8?q?=E8=B5=B5=E7=8E=B0=E5=88=9A?=)
Date: Mon, 24 Nov 2008 02:21:01 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>


New submission from ??? <zhaolu8 at hotmail.com>:

I am using windows xp(sp3),chinese simplified.I found that in os 
module,os.getenv('PATH') return different result between python 2.5 and 
3.0rc3.py2.5's result is the same as the path command's result.

path command's result:
PATH=C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py2.5's result:
C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py3.0rc3's result:
C:\Python25\;C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...

you can see that python3.0 gets extra element "C:\Python25\",which is 
first. Is it a bug or something? thanks.

----------
components: Library (Lib)
files: path_result.txt
messages: 76294
nosy: clive
severity: normal
status: open
title: os.getenv('PATH')   return different result between 2.5 and 3.0rc3
versions: Python 3.0
Added file: http://bugs.python.org/file12116/path_result.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Mon Nov 24 04:59:04 2008
From: report at bugs.python.org (August Mueller)
Date: Mon, 24 Nov 2008 03:59:04 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>


New submission from August Mueller <gus at flyingmeat.com>:

smtplib requires that messages being sent be in ascii, and throws an exception otherwise.  
Python 2.6 doesn't require this.  Here's the diff where it was introduced:
http://svn.python.org/view/python/branches/py3k/Lib/smtplib.py?rev=59102&r1=58495&r2=59102

Is there a good reason for this?  I use python for a webstore, and send out emails for folks 
with multibyte names (for instance, if a name has an umlaut).

Here's a code snippit + exception:

Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 18:45:57) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> server = smtplib.SMTP("localhost")
>>> server.sendmail("gus at flyingmeat.com", "gus at flyingmeat.com", "?mlaut")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 713, in sendmail
    (code,resp) = self.data(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 481, in data
    self.send(q)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 305, in send
    s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode character '\xdc' in position 0: ordinal not in 
range(128)

Is there a workaround or a new way of using it?  I couldn't seem to find it.

Thanks!

----------
components: Library (Lib)
messages: 76295
nosy: ccgus
severity: normal
status: open
title: regression from 2.6: smtplib.py requiring ascii for sending messages
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Mon Nov 24 05:09:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2008 04:09:27 +0000
Subject: [issue4396] parser module fails to validate "with" statements.
In-Reply-To: <1227467228.52.0.497056133571.issue4396@psf.upfronthosting.co.za>
Message-ID: <1227499767.89.0.862779775756.issue4396@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! Fixed in r67365.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4396>
_______________________________________

From report at bugs.python.org  Mon Nov 24 05:34:50 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 04:34:50 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227501290.52.0.350705712381.issue4006@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Pardon, but when you close something as wontfix it's polite to say why.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 06:20:17 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 05:20:17 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1227504017.72.0.572888926453.issue1208304@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

I tried to repeat the test in http://bugs.python.org/msg60749 and found
that the descriptors will close if you read from the file before closing.

so this leads to open descriptors::

  import urllib2
  f = urllib2.urlopen('http://www.google.com')
  f.close()

while this does not::

  import urllib2
  f = urllib2.urlopen('http://www.google.com')
  f.read(1)
  f.close()

----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208304>
_______________________________________

From report at bugs.python.org  Mon Nov 24 06:44:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 05:44:36 +0000
Subject: [issue2433] Merge audio modules
In-Reply-To: <1227484140.82.0.769531983038.issue2433@psf.upfronthosting.co.za>
Message-ID: <bbaeab100811232144l6f52d111nb0d50275f9e3cc9a@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Nov 23, 2008 at 15:49, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> 2.6 and 3.0rc3 are released. It's too late to change the standard
> library. So I prefer to close the bug. Reopen it if you want to work
> on that.
>

It's not too late, just harder; new modules can always be added and
old ones deprecated. If Michael still wants to do this there is a
chance for it to go into the stdlib. But closing the bug is fine.

----------
title: Merge  audio modules -> Merge audio modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2433>
_______________________________________

From report at bugs.python.org  Mon Nov 24 06:47:09 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 05:47:09 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1227505629.05.0.803025680145.issue1208304@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

One further data point.   On two rhel5 systems with identical kernels,
both x86_64, both python-2.4.3... basically, everything I've thought to
check identical, I ran the test code with f.read() in an infinite loop.
 One system only has one TCP socket in use at a time.  The other one has
multiple TCP sockets in use, but they all close eventually.

/usr/sbin/lsof -p INTERPRETER_PID|wc -l reported 

96 67 97 63 91 62 94 78

on subsequent runs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208304>
_______________________________________

From report at bugs.python.org  Mon Nov 24 06:50:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 05:50:14 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <492A4091.8050800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is there a good reason for this?

Most definitely. In Python 2.x, the string literal denotes
a byte string, whereas in 3.x, it is a character string.
It's not possible to send a character string directly over
the network; try encoding it.

It might be considered a bug that sendmail accepts a string
at all as long as the string only consists of ASCII characters;
it should reject such strings as well.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Mon Nov 24 06:57:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 05:57:10 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1227501290.52.0.350705712381.issue4006@psf.upfronthosting.co.za>
Message-ID: <492A4233.4050102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Pardon, but when you close something as wontfix it's polite to say why.

Can you propose a reasonable way to fix this? People have thought hard,
and many days, and nobody could propose a reasonable fix. As 3.0 is
going to be released soon, there will be no way to fix it now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 07:26:30 2008
From: report at bugs.python.org (August Mueller)
Date: Mon, 24 Nov 2008 06:26:30 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1227507990.91.0.278631503331.issue4403@psf.upfronthosting.co.za>


August Mueller <gus at flyingmeat.com> added the comment:

Encoding the message first doesn't work either:

>>> import smtplib
>>> server = smtplib.SMTP("localhost")
>>> server.sendmail("gus at flyingmeat.com", "gus at flyingmeat.com", "?mlaut".encode("UTF-8"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 713, in sendmail
    (code,resp) = self.data(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 477, in data
    q = quotedata(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 157, in quotedata
    re.sub(r'(?:\r\n|\n|\r(?!\n))', CRLF, data))
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/re.py", line 165, in sub
    return _compile(pattern, 0).sub(repl, string, count)
TypeError: can't use a string pattern on a bytes-like object

Should a check be done in data() first, before it tries to try string operations on it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Mon Nov 24 07:40:39 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 06:40:39 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227508839.13.0.529572776917.issue4006@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Is it a bug?  If so, then it should be retargetted to 3.1 instead of
closed wontfix.  If it's not a bug then there should be an explanation
of why it's not a bug.

As for fixing it there are several inelegant methods that are better
than silently ignoring the problem:

1) return mixed unicode and byte types in os.environ
2) return only byte types in os.environ
3) raise an exception if someone attempts to access an environment
variable that cannot be decoded to unicode via the system encoding and
allow the value to be accessed as a byte string via another method.
4) silently ignore the non-decodable variables when accessing os.environ
the normal way but have another method of accessing it that returns all
values as byte strings.

#4 is closest to what was done with os.listdir().  However, I think that
approach is wrong for os.listdir() and os.environ because it leads to
code that works in simple testing but can start failing mysteriously
when it becomes used in more environments.  The os.listdir() method will
lead to lots of people having to write code that uses the byte methods
on Unix and does its own conversion because it's the only thing
guaranteed to work on Unix and the unicode methods on Windows because
it's the only thing guaranteed to work there.  It degenerates to case #2
except harder to debug and requiring more platform specific knowledge of
the programmer.

#3 seems like the best choice to me as it provides a way for the
programmer to discover what's wrong and provide a fix but people seem to
have learned the wrong lessons from the python2 UnicodeEncode/Decode
problems so that might not have a large following other than me....

#2 is conceptually correct since environment variables are a point where
you're receiving bytes from a non-python environment.  However, it's
very annoying for the common case where everything in the environment
has a single encoding.

#1 is the easiest for simplistic code to deal with but seems to violate
the python3 philosophy the most.  I don't like it as it takes us to one
of the real failings of python2's unicode handling: Not knowing what
type of data you're going to get back from a method and therefore not
knowing if you have to convert it before passing it on.  Please don't do
this one as it's two steps forward and one step backwards from where we
are now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 07:52:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 06:52:46 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1227508839.13.0.529572776917.issue4006@psf.upfronthosting.co.za>
Message-ID: <492A4F3B.7010909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is it a bug?

It's not a bug; see my original reply. This case is just not supported.

It may be supported in future versions, but (if it was for me) not
without a PEP first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 07:59:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 06:59:21 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1227509961.75.0.902502107054.issue4403@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. It seems Python 3.0 just won't support that usage, then.

You still should be able to use MIME to send non-ASCII characters.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Mon Nov 24 08:00:56 2008
From: report at bugs.python.org (steve21)
Date: Mon, 24 Nov 2008 07:00:56 +0000
Subject: [issue4404] os.listdir() documentation error
In-Reply-To: <1227510056.52.0.380285272246.issue4404@psf.upfronthosting.co.za>
Message-ID: <1227510056.52.0.380285272246.issue4404@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

The documentation entry for os.listdir(path) at
 html docs at http://docs.python.org/dev/3.0/library/os.html#module-os
says:

"os.listdir(path)
   Return a list containing the names of the entries in the directory.
The list is in arbitrary order. It does not include the special entries
. and .. even if they are present in the directory. Availability: Unix,
Windows.

    This function can be called with a bytes or string argument. In the
bytes case, all filenames will be listed as returned by the underlying
API. In the string case, filenames will be decoded using the file system
encoding, and skipped if a decoding error occurs."

The problem is that nowhere it the above documentation does it describe
what the 'path' argument should be !

However, if I do
$ Python3.0
>>> import os
>>> help(os.listdir)   # it does describe 'path'
Help on built-in function listdir in module posix:

listdir(...)
    listdir(path) -> list_of_strings

    Return a list containing the names of the entries in the directory.

            path: path of directory to list

    The list is in arbitrary order.  It does not include the special
    entries '.' and '..' even if they are present in the directory.


It looks like the html docs are missing some information and out of sync
with the module docs.

----------
assignee: georg.brandl
components: Documentation
messages: 76307
nosy: georg.brandl, steve21
severity: normal
status: open
title: os.listdir() documentation error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4404>
_______________________________________

From report at bugs.python.org  Mon Nov 24 08:07:12 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 07:07:12 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227510432.17.0.97541109132.issue4006@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

I'm sorry but "For the moment, this case is just not supported." is not
an explanation of why this is not a bug.  It is a statement that the
interpreter cannot handle a situation that has arisen.

If you said, "We don't believe that any computer has mixed encodings
that can show up in environment variables" that would be an explanation
of why this is not a bug and I could then give counter-examples of
computers that have mixed encodings in their environment variables.  So
what's the reason this is not a bug?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 08:39:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 07:39:46 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1227510432.17.0.97541109132.issue4006@psf.upfronthosting.co.za>
Message-ID: <492A5A40.7070903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Toshio Kuratomi wrote:
> So what's the reason this is not a bug?

It's a bug only if the implementation deviates from the specification.
In this case, it does not. The behavior is intentional: python
deliberately drops environment variables it cannot represent as a
string. We know that such environment variables can happen in real
life - that's why they get dropped (rather than raising an exception
at startup).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:00:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2008 09:00:33 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227517233.27.0.809676247073.issue4402@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I cannot reproduce this. Python does not modify the environment variables.
How did you exactly start the python interpreters, 2.5 and 3.0?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:02:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 09:02:06 +0000
Subject: [issue4405] fix_metaclass broken
In-Reply-To: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
Message-ID: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When trying to run 2to3 on Django, I get a traceback

  File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 260, in
refactor_string
    self.refactor_tree(tree, name)
  File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 299, in
refactor_tree
    self.traverse_by(self.post_order, tree.post_order())
  File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 323, in
traverse_by
    new = fixer.transform(node, results)
  File "/tmp/py3/lib/python3.0/lib2to3/fixes/fix_metaclass.py", line
156, in transform
    for suite, i, stmt in find_metas(node):
  File "/tmp/py3/lib/python3.0/lib2to3/fixes/fix_metaclass.py", line
114, in find_metas
    if leaf_node.value == '__metaclass__':
AttributeError: 'Node' object has no attribute 'value'

The smallest example reproducing this is

class Model(object):
    __metaclass__ = ModelBase
    save.alters_data = True

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76311
nosy: loewis
severity: normal
status: open
title: fix_metaclass broken
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:14:39 2008
From: report at bugs.python.org (lion.guo)
Date: Mon, 24 Nov 2008 09:14:39 +0000
Subject: [issue4406] In Lib\tkinter\filedialog.py,
	class Directory define loss a"_"
In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
Message-ID: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>


New submission from lion.guo <lion.guo at gmail.com>:

In Lib\tkinter\filedialog.py, class Directory 

"class Directory(Dialog):"
 should be 

"class Directory(_Dialog):"

----------
components: Tests
messages: 76312
nosy: lion.guo
severity: normal
status: open
title: In Lib\tkinter\filedialog.py, class Directory define loss a"_"
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4406>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:17:16 2008
From: report at bugs.python.org (lion.guo)
Date: Mon, 24 Nov 2008 09:17:16 +0000
Subject: [issue4406] In Lib\tkinter\filedialog.py,
	class Directory define loss a"_"
In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
Message-ID: <1227518236.69.0.382276282806.issue4406@psf.upfronthosting.co.za>


Changes by lion.guo <lion.guo at gmail.com>:


----------
components: +Library (Lib) -Tests
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4406>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:25:39 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 24 Nov 2008 09:25:39 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227518739.05.0.871721754861.issue1755388@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I think that closing it as wontfix is not the proper thing to do. It 
is a real bug; closing it will hide it from anybody that could 
potentially fix it. Also it won't appear on bug listings unless you 
explicitely ask for closed ones. 

Setting the right categories might help.

----------
components: +Interpreter Core -Extension Modules
type:  -> behavior
versions: +Python 2.6, Python 3.0 -Python 2.5
Added file: http://bugs.python.org/file12117/bug1755388.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Mon Nov 24 10:34:41 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 24 Nov 2008 09:34:41 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227519281.22.0.32979368691.issue1755388@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:01:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 10:01:17 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227520877.29.0.814805356882.issue1755388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@gagenellina: It's a bug! Python does raise a KeyboardInterrupt 
exception, but too late. The exception is raised during the 
gethostbyaddr() so I expect to get a KeyboardInterrupt just after 
gethostbyaddr().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:05:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 10:05:44 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227521144.28.0.543032545584.issue4006@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@a.badger: The behaviour (drop non encodable strings) is not really a 
problem if you configure correctly your program and computer. Eg. you 
spoke about CGI-WSGI: if your website also speak UTF-8, you will be 
able to read all environment variables. So this issue is not 
important, it only appears when your website/OS is not well 
configured. I mean the problem is not in Python but outside Python. 
The PATH variable contains directory names, if you have only names 
encodable in your filesystem encoding (UTF-8 most of the time), you 
will be able to use the PATH variable. If a directory has an non 
decodable name, rename the directory but don't try to fix Python!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:19:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 10:19:39 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1227508839.13.0.529572776917.issue4006@psf.upfronthosting.co.za>
Message-ID: <200811241118.02365.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug tracker is maybe not the right place to discuss a new Python3 feature.

> 1) return mixed unicode and byte types in os.environ

One goal of Python3 was to avoid mixing bytes and characters (bytes/str).

> 2) return only byte types in os.environ

os.environ contains text (characters) and so should decoded as unicode.

> 3) raise an exception if someone attempts to access an environment
> variable that cannot be decoded to unicode via the system encoding and
> allow the value to be accessed as a byte string via another method.
> 4) silently ignore the non-decodable variables when accessing os.environ
> the normal way but have another method of accessing it that returns all
> values as byte strings.

Why not for (3). But what would be the "another method" (4) to access byte 
string? The problem of having two methods is that you need consistent 
objects.

Imagine that you have os.environ (unicode) and os.environb (bytes).

Example 1:
  os.environb['PATH'] = b'\xff\xff\xff\xff'
What is the value in os.environ['PATH']?

Example 2:
  os.environb['PATH'] = b't?st'
What is the value in os.environ['PATH']?

Example 3:
  os.environ['PATH'] = 't?st'
What is the value in os.environb['PATH']?

Example 4:
 should I use os.environ['PATH'] or os.environb['PATH'] to get the current
 PATH?

It introduces many new cases (bugs?) that have to be prepared and tested. If 
you are motivated, you can contribute by a patch to test your ideas ;-) I'm 
interrested by os.environb, but as I wrote, I expect new complex problems :-/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:13:42 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 11:13:42 +0000
Subject: [issue4406] In Lib\tkinter\filedialog.py,
	class Directory define loss a"_"
In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
Message-ID: <1227525222.77.0.188490538754.issue4406@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Actually it should be commondialog.Dialog

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file12118/Directory_fix_subclass.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4406>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:15:13 2008
From: report at bugs.python.org (Eric Devolder)
Date: Mon, 24 Nov 2008 11:15:13 +0000
Subject: [issue4407] Windows Installer Error 1722 when opting for compilation
	at install time
In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
Message-ID: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>


New submission from Eric Devolder <eric.devolder at gmail.com>:

This error happens when opting in for compiling the scripts at
installation. (please note also that I did not selected "register
extension", but I don't think this has an impact).

Here is the text from event viewer:

Product: Python 3.0rc3 -- Error 1722. There is a problem with this
Windows Installer package. A program run as part of the setup did not
finish as expected. Contact your support personnel or package vendor. 
Action CompilePyc, location: L:\Python30\python.exe, command: -Wi
"L:\Python30\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "L:\Python30\Lib" 

Running the command manually indeed crashes, because of pipe symbol
being interpretted at shell level, not Python.

Please find attached a patch on Tools\msi\msi.py that addresses the
problem (untested, I don't have VStudio )

----------
components: Installation
files: compileall_py.patch
keywords: patch
messages: 76318
nosy: keldonin
severity: normal
status: open
title: Windows Installer Error 1722 when opting for compilation at install time
versions: Python 3.0
Added file: http://bugs.python.org/file12119/compileall_py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:16:44 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 11:16:44 +0000
Subject: [issue4406] In Lib\tkinter\filedialog.py,
	class Directory define loss a"_"
In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
Message-ID: <1227525404.18.0.723583731544.issue4406@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

It is important to commit this actually, since right now
tkinter.filedialog.Directory is pretty broken but also very simple to fix.

----------
components: +Tkinter -Library (Lib)
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4406>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:23:59 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 11:23:59 +0000
Subject: [issue775309] button methods tkButtonDown, etc don't work
Message-ID: <1227525839.31.0.140357446505.issue775309@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

There is a more general patch on issue4350 now

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775309>
_______________________________________

From report at bugs.python.org  Mon Nov 24 13:16:11 2008
From: report at bugs.python.org (Florian Weimer)
Date: Mon, 24 Nov 2008 12:16:11 +0000
Subject: [issue4408] re.compile(regexp).groups not documented
In-Reply-To: <1227528971.48.0.179981852127.issue4408@psf.upfronthosting.co.za>
Message-ID: <1227528971.48.0.179981852127.issue4408@psf.upfronthosting.co.za>


New submission from Florian Weimer <fw at deneb.enyo.de>:

This does result in the expected result 2:

> re.compile('(.)(.)').groups

But as far as I can see, the groups property is missing from the HTML
documentation.  Please clarify if this an internal interface, or a
documentation oversight.

----------
components: Regular Expressions
messages: 76321
nosy: fw
severity: normal
status: open
title: re.compile(regexp).groups not documented
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4408>
_______________________________________

From report at bugs.python.org  Mon Nov 24 13:34:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 12:34:37 +0000
Subject: [issue1532] Refleak run of test_tcl fails
In-Reply-To: <1196464643.1.0.5780121191.issue1532@psf.upfronthosting.co.za>
Message-ID: <1227530077.15.0.158723906994.issue1532@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Disable it while running regrtest with -R ?

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file12120/disable_testLoadTkFailure_in_regrtest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1532>
_______________________________________

From report at bugs.python.org  Mon Nov 24 13:53:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2008 12:53:12 +0000
Subject: [issue4405] fix_metaclass broken
In-Reply-To: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
Message-ID: <1227531192.14.0.327897785075.issue4405@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________

From report at bugs.python.org  Mon Nov 24 14:36:02 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 13:36:02 +0000
Subject: [issue1191726] about shift key
Message-ID: <1227533762.11.0.639733666591.issue1191726@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can reproduce this under windows vista with tk8.4 and tk8.5, but the
problem doesn't show up in Linux and it is not tkinter fault either.

----------
nosy: +gpolo
Added file: http://bugs.python.org/file12121/issue1191726.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191726>
_______________________________________

From report at bugs.python.org  Mon Nov 24 14:36:10 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 13:36:10 +0000
Subject: [issue1191726] about shift key
Message-ID: <1227533770.11.0.296758482653.issue1191726@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Added file: http://bugs.python.org/file12122/test1.tcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191726>
_______________________________________

From report at bugs.python.org  Mon Nov 24 14:38:41 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 24 Nov 2008 13:38:41 +0000
Subject: [issue1191726] about shift key
Message-ID: <1227533921.46.0.229901145372.issue1191726@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191726>
_______________________________________

From report at bugs.python.org  Mon Nov 24 15:04:49 2008
From: report at bugs.python.org (David Fraser)
Date: Mon, 24 Nov 2008 14:04:49 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1226711729.86.0.312684878446.issue2736@psf.upfronthosting.co.za>
Message-ID: <667436787.107671227518475401.JavaMail.root@klofta.sjsoft.com>


David Fraser <davidf at sjsoft.com> added the comment:

----- "Alexander Belopolsky" <report at bugs.python.org> wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the
> comment:
> 
> I would like to voice my opposition the totimestamp method.
> 
> Representing time as a float is a really bad idea (originated at 
> Microsoft as I have heard).  In addition to the usual numeric problems
> when dealing with the floating point, the resolution of the floating 
> point timestamp varies from year to year making it impossible to 
> represent high resolution historical data.
> 
> In my opinion both time.time() returning float and 
> datetime.fromtimestamp() taking a float are both design mistakes and 
> adding totimestamp that produces a float will further promote a bad 
> practice.

The point for me is that having to interact with Microsoft systems that require times means that the conversions have to be done. Is it better to have everybody re-implement this, with their own bugs, or to have a standard implementation? I think it's clearly better to have it as a method on the object. Of course, we should put docs in describing the pitfalls of this approach...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:11:57 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 24 Nov 2008 15:11:57 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <1227488357.87.0.501494241414.issue4194@psf.upfronthosting.co.za>
Message-ID: <18730.50224.580059.974146@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Victor> About Python3, os.popen() is more than two times faster (0.20
    Victor> sec vs 0.50 sec) than subprocess.Popen()! It's amazing because
    Victor> popen() opens the standard output as unicode file whereas
    Victor> Popen() creates a binary file! Another funny thing: os.popen()
    Victor> calls subprocess.Popen() :-) The difference is just this
    Victor> instruction:
    Victor>    stdout = io.TextIOWrapper(stdout)

This is a known issue.  The default for bufsize in os.popen is -1 (fully
buffered? line buffered?).  The default for bufsize in subprocess.Popen is 0
(unbuffered).  I think it should have been changed but was voted down.  I
think the best you can do at this point is document the change, perhaps in
the "Replacing os.popen" section.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:16:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 24 Nov 2008 15:16:45 +0000
Subject: [issue4409] Dangling asterisks in Python 3.0 subprocess docs
In-Reply-To: <18730.50503.956524.686132@montanaro-dyndns-org.local>
Message-ID: <18730.50503.956524.686132@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

Georg,

I just noticed that there are asterisks in a couple places in the subprocess
module documentation which don't appear to have corresponding footnotes.
All the way at the bottom are subsections called

    Replacing os.spawn*    
    Replacing os.popen*

I don't know what the '*' is supposed to mean, but in normal usage it would
tell the user there is a footnote which elaborates on something related to
that text.  I don't see any such footnotes.  Oh, wait a minute.  You
probably mean for them to be wildcards.  Hmmm...  Probably not the best
usage.  Can you find a different way to indicate that those examples refer
to a larger category of functions?

Skip

----------
messages: 76326
nosy: skip.montanaro
severity: normal
status: open
title: Dangling asterisks in Python 3.0 subprocess docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4409>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:17:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2008 15:17:38 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <667436787.107671227518475401.JavaMail.root@klofta.sjsoft.com>
Message-ID: <d38f5330811240717w552c8eecle8768e29d619190b@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 24, 2008 at 9:04 AM, David Fraser <report at bugs.python.org> wrote:
...
> The point for me is that having to interact with Microsoft systems that require times means that the conversions have to be done.

I did not see the "epoch" proposal as an interoperability with
Microsoft systems feature.  If this is the goal, a deeper analysis of
the Microsoft standards is in order.  For example, what is the valid
range of the floating point timestamp?  What is the range for which
fromepoch (float to datetime) translation is valid?  For example, if
all floats are valid timestamps, then fromepoch can be limited to +/-
2**31 or to a smaller range where a float has enough precision to
roundtrip microseconds.

> Is it better to have everybody re-implement this, with their own bugs, or to have a standard implementation?

As far as I know, interoperability with Microsoft systems requires
re-implementation of their bugs many of which are not documented.  For
example, OOXML requires that 1900 be treated as a leap year at least
in some cases.  When you write your own implementation, at least you
have the source code to your own bugs.

> I think it's clearly better to have it as a method on the object. Of course, we should put docs in describing the pitfalls of this approach...

Yes, having a well documented high resolution "time since epoch" to
"local datetime" method in the datetime module is helpful if
non-trivial timezones (such as the one Victor lives in) are supported.
 However, introducing floating point pitfalls into the already
overcomplicated realm of calendar calculations would be a mistake.

I believe the correct approach would be to extend fromtimestamp (and
utcfromtimestamp) to accept a (seconds, microseconds) tuple as an
alternative (and in addition) to the float timestamp.  Then
totimestamp can be implemented to return such tuple that
fromtimestamp(totimestamp(dt) == dt for any datetime dt and
totimestamp(fromtimestamp((s,us))) == (s, us) for any s and us within
datetime valid range (note that s will have to be a long integer to
achieve that).

In addition exposing the system gettimeofday in the time module to
produce (s, us) tuples may be helpful to move away from float
timestamps produced by time.time(), but with totimestamp as proposed
above that would be equivalent to datetime.now().totimestamp().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:32:24 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 15:32:24 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18730.50224.580059.974146@montanaro-dyndns-org.local>
Message-ID: <200811241630.17769.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor> About Python3, os.popen() is more than two times faster (...)
> Victor> The difference is just this instruction:
> Victor>    stdout = io.TextIOWrapper(stdout)
>
> This is a known issue.  The default for bufsize in os.popen is -1 (fully
> buffered? line buffered?).  The default for bufsize in subprocess.Popen is
> 0 (unbuffered).

Wrong, it's not related to the buffer size.

With Python3 trunk on Linux, os.popen time is ~0.10 sec whereas 
subprocess.Popen is ~0.25 sec. Change the buffer size of subprocess doesn't 
help:
 - (default) 0.25
 - buffering = (-1):  0.25
 - buffering = 1:     0.25
 - buffering = 8192:  0.26
 - buffering = 16384: 0.26
(it's a little big slower with a bigger buffer...)

You get the same speed (than os.popen) using TextIOWrapper() adapter:
  [i for i in read_handle] => 0.25 sec
  [i for i in io.TextIOWrapper(read_handle)] => 0.10 sec

WTF? Unicode is *FASTER* than raw bytes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:46:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 15:46:12 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1227541572.07.0.410587004811.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the timestamp, there are many formats:

(a) UNIX: 32 bits signed integer, number of seconds since the 1st 
january 1970. 
 - file format: gzip header, Portable Executable (PE, Windows), 
compiled python script header (.pyc/.pyo)
 - file system: ext2 and ext3

(b) UNIX64: 64 bits signed integer, number of seconds since the 1st 
january 1970
 - file format: Gnome keyring

(c) UNIX: 32 bits unsigned integer, number of seconds since the 1st 
january 1904
 - file format: True Type Font (.ttf), iTunes database, AIFF, .MOV

(d) UUID60: 60 bits unsigned integer, number of 1/10 microseconds 
since the 15st october 1582
 - all formats using UUID version 1 (also known as "GUID" in the 
Microsoft world)

(e) Win64: 64 bits unsigned integer, number of 1/10 microseconds since 
the 1st january 1601
 - file format: Microsoft Office documents (.doc, .xls, etc), ASF 
video (.asf), Windows link (.lnk)
 - file system: NTFS

(f) MSDOS DateTime or TimeDate: bitfield with 16 bits for the date and 
16 bits for the time. Time precision is 2 seconds, year is in range 
[1980; 2107]
 - file format: Windows link (.lnk), CAB archive (.cab), Word document 
(.doc), ACE archive (.ace), ZIP archive (.zip), RAR achive (.rar)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:52:00 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 15:52:00 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227541920.31.0.085782862438.issue4006@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

'''
@a.badger: The behaviour (drop non encodable strings) is not really a 
problem if you configure correctly your program and computer. Eg. you 
spoke about CGI-WSGI: if your website also speak UTF-8, you will be 
able to read all environment variables. So this issue is not 
important, it only appears when your website/OS is not well 
configured. I mean the problem is not in Python but outside Python. 
The PATH variable contains directory names, if you have only names 
encodable in your filesystem encoding (UTF-8 most of the time), you 
will be able to use the PATH variable. If a directory has an non 
decodable name, rename the directory but don't try to fix Python!
'''

The idea that having mixed encodings on a system is a misconfiguration 
is a fallacy.

1) In a multiuser setup, each user has a choice of what encoding to use.
 So mixed encodings are both possible and valid.

2) In a legacy system, your operating system may have all utf-8 naming
for the core OS but all of the old data files is being mounted with
another encoding that the legacy programs on the host expect.

3) On an nfs mount, data may come from users on different machines from
widely separated areas using different system encodings.

4) The same thing as 1-3 but applied to any of the data a site may be
passing via an environment variable rather than just file and directory
names.

5) An application may have to deal with different encodings from the
system default due to limitations of another program.  Since one of
python's many uses is as a glue language, it needs to be able to deal
with these quirks.

6) The application you're interfacing may just be using bytes rather
than text in the environment variables.

Let me put it this way:

If I write a file in a latin-1 encoding and put it on my system that has
a utf-8 system encoding what does python-3 do?

1) If I try to open it as a text file: "open('filename', 'r')" it throws
a UnicodeDecodeError when I attempt to read some non-utf-8 characters
from it.

2) As a programmer I then know to open it as binary "open('filename',
'rb')" and do my own decoding of the data now that I've been made aware
that I must take this corner case into account.

Some notes:
1) This seems to be the right general procedure to take when handling
things that are usually text but can contain arbitrary bytes.

2) This makes use of python's exception infrastructure to tell the
programmer plainly what's going wrong instead of silently ignoring
values that the programmer may not have encountered in their test data
but could exist in the real world.  Would you rather get a bug report
from a user that says: "FooApp gives me a UnicodeDecodeError traceback
pointing at line 345" (how open() works) or "FooApp never authenticates
me" (which you then have to track down to the fact that the credentials
on the user's system are being passed in an env var and are not in the
system encoding.)

3) This learns the correct lesson from python-2's unicode problems: Stop
the mixture of bytes and unicode at the border so the programmer can be
explicit about how to deal with the odd-ball data there.  It does not
become squeamish about throwing a Unicode Exception which is the wrong
lesson to learn from python-2.

4) It also doesn't refuse to acknowledge that the world outside python
is not as simple and elegant as the world inside python and allows the
programmer to write an interface to that world instead of forcing them
to go outside of python to deal with it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:00:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 16:00:40 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1227542440.99.0.0648873880972.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Timedelta formats:

(a) Win64: 64 bits unsigned integer, number of 1/10 microsecond
 - file format: Microsoft Word document (.doc), ASF video (.asf)

(b) 64 bits float, number of seconds
 - file format: AMF metadata used in Flash video (.flv)

Other file formats use multiple numbers to store a duration:

[AVI video]
 - 3 integers (32 bits unsigned): length, rate, scale
 - seconds = length / (rate / scale) 
 - (seconds = length * scale / rate)

[WAV audio]
 - 2 integers (32 bits unsigned): us_per_frame, total_frame
 - seconds = total_frame * (1000000 / us_per_frame)

[Ogg Vorbis]
 - 2 integers: sample_rate (32 bits unsigned), position (64 bits 
unsigned)
 - seconds = position / sample_rate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:14:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2008 16:14:29 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1227542440.99.0.0648873880972.issue2736@psf.upfronthosting.co.za>
Message-ID: <d38f5330811240814y8faf5cbs86e8c2f08ed95032@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

That's an impressive summary, but what is your conclusion?  I don't
see any format that will benefit from a subsecond
timedelta.totimestamp().  Your examples have either multisecond or
submicrosecond resolution.

On Mon, Nov 24, 2008 at 11:00 AM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Timedelta formats:
>
> (a) Win64: 64 bits unsigned integer, number of 1/10 microsecond
>  - file format: Microsoft Word document (.doc), ASF video (.asf)
>
> (b) 64 bits float, number of seconds
>  - file format: AMF metadata used in Flash video (.flv)
>
> Other file formats use multiple numbers to store a duration:
>
> [AVI video]
>  - 3 integers (32 bits unsigned): length, rate, scale
>  - seconds = length / (rate / scale)
>  - (seconds = length * scale / rate)
>
> [WAV audio]
>  - 2 integers (32 bits unsigned): us_per_frame, total_frame
>  - seconds = total_frame * (1000000 / us_per_frame)
>
> [Ogg Vorbis]
>  - 2 integers: sample_rate (32 bits unsigned), position (64 bits
> unsigned)
>  - seconds = position / sample_rate
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2736>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:15:46 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Nov 2008 16:15:46 +0000
Subject: [issue4401] os.extsep status? doc or os bug?
In-Reply-To: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za>
Message-ID: <1227543346.74.0.447224875257.issue4401@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For more information: in 3.0, os.curdir, os.pardir, os.sep, os.altsep,
os.pathsep, os.defpath, and os.devnull are also in os.path. Only
os.extset was removed from os. Among the sysinfo constants, only
os.linesep was not in os.path.  I think either all names or none should
be duplicated.

The doc for os.path begins "This module implements some useful functions
on pathnames".  The duplication of the sysinfo constants is not
mentioned!  (Though perhaps is should be "Also, as a convenience, the
system information constants from os are available here also.")  So if
they are only in one place, it should be os, not os.path.

In any case, the removal of extpath and only that from os is gratuitous
breakage.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4401>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:18:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Nov 2008 16:18:58 +0000
Subject: [issue4409] Dangling asterisks in Python 3.0 subprocess docs
In-Reply-To: <18730.50503.956524.686132@montanaro-dyndns-org.local>
Message-ID: <1227543538.53.0.0391492361235.issue4409@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4409>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:21:23 2008
From: report at bugs.python.org (David Binger)
Date: Mon, 24 Nov 2008 16:21:23 +0000
Subject: [issue4396] parser module fails to validate "with" statements.
In-Reply-To: <1227499767.89.0.862779775756.issue4396@psf.upfronthosting.co.za>
Message-ID: <700EEB76-9460-4E60-B84E-0860BBDAF4AB@mac.com>


David Binger <davidbinger at mac.com> added the comment:

Thanks, Benjamin.

I see that you applied this to the main python branch,
which is probably okay (though I haven't tested it),
but I wrote the patch against the py3k code.
Did you mean to apply it to py3k?

On Nov 23, 2008, at 11:09 PM, Benjamin Peterson wrote:

>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Thanks for the patch! Fixed in r67365.
>
> ----------
> nosy: +benjamin.peterson
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4396>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4396>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:22:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2008 16:22:07 +0000
Subject: [issue4396] parser module fails to validate "with" statements.
In-Reply-To: <700EEB76-9460-4E60-B84E-0860BBDAF4AB@mac.com>
Message-ID: <1afaf6160811240822r1076b611weae20e52a54452aa@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Mon, Nov 24, 2008 at 10:21 AM, David Binger <report at bugs.python.org> wrote:
>
> David Binger <davidbinger at mac.com> added the comment:
>
> Thanks, Benjamin.
>
> I see that you applied this to the main python branch,
> which is probably okay (though I haven't tested it),
> but I wrote the patch against the py3k code.
> Did you mean to apply it to py3k?

Yes, I applied it to the trunk because it was a problem there, too. It
will be merged into py3k eventually.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4396>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:44:14 2008
From: report at bugs.python.org (Jonathan)
Date: Mon, 24 Nov 2008 16:44:14 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1227545054.48.0.788437997966.issue2628@psf.upfronthosting.co.za>


Jonathan <jbell at scrippsweb.com> added the comment:

Yeah, I'm glad to see a test suite. I've only skimmed the test, but it
seems like an excellent starting point. Initial thoughts for updating
the tests:
- Need a cmd_mode to handle the MODE command.
- Suite cmd_retr logic needs to keep dtp connection open and write a
simple header depending on MODE.

Due to the Thanksgiving holiday, I may be without network access (or
time) until next week, however.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:49:17 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 24 Nov 2008 16:49:17 +0000
Subject: [issue4006] os.getenv silently discards env variables with non-UTF-8
	values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1227545357.26.0.0820598869666.issue4006@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

> The bug tracker is maybe not the right place to discuss a new Python3
feature.

It's a bug!  But if you guys want it to be a feature, then what mailing
list do I need to join?  Is there one devoted to Unicode or is
python-dev where I need to go?

>> 1) return mixed unicode and byte types in os.environ
>One goal of Python3 was to avoid mixing bytes and characters (bytes/str).

As stated, in my evaluation of the four options, +1 to this, option #1 takes
us back to the problems encountered in python-2.

>> 2) return only byte types in os.environ
> os.environ contains text (characters) and so should decoded as unicode.

This is correct but is not accurate :-)  os.environ, the python variable,
contains only unicode because that's the way it's coded.  However, the Unix
environment which os.environ attempts to give access to contains bytes which
are almost always representable as characters.  The two caveats are:

1) There's nothing that constrains it to characters -- putting byte
sequences
   that do not include null in the environment is valid.

2) The characters in the environment may be mixed encodings, sometimes
due to
   things outside of the user's control.

>> 3) raise an exception if someone attempts to access an environment
>> variable that cannot be decoded to unicode via the system encoding and
>> allow the value to be accessed as a byte string via another method.
>> 4) silently ignore the non-decodable variables when accessing os.environ
>> the normal way but have another method of accessing it that returns all
>> values as byte strings.
>
> Why not for (3).
"""

Do you mean, "I support 3"?  Or did you not finish a thought here?

> But what would be the "another method" (4) to access byte 
> string? The problem of having two methods is that you need consistent 
> objects.

This is exactly the problem I was talking about in my analysis of #4 in the
previous comment.  This problem plagues the new os.listdir() method as
well by
introducing a construct that programmers can use that doesn't give all the
information (os.listdir('.')) but also doesn't warn the programmer when the
information is not being shown.

> Imagine that you have os.environ (unicode) and os.environb (bytes).
> 
> Example 1:
>   os.environb['PATH'] = b'\xff\xff\xff\xff'
> What is the value in os.environ['PATH']?

Since option 4 mimics the os.listdir() method, accesing os.environ['PATH']
would give you a KeyError.  ie, the value was silently dropped just as
os.listdir('.') does.

> Example 2:
>   os.environb['PATH'] = b't?st'
> What is the value in os.environ['PATH']?

This doesn't work in python3 since byte strings can only be ASCii literals.

> Example 3:
>   os.environ['PATH'] = 't?st'
> What is the value in os.environb['PATH']?

Dependent on the default system encoding.  Assuming utf-8 encoding,
os.environb['PATH'] == b't\xc3\xaast'

> Example 4:
>  should I use os.environ['PATH'] or os.environb['PATH'] to get the current
>  PATH?

Should you use os.listdir('.') or os.listdir(b'.') to get the list of
files in
the current directory?

This is where treating pathnames, environment variables and etc as strings
instead of bytes becomes non-simple.  Now you have to decide what you really
want to know (and possibly keep two slightly different values if you want to
know two things.)

If you want to keep the path in order to look up commands that the user can
run you want os.environb['PATH'] since this is exactly what the shell
will use
when the user types a command at the commandline.

If you want to display the elements of the PATH for the user, you probably
want this::
  try:
      path = os.environ['PATH'].split(':')
  except KeyError:
      try:
          temp_path = os.environ['PATH'].split(b':')
      except KeyError:
          path = DEFAULT_PATH
      else:
          path = []
          for directory in os.environ['PATH'].split(b':'):
              path.append(unicode(directory,
                      sys.getdefaultencoding(), 'replace'))

> It introduces many new cases (bugs?) that have to be prepared and tested.

Those bugs are *already present*.  Without taking one of the four options,
there's simply no way to code a solution.  Take the above code and imagine
that there's no way to access the user's PATH variable when a
non-default-encoding character is present in the PATH.  That means that
you're
always stuck with the value of DEFAULT_PATH instead of being able to display
something reasonable to the user.

(Note, these examples are pretty much the same for option #3 or option
#4.  The
value of option #3 becomes apparent when you use os.getenv('PATH')
instead of
os.environ['PATH'])

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4006>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:52:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Nov 2008 16:52:11 +0000
Subject: [issue4405] fix_metaclass broken
In-Reply-To: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
Message-ID: <1227545531.36.0.745163314434.issue4405@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Are you sure you run the latest 2to3? I ran it over docutils last night,
and while the version distributed with 2.6 failed with the same
exception, the current 2to3 from the sandbox worked.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:53:39 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 16:53:39 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1227545619.97.0.593386429049.issue4327@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

It seems generally useful to have a helper function to replace a range
of nodes in a sequence of statements with another sequence of nodes.  A
general API like that would allow you to insert or delete nodes as well
as replacing one node with a set of nodes.  It seems like that could be
implemented pretty independently of this patch, and would then simplify
it.  I don't think it's a good idea to add the Seq type just to simplify
the implementation.

----------
nosy: +jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:13:43 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 17:13:43 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1227546823.91.0.931359618478.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, timestamp (c) is the *Mac* timestamp: seconds since the 1st 
january 1904.

> what is your conclusion?

Hum, it's maybe not possible to choose between integer and float. Why 
not supporting both? Example:
 - totimestamp()->int: truncate microseconds
 - totimestamp(microseconds=True)->float: with microseconds

Attached file (timestamp.py) is a module to import/export timestamp in 
all listed timestamp formats. It's written in pure Python.
----------------
>>> import timestamp
>>> from datetime import datetime
>>> now = datetime.now()
>>> now
datetime.datetime(2008, 11, 24, 18, 7, 50, 216762)

>>> timestamp.exportUnix(now)
1227550070
>>> timestamp.exportUnix(now, True)
1227550070.2167621
>>> timestamp.exportMac(now)
3310394870L
>>> timestamp.exportWin64(now)
128720236702167620L
>>> timestamp.exportUUID(now)
134468428702167620L

>>> timestamp.importMac(3310394870)
datetime.datetime(2008, 11, 24, 18, 7, 50)
>>> timestamp.importUnix(1227550070)
datetime.datetime(2008, 11, 24, 18, 7, 50)
>>> timestamp.importUnix(1227550070.2167621)
datetime.datetime(2008, 11, 24, 18, 7, 50, 216762)
----------------

It supports int and float types for import and export.

Added file: http://bugs.python.org/file12123/timestamp.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:14:01 2008
From: report at bugs.python.org (David Turner)
Date: Mon, 24 Nov 2008 17:14:01 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1227546841.75.0.860104623042.issue4327@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

jhylton, keep in mind that this would require an additional "parent"
argument to each function which takes a stmt.  Do you think this added
complexity is worth it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From jeremy at alum.mit.edu  Mon Nov 24 18:16:26 2008
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 24 Nov 2008 12:16:26 -0500
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1227546841.75.0.860104623042.issue4327@psf.upfronthosting.co.za>
References: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
	<1227546841.75.0.860104623042.issue4327@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811240916m26c389f7pc1eddb4f0e23e2b0@mail.gmail.com>

On Mon, Nov 24, 2008 at 12:14 PM, David Turner <report at bugs.python.org> wrote:
>
> David Turner <novalis at novalis.org> added the comment:
>
> jhylton, keep in mind that this would require an additional "parent"
> argument to each function which takes a stmt.  Do you think this added
> complexity is worth it?

Or we could add parent pointers in the tree, right?

Jeremy

>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4327>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Mon Nov 24 18:16:28 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 17:16:28 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1227546841.75.0.860104623042.issue4327@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811240916m26c389f7pc1eddb4f0e23e2b0@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Mon, Nov 24, 2008 at 12:14 PM, David Turner <report at bugs.python.org> wrote:
>
> David Turner <novalis at novalis.org> added the comment:
>
> jhylton, keep in mind that this would require an additional "parent"
> argument to each function which takes a stmt.  Do you think this added
> complexity is worth it?

Or we could add parent pointers in the tree, right?

Jeremy

>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4327>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:32:15 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 17:32:15 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227547935.56.0.907800385246.issue4336@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

This patch makes sense in principle, but some of the details need to
change.  The _send_output() method is used by some clients, merely
because it can be used :-(.  It's fairly easy to preserve this API for
backwards compatibility.

I am also worried about this new api call getheaderdata().  It
complicates the API.  Even if it were necessary, it needs a better name,
because getheaderdata() doesn't sound like a method that changes the
connection state or consumes buffered header data.

I think it would be better to have the new behavior exposed only through
HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility
API(!).  We can make some small changes to xmlrpclib to use the newer
API.  It would probably be a good change merely because py3k now uses
the newer API.

I've got a working local change, but it's still a little ugly.

----------
assignee:  -> jhylton
nosy: +jhylton
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:33:06 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2008 17:33:06 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1227546823.91.0.931359618478.issue2736@psf.upfronthosting.co.za>
Message-ID: <d38f5330811240933x49bd9163vaf9b56f7ec4259b9@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 24, 2008 at 12:13 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> Hum, it's maybe not possible to choose between integer and float. Why
> not supporting both? Example:
>  - totimestamp()->int: truncate microseconds
>  - totimestamp(microseconds=True)->float: with microseconds

I would still prefer totimestamp()->(int, int) returning (sec, usec)
tuple.  The important benefit is that such totimestamp() will not
loose information and will support more formats than either of your
->int or ->float variants.  The ->int can then be spelt simply as
totimestamp()[0] and on systems with numpy (which is likely for users
that deal with floats a lot), totimestamp(microseconds=True) is simply
dot([1, 1e-6], totimestamp()). (and s,us = totimestamp(); return s +
us * 1e-6 is not that hard either.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:34:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 17:34:57 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <d38f5330811240933x49bd9163vaf9b56f7ec4259b9@mail.gmail.com>
Message-ID: <200811241832.56431.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > Hum, it's maybe not possible to choose between integer and float. Why
> > not supporting both? Example:
> >  - totimestamp()->int: truncate microseconds
> >  - totimestamp(microseconds=True)->float: with microseconds
>
> I would still prefer totimestamp()->(int, int) returning (sec, usec)
> tuple.  The important benefit is that such totimestamp() will not
> loose information

Right, I prefer your solution ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:47:28 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 17:47:28 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227548848.68.0.49041053979.issue4336@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Just wanted to mention that the best solution is to update as much code
as possible to use HTTPConnection instead of HTTP.  I'm not sure how
easy it is to do for xmlrpclib, since it exposes methods like
send_content().  I guess we can preserve those APIs somehow, but it
won't be pretty.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:50:03 2008
From: report at bugs.python.org (David Turner)
Date: Mon, 24 Nov 2008 17:50:03 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1227549003.47.0.321555177877.issue4327@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

Sure, but that's an even bigger change.  Every piece of code which
modifies the AST would now also have to modify parent pointers.  Having
the pointers would make many things easier, but I didn't want to make a
very invasive change like that without thinking it through thoroughly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:55:22 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 17:55:22 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1227549003.47.0.321555177877.issue4327@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811240955r1b2c81d8w1c5b7bee51b6d12e@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I haven't thought about the code in a while, but what code that
modifies the AST are we worried about?  There are lots of
modifications in ast.c, since it is being created there.  The case we
really care about is sequences, where we want to modify the sequence.
The creation goes through macros like asdl_seq_SET(), so we could just
change the macro.  What are other cases we need to worry about?

Jeremy

On Mon, Nov 24, 2008 at 12:50 PM, David Turner <report at bugs.python.org> wrote:
>
> David Turner <novalis at novalis.org> added the comment:
>
> Sure, but that's an even bigger change.  Every piece of code which
> modifies the AST would now also have to modify parent pointers.  Having
> the pointers would make many things easier, but I didn't want to make a
> very invasive change like that without thinking it through thoroughly.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4327>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From jeremy at alum.mit.edu  Mon Nov 24 18:59:08 2008
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 24 Nov 2008 12:59:08 -0500
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227547935.56.0.907800385246.issue4336@psf.upfronthosting.co.za>
References: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
	<1227547935.56.0.907800385246.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811240959i215f32b6jfcafd1e148d36358@mail.gmail.com>

Actually, the patch doesn't work :-).  The httplib API allows you to
pass a file or a string for the body of the request.  The
getheaderdata() + body case only works for the string.  Easy to fix,
but I worry that he still run into Nagle problems with the file case,
which was presumably added for efficiency.

Jeremy

On Mon, Nov 24, 2008 at 12:32 PM, Jeremy Hylton <report at bugs.python.org> wrote:
>
> Jeremy Hylton <jeremy at alum.mit.edu> added the comment:
>
> This patch makes sense in principle, but some of the details need to
> change.  The _send_output() method is used by some clients, merely
> because it can be used :-(.  It's fairly easy to preserve this API for
> backwards compatibility.
>
> I am also worried about this new api call getheaderdata().  It
> complicates the API.  Even if it were necessary, it needs a better name,
> because getheaderdata() doesn't sound like a method that changes the
> connection state or consumes buffered header data.
>
> I think it would be better to have the new behavior exposed only through
> HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility
> API(!).  We can make some small changes to xmlrpclib to use the newer
> API.  It would probably be a good change merely because py3k now uses
> the newer API.
>
> I've got a working local change, but it's still a little ugly.
>
> ----------
> assignee:  -> jhylton
> nosy: +jhylton
> status: open -> pending
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Mon Nov 24 18:59:11 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 17:59:11 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227547935.56.0.907800385246.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811240959i215f32b6jfcafd1e148d36358@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Actually, the patch doesn't work :-).  The httplib API allows you to
pass a file or a string for the body of the request.  The
getheaderdata() + body case only works for the string.  Easy to fix,
but I worry that he still run into Nagle problems with the file case,
which was presumably added for efficiency.

Jeremy

On Mon, Nov 24, 2008 at 12:32 PM, Jeremy Hylton <report at bugs.python.org> wrote:
>
> Jeremy Hylton <jeremy at alum.mit.edu> added the comment:
>
> This patch makes sense in principle, but some of the details need to
> change.  The _send_output() method is used by some clients, merely
> because it can be used :-(.  It's fairly easy to preserve this API for
> backwards compatibility.
>
> I am also worried about this new api call getheaderdata().  It
> complicates the API.  Even if it were necessary, it needs a better name,
> because getheaderdata() doesn't sound like a method that changes the
> connection state or consumes buffered header data.
>
> I think it would be better to have the new behavior exposed only through
> HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility
> API(!).  We can make some small changes to xmlrpclib to use the newer
> API.  It would probably be a good change merely because py3k now uses
> the newer API.
>
> I've got a working local change, but it's still a little ugly.
>
> ----------
> assignee:  -> jhylton
> nosy: +jhylton
> status: open -> pending
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:02:56 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2008 18:02:56 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227549776.44.0.876042032604.issue4336@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:03:58 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 24 Nov 2008 18:03:58 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1227549838.83.0.00613354291501.issue1208304@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Python 2.4 is now in security-fix-only mode. No new features are being
added, and bugs are not fixed anymore unless they affect the stability
and security of the interpreter, or of Python applications.
http://www.python.org/download/releases/2.4.5/

This bug doesn't rise to the level of making into a 2.4.6.

----------
nosy: +jhylton
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208304>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:07:44 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2008 18:07:44 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <200811241832.56431.victor.stinner@haypocalc.com>
Message-ID: <d38f5330811241007k5b52de8ftbe7e984f1576b760@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 24, 2008 at 12:34 PM, STINNER Victor <report at bugs.python.org> wrote:
..
>> I would still prefer totimestamp()->(int, int) returning (sec, usec)
>> tuple.  The important benefit is that such totimestamp() will not
>> loose information
>
> Right, I prefer your solution ;-)
>

Great!  What do you think about extending fromtimestamp(timestamp[,
tz]) and utcfromtimestamp(timestamp) to accept a tuple for the
timestamp?

Also, are you motivated enough to bring this up on python-dev to get a
community and BDFL blessings?  I think this has a chance to be
approved.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:09:28 2008
From: report at bugs.python.org (David Fraser)
Date: Mon, 24 Nov 2008 18:09:28 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1831613200.107781227533102429.JavaMail.root@klofta.sjsoft.com>
Message-ID: <1469301663.107801227533154977.JavaMail.root@klofta.sjsoft.com>


David Fraser <davidf at sjsoft.com> added the comment:

----- "STINNER Victor" <report at bugs.python.org> wrote:

> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Timedelta formats:
> 
> (a) Win64: 64 bits unsigned integer, number of 1/10 microsecond
>  - file format: Microsoft Word document (.doc), ASF video (.asf)
> 
> (b) 64 bits float, number of seconds
>  - file format: AMF metadata used in Flash video (.flv)

There are also the PyWinTime objects returned by PythonWin COM calls which are basically FILETIMEs
I don't have time to get the details now but I recently submitted a patch to make them work with milliseconds - see http://sourceforge.net/tracker/index.php?func=detail&aid=2209864&group_id=78018&atid=551954 (yes I know this is a bit off-topic here)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:13:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 18:13:44 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1227550424.31.0.512824633838.issue4236@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:14:37 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 18:14:37 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227550477.26.0.171502937909.issue4382@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:16:49 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=)
Date: Mon, 24 Nov 2008 18:16:49 +0000
Subject: [issue4410] IDLE string problem in Run/Run Module
In-Reply-To: <1227550609.93.0.240511987484.issue4410@psf.upfronthosting.co.za>
Message-ID: <1227550609.93.0.240511987484.issue4410@psf.upfronthosting.co.za>


New submission from Andr? <info at orlans-amo.be>:

Python 3.0 rc3 on Windows (Server 2003 US English)

The code with a string including a non ascii character:

s = 'ab?d'
print (s)

is returning correct result in console mode and when it's typed in the 
IDLE Python Shell

But when executed from an IDLE editor window with Run/Run Module
it prints 5 characters instead of 4.

With more details, the code:

s = 'ab?d'
print (s)

for i in range(len(s)):
    print(hex(ord(s[i])),end=' ')
    
  
gives  in console mode:

ab?d
0x61 0x62 0xe7 0x64

but with Run/Run Module:

ab??d
0x61 0x62 0xc3 0xa7 0x64

----------
components: IDLE
messages: 76353
nosy: andre
severity: normal
status: open
title: IDLE string problem in Run/Run Module
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4410>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:19:03 2008
From: report at bugs.python.org (David Turner)
Date: Mon, 24 Nov 2008 18:19:03 +0000
Subject: [issue4327] Patch: simplify complex constant assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1227550743.1.0.334214151989.issue4327@psf.upfronthosting.co.za>


David Turner <novalis at novalis.org> added the comment:

Everything in optimize.c is about modifying the AST  (this is on tlee's
ast optimization branch, in case I didn't mention earlier).  Also,
changing asdl_seq_SET would be a bad idea, since it is used for
sequences of things other than stmt_tys.

What if asdl_seq were instead a doubly-linked list?  Then each node
contains enough information to add and remove elements.  asdl_seq_LEN
would be slower, but it is rarely used.  To be really slick, we could
store the len of the seq in the first element's prev pointer as (len <<
1) | 1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________

From report at bugs.python.org  Mon Nov 24 20:08:29 2008
From: report at bugs.python.org (Sebastian Wiesner)
Date: Mon, 24 Nov 2008 19:08:29 +0000
Subject: [issue4411] __mro__ documentation
In-Reply-To: <1227553709.92.0.112307623193.issue4411@psf.upfronthosting.co.za>
Message-ID: <1227553709.92.0.112307623193.issue4411@psf.upfronthosting.co.za>


New submission from Sebastian Wiesner <basti.wiesner at gmx.net>:

The documentation of Python 2.6 and 2.7 only mentions the class
attribute "__mro__" in ABC documentation and in Data model documentation
when explaining description invocation (see search results:
http://docs.python.org/dev/search.html?q=__mro__&check_keywords=yes&area=default)

Imho __mro__ lacks documentation in "Standard Type Hierachy", where
special attributes of fundamental data types are documented.

----------
assignee: georg.brandl
components: Documentation
messages: 76355
nosy: georg.brandl, lunar
severity: normal
status: open
title: __mro__ documentation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4411>
_______________________________________

From report at bugs.python.org  Mon Nov 24 20:38:56 2008
From: report at bugs.python.org (Florian Steinel)
Date: Mon, 24 Nov 2008 19:38:56 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1227555536.42.0.98980340831.issue3244@psf.upfronthosting.co.za>


Florian Steinel <Florian.Steinel at googlemail.com> added the comment:

see http://code.activestate.com/recipes/146306/ for a user contributed
implementation.

----------
nosy: +fsteinel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Mon Nov 24 20:54:48 2008
From: report at bugs.python.org (Chris AtLee)
Date: Mon, 24 Nov 2008 19:54:48 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1227556488.53.0.605049436471.issue3244@psf.upfronthosting.co.za>


Chris AtLee <chris at atlee.ca> added the comment:

I also wrote some software to handle this:
http://atlee.ca/software/poster/poster.encode.html

The reason I wrote this is to avoid having the load the entire file into
memory before posting the request.

This, along with Issue #3243, would allow streaming uploads of files via
HTTP POST.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Mon Nov 24 20:57:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Nov 2008 19:57:33 +0000
Subject: [issue4404] os.listdir() documentation error
In-Reply-To: <1227510056.52.0.380285272246.issue4404@psf.upfronthosting.co.za>
Message-ID: <1227556653.57.0.170006203756.issue4404@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in r67368.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4404>
_______________________________________

From report at bugs.python.org  Mon Nov 24 21:11:04 2008
From: report at bugs.python.org (Elizabeth Chang)
Date: Mon, 24 Nov 2008 20:11:04 +0000
Subject: [issue4049] IDLE does not open too
In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za>
Message-ID: <1227557464.72.0.733326478302.issue4049@psf.upfronthosting.co.za>


Elizabeth Chang <elizabeth.chang at noblis.org> added the comment:

I have this problem too but I am running Python 2.5.2 on Windows XP 
professional. I did install Python for all users. I tried uninstalling 
and reinstalling Python. IDLE does not open for me. It cannot find 
Tkinker.

C:\Python25>python.exe lib\idlelib\idle.py
Traceback (most recent call last):
  File "lib\idlelib\idle.py", line 6, in <module>
    import PyShell
  File "C:\Python25\Lib\idlelib\PyShell.py", line 14, in <module>
    import macosxSupport
  File "C:\Python25\Lib\idlelib\macosxSupport.py", line 6, in <module>
    import Tkinter
ImportError: No module named Tkinter

----------
nosy: +ec2929

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4049>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:00:44 2008
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 24 Nov 2008 21:00:44 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227560444.78.0.0398810038709.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Amaury,
thank you for pointing that out.

Attached patch disables this "__attribute__"
when PY_FORMAT_SIZE_T is undefined after configure script.

I confirmed this eliminate warnings in FreeBSD 4.11

----------
keywords: +patch
Added file: http://bugs.python.org/file12124/pyport.h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:07:14 2008
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 24 Nov 2008 21:07:14 +0000
Subject: [issue4366] cannot find -lpython2.X when buinding Python on FreeBSD
	4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227560834.47.0.933817439702.issue4366@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Changing the title because this is not 2.5.x specific.

----------
title: cannot find -lpython2.5 when buinding Python 2.5.2 on FreeBSD 4.11 -> cannot find -lpython2.X when buinding Python on FreeBSD 4.11
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:10:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 21:10:26 +0000
Subject: [issue4382] test_dbm_dumb fails due to character encoding issue on
	Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227561026.49.0.0470788217412.issue4382@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r67369.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:11:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 21:11:59 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227561119.73.0.304632744764.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

specify_open_encoding.diff has been committed in r67369.

I still need a review for doc_dbm_strings.diff, though, which clarifies
the docs, fixes one oversight in dbm.dumb, and extends testing to make
sure strings can be accepted.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:12:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Nov 2008 21:12:18 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227561138.54.0.845837965311.issue3799@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: +Library (Lib)
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:18:19 2008
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 24 Nov 2008 21:18:19 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227561499.27.0.488875107702.issue4366@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Changing the title again because this problem is not FreeBSD 4 specific.
Build on recent FreeBSD also has the same problem.
(I tested this on 6.3, too)

----------
title: cannot find -lpython2.X when buinding Python on FreeBSD 4.11 -> cannot find -lpythonX.X when buinding Python on FreeBSD
versions:  -Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:36:58 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 21:36:58 +0000
Subject: [issue4407] Windows Installer Error 1722 when opting for compilation
	at install time
In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
Message-ID: <1227562618.31.0.313888030028.issue4407@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:37:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 21:37:08 +0000
Subject: [issue4407] Windows Installer Error 1722 when opting for compilation
	at install time
In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
Message-ID: <1227562628.12.0.37780740661.issue4407@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:40:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 21:40:03 +0000
Subject: [issue4405] fix_metaclass broken
In-Reply-To: <1227545531.36.0.745163314434.issue4405@psf.upfronthosting.co.za>
Message-ID: <492B1F30.1040808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Are you sure you run the latest 2to3? I ran it over docutils last night,
> and while the version distributed with 2.6 failed with the same
> exception, the current 2to3 from the sandbox worked.

I was using the one included in the py3k branch (in r67369), which goes
up to r66985 from the 2to3 project.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:45:36 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 21:45:36 +0000
Subject: [issue4049] IDLE does not open too
In-Reply-To: <1227557464.72.0.733326478302.issue4049@psf.upfronthosting.co.za>
Message-ID: <492B207D.7010003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I have this problem too but I am running Python 2.5.2 on Windows XP 
> professional.

That is most definitely a different problem from the one reported here
originally.

> I did install Python for all users. I tried uninstalling 
> and reinstalling Python. IDLE does not open for me. It cannot find 
> Tkinker.

Make sure you select Tkinter in the feature selection window of Python.
If you can't get it to work, and still believe you have found a bug,
please report it as a separate issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4049>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:02:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2008 22:02:14 +0000
Subject: [issue4405] fix_metaclass broken
In-Reply-To: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
Message-ID: <1227564134.64.0.071756837574.issue4405@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67371.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:04:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2008 22:04:52 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227564292.84.0.05053001064.issue4370@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:05:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2008 22:05:03 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227564303.28.0.176672867727.issue4370@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:22:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2008 22:22:35 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1227565355.8.0.150927622928.issue1208304@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Reopening: I reproduce the problem consistently with both 2.6 and trunk 
versions (not with python 3.0), on Windows XP.

----------
nosy: +amaury.forgeotdarc
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208304>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:47:53 2008
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 24 Nov 2008 22:47:53 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227566873.93.0.061475767701.issue4368@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I tested this on FreeBSD 6.3 and it worked. (release25-maint)
waiting for review.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Tue Nov 25 00:47:42 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 24 Nov 2008 23:47:42 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227570462.23.0.728431220403.issue4370@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Technically patch is not correct : it disable __attribute__ always . 

The name of the macro is Py_GCC_ATTRIBUTE. It is a generic name and is
possible(in future) macro to be used set other attributes.

It is just a warning and is not related to "compile error" (issue type).

I will agree with patch that change name of attribute(as example
Py_GCC_FORMAT_ATTRIBUTE) that show its specific usage.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Tue Nov 25 01:25:02 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 25 Nov 2008 00:25:02 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1227561119.73.0.304632744764.issue3799@psf.upfronthosting.co.za>
Message-ID: <18731.17873.538097.326200@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Brett> I still need a review for doc_dbm_strings.diff, though, which
    Brett> clarifies the docs, fixes one oversight in dbm.dumb, and extends
    Brett> testing to make sure strings can be accepted.

Was my comment

    http://bugs.python.org/msg76198

and your resonse

    http://bugs.python.org/msg76199

not sufficient?

If not, allow me to anoint said diff with virtual holy water now...

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Tue Nov 25 01:39:49 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:39:49 +0000
Subject: [issue4412] Failure to test return value of PyUnicode_AsUTF8String()
	for NULL
In-Reply-To: <1227573589.29.0.468760733343.issue4412@psf.upfronthosting.co.za>
Message-ID: <1227573589.29.0.468760733343.issue4412@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

/home/rxc92/project/Python-2.5.2/Parser/tokenizer.c
(translate_into_utf8) Line 573
The return value of PyUnicode_AsUTF8String() is never checked if it is NULL.

Reference:
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-523

----------
components: None
messages: 76372
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to test return value of PyUnicode_AsUTF8String() for NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4412>
_______________________________________

From report at bugs.python.org  Tue Nov 25 01:42:39 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:42:39 +0000
Subject: [issue4413] Failure to check PyUnicode_AsUTF8String() return value
	for NULL
In-Reply-To: <1227573759.51.0.712537159422.issue4413@psf.upfronthosting.co.za>
Message-ID: <1227573759.51.0.712537159422.issue4413@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

/home/rxc92/project/Python-2.5.2/Objects/unicodeobject.c(PyUnicodeUCS2_AsEncodedString)
Line 699

Failed to check PyUnicode_AsUTF8String() for returning NULL.

Referenced:
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-523

----------
components: None
messages: 76373
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check PyUnicode_AsUTF8String() return value for NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4413>
_______________________________________

From report at bugs.python.org  Tue Nov 25 01:49:34 2008
From: report at bugs.python.org (Michael K. Edwards)
Date: Tue, 25 Nov 2008 00:49:34 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1227574174.14.0.987656390632.issue4395@psf.upfronthosting.co.za>


Michael K. Edwards <m.k.edwards at gmail.com> added the comment:

It would be really useful to explain, right in this section, why __ne__
is worth having.  Something along these lines (based on the logic from
Python 2.x -- modify as necessary):

<doctext>

The values most commonly returned by the rich comparison methods are
True, False, and NotImplemented (which tells the Python interpreter to
try a different comparison strategy).  However, it is quite legal and
often useful to return some other value, usually one which can be
coerced to True/False by bool().

For instance, if equality testing of instances of some class is
computationally expensive, that class's implementation of __eq__ may
return a "comparison object" whose __nonzero__ method calculates and
caches the actual boolean value.  Subsequent references to this same
comparison object may be returned for subsequent, logically equivalent
comparisons; the expensive comparison takes place only once, when the
object is first used in a boolean context.  This class's implementation
of __ne__ could return, not just "not (self == other)", but an object
whose __nonzero__ method returns "not (self == other)" -- potentially
delaying the expensive operation until its result is really tested for
boolean truth.

Python allows the programmer to define __ne__ separately from __eq__ for
this and similar reasons.  It is up to the programmer to ensure that
bool(self != other) == (not bool(self == other)), if this is a desired
property.  (One can even imagine situations in which it is appropriate
for neither (self == other) nor (self != other) to be true.  For
instance, a mathematical theorem prover might contain values a, b, c,
... that are formally unknown, and raise an exception when a==b is used
in a boolean context, but allow comparison of M = (a==b) against N =
(a!=b).)

</doctext>

Now that I write this, I see a use for magic __logical_or__,
__logical_and__, and __logical_not__ methods, so that one can postpone
or even avoid the evaluation of expensive/indeterminate comparisons. 
Consider the expression:
  ((a==b) and (c==d)) and ((a!=b) and (d==f))
If my class is designed such that a==b and a!=b cannot both be true,
then I can conclude that this expression is false without evaluating any
of the equality/inequality tests.

Is it too late to request these for Python 3.0?

----------
nosy: +medwards
title: Document auto __ne__ generation -> Document auto __ne__ generation; provide a use case for non-trivial __ne__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Tue Nov 25 01:50:30 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:50:30 +0000
Subject: [issue4414] Failure to check return value of PyBool_FromLong for NULL
In-Reply-To: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>
Message-ID: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

/home/rxc92/project/Python-2.5.2/Objects/unicodeobject.c(unicode_istitle)
Line 5953

Failed to check that the return value of PyBool_FromLong is not NULL

Referenced:
http://www.python.org/doc/2.5.2/api/boolObjects.html#l2h-400

----------
components: None
messages: 76375
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check return value of PyBool_FromLong for NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4414>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:01:36 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:01:36 +0000
Subject: [issue4415] Failure to check return value of PyBool_FromLong for NULL
In-Reply-To: <1227574895.83.0.787217406035.issue4415@psf.upfronthosting.co.za>
Message-ID: <1227574895.83.0.787217406035.issue4415@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

/home/rxc92/project/Python-2.5.2/Python/import.c(imp_is_frozen)
Line 2740

Failed to check that the return value of PyBool_FromLong is not NULL

Referenced:
http://www.python.org/doc/2.5.2/api/boolObjects.html#l2h-400

----------
components: None
messages: 76376
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check return value of PyBool_FromLong for NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4415>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:11:06 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:11:06 +0000
Subject: [issue4416] state_reset not called on 'state' before sre_search
	invoked
In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za>
Message-ID: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

/home/rxc92/project/Python-2.5.2/Modules/_sre.c (pattern_search)
Line 2740

Elsewhere in the codebase, state_reset is called on the first parameter
of sre_search before sre_search is invoked.  The does not occur here.

----------
components: None
messages: 76377
nosy: CWRU_Researcher1
severity: normal
status: open
title: state_reset not called on 'state' before sre_search invoked
type: performance
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4416>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:11:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Nov 2008 01:11:50 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <18731.17873.538097.326200@montanaro-dyndns-org.local>
Message-ID: <bbaeab100811241711w59fecbe6yf461a3b655e67aa3@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Nov 24, 2008 at 16:25, Skip Montanaro <report at bugs.python.org> wrote:
>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Brett> I still need a review for doc_dbm_strings.diff, though, which
>    Brett> clarifies the docs, fixes one oversight in dbm.dumb, and extends
>    Brett> testing to make sure strings can be accepted.
>
> Was my comment
>
>    http://bugs.python.org/msg76198
>
> and your resonse
>
>    http://bugs.python.org/msg76199
>
> not sufficient?
>

Wasn't sure if that meant everything not mentioned was fine.

> If not, allow me to anoint said diff with virtual holy water now...
>

=) Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:15:06 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:15:06 +0000
Subject: [issue4417] PySequence_List is not checked for NULL return value
In-Reply-To: <1227575705.99.0.0604113097847.issue4417@psf.upfronthosting.co.za>
Message-ID: <1227575705.99.0.0604113097847.issue4417@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Objects/abstract.c(PySequence_Fast)
Line 1611

PySequence_List is not checked for NULL return value

----------
messages: 76379
nosy: CWRU_Researcher1
severity: normal
status: open
title: PySequence_List is not checked for NULL return value
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4417>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:17:27 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:17:27 +0000
Subject: [issue4418] PyObject_CallObject is not checked for NULL return value
In-Reply-To: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>
Message-ID: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Modules/_sre.c(PySequence_Fast)
Line 1963

PyObject_CallObject is not checked for NULL return value

----------
messages: 76380
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyObject_CallObject is not checked for NULL return value
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4418>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:20:23 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:20:23 +0000
Subject: [issue4418] PyObject_CallObject is not checked for NULL return value
In-Reply-To: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>
Message-ID: <1227576023.59.0.0970018780132.issue4418@psf.upfronthosting.co.za>


Brian Szuter <Brian.Szuter at gmail.com> added the comment:

Python-2.5.2/Modules/_sre.c(join_list)
Line 2023

PyObject_CallObject is not checked for NULL return value

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4418>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:23:46 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:23:46 +0000
Subject: [issue4419] PyUnicode_DecodeUTF8 is not checked for NULL return value
In-Reply-To: <1227576226.15.0.611175528294.issue4419@psf.upfronthosting.co.za>
Message-ID: <1227576226.15.0.611175528294.issue4419@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Objects/unicodeobject.c
Line 587

PyUnicode_DecodeUTF8 is not checked for NULL return value

----------
components: None
messages: 76382
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyUnicode_DecodeUTF8 is not checked for NULL return value
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4419>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:26:39 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:26:39 +0000
Subject: [issue4420] PyUnicode_Decode is not checked for NULL return value
In-Reply-To: <1227576399.41.0.804406467928.issue4420@psf.upfronthosting.co.za>
Message-ID: <1227576399.41.0.804406467928.issue4420@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Objects/unicodeobject.c(PyUnicodeUCS2_FromEncodedObject)
Line 567

PyUnicode_Decode is not checked for NULL return value

----------
components: None
messages: 76383
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyUnicode_Decode is not checked for NULL return value
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4420>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:33:42 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:33:42 +0000
Subject: [issue4421] Failed to check 3rd Param of PyArena_AddPyObject() to
	ensure it isn't NULL
In-Reply-To: <1227576822.65.0.0416412823573.issue4421@psf.upfronthosting.co.za>
Message-ID: <1227576822.65.0.0416412823573.issue4421@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/ast.c(new_identifier)
Line 52

Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL

----------
components: None
messages: 76384
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4421>
_______________________________________

From report at bugs.python.org  Tue Nov 25 02:35:12 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:35:12 +0000
Subject: [issue4422] Failed to check 3rd Param of PyArena_AddPyObject() to
	ensure it isn't NULL
In-Reply-To: <1227576912.78.0.193917017995.issue4422@psf.upfronthosting.co.za>
Message-ID: <1227576912.78.0.193917017995.issue4422@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/ast.c(alias_for_import_name)
Line 2282, 2288

Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL

----------
components: None
messages: 76385
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4422>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:31:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:31:07 +0000
Subject: [issue4417] PySequence_List is not checked for NULL return value
In-Reply-To: <1227575705.99.0.0604113097847.issue4417@psf.upfronthosting.co.za>
Message-ID: <1227580267.69.0.0893609886177.issue4417@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There doesn't need to be a NULL check here. The exception is merely
propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4417>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:38:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:38:27 +0000
Subject: [issue4420] PyUnicode_Decode is not checked for NULL return value
In-Reply-To: <1227576399.41.0.804406467928.issue4420@psf.upfronthosting.co.za>
Message-ID: <1227580707.93.0.176800693107.issue4420@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There doesn't need to be a NULL check here. The exception is merely
propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4420>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:40:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:40:51 +0000
Subject: [issue4415] Failure to check return value of PyBool_FromLong for NULL
In-Reply-To: <1227574895.83.0.787217406035.issue4415@psf.upfronthosting.co.za>
Message-ID: <1227580851.29.0.0870466456409.issue4415@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There doesn't need to be a NULL check here. The exception is merely
propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4415>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:43:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:43:04 +0000
Subject: [issue4414] Failure to check return value of PyBool_FromLong for NULL
In-Reply-To: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>
Message-ID: <1227580984.93.0.270911488395.issue4414@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

None of these cases need checks. The exception is propagated to the caller.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4414>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:43:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:43:16 +0000
Subject: [issue4414] Failure to check return value of PyBool_FromLong for NULL
In-Reply-To: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>
Message-ID: <1227580996.06.0.445668961992.issue4414@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4414>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:44:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:44:38 +0000
Subject: [issue4413] Failure to check PyUnicode_AsUTF8String() return value
	for NULL
In-Reply-To: <1227573759.51.0.712537159422.issue4413@psf.upfronthosting.co.za>
Message-ID: <1227581078.09.0.891433000945.issue4413@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This doesn't need a NULL check. The exception is propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4413>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:46:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:46:39 +0000
Subject: [issue4418] PyObject_CallObject is not checked for NULL return value
In-Reply-To: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>
Message-ID: <1227581199.99.0.865147549311.issue4418@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This doesn't need a NULL check. The exception is propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4418>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:48:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:48:22 +0000
Subject: [issue4419] PyUnicode_DecodeUTF8 is not checked for NULL return value
In-Reply-To: <1227576226.15.0.611175528294.issue4419@psf.upfronthosting.co.za>
Message-ID: <1227581302.38.0.00213701970514.issue4419@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This doesn't need a NULL check. The exception is propagated to the caller.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4419>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:49:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 02:49:46 +0000
Subject: [issue4412] Failure to test return value of PyUnicode_AsUTF8String()
	for NULL
In-Reply-To: <1227573589.29.0.468760733343.issue4412@psf.upfronthosting.co.za>
Message-ID: <1227581386.19.0.49628827216.issue4412@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There are already NULL checks.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4412>
_______________________________________

From report at bugs.python.org  Tue Nov 25 04:35:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Nov 2008 03:35:00 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In 2to3 (from the py3k branch, as of r67372) translates the fragment

def f():
    commands = foo()
    commands.sort()

to

def f():
    commands = foo()
    subprocess.sort()

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76394
nosy: loewis
severity: normal
status: open
title: 2to3 replaces "arbitrary" variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Tue Nov 25 04:39:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 03:39:23 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227584363.05.0.0859057477289.issue4423@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yes, this a known issue. You can currently circumvent it by disabling
the imports fixer.

----------
nosy: +benjamin.peterson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Tue Nov 25 05:03:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Nov 2008 04:03:02 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227585782.3.0.0582254728079.issue4423@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are there any plans to improve that? In the specific case, it would help
if commands gets only replaced if an import of commands appears "in
scope" (or, if that is too difficult, anywhere in the file). I think
2to3 should create a list of all names that get imported anywhere, and
compare candidates for renaming against this list.

Also, I tried to work-around by just deleting "commands" from MAPPING
(nobody uses the commands module, anyway); this unfortunately failed
because PATTERN already had the name compiled in. It would be helpful if
PATTERN was computed more lazily, e.g. by overriding compile_pattern.
(I then worked around by regenerating PATTERN after monkey-patching
MAPPING).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Tue Nov 25 05:06:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 04:06:38 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227585998.93.0.464754166855.issue4423@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This bug certainly has been reported before, so I'll see if I can find
time for it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Tue Nov 25 05:39:24 2008
From: report at bugs.python.org (Alex)
Date: Tue, 25 Nov 2008 04:39:24 +0000
Subject: [issue4424] Add support for a cmp, or key argument to heapq functions.
In-Reply-To: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>
Message-ID: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

Currently the heapq module can only really be used if your data has it's
own ordering defined.  There is no way to do a custom ordering.  From my
cursory review of the code it looks like some of the lower level
functions actually take these kwargs, but the public interface does not.

----------
components: Library (Lib)
messages: 76398
nosy: alex
severity: normal
status: open
title: Add support for a cmp, or key argument to heapq functions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4424>
_______________________________________

From report at bugs.python.org  Tue Nov 25 06:06:57 2008
From: report at bugs.python.org (=?utf-8?q?=E8=B5=B5=E7=8E=B0=E5=88=9A?=)
Date: Tue, 25 Nov 2008 05:06:57 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227517233.27.0.809676247073.issue4402@psf.upfronthosting.co.za>
Message-ID: <BAY112-W258B48AB172CA9742A171F20B0@phx.gbl>


??? <zhaolu8 at hotmail.com> added the comment:

I have installed both py2.5 and py3.0rc3. I got the result as follows:

1.py3.0  : from the windows start menu-->run, type in "python" ,and py3.0 will startup(which I don't understand why),then execute 

import ossys_path=os.getenv('PATH')print(sys_path)
will get the result.

2.py2.5: First start the windows programme "cmd", and then type in "python", and py2.5 will startup,then  also execute the code 
import ossys_path=os.getenv('PATH')print(sys_path)
will get the result.

Thanks!> Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3> To: zhaolu8 at hotmail.com> From: report at bugs.python.org> Date: Mon, 24 Nov 2008 09:00:33 +0000> > > Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:> > I cannot reproduce this. Python does not modify the environment variables.> How did you exactly start the python interpreters, 2.5 and 3.0?> > ----------> nosy: +amaury.forgeotdarc> > _______________________________________> Python tracker <report at bugs.python.org>> <http://bugs.python.org/issue4402>> _______________________________________
_________________________________________________________________
MSN???????????????????
http://im.live.cn/newsexpress

Added file: http://bugs.python.org/file12125/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081125/9782d87e/attachment.txt>

From report at bugs.python.org  Tue Nov 25 06:40:12 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Nov 2008 05:40:12 +0000
Subject: [issue4424] Add support for a cmp, or key argument to heapq functions.
In-Reply-To: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>
Message-ID: <1227591612.57.0.814443148478.issue4424@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is a duplicate of a previously rejected request.  The usual
approach is to load the heap with (priority, record) tuples.

----------
nosy: +rhettinger
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4424>
_______________________________________

From report at bugs.python.org  Tue Nov 25 06:42:20 2008
From: report at bugs.python.org (Alex)
Date: Tue, 25 Nov 2008 05:42:20 +0000
Subject: [issue4424] Add support for a cmp, or key argument to heapq functions.
In-Reply-To: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>
Message-ID: <1227591740.12.0.228586865898.issue4424@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Apologies, searching didn't yield that.  That's not necessarily always
easy, for example I'd like to use heapq to merge iterators coming from
the database.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4424>
_______________________________________

From report at bugs.python.org  Tue Nov 25 09:24:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2008 08:24:21 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227601461.63.0.103875100152.issue4402@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you please check with the "regedit" application whether you have an
entry for the key:

"HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Windows\CURRENTVERSION\App
Paths\python.exe"

(this key is used when you type "python" in the "Run" dialog box)

What is its "(Default)" value?
Is there an additional entry named "PATH"?

(I presume that (Default)=C:\Python30\Python.exe, and PATH=C:\Python25\)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Tue Nov 25 11:14:18 2008
From: report at bugs.python.org (=?utf-8?q?=E8=B5=B5=E7=8E=B0=E5=88=9A?=)
Date: Tue, 25 Nov 2008 10:14:18 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227601461.63.0.103875100152.issue4402@psf.upfronthosting.co.za>
Message-ID: <BAY112-W24841E5FE6F48E000DF111F20B0@phx.gbl>


??? <zhaolu8 at hotmail.com> added the comment:

YES! It is exactly what you assumed. 
 The default value is "C:\Python30\Python.exe", and  there is also another entry "path",its value is "C:\Python25\".

Does that mean I should not start python from the "Run" dialog box? 

?????????> Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3> To: zhaolu8 at hotmail.com> From: report at bugs.python.org> Date: Tue, 25 Nov 2008 08:24:21 +0000> > > Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:> > Can you please check with the "regedit" application whether you have an> entry for the key:> > "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Windows\CURRENTVERSION\App> Paths\python.exe"> > (this key is used when you type "python" in the "Run" dialog box)> > What is its "(Default)" value?> Is there an additional entry named "PATH"?> > (I presume that (Default)=C:\Python30\Python.exe, and PATH=C:\Python25\)> > _______________________________________> Python tracker <report at bugs.python.org>> <http://bugs.python.org/issue4402>> _______________________________________
_________________________________________________________________
MSN???????????????????
http://im.live.cn/newsexpress

Added file: http://bugs.python.org/file12126/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081125/5a60d089/attachment.txt>

From report at bugs.python.org  Tue Nov 25 12:03:53 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 11:03:53 +0000
Subject: [issue4425] UTF7 encoding of slash (character 47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>


New submission from Nick Barnes <Nick.Barnes at pobox.com>:

'/'.encode('utf7') returns '+AC8-'.  It should return '/'.  See RFC 2152.

'/'.decode('utf7') raises an exception (this is a special case of a
general problem with UTF-7 decoding, which I will report as a separate bug).

----------
components: Unicode
messages: 76404
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 encoding of slash (character 47) is incorrect
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4425>
_______________________________________

From report at bugs.python.org  Tue Nov 25 12:11:56 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 11:11:56 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>


New submission from Nick Barnes <Nick.Barnes at pobox.com>:

UTF-7 decoding raises an exception for any character not in the RFC2152
"Set D" (directly encoded characters).  In particular, it raises an
exception for characters in "Set O" (optional direct characters), such
as < = > [ ] @ etc.  These characters can legitimately appear in
UTF-7-encoded text, and should be decoded (as themselves).  As it is,
the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
than that encoded by Python's own UTF-7 encoder.

Looking at the source of unicodeobject.c, the call to the SPECIAL macro
on line 1009 has hardcoded second and third arguments of zero.  Maybe
changing the second argument to 1 would fix this.  Maybe.

----------
components: Unicode
messages: 76405
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 decoding is far too strict
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 12:13:40 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 25 Nov 2008 11:13:40 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227611620.52.0.772028483822.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I have addressed some issues mentioned:
1) I have retained the _send_output() method.
2) the endheaders() method now takes an optional argument, send_data 
that defaults to True.  It also returns any unsent data as a string.  
This simplifies any code wishing to send more data.
3) The old HTTP class needs no changes anymore.
4) I've fixed the test_xmlrpc.py test case to run all the tests on 
windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer 
valid.
5) concatenating the result from endheaders() with the request body is 
valid, in xmlrpclib, because the assumption has already been made in 
send_content() that request_body is a string (str(len(request_body)).  
However, in httplib's request() method, we now special case this.  I 
don't want to complicate the code for what appears to be a rare case.

I chose not to mess with xmlrpclib and make it continue to use the old 
HTTP class in order to minimise the extent of this patch.  A simple and 
clear performance patch has in my experience a much greater chance of 
finding its way into the codebase than a more extensive rewrite :)

You may have concerns regarding point 3 above, and I am open to 
suggestions.

Now, what remains is the question of the read buffering for the socket 
fileobject.  Do you think that it is feasible to simply change the 
default read buffering for fileobjects to use buffering for readline() 
same as they do for read()?  Then we wouldn't need the second half of 
this patch and we could make a separate "socket" performance patch.

Added file: http://bugs.python.org/file12127/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Tue Nov 25 12:15:34 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 25 Nov 2008 11:15:34 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227611734.33.0.279559190288.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sorry, I meant : "you may have concerns regarding point 2) above"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Tue Nov 25 12:41:05 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 11:41:05 +0000
Subject: [issue4427] Docs for 'y' Py_BuildValue tag are wrong
Message-ID: <1227613265.45.0.0537998980121.issue4427@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
assignee: georg.brandl
components: Documentation
files: doc.patch
keywords: patch, patch
nosy: georg.brandl, theller
severity: normal
stage: patch review
status: open
title: Docs for 'y' Py_BuildValue tag are wrong
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12128/doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4427>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:35:00 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 25 Nov 2008 12:35:00 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The Buffered I/O interface in the io module has the user specify buffer 
limits such as size and max_buffer_size.   The first limit (size) is 
easy to understand as a buffering threshold at which writes will occur.  
However, no apparent attempt is made to strictly limit the internal 
buffer size to max_buffer_size.
   
In BuffererWriter.write(), one of the first operations is 

     self._write_buf.extend(b)

which simply extends the buffer by the full data being written.  If b 
happens to be a large string (e.g., megabytes or even the entire 
contents of a big file), then the internal I/O buffer makes a complete 
copy of the data, effectively doubling the memory requirements for 
carrying out the write operation.

I suppose most programmers might not notice given that everyone has 
gigabytes of RAM these days, but you certainly don't see this kind of 
buffering behavior in the operating system kernel or in the C library.

Some patch suggestions (details left to the maintainers of this module):

1. Don't extend self._write_buf by more than the max_buffer_size.

     fragment = b[:self.max_buffer_size - len(self._write_buf)]
     self._write_buf.extend(fragment)

2. For large blocking writes, simply carry out the remaining I/O 
   operations in the write() method instead of in the _flush_locked()
   method.   Try to use the original input data b as the data
   source instead of making copies of it.  And if you have to copy
   the data, don't do it all at once.

----------
components: Library (Lib)
messages: 76408
nosy: beazley
severity: normal
status: open
title: io.BufferedWriter does not observe buffer size limits
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:38:46 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2008 12:38:46 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227616726.27.0.20683613969.issue4426@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write some tests to help fixing this issue? Stupid example (I 
don't know UTF-8 encoding):
>>> all((byte.encode("utf-7") == byte) for byte in '<=>[]@')
>>> all((byte.decode("utf-7") == byte) for byte in '<=>[]@')

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:39:35 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2008 12:39:35 +0000
Subject: [issue4425] UTF7 encoding of slash (character 47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1227616775.16.0.890434556416.issue4425@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Related issue: #4426

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4425>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:43:12 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 12:43:12 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

ctypes raises UnicodeDecodeError in german windows (it should print
'Unzul?ssige Funktion'):

>>> from ctypes import FormatError
[46681 refs]
>>> FormatError(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 5-7:
invalid data
[46742 refs]
>>>

----------
assignee: theller
components: ctypes
messages: 76411
nosy: theller
priority: release blocker
severity: normal
status: open
title: ctypes.FormatError raises when the string to return contains non-ascii characters
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:44:59 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 12:44:59 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227617099.13.0.907082874816.issue4429@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The simple patch (ctypes-simple.patch) uses the 'y' format tag for
PyBuild_Value to build a bytes object as error message.

----------
keywords: +patch
Added file: http://bugs.python.org/file12129/ctypes-simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:48:33 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 12:48:33 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227617313.78.0.085836251441.issue4429@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The 'better' patch changes the internal FormatError function to return a
wide string; so conversion from ascii to unicode by Python functions is
not needed and it returns strings to the caller:

>>> from ctypes import FormatError
[46681 refs]
>>> FormatError(1)
'Unzul?ssige Funktion.'
[46698 refs]
>>>

Added file: http://bugs.python.org/file12130/ctypes-better.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:49:16 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 12:49:16 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227617356.81.0.5035286731.issue4429@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:50:31 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2008 12:50:31 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227617431.64.0.360815284141.issue4429@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 14:09:23 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 13:09:23 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227618563.01.0.835469631963.issue4426@psf.upfronthosting.co.za>


Nick Barnes <Nick.Barnes at pobox.com> added the comment:

# Note, this test covers issues 4425 and 4426

# Direct encoded characters:
set_d =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'(),-./:?"

# Optional direct characters:
set_o = '!"#$%&*;<=>@[]^_`{|}'

all((c.encode('utf7') == c) for c in set_d)
all((c.decode('utf7') == c) for c in set_d)
all((c.decode('utf7') == c) for c in set_o)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 14:30:09 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 25 Nov 2008 13:30:09 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <492BFDDF.4030402@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-11-25 12:11, Nick Barnes wrote:
> New submission from Nick Barnes <Nick.Barnes at pobox.com>:
> 
> UTF-7 decoding raises an exception for any character not in the RFC2152
> "Set D" (directly encoded characters).  In particular, it raises an
> exception for characters in "Set O" (optional direct characters), such
> as < = > [ ] @ etc.  These characters can legitimately appear in
> UTF-7-encoded text, and should be decoded (as themselves).  As it is,
> the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
> than that encoded by Python's own UTF-7 encoder.

Thanks for noticing this. Apparently, the UTF-7 codec is not used
a lot by Python users, since it's been like this for years.

The tests we have do check round-trip safety, but not the special
characteristics of the UTF-7 codec.

Also note that the code for the codec was contributed and is, AFAIK,
not maintained by any of the Python developers.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:09:06 2008
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 25 Nov 2008 16:09:06 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227629346.93.0.508901311626.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Roumen,
Thanks for the feedback!

This patch disables __attribute__ when PY_FORMAT_SIZE_T isn't defined,
not always.

About the name of the macro, I think you are right.
Py_GCC_FORMAT_ATTRIBUTE would be much better name if it is not used for
other uses. (I'm not sure)
I'll look into the code more and if it seems being safe to rename it,
I'll update the patch and resubmit it.

----------
components: +2to3 (2.x to 3.0 conversion tool), None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:36:42 2008
From: report at bugs.python.org (sil)
Date: Tue, 25 Nov 2008 16:36:42 +0000
Subject: [issue4430] time.strptime does not allow same format directive twice
In-Reply-To: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>
Message-ID: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>


New submission from sil <sil-python at kryogenix.org>:

$ python -c "import time; print time.strptime('25/11/2008
25/11/2008','%d/%m/%y %d/%m/%y')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/_strptime.py", line 311, in strptime
    format_regex = _TimeRE_cache.compile(format)
  File "/usr/lib/python2.5/_strptime.py", line 267, in compile
    return re_compile(self.pattern(format), IGNORECASE)
  File "/usr/lib/python2.5/re.py", line 188, in compile
    return _compile(pattern, flags)
  File "/usr/lib/python2.5/re.py", line 241, in _compile
    raise error, v # invalid expression
sre_constants.error: redefinition of group name 'd' as group 4; was group 1

If a format directive is repeated in time.strptime's format string, it
throws an error and should not do so. Subversion, for example, repeats
date parts in its svn log output ("2008-09-26 16:20:59 +0100 (Fri, 26
Sep 2008)"), which repeats both %d (day) and %y (year).

----------
messages: 76417
nosy: sil
severity: normal
status: open
title: time.strptime does not allow same format directive twice
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4430>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:36:57 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 25 Nov 2008 18:36:57 +0000
Subject: [issue4430] time.strptime does not allow same format directive twice
In-Reply-To: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>
Message-ID: <1227638217.3.0.946216266818.issue4430@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Subversion is formatting a string from a time (strftime), so a repeated
placeholder is OK.

You're trying to _parse_ a time from a string (strptime). If you're
telling it that 2 different parts of the string are the date, what
should it do? The Pythonic thing to do is raise an exception.

(I suppose an alternative would be to raise an exception only if they
give different results.)

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4430>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:56:47 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 18:56:47 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227639407.17.0.674767742462.issue4426@psf.upfronthosting.co.za>


Nick Barnes <Nick.Barnes at pobox.com> added the comment:

Well, I could submit a diff for unicodeobject.c, but I have never
contributed to Python (or used this particular tracking system) before.
 Is there a standard form for contributing changes?  Unified diff?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:19:37 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Nov 2008 19:19:37 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1227640777.04.0.896134968721.issue3799@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r67380 has the fix. Thanks for the review, Skip!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:28:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Nov 2008 19:28:52 +0000
Subject: [issue4430] time.strptime does not allow same format directive twice
In-Reply-To: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>
Message-ID: <1227641332.73.0.290394868408.issue4430@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The reason this occurs is that in order to have a portable and sane
implementation time.strptime() uses the re module to parse dates. The
issue here is that by specifying the same format twice the re module is
complaining that there are two named groups with the same name, leading
to a conflict.

About the only solution I can think of that doesn't require some massive
rewrite is to drop named group usage from time.strptime() and move to
positional groups by keeping track of the order of the formats and
zipping the format order and results together or something.

But I don't plan on doing that personally as that would require writing
a parser for format strings as well. But if someone manages to get it to
work I would be willing to review the patch.

Setting the priority to low as this is easy to work around since you
just use one set of date information instead of two which is redundant.

----------
nosy: +brett.cannon
priority:  -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4430>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:33:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Nov 2008 19:33:29 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227641609.54.0.0444927462541.issue4373@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Amaury's patch for pickle looks fine to me.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:35:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2008 19:35:14 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227641714.57.0.107238802265.issue4426@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is there a standard form for contributing changes?  Unified diff?

Attach a patch file (unified diff, yes).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:16:34 2008
From: report at bugs.python.org (David Schnur)
Date: Tue, 25 Nov 2008 20:16:34 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>


New submission from David Schnur <david.schnur at dartware.com>:

This is my first time submitting an issue; sorry if I am doing this 
wrong.  While attempting to build/install PyOpenSSL on Windows / MSVC, 
the mt.exe step failed because it could not find the manifest file that 
it was attempting to embed in crypto.pyd.  The problem was that link.exe 
was not creating the manifest.

The reason why is that distutils only passes link.exe the 
/MANIFESTFILE:filename parameter.  This tells it where to output the 
manifest, but not to actually create the manifest (see http://msdn.microsoft.com/en-us/library/fft52235(VS.80).aspx).  You'd 
think link could figure out that, if you use /MANIFESTFILE, you want a 
manifest, but I guess not ;)

My solution was to add this line to distutils/msvc9compiler.py:

ld_args.append('/MANIFEST')

Right beneath the existing line:

ld_args.append('/MANIFESTFILE:' + temp_manifest)

Hope that helps

----------
components: Distutils
messages: 76424
nosy: dschnur
severity: normal
status: open
title: Distutils MSVC doesn't create manifest file (with fix)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:35:09 2008
From: report at bugs.python.org (August Mueller)
Date: Tue, 25 Nov 2008 20:35:09 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1227645309.05.0.879489664358.issue4403@psf.upfronthosting.co.za>


August Mueller <gus at flyingmeat.com> added the comment:

For completeness, if anyone runs across this in the future, the following seems to work for sending utf-8 mail 
in python 3:

import smtplib
import email.mime.text

msg = email.mime.text.MIMEText("?mlaut", _charset="UTF-8")

smtp = smtplib.SMTP('localhost')
smtp.sendmail('gus at flyingmeat.com', 'gus at flyingmeat.com', "Subject: This is your mail\n" + msg.as_string())
smtp.quit()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:53:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2008 20:53:48 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1227646428.74.0.278415906907.issue4431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Since issue4120, the compilation tools precisely chose to *not* embed 
manifests in .pyd extensions.
This probably means that the "mt.exe" step should be skipped by 
distutils.

----------
assignee:  -> loewis
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:59:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2008 20:59:14 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227646754.84.0.624794892069.issue4402@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Does that mean I should not start python from the "Run" dialog box? 
Not at all. Just remove the "PATH" entry and the inconsistency will 
disappear.

I just wonder how to explain the presence of this additional variable.

Which distribution of python did you install, the "official" one from 
www.python.org, or another one, from ActiveState for example?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:12:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2008 21:12:37 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227647557.32.0.714233708219.issue4373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied pickle-leak2.patch in 67381.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:17:13 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 25 Nov 2008 21:17:13 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <492C6B54.3060304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-11-25 21:16, David Schnur wrote:
> New submission from David Schnur <david.schnur at dartware.com>:
> 
> This is my first time submitting an issue; sorry if I am doing this 
> wrong.  While attempting to build/install PyOpenSSL on Windows / MSVC, 
> the mt.exe step failed because it could not find the manifest file that 
> it was attempting to embed in crypto.pyd.  The problem was that link.exe 
> was not creating the manifest.
> 
> The reason why is that distutils only passes link.exe the 
> /MANIFESTFILE:filename parameter.  This tells it where to output the 
> manifest, but not to actually create the manifest (see http://msdn.microsoft.com/en-us/library/fft52235(VS.80).aspx).  You'd 
> think link could figure out that, if you use /MANIFESTFILE, you want a 
> manifest, but I guess not ;)
> 
> My solution was to add this line to distutils/msvc9compiler.py:
> 
> ld_args.append('/MANIFEST')
> 
> Right beneath the existing line:
> 
> ld_args.append('/MANIFESTFILE:' + temp_manifest)
> 
> Hope that helps

I'm not sure whether that's necessary. We are building pyOpenSSL
just fine against stock Python 2.6.0 in our distribution:

    http://www.egenix.com/products/python/pyOpenSSL/

and even though the command line does not include the /MANIFEST
switch, the linker does builds the .manifest file just fine.

OTOH, it probably doesn't hurt adding the switch :-)

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:20:52 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 25 Nov 2008 21:20:52 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <492C6B54.3060304@egenix.com>
Message-ID: <492C6C2E.8040509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

This is why we don't see the problem:

http://msdn.microsoft.com/en-us/library/f2c0w594.aspx

"""
The default is /MANIFEST.
"""

So it appears that you must have disabled this default somehow.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:22:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Nov 2008 21:22:00 +0000
Subject: [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227648120.45.0.251806333278.issue4373@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Second fix applied in r67382

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:39:47 2008
From: report at bugs.python.org (David Schnur)
Date: Tue, 25 Nov 2008 21:39:47 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1227649187.71.0.482121072498.issue4431@psf.upfronthosting.co.za>


David Schnur <david.schnur at dartware.com> added the comment:

I looked at this some more (I'm not super familiar with the use of
manifests) and I think I figured it out.  For somewhat complicated
reasons, I'm compiling with /MT rather than /MD.  Although link normally
produces a manifest, since it's unnecessary when compiling static, it
isn't created unless you specify /MANIFEST.

So I suppose the issue is that distutils is trying to embed the manifest
in cases where it may legitimately not exist.  Since /MT is not the
default (I had to make that change explicitly), this is probably not a bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:43:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2008 21:43:47 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227649427.4.0.232897253803.issue4429@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The "better" patch is good to me. It is indeed better to always use the 
"Wide" Win32 API.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Tue Nov 25 23:20:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Nov 2008 22:20:10 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1227651610.92.0.983583986711.issue4431@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing it as "invalid" then.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Nov 25 23:46:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 22:46:40 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227653200.02.0.857098785961.issue4423@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm not sure what you mean about MAPPING being compiled in. It is
regenerated every time 2to3 is run.

Anyway, I fixed the replacement problem in r67386.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:03:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 23:03:08 +0000
Subject: [issue4421] Failed to check 3rd Param of PyArena_AddPyObject() to
	ensure it isn't NULL
In-Reply-To: <1227576822.65.0.0416412823573.issue4421@psf.upfronthosting.co.za>
Message-ID: <1227654188.87.0.00516279561982.issue4421@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Closing in favor of the closely related #4422.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4421>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:05:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 23:05:05 +0000
Subject: [issue4422] Failed to check 3rd Param of PyArena_AddPyObject() to
	ensure it isn't NULL
In-Reply-To: <1227576912.78.0.193917017995.issue4422@psf.upfronthosting.co.za>
Message-ID: <1227654305.21.0.87370407158.issue4422@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm not what sure you mean, by the third param since PyArena_AddPyObject
only takes two arguments. However, in r67373, I fixed a bunch of cases
where NEW_INDENTIFER was used without checking for NULL.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4422>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:10:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Nov 2008 23:10:12 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227653200.02.0.857098785961.issue4423@psf.upfronthosting.co.za>
Message-ID: <492C85D0.1010603@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm not sure what you mean about MAPPING being compiled in. It is
> regenerated every time 2to3 is run.

This code does not work:

    from lib2to3.fixes import fix_imports
    del fix_imports.MAPPING['commands']

when followed by an attempt to actually run the fixer. Instead, I need
to write

    from lib2to3.fixes import fix_imports
    del fix_imports.MAPPING['commands']
    fix_imports.FixImports.PATTERN="|".join(fix_imports.build_pattern())

> Anyway, I fixed the replacement problem in r67386.

Thanks! It still transforms

def g():
    import commands
def f():
    commands = foo()
    commands.sort()

but I think this is ok; people just shouldn't write such code in the
first place (and the resulting code does work correctly - just with
a strangely-renamed local variable).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:11:33 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 25 Nov 2008 23:11:33 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227629346.93.0.508901311626.issue4370@psf.upfronthosting.co.za>
Message-ID: <492C8622.5060701@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Akira Kitada wrote:
> Akira Kitada <akitada at gmail.com> added the comment:
> 
> Roumen,
> Thanks for the feedback!
> 
> This patch disables __attribute__ when PY_FORMAT_SIZE_T isn't defined,
> not always.

I would like to clarify. After patch if PY_FORMAT_SIZE_T isn't defined 
then __attribute__(XXX) will be ignored always irrespective of content, 
i.e. XXX.

> About the name of the macro, I think you are right.
> Py_GCC_FORMAT_ATTRIBUTE would be much better name if it is not used for
> other uses. (I'm not sure)
> I'll look into the code more and if it seems being safe to rename it,
> I'll update the patch and resubmit it.

The current python code use Py_GCC_ATTRIBUTE only for 
'format(printf(...)) ' attribute. The patch will prevent python to use 
this macro in future for other attributer.

Also I'm not sure that I would like warning to be hidden.
As example I know that GCC(mingw) 3.5.x don't support %z and I prefer to 
see those warnings instead to hide them.

Roumen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:14:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 23:14:50 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227654890.82.0.454508810436.issue4370@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
components:  -2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:26:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2008 23:26:08 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <492C85D0.1010603@v.loewis.de>
Message-ID: <1afaf6160811251526r6ce4b9c8n4a25f6d0a2d1d81b@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Tue, Nov 25, 2008 at 5:10 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> I'm not sure what you mean about MAPPING being compiled in. It is
>> regenerated every time 2to3 is run.
>
> This code does not work:
>
>    from lib2to3.fixes import fix_imports
>    del fix_imports.MAPPING['commands']
>
> when followed by an attempt to actually run the fixer. Instead, I need
> to write
>
>    from lib2to3.fixes import fix_imports
>    del fix_imports.MAPPING['commands']
>    fix_imports.FixImports.PATTERN="|".join(fix_imports.build_pattern())

This is true of many fixers. What is the use case?

>
>> Anyway, I fixed the replacement problem in r67386.
>
> Thanks! It still transforms
>
> def g():
>    import commands
> def f():
>    commands = foo()
>    commands.sort()
>
> but I think this is ok; people just shouldn't write such code in the
> first place (and the resulting code does work correctly - just with
> a strangely-renamed local variable).

This also won't work:

def f():
    commands.call() # This fails to be fixed.

import commands

Is that reasonable also?

Scoping isn't something that 2to3 does well, and we'd probably have to
add a whole symtable analyzer to fix a few obscure bugs like above.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:31:41 2008
From: report at bugs.python.org (Michael Becker)
Date: Tue, 25 Nov 2008 23:31:41 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227655901.43.0.434895670503.issue4329@psf.upfronthosting.co.za>


Michael Becker <spammb at gmail.com> added the comment:

Terry,
Thanks for your response. My main concern was that the behavior changed
when updating from 2.5 to 2.6. The new behavior was not intuitive. Also
2.6, I thought, was supposed to be backward compatible.  Based on this
issue, I would assume this statement is not true when strings are passed
to any method that convert them to bytes. Maybe this was documented in
the 2.6 documentation somewhere and I simply missed it. Should I have
run the 2to3 converter on my 2.5 code prior to updating to 2.6? Please
let me know the new issue number so I can track the progress.
Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:39:55 2008
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 25 Nov 2008 23:39:55 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227656395.52.0.804482780956.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Thank you again for the feedback.

I think those warnings are not so useful, or even misleading,
when we know they are handled appropriately.
with these warnings hidden, it would get much more easy to read
build log and find real warnings there.

As for renaming Py_GCC_ATTRIBUTE,
yes this would prevent python to use this macro in future for
other attributer, but after all python does not need it for now.
So I think that's not a problem.
Someone will write it when he/she need it.

----------
components:  -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:41:59 2008
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 25 Nov 2008 23:41:59 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227656519.78.0.185174293863.issue4366@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Nov 26 02:22:24 2008
From: report at bugs.python.org (LZ)
Date: Wed, 26 Nov 2008 01:22:24 +0000
Subject: [issue4432] IDLE.app (Mac) File Menu MIssing Options
In-Reply-To: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>
Message-ID: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>


New submission from LZ <zullil at lafayette.edu>:

Just compiled and installed 3.0rc3 configured with --enable-framework

I can start IDLE.app in /Applications/Python 3.0, but the only option in 
that application's File menu is a list of recent files. What about Open? 
What about Save? etc

----------
components: IDLE
messages: 76443
nosy: LZ
severity: normal
status: open
title: IDLE.app (Mac) File Menu MIssing Options
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4432>
_______________________________________

From report at bugs.python.org  Wed Nov 26 02:47:45 2008
From: report at bugs.python.org (=?utf-8?q?=E8=B5=B5=E7=8E=B0=E5=88=9A?=)
Date: Wed, 26 Nov 2008 01:47:45 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227646754.84.0.624794892069.issue4402@psf.upfronthosting.co.za>
Message-ID: <BAY112-W302A46DE615E5538427425F20A0@phx.gbl>


??? <zhaolu8 at hotmail.com> added the comment:

_________________________________________________________________
MSN???????In?????????????????
 http://top.msn.com.cn

Added file: http://bugs.python.org/file12131/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081126/8e40776b/attachment.txt>

From report at bugs.python.org  Wed Nov 26 04:23:15 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 26 Nov 2008 03:23:15 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1227669795.68.0.752590760528.issue4279@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

I can confirm this problem in 3.0rc3 on Cygwin.  If I could get some
direction from the Python devs on which method would be preferred
(accessor function vs. exposing data structure), I would be happy to
provide a patch.

----------
nosy: +yselkowitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:03:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 04:03:59 +0000
Subject: [issue3994] import fixer misses some symbols
In-Reply-To: <1222672392.58.0.438026225401.issue3994@psf.upfronthosting.co.za>
Message-ID: <1227672239.1.0.846799785816.issue3994@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I do have performance problems if I remove the match() override, but I
found that special casing usage replacements fixes the bug while keeping
speed.

Done in r67390. Nick, thanks for the debugging and the patch!

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3994>
_______________________________________

From report at bugs.python.org  Wed Nov 26 07:45:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 26 Nov 2008 06:45:31 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1afaf6160811251526r6ce4b9c8n4a25f6d0a2d1d81b@mail.gmail.com>
Message-ID: <492CF084.4090707@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This is true of many fixers. What is the use case?

In this case, I wanted to work around the fixer working incorrectly
for commands, but still have it continue to work for all the other
modules it fixes. The context is the setup.py script of Django.

> Is that reasonable also?

Sure! People will accept that they have to reorganize the source
before 2to3 can work correctly. More precisely, if they follow the
"convert once, cut the bridges" approach, they can just manually
unfix the few places that 2to3 got wrong. If they follow the
"single source" approach, they will accept that they have to
reformulate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 07:47:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 26 Nov 2008 06:47:21 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227682041.98.0.0973892995596.issue4366@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

2.5.3 is out of scope for this issue (and thus, the whole of 2.5). There
is no workable patch, yet, and 2.5.3 is just two weeks ahead.

----------
versions:  -Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Nov 26 07:52:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 26 Nov 2008 06:52:43 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1227682363.58.0.0330082594235.issue4279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the parser module should call one of the existing functions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:23:37 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 26 Nov 2008 08:23:37 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1227687817.8.0.347614889023.issue4279@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Attempting to export and use Py_meta_grammar() gives me a broken module,
based on the results of test/test_parser.py.

This patch, which exports _PyParser_Grammar, is very simple and the test
passes.

I will gladly take guidance on this patch.

Added file: http://bugs.python.org/file12132/3.0rc3-parsermodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:36:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 26 Nov 2008 08:36:06 +0000
Subject: [issue4433] _ctypes.COMError crash
In-Reply-To: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>
Message-ID: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

The following code, which only works on Windows, crashes with an access
violation somewhere in the garbage collector in a debug build:

>>> import _ctypes
[43470 refs]
>>> _ctypes.COMError(1, 2, 3)

The problem is that the PyComError_Type's tp_flags contains
Py_TPFLAGS_HAVE_GC although the tp_traverse slot is NULL.

The attached patch removes the Py_TPFLAGS_HAVE_GC which is not necessary
at all because a PyComError_Type instance (normally) only contains
simple objects (strings, numbers, None, and a tuple of strings, numbers,
and None), so no reference cycles should be possible.

----------
assignee: theller
components: ctypes
files: ctypes.patch
keywords: needs review, patch, patch
messages: 76451
nosy: theller
priority: release blocker
severity: normal
status: open
title: _ctypes.COMError crash
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12133/ctypes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4433>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:47:00 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 26 Nov 2008 08:47:00 +0000
Subject: [issue4429] ctypes.FormatError raises when the string to return
	contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227689220.41.0.56436053868.issue4429@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks for the review.  I commited the 'better' patch plus a NEWS entry
as svn rev. 67391.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:11:24 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 26 Nov 2008 09:11:24 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227639407.17.0.674767742462.issue4426@psf.upfronthosting.co.za>
Message-ID: <492D12B8.6030708@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-11-25 19:56, Nick Barnes wrote:
> Nick Barnes <Nick.Barnes at pobox.com> added the comment:
> 
> Well, I could submit a diff for unicodeobject.c, but I have never
> contributed to Python (or used this particular tracking system) before.
>  Is there a standard form for contributing changes?  Unified diff?

Please send unified diffs and attach them to the ticket.

While you're at it: perhaps you could try to refactor the code a bit
in order to get rid off the many macros use throughout the codec.
They make the code a lot less readable.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2008-11-12: Released mxODBC.Connect 0.9.3      http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

   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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:13:40 2008
From: report at bugs.python.org (rb)
Date: Wed, 26 Nov 2008 09:13:40 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>


New submission from rb <rb-oss-1 at justgohome.co.uk>:

Python cannot be embedded in shared library due to dependency problems
with lib-dynload.

I am implementing a shared library (in C) that implements a specific API
as a dynamically loadable plugin to an application. To implement this
library, I am calling out to Python via the C API.

When my code tries to load a Python module, it fails. This is because
lib-dynload/time.so (for example) cannot resolve symbols that are in
libpython2.5.so because it never looks there.

In this test case I'm trying to import "time", but it seems to fail on
other modules too - presumably anything that is in lib-dynload. It also
fails if I import a pure Python module that then tries to import time.

The error produced is: ImportError:
/usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError

>From LD_DEBUG:
     29682:file=/usr/lib/python2.5/lib-dynload/time.so [0];  needed by 
/usr/lib/libpython2.5.so.1.0 [0]
...
     29682:relocation processing: /usr/lib/python2.5/lib-dynload/time.so
     29682:symbol=PyExc_ValueError;  lookup in file=./myprog [0]
     29682:symbol=PyExc_ValueError;  lookup in file=/lib/libdl.so.2 [0]
     29682:symbol=PyExc_ValueError;  lookup in file=/lib/libc.so.6 [0]
     29682:symbol=PyExc_ValueError;  lookup in
file=/lib64/ld-linux-x86-64.so.2 [0]
     29682:symbol=PyExc_ValueError;  lookup in 
file=/usr/lib/python2.5/lib-dynload/time.so [0]
     29682:symbol=PyExc_ValueError;  lookup in file=/lib/libm.so.6 [0]
     29682:symbol=PyExc_ValueError;  lookup in file=/lib/libpthread.so.0 [0]
     29682:symbol=PyExc_ValueError;  lookup in file=/lib/libc.so.6 [0]
     29682:symbol=PyExc_ValueError;  lookup in
file=/lib64/ld-linux-x86-64.so.2 [0]
     29682:/usr/lib/python2.5/lib-dynload/time.so: error: symbol lookup
error: 
undefined symbol: PyExc_ValueError (fatal)


$ nm -D /usr/lib/libpython2.5.so.1|grep PyExc_ValueError
000000000033a7e0 D PyExc_ValueError



$ ldd /usr/lib/python2.5/lib-dynload/time.so
libm.so.6 => /lib/libm.so.6 (0x00002afe014c9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002afe0174a000)
libc.so.6 => /lib/libc.so.6 (0x00002afe01967000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)



I am told that the problem is that lib-dynload/*.so should depend on
libpython2.5.so.1.


Test case attached. mylib.c is the library that I'm implementing reduced
to the problem case. myprog.c is a stub program that loads mylib.c to
demonstrate the problem. The "real" myprog would be any third-party
application that I have no control over that expects to be able to
dlopen() mylib.so and call functions within it.


I have been given the following workaround: in mylib.c, before
PyInitialize() I can call dlopen("libpython2.5.so", RTLD_LAZY |
RTLD_GLOBAL);

This works, but I believe that lib-dynload/*.so should depend on
libpython2.5.so.1 so this hack should not be necessary.

I am using Ubuntu 8.04 with Python version 2.5.2-2ubuntu4.1.

----------
components: Library (Lib)
files: mylib.c
messages: 76454
nosy: rb
severity: normal
status: open
title: Embedding into a shared library fails
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12134/mylib.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:14:31 2008
From: report at bugs.python.org (rb)
Date: Wed, 26 Nov 2008 09:14:31 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227690871.38.0.818986992092.issue4434@psf.upfronthosting.co.za>


Changes by rb <rb-oss-1 at justgohome.co.uk>:


Added file: http://bugs.python.org/file12135/myprog.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:20:35 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 26 Nov 2008 09:20:35 +0000
Subject: [issue4435] Sphinx does not show failed doctests in quiet mode
In-Reply-To: <1227691235.13.0.763520768033.issue4435@psf.upfronthosting.co.za>
Message-ID: <1227691235.13.0.763520768033.issue4435@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

Sphinx does not show failed doctests when run in quiet mode. Any output
from the tests seems to be suppressed. The same applies to the linkckeck
builder.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 76455
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Sphinx does not show failed doctests in quiet mode
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4435>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:24:55 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 26 Nov 2008 09:24:55 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1227691495.35.0.140067452184.issue4279@psf.upfronthosting.co.za>


Changes by Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12132/3.0rc3-parsermodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Wed Nov 26 10:42:15 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 26 Nov 2008 09:42:15 +0000
Subject: [issue4436] Sphinx latex writer crashes when encountering deep
	section levels
In-Reply-To: <1227692535.17.0.165619686798.issue4436@psf.upfronthosting.co.za>
Message-ID: <1227692535.17.0.165619686798.issue4436@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

The Sphinx latex writer crashes if a documentation has more than 7
levels in a section hierarchy. The LaTeXTranslator class defines 7
section names, each corresponding to a level. If a deeper level is
encountered, no appropriate section name can be found:

File "[..]/svn/doctools/sphinx/latexwriter.py", line 348,  in visit_title
     print "self.sectionnames", self.sectionnames[self.sectionlevel]
IndexError: list index out of range

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 76456
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Sphinx latex writer crashes when encountering deep section levels
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4436>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:41:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Nov 2008 10:41:04 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227696064.14.0.734643170683.issue4402@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

(Clive's message was entirely in the HTML "unnamed" attachement)

Clive said:
> My python2.5 is from ActiveState, and python3.0 is the official.

Great.

But -- didn't you get the same behavior *before* installing python 3.0?
when python2.5 started from the "run" dialog box, didn't it get the same
addition to the PATH environment variable?

Martin: Could the msi installer remove the key named
"HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Windows\CURRENTVERSION\App
Paths\python.exe\Path"
when it is present? Or is this just a "Won't fix" issue?

----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:42:11 2008
From: report at bugs.python.org (Akira Kitada)
Date: Wed, 26 Nov 2008 10:42:11 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227696131.76.0.389513729615.issue4366@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Martin,
Two questions:

1. Isn't Christian's patch enough for this?
2. How about Python 3.0 and 2.6.1? Are they also out of scope for this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:43:59 2008
From: report at bugs.python.org (Francois Grieu)
Date: Wed, 26 Nov 2008 10:43:59 +0000
Subject: [issue4437] Windows 32-bit installer crash on "cancel" in "advanced"
	settings
In-Reply-To: <1227696239.72.0.87378964191.issue4437@psf.upfronthosting.co.za>
Message-ID: <1227696239.72.0.87378964191.issue4437@psf.upfronthosting.co.za>


New submission from Francois Grieu <fgrieu at francenet.fr>:

On an Windows XP 32-bit system without Python installed
- launch python-2.6.msi (md5 6c62c123d248a48dccbaa4d3edc12680)
- click "next >" "next >" "advanced" "cancel" "yes"
- msiexex.exe crashes (repeatable).

Installation works fine if one do not press "advanced", or press
"finish" instead of "cancel".

----------
components: Installation
messages: 76459
nosy: fgrieu
severity: normal
status: open
title: Windows 32-bit installer crash on "cancel" in "advanced" settings
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4437>
_______________________________________

From report at bugs.python.org  Wed Nov 26 12:58:39 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 11:58:39 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>


New submission from Mart S?mermaa <mrts at mrts.pri.ee>:

The need to dynamically import module foo given a module name string
'bar.baz.foo' is quite common.

Quite often, the hack described in http://bugs.python.org/issue2090 is
used (see e.g. the Google code results linked from the issue).

Quoting Brett Cannon from the issue:
"I plan to add a much simpler API to the imp module for people to use
directly so that these abuses don't continue."

Although there are reasonable workarounds, let the current ticket be a
remainder for Brett that his plan is indeed needed.

Perhaps the easiest thing to do would be to add yet another argument,
e.g. 'toplevel', to __import__, such that:

>>> __import__('imprt.foo.foo') # toplevel=True by default
<module 'imprt' from 'imprt/__init__.pyc'>
>>> __import__('imprt.foo.foo', toplevel=False)
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>

The latter can currently be achieved by

>>> __import__('imprt.foo.foo', {}, {}, ['foo'])
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>

which is cumbersome if the module name is given in a string, resulting
in unnecessarily complex code:

modname = "imprt.foo.foo"
>>> __import__(modname, {}, {}, [modname.rsplit(".", 1)[-1]])
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>

----------
components: Interpreter Core, Library (Lib)
messages: 76460
nosy: mrts
severity: normal
status: open
title: Add an easy way to __import___ submodules
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:01:06 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 12:01:06 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1227700866.5.0.916449993922.issue2090@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Just for reference, the simplest workaround is to use:

modname = "foo.bar.baz.baq"
mod = __import__(modname, {}, {}, [modname.rsplit(".", 1)[-1]])

----------
nosy: +mrts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:02:10 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 12:02:10 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1227700930.73.0.447586627042.issue2090@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

See also http://bugs.python.org/issue4438

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:10:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Nov 2008 12:10:36 +0000
Subject: [issue2491] io.open() handles errors differently on different
	platforms
In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
Message-ID: <1227701436.97.0.87019189448.issue2491@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2491>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:12:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Nov 2008 12:12:19 +0000
Subject: [issue4437] Windows 32-bit installer crash on "cancel" in "advanced"
	settings
In-Reply-To: <1227696239.72.0.87378964191.issue4437@psf.upfronthosting.co.za>
Message-ID: <1227701539.04.0.579280398542.issue4437@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Already corrected with issue4289.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python 2.6 installer crashes when selecting 'advanced' and cancelling it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4437>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:26:58 2008
From: report at bugs.python.org (sebek)
Date: Wed, 26 Nov 2008 13:26:58 +0000
Subject: [issue1772794] Telnetlib dosn't accept u'only ascii'
Message-ID: <1227706018.99.0.511307519421.issue1772794@psf.upfronthosting.co.za>


sebek <sebeeek at gmail.com> added the comment:

I wonder if it is the same problem as bug #3725.
In this case it has been fixed in r66904 where telnetlib knows only
understand bytes instead of characters.

see http://bugs.python.org/issue3725

----------
nosy: +sebek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772794>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:41:01 2008
From: report at bugs.python.org (John Levon)
Date: Wed, 26 Nov 2008 13:41:01 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227706861.28.0.887973804849.issue4434@psf.upfronthosting.co.za>


Changes by John Levon <movement at users.sourceforge.net>:


----------
nosy: +movement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:48:45 2008
From: report at bugs.python.org (olt)
Date: Wed, 26 Nov 2008 13:48:45 +0000
Subject: [issue4439] Typo in sqlite3 documentation.
In-Reply-To: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>
Message-ID: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>


New submission from olt <olt at bogosoft.com>:

There is a small typo in the possible Connection.isolation_level
http://docs.python.org/library/sqlite3.html#connection-objects
Its EXCLUSIVE not EXLUSIVE.

----------
components: Distutils
messages: 76465
nosy: olt
severity: normal
status: open
title: Typo in sqlite3 documentation.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4439>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:49:14 2008
From: report at bugs.python.org (olt)
Date: Wed, 26 Nov 2008 13:49:14 +0000
Subject: [issue4439] Typo in sqlite3 documentation.
In-Reply-To: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>
Message-ID: <1227707354.75.0.0966362345339.issue4439@psf.upfronthosting.co.za>


Changes by olt <olt at bogosoft.com>:


----------
assignee:  -> georg.brandl
components: +Documentation -Distutils
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4439>
_______________________________________

From report at bugs.python.org  Wed Nov 26 15:23:59 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 14:23:59 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227709439.1.0.0951303831853.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Attached is a naive proof-of-concept implementation (that breaks things,
i.e. the real implementation should strive for better
general compatibility), but works as expected:

>>> __import__('imprt.foo.foo', submodule=True)
<module 'imprt.foo.foo' from 'imprt/foo/foo.py'>

>>> __import__('imprt.foo.foo', submodule=False)   
<module 'imprt' from 'imprt/__init__.py'>

>>> __import__('imprt.foo.foo')
<module 'imprt' from 'imprt/__init__.py'>

# Die on unexpected arguments like strings, lists etc to
# avoid confusion
>>> __import__('imprt.foo.foo', submodule='z')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

----------
keywords: +patch
Added file: http://bugs.python.org/file12136/issue4438.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:00:51 2008
From: report at bugs.python.org (Marcin Bachry)
Date: Wed, 26 Nov 2008 15:00:51 +0000
Subject: [issue4440] "sort" command doesn't work in pstats if run interactively
In-Reply-To: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
Message-ID: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>


New submission from Marcin Bachry <hegel666 at gmail.com>:

Sort command in Python's 3.0 pstats doesn't accept any valid argument
and views help all the time:

$ python3.0 -m pstats pstats
Welcome to the profile statistics browser.
% sort cumulative
Valid sort keys (unique prefixes are accepted):
stdname -- standard name
nfl -- name/file/line
pcalls -- call count
file -- file name
calls -- call count
time -- internal time
line -- line number
cumulative -- cumulative time
module -- file name
name -- function name
%

----------
components: Library (Lib)
files: pstats-fix.diff
keywords: patch
messages: 76467
nosy: marcin.bachry
severity: normal
status: open
title: "sort" command doesn't work in pstats if run interactively
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12137/pstats-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4440>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:16:54 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 15:16:54 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227712614.09.0.655156700004.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Just a note that `make test` passes:

322 tests OK.
38 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dbm test_dl test_gl test_imageop test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_normalization
    test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
    test_socketserver test_startfile test_sunaudiodev test_tcl
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_zipfile64
3 skips unexpected on linux2:
    test_tcl test_dbm test_bsddb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:22:15 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Nov 2008 15:22:15 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227712935.83.0.458585259912.issue4329@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is, as far as I know, intended to be backwards compatible except for
where it fixes bugs.  Upgrading to 2.6 does (should) not change strings
(type str) to unicode.  Only importing the appropriate __future__ or
upgrading to 3.0 will do that.  I have no idea what Django does.

The 3 lines of code you posted gives exactly the same traceback in my
copy of 2.5 as the one you posted.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:47:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 15:47:31 +0000
Subject: [issue4433] _ctypes.COMError crash
In-Reply-To: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>
Message-ID: <1227714451.37.0.959968277264.issue4433@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Looks good.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4433>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:49:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 15:49:08 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1227714548.87.0.753717817285.issue3020@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: collinwinter -> 
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Wed Nov 26 17:21:50 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Nov 2008 16:21:50 +0000
Subject: [issue4441] Improve os open flag options doc
In-Reply-To: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za>
Message-ID: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

os module doc, File Descriptor Operations, at end.

Suggestions:

1. Replace
"The following data items are available for use in constructing the
flags parameter to the open() function."
with
"The following data items are options for the flag argument to the
open() function. These can be combined using the bitwise OR operator |."
(and remove the redundant text from the block headings -- see below).

2. In the next sentence, replace 'will not be' with 'are not'.

3. The next sentence ends with 'consult open(2).' I presume this refers
to unix manual section on the open system call.  This is cryptic and
useless to many Windows users.  Where are descriptions for flags valid
on Windows?

4. Block captions: remove repeated text and move availability note above
rather than below the block. 'Available on Unix and Windows', 'Available
on Unix only', 'Available on Windows only', 'Gnu extensions....'.

5. The items in the fifth block are *not* open() options.  The caption
should instead be an un-indented introductory sentence before the block.
"The following data items are parameters to the lseek() function. ..."

----------
assignee: georg.brandl
components: Documentation
messages: 76471
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improve os open flag options doc
versions: Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4441>
_______________________________________

From report at bugs.python.org  Wed Nov 26 17:50:24 2008
From: report at bugs.python.org (Michael Becker)
Date: Wed, 26 Nov 2008 16:50:24 +0000
Subject: [issue4329] base64 does not properly handle unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1227718224.24.0.446912891431.issue4329@psf.upfronthosting.co.za>


Michael Becker <spammb at gmail.com> added the comment:

Terry,
I had a feeling Django had something to do with this. I'll have a closer
look there. For reference, in my django code, I did not explicitly
declare the string as a unicode string. Django must be importing
unicode_literals from __future__ as you suggested. I'll have a closer
look there. 

Just out of curiosity, would the 2to3 tool have resolved this issue come
3.0? Would it have change the type to a bytes? Or, would this issue need
to be caught in unit tests?

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:08:02 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 26 Nov 2008 17:08:02 +0000
Subject: [issue4442] datetime not subclassable in the usual way
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

>>> from datetime import datetime
>>> class defaultdatetime(datetime):
...   defaults=(2001,1,1)
...   def __init__(self,*args):
...     if not args:
...       args = self.defaults
...     datetime.__init__(self,*args)
...
>>> defaultdatetime()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes at least 3 arguments (0 given)

----------
components: Library (Lib)
messages: 76473
nosy: cjw296
severity: normal
status: open
title: datetime not subclassable in the usual way
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:18:21 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 26 Nov 2008 17:18:21 +0000
Subject: [issue4442] datetime not subclassable in the usual way
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1227719901.55.0.723746312882.issue4442@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Sorry, forgot to say that the above is at best counterintuitive and not
documented anywhere...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:24:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 17:24:58 +0000
Subject: [issue4442] datetime not subclassable in the usual way
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1227720298.62.0.146248172352.issue4442@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is because datetime does all its initialization in __new__ instead
of __init__.

----------
nosy: +benjamin.peterson
priority:  -> normal
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:35:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 17:35:51 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <492CF084.4090707@v.loewis.de>
Message-ID: <1afaf6160811260935l23b1faa6kf3b4aaff407d5755@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Wed, Nov 26, 2008 at 12:45 AM, Martin v. L?wis
<report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> This is true of many fixers. What is the use case?
>
> In this case, I wanted to work around the fixer working incorrectly
> for commands, but still have it continue to work for all the other
> modules it fixes. The context is the setup.py script of Django.

I wonder if a better way would be to configure the imports fixer
through the options dict passed to RefactoringTool. i.e.

 RefactoringTool(..., {"fix_imports:dont_transform" : ["commands",
"other_module"]})

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:39:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 17:39:38 +0000
Subject: [issue4439] Typo in sqlite3 documentation.
In-Reply-To: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>
Message-ID: <1227721178.61.0.54405985183.issue4439@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the report! Fixed in r67398.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4439>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:41:32 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 26 Nov 2008 17:41:32 +0000
Subject: [issue4442] datetime not subclassable in the usual way
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1227721292.38.0.428723967576.issue4442@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

But that isn't documented anywhere...

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________

From report at bugs.python.org  Wed Nov 26 19:05:25 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 26 Nov 2008 18:05:25 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227722725.82.0.956261119218.issue4434@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

ubuntu comes with a static libpython.a which you can also link against.
Linking the c modules against the shared python library would make that
static library pretty much useless...

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Wed Nov 26 19:52:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 26 Nov 2008 18:52:23 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227696131.76.0.389513729615.issue4366@psf.upfronthosting.co.za>
Message-ID: <492D9AE3.9000903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 1. Isn't Christian's patch enough for this?

No. It should be dealt with in the same way as on Linux (or the Linux
way should be changed).

> 2. How about Python 3.0 and 2.6.1? Are they also out of scope for this?

Not yet, no. However, they are soon to be released, so chances are low
that a patch arrives in time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Nov 26 19:55:17 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 26 Nov 2008 18:55:17 +0000
Subject: [issue4433] _ctypes.COMError crash
In-Reply-To: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>
Message-ID: <1227725717.37.0.610480415902.issue4433@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks for the review; committed as svn rev. 67402.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4433>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:00:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 26 Nov 2008 19:00:38 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1afaf6160811260935l23b1faa6kf3b4aaff407d5755@mail.gmail.com>
Message-ID: <492D9CD2.6010409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I wonder if a better way would be to configure the imports fixer
> through the options dict passed to RefactoringTool. i.e.
> 
>  RefactoringTool(..., {"fix_imports:dont_transform" : ["commands",
> "other_module"]})

That's very obscure, IMO. I didn't know that syntax existed, and
I can't guess easily what it means (in general).

In the specific case, it's also difficult to pass the options,
since the distutils command doesn't support doing so.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:30:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 19:30:25 +0000
Subject: [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227727825.48.0.768811857947.issue4423@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. The building of the pattern in fix_imports is changed to
compile_pattern in r67404.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:43:34 2008
From: report at bugs.python.org (LuisC)
Date: Wed, 26 Nov 2008 19:43:34 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>


New submission from LuisC <luis.carrion at tcs.com>:

The project goal is to incorporate the functionality of interaction of 
the excel application (gnumeric) with the XO's journal. All the 
activities needs to register any change in that datastore (save and 
open files are made throw it). 

In order to apply this option, we need to call some python code from 
the implementation of the worksheet in C code. This is called embedded 
python in C. The steps followed to accomplish this goal came from the 
OLPC site recomendations, in wiki.laptop.org. The python script for the 
interaction with the journal's datastore can be found in here: 
http://wiki.laptop.org/go/Copy_to_and_from_the_Journal 

The changes in the gnumeric code are basically in the workbook-view.c 
and main-application.c to handle the open and save options. In the main-
application.c the method gui_file_copy_from_journal uses the python 
api/c to make the call to the journal script. after this method and 
during the open of the file, an exception rises. Although we are not 
sure, we believe it has to do with the closure of the python enviroment 
after the finalize call. We need to erase this exception or may be just 
handle it. 

The error running in the XO is: 

gnumeric: Python/pystate.c:561 :PyGILState: The 
assertion 'autoInterpreterState' has failed 

The configuration of the XO where we are getting the exception is: 

Python 2.5 (r25:51908, Oct 19 2007, 09:47:40) [gcc 4.1.2 20070925 (Red 
Hat 4.1.2-27)] on linux2 

Any help is greatly appreciated!!!

----------
components: Interpreter Core
messages: 76484
nosy: barry, brett.cannon, doerwalter, gvanrossum, lcarrionr, lemburg, mwh
severity: normal
status: open
title: Python/pystate.c:561 :PyGILState: The assertion 'autoInterpreterState' has failed
type: resource usage
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:53:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Nov 2008 19:53:38 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227729218.47.0.656143663846.issue4443@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Is this an actual bug report or more of a request for help? If it is the
former then a test case is needed in order to help figure out what is
going on. If it is the latter you should ask on
comp.lang.python/python-list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:59:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 19:59:43 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227729583.26.0.861730949633.issue4443@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Also, please do not add everyone in the project to the nosy list.

----------
nosy: +benjamin.peterson -barry, doerwalter, gvanrossum, lemburg, mwh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Wed Nov 26 21:00:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2008 20:00:06 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227729606.86.0.359884930956.issue4443@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy:  -benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From jeremy at alum.mit.edu  Wed Nov 26 22:53:51 2008
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 26 Nov 2008 16:53:51 -0500
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227611620.52.0.772028483822.issue4336@psf.upfronthosting.co.za>
References: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
	<1227611620.52.0.772028483822.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811261353i365c018fk5702e33620835ae8@mail.gmail.com>

I think we're making progress, but I'm still not sure about the new
httplib api.  My current worry is that endheaders() behaves very
differently when send_data is false.  My chief concern is that the
__state variable is going to indicate that the request has been sent
when we're really depending on the client to send the header.  In
general, I don't like the public send() method since it's exposing a
raw socket that could be called at any time regardless of the _state
of the object.

What if endheaders() takes body as an optional argument and sends it
along with the headers?  This accomplishes the same basic goal as
returning the header from endheaders(), but keeps the actual sending
of data encapsulated within the http connection.

Jeremy

On Tue, Nov 25, 2008 at 6:13 AM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> I have addressed some issues mentioned:
> 1) I have retained the _send_output() method.
> 2) the endheaders() method now takes an optional argument, send_data
> that defaults to True.  It also returns any unsent data as a string.
> This simplifies any code wishing to send more data.
> 3) The old HTTP class needs no changes anymore.
> 4) I've fixed the test_xmlrpc.py test case to run all the tests on
> windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer
> valid.
> 5) concatenating the result from endheaders() with the request body is
> valid, in xmlrpclib, because the assumption has already been made in
> send_content() that request_body is a string (str(len(request_body)).
> However, in httplib's request() method, we now special case this.  I
> don't want to complicate the code for what appears to be a rare case.
>
> I chose not to mess with xmlrpclib and make it continue to use the old
> HTTP class in order to minimise the extent of this patch.  A simple and
> clear performance patch has in my experience a much greater chance of
> finding its way into the codebase than a more extensive rewrite :)
>
> You may have concerns regarding point 3 above, and I am open to
> suggestions.
>
> Now, what remains is the question of the read buffering for the socket
> fileobject.  Do you think that it is feasible to simply change the
> default read buffering for fileobjects to use buffering for readline()
> same as they do for read()?  Then we wouldn't need the second half of
> this patch and we could make a separate "socket" performance patch.
>
> Added file: http://bugs.python.org/file12127/xmlrpc.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Wed Nov 26 22:53:59 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Wed, 26 Nov 2008 21:53:59 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227611620.52.0.772028483822.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811261353i365c018fk5702e33620835ae8@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I think we're making progress, but I'm still not sure about the new
httplib api.  My current worry is that endheaders() behaves very
differently when send_data is false.  My chief concern is that the
__state variable is going to indicate that the request has been sent
when we're really depending on the client to send the header.  In
general, I don't like the public send() method since it's exposing a
raw socket that could be called at any time regardless of the _state
of the object.

What if endheaders() takes body as an optional argument and sends it
along with the headers?  This accomplishes the same basic goal as
returning the header from endheaders(), but keeps the actual sending
of data encapsulated within the http connection.

Jeremy

On Tue, Nov 25, 2008 at 6:13 AM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> I have addressed some issues mentioned:
> 1) I have retained the _send_output() method.
> 2) the endheaders() method now takes an optional argument, send_data
> that defaults to True.  It also returns any unsent data as a string.
> This simplifies any code wishing to send more data.
> 3) The old HTTP class needs no changes anymore.
> 4) I've fixed the test_xmlrpc.py test case to run all the tests on
> windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer
> valid.
> 5) concatenating the result from endheaders() with the request body is
> valid, in xmlrpclib, because the assumption has already been made in
> send_content() that request_body is a string (str(len(request_body)).
> However, in httplib's request() method, we now special case this.  I
> don't want to complicate the code for what appears to be a rare case.
>
> I chose not to mess with xmlrpclib and make it continue to use the old
> HTTP class in order to minimise the extent of this patch.  A simple and
> clear performance patch has in my experience a much greater chance of
> finding its way into the codebase than a more extensive rewrite :)
>
> You may have concerns regarding point 3 above, and I am open to
> suggestions.
>
> Now, what remains is the question of the read buffering for the socket
> fileobject.  Do you think that it is feasible to simply change the
> default read buffering for fileobjects to use buffering for readline()
> same as they do for read()?  Then we wouldn't need the second half of
> this patch and we could make a separate "socket" performance patch.
>
> Added file: http://bugs.python.org/file12127/xmlrpc.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Thu Nov 27 02:43:02 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 27 Nov 2008 01:43:02 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1227750182.9.0.970618664793.issue1755388@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Yes, I know it's a bug, and certainly closing this report won't help 
solve it. I can't reopen this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Thu Nov 27 10:22:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 27 Nov 2008 09:22:45 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227777765.28.0.394458436284.issue4443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The assertion is clear if you open the source code (Python/pystate.c,
line 561):

assert(autoInterpreterState); /* Py_Initialize() hasn't been called! */

Does your code make sure that the python interpreter is initialized?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Thu Nov 27 10:50:00 2008
From: report at bugs.python.org (David Leonard)
Date: Thu, 27 Nov 2008 09:50:00 +0000
Subject: [issue4444] unittest - use contexts to assert exceptions
In-Reply-To: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za>
Message-ID: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za>


New submission from David Leonard <d+python at adaptive-enterprises.com>:

Patch to allow unit tests to test for exceptions through a 'with' 
statement. Resulting (failing) test would look like this:

  import unittest

  class T(unittest.TestCase):
     def runTest(self):
        with self.assertRaises(KeyError):
           raise ValueError

This saves having to put exception raising tests into a try/except 
block, which is cool. And by cool I mean totally sweet.

----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 76492
nosy: dleonard0
severity: normal
status: open
title: unittest - use contexts to assert exceptions
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12138/unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4444>
_______________________________________

From report at bugs.python.org  Thu Nov 27 12:59:38 2008
From: report at bugs.python.org (LuisC)
Date: Thu, 27 Nov 2008 11:59:38 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227777765.28.0.394458436284.issue4443@psf.upfronthosting.co.za>
Message-ID: <OF827BA364.7C154707-ON8325750E.0041BEBB-8325750E.0041DB6D@tcs.com>


LuisC <luis.carrion at tcs.com> added the comment:

Hi Amaury, thanks for you response...

This is my code sniped

gboolean
gui_file_copy_to_journal(char const *uri)
{
        g_printerr("SAVING PYTHON JOURNAL!...........%s\n", uri);

        char * arg1[7];

        arg1[0] = "python";
        arg1[1] = "/home/olpc/copy-to-Journal.py"; 
        arg1[2] = uri+7;
        arg1[3] = "-d";
        arg1[4] = "hoja_de_calculo"; 
        arg1[5] = "-m";
        arg1[6] = "application/x-gnumeric"; 

        g_printerr ("Writing py \n");
        Py_Initialize(); 
        Py_Main(7, arg1);
        Py_Finalize();
        g_printerr ("Writing Py_Finalize \n");

        return TRUE;
}

also, I tried with other method like linux journal show in 
http://www.linuxjournal.com/article/3641

Any help is greatly appreciated...

Luis Carri?n
Tata Consultancy Services
Colonia 1329-Piso 3
Montevideo,.
Uruguay
Mailto: luis.carrion at tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________

Amaury Forgeot d'Arc <report at bugs.python.org> 
27/11/2008 07:22 a.m.
Please respond to
Python tracker <report at bugs.python.org>

To
luis.carrion at tcs.com
cc

Subject
[issue4443] Python/pystate.c:561 :PyGILState: The assertion 
'autoInterpreterState' has failed

Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The assertion is clear if you open the source code (Python/pystate.c,
line 561):

assert(autoInterpreterState); /* Py_Initialize() hasn't been called! */

Does your code make sure that the python interpreter is initialized?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

ForwardSourceID:NT0000A7E6 
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Added file: http://bugs.python.org/file12139/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081127/a912d33c/attachment.txt>

From report at bugs.python.org  Thu Nov 27 13:11:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 27 Nov 2008 12:11:34 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227787894.34.0.968084553456.issue4443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Py_Initialize(); 
> Py_Main(7, arg1);
> Py_Finalize();

This seems correct... unless two threads run this function at the same
time. Can you ensure that this is not the case?

It seems to me that a simple call to 
   system("python /home/olpc/copy-to-Journal.py [other-args-here]") 
would be better...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:15:01 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2008 12:15:01 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

There are a number of places in Objects/stringobject.c where memory is 
allocated for a string of length n using:

PyObject_MALLOC(sizeof(PyStringObject) + n)

On my computer (OS X 10.5.5/Intel), and, I suspect, on most common 
platforms, the PyStringObject struct is going to contain some number of 
bytes (probably 3) of trailing padding;  the result is that the 
PyObject_MALLOC call above asks for 3 more bytes than are necessary, and 
on average the Python interpreter will waste 3 bytes of memory per string 
allocation.  Is there any reason not to replace these calls with:

PyObject_MALLOC(offsetof(PyStringObject, ob_sval) + n + 1)

instead?

Patch attached.

----------
components: Interpreter Core
files: string_alloc.patch
keywords: patch
messages: 76495
nosy: marketdickinson
severity: normal
status: open
title: String allocations waste 3 bytes of memory on average.
type: performance
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12140/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:18:25 2008
From: report at bugs.python.org (Nick Barnes)
Date: Thu, 27 Nov 2008 12:18:25 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227788305.07.0.41362631639.issue4426@psf.upfronthosting.co.za>


Nick Barnes <Nick.Barnes at pobox.com> added the comment:

I'll try to get to this next week.  Right now I'm snowed under.  I don't
promise to do any refactoring.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:53:31 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Thu, 27 Nov 2008 12:53:31 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227790411.99.0.728276334373.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Corrections and clarifications:

 * I'd say labeling the patch naive and "breaking things" was misleading
(there was a breakage that resulted from stale files with incorrect
permissions from my previous build of Python 2.6; after a make distclean
all tests passed as described above). The patch is correct and
backwards-compatible in Python level, but it introduces a change in the
C API:

 PyAPI_FUNC(PyObject *) PyImport_ImportModuleLevel(char *name,
-       PyObject *globals, PyObject *locals, PyObject *fromlist, int level);
+       PyObject *globals, PyObject *locals, PyObject *fromlist,
+       int level, char submodule);


 * The patch was made against Python 2.6 release source.

 * The argument is named 'submodule' instead of 'toplevel' to avoid
confusion with 'level'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:54:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2008 12:54:44 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227790484.05.0.0421029267923.issue4445@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch: fix overflow checks to use offsetof instead of sizeof as 
well.

Added file: http://bugs.python.org/file12141/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:54:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2008 12:54:47 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227790487.13.0.716417807089.issue4445@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file12140/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:50:40 2008
From: report at bugs.python.org (Simon Cross)
Date: Thu, 27 Nov 2008 13:50:40 +0000
Subject: [issue4446] Distutils Metadata Documentation Missing "platforms"
	Keyword
In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za>
Message-ID: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za>


New submission from Simon Cross <hodgestar at gmail.com>:

The section on Additional meta-data in Doc/distutils/setupscript.rst is
missing any reference to the setup() "platforms" keyword. I've attached
a patch which fills in the basics but there are some outstanding questions:

 - Does note (4) about backwards compatibility with earlier versions of
Python apply?

 - What strings should be used to describe each platform? Perhaps any
final element of an "Operating System ::" trove classifier?

 - Given that we have the classifiers, is the "platforms" keyword
actually needed? Perhaps the docs should just mark it as deprecated? We
would then maybe need to change distutils to populate the platforms key
in PKG-INFO from the classifiers?

----------
assignee: georg.brandl
components: Documentation
files: distutils-platforms-keyword-documentation.diff
keywords: patch
messages: 76499
nosy: georg.brandl, hodgestar
severity: normal
status: open
title: Distutils Metadata Documentation Missing "platforms" Keyword
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12142/distutils-platforms-keyword-documentation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4446>
_______________________________________

From report at bugs.python.org  Thu Nov 27 15:07:42 2008
From: report at bugs.python.org (Steve Purcell)
Date: Thu, 27 Nov 2008 14:07:42 +0000
Subject: [issue4444] unittest - use contexts to assert exceptions
In-Reply-To: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za>
Message-ID: <1227794862.52.0.72831518265.issue4444@psf.upfronthosting.co.za>


Steve Purcell <purcell at users.sourceforge.net> added the comment:

I like this change, since assertRaises can be a bit messy when passing it 
a local function.
 
I'd suggest modifying the patch such that the AssertRaisesContext class is 
also used when callableObj is provided, which would eliminate the 
duplication of the code that checks for exceptions.

----------
nosy: +purcell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4444>
_______________________________________

From report at bugs.python.org  Thu Nov 27 15:41:29 2008
From: report at bugs.python.org (LuisC)
Date: Thu, 27 Nov 2008 14:41:29 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227787894.34.0.968084553456.issue4443@psf.upfronthosting.co.za>
Message-ID: <OFD942B17E.2D995FCB-ON8325750E.004D0F13-8325750E.0050B20E@tcs.com>


LuisC <luis.carrion at tcs.com> added the comment:

Thank you so much. It do worked!

I don't think two threads to be running the same function because the 
messages are displayed only once.
Yes it seems to be a better way it worked, thank you again.

Regards, 

Luis Carri?n
Tata Consultancy Services
Colonia 1329-Piso 3
Montevideo,.
Uruguay
Mailto: luis.carrion at tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________

Amaury Forgeot d'Arc <report at bugs.python.org> 
27/11/2008 10:11 a.m.
Please respond to
Python tracker <report at bugs.python.org>

To
luis.carrion at tcs.com
cc

Subject
[issue4443] Python/pystate.c:561 :PyGILState: The assertion 
'autoInterpreterState' has failed

Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Py_Initialize(); 
> Py_Main(7, arg1);
> Py_Finalize();

This seems correct... unless two threads run this function at the same
time. Can you ensure that this is not the case?

It seems to me that a simple call to 
   system("python /home/olpc/copy-to-Journal.py [other-args-here]") 
would be better...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

ForwardSourceID:NT0000A982 
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Added file: http://bugs.python.org/file12143/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081127/bbd8eceb/attachment.txt>

From report at bugs.python.org  Thu Nov 27 16:07:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 27 Nov 2008 15:07:12 +0000
Subject: [issue4443] Python/pystate.c:561 :PyGILState: The assertion
	'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227798432.82.0.0235404310691.issue4443@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________

From report at bugs.python.org  Thu Nov 27 17:06:57 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 27 Nov 2008 16:06:57 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227802017.05.0.636920306462.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I like the suggestion of having endheaders() accept any extra data.
I have uploaded a new patch which implements this idea.  It simplifies 
things a lot.

The issue with the read buffer size is still open.  I have sent an 
email to python-dev requesting comments.

Added file: http://bugs.python.org/file12144/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Thu Nov 27 17:57:33 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2008 16:57:33 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227805053.96.0.828437582757.issue4445@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on the idea.  -1 on the current patch.  Can you encapsulate this in a
simpler macro?  I find the proposed replacement to be cryptic and
error-prone (i.e. hard to mentally verify its correctness and somewhat
likely to be screwed-up by a future maintainer).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:07:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Nov 2008 17:07:20 +0000
Subject: [issue4435] Sphinx does not show failed doctests in quiet mode
In-Reply-To: <1227691235.13.0.763520768033.issue4435@psf.upfronthosting.co.za>
Message-ID: <1227805640.84.0.415620726529.issue4435@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4435>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:07:56 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Nov 2008 17:07:56 +0000
Subject: [issue4436] Sphinx latex writer crashes when encountering deep
	section levels
In-Reply-To: <1227692535.17.0.165619686798.issue4436@psf.upfronthosting.co.za>
Message-ID: <1227805676.34.0.180420591243.issue4436@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues

(Yes, I know there was still a Sphinx component -- I've removed that now.)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4436>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:08:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Nov 2008 17:08:44 +0000
Subject: [issue4446] Distutils Metadata Documentation Missing "platforms"
	Keyword
In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za>
Message-ID: <1227805724.39.0.114181595303.issue4446@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4446>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:31:58 2008
From: report at bugs.python.org (rb)
Date: Thu, 27 Nov 2008 17:31:58 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227807118.36.0.717226204433.issue4434@psf.upfronthosting.co.za>


rb <rb-oss-1 at justgohome.co.uk> added the comment:

What is the purpose of linking to the static library if you're still
going to depend on shared objects in lib-dynload?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:33:10 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 27 Nov 2008 17:33:10 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1227807190.4.0.717144475364.issue4010@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I'm having similar problem with distutils.
http://mail.python.org/pipermail/python-dev/2008-November/083670.html

Is there any reason customize_compiler 
- only get CPPFLAGS in env, not ones from sysconfig?
- doesn't get OPT from from sysconfig, but it's used when env has CFLAGS?

I think this is a bug.
CPPFLAGS and OPT both should be used when building extension modules.
Just imagine a system that has include files in a non-standard locations
and explicitly added -I compiler flags to CPPFLAGS to adjust it.
When building an extension modules, the system should requires
the same CPPFLAGS settings. Without it, it won't compile.

In my opinion, this is rather serious bug.
So it would be nice to fix this before releasing Python 3.0/2.6.1/2.5.3

----------
nosy: +akitada
type: behavior -> compile error
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:35:02 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 27 Nov 2008 17:35:02 +0000
Subject: [issue4447] exec inside a function
In-Reply-To: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>
Message-ID: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Is the following code valid Python 3 or not?

def foo():
    x = 1
    exec("x = 42")
    print(x)    # Prints 1  (exec has no effect)

I know there are a variety of issues surrounding exec(), function 
bodies, and other matters.   Just wondering if this sort of thing is now 
forbidden or not.

----------
components: Interpreter Core
messages: 76508
nosy: beazley
severity: normal
status: open
title: exec inside a function
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4447>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:47:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Nov 2008 17:47:21 +0000
Subject: [issue4447] exec inside a function
In-Reply-To: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>
Message-ID: <1227808041.76.0.167850463445.issue4447@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is "valid" Python 3 and the lack of an effect on the local is correct.

>From Python 3 on, "exec" is a function and therefore lacks the special
magic properties it had in Python 2 that made it possible execute the
code "as if it just was written there".

In effect, what exec() modifies here is similar to what locals()
returns: a mere copy of the local namespace.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4447>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:48:45 2008
From: report at bugs.python.org (John Levon)
Date: Thu, 27 Nov 2008 17:48:45 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227808125.86.0.721438340668.issue4434@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Besides, .so files should always declare their dependencies.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu Nov 27 19:07:19 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 27 Nov 2008 18:07:19 +0000
Subject: [issue4447] exec inside a function
In-Reply-To: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>
Message-ID: <1227809239.49.0.395306139174.issue4447@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

For what it's worth, I hope this behavior gets well-documented.  Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4447>
_______________________________________

From report at bugs.python.org  Thu Nov 27 19:42:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2008 18:42:25 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227811345.66.0.0434737471672.issue4445@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Suggestion:

#define PyStringObject_SIZE (offsetof(PyStringObject, ob_sval) + 1)


 	/* Inline PyObject_NewVar */
-	op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size);
 	/* Inline PyObject_NewVar */
+	op = (PyStringObject *)PyObject_MALLOC(PyStringObject_SIZE + size);

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:20:46 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 27 Nov 2008 19:20:46 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1227813646.73.0.547516430997.issue4376@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Currently, the _fields_ of ctypes Structures with non-native byte order
can only contain simple types (like int, char, but not pointers), and
arrays of those.

Since this is all Python code (in Lib/ctypes/endian.py) it should be
possible to extend the code to handle other types as well.

If we do this, it must be decided if a Structure (call it 'part' for
this discussion) of some byte order is contained in a _field_ of a
non-native Structure type:
- Should 'part' be inserted as is, leading to a total structure of
fields with mixed byte order?

- Should a new type be created from the 'part' _fields_, with also
non-native byte-order?

Other approaches would be possible as well...

Here is a simple patch that implements the first approach; I have not
tested if it works correctly:

Index: _endian.py
===================================================================
--- _endian.py	(revision 67045)
+++ _endian.py	(working copy)
@@ -17,6 +17,8 @@
     except AttributeError:
         if type(typ) == _array_type:
             return _other_endian(typ._type_) * typ._length_
+        if issubclass(typ, Structure):
+            return typ
         raise TypeError("This type does not support other endian: %s" %
typ)
 
 class _swapped_meta(type(Structure)):

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:21:58 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 27 Nov 2008 19:21:58 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1227813718.84.0.515868569595.issue4376@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Correction:
>> Since this is all Python code (in Lib/ctypes/_endian.py) it should be

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:57:50 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 27 Nov 2008 19:57:50 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1227815870.18.0.841009318204.issue4309@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:07:18 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 27 Nov 2008 20:07:18 +0000
Subject: [issue4022] 2.6 dependent on c:\python26\ on windows
In-Reply-To: <1222989342.94.0.529774628368.issue4022@psf.upfronthosting.co.za>
Message-ID: <1227816438.8.0.245038526292.issue4022@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4022>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:11:33 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 27 Nov 2008 20:11:33 +0000
Subject: [issue4315] On some Python builds,
	exec in a function can't create shadows of variables if these are
	declared "global" in another function of the same module
In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
Message-ID: <1227816693.95.0.340022522169.issue4315@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4315>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:49:08 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Thu, 27 Nov 2008 20:49:08 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227818948.4.0.839586184155.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

See also
http://mail.python.org/pipermail/python-dev/2008-November/083727.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:57:11 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Nov 2008 20:57:11 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

....
>From Kristj?n Valur J?nsson (kristjan at ccpgames.com) on python-dev:

 http://mail.python.org/pipermail/python-dev/2008-November/083724.html
....

I came across this in socket.c:

        # _rbufsize is the suggested recv buffer size.  It is *strictly*
        # obeyed within readline() for recv calls.  If it is larger than
        # default_bufsize it will be used for recv calls within read().
       

What I worry about is the readline() case.  Is there a reason why we
want to strictly obey it for that function?  Note that in the
documentation for _fileobject.read() it says:

        # Use max, disallow tiny reads in a loop as they are very
inefficient.

 
The same argument surely applies for readline().

 
The reason I am fretting about this is that httplib.py (and therefore
xmlrpclib.py) specify bufsize=0 when createing their socket fileobjects,
presumably to make sure that write() operations are not buffered but
flushed immediately.  But this has the side effect of setting the
_rbufsize to 1, and so readline() calls become very slow.

 
I suggest that readline() be made to use at least defaultbufsize, like
read().  Any thoughts?

----------
assignee: gregory.p.smith
messages: 76516
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: should socket readline() use default_bufsize instead of _rbufsize?
type: performance
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Thu Nov 27 22:38:06 2008
From: report at bugs.python.org (Weeble)
Date: Thu, 27 Nov 2008 21:38:06 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1227821886.52.0.166005961729.issue1529142@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

Is this ever likely to make it into IDLE? Running without a subprocess 
in Windows appears to interact badly with the multiprocessing library 
(attempting to spawn a process just creates a new IDLE window). I 
couldn't figure out how to apply the patch on Windows - I couldn't tell 
if the errors were because I was using the patch program wrong or 
because the file is different now. Nevertheless, I made the changes 
manually and they seemed to work. What needs to happen for this issue to 
be fixed, whether by this patch or another solution?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Thu Nov 27 22:54:22 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 27 Nov 2008 21:54:22 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227822862.45.0.0637383093085.issue4434@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Yes, there is no purpose in linking with a static library when the
dynamically loaded modules still depend on the shared library.
And yes, the dynamically loaded libraries should declare their
dependencies. My point is they do *not* depend on the shared library.
That's why the static lib currently makes sense on ubuntu, but wouldn't
make any sense when your proposal would be implemented.

I recommend closing this issue as invalid.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:05:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 27 Nov 2008 22:05:45 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227823545.2.0.757455607212.issue4434@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Linking with the static library really works. You have to link with
'-Xlinker -export-dynamic' however on linux in order to make the symbols
from the static library visible. (just in case if I haven't been clear..)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:43:56 2008
From: report at bugs.python.org (Lars Immisch)
Date: Thu, 27 Nov 2008 23:43:56 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1227829436.6.0.482548087302.issue4073@psf.upfronthosting.co.za>


Changes by Lars Immisch <lars at ibp.de>:


----------
nosy: +larsimmisch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Fri Nov 28 05:34:17 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Nov 2008 04:34:17 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1227846857.69.0.874598618601.issue4448@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

You meant socket.py.

This is an extremely subtle area.  I would be very wary of changing this
-- there is a use case where headers are read from the socket using
readline() but the rest of the data is read directly from the socket,
and this would break if there was buffered data in the file objects. 
This is exactly why httplib sets the buffer size to 0.

Fortunately things are completely different in Python 3.0 and I believe
the same problem doesn't exist -- in 3.0 it makes more sense to always
read from the (binary) buffered file object representing the socket.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:10:28 2008
From: report at bugs.python.org (rb)
Date: Fri, 28 Nov 2008 09:10:28 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227863428.06.0.32111948414.issue4434@psf.upfronthosting.co.za>


rb <rb-oss-1 at justgohome.co.uk> added the comment:

The problem, and the reason for the existence of this bug, is that I
cannot build a shared object that links to libpython2.5.so.1 and works.

Please don't mark this bug invalid until this problem is fixed.

My proposal of adding dependencies to lib-dynload/*.so is just a
suggestion on how to go about fixing this bug. If this is not a suitable
solution, please suggest a solution that is.


In response to your discussion on why the static library is currently
useful, you haven't really answered the question. In what circumstance
would someone actually want to build against the static library and then
dynamically load other libraries?

"Because it works" isn't an answer, as if this bug were fixed, then
building against the shared library would validly have the same response.

Why static over dynamic, if when static you have to link to dynamic anyway?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:35:44 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 28 Nov 2008 09:35:44 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1227864944.5.0.903589123933.issue4448@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

If you look at http://bugs.python.org/issue4336, half of the proposed 
patch is an attempt to deal with this performance issue.  In the patch, 
we laboriously ensure that bufsize=-1 is passed in for for the xmlrpc 
client.

Seeing your comment, I realize that xmlrpclib.py also uses direct 
access to h._conn.sock (if present) and uses recv() on that.  In fact, 
that is the only place in the standard library where I can find this 
pattern.  Was that a performance improvement?  It is hard to see how 
bypassing buffered read with a manual recv() can significantly alter 
performance.

In all the cases in the test_xmlrpc.py, h._conn.sock is actually None 
because h._conn has been closed in HttpConnection.getresponse()  
Therefore, my patch continues to work.  However, I will fix that patch 
to cater to this strange special case.

However, please observe that since _fileobject.read() calls are always 
buffered, in general there is no way to safely mix read() and recv() 
calls, althought the recv() and readline() has been fudged to work.  
Isn?t this just a case of a wart in the standard lib that we ought to 
remove?

Here is a suggestion:
1) document why readline() observes 0 buffering (to enable it to be 
used as a readline() utility tool on top of vanilla socket recv()
2) stop doing that in xmrlrpclib and use default buffering.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Fri Nov 28 11:53:31 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 28 Nov 2008 10:53:31 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1227869611.63.0.551728094566.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Guido pointed out the problem with _fileobject.readline() being 
followed by socket.recv() if readline uses read buffering.  
xmlrpclib.py was attempting to directly use the underlying socket, 
although in actual fact it never did, (since HTTPConnectio had closed 
it when it returned the response from getresponse()) Never the less, it 
is prudent to make sure that we don't attempt this.
There really should be no need to use the socket directly, a buffered 
read() call is just as efficient.

Added file: http://bugs.python.org/file12145/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:05:26 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:05:26 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1227870326.13.0.319085115952.issue3741@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Fixed in r67414, r67415, r67416 (trunk, 2.6, 3.0).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:17:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:17:05 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

./python Doc/includes/mp_benchmarks.py

       ######## testing Array("i", ..., lock=False)

Traceback (most recent call last):
  File "Doc/includes/mp_benchmarks.py", line 235, in <module>
    test()
  File "Doc/includes/mp_benchmarks.py", line 203, in test
    test_seqspeed(multiprocessing.Array('i', range(10), lock=False))
  File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/__init__.py",
line 254, in Array
    return Array(typecode_or_type, size_or_initializer, **kwds)
  File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/sharedctypes.py",
line 87, in Array
    assert hasattr(lock, 'acquire')
AssertionError

The assertion error occurs when using Python 2.6 and our backports to
2.4 and 2.5.

----------
assignee: jnoller
components: Library (Lib)
messages: 76525
nosy: christian.heimes, jnoller
priority: high
severity: normal
stage: needs patch
status: open
title: AssertionError in Doc/includes/mp_benchmarks.py
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:25:34 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:25:34 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227871534.02.0.400720055461.issue4449@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The examples in 3.0 didn't work at at all because nobody did a 2to3 run
on them. See r67417: mp_benchmarks, mp_newtypes and mp_distribution are
still broken but the others are working properly. We should include the
examples in our unit test suite ...

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:28:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:28:21 +0000
Subject: [issue4450] 2to3 run changed multiprocessing.Queue() to
	multiprocessing.queue()
In-Reply-To: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>
Message-ID: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

I've fixed the multiprocessing examples in r67417. 2to3 altered
multiprocessing.Queue() to multiprocessing.queue().

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76527
nosy: benjamin.peterson, christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: 2to3 run changed multiprocessing.Queue() to multiprocessing.queue()
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4450>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:04:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 14:04:51 +0000
Subject: [issue4451] multiprocessing fails with "Invalid thread state for this
	thread" on 2.4 and 2.5
In-Reply-To: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>
Message-ID: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The multiprocessing backport to 2.4/2.5 fails with a fatal error when
the test suite is run with a debug build of Python.

PYTHONPATH="Lib/" /home/heimes/dev/python/release25-maint/python -tt -c
"from multiprocessing.tests import main; main()"
Fatal Python error: Invalid thread state for this thread
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/tests.py",
line 1826, in main
    test_main(unittest.TextTestRunner(verbosity=2).run)
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/tests.py",
line 1805, in test_main
    ManagerMixin.pool = ManagerMixin.manager.Pool(4)
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/managers.py",
line 637, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/managers.py",
line 535, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/connection.py",
line 142, in Client
    answer_challenge(c, authkey)
  File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/connection.py",
line 373, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
EOFError

----------
components: Interpreter Core
messages: 76528
nosy: christian.heimes, jnoller
priority: high
severity: normal
stage: needs patch
status: open
title: multiprocessing fails with "Invalid thread state for this thread" on 2.4 and 2.5
type: crash
versions: Python 2.4, Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4451>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:23:31 2008
From: report at bugs.python.org (Mark Florisson)
Date: Fri, 28 Nov 2008 14:23:31 +0000
Subject: [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

The docstring of os.setpgrp says 'Make this process a session leader.',
but that's not what setpgrp does. setpgrp() is the same as setpgid(0,
0), which sets the pgid of the calling process to the pid of the calling
process, thus making it a process group leader, not a session leader (it
will still be in the same session). It might say instead 'Make this
process a process group leader.'.

----------
messages: 76529
nosy: eggy
severity: normal
status: open
title: Incorrect docstring of os.setpgrp
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4452>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:35:01 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 14:35:01 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227882901.83.0.034048356711.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

The 3.0 doc/example issue is in issue 3256

I plan on fixing all the doc/example issue this/next week.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:36:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 14:36:32 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227882992.3.0.257904457757.issue4449@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Are you able to fix the examples before 3.0.0 and 2.6.1 are released?
They are scheduled for Wednesday 3rd of December.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:38:06 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 14:38:06 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227882992.3.0.257904457757.issue4449@psf.upfronthosting.co.za>
Message-ID: <4222a8490811280638m198951c3o3a4a8dfca9cce8dd@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Yes, I have a pending patch. I'll see if I can steal some time today
to check it in.

On Fri, Nov 28, 2008 at 9:36 AM, Christian Heimes
<report at bugs.python.org> wrote:
>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> Are you able to fix the examples before 3.0.0 and 2.6.1 are released?
> They are scheduled for Wednesday 3rd of December.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4449>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 15:57:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 14:57:23 +0000
Subject: [issue4451] multiprocessing fails with "Invalid thread state for this
	thread" on 2.4 and 2.5
In-Reply-To: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>
Message-ID: <1227884243.78.0.516227142146.issue4451@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Christian, to fix this, you need to backport the fix for #1683.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4451>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:09:42 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 15:09:42 +0000
Subject: [issue4451] multiprocessing fails with "Invalid thread state for this
	thread" on 2.4 and 2.5
In-Reply-To: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>
Message-ID: <1227884982.53.0.0551268183716.issue4451@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

As ben mentioned, this is already fixed in core. See issue 1683 - this is 
only a problem when running in 2.5/2.4

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4451>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:15:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 15:15:33 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227885333.71.0.671829505716.issue1683@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The fix is required to run multiprocessing on Python 2.4 and 2.5, see
#4451. I suggest we fix the issue in 2.5.3. The fork-thread-patch-2
patch doesn't work on Python 2.5. I'm getting a segfault on my system:

test_connection (multiprocessing.tests.WithProcessesTestConnection) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa2e999f6e0 (LWP 10594)]
0x000000000052065f in PyCFunction_Call (func=Cannot access memory at
address 0x7ffeffffffd8
) at Objects/methodobject.c:73
73                              return (*meth)(self, arg);

Linux on AMD64 with Python 2.5 svn --with-pydebug.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:16:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 15:16:47 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227885407.4.0.582165257671.issue1683@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions:  -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:17:40 2008
From: report at bugs.python.org (John Levon)
Date: Fri, 28 Nov 2008 15:17:40 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227885460.72.0.255331988585.issue4434@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

If Ubuntu wants to deliver a static libpython, it also needs to deliver
static versions of the Python modules, or accept that they're not usable
from a static libpython.

It makes no sense at all to mix libpython.a with these .so files. Many of
them declare dynamic dependencies on stuff like libkrb5.so or
libsqlite3.so. I can't conceive of a scenario where you need a static
libpython AND you're OK with both dlopen() of the Python modules and any
of its dynamic dependencies. What is this case?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:23:18 2008
From: report at bugs.python.org (Suraj Barkale)
Date: Fri, 28 Nov 2008 15:23:18 +0000
Subject: [issue4453] MSI installer shows error message if "Compile .py files
	to bytecode" option is selected
In-Reply-To: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>
Message-ID: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>


New submission from Suraj Barkale <suraj+python at barkale.com>:

If the option to "Compile .py files to bytecode after installation" is
selected during installation (by clicking on "Advanced" button on
"Customize" dialog), installer shows the attached dialog. There seems to
be no problem after installation is finished. I have tested this on
Vista Ultimate SP1 32 bit.

----------
components: Installation
files: SetupError.JPG
messages: 76537
nosy: suraj
severity: normal
status: open
title: MSI installer shows error message if "Compile .py files to bytecode" option is selected
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12146/SetupError.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4453>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:50:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Nov 2008 15:50:55 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1227887455.69.0.909817053515.issue4448@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm fine with disabling this feature in xmlrpclib.py, and possibly even
in httplib.py.

I'm *not* fine with "fixing" this behavior in socket.py -- the unittest
coverage is unfortunately small and we have had plenty of trouble in
this area in the past.  It is there for a reason, even if that reason is
hard to fathom and poorly documented.

Fortunately in 3.0 it's gone (or, more likely, replaced with a different
set of issues :-).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:25:04 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 28 Nov 2008 16:25:04 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227889504.29.0.0619981015814.issue4434@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

no john, linking with the static library really works. the resulting
executable does not depend on the shared library and it is possible to
import the e.g. the time module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:58:33 2008
From: report at bugs.python.org (rb)
Date: Fri, 28 Nov 2008 16:58:33 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227891513.92.0.0191003015649.issue4434@psf.upfronthosting.co.za>


rb <rb-oss-1 at justgohome.co.uk> added the comment:

Ralf,

I'm sure it does work, but what is the point of linking statically to
libpython.a but then having other dependencies, for example on
lib-dynload/time.so? Why not just link to libpython2.5.so in the first
place?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:13:40 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 Nov 2008 17:13:40 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227892420.64.0.766675044542.issue4389@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Would be nice if the same icon could also be the default for bdist_msi.

"Retro" could you point us to some documentation on how to fix this ?

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:41:51 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 Nov 2008 17:41:51 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1227894111.34.0.830154412074.issue4385@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think this is a documentation bug more than anything else.

Removing PyObject_HEAD_INIT() is certainly not an option, since it is
required to init static PyObject singletons that are declared in C (just
like the PyTypeObjects are).

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:58:30 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 17:58:30 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227895110.96.0.0106028944532.issue1683@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:59:49 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 17:59:49 +0000
Subject: [issue4450] 2to3 run changed multiprocessing.Queue() to
	multiprocessing.queue()
In-Reply-To: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>
Message-ID: <1227895189.14.0.46928893987.issue4450@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hmm, we should actually rename mp.Queue to mp.queue at one point

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4450>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:18:32 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 18:18:32 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227896312.44.0.627453794482.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I guess you just 2to3'ed the examples

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:48:14 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 18:48:14 +0000
Subject: [issue4193] Multiprocessing example
In-Reply-To: <1224867277.0.0.802822144442.issue4193@psf.upfronthosting.co.za>
Message-ID: <1227898094.62.0.686048821892.issue4193@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Added in r67419 on trunk, merged to py3k and 2.6.1

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4193>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:48:55 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 18:48:55 +0000
Subject: [issue3518] multiprocessing: BaseManager.from_address documented but
	doesn't exist
In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
Message-ID: <1227898135.81.0.625712295417.issue3518@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Added the mp.managers shared queue example, fixed the docs in r67419 on 
trunk. merged to py3k and 2.6.1 maint

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3518>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:49:49 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 18:49:49 +0000
Subject: [issue4012] Minor errors in multiprocessing docs
In-Reply-To: <1222910620.56.0.617350560863.issue4012@psf.upfronthosting.co.za>
Message-ID: <1227898189.46.0.360268069052.issue4012@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Warning added for georg's issue, all doc errors fixed on trunk, py3k and 
2.6.1 maint. see r67419

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4012>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:02:07 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 28 Nov 2008 19:02:07 +0000
Subject: [issue4238] BSD support for multiprocessing.cpu_count
In-Reply-To: <1225343925.21.0.735322419857.issue4238@psf.upfronthosting.co.za>
Message-ID: <1227898927.55.0.345598182822.issue4238@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fixed, trunk r67423

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4238>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:02:13 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Fri, 28 Nov 2008 19:02:13 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227898930.68.0.0945388426479.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Implement imp.import_module() instead. See
http://mail.python.org/pipermail/python-dev/2008-November/083758.html

Added file: http://bugs.python.org/file12147/imp_import_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:05:44 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Fri, 28 Nov 2008 19:05:44 +0000
Subject: [issue4438] Add an easy way to __import___ submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227899144.1.0.473675022538.issue4438@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Note that the hack described in http://bugs.python.org/issue2090 should
be disabled once this gets integrated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:09:09 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Fri, 28 Nov 2008 19:09:09 +0000
Subject: [issue4438] Given a module hierarchy string 'a.b.c',
	add an easy way to import tail module 'c'
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227899349.46.0.170434947162.issue4438@psf.upfronthosting.co.za>


Changes by Mart S?mermaa <mrts at mrts.pri.ee>:


----------
components:  -Interpreter Core
title: Add an easy way to __import___ submodules -> Given a module hierarchy string 'a.b.c', add an easy way to import tail module 'c'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:59:24 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Nov 2008 19:59:24 +0000
Subject: [issue4454] Coding cookie crashes IDLE
In-Reply-To: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
Message-ID: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Running the following from an edit window with F5 in IDLE 3.0c3 causes a
complete crash. Both edit window and shell window disappear.

# -*- coding: utf-8 -*-

The is copied from what IDLE said to add when I previously ran file with
non-ascii char and no cookie. Same if add pass statement.

Copying the same directly into the shell window appears to work fine.

----------
components: IDLE
messages: 76551
nosy: tjreedy
severity: normal
status: open
title: Coding cookie crashes IDLE
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4454>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:16:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Nov 2008 20:16:05 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227903365.25.0.121640707159.issue4445@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yep.  That works nicely.

Here's a revised patch.

Added file: http://bugs.python.org/file12148/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:16:11 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Nov 2008 20:16:11 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227903371.99.0.612185799533.issue4445@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file12141/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:27:47 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 20:27:47 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227904067.35.0.702137181534.issue4445@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Why is +1 required here? If I understand offsetof() correctly than it
returns the position of the ob_sval element. Shouldn't PyStringObject +
offsetof(PyStringObject, ob_sval) point to the first element of the
ob_svall array?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:34:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Nov 2008 20:34:10 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227904450.28.0.939120966154.issue4445@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The +1 is there for the trailing null byte on the string:  if s is a 
Python string with len(s) == n, then the ob_sval array needs space for n+1 
characters.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:46:43 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 20:46:43 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227905203.35.0.0748321496876.issue4445@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Ah! I forgot the trailing \0 byte ... Thanks Mark!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:14:56 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Nov 2008 21:14:56 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1227906896.37.0.936030582141.issue1693050@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Vowel 'marks' are condensed vowel characters and are very much part of
words and do not separate words.  Python3 properly includes Mn and Mc as
identifier characters.

http://docs.python.org/dev/3.0/reference/lexical_analysis.html#identifiers-and-keywords

For instance, the word 'hindi' has 3 consonants 'h', 'n', 'd', 2 vowels
'i' and 'ii' (long i) following 'h' and 'd', and a null vowel (virama)
after 'n'. [The null vowel is needed because no vowel mark indicates the
default vowel short a.  So without it, the word would be hinadii.]
The difference between the devanagari vowel characters, used at the
beginning of words, and the vowel marks, used thereafter, is purely
graphical and not phonological.  In short, in the sanskrit family,
word = syllable+
syllable = vowel | consonant + vowel mark

>From a clp post asking why re does not see hindi as a word:

??????
     ? DEVANAGARI LETTER HA (Lo)
     ? DEVANAGARI VOWEL SIGN I (Mc)
     ? DEVANAGARI LETTER NA (Lo)
     ? DEVANAGARI SIGN VIRAMA (Mn)
     ? DEVANAGARI LETTER DA (Lo)
     ? DEVANAGARI VOWEL SIGN II (Mc)

.isapha and possibly other unicode methods need fixing also
>>> '??????'.isalpha()#2.x and 3.0
False

----------
nosy: +tjreedy
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:33:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 28 Nov 2008 21:33:41 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1227908021.62.0.877440749758.issue1693050@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unicode TR#18 defines \w as a shorthand for

\p{alpha}
\p{gc=Mark}
\p{digit}
\p{gc=Connector_Punctuation}

which would include all marks. We should recursively check whether we
follow the recommendation (e.g. \p{alpha} refers to all character having
the Alphabetic derived core property, which is Lu+Ll+Lt+Lm+Lo+Nl +
Other_Alphabetic, where Other_Alphabetic is a selected list of
additional character - all from Mn/Mc)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:44:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Nov 2008 21:44:49 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227908689.15.0.0551234004445.issue4445@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmmm.  test_sys fails on 64-bit build.
Patch updated to fix this.

All tests now pass on 32-bit and 64-bit, debug and non-debug builds.

Added file: http://bugs.python.org/file12149/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:44:55 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Nov 2008 21:44:55 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227908695.78.0.676610947529.issue4445@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file12148/string_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:02:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 22:02:00 +0000
Subject: [issue4450] 2to3 run changed multiprocessing.Queue() to
	multiprocessing.queue()
In-Reply-To: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>
Message-ID: <1227909720.61.0.162373938269.issue4450@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r67426.

One result of this fix is that attribute usage of modules is not
replaced. (ie. getattr(somemodule, "attr") isn't changed.) This is
probably isn't a problem, though.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4450>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:32:48 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Nov 2008 22:32:48 +0000
Subject: [issue4195] Regression for executing packages
In-Reply-To: <1224873899.8.0.177595218059.issue4195@psf.upfronthosting.co.za>
Message-ID: <1227911568.93.0.808200259914.issue4195@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Missed the window for 2.6/3.0. Guido agreed on python-dev that it counts
as a new feature, so it was definitely out for the already-released 2.6,
and also wasn't really an option for the release candidate phase of 3.0.

Assigning to myself for 2.7/3.1 - I'll put it in once the 3.0
maintenance branch has been cut (so I can update both 2.x and 3.x at the
same time.

For 2.6 and 3.0 though, short run scripts such as "python -m jcc.main"
are going to be the order of the day.

----------
assignee:  -> ncoghlan
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4195>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:36:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Nov 2008 22:36:52 +0000
Subject: [issue4082] __main__.__file__ not set correctly when -m switch gets
	__main__ from a zipfile
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1227911812.34.0.771656947514.issue4082@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Morphing the issue to refer to the __main__.__file__ problem I mentioned
in my previous comment.

----------
assignee:  -> ncoghlan
title: python2.6 -m site doesn't run site._script() any more -> __main__.__file__ not set correctly when -m switch gets __main__ from a zipfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4082>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:42:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2008 22:42:56 +0000
Subject: [issue4455] No Windows List in IDLE if several windows have the same
	title
In-Reply-To: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>
Message-ID: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Start IDLE, and hit Ctrl-N twice to create two windows named "Untitled":
This displays the message
"""
warning: callback failed in WindowList <class 'TypeError'> : unorderable 
types: ListedToplevel() < ListedToplevel()
"""
And the "Windows" menu does not contain the windows list.

This is specific to python 3: Windows objects cannot be ordered any 
more. Patch is attached.

----------
files: windowslist.patch
keywords: needs review, patch
messages: 76562
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: No Windows List in IDLE if several windows have the same title
versions: Python 3.0
Added file: http://bugs.python.org/file12150/windowslist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4455>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:43:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 22:43:51 +0000
Subject: [issue4456] xmlrpc is broken
In-Reply-To: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>
Message-ID: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

It looks there are logic problems with regards to encoding in xmlrpc:

        if not isinstance(methodname, str):
            methodname = methodname.encode(encoding)

Merging r67370 and running test_xmlrpc gives:

test_bug_1164912 (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_cmp_datetime_DateTime (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_bad_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_bare_datetime (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_big_int (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_big_long (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_load (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_none (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_recursive_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_recursive_seq (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_newstyle_class (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_escape (test.test_xmlrpc.HelperTestCase) ... ok
test_datetime_datetime (test.test_xmlrpc.DateTimeTestCase) ... ok
test_decode (test.test_xmlrpc.DateTimeTestCase) ... ok
test_default (test.test_xmlrpc.DateTimeTestCase) ... ok
test_repr (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time_struct (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time_tuple (test.test_xmlrpc.DateTimeTestCase) ... ok
test_decode (test.test_xmlrpc.BinaryTestCase) ... ok
test_default (test.test_xmlrpc.BinaryTestCase) ... ok
test_string (test.test_xmlrpc.BinaryTestCase) ... ok
test_dotted_attribute (test.test_xmlrpc.FaultTestCase) ... ok
test_dump_fault (test.test_xmlrpc.FaultTestCase) ... ok
test_repr (test.test_xmlrpc.FaultTestCase) ... ok
test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase) ...
ERROR
test_send_content (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_send_host (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_send_request (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection2 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection3 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection4 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_simple1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_basic (test.test_xmlrpc.FailingServerTestCase) ... ok
test_fail_no_info (test.test_xmlrpc.FailingServerTestCase) ... ok
test_fail_with_info (test.test_xmlrpc.FailingServerTestCase) ... ok
test_cgi_get (test.test_xmlrpc.CGIHandlerTestCase) ... ok
test_cgi_xmlrpc_response (test.test_xmlrpc.CGIHandlerTestCase) ... ok

======================================================================
ERROR: test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 657, in
test_custom_user_agent
    req = self.issue_request(TestTransport)
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
    proxy.pow(6, 8)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
    return self.__send(self.__name, args)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
    verbose=self.__verbose
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
    return self._parse_response(resp, None)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
    p.feed(response)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2

======================================================================
ERROR: test_send_content (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 687, in
test_send_content
    req = self.issue_request(TestTransport)
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
    proxy.pow(6, 8)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
    return self.__send(self.__name, args)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
    verbose=self.__verbose
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
    return self._parse_response(resp, None)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
    p.feed(response)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2

======================================================================
ERROR: test_send_host (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 667, in
test_send_host
    req = self.issue_request(TestTransport)
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
    proxy.pow(6, 8)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
    return self.__send(self.__name, args)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
    verbose=self.__verbose
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
    return self._parse_response(resp, None)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
    p.feed(response)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2

======================================================================
ERROR: test_send_request (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 677, in
test_send_request
    req = self.issue_request(TestTransport)
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
    proxy.pow(6, 8)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
    return self.__send(self.__name, args)
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
    verbose=self.__verbose
  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1124, in request
    http_conn = self.send_request(host, handler, request_body, verbose)
  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 675, in
send_request
    conn.putheader("X-Test", "test_send_request")
AttributeError: 'str' object has no attribute 'putheader'

----------------------------------------------------------------------

----------
components: Library (Lib)
messages: 76563
nosy: benjamin.peterson, jhylton
priority: release blocker
severity: normal
stage: needs patch
status: open
title: xmlrpc is broken
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4456>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:44:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 22:44:34 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227912274.41.0.503842338441.issue1683@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee: gregory.p.smith -> christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:00:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 23:00:03 +0000
Subject: [issue4455] No Windows List in IDLE if several windows have the same
	title
In-Reply-To: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>
Message-ID: <1227913203.1.0.479376946262.issue4455@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4455>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:05:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2008 23:05:59 +0000
Subject: [issue4454] Coding cookie crashes IDLE
In-Reply-To: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
Message-ID: <1227913559.69.0.970529968301.issue4454@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't reproduce this problem (on windows XP). Which platform are you 
running?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4454>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:27:02 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 23:27:02 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227914822.67.0.0115317592572.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12151/issue3826_socketserver-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:27:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 23:27:31 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227914851.55.0.838056701632.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file12152/issue3826_socket-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:29:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2008 23:29:07 +0000
Subject: [issue4455] No Windows List in IDLE if several windows have the same
	title
In-Reply-To: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>
Message-ID: <1227914947.14.0.456052577973.issue4455@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r67436.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4455>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:32:05 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 23:32:05 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227915125.64.0.216650146923.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Alright I've taken another fresh look at this.  I understand the dup
semantics issue and don't want to break that.

Attached are two patches, either one of these will fix the problem and
breakage.py test code attached to this bug.

Personally I prefer the socket.py patch as I think it will solve this
problem in other places it could potentially pop up.  It calls
self._sock._decref_socketios() from within the SocketIO.close() method
so that after a SocketIO returned by socket.makefile() is closed, it
will no longer prevent the underlying socket from closing.

The socketserver.py patch also works but seems like more of a hack as it
is still relies on immediate reference counted destruction.

Please review.

I'm guessing its too late in the release candidate process for 3.0 to
get this in, but we should do it for 3.0.1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:34:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 23:34:42 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227915282.38.0.989542113729.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

P.S.  Gabriel Genellina (gagenellina)  -  Your comment sounded like you
had a unit test for this but it never got attached.  Still have it?

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:41:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Nov 2008 23:41:17 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227915677.34.0.632829896029.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file12153/issue3826_socket-gps02.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:58:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2008 23:58:13 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227916693.59.0.912595582447.issue3826@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree that the patch on socket.py is the correct fix: the raw socket 
should be detached when the close() method is called.

I have one remark on the patch:
io.IOBase.__del__ already calls close(): could SocketIO.__del__ be 
removed completely? And no need for "_need_to_decref_sock": the closed 
property should be enough.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:04:49 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 00:04:49 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227917089.54.0.969316048479.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Indeed IOBase does call close() from its __del__.  Excellent.  That
makes this simpler.  -gps03 attached.

Added file: http://bugs.python.org/file12154/issue3826_socket-gps03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:04:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 00:04:58 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227917098.35.0.0749332167097.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12152/issue3826_socket-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:13:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 00:13:00 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227917580.28.0.0530010493711.issue4428@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:54:30 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 00:54:30 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227920070.15.0.911423104187.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I've attached my first attempt at fixing this as io-bufwrite-gps01.

Unfortunately it causes the Lib/test/test_io.py testThreads to fail:

======================================================================
FAIL: testThreads (__main__.BufferedReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_io.py", line 456, in testThreads
    self.assertEqual(s.count(c), N)
AssertionError: 30 != 1000

I haven't read the test yet, but my guess is that the test is broken and
is blindly calling write() without checking the return value.

----------
keywords: +patch
Added file: http://bugs.python.org/file12155/issue4428-io-bufwrite-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:58:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 29 Nov 2008 00:58:03 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227920283.81.0.222115480824.issue3826@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Patch issue3826_socket-gps03.diff is OK for me.
Here is a unit test for this new behavior.

Someone should review both patches.

----------
keywords: +needs review
Added file: http://bugs.python.org/file12156/test_makefileclose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:01:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 01:01:42 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227920502.64.0.0196248481581.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Yep, the test was ignoring the return value from BufferedWriter.write. 
Fixed in the attached io-bufwrite-gps02.

This can wait for 3.0.1 and 2.6.1/2 (depending on the 2.6.x release
schedule).

----------
keywords: +needs review
Added file: http://bugs.python.org/file12157/issue4428-io-bufwrite-gps02.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:15:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 29 Nov 2008 01:15:46 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227921346.14.0.642758939416.issue4428@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I do not agree. User code should not have to verify the return value of write().

When a big amount of data is passed to BufferedWriter.write,
- normal blocking streams should block until all data has been written.
(the implementation may call self.raw.write several times)
- non-blocking streams should raise BlockingIOError indicating the number of 
characters actually written.

This applies only to buffered files, of course.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:16:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 01:16:45 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1227921405.06.0.693356749217.issue1208304@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
components: +Library (Lib) -Extension Modules
type:  -> resource usage
versions: +Python 2.5, Python 2.6, Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208304>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:37:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 29 Nov 2008 01:37:16 +0000
Subject: [issue4454] Coding cookie crashes IDLE
In-Reply-To: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
Message-ID: <1227922636.88.0.140334268172.issue4454@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of #4008

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE: checksyntax() doesn't support Unicode?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4454>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:42:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 01:42:48 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227922968.51.0.842713630602.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I agree with Amuary, write() traditionally never writes less data unless
the underlying IO is in nonblocking mode.

I'm working up a new patch to write to self.raw in max_buffer_size
chunks with as few data copies as possible, raising an appropriate
BlockingIOError (as the surrounding code does) when the IO on the
underlying self.raw.write raises one through self._flush_unlocked().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:48:46 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 01:48:46 +0000
Subject: [issue4445] String allocations waste 3 bytes of memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227923326.38.0.80155200641.issue4445@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Looks much cleaner.

----------
assignee:  -> marketdickinson
resolution:  -> accepted
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:52:26 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Sat, 29 Nov 2008 01:52:26 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227869611.63.0.551728094566.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811281752l7a5438b2odb1d2686a8a56729@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I did the simple part of the patch, where the request and headers are
sent at the same time.  The applied patch didn't pass the test suite,
and I want to think about the buffering change a bit more.  It's
definitely tricky.

Jeremy

On Fri, Nov 28, 2008 at 5:53 AM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> Guido pointed out the problem with _fileobject.readline() being
> followed by socket.recv() if readline uses read buffering.
> xmlrpclib.py was attempting to directly use the underlying socket,
> although in actual fact it never did, (since HTTPConnectio had closed
> it when it returned the response from getresponse()) Never the less, it
> is prudent to make sure that we don't attempt this.
> There really should be no need to use the socket directly, a buffered
> read() call is just as efficient.
>
> Added file: http://bugs.python.org/file12145/xmlrpc.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From jeremy at alum.mit.edu  Sat Nov 29 02:52:21 2008
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 28 Nov 2008 20:52:21 -0500
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1227869611.63.0.551728094566.issue4336@psf.upfronthosting.co.za>
References: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
	<1227869611.63.0.551728094566.issue4336@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811281752l7a5438b2odb1d2686a8a56729@mail.gmail.com>

I did the simple part of the patch, where the request and headers are
sent at the same time.  The applied patch didn't pass the test suite,
and I want to think about the buffering change a bit more.  It's
definitely tricky.

Jeremy

On Fri, Nov 28, 2008 at 5:53 AM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> Guido pointed out the problem with _fileobject.readline() being
> followed by socket.recv() if readline uses read buffering.
> xmlrpclib.py was attempting to directly use the underlying socket,
> although in actual fact it never did, (since HTTPConnectio had closed
> it when it returned the response from getresponse()) Never the less, it
> is prudent to make sure that we don't attempt this.
> There really should be no need to use the socket directly, a buffered
> read() call is just as efficient.
>
> Added file: http://bugs.python.org/file12145/xmlrpc.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Sat Nov 29 03:15:42 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2008 02:15:42 +0000
Subject: [issue4008] IDLE: checksyntax() doesn't support Unicode?
In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>
Message-ID: <1227924942.02.0.0309434452644.issue4008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is still a problem on my WinXP 3.0rc3 with
# -*- coding: utf-8 -*-
in a file but not with the same pasted directly into the shell Window.

----------
nosy: +tjreedy
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4008>
_______________________________________

From report at bugs.python.org  Sat Nov 29 03:15:59 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2008 02:15:59 +0000
Subject: [issue4454] Coding cookie crashes IDLE
In-Reply-To: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
Message-ID: <1227924959.9.0.25329113928.issue4454@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

WinXP
And sorry for dup.  I searched IDLE items for 'crash'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4454>
_______________________________________

From report at bugs.python.org  Sat Nov 29 03:38:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 02:38:28 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227926308.29.0.960236924319.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Okay, here's a new patch that obeys the blocking vs nonblocking
semantics properly.  It still needs explicit unit tests for proper behavior.

Added file: http://bugs.python.org/file12158/issue4428-io-bufwrite-gps03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 03:38:52 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 02:38:52 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227926332.02.0.621476154955.issue4428@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12155/issue4428-io-bufwrite-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 05:40:55 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Nov 2008 04:40:55 +0000
Subject: [issue4457] __import__ documentation obsolete
In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za>
Message-ID: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

The documentation for __import__ says that it primarily exists "so that
you can replace it with another function that has a compatible
interface, in order to change the semantics of the import statement".
http://docs.python.org/library/functions.html

That is no longer the case. The recommended way to do that is with the
new import hooks, and the docs should reflect that.

A common use for __import__ is for when you don't know the module name
until runtime. That too should be mentioned.

----------
assignee: georg.brandl
components: Documentation
messages: 76582
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: __import__ documentation obsolete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4457>
_______________________________________

From report at bugs.python.org  Sat Nov 29 05:48:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 04:48:35 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1227934116.0.0.0257557231348.issue1868@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Sat Nov 29 06:04:00 2008
From: report at bugs.python.org (Yevgen Muntyan)
Date: Sat, 29 Nov 2008 05:04:00 +0000
Subject: [issue4458] getopt.gnu_getopt() loses dash argument
In-Reply-To: <1227935040.48.0.357266334466.issue4458@psf.upfronthosting.co.za>
Message-ID: <1227935040.48.0.357266334466.issue4458@psf.upfronthosting.co.za>


New submission from Yevgen Muntyan <muntyan at tamu.edu>:

If you feed a dash as an argument to getopt.gnu_getopt() then it gets
lost, because the code only checks if the argument starts with a dash,
not if it's more than a dash (unlike getopt.getopt() which is correct).

Example:

>>> import getopt
>>> getopt.gnu_getopt('-', '')
([], [])
>>> getopt.getopt('-', '')
([], '-')

----------
components: Library (Lib)
messages: 76583
nosy: muntyan
severity: normal
status: open
title: getopt.gnu_getopt() loses dash argument
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4458>
_______________________________________

From report at bugs.python.org  Sat Nov 29 09:11:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 08:11:15 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1227946275.13.0.167818069926.issue1868@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Is any of the patches believed to be ready?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Sat Nov 29 11:48:27 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 10:48:27 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227955707.07.0.611462632329.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

The new patch attached renamed Py_GCC_ATTRIBUTE to Py_GCC_FORMAT_ATTRIBUTE.

As Roumen pointed out, "the current python code use Py_GCC_ATTRIBUTE
only for 'format(printf(...)) ' attribute.",  so this change should not
be no harm itself.
 
Because a GCC attribute was/will be introduced in different version of
GCC, we cannot have generic Py_GCC_ATTRIBUTE easily.

You can find availability of a attribute at
http://www.ohse.de/uwe/articles/gcc-attributes.html
http://www.ohse.de/uwe/articles/gcc-attributes.html

Added file: http://bugs.python.org/file12159/issue4370.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 12:17:52 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 11:17:52 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227957472.17.0.461494947767.issue4370@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file12124/pyport.h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 12:54:24 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 29 Nov 2008 11:54:24 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1227959664.5.0.506655182703.issue1529142@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

First of all, the multiprocessing module doesn't work fully in an
interactive shell.

>From the Python2.6 docs:
"Note Functionality within this package requires that the __main__
method be importable by the children. This is covered in Programming
guidelines however it is worth pointing out here. This means that some
examples, such as the multiprocessing.Pool examples will not work in
the interactive interpreter."

And later on that same page (under Programming Guidelines -> Windows):
"Make sure that the main module can be safely imported by a new Python
interpreter without causing unintended side effects (such a starting a
new process)."

This is probably why IDLE is acting up for you. I would be surprised
if using the multiprocessing module will work well in IDLE either with
or without a sub-process.


As per the patch, someone should just work up an updated one with all
of the insight gained in the last several years (!) regarding this.

It should just do two things:
1) remove the use of the SO_REUSEADDR flag in the sub-process spawning
code -- see http://bugs.python.org/issue1201569
2) pass zero as the argument for the port number, which instructs the
underlying socket library to select an available port, and later
retrieve the selected port from the socket object -- see
http://mail.python.org/pipermail/idle-dev/2008-June/002687.html

The other changes in my original patch, while they do work, are
unnecessarily complex and make it much harder to get the patch
accepted. They should also not be significant if the spawning delays
are fixed.

If you'd like to work up such a patch and get it reviewed and
committed, please be my guest! I will help you in any way I can if you
take this up. Otherwise I guess it will wait until I find the time and
energy...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:04:20 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 12:04:20 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227960260.74.0.660687614558.issue4370@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Added file: http://bugs.python.org/file12160/issue4370.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:04:33 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 12:04:33 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227960273.77.0.709788619623.issue4370@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file12159/issue4370.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:15:50 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 12:15:50 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227960950.73.0.0613214834964.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Tested my patch on 
* FreeBSD 4.11 (gcc version 2.95.4, does not support "z")
* FreeBSD 6.3 (gcc version 3.4.6, supports "z")
and it worked fine on both. (using trunk)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:44:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 12:44:07 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227962647.62.0.427954508852.issue4370@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm opposed to applying this patch to a maintenance branch. It removes
the Py_GCC_ATTRIBUTE macro, which some extension modules might rely on.

I also wonder whether it is really necessary to complicate the code just
so that gcc 2.95 stops producing some warnings. So I propose to close
this as "won't fix".

----------
keywords:  -needs review
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:47:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 12:47:00 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1227962820.62.0.102981726083.issue1868@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Reconsidering: I think the "needs review" keyword should only be applied
if there is a single patch associated with the issue that needs review.
So anybody setting the keyword should remove all patches that don't need
review anymore (as they are superceded). I'm removing the keyword for now.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:49:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 12:49:10 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227962950.9.0.398420285058.issue4428@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

According to msg76581, the patch fails review (lacking test cases), so
I'm removing the "needs review" keyword.

----------
keywords:  -needs review
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:49:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 12:49:53 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227962993.96.0.682980853711.issue3826@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file12151/issue3826_socketserver-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 13:49:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 12:49:59 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227962999.31.0.205348530083.issue3826@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file12153/issue3826_socket-gps02.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 14:24:51 2008
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 29 Nov 2008 13:24:51 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227965091.54.0.633463074645.issue4428@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

I agree with previous comments that write() should definitely write all 
data when in blocking mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Sat Nov 29 14:25:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 13:25:13 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227965113.92.0.437889956912.issue3826@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this is quite right yet. If I run

import socket
s=socket.socket()
s.connect(('www.python.org',80))
x=s.makefile()
del x
del s

and put a print statement into real_close, I don't see that real_close
is invoked.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 14:28:06 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 13:28:06 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227965286.25.0.0771870251544.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Martin,
Thank you for the feedback.

I think we can avoid the problem that would be introduced by the removal
of Py_GCC_ATTRIBUTE by leaving it as is
(probably adding "#warning this macro is deprecated. Please use
Py_GCC_FORMAT_ATTRIBUTE instead").

The patch looks not so complicated to me. It's just a renaming of a
macro. The new name is more explicit.

IMHO, source code should be kept warning-free, as long as the fix is
simple and it does not cost much.

So I think now the question would be whether having explicitly named
macro and warning-free code for old compilers worth the effort of
renaming all Py_GCC_ATTRIBUTE to Py_GCC_FORMAT_ATTRIBUTE.

I would like to leave the decision to the core developers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 14:36:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 13:36:01 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227965761.4.0.639538366658.issue4370@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok. Removing 2.5.3 from the target releases until a decision is made
(and potentially a new patch is available).

----------
versions:  -Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:38:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 29 Nov 2008 14:38:46 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227969526.6.0.750967104985.issue3826@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But real_close() is not called either in the trivial socket use:

import socket
s=socket.socket()
s.connect(('www.python.org',80))
del s

OTOH, I added some printf statements in socketmodule.c, near all usages 
of SOCKETCLOSE(). They show that the raw socket is closed as expected - 
except in the following case:

import socket
s=socket.socket()
s.connect(('www.python.org',80))
x=s.makefile()
x.close()
del s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:42:31 2008
From: report at bugs.python.org (John5342)
Date: Sat, 29 Nov 2008 14:42:31 +0000
Subject: [issue4459] bdist_rpm assumes python
In-Reply-To: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
Message-ID: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>


New submission from John5342 <John5342 at googlemail.com>:

When using bdist_rpm the %build section of the generated spec file
contains the following:

env CFLAGS="$RPM_OPT_FLAGS" python setup.py build

This works fine until the python is installed using altinstall. In this
situation the spec file will use the default python rather than the one
currently used.

I am currently using python3.0 with the default python being 2.5. As a
result the spec file is created which then calles python (2.5) and my
setup.py contains 3.0 code so the spec file fails.

When the above line is generated it should use the current interpreters
path and name rather than just "python"

----------
components: Distutils
messages: 76596
nosy: John5342
severity: normal
status: open
title: bdist_rpm assumes python
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4459>
_______________________________________

From report at bugs.python.org  Sat Nov 29 16:00:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 29 Nov 2008 15:00:14 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227970814.44.0.0178554585495.issue1683@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I was wrong and the patch is right. Something is wrong in
multiprocessings connection_recvbytes_into() function for the old buffer
protocol. Somehow PyArg_ParseTuple(args, "w#|" ...) fucks up the
process' memory.

Martin, are you fine with the patch? fork-thread-patch-2 still applies
with some fuzzying.

----------
assignee: christian.heimes -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:21:36 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Sat, 29 Nov 2008 16:21:36 +0000
Subject: [issue4456] xmlrpc is broken
In-Reply-To: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530811290821v38c911ddmeb69f058912d12f7@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I don't think I understand this report.  The TransportSubclassTestCase
class tests the behavior of overridable methods that don't exist in
Python 3.0.  Is this really a Python 3.0 problem?  I'm not sure why we
expect it to work there.

Jeremy

On Fri, Nov 28, 2008 at 5:43 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> New submission from Benjamin Peterson <musiccomposition at gmail.com>:
>
> It looks there are logic problems with regards to encoding in xmlrpc:
>
>        if not isinstance(methodname, str):
>            methodname = methodname.encode(encoding)
>
> Merging r67370 and running test_xmlrpc gives:
>
> test_bug_1164912 (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_cmp_datetime_DateTime (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_bad_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_bare_datetime (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_big_int (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_big_long (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_load (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_none (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_recursive_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_recursive_seq (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_newstyle_class (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_escape (test.test_xmlrpc.HelperTestCase) ... ok
> test_datetime_datetime (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_decode (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_default (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_repr (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time_struct (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time_tuple (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_decode (test.test_xmlrpc.BinaryTestCase) ... ok
> test_default (test.test_xmlrpc.BinaryTestCase) ... ok
> test_string (test.test_xmlrpc.BinaryTestCase) ... ok
> test_dotted_attribute (test.test_xmlrpc.FaultTestCase) ... ok
> test_dump_fault (test.test_xmlrpc.FaultTestCase) ... ok
> test_repr (test.test_xmlrpc.FaultTestCase) ... ok
> test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase) ...
> ERROR
> test_send_content (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_send_host (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_send_request (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection2 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection3 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection4 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_simple1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_basic (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_fail_no_info (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_fail_with_info (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_cgi_get (test.test_xmlrpc.CGIHandlerTestCase) ... ok
> test_cgi_xmlrpc_response (test.test_xmlrpc.CGIHandlerTestCase) ... ok
>
> ======================================================================
> ERROR: test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 657, in
> test_custom_user_agent
>    req = self.issue_request(TestTransport)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
> issue_request
>    proxy.pow(6, 8)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
>    return self.__send(self.__name, args)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
>    verbose=self.__verbose
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
>    return self._parse_response(resp, None)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
> _parse_response
>    p.feed(response)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
>    self._parser.Parse(data, 0)
> xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
>
> ======================================================================
> ERROR: test_send_content (test.test_xmlrpc.TransportSubclassTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 687, in
> test_send_content
>    req = self.issue_request(TestTransport)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
> issue_request
>    proxy.pow(6, 8)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
>    return self.__send(self.__name, args)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
>    verbose=self.__verbose
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
>    return self._parse_response(resp, None)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
> _parse_response
>    p.feed(response)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
>    self._parser.Parse(data, 0)
> xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
>
> ======================================================================
> ERROR: test_send_host (test.test_xmlrpc.TransportSubclassTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 667, in
> test_send_host
>    req = self.issue_request(TestTransport)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
> issue_request
>    proxy.pow(6, 8)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
>    return self.__send(self.__name, args)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
>    verbose=self.__verbose
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
>    return self._parse_response(resp, None)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
> _parse_response
>    p.feed(response)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
>    self._parser.Parse(data, 0)
> xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
>
> ======================================================================
> ERROR: test_send_request (test.test_xmlrpc.TransportSubclassTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 677, in
> test_send_request
>    req = self.issue_request(TestTransport)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
> issue_request
>    proxy.pow(6, 8)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
>    return self.__send(self.__name, args)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
>    verbose=self.__verbose
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1124, in request
>    http_conn = self.send_request(host, handler, request_body, verbose)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 675, in
> send_request
>    conn.putheader("X-Test", "test_send_request")
> AttributeError: 'str' object has no attribute 'putheader'
>
> ----------------------------------------------------------------------
>
> ----------
> components: Library (Lib)
> messages: 76563
> nosy: benjamin.peterson, jhylton
> priority: release blocker
> severity: normal
> stage: needs patch
> status: open
> title: xmlrpc is broken
> type: behavior
> versions: Python 3.0
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4456>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4456>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:27:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Nov 2008 16:27:24 +0000
Subject: [issue4456] xmlrpc is broken
In-Reply-To: <e8bf7a530811290821v38c911ddmeb69f058912d12f7@mail.gmail.com>
Message-ID: <1afaf6160811290827y59aa540ak5686b4632e4bfaee@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Sat, Nov 29, 2008 at 10:21 AM, Jeremy Hylton <report at bugs.python.org> wrote:
>
> Jeremy Hylton <jeremy at alum.mit.edu> added the comment:
>
> I don't think I understand this report.  The TransportSubclassTestCase
> class tests the behavior of overridable methods that don't exist in
> Python 3.0.  Is this really a Python 3.0 problem?  I'm not sure why we
> expect it to work there.

Oh! I had no idea that those methods were not supported in 3.0. I
guess we can close this.

>
> Jeremy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4456>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:27:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Nov 2008 16:27:41 +0000
Subject: [issue4456] xmlrpc is broken
In-Reply-To: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>
Message-ID: <1227976061.44.0.0101545036643.issue4456@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4456>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:35:42 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:35:42 +0000
Subject: [issue4460] The parameter of PyInt_AsSsize_t() is not checked to see
	if it is NULL
In-Reply-To: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
Message-ID: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Modules/_sre.c(match_getindex)
Line 2766

The parameter of PyInt_AsSsize_t() is not checked to see if it is NULL.

----------
components: None
messages: 76600
nosy: CWRU_Researcher1
severity: normal
status: open
title: The parameter of PyInt_AsSsize_t() is not checked to see if it is NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4460>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:54:37 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 29 Nov 2008 16:54:37 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227977677.39.0.672522631408.issue4370@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

My idea was not to remove Py_GCC_ATTRIBUTE but the new macro with
specific name that use Py_GCC_ATTRIBUTE.

If macro name is Py_GCC_FORMAT_ATTRIBUTE then something similar to :
#if !defined(PY_FORMAT_SIZE_T)
#define Py_GCC_FORMAT_ATTRIBUTE(type, str_idx, arg_idx)
#else
#define Py_GCC_FORMAT_ATTRIBUTE(type, str_idx, arg_idx)
Py_GCC_ATTRIBUTE((format(type, str_idx, arg_idx))
#endif

and next in the code
s/Py_GCC_ATTRIBUTE(...)/Py_GCC_FORMAT_ATTRIBUTE(...)/g as rest of the
proposed patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:54:38 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:54:38 +0000
Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL
In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>
Message-ID: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/ast.c(parsenumber)
Line 3061

The parameters of PyLong_FromString() are not checked for NULL before
the method is called.

----------
components: None
messages: 76602
nosy: CWRU_Researcher1
severity: normal
status: open
title: parameters of PyLong_FromString() are not checked for NULL
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4461>
_______________________________________

From report at bugs.python.org  Sat Nov 29 17:59:43 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:59:43 +0000
Subject: [issue4462] result of PyList_GetItem() not validated
In-Reply-To: <1227977983.78.0.00196482293309.issue4462@psf.upfronthosting.co.za>
Message-ID: <1227977983.78.0.00196482293309.issue4462@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/import.c(find_module)
Lines 1171

PyString_Check() is not called on the result of PyList_GetItem(), nor is
the result checked to see if it is NULL.

----------
components: None
messages: 76603
nosy: CWRU_Researcher1
severity: normal
status: open
title: result of PyList_GetItem() not validated
type: resource usage
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4462>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:02:14 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:02:14 +0000
Subject: [issue4463] Parameters and result of PyList_GetItem() are not
	validated
In-Reply-To: <1227978134.48.0.524968542357.issue4463@psf.upfronthosting.co.za>
Message-ID: <1227978134.48.0.524968542357.issue4463@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/import.c(get_path_importer)
Lines 1079

PyString_Check() is not called on the result of PyList_GetItem() and the
parameters of PyList_GetItem() are not validated before the method is
called.

----------
components: None
messages: 76604
nosy: CWRU_Researcher1
severity: normal
status: open
title: Parameters and result of PyList_GetItem() are not validated
type: performance
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4463>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:06:35 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:06:35 +0000
Subject: [issue4464] PyList_GetItem() result and parameters not fully validated
In-Reply-To: <1227978395.86.0.799094154401.issue4464@psf.upfronthosting.co.za>
Message-ID: <1227978395.86.0.799094154401.issue4464@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Python/codecs.c(_PyCodec_Lookup)
Lines 106, 144

PyString_Check() is not called on the result of PyList_GetItem() and the
first parameter of PyList_GetItem() does not have PyList_Check() called
on it.
(See Python-2.5.2/Python/traceback.c(tb_displayline) for a correct
instance of the pattern)

----------
components: None
messages: 76605
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyList_GetItem() result and parameters not fully validated
type: performance
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4464>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:11:06 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 17:11:06 +0000
Subject: [issue4368] A bug in ncurses.h still exists in FreeBSD 4.9 - 4.11
In-Reply-To: <1227203306.6.0.971965708018.issue4368@psf.upfronthosting.co.za>
Message-ID: <1227978666.45.0.00145667066189.issue4368@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
versions: +Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:12:26 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:12:26 +0000
Subject: [issue4465] The result of set_copy() is not checked for NULL
In-Reply-To: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>
Message-ID: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Objects/setobject.c
Line 1204

The result of set_copy() is not checked for NULL.

[See Objects/setobject.c(set_difference) for example of correct usage]

----------
components: None
messages: 76606
nosy: CWRU_Researcher1
severity: normal
status: open
title: The result of set_copy() is not checked for NULL
type: performance
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4465>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:17:21 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 17:17:21 +0000
Subject: [issue4460] The parameter of PyInt_AsSsize_t() is not checked to see
	if it is NULL
In-Reply-To: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
Message-ID: <1227979041.41.0.714939047061.issue4460@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm confused.  I'm probably missing something, but why do you think such a 
check is necessary?  The code I'm seeing at around line 2766 is:

static Py_ssize_t
match_getindex(MatchObject* self, PyObject* index)
{
    Py_ssize_t i;

    if (PyInt_Check(index))
        return PyInt_AsSsize_t(index);

...

Is there any reason to expect that the index argument to match_getindex 
might be NULL?  Even if it were, surely it would be the PyInt_Check call 
that would be affected, not PyInt_AsSsize_t?

The usual pattern in Python C code is to check return values, but not 
incoming arguments.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4460>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:31:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 17:31:10 +0000
Subject: [issue4465] The result of set_copy() is not checked for NULL
In-Reply-To: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>
Message-ID: <1227979870.23.0.262108422228.issue4465@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I believe the code is correct as it is.  The relevant lines are in
set_intersection:

	if ((PyObject *)so == other)
		return set_copy(so);

If the result of the set_copy is NULL then the NULL is passed directly 
back to the calling routine;  this is as it should be.  A NULL coming from 
set_copy indicates that an exception occurred; this is then passed on to 
the calling routine so that the calling routine is aware of the exception.

If you haven't already done so, please take a look at

http://docs.python.org/dev/c-api/index.html

especially the section on exception handling.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4465>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:34:48 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:34:48 +0000
Subject: [issue4460] The parameter of PyInt_AsSsize_t() is not checked to see
	if it is NULL
In-Reply-To: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
Message-ID: <1227980088.64.0.601896828514.issue4460@psf.upfronthosting.co.za>


Brian Szuter <Brian.Szuter at gmail.com> added the comment:

abstract.c(PyNumber_AsSsize_t) shows this check of PyInt_AsSsize_t()'s
parameter:

980: 	if (value == NULL)    
981: 		return -1;    
982:     
983: 	/* We're done if PyInt_AsSsize_t() returns without error. */   
984: 	result = PyInt_AsSsize_t(value);

Similar checks of this parameter occur in the following places:
classobject.c(instance_length) 980
sliceobject.c(PySlice_GetIndices) 1020
sliceobject.c(PySlice_GetIndices) 123
sliceobject.c(PySlice_GetIndices) 115
ceval.c(PyEval_EvalFrameEx) 1179
_sre.c(match_getindex) 2772

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4460>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:37:51 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 17:37:51 +0000
Subject: [issue4465] The result of set_copy() is not checked for NULL
In-Reply-To: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>
Message-ID: <1227980271.76.0.889465476189.issue4465@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The code is correct as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4465>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:40:45 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:40:45 +0000
Subject: [issue4466] The return value of PyFile_FromFile is not checked for
	NULL
In-Reply-To: <1227980445.15.0.00624503255277.issue4466@psf.upfronthosting.co.za>
Message-ID: <1227980445.15.0.00624503255277.issue4466@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Modules/posixmodule.c(posix_tmpfile)
Line 6841

The return value of PyFile_FromFile is not checked for NULL

See the following where it is checked:
tokenizer.c(fp_setreadl) 429
fileobject.c(PyFile_FromString) 300
posixmodule.c(posix_popen) 5323

----------
messages: 76611
nosy: CWRU_Researcher1
severity: normal
status: open
title: The return value of PyFile_FromFile is not checked for NULL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4466>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:43:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 17:43:51 +0000
Subject: [issue4460] The parameter of PyInt_AsSsize_t() is not checked to see
	if it is NULL
In-Reply-To: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
Message-ID: <1227980631.94.0.847868178005.issue4460@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> abstract.c(PyNumber_AsSsize_t) shows this check of PyInt_AsSsize_t()'s
> parameter:

Yup.  And that's because 'value' is the return value from 
PyNumber_Index.  PyNumber_Index might return NULL, so the check is 
necessary.

Am closing this as invalid.

I appreciate that you're trying to help here;  may I suggest that you 
take some time to read through the various development docs available?

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4460>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:49:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 17:49:20 +0000
Subject: [issue4466] The return value of PyFile_FromFile is not checked for
	NULL
In-Reply-To: <1227980445.15.0.00624503255277.issue4466@psf.upfronthosting.co.za>
Message-ID: <1227980960.53.0.380976729783.issue4466@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See explanation for issue 4465.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4466>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:59:47 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:59:47 +0000
Subject: [issue4467] return value of PyUnicode_AsEncodedString() is not
	checked for NULL
In-Reply-To: <1227981587.71.0.239031040576.issue4467@psf.upfronthosting.co.za>
Message-ID: <1227981587.71.0.239031040576.issue4467@psf.upfronthosting.co.za>


New submission from Brian Szuter <Brian.Szuter at gmail.com>:

Python-2.5.2/Objects/unicodeobject.c(unicode_str)
Line 6816

The return value of PyUnicode_AsEncodedString() is not checked for NULL.

According to
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-519 this
indicates an exception occurred.

See the following for instances of where this value is checked:
Parser/tokenizer.c(tok_stdin_decode) 726
Parser/tokenizer.c(dec_utf8) 1555
Objects/object.c(PyObject_GenericSetAttr) 1386
Objects/object.c(PyObject_GenericGetAttr) 1260
Objects/object.c(PyObject_SetAttr) 1161
Objects/object.c(PyObject_Str) 434-437
Objects/stringobject.c(PyString_AsEncodedString) 501
Objects/stringobject.c(PyString_AsDecodedString) 421
Objects/unicodeobject.c(_PyUnicodeUCS2_AsDefaultEncodedString) 735

----------
components: None
messages: 76614
nosy: CWRU_Researcher1
severity: normal
status: open
title: return value of PyUnicode_AsEncodedString() is not checked for NULL
type: performance
versions: Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4467>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:13:45 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 18:13:45 +0000
Subject: [issue4467] return value of PyUnicode_AsEncodedString() is not
	checked for NULL
In-Reply-To: <1227981587.71.0.239031040576.issue4467@psf.upfronthosting.co.za>
Message-ID: <1227982425.79.0.607589045392.issue4467@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See explanation for issue 4466.

It seems to me that you have some misunderstandings about the way that 
Python works.  Please could you refrain from introducing new issues here 
unless you're sure that they really *are* issues.

If you're unsure whether something really is an issue or not, I'd be happy 
to answer queries by email.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4467>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:17:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 18:17:32 +0000
Subject: [issue4462] result of PyList_GetItem() not validated
In-Reply-To: <1227977983.78.0.00196482293309.issue4462@psf.upfronthosting.co.za>
Message-ID: <1227982652.55.0.19733450059.issue4462@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

PyObject *hook = PyList_GetItem(meta_path, i);
loader = PyObject_CallMethod(hook, "find_module",
  "sO", fullname, path != NULL ? path : Py_None);


The "hook" pointer is checked for NULL in PyObject_CallMethod() -- see
line 1947 in Objects/abstract.c.  The hook is a general object
(hopefully with a find_module() method), not a string.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4462>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:21:54 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 18:21:54 +0000
Subject: [issue4464] PyList_GetItem() result and parameters not fully validated
In-Reply-To: <1227978395.86.0.799094154401.issue4464@psf.upfronthosting.co.za>
Message-ID: <1227982914.97.0.753179164141.issue4464@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Python/codecs.c line 144-147:

	func = PyList_GetItem(interp->codec_search_path, i);
	if (func == NULL)
	    goto onError;
	result = PyEval_CallObject(func, args);

The "func" result is expected to be a callable, not a string.

The code for PyList_GetItem does the list check.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4464>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:25:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 18:25:25 +0000
Subject: [issue4463] Parameters and result of PyList_GetItem() are not
	validated
In-Reply-To: <1227978134.48.0.524968542357.issue4463@psf.upfronthosting.co.za>
Message-ID: <1227983125.16.0.170235936275.issue4463@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Python/import.c lines: 1078-1082:

	for (j = 0; j < nhooks; j++) {
		PyObject *hook = PyList_GetItem(path_hooks, j);
		if (hook == NULL)
			return NULL;
		importer = PyObject_CallFunctionObjArgs(hook, p, NULL);

The "hook" object is supposed to be a callable, not a string.  The code
for PyList_GetItem() does its own argument checking.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4463>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:26:58 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 29 Nov 2008 18:26:58 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1227983218.59.0.78083147385.issue2053@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Attaching a new patch against a more recent revision (resolved minor
conflict).

Only 3 extremely minor changes from previous patch: fixed two more
places where the parent was being passed explicitly (no longer required)
and changed two tabs -> spaces.

I've done some fairly thorough manual testing of this, and have been
using it without any issues for almost six months.

Added file: http://bugs.python.org/file12161/IDLE_standardize_dialogs.081129.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:33:57 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2008 18:33:57 +0000
Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL
In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>
Message-ID: <1227983637.33.0.686635102365.issue4461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is an internal call, so am not worried about "const char *s" being
NULL -- that duty belongs to the caller who creates the pointer in the
first place.  That being said, it wouldn't hurt to add an assertion at
the beginning of the function.

----------
assignee:  -> marketdickinson
components: +Interpreter Core -None
keywords: +patch
nosy: +marketdickinson, rhettinger
priority:  -> low
stage:  -> patch review
type: resource usage -> 
versions: +Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12162/parsenumber.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4461>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:44:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 18:44:29 +0000
Subject: [issue4461] parameters of PyLong_FromString() are not checked for NULL
In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>
Message-ID: <1227984269.3.0.715249665432.issue4461@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch looks fine. (!)
Okay just to apply this to 2.6 and up?  It's not a bugfix.

----------
versions:  -Python 2.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4461>
_______________________________________

From report at bugs.python.org  Sat Nov 29 20:44:49 2008
From: report at bugs.python.org (John Smith)
Date: Sat, 29 Nov 2008 19:44:49 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1227987889.32.0.659007849803.issue1706039@psf.upfronthosting.co.za>


John Smith <ebgssth at gmail.com> added the comment:

Hi, when will this patch be checkedin?

----------
versions: +Python 2.5.3, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Sat Nov 29 21:28:16 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 20:28:16 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1227990496.09.0.0547512594422.issue1533@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I'm just curious to know which is the right behavior.

# Python 3.0
Traceback (most recent call last):
  File "bad_range.py", line 7, in <module>
    print(range(MyInt(2**3), MyInt(2**3+10)))
TypeError: 'MyInt' object cannot be interpreted as an integer

# Python 2.7a0
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L,
18446744073709551619L, 18446744073709551620L, 18446744073709551621L,
18446744073709551622L, 18446744073709551623L, 18446744073709551624L,
18446744073709551625L]
Traceback (most recent call last):
  File "bad_range.py", line 11, in <module>
    print(range(MyInt(2**64), MyInt(2**64+10)))
TypeError: range() integer start argument expected, got instance.

----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Sat Nov 29 21:45:37 2008
From: report at bugs.python.org (Robert Bradshaw)
Date: Sat, 29 Nov 2008 20:45:37 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1227991537.71.0.00164645391464.issue1533@psf.upfronthosting.co.za>


Robert Bradshaw <robertwb at math.washington.edu> added the comment:

I think *both* behaviors are wrong, the 3.0 one is backwards
incompatible, and the 2.7 one is inconsistent (accepting MyInt if it's <
32 bits, rejecting it for > 64 bits). 

For our particular use case, it is very annoying to not be able to use
non-ints. It goes against the principle duck typing by simply defining
the __int__ and __index__ methods.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Sat Nov 29 22:52:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 21:52:17 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1227995537.0.0.561361490214.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Martin: socket.socket has no destructor so a call to
socket.socket._real_close() is not guaranteed.  Thats fine as its parent
class from socketmodule.c _socket.socket does the right thing in its
destructor.

Amaury: The case you show doesn't call SOCKETCLOSE() because x still
exists and holds a reference to the socket object.

In order to fix that, SocketIO needs to drop its reference on close. 
Take a look at the attached -gps04 patch.  It fixes that.

Added file: http://bugs.python.org/file12163/issue3826_socket-gps04.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:22:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Nov 2008 22:22:58 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227997378.2.0.127280097426.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So the obvious quick fix is, on OS X only, to set the locale to e.g. 
"en_US.UTF-8" instead of "" just before the mbstowcs call.

Here's a patch that does this.

I don't like this much, though.  For one thing, I don't have any reason 
to believe that the particular locale "en_US.UTF-8" will be supported on 
any given installation of OS X.

Anyone have any better suggestions?

----------
keywords: +patch
Added file: http://bugs.python.org/file12164/issue4388.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:33:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Nov 2008 22:33:43 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227998023.9.0.953072691488.issue4426@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:36:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Nov 2008 22:36:07 +0000
Subject: [issue4425] UTF7 encoding of slash (character 47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1227998167.18.0.466972542294.issue4425@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4425>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:44:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 22:44:05 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1227998645.29.0.604376613315.issue1683@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine to me, somebody please backport it.

I'm concerned about the memory leak that this may cause, though (IIUC):
all the values are garbage, provided that they are pointers to dynamic
memory in the first place.

I think in the long run, we should allow to store a pointer to a release
function along with actual value to release.

----------
assignee: loewis -> 
priority: critical -> release blocker
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:48:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Nov 2008 22:48:04 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1227998884.38.0.532377607433.issue4387@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not /exactly/ nonsense, it seems to assume an utf8 encoding pass is
necessary:

>>> b'\xe1\x80\x80'.decode('utf8') == '\u1000'
True

IMO, while accepting unicode strings instead of bytes for the a2b_xx
functions is understandable (because in practice only ASCII characters
are allowed), it is not acceptable for b2a_xx functions to accept
unicode strings instead of bytes.

In other words, it might/should be ok for
`binascii.a2b_base64('YWFh\n')` to return the same as
`binascii.a2b_base64('YWFh\n')` (that is, b'aaa'), but
`binascii.b2a_base64('aaa')` should raise a TypeError rather than
applying an utf8 encoding pass before doing the actual b2a encoding.

I think this must be fixed before 3.0 final, and is therefore a release
blocker.

----------
nosy: +pitrou
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:49:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Nov 2008 22:49:43 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1227998983.27.0.629980333075.issue4387@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, I obviously meant:

[...] In other words, it might/should be ok for
`binascii.a2b_base64('YWFh\n')` to return the same as
`binascii.a2b_base64(b'YWFh\n')` (that is, b'aaa') [...]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:53:59 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 29 Nov 2008 22:53:59 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1227999239.02.0.941938264624.issue1533@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Updating versions.

----------
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Sun Nov 30 00:06:46 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 23:06:46 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1228000006.83.0.722914296312.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

gps05.diff includes the fix and unittests.

Added file: http://bugs.python.org/file12165/issue3826_gps05.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sun Nov 30 00:06:54 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 23:06:54 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1228000014.05.0.121964986129.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12154/issue3826_socket-gps03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sun Nov 30 00:07:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 23:07:17 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1228000037.22.0.562090576049.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12156/test_makefileclose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sun Nov 30 00:07:22 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Nov 2008 23:07:22 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1228000042.87.0.180974678411.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12163/issue3826_socket-gps04.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sun Nov 30 00:18:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 29 Nov 2008 23:18:43 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227997378.2.0.127280097426.issue4388@psf.upfronthosting.co.za>
Message-ID: <4931CDD1.3080007@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't like this much, though.  For one thing, I don't have any reason 
> to believe that the particular locale "en_US.UTF-8" will be supported on 
> any given installation of OS X.

I'm opposed to this patch for the same reason.

> Anyone have any better suggestions?

We should manually decode the command line arguments with UTF-8 on OSX;
this will require yet another UTF-8 implementation (this time to
wchar_t).

Regards,
Martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 08:37:54 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 30 Nov 2008 07:37:54 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1227915282.38.0.989542113729.issue3826@psf.upfronthosting.co.za>
Message-ID: <652897.39262.qm@web32806.mail.mud.yahoo.com>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

--- El vie 28-nov-08, Gregory P. Smith <report at bugs.python.org> escribi?:

> P.S.  Gabriel Genellina (gagenellina)  -  Your comment
> sounded like you
> had a unit test for this but it never got attached.  Still
> have it?

I've found it; it uses BaseHTTPRequestHandler as in the original bug report. I'm not sure it is still relevant, but I'm attaching it here anyway.

Added file: http://bugs.python.org/file12166/test_httpclose_py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_httpclose_py3k.py
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081130/a1253818/attachment.txt>

From report at bugs.python.org  Sun Nov 30 09:57:35 2008
From: report at bugs.python.org (Kay Schluehr)
Date: Sun, 30 Nov 2008 08:57:35 +0000
Subject: [issue4468] Restore chapter enumeration in Python docs
In-Reply-To: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za>
Message-ID: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za>


New submission from Kay Schluehr <kay at fiber-space.de>:

Request for restoring chapter enumeration in the Python docs for Python
2.6 and newer releases.

In the new style Sphinx documentation for Python the enumeration of
sections and subsections has been dropped. This is highly unusual for a
technical documentation and in particular for a body of documents that
represent a de-facto standard. An easy access to content is required
even in communication being not web based where URLs can be copied and
sent. Even right now the chm documents provided in the Windows
distribution of Python 2.6 are of reduced value. Given that there are
chapters with pretty generic titles like "How it works" the lack of
enumeration causes disorientation.

----------
assignee: georg.brandl
components: Documentation
messages: 76634
nosy: georg.brandl, schluehk
severity: normal
status: open
title: Restore chapter enumeration in Python docs
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4468>
_______________________________________

From report at bugs.python.org  Sun Nov 30 11:37:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 10:37:38 +0000
Subject: [issue4407] Windows Installer Error 1722 when opting for compilation
	at install time
In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
Message-ID: <1228041458.59.0.104198200547.issue4407@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. The problem was not with the quoting (this works
fine), but that test/crashers/iter.py failed to compile. Fixed in r67448.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________

From report at bugs.python.org  Sun Nov 30 12:14:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 11:14:18 +0000
Subject: [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1228043658.24.0.372636388049.issue4389@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks again for the report. This is now fixed in r67449, r67450, r67451.

Marc-Andre, if you want request a change to bdist_msi, please submit a
separate report. I'm skeptical though that bdist_msi packages should use
the Python icon in ARP.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________

From report at bugs.python.org  Sun Nov 30 13:38:22 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Sun, 30 Nov 2008 12:38:22 +0000
Subject: [issue4457] __import__ documentation obsolete
In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za>
Message-ID: <1228048702.16.0.772109295894.issue4457@psf.upfronthosting.co.za>


Mart S?mermaa <mrts at mrts.pri.ee> added the comment:

Also, the examples that clarify __import__ behaviour by Nick Coghlan
should be added:

http://mail.python.org/pipermail/python-dev/2008-November/083735.html

---

"from foo.bar import baz" ---->

<stack top> = __import__('foo.bar', globals(), locals(), ['baz'], -1)
baz = <stack top>.baz

When there are multiple names being imported or an 'as' clause is
involved, I hope the reasons for doing it this way become more obvious:

"from foo.bar import baz, bob" ---->

<stack top> = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
baz = <stack top>.baz
bob = <stack top>.bob

"from foo.bar import baz as bob" ---->

<stack top> = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
bob = <stack top>.baz

---

And the "winning idiom" by Hrvoje Niksic for accessing module 'z', given
name hierarchy 'x.y.z' should be documented as well:

>>> import sys
>>> __import__('x.y.z')
>>> mod = sys.modules['x.y.z']

----------
nosy: +mrts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4457>
_______________________________________

From report at bugs.python.org  Sun Nov 30 14:38:53 2008
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 30 Nov 2008 13:38:53 +0000
Subject: [issue4469] CVE-2008-5031 multiple integer overflows
In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>
Message-ID: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507317

needs backport of rev 61350 from the trunk.

fixed in newer versions.

----------
components: Interpreter Core
messages: 76638
nosy: doko
priority: release blocker
severity: normal
status: open
title: CVE-2008-5031 multiple integer overflows
type: security
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4469>
_______________________________________

From report at bugs.python.org  Sun Nov 30 14:48:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 13:48:31 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1228052911.06.0.801598122852.issue4387@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patches that fixes the problem.

Notice that this affects the email API; base64mime.body_encode now also
requires bytes (whereas quoprimime remains unchanged).

There are probably more functions that still incorrectly accept strings,
e.g. zlib.crc32.

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file12167/reqbytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sun Nov 30 14:58:56 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 13:58:56 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1228053536.15.0.74498504278.issue4387@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:23:34 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:23:34 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>


New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:

The enclosed patch does three things:
1. enables SMTP_SSL working: the _get_socket method was setting
   self.sock instead of returning the socket to the caller, which
   did reset self.sock to None
2. replace home-grown SSLFakeFile() with calls to ssl.socket's makefile()
   calls both in the starttls and in the SMTP_SSL cases
3. shutdown sockets before closing them, to avoid server-side piling and
   connection refused on connection-limited servers
The last change is just a cosmetical refactoring, but it really helps
the SMTP_SSL case: default_port should really be a class attribute,
instead of being set at __init__ time.

----------
components: Library (Lib)
files: smtplib.py.patch
keywords: patch
messages: 76640
nosy: lcatucci
severity: normal
status: open
title: smtplib SMTP_SSL not working.
versions: Python 2.6
Added file: http://bugs.python.org/file12168/smtplib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:33:16 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:33:16 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>


New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:

In the enclosed patch, there are three changes:
1. Support starttls on IMAP4 connections
2. Rework of the IMAP_SSL, to replace home-grown file-like
   methods with proper ones from ssl module's makefile();
3. Properly shutdown sockets at close() time to avoid server-side pile-up

----------
components: Library (Lib)
files: imaplib.py.patch
keywords: patch
messages: 76641
nosy: lcatucci
severity: normal
status: open
title: IMAP4 missing support for starttls
versions: Python 2.6
Added file: http://bugs.python.org/file12169/imaplib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:37:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 30 Nov 2008 16:37:55 +0000
Subject: [issue4472] Is shared lib building broken on trunk?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <18738.49496.996446.483821@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

I have tried several different combinations of configure args on my Mac in
the past couple days in a so far fruitless attempt to generate a
libpython.2.7.dylib file.  All it will ever generate is a .a file.  I've
come to the conclusion that building a shared Python library is broken, at
least on Macs.  I only even noticed this because I wanted to bundle up a
trivial little Python script as a Mac app build.  py2app requires a dylib
file to generate the app bundle (to include?).

I build in separate build directories so I can have normal, debug and
framework builds.  Here's the configure command from my framework build:

    ../configure --prefix=/Users/skip/local --enable-shared \
        '--enable-framework=/Users/skip/Applications' \
        'CPPFLAGS=-I/Users/skip/local/include -I/opt/local/include' \
        'LDFLAGS=-L/Users/skip/local/lib -L/opt/local/lib'

I've tried taking out the --prefix and/or --enable-shared flags thinking
maybe the --enable-framework flag was sufficient.  I've tried making the
sharedinstall target.  I never see anything like -fPIC or -fpic in the gcc
command line args.  In fact, I don't see "dylib" or "pic" mentioned in the
Makefile at all.

I gave up building in a subdirectory then whittled the configure command
down to this:

    ./configure --prefix=/Users/skip/local --enable-shared \
        '--enable-framework=/Users/skip/Applications'

make clean.  make.  Still no libpython.2.7.dylib file.

Skip

----------
messages: 76642
nosy: skip.montanaro
severity: normal
status: open
title: Is shared lib building broken on trunk?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:39:03 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:39:03 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>


New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:

In the enclosed patch, there are four changes 
1. add support for the optional CAPA pop command, since it is needed
   for starttls support discovery
2. add support for the STLS pop command
3. replace home-grown file-like methods and replace them with ssl
   socket's makefile() in POP3_SSL
4. Properly shutdown sockets at close() time to avoid server-side pile-up

----------
files: poplib.py.patch
keywords: patch
messages: 76643
nosy: lcatucci
severity: normal
status: open
title: POP3 missing support for starttls
Added file: http://bugs.python.org/file12170/poplib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:45:19 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:45:19 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1228063519.01.0.265933659471.issue4471@psf.upfronthosting.co.za>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

the needed changes to library documentation if the patch is accepted

Added file: http://bugs.python.org/file12171/imaplib.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:46:18 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:46:18 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1228063578.32.0.505429062353.issue4473@psf.upfronthosting.co.za>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

The needed changes to documentation if the patch gets accepted

Added file: http://bugs.python.org/file12172/poplib.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Sun Nov 30 18:32:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 17:32:52 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1228066372.85.0.95271528221.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm now very confused.

In trying to follow things of type wchar_t* around the Python source, I 
discovered PyUnicode_FromWideChar in unicodebject.c.  For OS X, the 
conversion lands in the following code, where w is the incoming WideChar 
array, declared as wchar_t *.

	register Py_UNICODE *u;
	register Py_ssize_t i;
	u = PyUnicode_AS_UNICODE(unicode);
	for (i = size; i > 0; i--)
	    *u++ = *w++;

But this looks wrong:  on OS X, sizeof(wchar_t) is 4 and I think w is 
encoded in UTF-32.  So I was expecting to see some kind of explicit 
conversion from UTF-32 to UCS-2 here.  Instead, it looks as though the 
incoming values are implicitly truncated from 32 bits to 16.  Doesn't this 
do the wrong thing for characters outside the BMP?

Should I open an issue for this, or am I simply misunderstanding?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 18:56:26 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 30 Nov 2008 17:56:26 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1228067786.36.0.68429523373.issue4370@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Attached patch just leaves Py_GCC_ATTRIBUTE as it is now.
Here is the highlight.

/*
 * Hide GCC's format attribute from compilers if one of the following is
true:
 * a) the compiler does not support it and not on RISC OS
 * b) the compiler does not support "z" printf format specifier
 */
#if ((!defined(__GNUC__) || __GNUC__ < 2 || \
     (__GNUC__ == 2 && __GNUC_MINOR__ < 3)) && \
     !defined(RISCOS)) || \
    !defined(PY_FORMAT_SIZE_T)
#define Py_GCC_FORMAT_ATTRIBUTE(type, str_idx, arg_idx)
/* Py_GCC_ATTRIBUTE is deprecated; use Py_GCC_FORMAT_ATTRIBUTE instead. */
#define Py_GCC_ATTRIBUTE(x)
#else
#define Py_GCC_FORMAT_ATTRIBUTE(type, str_idx, arg_idx) \
    __attribute__((format(type, str_idx, arg_idx)))
/* Py_GCC_ATTRIBUTE is deprecated; use Py_GCC_FORMAT_ATTRIBUTE instead. */
#define Py_GCC_ATTRIBUTE(x) __attribute__(x)
#endif

Added file: http://bugs.python.org/file12173/issue4370.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sun Nov 30 18:56:37 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 30 Nov 2008 17:56:37 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1228067797.43.0.448498351489.issue4370@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file12160/issue4370.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:05:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 18:05:29 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1228068329.32.0.381141174178.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> conversion from UTF-32 to UCS-2 here

That 'UCS-2' should be 'UTF-16', of course.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:22:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 18:22:40 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1228066372.85.0.95271528221.issue4388@psf.upfronthosting.co.za>
Message-ID: <4932D9ED.90103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Should I open an issue for this, or am I simply misunderstanding?

I think you are right. However, conversion to/from wchar_t is/was
rarely used, and so are non-BMP characters; it's very likely that
the problem hasn't occurred in practice (and I doubt it would occur
in 3.0 if not fixed - there are more severe problems around).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:31:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 18:31:29 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1228069889.01.0.288294179332.issue4073@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the review. Here is a revised version, addressing comments 1
and 2.

Comment 3 is address by exposing all arguments to RefactoringTool as
class variables in a new class Mixin2to3, from which build_py and
build_scripts inherit.

Added file: http://bugs.python.org/file12174/build_scripts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:31:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 18:31:39 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1228069899.85.0.00361100462442.issue4073@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file11803/build_scripts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:54:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 18:54:08 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

On systems (Linux, OS X) where sizeof(wchar_t) is 4 and wchar_t arrays are 
usually encoded as UTF-32, it looks as though PyUnicode_FromWideChar 
simply truncates the 32-bit characters to 16-bits, thus giving incorrect 
results for characters outside the BMP.  I expected it to convert the UTF-
32 encoding to UTF-16.

Note that PyUnicode_FromWideChar is used to process command-line 
arguments, so strange things can happen when passing filenames with non-
BMP characters to a Python script.

Here's an OS X 10.5 Terminal session (current directory is the root of the 
py3k tree).

dickinsm$ cat test??.py
from sys import argv
print("My arguments are: ",argv)
dickinsm$ ./python.exe test??.py
My arguments are:  ['test?.py']
dickinsm$ ./python.exe Lib/tabnanny.py test??.py
'test?.py': I/O Error: [Errno 2] No such file or directory: 'test?.py'


(In case the character after 'test' and before '.py' isn't showing up 
correctly, it's chr(65901), 'GREEK ACROPHONIC TROEZENIAN FIVE HUNDRED'.)

----------
components: Interpreter Core
messages: 76651
nosy: marketdickinson
severity: normal
status: open
title: PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only)
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:59:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 18:59:13 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1228071553.37.0.762658807292.issue4388@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> it's very likely that
> the problem hasn't occurred in practice (and I doubt it would occur
> in 3.0 if not fixed - there are more severe problems around).

Okay. So it's an issue, but not a blocker. Opened issue 4474 for this.

Thanks, Martin.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:00:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 19:00:27 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228071627.35.0.424874103109.issue4474@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Comments from MvL in issue 4388:

> I think you are right. However, conversion to/from wchar_t is/was
> rarely used, and so are non-BMP characters; it's very likely that
> the problem hasn't occurred in practice (and I doubt it would occur
> in 3.0 if not fixed - there are more severe problems around).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:16:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Nov 2008 19:16:48 +0000
Subject: [issue4469] CVE-2008-5031 multiple integer overflows
In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>
Message-ID: <1228072608.84.0.871298238873.issue4469@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4469>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:18:41 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 30 Nov 2008 19:18:41 +0000
Subject: [issue4468] Restore chapter enumeration in Python docs
In-Reply-To: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za>
Message-ID: <1228072721.94.0.212294802458.issue4468@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


----------
nosy: +wplappert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4468>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:29:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 19:29:39 +0000
Subject: [issue4365] Add CRT version info in msvcrt module
In-Reply-To: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>
Message-ID: <1228073379.02.0.972257432888.issue4365@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed (with modifications) as r67455.

Barry, I would like to apply this to both 2.6 and 3.0. Ok?

----------
assignee:  -> barry
nosy: +barry, loewis
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4365>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:35:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 30 Nov 2008 19:35:19 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228073719.28.0.245269040393.issue4474@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:40:44 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 19:40:44 +0000
Subject: [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1228074044.5.0.0557406800416.issue2306@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Guido... ping?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:42:15 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 19:42:15 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1228074135.82.0.221208125966.issue4449@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Jesse, please apply so we can close this issue.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:44:14 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 19:44:14 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1228074254.55.0.139453167257.issue4385@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I agree with MvL and MAL.  We can't change Python, so this is a
documentation issue.  I'm lowering the priority so it doesn't block the
release.

----------
nosy: +barry
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:47:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 19:47:10 +0000
Subject: [issue1683] Thread local storage and PyGILState_* mucked up by
	os.fork()
In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>
Message-ID: <1228074430.62.0.483168144368.issue1683@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Since this is a Python 2.5.3 issue, I'm lowering to deferred blocker
until after 3.0 and 2.6.1 are released.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:55:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 30 Nov 2008 19:55:33 +0000
Subject: [issue4475] More verbose error message for Py_FindMethod
In-Reply-To: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>
Message-ID: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

As was told in
http://mail.python.org/pipermail/python-dev/2008-November/083782.html
some objects may print a not so nice message when an attribute is not
found. 
I considered this was due to Py_FindMethod being so easy to use that is
probably used in several extensions but it doesn't set a good error message.

----------
components: Interpreter Core
files: FindMethod_verbose_err.diff
keywords: patch
messages: 76659
nosy: gpolo
severity: normal
status: open
title: More verbose error message for Py_FindMethod
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12175/FindMethod_verbose_err.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4475>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:59:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2008 19:59:14 +0000
Subject: [issue4073] distutils build_scripts and install_data commands need
	2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1228075154.67.0.842998290573.issue4073@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Looks good.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4073>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:10:38 2008
From: report at bugs.python.org (Eric Devolder)
Date: Sun, 30 Nov 2008 20:10:38 +0000
Subject: [issue4407] Windows Installer Error 1722 when opting for compilation
	at install time
In-Reply-To: <1228041458.59.0.104198200547.issue4407@psf.upfronthosting.co.za>
Message-ID: <f0531c170811301210r52add6b5j684b1cac35ea8e26@mail.gmail.com>


Eric Devolder <eric.devolder at gmail.com> added the comment:

Dear Martin,

It's my pleasure. I'm just sorry if I misled you a bit, but as I told I
haven't managed to have a full testing env yet ( although I'm close to it),
so I could not check in time if it would have fixed the bug.

Thanks for the great work.

Eric

2008/11/30 Martin v. L?wis <report at bugs.python.org>

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Thanks for the report. The problem was not with the quoting (this works
> fine), but that test/crashers/iter.py failed to compile. Fixed in r67448.
>
> ----------
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4407>
> _______________________________________
>

Added file: http://bugs.python.org/file12176/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20081130/8d859a75/attachment.txt>

From report at bugs.python.org  Sun Nov 30 21:14:39 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 20:14:39 +0000
Subject: [issue4387] binascii b2a functions accept strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1228076079.06.0.315945766393.issue4387@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Martin, the patch looks okay to me.  I vote for applying it.

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:15:11 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 20:15:11 +0000
Subject: [issue4469] CVE-2008-5031 multiple integer overflows
In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>
Message-ID: <1228076111.6.0.150427138231.issue4469@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Lowering priority since this is not a Python 3.0 or 2.6.1 issue.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4469>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:17:00 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Nov 2008 20:17:00 +0000
Subject: [issue4365] Add CRT version info in msvcrt module
In-Reply-To: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>
Message-ID: <1228076220.62.0.534891350943.issue4365@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Go for it Martin.

----------
resolution:  -> accepted
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4365>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:27:56 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 30 Nov 2008 21:27:56 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228080476.43.0.311899316493.issue4474@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

it is fine on linux (tested with UTF-8 codeset for locale):
$ ./python test??.py
('My arguments are: ', ['test\xf0\x90\x85\xad.py'])
\xf0\x90\x85\xad (UTF-8) =  0001016d (USC-4) = 65901

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:29:46 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 30 Nov 2008 21:29:46 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228080586.46.0.113221427708.issue4474@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

s/USC-4/UCS-4/g

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:42:57 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 30 Nov 2008 21:42:57 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1228081377.61.0.242690846989.issue4388@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

"C locale (alias POSIX, ANSI_X3.4-1968) define is 7-bit char-set.
It is expected mbstowcs to return error is a byte sequence contain a
byte > 128. 

After quick check into code
(http://svn.python.org/view/python/branches/py3k/Lib/test/test_cmd_line.py?rev=67193&view=auto)
I guess that failure is from command "assert(ord('\xe9') == 0xe9)" (test
is run only on mac os platforms). For the "C" program run is ascii(C,..)
locale is expected conversion of byte \xe9 to wchar_t to return error.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:58:27 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 30 Nov 2008 21:58:27 +0000
Subject: [issue4475] More verbose error message for Py_FindMethod
In-Reply-To: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>
Message-ID: <1228082307.75.0.856716747934.issue4475@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4475>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:00:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 30 Nov 2008 22:00:10 +0000
Subject: [issue4475] More verbose error message for Py_FindMethod
In-Reply-To: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>
Message-ID: <1228082410.91.0.875808587064.issue4475@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Py_FindMethod was removed in 3.0

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4475>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:07:11 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 30 Nov 2008 22:07:11 +0000
Subject: [issue4472] Is shared lib building broken on trunk?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1228082831.23.0.78565798271.issue4472@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

OS X 10.5.5 seems to have the problem just as described, 
whereas there seems no problem on FreeBSD 6.3.

----------
components: +Build, Macintosh
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:22:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 22:22:05 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228083725.25.0.74777585107.issue4474@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> it is fine on linux

Interesting.  Which version of Python is that?  And is PyUNICODE 2 bytes 
or 4 bytes for that build of Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________