David Jones d...@pobox.com added the comment:
Attached is a patch which is a diff from this version of wave.py :
http://svn.python.org/view/*checkout*/python/trunk/Lib/wave.py?rev=54394
--
keywords: +patch
Added file: http://bugs.python.org/file13011/wave-20090210.patch
Guilherme Polo ggp...@gmail.com added the comment:
Wouldn't it be better if you only ignored the 'illegal seek' error
instead of ignoring any ioerror (should it even be always discarded) ? I
get a 'bad file descriptor' under Windows 7, but, again, can it be
always discarded ?
You can also
Tarek Ziadé ziade.ta...@gmail.com added the comment:
Done in r69485. Thanks for the patch Phillip !
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3386
___
New submission from Amaury Forgeot d'Arc amaur...@gmail.com:
The following code segfaults on platforms where HAVE_USABLE_WCHAR_T is
not defined (for example: narrow unicode build and sizeof(wchar_t)==4)
from ctypes import *
import ctypes.util
Benjamin Peterson benja...@python.org added the comment:
Fixed in #5137.
--
nosy: +benjamin.peterson
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3729
David Jones d...@pobox.com added the comment:
On 10 Feb 2009, at 12:28, Guilherme Polo wrote:
Guilherme Polo ggp...@gmail.com added the comment:
Wouldn't it be better if you only ignored the 'illegal seek' error
instead of ignoring any ioerror (should it even be always discarded) ?
No.
David Jones d...@pobox.com added the comment:
On 10 Feb 2009, at 12:28, Guilherme Polo wrote:
Guilherme Polo ggp...@gmail.com added the comment:
I'm really unsure about the proposed patch.
Perhaps my example was too trivial. The point is that if you call
setnframes then you can get
Martin v. Löwis mar...@v.loewis.de added the comment:
Fixed in r69489, r69490, r69491, r69492, r69493.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5134
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Committed r69495
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4804
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the patch!
I agree that the 'versionchanged' reference should be added in the docs.
I also think that the test should be updated to check the exception type.
Here's a modified version of your patch that adds a test for
New submission from Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp:
This comes from issue4804. This simple patch is required to pass
test_fdopen on VC6.
--
components: Windows
files: test_fdopen_on_vc6.patch
keywords: patch
messages: 81551
nosy: ocean-city
severity: normal
stage: commit
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment:
I opened new issue related to VC6 as issue5204.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4804
___
David Jones d...@pobox.com added the comment:
On 10 Feb 2009, at 13:02, David Jones wrote:
I also note that my patch can be improved by removing its last 11
lines.
Er, no it can't. What was I thinking?
___
Python tracker rep...@bugs.python.org
Lisandro Dalcin dalc...@gmail.com added the comment:
It worked for me.
BTW, 'make test' did not noticed the change in Modules/testcapi_long.h,
which is #include'd by Modules/_testcapimodule.c. I've attached a
trivial patch for setup.py fixing the dependency issue.
Added file:
New submission from Lie Ryan lie.1...@gmail.com:
I've been experimenting with namedtuple, it seems that string formatting
doesn't recognize namedtuple as mapping.
from collections import namedtuple
Nt = namedtuple('Nt', ['x', 'y'])
nt = Nt(12, 32)
print 'one = %(x)s, two = %(y)s' % nt
#
Changes by Lie Ryan lie.1...@gmail.com:
--
components: +Interpreter Core
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5205
___
Mark Dickinson dicki...@gmail.com added the comment:
Committed, r69498 (trunk) and r69499 (py3k).
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5175
___
Mark Dickinson dicki...@gmail.com added the comment:
...and your patch for setup.py applied in r69500, r69501, r69502, r69503.
Thank you!
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1035576
___
___
Python-bugs-list mailing
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue818201
___
___
Python-bugs-list mailing
Akira Kitada akit...@gmail.com added the comment:
Duplicate of issue1035576
--
nosy: +akitada, tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue755286
___
Akira Kitada akit...@gmail.com added the comment:
duplicate of issue755286
--
nosy: +akitada
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1035576
___
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1169193
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue809846
___
___
Python-bugs-list mailing
Akira Kitada akit...@gmail.com added the comment:
Duplicate of issue644744
--
nosy: +akitada
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1169193
___
Akira Kitada akit...@gmail.com added the comment:
Duplicate of issue1169193
--
nosy: +akitada, tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue644744
___
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1382562
Akira Kitada akit...@gmail.com added the comment:
Is this problem already closed?
--
nosy: +akitada, tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue957381
___
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1289136
___
___
Guilherme Polo ggp...@gmail.com added the comment:
I see what you want to do, but I fell really uncomfortable by totally
ignoring IOError. I could get a bad file descriptor under Linux too, and
I wouldn't like to see it discarded for no reason.
Now, is there some problem if we remove the calls
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1274324
___
___
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - feature request
versions: +Python 2.7, Python 3.1 -Python 2.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1028432
___
New submission from Martin Blais bl...@furius.ca:
Here is a useful trick to restore the normal call syntax for delayed
evaluation for assertRaises():
from contextlib import contextmanager
@contextmanager
def raised(exctype):
try:
yield
raise
Changes by Akira Kitada akit...@gmail.com:
--
nosy: +tarek
type: - feature request
versions: +Python 2.7, Python 3.1 -Python 2.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1051216
___
New submission from Iakov Davydov da...@myths.ru:
Currently there is no obvious way to parse time from ISO
8601/W3C/RFC3339 datetime format (http://www.ietf.org/rfc/rfc3339.txt)
or RFC2822. (Actually RFC2822 could be parsed with rfc822 module but
that is not very good way).
I suggest that we
Changes by Martin Blais bl...@furius.ca:
--
components: +Library (Lib)
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5206
___
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Issue 4879 has been resolved so that that HTTPResponse invokes
socket.socket.makefile() with default buffering. see r69209. Since the
problem stated in this defect has no bearing on 3.0 (there is no special
hack for readline()
New submission from Max m...@research-net.de:
The build_opener() function of urllib2 is speciofied as:
urllib2.build_opener([handler, ...])
I think it should be:
urllib2.build_opener(handler, ...)
see
http://docs.python.org/library/urllib2.html?highlight=build_opener
--
assignee:
Changes by Daniel Diniz aja...@gmail.com:
--
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1214675
___
___
alec resnick aresnick...@gmail.com added the comment:
Hi Georg!
Sorry to be so long in getting back to you. I've attached a suggested
patch for the python-2.6.1-docs-text/library/re.txt documentation.
Also, in looking over Kuchling's HOWTO, the necessary information is
actually there, and I
Changes by Daniel Diniz aja...@gmail.com:
--
components: +Documentation -Library (Lib)
type: - behavior
versions: +Python 2.6, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1440472
Changes by Daniel Diniz aja...@gmail.com:
--
assignee: - georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1661108
Daniel Diniz aja...@gmail.com added the comment:
Invalid per discussion.
--
nosy: +ajaksu2
title: csv.reader endless loop - csv.reader endless loop
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1381476
Daniel Diniz aja...@gmail.com added the comment:
Not confirmed with newer versions, closing suggested.
--
nosy: +ajaksu2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1630794
___
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +facundobatista
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3676
___
___
Python-bugs-list
Daniel Diniz aja...@gmail.com added the comment:
Confirmed in trunk. Here's a copy-n-past'able testcase:
class xcomplex( complex ):
def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)
def __coerce__(self,other):
t = complex.__coerce__(self,other)
Daniel Diniz aja...@gmail.com added the comment:
OP posted a message in python-dev, with no replies:
http://mail.python.org/pipermail/python-dev/2007-June/073625.html
--
nosy: +ajaksu2, marketdickinson
versions: +Python 2.7, Python 3.1 -Python 2.6
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1151323
___
___
Python-bugs-list
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1633648
___
___
Python-bugs-list
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue119
___
___
Python-bugs-list
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3694
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
This is already done in trunk, you can use it as follows:
with self.assertRaises(ZeroDivisionError):
1/0
--
nosy: +pitrou
resolution: - out of date
status: open - closed
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Yes, PyNumber_AsSsize_t() should be used instead.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3694
___
Antoine Pitrou pit...@free.fr added the comment:
Oh, and a test should be added :)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3694
___
___
Barry A. Warsaw ba...@python.org added the comment:
I think we should update the documentation to mention these exceptions.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1440472
___
Georg Brandl ge...@python.org added the comment:
Thanks, closing.
--
nosy: +georg.brandl
resolution: - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1911
Antoine Pitrou pit...@free.fr added the comment:
I agree with MvL, it should probably be rejected. Memory size of longs
is critical in py3k.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue119
Georg Brandl ge...@python.org added the comment:
Well, easy access is not the point. If the object is supposed to have
the file-like interface, and can provide a fileno(), it should.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
Changes by Brett Cannon br...@python.org:
--
title: add reload function - add reload function to IDLE
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1175686
___
Martin v. Löwis mar...@v.loewis.de added the comment:
It is not true that normalize produces aaoAAO. Instead, it produces
u'a\u030aa\u0308o\u0308A\u030aA\u0308O\u0308'
This is the correct result, according to the Unicode specification. It
would be incorrect to normalize them unchanged under
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Duplicate of 1175686.
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5138
Thomas Heller thel...@ctypes.org added the comment:
Fixed in trunk (rev 69505) and release26-maint (rev 69506).
The bug was already fixed in a different way in py3k and release30-maint
although in a different way, I merged this exact fix anyway (rev 69507
and rev 69508).
Thanks.
--
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Kurt, is this something you can add?
Closed the duplicate issue 5138 and leaving this open.
IDLE would be *much* easier to use in conjunction with version control
if there were a reload option that did the equivalent of
Mark Dickinson dicki...@gmail.com added the comment:
I'll take a look.
--
assignee: - marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3734
___
Brett Cannon br...@python.org added the comment:
Georg is right and this has been fixed apparently in 3.0, leaving 2.7
and older broken.
There are two possible solutions to this. One is to change
socket._fileobject.fileno() to simply try self._sock.fp.fileno() if
self._sock.fileno() does not
Martin v. Löwis mar...@v.loewis.de added the comment:
The patch is fine, please apply.
--
assignee: - ocean-city
nosy: +loewis
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5204
New submission from Travis Hassloch tra...@giganews.com:
RFC 977 has been obsoleted by RFC 3977
Numerous new commands, standardized extensions, clarifications.
--
components: Library (Lib)
messages: 81587
nosy: travis
severity: normal
status: open
title: nntplib needs updating to RFC
Brett Cannon br...@python.org added the comment:
Another option is to change urllib.addinfourl to look for fileno() on an
HTTPResponse object.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1327971
New submission from Travis Hassloch tra...@giganews.com:
Underlying zlib can determine when it has hit the end of a compressed
stream without reading past the end. Python zlib implementation requires
that one read past the end before it signals the end by putting data in
Decompress.unused_data.
Mark Dickinson dicki...@gmail.com added the comment:
I don't see a huge need for this. In 2.6, 3.0 and higher, float(repr(x))
recovers x reliably across platforms
(modulo the occasional system strtod bug), even when x is an infinity or nan.
It's true that using float() doesn't help if you
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1732212
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Since PEP 754 has been rejected, I think this issue can be closed.
As noted at the top of PEP 754, much of the functionality of the patch is
already included (in somewhat different form) in 2.6 and 3.0.
--
resolution: - out of date
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1633648
___
___
Daniel Diniz aja...@gmail.com added the comment:
Here's a patch with test for 3.x. Erm, I have no idea if that's all that
is necessary :)
Does this have the potential to break existing code?
Added file: http://bugs.python.org/file13017/pynumber_assizet.diff
Martin v. Löwis mar...@v.loewis.de added the comment:
I wasn't actually proposing to reject it, merely asking, since all
people who ever commented are also committers.
However, since nobody bothered committing it in the last 3+ years, I'm
now rejecting it.
--
resolution: - rejected
Raghuram Devarakonda draghu...@gmail.com added the comment:
The attached patch is a proof of concept for throwing an exception.
If it is not too much of a problem, can you upload the patch to
http://codereview.appspot.com? Reviewing there is simpler. Also, you
will have to include some test
Peter Landgren peter.tal...@telia.com added the comment:
Thanks for the fast response.
I understand that python follows the unicode specification. I think the unicode
standard
is not correct in this case for the Swedish letters. I have asked unicode.org
for an
explanation.
Should not the
Martin v. Löwis mar...@v.loewis.de added the comment:
Should not the Danish letter Ø be normalized as O? I get Ø for all
NFC/NFD/NFKC/NFKD
normalizations?
I think you have a fundamental misunderstanding what a decomposition
is. Ø should *not* be decomposed as O, because clearly, Ø and O
Mark Dickinson dicki...@gmail.com added the comment:
I recommend closing this due to lack of interest/PEP/patch.
2.7 and 3.1 now have n.bit_length(), which matches Gregory's proposed
n.bitwid().
I'm semi-interested in the bit-access methods n.bit(x) and n.bit(hi, lo),
but not enough to write
Peter Landgren peter.tal...@telia.com added the comment:
The same applies Å and A, Ä and A and Ö and O
which also are also different letters as Ø and O are. (Ø is the Danish
version of
Ö )
Maybe not in the unicode world but in treal life.
That's why I'm a little confused.
Will wait and see
Mark Dickinson dicki...@gmail.com added the comment:
Some comments, while I remember:
* the argument to _Py_HashPointer is not always divisible by 8. It's
called to create hashes for various objects, including methodobjects; see
the line:
y = _Py_HashPointer((void*)(a-m_ml-ml_meth));
Antoine Pitrou pit...@free.fr added the comment:
Well, a patch for 2.6 should be provided as well. Besides,
PyExc_OverflowError is probably a better choice than PyExc_IndexError
(but I'm not sure on this one).
___
Python tracker rep...@bugs.python.org
David Jones d...@pobox.com added the comment:
On 10 Feb 2009, at 16:57, Guilherme Polo wrote:
Guilherme Polo ggp...@gmail.com added the comment:
Now, is there some problem if we remove the calls to the tell method
in _write_header ? See patch attached (tests are very welcome too).
Yes
Antoine Pitrou pit...@free.fr added the comment:
Some tests on py3k (32-bit build):
l = [object() for i in range(20)]
[id(l[i+1]) - id(l[i]) for i in range(len(l)-1)]
[16, -96, 104, 8, 8, 8, 8, 8, -749528, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8]
class C(object):
...__slots__ = ()
...
l = [C()
Martin v. Löwis mar...@v.loewis.de added the comment:
The same applies Å and A, Ä and A and Ö and O
which also are also different letters as Ø and O are.
Sure. And rightfully, they Å is *not* (I repeat: not)
normalized as A, under NFD:
py unicodedata.normalize(NFD, uÅ)
u'A\u030a'
Maybe
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Recommend closing this. We like to have eval(repr(obj))==obj where
possible but it is not a strict requirement. Am opposed to the two
proposed solutions (float attributes or new literals). Mark's solution
of defining
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Humph! The time machine strikes again.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5206
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1732212
___
Antoine Pitrou pit...@free.fr added the comment:
Le mardi 10 février 2009 à 21:18 +, Antoine Pitrou a écrit :
Note: a 64-bit build shows an even greater allocation unit:
class C(object):
...__slots__ = ('x')
...
l = [C() for i in range(20)]
[id(l[i+1]) - id(l[i]) for i in
Mark Dickinson dicki...@gmail.com added the comment:
Closing.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue722647
___
Travis Hassloch tra...@giganews.com added the comment:
Attached is a difference which implements CAPABILITIES and MODE READER
and leaves some TODO comments for other RFC 3977 commands.
--
keywords: +patch
Added file: http://bugs.python.org/file13020/nntplib.diff
Mark Dickinson dicki...@gmail.com added the comment:
So there's a hint about what's happening here at the bottom of the section
http://docs.python.org/reference/datamodel.html#id5
of the docs, where it says:
In the current implementation, the built-in numeric types int, long and
float do not
Antoine Pitrou pit...@free.fr added the comment:
I took a look at the patch and it looks ok, apart from the
_checkClosed() hack (but I don't think there's any immediate solution).
It should be noted that HTTPResponse.readline() will be awfully slow
since, as HTTPResponse doesn't have peek(),
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch without the _checkClosed() hack. The solution is simply
to remove redundant _checkClosed() calls in IOBase (for example,
readline() doesn't need to do an explicit `closed` check as it calls
read()).
Added file:
New submission from Mark Dickinson dicki...@gmail.com:
In the 'coercion rules' section of the reference manual, at:
http://docs.python.org/dev/reference/datamodel.html#id5
it says:
Over time, the type complex may be fixed to avoid coercion.
In 3.x, the complex type has (necessarily) been
Mark Dickinson dicki...@gmail.com added the comment:
I think this issue comes down to a doc fix, though I've opened issue 5211
for anyone who fancies having a go at removing coercion from the complex
type.
Here's a doc patch.
--
assignee: marketdickinson - georg.brandl
keywords:
Blair bidih...@gmail.com added the comment:
While Mark Dickinson's patch fixes the documentation, it does not offer
a solution to the original problem, which was rooted in a need to
provide special behaviour based on the numeric types. I made the
original posting because I hoped that this
Changes by Antoine Pitrou pit...@free.fr:
--
resolution: - accepted
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4631
___
New submission from .:. brainsik spork-pyt...@theory.org:
The HMAC module page [1] says:
Note: The md5 hash has known weaknesses but remains the default for
backwards compatibility. Choose a better one for your application.
However, according to the Hash Collision QA [2] linked to from the
.:. brainsik spork-pyt...@theory.org added the comment:
Bruce Schneier also says (regarding the SHA-1 collision attacks), it
doesn't affect applications such as HMAC where collisions aren't important:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
201 - 300 of 375 matches
Mail list logo