New submission from James G. sack (jim) :
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 -vv
or
./python -Ebb Lib
James G. sack (jim) 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 such as an acce
James G. sack (jim) 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.
James G. sack (jim) 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
--
___
Python
James G. sack (jim) 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 the main message, though:
The
James G. sack (jim) 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 to confirm was real rather
James G. sack (jim) 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 (latest)
-r 75818 (first
James G. sack (jim) 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, ostensibly to verify the pat
James G. sack (jim) 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 -r 74869
rm /tmp
New submission from James G. sack (jim) :
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 to an iterable, and hence
New submission from James G. sack (jim) :
Docs for 2.6.2 (http://docs.python.org/library/random.html?
highlight=random#module-random)
presently say
"""
random.randint(a, b)
Return a random integer N such that a <= N <= b.
"""
It should say
...a <= N &l
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".
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
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:
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 PROT
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:
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 lobb
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>
__
___
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_su
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 nothi
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/
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 to
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 u
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
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 mul
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 yo
James G. sack (jim) added the comment:
Here's more:
>>> unicode(object)
u""
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 Unic
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
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:
29 matches
Mail list logo