[ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Bugs item #494589, was opened at 2001-12-18 15:29
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&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
Private: No
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars deletes things on w32
Initial Comment:
Try this:
import os.path
print os.path.expandvars('foo$doesnotexist')
On FreeBSD, Python 2.1, I get:
'foo$doesnotexist'
But on WIN32, Python 2.1, I get:
'foo'
The docs explicitly states that variables that are not
found will be left in place ... but on win32 that
appears to not be the case.
--
>Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 12:42
Message:
Logged In: YES
user_id=43607
Originator: NO
I got bit by this today and saw there was a bug report of over 6 years
old.
The patch is trivial, though.
The attached patch may not solve the problem that the various
implementations of expandvars are made exactly the same again, but it does
solve the problem that this implementation doesn't do what it promises in
the doc string. It also solves the problem noted by Tim of two
consecutive non-existing variables being treated differently.
File Added: ntpath.patch
--
Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 15:45
Message:
Logged In: YES
user_id=806514
tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()
There are two problems here.
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.
About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.
Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality
To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.
To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.
So my view point-> same interface, same documentation
For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.
#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
"""Expand paths containing shell variable
substitutions.
The following rules apply:
- no expansion within single quotes
- no escape character, except for '$$' which is
translated into '$'
- ${varname} is accepted.
- varnames can be made out of letters, digits and
the character '_'"""
global _varprog, _findquotes
if '$' not in path:
return path
if not _varprog:
import re
_varprog = re.compile(r'\$(\w+|\{[^}]*\}|\$)')
_findquotes = re.compile("'.*?'")
quoteareas = []
i = 0
while 1:
quotearea = _findquotes.search(path, i)
if not quotearea:
break
(i, j) = quotearea.span(0)
quoteareas.append((i, j))
i = j
i = 0
while 1:
m = _varprog.search(path, i)
if not m:
break
i, j = m.span(0)
insidequotes=None
for (quotebegin, quoteend) in quoteareas:
if quotebegin < i and
[ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Bugs item #494589, was opened at 2001-12-18 09:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&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: Accepted
Priority: 5
Private: No
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars deletes things on w32
Initial Comment:
Try this:
import os.path
print os.path.expandvars('foo$doesnotexist')
On FreeBSD, Python 2.1, I get:
'foo$doesnotexist'
But on WIN32, Python 2.1, I get:
'foo'
The docs explicitly states that variables that are not
found will be left in place ... but on win32 that
appears to not be the case.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 10:50
Message:
Logged In: YES
user_id=6380
Originator: NO
Looks good. Sjoerd, can you check that in yourself or did you give up your
privileges?
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 06:42
Message:
Logged In: YES
user_id=43607
Originator: NO
I got bit by this today and saw there was a bug report of over 6 years
old.
The patch is trivial, though.
The attached patch may not solve the problem that the various
implementations of expandvars are made exactly the same again, but it does
solve the problem that this implementation doesn't do what it promises in
the doc string. It also solves the problem noted by Tim of two consecutive
non-existing variables being treated differently.
File Added: ntpath.patch
--
Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 09:45
Message:
Logged In: YES
user_id=806514
tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()
There are two problems here.
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.
About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.
Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality
To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.
To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.
So my view point-> same interface, same documentation
For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.
#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
"""Expand paths containing shell variable
substitutions.
The following rules apply:
- no expansion within single quotes
- no escape character, except for '$$' which is
translated into '$'
- ${varname} is accepted.
- varnames can be made out of letters, digits and
the character '_'"""
global _varprog, _findquotes
if '$' not in path:
return path
if not _varprog:
import re
_varprog = re.compile(r'\$(\w+|\{[^}]*\}|\$)')
_findquotes = re.compile("'.*?'")
quoteareas = []
i = 0
while 1:
quotearea = _findquotes.search(path, i)
if not quotearea:
break
(i, j) = quotear
[ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Bugs item #494589, was opened at 2001-12-18 09:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&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: Accepted
Priority: 5
Private: No
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars deletes things on w32
Initial Comment:
Try this:
import os.path
print os.path.expandvars('foo$doesnotexist')
On FreeBSD, Python 2.1, I get:
'foo$doesnotexist'
But on WIN32, Python 2.1, I get:
'foo'
The docs explicitly states that variables that are not
found will be left in place ... but on win32 that
appears to not be the case.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 10:52
Message:
Logged In: YES
user_id=6380
Originator: NO
Oh, I forgot. It needs a unit test (preferably one that tests each xxpath
module on each platform).
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 10:50
Message:
Logged In: YES
user_id=6380
Originator: NO
Looks good. Sjoerd, can you check that in yourself or did you give up your
privileges?
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 06:42
Message:
Logged In: YES
user_id=43607
Originator: NO
I got bit by this today and saw there was a bug report of over 6 years
old.
The patch is trivial, though.
The attached patch may not solve the problem that the various
implementations of expandvars are made exactly the same again, but it does
solve the problem that this implementation doesn't do what it promises in
the doc string. It also solves the problem noted by Tim of two consecutive
non-existing variables being treated differently.
File Added: ntpath.patch
--
Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 09:45
Message:
Logged In: YES
user_id=806514
tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()
There are two problems here.
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.
About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.
Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality
To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.
To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.
So my view point-> same interface, same documentation
For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.
#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
"""Expand paths containing shell variable
substitutions.
The following rules apply:
- no expansion within single quotes
- no escape character, except for '$$' which is
translated into '$'
- ${varname} is accepted.
- varnames can be made out of letters, digits and
the character '_'"""
global _varprog, _findquotes
if '$' not in path:
return path
[ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Bugs item #494589, was opened at 2001-12-18 15:29
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&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: Accepted
Priority: 5
Private: No
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars deletes things on w32
Initial Comment:
Try this:
import os.path
print os.path.expandvars('foo$doesnotexist')
On FreeBSD, Python 2.1, I get:
'foo$doesnotexist'
But on WIN32, Python 2.1, I get:
'foo'
The docs explicitly states that variables that are not
found will be left in place ... but on win32 that
appears to not be the case.
--
>Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 17:03
Message:
Logged In: YES
user_id=43607
Originator: NO
I can check this in. I'll try to create some tests.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 16:52
Message:
Logged In: YES
user_id=6380
Originator: NO
Oh, I forgot. It needs a unit test (preferably one that tests each xxpath
module on each platform).
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 16:50
Message:
Logged In: YES
user_id=6380
Originator: NO
Looks good. Sjoerd, can you check that in yourself or did you give up your
privileges?
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 12:42
Message:
Logged In: YES
user_id=43607
Originator: NO
I got bit by this today and saw there was a bug report of over 6 years
old.
The patch is trivial, though.
The attached patch may not solve the problem that the various
implementations of expandvars are made exactly the same again, but it does
solve the problem that this implementation doesn't do what it promises in
the doc string. It also solves the problem noted by Tim of two consecutive
non-existing variables being treated differently.
File Added: ntpath.patch
--
Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 15:45
Message:
Logged In: YES
user_id=806514
tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()
There are two problems here.
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.
About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.
Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality
To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.
To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.
So my view point-> same interface, same documentation
For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.
#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
"""Expand paths containing shell variable
substitutions.
The following rules apply:
- no expansion within single quotes
- no escape character,
[ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Bugs item #494589, was opened at 2001-12-18 15:29
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael McCandless (mikemccand)
>Assigned to: Sjoerd Mullender (sjoerd)
Summary: os.path.expandvars deletes things on w32
Initial Comment:
Try this:
import os.path
print os.path.expandvars('foo$doesnotexist')
On FreeBSD, Python 2.1, I get:
'foo$doesnotexist'
But on WIN32, Python 2.1, I get:
'foo'
The docs explicitly states that variables that are not
found will be left in place ... but on win32 that
appears to not be the case.
--
>Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 17:44
Message:
Logged In: YES
user_id=43607
Originator: NO
Committed as rev. 53460.
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 17:03
Message:
Logged In: YES
user_id=43607
Originator: NO
I can check this in. I'll try to create some tests.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 16:52
Message:
Logged In: YES
user_id=6380
Originator: NO
Oh, I forgot. It needs a unit test (preferably one that tests each xxpath
module on each platform).
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-16 16:50
Message:
Logged In: YES
user_id=6380
Originator: NO
Looks good. Sjoerd, can you check that in yourself or did you give up your
privileges?
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-01-16 12:42
Message:
Logged In: YES
user_id=43607
Originator: NO
I got bit by this today and saw there was a bug report of over 6 years
old.
The patch is trivial, though.
The attached patch may not solve the problem that the various
implementations of expandvars are made exactly the same again, but it does
solve the problem that this implementation doesn't do what it promises in
the doc string. It also solves the problem noted by Tim of two
consecutive non-existing variables being treated differently.
File Added: ntpath.patch
--
Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 15:45
Message:
Logged In: YES
user_id=806514
tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()
There are two problems here.
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.
About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.
Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality
To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.
To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.
So my view point-> same interface, same documentation
For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.
#expandvars() implementation
_varpr
[ python-Bugs-1636950 ] Newline skipped in "for line in file"
Bugs item #1636950, was opened at 2007-01-16 10:56 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=1636950&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 Private: No Submitted By: Andy Monthei (amonthei) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: When processing huge fixed block files of about 7000 bytes wide and several hundred thousand lines long some pairs of lines get read as one long line with no line break when using "for line in file:". The problem is even worse when using the fileinput module and reading in five or six huge files consisting of 4.8 million records causes several hundred pairs of lines to be read as single lines. When a newline is skipped it is usually followed by several more in the next few hundred lines. I have not noticed any other characters being skipped, only the line break. O.S. Windows (5, 1, 2600, 2, 'Service Pack 2') Python 2.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633630 ] class derived from float evaporates under +=
Bugs item #1633630, was opened at 2007-01-11 15:49 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&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: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: class derived from float evaporates under += Initial Comment: [forwarded from http://bugs.debian.org/345373] There seems to be a bug in classes derived from float. For instance, consider the following: >>> class Float(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... >>> a = Float(2.0) >>> b = Float(3.0) >>> type(a) >>> type(b) >>> a += b >>> type(a) Now, the type of a has silently changed. It was a Float, a derived class with all kinds of properties, and it became a float -- a plain vanilla number. My understanding is that this is incorrect, and certainly unexpected. If it *is* correct, it certainly deserves mention somewhere in the documentation. It seems that Float.__iadd__(a, b) should be called. This defaults to float.__iadd__(a, b), which should increment the float part of the object while leaving the rest intact. A possible explanation for this problem is that float.__iadd__ is not actually defined, and so it falls through to a = float.__add__(a, b), which assigns a float to a. This interpretation seems to be correct, as one can add a destructor to the Float class: >>> class FloatD(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... def __del__(self): ... print 'Deleting FloatD class, losing x=', self.x ... >>> a = FloatD(2.0) >>> b = FloatD(3.0) >>> a += b Deleting FloatD class, losing x= 1 >>> -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-16 09:40 Message: Logged In: YES user_id=341410 Originator: NO The current behavior is as designed. Not a bug. Suggested move to RFE or close as "Not a bug". There has been discussion on either the python-dev or python-3000 mailing lists discussing how subclasses of builtin types (int, long, float, str, unicode, list, tuple, ...) should behave when confronted with one of a set of "standard" operators. While there has been general "it would be nice" if 'a + b' produced 'type(a)(a + b)' on certain occasions, this would change the semantics of all such operations in a backwards incompatible way (so has not been implemented). If you want to guarantee such behavior (without writing all of the __special__ methods) I would suggest that you instead create a __getattr__ method to automatically handle the coercion back into your subtype. -- Comment By: Georg Brandl (gbrandl) Date: 2007-01-13 09:57 Message: Logged In: YES user_id=849994 Originator: NO You don't need augmented assign for that, just doing "a+b" will give you a float too. -- Comment By: Jim Jewett (jimjjewett) Date: 2007-01-12 13:26 Message: Logged In: YES user_id=764593 Originator: NO Python float objects are immutable and can be shared. Therefore, their values cannot be modified -- which is why it falls back to not-in-place assignment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637022 ] Python-2.5 segfault with tktreectrl
Bugs item #1637022, was opened at 2007-01-16 19:46 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=1637022&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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: klappnase (klappnase) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5 segfault with tktreectrl Initial Comment: Python-2.5 segfaults when using the tktreectrl widget. As Anton Hartl pointed out (see http://groups.google.com/group/comp.lang.python/browse_thread/thread/37536988c8499708/aed1d725d8e84ed8?lnk=raot#aed1d725d8e84ed8) this is because both Python-2.5 and tktreectrl use a global symbol "Ellipsis". Changing "Ellipsis" in ast.c and Python-ast.c into something like "PyAst_Ellipsis" fixes this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1603688 ] SaveConfigParser.write() doesn't quote %-Sign
Bugs item #1603688, was opened at 2006-11-27 12:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603688&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: Duplicate
Priority: 5
Private: No
Submitted By: Rebecca Breu (rbreu)
Assigned to: Nobody/Anonymous (nobody)
Summary: SaveConfigParser.write() doesn't quote %-Sign
Initial Comment:
>>> parser = ConfigParser.SafeConfigParser()
>>> parser.add_section("test")
>>> parser.set("test", "foo", "bar%bar")
>>> parser.write(open("test.config", "w"))
>>> parser2 = ConfigParser.SafeConfigParser()
>>> parser2.readfp(open("test.config"))
>>> parser.get("test", "foo")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/ConfigParser.py", line 525, in get
return self._interpolate(section, option, value, d)
File "/usr/lib/python2.4/ConfigParser.py", line 593, in _interpolate
self._interpolate_some(option, L, rawval, section, vars, 1)
File "/usr/lib/python2.4/ConfigParser.py", line 634, in _interpolate_some
"'%%' must be followed by '%%' or '(', found: %r" % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or '(',
found: '%bar'
Problem: SaveConfigParser saves the string "bar%bar" as is and not as
"bar%%bar".
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-01-16 20:50
Message:
Logged In: YES
user_id=849994
Originator: NO
Closing this as a duplicate.
--
Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-15 07:45
Message:
Logged In: YES
user_id=1591633
Originator: NO
Initially, I believed ValueError was the appropriate way to go with this.
However, when I thought about how I use ConfigParser, I realized that it
would be far nicer if it simply worked.
See the patches in 1635639.
http://sourceforge.net/tracker/index.php?func=detail&aid=1635639&group_id=5470&atid=105470
Good catch on this. I haven't caught it and I've been using ConfigParser
for a while now.
--
Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-15 02:33
Message:
Logged In: YES
user_id=1591633
Originator: NO
I'm not sure that automagically changing their input is such a great idea.
I'm -0 for automagically changing their input, but +1 for raising
ValueError when the input contains a string that can't be properly
interpolated. I've implemented the patch both ways. Anyone else have an
opinion about this?
Examples of such malformatted strings include bar%bar and bar%.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603688&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637120 ] Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Bugs item #1637120, was opened at 2007-01-16 18: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=1637120&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orlando Irrazabal (oirraza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Initial Comment:
Initial Comment:
Build of Python 2.5 on AIX 5.3 with xlc_r fails with the below error message.
The configure line is:
./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6
AR="ar -X64"
[...]
building '_ctypes' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include
-Ibuild/temp.aix-5.3-2.5/libffi/include -Ibuild/temp.aix-5.3-2.5/libffi
-I/sw_install/python-2.5/Modules/_ctypes/libffi/src -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes.c -o
build/temp.aix-5.3-2.5/sw_install/python-2.5/Modules/_ctypes/_ctypes.o
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.3: 1506-166 (S)
Definition of function ffi_closure requires parentheses.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.15: 1506-276 (S) Syntax
error: possible missing '{'?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 248.3: 1506-273 (E) Missing
type in declaration of ffi_raw_closure.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.38: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 252.23: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-033 (S)
Function ffi_prep_raw_closure is not valid. Function cannot return a function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.23: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.38: 1506-275 (S)
Unexpected text ')' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.43: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 258.28: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-033 (S)
Function ffi_prep_java_raw_closure is not valid. Function cannot return a
function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.28: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.43: 1506-275 (S)
Unexpected text ')' encountered.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 71.9: 1506-046 (S)
Syntax error.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 77.26: 1506-195 (S)
Integral constant expression with a value greater than zero is required.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 2804.31: 1506-068 (E)
Operation between types "void*" and "int(*)(void)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3357.28: 1506-280 (E)
Function argument assignment between types "int(*)(void)" and "void*" is not
allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3417.42: 1506-022 (S)
"pcl" is not a member of "struct {...}".
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4749.67: 1506-280 (E)
Function argument assignment between types "void*" and "void*(*)(void*,const
void*,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4750.66: 1506-280 (E)
Function argument assignment between types "void*" and
"void*(*)(void*,int,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4751.69: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const char*,long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4752.64: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4754.70: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const unsigned int*,int)" is not allowed.
building '_ctypes_test' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes_test.
[ python-Bugs-1637167 ] mailbox.py uses old email names
Bugs item #1637167, was opened at 2007-01-16 14:19 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=1637167&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 Private: No Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.py uses old email names Initial Comment: mailbox.py uses old (and presumably deprecated) names for stuff in the email package. This can confuse application packagers such as py2app. I believe the complete list of desirable changes is: email.Generator -> email.generator email.Message -> email.message email.message_from_string -> email.parser.message_from_string email.message_from_file -> email.parser.message_from_file I submitted patches for urllib, urllib2 and smptlib but wasn't sure enough of mailbox to do that. Those four modules are the only instances I found that needed changing at the main level of the library. However, I did not do a recursive search. There may be files inside packages that could also use cleanup. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1636950 ] Newline skipped in "for line in file"
Bugs item #1636950, was opened at 2007-01-16 08:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&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 Private: No Submitted By: Andy Monthei (amonthei) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: When processing huge fixed block files of about 7000 bytes wide and several hundred thousand lines long some pairs of lines get read as one long line with no line break when using "for line in file:". The problem is even worse when using the fileinput module and reading in five or six huge files consisting of 4.8 million records causes several hundred pairs of lines to be read as single lines. When a newline is skipped it is usually followed by several more in the next few hundred lines. I have not noticed any other characters being skipped, only the line break. O.S. Windows (5, 1, 2600, 2, 'Service Pack 2') Python 2.5 -- >Comment By: Brett Cannon (bcannon) Date: 2007-01-16 14:33 Message: Logged In: YES user_id=357491 Originator: NO Do you happen to have a sample you could upload that triggers the bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1037516 ] ftplib PASV error bug
Bugs item #1037516, was opened at 2004-09-30 05:35 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037516&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: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Nelson (wayland) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib PASV error bug Initial Comment: Hi. If ftplib gets an error while doing the PASV section of the ntransfercmd it dies. I've altered it so that ntransfercmd does an autodetect, if an autodetect hasn't been done yet. If there are any problems (as I'm not a python programmer :) ), please either fix them or let me know. -- Comment By: Tim Nelson (wayland) Date: 2007-01-16 00:02 Message: Logged In: YES user_id=401793 Originator: YES Oops. I probably did, but I don't work in that job any more, so I'm afraid I don't have access to it. Sorry. You should, however, be able to correct it from the description. -- Comment By: Andrew Bennetts (spiv) Date: 2004-10-06 10:49 Message: Logged In: YES user_id=50945 Did you mean to submit a patch with this bug report? It sounds like you did, but there's no files attached to this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037516&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-1637365 ] if __name__=='__main__' missing in tutorial
Feature Requests item #1637365, was opened at 2007-01-17 02:11
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=1637365&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: if __name__=='__main__' missing in tutorial
Initial Comment:
I could not find any reference to the big idiom:
if __name__=="__main__":
xxx()
inside the Python tutorial. Of course it is documented in the Library Reference
and the Reference Manual, but such an important idiom should be on the Tutorial
for beginners to see.
I can't provide a patch, and English is not my native language, but I think a
short text like the following would suffice (in section More on Modules, before
the paragraph "Modules can import other modules..."):
Sometimes it is convenient to invoke a module as it were a script, either for
testing purposes, or to provide a convenient user interfase to the functions
contained in the module. But you don't want to run such code when the module is
imported into another program, only when it's used as a standalone script. The
way of differentiate both cases is checking the \code{__name__} attribute: as
seen on the previous section, it usually holds the module name, but when the
module is invoked directly, it's always \samp{__main__} regardless of the
script name.
Add this at the end of \file{fibo.py}:
\begin{verbatim}
if __name__=="__main__":
import sys
fib(int(sys.argv[1]))
\end{verbatim}
and then you can execute it using:
\begin{verbatim}
python fibo.py 50
1 1 2 3 5 8 13 21 34
\end{verbatim}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 07:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed
Priority: 9
Private: No
Submitted By: Richard Boulton (richardb)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python polls unnecessarily every 0.1 second when interactive
Initial Comment:
When python is running an interactive session, and is
idle, it calls "select" with a timeout of 0.1 seconds
repeatedly. This is intended to allow PyOS_InputHook()
to be called every 0.1 seconds, but happens even if
PyOS_InputHook() isn't being used (ie, is NULL).
To reproduce:
- start a python session
- attach to it using strace -p PID
- observe that python repeatedly
This isn't a significant problem, since it only affects
idle interactive python sessions and uses only a tiny
bit of CPU, but people are whinging about it (though
some appear to be doing so tongue-in-cheek) and it
would be nice to fix it.
The attached patch (against Python-2.5c1) modifies the
readline.c module so that the polling doesn't happen
unless PyOS_InputHook is not NULL.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-16 22:47
Message:
Logged In: YES
user_id=33168
Originator: NO
I'm fine if this patch is applied. Since it was applied to trunk, it
seems like it might as well go into 2.5.1 as well. I agree it's not that
high priority, but don't see much reason to wait either. OTOH, I won't
lose sleep if it's not applied, so do what you think is best.
--
Comment By: Richard Boulton (richardb)
Date: 2006-09-08 07:30
Message:
Logged In: YES
user_id=9565
I'm finding the function because it's defined in the
compiled library - the header files aren't examined by
configure when testing for this function. (this is because
configure.in uses AC_CHECK_LIB to check for
rl_callback_handler_install, which just tries to link the
named function against the library). Presumably, rlconf.h
is the configuration used when the readline library was
compiled, so if READLINE_CALLBACKS is defined in it, I would
expect the relevant functions to be present in the compiled
library.
In any case, this isn't desperately important, since you've
managed to hack around the test anyway.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-08 06:12
Message:
Logged In: YES
user_id=11375
That's exactly my setup. I don't think there is a -dev
package for readline 4.
I do note that READLINE_CALLBACKS is defined in
/usr/include/readline/rlconf.h, but Python's readline.c
doesn't include this file, and none of the readline headers
include it. So I don't know why you're finding the function!
--
Comment By: Richard Boulton (richardb)
Date: 2006-09-08 02:34
Message:
Logged In: YES
user_id=9565
HAVE_READLINE_CALLBACK is defined by configure.in whenever
the readline library on the platform supports the
rl_callback_handler_install() function. I'm using Ubuntu
Dapper, and have libreadline 4 and 5 installed (more
precisely, 4.3-18 and 5.1-7build1), but only the -dev
package for 5.1-7build1. "info readline" describes
rl_callback_handler_install(), and configure.in finds it, so
I'm surprised it wasn't found on akuchling's machine.
I agree that the code looks buggy on platforms in which
signals don't necessarily get delivered to the main thread,
but looks no more buggy with the patch than without.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 07:38
Message:
Logged In: YES
user_id=11375
On looking at the readline code, I think this patch makes no
difference to signals.
The code in readline.c for the callbacks looks like this:
has_input = 0;
while (!has_input) {
...
has_input = select.select(rl_input);
}
if (has_input > 0) {read character}
elif (errno == EINTR) {check signals}
So I think that, if a signal is delivered to a thread and
select() in the main thread doesn't return EINTR, the old
code is just as problematic as the code with this patch.
The (while !has_input) loop doesn't check for signals at all
as an exit condition.
I'm not sure what to do at this point. I think the new code
is no worse than the old code with regard to signals. Maybe
this loop is buggy w.r.t. to signals, but I don't know how
to test that.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 0
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 08:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-16 22:48 Message: Logged In: YES user_id=33168 Originator: NO Andrew, do you need any help with this? -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-15 11:01 Message: Logged In: YES user_id=11375 Originator: NO Comment from Andrew MacIntyre (os2vacpp is the OS/2 that lacks ftruncate()): I actively support the OS/2 EMX port (sys.platform == "os2emx"; build directory is PC/os2emx). I would like to keep the VAC++ port alive, but the reality is I don't have the resources to do so. The VAC++ port was the subject of discussion about removal of build support support from the source tree for 2.6 - I don't recall there being a definitive outcome, but if someone does delete the PC/os2vacpp directory, I'm not in a position to argue. AMK: (mailbox.py has a separate section of code used when file.truncate() isn't available, and the existence of this section is bedevilling me. It would be convenient if platforms without file.truncate() weren't a factor; then this branch could just be removed. In your opinion, would it hurt OS/2 users of mailbox.py if support for platforms without file.truncate() was removed?) aimacintyre: No. From what documentation I can quickly check, ftruncate() operates on file descriptors rather than FILE pointers. As such I am sure that, if it became an issue, it would not be difficult to write a ftruncate() emulation wrapper for the underlying OS/2 APIs that implement the required functionality. -- Comment By: David Watson (baikie) Date: 2007-01-13 10:32 Message: Logged In: YES user_id=1504904 Originator: YES I like the warning idea - it seems appropriate if the problem is relatively rare. How about this? File Added: mailbox-fcntl-warn.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 11:41 Message: Logged In: YES user_id=11375 Originator: NO One OS/2 port lacks truncate(), and so does RISCOS. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 10:41 Message: Logged In: YES user_id=11375 Originator: NO I realized that making flush() invalidate keys breaks the final example in the docs, which loops over inbox.iterkeys() and removes messages, doing a pack() after each message. Which platforms lack file.truncate()? Windows has it; POSIX has it, so modern Unix variants should all have it. Maybe mailbox should simply raise an exception (or trigger a warning?) if truncate is missing, and we should then assume that flush() has no effect upon keys. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 09:12 Message: Logged In: YES u
[ python-Bugs-1598181 ] subprocess.py: O(N**2) bottleneck
Bugs item #1598181, was opened at 2006-11-16 22:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&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: Fixed Priority: 5 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Peter Åstrand (astrand) Summary: subprocess.py: O(N**2) bottleneck Initial Comment: subprocess.py (Python 2.5, current SVN, probably all versions) contains this O(N**2) code: bytes_written = os.write(self.stdin.fileno(), input[:512]) input = input[bytes_written:] For large but reasonable "input" the second line is rate limiting. Luckily, it is very easy to remove this bottleneck. I'll upload a simple patch. Below is a small script that demonstrates the huge speed difference. The output on my machine is: creating input 0.888417959213 slow slicing input 61.1553330421 creating input 0.863168954849 fast slicing input 0.0163860321045 done The numbers are times in seconds. This is the source: import time import sys size = 100 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "slow slicing input" n_out_slow = 0 while True: out = input[:512] n_out_slow += 1 input = input[512:] if not input: break print time.time()-t0 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "fast slicing input" n_out_fast = 0 input_done = 0 while True: out = input[input_done:input_done+512] n_out_fast += 1 input_done += 512 if input_done >= len(input): break print time.time()-t0 assert n_out_fast == n_out_slow print "done" -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-16 23:00 Message: Logged In: YES user_id=33168 Originator: NO Peter this is fine for 2.5.1. Please apply and update Misc/NEWS. Thanks! -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2007-01-07 07:15 Message: Logged In: YES user_id=71407 Originator: YES Thanks for the fixes! -- Comment By: Peter Åstrand (astrand) Date: 2007-01-07 06:36 Message: Logged In: YES user_id=344921 Originator: NO Fixed in trunk revision 53295. Is this a good candidate for backporting to 25-maint? -- Comment By: Mike Klaas (mklaas) Date: 2007-01-04 10:20 Message: Logged In: YES user_id=1611720 Originator: NO I reviewed the patch--the proposed fix looks good. Minor comments: - "input_done" sounds like a flag, not a count of written bytes - buffer() could be used to avoid the 512-byte copy created by the slice -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-11-16 22:43 Message: Logged In: YES user_id=71407 Originator: YES Sorry, I didn't know the tracker would destroy the indentation. I'm uploading the demo source as a separate file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-17 19:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&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: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-16 23:01 Message: Logged In: YES user_id=33168 Originator: NO Bumping priority to see if this should go into 2.5.1. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 02:42 Message: Logged In: YES user_id=21627 Originator: NO Why do frame objects have a thread state in the first place? In particular, why does PyTraceBack_Here get the thread state from the frame, instead of using the current thread? Introduction of f_tstate goes back to r7882, but it is not clear why it was done that way. -- Comment By: Andrew Waters (awaters) Date: 2007-01-04 01:35 Message: Logged In: YES user_id=1418249 Originator: NO This fixes the segfault problem that I was able to reliably reproduce on Linux. We need to get this applied (assuming it is the correct fix) to the source to make Python 2.5 usable for me in production code. -- Comment By: Mike Klaas (mklaas) Date: 2006-11-27 10:41 Message: Logged In: YES user_id=1611720 Originator: YES The following patch resets the thread state of the generator when it is resumed, which prevents the segfault for me: Index: Objects/genobject.c === --- Objects/genobject.c (revision 52849) +++ Objects/genobject.c (working copy) @@ -77,6 +77,7 @@ Py_XINCREF(tstate->frame); assert(f->f_back == NULL); f->f_back = tstate->frame; +f->f_tstate = tstate; gen->gi_running = 1; result = PyEval_EvalFrameEx(f, exc); -- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 10:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. -- Comment By: Tim Peters (tim_one) Date: 2006-10-27 22:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's malloc. The valgrind report is pointing at the same thing. Whether this leads to a crash is purely an accident of when and how the system malloc happens to reuse the freed memory. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-27 21:56 Message: Logged In: YES user_id=33168 Mike, what platform are you having the problem on? I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with debug builds and neither one crashed. Tim's guess looks pretty damn good too. Here's the result of valgrind: Invalid read of size 8 at 0x4CEBFE: PyTraceBack_Here (traceback.c:117) by 0x49C1
[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs
Bugs item #1377858, was opened at 2005-12-10 13:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&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: 9 Private: No Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Michael Hudson (mwh) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-16 23:02 Message: Logged In: YES user_id=33168 Originator: NO Brett, Michael, Armin, can we get this patch checked in for 2.5.1? -- Comment By: Brett Cannon (bcannon) Date: 2006-08-19 21:31 Message: Logged In: YES user_id=357491 After finally figuring out where *list was made NULL (and adding a comment about it where it occurs), I added a test to test_weakref.py . Didn't try to tackle classic classes. -- Comment By: Armin Rigo (arigo) Date: 2006-08-12 04:31 Message: Logged In: YES user_id=4771 The clear_weakref(*list) only clears the first weakref to the object. You need a while loop in your patch. (attached proposed fix) Now we're left with fixing the same bug in old-style classes (surprize surprize), and turning the crasher into a test. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:36 Message: Logged In: YES user_id=357491 So after staring at this crasher it seemed to me to be that clearing the new weakrefs w/o calling their finalizers after calling the object's finalizer was the best solution. I couldn't think of any other good way to communicate to the new weakrefs that the object they refer to was no longer viable memory without doing clear_weakref() work by hand. Attached is a patch to do this. Michael, can you have a look? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 11:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. -- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? -- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 09:17
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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.4
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-16 23:22
Message:
Logged In: YES
user_id=33168
Originator: NO
Were these changes applied by Raymond? I don't think there were NEWS
entries though.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 12:43
Message:
Logged In: YES
user_id=80475
Originator: NO
That looks about right. Please add test cases that fail without the patch
and succeed with the patch. Also, put a comment in Misc/NEWS. If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.
Thanks,
Raymond
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 11:56
Message:
Logged In: YES
user_id=849994
Originator: NO
Attaching patch.
File Added: nokeywordchecks.diff
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 10:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 16:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 13:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name
Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 18:26
Message:
Logged In: YES
user_id=80475
Originator: NO
I prefer the approach used by list().
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 18:19
Message:
Logged In: YES
user_id=1326842
See patch #1491939
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 13:02
Message:
Logged In: YES
user_id=1326842
This bug was introduced as part of the fix for bug #1119418.
It also affects collections.deque.
Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?
array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.
The rest of the types changed in that fix should not
be affected, since they are immutable.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 10:23
Message:
Logged In: YES
user_id=849994
Raymond, what to do in this case?
Note that other built-in types, such as list(), do accept
keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=148666
