[issue10145] (4.2).is_integer() is undocumented.
New submission from Ralph Corderoy : floats now have an is_integer() method. I think it was added in 2.6 around the same time as as_integer_ratio(). It has a docstring but it isn't mentioned in the documentation. I only idled across it when reading the C source. I'd expect to find it, for example, at http://docs.python.org/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float http://docs.python.org/py3k/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float Can it please be added, and for Py2, mention what version it appeared in. -- assignee: d...@python components: Documentation messages: 119133 nosy: d...@python, ralph.corderoy priority: normal severity: normal status: open title: (4.2).is_integer() is undocumented. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue10145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10713] re module doesn't describe string boundaries for \b
Ralph Corderoy added the comment:
Examining the source of Ubuntu's python2.6 2.6.6-5ubuntu1 package
suggests beyond the limits of the string is considered \W, like Perl.
Modules/_sre.c:
336 LOCAL(int)
337 SRE_AT(SRE_STATE* state, SRE_CHAR* ptr, SRE_CODE at)
338 {
339 /* check if pointer is at given position */
340
341 Py_ssize_t thisp, thatp;
...
365 case SRE_AT_BOUNDARY:
366 if (state->beginning == state->end)
367 return 0;
368 thatp = ((void*) ptr > state->beginning) ?
369 SRE_IS_WORD((int) ptr[-1]) : 0;
370 thisp = ((void*) ptr < state->end) ?
371 SRE_IS_WORD((int) ptr[0]) : 0;
372 return thisp != thatp;
SRE_IS_WORD() returns 16 for the 63 \w characters, 0 otherwise.
This is born out by tests.
Note, 366 above confirms it's never true for an empty string. The
documentation states that \B "is just the opposite of \b" yet
re.match(r'\b', '') returns None and so does \B so \B isn't the opposite
of \b in all cases.
--
___
Python tracker
<http://bugs.python.org/issue10713>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12030] Roundup Refused Update with No text/plain
New submission from Ralph Corderoy : I tried to reply to the email I was sent when eric.araujo added a comment to #10713. The email I sent was plain text but wasn't a MIME email. It was rejected, "Failed issue tracker submission", "Roundup requires the submission to be plain text. The message parser could not find a text/plain part to use." I understand why it looks for plain/text parts of a MIME email, but shouldn't it be happy with a non-MIME email that by definition is plain text and has only one part? I've attached the rejected email. -- components: None files: nonmime.txt messages: 135525 nosy: ralph.corderoy priority: normal severity: normal status: open title: Roundup Refused Update with No text/plain versions: 3rd party Added file: http://bugs.python.org/file21933/nonmime.txt ___ Python tracker <http://bugs.python.org/issue12030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10713] re module doesn't describe string boundaries for \b
New submission from Ralph Corderoy : The re module defines \b in a regexp to need \w one side and \W the other. What about when the end of the string or line is involved? perlre(1) says that's treated as a \W. Python should precisely document that case too. -- assignee: d...@python components: Documentation messages: 124097 nosy: d...@python, ralph.corderoy priority: normal severity: normal status: open title: re module doesn't describe string boundaries for \b ___ Python tracker <http://bugs.python.org/issue10713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3758] "make check" suggest a testing target under GNU coding standards
New submission from Ralph Corderoy <[EMAIL PROTECTED]>: A new target, "check", has been added to Makefile for 2.6. It runs some tests on the source code that are intended to check there's nothing wrong before preparing a patch. http://svn.python.org/view/python/trunk/Makefile.pre.in?rev=61528&view=markup Unfortunately, GNU coding standards have cemented in many people's minds that "check" is the target for self-tests, e.g. "make clean all check install". http://www.gnu.org/prep/standards/standards.html#Standard-Targets I realise Python doesn't fall under those coding standards, but none the less it is confusing to people to re-use a standard target name for a different use. In the past, Python had no "check" target so people spotted their mistake, investigated, and found the "test" target. Please consider renaming this new "check" target, e.g. to "prepatch", to avoid this confusion when 2.6 is released. Perhaps a "check" target can be added as a synonym for "test" at the same time? -- components: Build messages: 72337 nosy: ralph.corderoy severity: normal status: open title: "make check" suggest a testing target under GNU coding standards type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3845] memory access before short string when checking suffix
Changes by Ralph Corderoy <[EMAIL PROTECTED]>: -- nosy: +ralph.corderoy ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3845> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3758] "make check" suggest a testing target under GNU coding standards
Ralph Corderoy <[EMAIL PROTECTED]> added the comment: The patchcheck target isn't in .PHONY at the end of the file. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8220] site.py's Quitter pollutes builtins with exit and quit for non-interactive use
New submission from Ralph Corderoy :
A friend wrote "exit(0)" in a script without an import of sys. I
pointed out the error and he said "But it works". He was right.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 9.10
Release:9.10
Codename: karmic
$ python --version
Python 2.6.4
$ python -c 'quit("foo")'
foo
$ echo $?
1
$ python -Sc 'quit("foo")'
Traceback (most recent call last):
File "", line 1, in
NameError: name 'quit' is not defined
$ python -c 'print quit.__class__, exit.__class__'
$
site.py is polluting, to my mind, the builtin namespace with `exit' and
`quit'. Surely this should only happen for interactive use of python?
http://docs.python.org/library/constants.html#exit says "They are useful
for the interactive interpreter shell and should not be used in
programs." but it seems to easy for exit, especially, to be used by
mistake.
Could the pollution only happen if the Python interpreter is an
interactive one? Or, not as good, when called, could they tell this
isn't an interactive session and error?
--
components: Library (Lib)
messages: 101635
nosy: ralph.corderoy
severity: normal
status: open
title: site.py's Quitter pollutes builtins with exit and quit for
non-interactive use
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue8220>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Changes by Ralph Corderoy : ___ Python tracker <http://bugs.python.org/issue4753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Ralph Corderoy added the comment: Regarding compressing the opcode table to make better use of cache; what if the most frequently occurring opcodes where placed together, e.g. the opcodes were ordered by frequency, most frequent first. Just based on a one-off static analysis of a body of code. A level one cache line can be, what, 64 bytes == 16 32-bit pointers. -- nosy: +ralph.corderoy ___ Python tracker <http://bugs.python.org/issue4753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633941] for line in sys.stdin: doesn't notice EOF the first time
Ralph Corderoy added the comment:
This most certainly is a bug under Unix and an annoying one. "Since the
issue is with platform's stdio library" is wrong; stdio is being used
incorrectly. It would be nice to see it fixed in the 2.x line.
I've two test programs.
$ head -42 stdin2.6 stdin3.1
==> stdin2.6 <==
#! /usr/bin/python2.6
import sys
for l in sys.stdin:
print repr(l)
print 'end'
==> stdin3.1 <==
#! /usr/bin/python3.1
import sys
for l in sys.stdin:
print(repr(l))
print('end')
$
For both of them I will type "1 Enter 2 Enter 3 Enter Ctrl-D" without
the spaces, Ctrl-D being my tty's EOF, stty -a.
$ ./stdin2.6
1
2
3
'1\n'
'2\n'
'3\n'
On the EOF the first iteration of sys.stdin returns and then so do the
others with the buffered lines. The loop doesn't terminate, a second
Ctrl-D is required, giving.
end
$
Next,
$ ./stdin3.1
1
'1\n'
2
'2\n'
3
'3\n'
end
$
perfect output. Only one Ctrl-D required and better still each line is
returned as it's entered.
ltrace shows python2.6 uses fread(3). I'm assuming it treats only a
zero return as EOF whereas whenever the return value is less than the
number of requested elements, EOF could have been reached; feof(3) must
be called afterwards to decide. Really, ferror(3) should also be called
to see if, as well as returning some elements, an error was detected.
It's this lack of feof() that means the second fread() is required to
trigger the flawed `only 0 return is EOF' logic.
Here's some C that shows stdio works fine if feof() and ferror() are
combined with fread().
#include
int main(void)
{
unsigned char s[8192], *p;
size_t n;
while ((n = fread(s, 1, 8192, stdin))) {
printf("%zd", n);
p = s;
while (n--)
printf(" %02hhx", *p++);
putchar('\n');
if (feof(stdin)) {
puts("end");
break;
}
if (ferror(stdin)) {
fputs("error", stderr);
return 1;
}
}
return 0;
}
--
nosy: +ralph.corderoy
___
Python tracker
<http://bugs.python.org/issue1633941>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30128] xid_start definition for Unicode identifiers refers to xid_continue
New submission from Ralph Corderoy: https://docs.python.org/3/reference/lexical_analysis.html#identifiers has a grammar. identifier ::= xid_start xid_continue* id_start ::= id_continue ::= xid_start::= xid_continue ::= I struggle to make sense of it unless I remove `xid_continue*' from `xid_start's definition. I suspect it ended up there due to cut and paste. -- assignee: docs@python components: Documentation messages: 292049 nosy: docs@python, ralph.corderoy priority: normal severity: normal status: open title: xid_start definition for Unicode identifiers refers to xid_continue versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30428] mailbox.MMDF wrongly adds From_ header to file
New submission from Ralph Corderoy:
Class mailbox.MMDF supports the MMDF-mail-spool file format. This is a file
with zero or more records, each starts and ends with a line of four ASCII SOHs.
Within those two lines is an email in RFC 5532 format, i.e. a headers section
followed by an optional body. There is no "From_" header before the headers
section as used by mbox format.
https://docs.python.org/3/library/mailbox.html#mmdf references
http://www.tin.org/bin/man.cgi?section=5&topic=mmdf that explains this clearly
and gives an example spool file; there is no "From_" header.
mailbox.MMDF documents it produces a From_ header and does so. This is wrong.
It's wrong in Python 2 too.
>>> import mailbox as mb
>>> f = mb.MMDF('mail.spool')
>>> f.add('Subject: Python Bug.\nFrom: b...@hunter.com\n\nEnds.\n')
0
>>> f.close()
>>> print(repr(open('mail.spool').read()))
'\x01\x01\x01\x01\nFrom MAILER-DAEMON Mon May 22 10:14:02 2017\nSubject:
Python Bug.\nFrom: b...@hunter.com\n\nEnds.\n\n\x01\x01\x01\x01\n'
>>>
Other MMDF-handling software other than tin(1), e.g.
http://www.nongnu.org/nmh/, neither produces a From_ header for MMDF, nor
handles one being present.
--
components: Library (Lib)
messages: 294138
nosy: ralph.corderoy
priority: normal
severity: normal
status: open
title: mailbox.MMDF wrongly adds From_ header to file
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5987] Broken link to "Curses Programming with Python"
New submission from Ralph Corderoy : http://www.python.org/doc/2.5.2/lib/module-curses.html links to http://docs.python.org/dev/howto/index.htmlcurses/curses.html as "Curses Programming with Python" but it's 404 Not Found. It may be that this link is broken in other Python versions, 2.5.2 is just the one I refer to for Ubuntu 8.04. -- assignee: georg.brandl components: Documentation messages: 87535 nosy: georg.brandl, ralph.corderoy severity: normal status: open title: Broken link to "Curses Programming with Python" versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue5987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5987] Broken link to "Curses Programming with Python"
Ralph Corderoy added the comment: Does that mean it's policy not to correct documentation for non-latest versions? Fair enough. But perhaps http://www.python.org/doc/2.5.2/lib/about.html should be changed to reflect that, and likewise on other non-latest versions, e.g. "If the problem still exists in the latest documentation, please report it". -- ___ Python tracker <http://bugs.python.org/issue5987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1152248] Enhance file.readlines by making line separator selectable
Ralph Corderoy added the comment: Google has led me here because I'm trying to see how to process find(1)'s -print0 output with Python. Perl's -0 option and $/ variable makes this trivial. find -name '*.orig' -print0 | perl -n0e unlink awk(1) has its RS, record separator, variable too. There's a clear need, and it should also be possible to modify or re-open sys.stdin to change the existing separator. -- nosy: +ralph.corderoy ___ Python tracker <http://bugs.python.org/issue1152248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1152248] Enhance file.readlines by making line separator selectable
Ralph Corderoy added the comment:
fileLineIter() is not a solution that allows this bug to be closed, no.
readline() needs modifying and if that means python-dev discussion then
that's what it needs. Things to consider include changing the record
separator as the file is read.
$ printf 'a b c\nd e f ' |
> awk '{print "<" $0 ">"} NR == 1 {RS = " "}'
$
--
___
Python tracker
<http://bugs.python.org/issue1152248>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
