[ python-Bugs-1515471 ] wrong handling of character buffers in stringobject

[SourceForge.net]

Bugs item #1515471, was opened at 2006-07-01 02:41
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: wrong handling of character buffers in stringobject

Initial Comment:
stringobject.c:

In string_replace, there is

if (PyString_Check(from)) {
  /* Can this be made a '!check' after the Unicode
check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
 from, to, count);
#endif
else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
return NULL;

[the same check with "to"]

return (PyObject *)replace((PyStringObject *) self,
   (PyStringObject *) from,
   (PyStringObject *) to, count);

This is not correct if from or to isn't a string
object, but a char buffer compatible object.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-30 00:03

Message:
Logged In: YES 
user_id=33168

Committed revision 50970.

Georg, let me know if you find any more issues.  I didn't
look for other places where a buffer wasn't handled
properly.  Thanks.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need updating

[SourceForge.net]

Bugs item #1495229, was opened at 2006-05-26 01:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Martin v. Löwis (loewis)
Summary: W3C <-> Python DOM type mapping docs need updating

Initial Comment:
I believe the information at
http://docs.python.org/lib/dom-type-mapping.html is
outdated; most if not all boolean return values, at
least in minidom, are handled as BooleanType, not
IntegerType. This should be standard.

Sorry, I don't have a patch to submit for this. Should
be an easy fix though.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-30 09:25

Message:
Logged In: YES 
user_id=21627

I agree with Fred that the documentation is not wrong as it
stands. As this section is meant to apply not only to
minidom, but to all Python DOM implementations, I don't
think the specification can be changed. minidom would
probably still comply (except perhaps for the "specified"
attribute), but other implementations might comply anymore.

If clarification is needed, it should go beyond boolean:
What is "IntegerType"? There is no type with that name in
Python, and, indeed, "unsigned long" cannot alway map to
types.IntType; unsigned long long (used for DOMTimeStamp)
and unsigned short don't get mapped at all in the table.

I think the intention is this: for the "proper" IDL integer
types (short, long, long long, +unsigned), both Python int
and long can be used. For boolean, int, long, and bool can
be used; on input, any non-zero value counts as true, and on
output, only 0 or 1 should be returned (where bool(0) is
False and bool(1) is True).

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 06:56

Message:
Logged In: YES 
user_id=3066

My position on this is that:

1) The docs are not wrong.

2) The docs should be updated to indicate that bool values
are returned where appropriate.

3) It is reasonable that Python developers know the
relationship between bool and int.  That is not something
that can reasonably change in Python 2.x.  It seems unlikely
to change for Python 3000.

4) The strict application of the IDL mapping really hasn't
helped in creating a good DOM-like interface for Python.

Dealing with the last item isn't within scope for handling
this issue.


--

Comment By: Mike Brown (mike_j_brown)
Date: 2006-06-03 23:01

Message:
Logged In: YES 
user_id=371366

If answer #1 is chosen and the others rejected, then the
docs remain misleading, since the average reader just wants
to know what types to expect from an implementation (or
should code into their implementation), and shouldn't be
expected to know the relationship between Booleans and
integers. Is it even reasonable to expect that this
relationship will always be true? In any case, I'd rather
see it made explicit as to why minidom doesn't seem, at
first, to respect the type mapping, at least in current
implementations. It could be as simple as adding Andrew's
comment, phrased as "This DOM mapping is derived from the
IDL mapping for Python, which predates the introduction of
BooleanType, which is currently a subtype of IntegerType.
Implementations may use either type." or some such.

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 22:42

Message:
Logged In: YES 
user_id=11375

Martin, you probably need to make a pronouncement on this.  The DOM 
mapping is supposed to be derived from the IDL mapping for Python, which 
predates Booleans, but methods such as hasChildNodes() return True/False.
I can see at least three answers:

1) Booleans are subtypes of integers, so the docs are not wrong.

2) The docs are wrong and should say Boolean.

3) The methods should be returning regular 0 and 1, not True and False, and 
should be changed.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-878908 ] suspect documentation of operator.isNumberType

[SourceForge.net]

Bugs item #878908, was opened at 2004-01-17 17:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878908&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: suspect documentation of operator.isNumberType 

Initial Comment:
The docs appear to draw a distinction between
containers and simple classes.  I had expected the
NumberType to include IntType, LongType, FloatType,
ComplexType and, perhaps BoolType, but no others.

The attached script shows that it includes the
BoolType, but it also includes the numarray.array.

On the other hand, it does not include array.array.

This is to suggest that either the docs be clarified or
a probably bug be reported.

--

Comment By: Tim Peters (tim_one)
Date: 2004-01-18 04:49

Message:
Logged In: YES 
user_id=31435

Sorry, I don't understand your point.  bool is a subtype of int, 
so of course it "acts like a number".  numarray isn't part of 
the Python core, so the core Python docs have nothing to 
say about it.  It seems reasonable to me for a numarray.array 
to say it's numeric, because it supports numeric operations 
(for example, you can add 1 to a numeric.array, and it 
broadcasts the scalar; you cannot add 1 to an array.array -- 
there's nothing number-like about array.arrays).

More formally, numarray.array fills in the type object's 
tp_as_number slot at the C level, while array.array does not.  
That's the only clue Python has as to whether a type 
is "number-like", and is (almost) the only thing the 
implementation of isNumberType looks at.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878908&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1002453 ] Wrong documentation of __radd__ etc.

[SourceForge.net]

Bugs item #1002453, was opened at 2004-08-03 07:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation of __radd__ etc.

Initial Comment:
Info node 'Emulating numeric types' says:

  __radd__(self, other)
  __rsub__(self, other)
  ...
  These functions are only called if the left operand
  does not support the corresponding operation.

Not so. Info node 'Coercion rules' lists one exception:

  if the left operand is an instance of a built-in
  type or a new-style class, and the right operand is
  an instance of a proper subclass of that type or
  class, the right operand's `__rop__()' method is
  tried _before_ the left operand's `__op__()' method.

...and one time where above the text is misleading:

  When either operand type defines a coercion, this
  coercion is called before that type's `__op__()' or
  `__rop__()' method is called, but no sooner.  If the
  coercion returns an object of a different type for
  the operand whose coercion is invoked, part of the
  process is redone using the new object.

Thus, Python can call __rop__(self, other) even if
self.__op__ exists:  If one does `x - y' where
y.__coerce__(x) coerces x to y's class, y.__rsub__(x)
is called instead of (coerced x).__sub__(y).  I think
this should be documented in the 'Emulating numeric
types' node.  Unless Python is changed to redo the
choice between __op__, __rop__ and __iop__ after
coercion.

I think it would also be good to explain in that Info
node what __op__ and __rop__ can do if they do not
support the operation with the supplied arguments, but
the other argument might support it.  It seems obvious
that self.__op__(other) can simply attempt to call
other.__rop__(self) and let that fail if it is not
supported.  However, the above rules seem to mean that
self.__rop__(other) might want to call
other.__op__(self) too, which could lead to infinite
recursion.  Are there some special times where it can
do that, and other times where it should not?


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 10:53

Message:
Logged In: YES 
user_id=849994

A note was added to __rop__ documentation a while ago.

--

Comment By: Andrew Durdin (adurdin)
Date: 2004-09-08 09:52

Message:
Logged In: YES 
user_id=625864

> I think it would also be good to explain in that Info
> node what __op__ and __rop__ can do if they do not
> support the operation with the supplied arguments

In that case I believe they should just return NotImplemented.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist)

[SourceForge.net]

Bugs item #1071248, was opened at 2004-11-22 20:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Later
Priority: 5
Submitted By: Lenard Lindstrom (kermode)
Assigned to: Jeremy Hylton (jhylton)
Summary: Documented grammar for List displays incorrect (testlist)

Initial Comment:
In section 5.2.4 of the Python Reference Manual for
Pythons 2.4 and 2.3 the definition

testlist ::= test ( "," test )* [ "," ]

should be

testlist ::= test [ ( "," test )+ [ "," ] ]

to conform with the definition of testlist_safe in the
Grammar definition file. In other words, a trailing
comma is not permitted if there is only one test in
testlist.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:02

Message:
Logged In: YES 
user_id=849994

This is subsumed by patch #1489771.

--

Comment By: Lenard Lindstrom (kermode)
Date: 2004-12-17 00:00

Message:
Logged In: YES 
user_id=663274

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> [x for x in 1,]
  File "", line 1
[x for x in 1,]
  ^
SyntaxError: invalid syntax
>>> [x for x in 1,2,]
[1, 2]
>>> for x in 1,:
... print x
...
1
>>>


--

Comment By: engelbert gruber (grubert)
Date: 2004-12-15 08:50

Message:
Logged In: YES 
user_id=147070

but

>>> testlist = 1,
>>> testlist
(1,)

so testlist = 1 does not produce a list

testlist ::= one "," ( another "," )* [and [","]]

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-766842 ] Installing documentation doesn't make it show up

[SourceForge.net]

Bugs item #766842, was opened at 2003-07-06 21:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Pending
>Resolution: Out of Date
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Installing documentation doesn't make it show up

Initial Comment:
If you're installing the full Python documentation through 
Package Manager, but you've already run the IDE previously 
(the common case) the new documentation doesn't show up 
in the Apple Help Viewer. It does show up when you remove 
your help preferences.

Probably a bug in the registration code in PythonIDE.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:04

Message:
Logged In: YES 
user_id=849994

Should be obsolete as PythonIDE is deprecated...

--

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-21 21:07

Message:
Logged In: YES 
user_id=45365

The IDE registration code turns out to be fine, so the problem is 
probably that if you do AHRegisterHelpBook() for an app for which 
you've done so before the call is simply ignored, in stead of the 
app being re-examined. This makes the problem difficult to fix 
right now.

A possible fix would be to put the "MacPython Help" and "Python 
Documentation" into two different apps (the former in the IDE and 
the latter in Python.app?), but that's too much work for now. 

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1002398 ] os.path.sameopenfile documentation wrong.

[SourceForge.net]

Bugs item #1002398, was opened at 2004-08-03 03:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.sameopenfile documentation wrong.

Initial Comment:
At http://docs.python.org/lib/module-os.path.html it very clearly 
states this:

sameopenfile(fp1, fp2)

Return True if the file objects fp1 and fp2 refer to the same file. 
The two file objects may represent different file descriptors. 
Availability: Macintosh, Unix.

However, on my OSX box, the source to posixpath.py clearly says 
otherwise:

def sameopenfile(fp1, fp2):
"""Test whether two open file objects reference the same file"""
s1 = os.fstat(fp1)
s2 = os.fstat(fp2)
return samestat(s1, s2)

I.e., sameopenfile accepts two integer filenos, not two file objects.  
Running it gives this exception:

  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/site-packages/supybot/plugins/Tail.py", line 77, 
in samefile
return os.path.sameopenfile(fd1, fd2)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/posixpath.py", line 220, in sameopenfile
s1 = os.fstat(fp1)
TypeError: an integer is required

Perhaps the (much more useful) documented behavior can be 
retained, and two if statements added to the definition of 
sameopenfile:

if not isinstance(fp1, int): fp1 = fp1.fileno()
if not isinstance(fp2, int): fp2 = fp2.fileno()

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:08

Message:
Logged In: YES 
user_id=849994

The function is not needed so often to warrant a
implementation change.

Fixed the docs in rev. 50974, 50975 (2.4).

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:48

Message:
Logged In: YES 
user_id=1188172

The question is, should we fix the docs or the
implementation? Or add the suggested hybrid-solution
(drawback: no other function that deals with files currently
allows file objects and descriptors).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in

[SourceForge.net]

Bugs item #1381717, was opened at 2005-12-15 15:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simo Salminen (ssalmine)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode 't' not documented as posssible mode for file built-in

Initial Comment:
At http://docs.python.org/lib/built-in-funcs.html,
'file' function parameter 'mode' accepts 't' (for text
mode). 

This is not documented. It is mentioned in file object
description
(http://docs.python.org/lib/bltin-file-objects.html).

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:11

Message:
Logged In: YES 
user_id=849994

I believe there's nothing more to do here.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 21:36

Message:
Logged In: YES 
user_id=1188172

I removed the reference to "t" from the docs of file.seek()
in rev 41703,41704.

--

Comment By: Tim Peters (tim_one)
Date: 2005-12-15 16:08

Message:
Logged In: YES 
user_id=31435

This is more involved than you might like.  In general,
open(path, mode) passes the mode string to the platform C
library's file-opening function, and using anything other
than standard C mode letters ("w", "b", "r", "a", "+") is
platform-dependent.  "t" is not a standard C mode letter, so
whether it has any meaning, and exactly what it means if it
_does_ mean something, depends entirely on the platform C
library.

Using "t" to force text mode is a Microsoft-specific
gimmick, so if "t" is documented at all, it should be
plastered with warnings about its platform-specific nature.
 Even on a Microsoft platform, "t" is basically silly:  text
mode is the default mode (C defines this) -- it's what you
get if you don't pass "b".  The only reason Microsoft
supports "t" is because MS has _another_ non-standard option
to tell its C runtime to use binary mode by default, and if
you use that non-standard option then you also need to use
the non-standard "t" mode letter to force a file to open in
text mode.

In short, the docs should change to spell out what the
standard C modes are, and note that at the cost of
portability you can also pass whichever non-standard mode
extensions your platform happens to support.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault

[SourceForge.net]

Bugs item #780714, was opened at 2003-07-31 08:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Gregory (stefan_gregory)
Assigned to: Nobody/Anonymous (nobody)
Summary: infinite __str__ recursion in thread causes seg fault

Initial Comment:
The following code reliably produces a segmentation
fault under Solaris8 in Python2.3, Python2.2,
Python2.1.3 and Python1.5. It produces a Bus Error when
run on Python2.2 under OSX. Clearly it should produce a
Python RuntimeError.

import thread, time

class Frog:

def __str__(self):
return str(self)

f = Frog()
thread.start_new_thread(str,(f,))
time.sleep(1000)

This problem manifests in scenarios such as when you
have 2 publishing objects (such as HTMLgen objects) A
and B and you put A inside B and B inside A and each
objects __str__ method calls its childrens __str__
methods and voila! (I hope this might be the reason my
Zope server has been intermitently crashing for the
past year or so though I have not found any recursive
structures yet.)

With Python2.3 gdb reports:

vgetargskeywords (args=0x1bdaf0, keywords=0x0,
format=0xd2579 "0:str", kwlist=0xf7b4c,
p_va=0xfed0C02c) at Python/getargs.c:1167

Though with Python2.1 it dies at line 330 in getargs.c.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:16

Message:
Logged In: YES 
user_id=849994

Under 2.5, I get a runtime error now, so this might be fixed.

--

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 19:22

Message:
Logged In: YES 
user_id=357491

Forgot to mention that Modules/threadmodule.c has 
thread_PyThread_start_new_thread which uses Python/
thread_*.h's PyThread_start_new_thread for executing threads;  
the '*' is replaced with the threading library used on your 
platform.  OS X should use thread_pthread.h (I think).

--

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 19:19

Message:
Logged In: YES 
user_id=357491

If you run ``str(Frog())`` instead of a bunch of threads you do get 
a RuntimeError.  Looks like this bus error has something to do 
with thread.start_new_thread and not 'str'.  It might be that since 
it runs using pthreads it does not have the built-in recursion limit 
check that the Python interpreter has.  Anyone with more 
experience with the 'thread' module have any ideas?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1166378 ] No os.spawn*p* on Windows

[SourceForge.net]

Feature Requests item #1166378, was opened at 2005-03-19 03:41
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1166378&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

--

Comment By: Christos Georgiou (tzot)
Date: 2005-03-21 09:17

Message:
Logged In: YES 
user_id=539787

This bug is *not* a bug, so it should be closed, and an
entry made in RFE (Request For Enhancements) aka wishlist.
Google has many pointers.  See for example
http://mail.python.org/pipermail/python-dev/2003-April/034473.html
.
Patches are welcome (either code or documentation).

--

Comment By: Chris Palmer (chris_palmer)
Date: 2005-03-20 20:43

Message:
Logged In: YES 
user_id=1242303

Okay, I read the page you point to. It provides no
explanation, just a statement of the fact I had already
discovered. An explanation would be nice.

Don't you think it's strange that these three conditions
should hold:

1. os.exec*p* are supported on Windows;
2. Windows systems have a PATH environment variable with the
same meaning and use as UNIX; and yet
3. os.spawn*p* are not supported on Windows?

If there's some difference to how the environment is treated
or used between exec* and spawn* on Windows, wouldn't it be
easy to emulate the PATH-searching feature?

My options are to emulate the PATH-searching feature myself
and ignore os.spawn*p* on all platforms, or to use it when
it's present and only emulate it on Windows. The first
option is ridiculous, the second is ridiculous and ugly.

If you won't emulate the spawn*p* behavior -- it's three
lines of Python! -- it would help if you could at least
explain why, technically.

Thanks.

--

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 10:02

Message:
Logged In: YES 
user_id=539787

This is documented (see
http://docs.python.org/lib/os-process.html). Python lib has
many places where underlying platform controls availability
of functionality.
Suggest closing of this bug or converting it to wishlist item.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1166378&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars

[SourceForge.net]

Bugs item #1193180, was opened at 2005-04-30 23:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange os.path.exists() results with invalid chars

Initial Comment:
Hi,

when there are invalid chars in a filename, os.path.exists
() behaves oddly, returning True.

The bug appears on win32 system, not on unix ones. 
Thus is probably related to some weird windows api call 
and doesn't maybe worth fixing.

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os
>>> f = file("a_b", "w")
>>> f.close()
>>> os.listdir(".")
['a_b']
>>> os.path.exists("a>> os.path.exists("a>b")
True

And, even more strange...

>>> os.path.exists("a<")
True
>>> os.path.exists("a>")
False

Better answers would have been:
  * False
  * raise ValueError


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-05-31 09:56

Message:
Logged In: YES 
user_id=1188172

I think Python just uses the Win32 system call, so there
isn't much Python can do about it.

--

Comment By: engelbert gruber (grubert)
Date: 2005-05-23 06:52

Message:
Logged In: YES 
user_id=147070

testing with perl: print -e "a<"; returns True/1 too

--

Comment By: Jarek Zgoda (zgoda)
Date: 2005-05-02 12:04

Message:
Logged In: YES 
user_id=9

Same for Python 2.3.5.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1488934 ] file.write + closed pipe = no error

[SourceForge.net]

Bugs item #1488934, was opened at 2006-05-15 16:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
>Assigned to: A.M. Kuchling (akuchling)
Summary: file.write + closed pipe = no error

Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed.  I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything. 
This is not the case, however.  I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.

Consider this example:

while True:
__print 'Hello'
__time.sleep (1)

If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours).  No exceptions are thrown.

In contrast, this example does die as soon as the ssh
connection dies (within one second):

while True:
__os.write (1, 'Hello')
__time.sleep (1)

I claim that this is because os.write does proper error
checking, but file.write seems not to.  I was surprised
to find this intricacy in fwrite().  Consider the
attached C program, test.c.  (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.)  While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0.  Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO).  So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.

I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):

2441n2 = fwrite(s, 1, n, f->f_fp);
2442Py_END_ALLOW_THREADS
2443if (n2 != n) {
2444PyErr_SetFromErrno(PyExc_IOError);
2445clearerr(f->f_fp);

I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities.  The current behavior is wrong.

Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away.  However, I could not get Python to die
by re-enabling SIGPIPE.  I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died.  Perhaps I'm not using the signal module correctly?

I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.

--

Comment By: Erik Demaine (edemaine)
Date: 2006-07-02 12:35

Message:
Logged In: YES 
user_id=265183

A simple test case is this Python script (fleshed out from
previous example), also attached:

import sys, time
while True:
__print 'Hello'
__sys.stdout.flush ()
__time.sleep (1)

Save as blah.py on machine foo, run 'ssh foo python blah.py'
on machine bar--you will see 'Hello' every second--then, in
another shell on bar, kill the ssh process on bar.  blah.py
should still be running on foo.  ('foo' and 'bar' can
actually be the same machine.)

The example from the original bug report that uses
os.write() instead of print was an example that *does* work.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 20:16

Message:
Logged In: YES 
user_id=11375

I agree with your analysis, and think your suggested fixes are correct.

However, I'm unable to construct a small test case that exercises this bug.  I 
can't even replicate the problem with SSH; when I run a remote script with 
SSH and then kill SSH with Ctrl-C, the write() gets a -1.  Are you terminating 
SSH in some other way?  (I'd really like to have a test case for this problem 
before committing the fix.)


--

Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 16:26

Message:
Logged In: YES 
user_id=265183

One more thing: fwrite() is used in a couple of other
places, and I think the same c

[ python-Feature Requests-1276768 ] dirutils.mkpath (verbose option does not work)

[SourceForge.net]

Feature Requests item #1276768, was opened at 2005-08-30 15:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1276768&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Distutils
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: gorilla_killa (gorilla_killa)
Assigned to: Nobody/Anonymous (nobody)
Summary: dirutils.mkpath (verbose option does not work)

Initial Comment:
The Verbose option does not work.

Looked at the python script for dir_utils.py and the
verbose parameter is not used in the code.

Please fix this simple bug.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:29

Message:
Logged In: YES 
user_id=33168

Can you provide a patch which behaves as you expect?  Thanks.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1276768&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1153417 ] os.remove error on Solaris

[SourceForge.net]

Bugs item #1153417, was opened at 2005-02-28 11:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Richard Philips (rphilips)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove error on Solaris

Initial Comment:
According to the documentation, when os.remove is
applied to a directory, OSError should be raised.

On Solaris, this is not the case: the directory is
removed BUT the link count on the parent directory does
NOT change.  File system corruption is the result.

Python details:
Python 2.3.4 (#3, Jun 18 2004, 10:14:55)
[GCC 3.2.2] on sunos5

Solaris details:

Number of CPUs is2
CPU Type is  sparcv9+vis2
CPU Speed is 750 MHz
App Architecture is  sparc
Kernel Architecture is   sun4u
Kernel Bit Size is   64
OS Name is   SunOS
OS Version is5.8
OS Distribution is   Solaris 8 7/01 s28s_u5wos_08 SPARC
Libc Name is libc
Libc Version is  1
Kernel Version isSunOS Release 5.8 Version
Generic_108528-20 64-bit


 

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:36

Message:
Logged In: YES 
user_id=849994

I don't think Python should do anything other than calling
the system's unlink().

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-03 22:50

Message:
Logged In: YES 
user_id=21627

This seems to be a bug report, not a patch, so I'm
reclassifying it.

Is there any chance that you tried os.remove as a superuser?
Python invokes unlink; according to the OS man page, unlink
gives EPERM when the file to remove is a directory.

I consider this a bug in the operating system: it should not
be possible, not even for the superuser, to corrupt the file
system using standard system calls. I don't know what the
rationale is for this behaviour.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1101667 ] popen3 on windows loses environment variables

[SourceForge.net]

Bugs item #1101667, was opened at 2005-01-13 14:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: June Kim (juneaftn)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen3 on windows loses environment variables

Initial Comment:
see the following test code:

#test_popen3_1.py
import os
FILENAME='c:\temp\test_popen3_2.py'
os.environ['FOOBAR']='foobar'
print os.environ['FOOBAR']
fs=os.popen3("c:\python24\python -u %s"%
FILENAME,'b')
print fs[1].read()

#c:\temp\test_popen3_2.py
print "from test_popen3_2.py"
import os;print os.environ['FOOBAR']

Running test_popen3_1.py is expected to print out:
foobar
from test_popen3_2.py
foobar

But it doesn't print the last foobar. It correctly prints 
out when run on python 2.3.

If the FILENAME is set to a relative path, as when you 
are in the c:\temp directory and the FILENAME is set to 
test_popen3_2.py, the code works correct.

Tests run on windows XP, SP1.

This bug is related to the cgi bug #1100235.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:40

Message:
Logged In: YES 
user_id=849994

This was fixed in rev. 38397.

--

Comment By: June Kim (juneaftn)
Date: 2005-01-27 07:16

Message:
Logged In: YES 
user_id=116941

Now I got it. The reason is os.py in python2.4 has changed
so that the _Environ(UserDict.IterableUserDict) has lost its
update method -- there was on in python2.3.

To rectify the problem you just copy and paste the update
method from python2.3 os.py.

--- os.py   Thu Jan 27 07:09:38 2005
+++ os_new.py   Thu Jan 27 07:10:44 2005
@@ -435,6 +435,9 @@
 return key.upper() in self.data
 def get(self, key, failobj=None):
 return self.data.get(key.upper(), failobj)
+def update(self, dict):
+for k, v in dict.items():
+self[k] = v
 def copy(self):
 return dict(self)

@@ -446,6 +449,9 @@
 def __setitem__(self, key, item):
 putenv(key, item)
 self.data[key] = item
+def update(self, dict):
+for k, v in dict.items():
+self[k] = v
 try:
 unsetenv
 except NameError:


--

Comment By: June Kim (juneaftn)
Date: 2005-01-27 07:00

Message:
Logged In: YES 
user_id=116941

Oh, stupid me. The full path filename included '\t'. It
should've been escaped. Then the example code works with 2.3
and 2.4.

The real problem seems to be with os.environ.

I have reassured this problem exists on some XP SP1 boxes.

The test code is...

#test_popen3_1.py
import os
FILENAME='test_popen3_2.py'
env={};env['ENVIRON_UPDATE']='123';os.environ.update(env)
os.environ['ENVIRON_DIRECT_SETTING']='123'
cmdline='c:\python24\python.exe -u %s'%FILENAME
fs=os.popen3(cmdline,'b')
print fs[1].read()

#test_popen3_2.py
import os
if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update
worked'
else:print 'os.env.update failed'
if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print
'os.env assignment worked'
else:print 'os.env assignment failed'

Put these two files in the same path and run
test_popen3_1.py with python2.4 and python2.3.

Following is the result I got:

C:\test>\python23\python test_popen3_1.py
os.env.update worked
os.env assignment worked


C:\test>\python24\python test_popen3_1.py
os.env.update failed
os.env assignment worked

As you see the environment varaible that's updated with
os.environ.update has failed to get passed to popen3ed process.

This is the reason CGIHTTPServer.py fails to deliver
QUERY_STRING and etc. -- they are updated with
os.environ.update(env).


--

Comment By: AGunn (ompeag)
Date: 2005-01-26 21:21

Message:
Logged In: YES 
user_id=1155133

I've tried recreating this problem and have had no luck.  I've 
tried three versions of python:  2.3, 2.4, and the current 
build version (2.5 something?).  I've also tried both absolute 
and relative paths.  All tests print out the second 'foobar' just 
fine.  I, too, am running XP, SP1.  

Any chance there's something special about how you are 
running the executables?  Say from a cygwin environment or 
something?

--

Comment By: June Kim (juneaftn)
Date: 2005-01-13 14:36

Message:
Logged In: YES 
user_id=116941

Sorry. I got confus

[ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup

[SourceForge.net]

Bugs item #1476845, was opened at 2006-04-26 21:57
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Finish PEP 343 terminology cleanup

Initial Comment:
test_with.py was missed in the PEP 343 terminology
cleanup for Python alpha 2

PEP 343 itself still needs to be updated, too.

Creating this tracker item to record items needed to
finish the terminology cleanup post-alpha 2.

--

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-07-30 21:53

Message:
Logged In: YES 
user_id=1038590

This all got dealt with when __context__() was removed. I
believe I left the bug report open with the intent of
closing it once we were happy that what went in to the first
beta was what we wanted to stick with for 2.5.

I'd say we've reached that point :)

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:13

Message:
Logged In: YES 
user_id=11375

Nick, does anything still need to be done for this?  What
terminology needs to be fixed in test_with.py?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1525866 ] Bug in shutil.copytree on Windows

[SourceForge.net]

Bugs item #1525866, was opened at 2006-07-20 15:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===
--- shutil.py   (Revision 50710)
+++ shutil.py   (Arbeitskopie)
@@ -127,7 +127,12 @@
 # continue with other files
 except Error, err:
 errors.extend(err.args[0])
-copystat(src, dst)
+try:
+copystat(src, dst)
+except WindowsError:
+pass
+except OSError, err:
+errors.extend(err.args[0])
 if errors:
 raise Error, errors

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-30 15:01

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as r50977.

--

Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 16:14

Message:
Logged In: YES 
user_id=1123892

Nope - not quite right. Will fix tonight and upload a proper
patch.

Michael

--

Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 16:09

Message:
Logged In: YES 
user_id=1123892

The following should work as a test method for shutil.copytree

(Passes on my box against a patched version of shutil)

def test_copytree_simple(self):
src_dir = tempfile.mkdtemp()
dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
os.mkdir(os.path.join(src_dir, 'test_dir'))
open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
#
def testStat(src, dst):
st_src = os.stat(src)
st_dst = os.stat(dst)
if hasattr(os, 'utime'):
self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
if hasattr(os, 'chmod'):
# Should be equal anyway, should we change
permissions on one of the source files ?
   
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
#
try:
shutil.copytree(src_dir, dst_dir)
   
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
   
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
   
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
   
finally:
try:
os.remove(os.path.join(src_dir, 'test.txt'))
os.remove(os.path.join(dst_dir, 'test.txt'))
os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
os.removedirs(src_dir)
os.removedirs(dst_dir)
except:
pass

Can turn the above into a patch tonight if needed.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-20 18:14

Message:
Logged In: YES 
user_id=21627

Can you also come up with a patch to the test suite?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1257728 ] error message incorrectly claims Visual C++ is required

[SourceForge.net]

Bugs item #1257728, was opened at 2005-08-12 17:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error message incorrectly claims Visual C++ is required

Initial Comment:
Thank you for the excellent distutils tool!

Two problems:

First, this error message is emitted on win32, but it
appears to be incorrect, inasmuch as the Microsoft
compiler is not actually required:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same
version of the compiler, but it isn't installed.
Error: Subprocess exited with result 1 for project core
"""

Second, the usage of distutils is somewhat confusing,
as the following line emits that error message:

./setup.py build -c mingw32; ./setup.py install

but the following line, which I intuitively believed to
be equivalent at first, works to compile and install
the package:

./setup.py build -c mingw32 install

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-30 15:31

Message:
Logged In: YES 
user_id=21627

Thanks for the suggestion; I committed something similar as
r50979 and r50980.

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-25 23:10

Message:
Logged In: YES 
user_id=52562

How about:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with a compiler that
can generate compatible binaries.  Some versions of gcc can
produce compatible binaries if given the "-mno-cygwin" flag.
 Distutils will pass the "-mno-cygwin" flag to gcc if
distutils is given the "-c mingw32" flag to the "build" command.

Error: Subprocess exited with result 1 for project core
"""

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-24 15:00

Message:
Logged In: YES 
user_id=21627

What would you like to say the error message instead?

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-31 13:35

Message:
Logged In: YES 
user_id=52562

Changing this from category Distutils to category Windows.

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-11-23 19:51

Message:
Logged In: YES 
user_id=52562

Whoo!  Progress!  Now it no longer spuriously claims that
Visual C++ is required for building extensions for Python,
and instead it spuriously claims that the .NET SDK is
required for building extensions for Python!

"""
error: The .NET Framework SDK needs to be installed before
building extensions for Python.
"""

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)

[SourceForge.net]

Bugs item #1439538, was opened at 2006-02-27 11:51
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Håvard Tveite (havatv)
Assigned to: Martin v. Löwis (loewis)
Summary: test -e is not portable (Solaris 2.7)

Initial Comment:
I was adviced by Barry Warsaw to file a bug on this.

I tried to install Python 2.4.2 (and 2.3.5) on Solaris
2.7, but configure failed.
The Solaris 2.7 sh does not support "test -e".
"test -e" is used two times in configure.

The use of "test -e" is not recommended for "Portable
Shell Programming":
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html
>

I replaced "test -e" with "test -r", and it seems to work
(configure finishes OK, and the files are found), but
I do not know if this is the correct way to do it.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-30 16:12

Message:
Logged In: YES 
user_id=21627

test -r seems to be the portable way, although it tests for
a slightly different property (read access, instead of mere
file presence).

For autoconf, the best way is to use AC_CHECK_FILE, which
then expands to test -r. Fixed in r50982 and r50983.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:49

Message:
Logged In: YES 
user_id=849994

Martin, is the replacement correct?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531349 ] Reflected (swapped) operations overridden by subclasses

[SourceForge.net]

Bugs item #1531349, was opened at 2006-07-31 02:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrei Polushin (polushin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reflected (swapped) operations overridden by subclasses

Initial Comment:
In Python 2.5b2 Documentation:
   Python Reference Manual
   Section 3.4.7 Emulating numeric types
   

Note to description of __radd__, __rsub__, etc.
specifies that "this method will be called before the
right operand's non-reflected method."

Should replace RIGHT with LEFT here. The correct phrase
is "this method will be called before the LEFT
operand's non-reflected method."

For example, reader should clearly understand that
"RIGHT.__radd__ will be called before the LEFT.__add__"
in case when type(RIGHT) is subclass of type(LEFT).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531349 ] Reflected (swapped) operations overridden by subclasses

[SourceForge.net]

Bugs item #1531349, was opened at 2006-07-30 19:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrei Polushin (polushin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reflected (swapped) operations overridden by subclasses

Initial Comment:
In Python 2.5b2 Documentation:
   Python Reference Manual
   Section 3.4.7 Emulating numeric types
   

Note to description of __radd__, __rsub__, etc.
specifies that "this method will be called before the
right operand's non-reflected method."

Should replace RIGHT with LEFT here. The correct phrase
is "this method will be called before the LEFT
operand's non-reflected method."

For example, reader should clearly understand that
"RIGHT.__radd__ will be called before the LEFT.__add__"
in case when type(RIGHT) is subclass of type(LEFT).

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 20:23

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 50990, 50991 (2.4). Thanks!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531405 ] format_exception raises if str(exception) raises

[SourceForge.net]

Bugs item #1531405, was opened at 2006-07-30 17:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: format_exception raises if str(exception) raises

Initial Comment:
Previously format_exception_only used _some_str() to
find the string representation of an exception.  In
current [EMAIL PROTECTED] that code has been factored into
_format_final_exc_line and changed in two ways: it now
calls str(exception) twice instead of once and in one
of those cases, it calls str() directly rather than
through _some_str, which does exception handling.

The end result of this is that application-level code
which uses the traceback module to format exceptions
which previously could not raise exceptions now can
raise exceptions.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531405 ] format_exception raises if str(exception) raises

[SourceForge.net]

Bugs item #1531405, was opened at 2006-07-30 17:06
Message generated for change (Settings changed) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: format_exception raises if str(exception) raises

Initial Comment:
Previously format_exception_only used _some_str() to
find the string representation of an exception.  In
current [EMAIL PROTECTED] that code has been factored into
_format_final_exc_line and changed in two ways: it now
calls str(exception) twice instead of once and in one
of those cases, it calls str() directly rather than
through _some_str, which does exception handling.

The end result of this is that application-level code
which uses the traceback module to format exceptions
which previously could not raise exceptions now can
raise exceptions.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr

[SourceForge.net]

Bugs item #1531415, was opened at 2006-07-30 17:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: parsetok.c emits warnings by writing to stderr

Initial Comment:
Warnings should be emitted with the warning system, via
PyErr_Warn.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells

[SourceForge.net]

Bugs item #1465014, was opened at 2006-04-06 01:14
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


--

>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 12:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

--

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 06:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 13:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

--

Comment By: David Goodger (goodger)
Date: 2006-06-23 13:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 10:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

--

Comment By: David Goodger (goodger)
Date: 2006-06-23 04:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

--

C

[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells

[SourceForge.net]

Bugs item #1465014, was opened at 2006-04-05 10:14
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


--

>Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 22:13

Message:
Logged In: YES 
user_id=44345

I'll see your 50993 and raise you a 50998.  Just minor tweaks.  Hopefully we 
can 
close this puppy, though a small example to make the idea concrete might be 
worthwhile.


--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-30 21:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

--

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 15:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 12:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 22:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

--

Comment By: David Goodger (goodger)
Date: 2006-06-22 22:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 19:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

--

Comment By: David Goodger (goodger)
Date: 2006-06-22 13:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string 

[ python-Bugs-1163367 ] correct/clarify documentation for super

[SourceForge.net]

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

>Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 21:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 14:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 10:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1531505 ] distutils 'register' command and windows home directories

[SourceForge.net]

Feature Requests item #1531505, was opened at 2006-07-30 20:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1531505&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils 'register' command and windows home directories

Initial Comment:
The current version of the Distutils 'register' command
does not support Windows 2k or XP home directories, as
it checks for 'HOME' in os.environ .  This is suffient
for posix platforms, but for Windows 2k and XP,
generally 'home directories' are specified via the
environment variable 'USERPROFILE', or can be
constructed from 'HOMEDRIVE' and 'HOMEPATH'.

A simple fix would be to create two functions:
has_home() and get_home(), whose purposes are to
determine whether a home directory exists for the
current platform, and to get the home directory for the
current platform, respectively.

A sample implementation of both functions is as follows
(replace the leading commas with spaces).

keys = ['HOME', 'USERPROFILE']

def has_home():
for i in keys:
if i in os.environ:
return 1
return 0

def get_home():
for i in keys:
if i in os.environ:
return os.environ[i]


Once those definitions are made, then the two relevant
portions of
distutils.command.register.register.set_metadata() can
be updated to use these two functions.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1531505&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1163367 ] correct/clarify documentation for super

[SourceForge.net]

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 23:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

--

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells

[SourceForge.net]

Bugs item #1465014, was opened at 2006-04-06 01:14
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


--

>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 14:14

Message:
Logged In: YES 
user_id=698599

Yep, your changes are reasonable. I considered adding an 
example, but couldn't think of anything that illustrated 
the point without confusing the reader further.

--

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-31 13:13

Message:
Logged In: YES 
user_id=44345

I'll see your 50993 and raise you a 50998.  Just minor tweaks.  Hopefully we 
can 
close this puppy, though a small example to make the idea concrete might be 
worthwhile.


--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 12:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

--

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 06:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 13:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

--

Comment By: David Goodger (goodger)
Date: 2006-06-23 13:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

--

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 10:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

--

Comment By: David Goodger (goodger)
Date: 2006-06-23 04:17

Me

[ python-Bugs-1163367 ] correct/clarify documentation for super

[SourceForge.net]

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 00:29

Message:
Logged In: YES 
user_id=3066

Ok, after playing around a bit with the 1-arg variation and
the 2nd-arg-is-a-type variation, I don't have a clue as to
how either would be used.

It someone can explain either of both of those, please post
an explanation here, and I'll do any LaTeX conversions needed.

I've attached what I have so far as a patch.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 23:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

--

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailm

[ python-Bugs-1163367 ] correct/clarify documentation for super

[SourceForge.net]

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

>Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:02

Message:
Logged In: YES 
user_id=945502

The two-arg type form is intended for use with classmethods,
e.g.::

>>> class C(object):
... @classmethod
... def f(cls):
... print 'C.f'
... 
>>> class D(C):
... @classmethod
... def f(cls):
... super(D, cls).f()
... print 'D.f'
... 
>>> D.f()
C.f
D.f

I do make use of this occasionally, so I do think it should
be documented.

The one-arg form is intended to be used as a class attribute::

>>> class C(object):
... def f(self):
... print 'C.f'
... 
>>> class D(C):
...  def f(self):
...  self.super.f()
...  print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
C.f
D.f

I don't know that we should really be advertising this
one-arg form though.  It requires modifying a class outside
the definition or using some metaclass hackery to be usable.
 And it's misleading because it won't work, for example,
with classmethods:

>>> class C(object):
... @classmethod
... def f(cls):
... print 'C.f'
... 
>>> class D(C):
... @classmethod
... def f(cls):
... cls.super.f()
... print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 4, in f
AttributeError: 'super' object has no attribute 'f'

That's why I tried to gloss over it lightly.  Personally I'd
prefer that the one-arg form was just deprecated.  It
introduces a lot more problems than it solves.

But if it has to be documented, it should probably say
something like "A super object created with a single
argument produces a descriptor object. This descriptor
object makes the superclass methods available on the object
returned by its __get__ method. The superclass methods are
only available when __get__ is called with an instance (not
a class)."


--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 22:29

Message:
Logged In: YES 
user_id=3066

Ok, after playing around a bit with the 1-arg variation and
the 2nd-arg-is-a-type variation, I don't have a clue as to
how either would be used.

It someone can explain either of both of those, please post
an explanation here, and I'll do any LaTeX conversions needed.

I've attached what I have so far as a patch.

--