New submission from James G. sack (jim) jgs...@users.sourceforge.net:
With -r 76870, on Fedora 11, amd x80_64, regrtest of test_format fails
when the -j option is combined with the -v option. It happens whether
testing everything or just the one test.
./python -Ebb Lib/test/regrtest -j3
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
test_commands test_getstatus also fails on linux with SELinux enabled
On gnu/linux, info ls reports:
Following the file mode bits is a single character that specifies
whether an alternate access method
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
It seems that on my Fedora 11 AMD X86_64, the problem still exists. In
test_codecs.UTF32Test, test_handlers() seems to run forever, gobbling
memory to 99+% and then activating swap until it fills up swap.
tested by
svn up
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
Clarification of my last message (msg96468):
The test_handler in the current revision (76850) also exhibits the same
memory-gobbling behavior. I only refered to -r 74869 because that's where
the test was introduced
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
On my Fedora 11 AMD x86_64 system, it appears the deadlock still occurs
(up to the limit of my patience, ie: several minutes). If I reduce to say
3, I can get the test to succeed sometimes.
Observed in: trunk
-r 76850
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
Thanks, it seems to work now.
My test method uses the command format
./python -Ebb Lib/test/regrtest.py -s test_calendar
Sorry for the delayed response, I discovered problems with
test_bz2
test_codecs
which I wanted
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
Update: I was doing something wrong and getting false failures.
I forgot to do ./configure and make after major revision-switches so the
failures I was seeing in bz2 and codecs (and others, :-[ ) was bogus.
Repeating
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
IMPORTANT Correction: Please disregard msg96472.
I was forgetting to do .configure and make, and evidently getting bogus
failures.
test_bz2 works fine now, ..sorry for the false alarm.
~jim
James G. sack (jim) jgs...@users.sourceforge.net added the comment:
IMPORTANT Correction: Please disregard msg 96468 96470.
I was forgetting to do ./configure and make, and evidently getting bogus
failures.
test_codecs works fine now, ..sorry for the false alarm.
~jim
New submission from James G. sack (jim) jgs...@users.sourceforge.net:
file Lib/tests/regrtest.py
Evidently rev 76260 (trunk) / 76261 (py3k)
broke code at
rev 76324 line 655 (py3k)
rev 76321 line 620 (trunk)
which is
if tests[0] == alltests[i]
because tests was rebound from a list
James G. sack (jim) [EMAIL PROTECTED] added the comment:
Can you post an example that requires this code?
This is not a big issue, and it wouldn't hurt if it got declared go away
and come back later if you have patch, test, docs, and a convincing use
case.
..But, for the record..
Suppose
James G. sack (jim) added the comment:
More discussion of utf_8.py decoding behavior (and possible change):
For my needs, I would like the decoding parts of the utf_8 module to treat
an initial BOM as an optional signature and skip it if there is one (just
like the utf_8_sig decoder). In fact
New submission from James G. sack (jim):
The streamreader in utf_8_sig.py fails when asked to read a specified
bytelength of data that ends up in the middle of a multibyte utf8 code.
I will attached a atandalone unittest (which does work from autotest, but
doesn't use test_support
Changes by James G. sack (jim):
Added file: http://bugs.python.org/file8750/test_utf8sig_stream.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1444
__
___
Python-bugs-list
James G. sack (jim) added the comment:
re: msg57041, I'm sorry if I gave the wrong impression about interacting
with other programs. I started this feature request with some half-baked
thinking, which I tried to revise in my second post.
Anyway I'm most interested right now in lobbying
James G. sack (jim) added the comment:
Oops, it looks like my patch may have broken test_partial in test_codecs. I
will try to figure out what the test_partial does in the next day or so,
unless someone else can add some insignt in the meantime.
.jim
James G. sack (jim) added the comment:
One additional clue: test_codecs succeeds in verbose mode but fails in non-
verbose mode (autotest verbosity) .. I think. My eyes are getting
blurry. More tomorrow, I guess.
..j
__
Tracker [EMAIL PROTECTED]
http
James G. sack (jim) added the comment:
I found the errror in my previous patch. It lacked a self.decode=.. line
in the StreamReader.decode elif branch.
I attach a replacement patch diff-u.py26_utf8sig (apply to the 2.6 version
of utf_8_sig.py. (If allowed, I will next remove the incorrect
James G. sack (jim) added the comment:
Adam Olsen wrote:
Adam Olsen added the comment:
The problem with being tolerate as you suggest is you lose the ability
to round-trip. Read in a file using the UTF-8 signature, write it back
out, and suddenly nothing else can open it.
I'm sorry, I
James G. sack (jim) added the comment:
Feature Request REVISION
Upon reflection and more playing around with some test cases, I wish to
revise my feature request.
I think the utf8 codecs should accept input with or without the sig.
On output, only the utf_8_sig should
James G. sack (jim) added the comment:
Later note: kind of weird!
On my LE machine, utf16 reads my BE-formatted test data (no BOM)
apparently assumng some kind of surrogate format, until it finds
an illegal UTF-16 surrogate.
That I fail to understand, especially since it quits upon seeing
James G. sack (jim) added the comment:
re: msg56782
Yes, of course I can explicitly write the BOM. I did realize that after
my first post ( my-'duh' :-[ ).
But after playing some more, I do think this issue has become a
worthwhile one. My second post msg56780 asks that utf_8 be tolerant
James G. sack (jim) added the comment:
OK, I will work on it. I have just downloaded trunk and will see what
I can do. Might be a week or two.
..jim
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1328
New submission from James G. sack (jim):
The behavior of codecs utf_16_[bl]e is to omit the BOM.
In a testing environment (and perhaps elsewhere), a forced BOM is useful.
I'm requesting an optional argument something like
force_BOM=False
I guess it would require such an option in multiple
James G. sack (jim) added the comment:
Martin v. Löwis wrote:
Martin v. Löwis added the comment:
Ok. This is not a bug, but by design. unicode(X)==unicode(str(X)) for
most things, and str(X)==repr(X) for most things. repr(None)=='None',
hence the result you see. Closing as invalid.
P.S
New submission from James G. sack (jim):
'2.5 (r25:51908, Apr 10 2007, 10:27:40) \n[GCC 4.1.2 20070403 (Red Hat
4.1.2-8)]'
unicode(None)
u'None'
This doesn't seem right, ;-)
Regards,
,,jim
--
components: Unicode
messages: 56628
nosy: jgsack
severity: normal
status: open
title
James G. sack (jim) added the comment:
(aside: Wow! that was a fast response to my posting!)
I'm not really sure what makes the most sense,
possibly:
- an exception
- u''
- None
but not u'None'; not a string of length 4. That's quite unexpected!
Regards,
..jim
PS: I don't understand why I
James G. sack (jim) added the comment:
Here's more:
unicode(object)
utype 'object'
There seems to be an call to repr() somewhere in the process.
This seems, at least to me, to violate the principle of least surprise, and
I'm thinking that unicode(x) ought to return UnicodeDecodeError if x
28 matches
Mail list logo
