New submission from Malte Helmert :
Section "3.1.2. Strings" says "*Once again*, the print() function produces the
more readable output.", but as far as I can see (or grep), this is the first
time that this aspect of print() is mentioned.
--
assignee: d.
New submission from Malte Helmert :
>From Section 3.1.2 of the tutorial:
print("""
Usage: thingy [OPTIONS]
-hDisplay this usage message
-H hostname Hostname to connect to
""")
Malte Helmert added the comment:
Here's a related one if you want to get the sample output really 100% correct.
In the last example of Section 3, the output in
{>>> a, b = 0, 1
>>> while b < 1000:
... print(b, end=' ')
... a, b = b, a+b
...
1 1 2
Malte Helmert added the comment:
I checked if issue1153016 has reappeared for me (Ubuntu, Python 2.6.6), but it
hasn't. Both the urllib and the imaplib examples given there work fine for me.
Or at least opening the connections works fine for me, which it didn't at the
time of is
Malte Helmert added the comment:
> 1. Rather than add a blank line to the output, the input should have
> the newline suppressed with \ (which has been done in previous
> examples).
> print("""\
I think that would be didactically bad after just mentioning that
Malte Helmert added the comment:
I see. (The tutorial really talks about the interactive interpreter though -- I
don't think IDLE has been mentioned yet.)
--
___
Python tracker
<http://bugs.python.org/is
Malte Helmert <[EMAIL PROTECTED]> added the comment:
David,
not sure what you are commenting on. Are you commenting on one of the
patches? The patches do contain those divisions, of course; you can also
run the attached unit test to verify that the patches work f
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9497/test_times.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9501/os_times.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9506/test_posix.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9515/test_posix2.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9516/test_posix3.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9517/test_posix4.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Malte Helmert added the comment:
I can find three places where "0x" is accepted, but probably shouldn't:
1. Python's tokenizer:
>>> 0x
0
>>> 0xL
ValueError: invalid literal for long() with base 16: '0xL'
=> I think these should both be syntax e
Malte Helmert added the comment:
Here's a patch that fixes case 1:
>>> 0x
File "", line 1
0x
^
SyntaxError: invalid token
>>> 0xL
File "", line 1
0xL
^
SyntaxError: invalid token
Added file: h
Malte Helmert added the comment:
And here's a patch that fixes case 3.
Added file: http://bugs.python.org/file9222/PATCH-3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Malte Helmert added the comment:
And here's a patch for case 2 (int) conversion. There is still a slight
inconsistency in error reporting (base 0 vs. base 16) between int and
long, but I'd see this as long's fault:
>>> int("0x", 0)
Traceback (most recent
Malte Helmert added the comment:
This is a cleaner version of PATCH-2a.diff in the sense that the
resulting code contains less duplication. The disadvantage is that it
applies more structural changes to PyOS_strtoul, so may be harder to
merge with other changes.
Added file: http
Malte Helmert added the comment:
Added tests to test_grammar, test_builtin and test_tokenize.
Added file: http://bugs.python.org/file9229/PATCH-TESTS.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Malte Helmert added the comment:
I can reproduce the bug on trunk (r60511). At first I thought the
behaviour might be caused by the testcase removing items from the
children list while iterating over it, but this is not the case; the
exception is raised upon the first removal already.
Here is a
Malte Helmert added the comment:
OK, I think I found the root cause. Node.normalize regenerates the list
of children L with their previousSibling/nextSibling references from
scratch; however, it fails to set the nextSibling reference for the very
last element of L to None at the end. This is
Malte Helmert added the comment:
Here is a minimal testcase to more clearly expose the root of the
problem, in case a regression test is needed. Without the patch, the
assertion fails.
==
from xml.dom import minidom
node
Changes by Malte Helmert:
--
versions: +Python 2.6 -Python 2.4
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1433694>
_
___
Python-bugs-list
Malte Helmert added the comment:
I'm attaching a test script (test_times.py) that forks a child which
runs for 5 seconds, waits for the child, then prints the time taken by
the child according to os.times().
I have a machine where os.times() reproducably reports that 8.33 seconds
have
Malte Helmert added the comment:
Here's three tests with different pythons on the same machine:
# ./python ../test_times.py
8.333
# python ../test_times.py
8.333
# python2.5 ../test_times.py
5.0
The first Python is current trunk, built just now.
The second Python is the v
Malte Helmert added the comment:
I'm attaching a patch against trunk that fixes the problem for me
(os_times.PATCH).
This uses the sysconf values when HAVE_SYSCONF is defined, and otherwise
falls back on the old behaviour (use HZ if that is defined, 60
otherwise).
I'm not sure
Malte Helmert added the comment:
Another comment: Since the fallback value of 60 was wrong in the past,
it may likely be wrong in the future. Should that fallback be removed
and replaced by a compile-time error? And is the "HZ" fallback necessary
at all? I don't know enough abou
Malte Helmert added the comment:
Here is a patch that adds a test case to test_posix.py. This is ignored
on Windows, as it requires fork.
There is a trade-off: If WAIT_TIME isn't large enough, small
irregularities in the process scheduler might cause this to fail. If it
is too large, the
Malte Helmert added the comment:
Using 1.0 would certainly be more robust. I wasn't sure if a slow-down
of "make test" by 1 second just for this one bug would be acceptable.
Regarding the fork, when I first encountered this bug, it was in the
context of measuring the runtime of
Malte Helmert added the comment:
Note: My original unit test fails to take account that previous unit
tests may have spawned child processes. The correct behaviour is of
course to call os.times() before and after the fork and compute the
difference.
I'm not uploading a modified patch be
New submission from Malte Helmert:
In the discussion of #1433694 on the #python-dev channel, it was
observed that the normalize method of minidom.Node could take some
refactoring. A patch is attached.
--
components: XML
files: minidom.diff
messages: 62794
nosy: maltehelmert
severity
Malte Helmert added the comment:
Attaching a new test (test_posix2.PATCH) that doesn't fork and fixes the
problem with the previous test not taking previously elapsed time into
account. This supersedes test_posix.PATCH.
I left the wait time at 0.1; if we stay within the same process,
Malte Helmert added the comment:
I was wrong -- 0.1 isn't enough, because os.times() typically has 0.01s
resolution, so we can easily get 0.1 vs. 0.11 which will fail the
assertion. Cranked up the WAIT_TIME to 0.3 in the attached patch
(test_posix3.PATCH). Sorry for the noise.
Added file:
Malte Helmert added the comment:
Sorry, but the test was still wrong because I misunderstood how
assertAlmostEqual works. Attaching a fourth (final?) test.
Added file: http://bugs.python.org/file9517/test_posix4.PATCH
_
Tracker <[EMAIL PROTECTED]>
Malte Helmert added the comment:
Alexander, regarding your comments:
1. sysconf in general returns a long because it can return all sorts of
information, but os.times() returns clock_t items, so the _SC_CLK_TCK
value must comfortably fit into a clock_t. It's preferable to cast into
a cl
Malte Helmert added the comment:
Alexander, speed-wise your patch is worse than the original one on
systems where HZ isn't predefined, because it calls sysconf 5 times in
each call to os.times, rather than only once per call.
If you worry about speed, the approach outlined in Antoine&#
Malte Helmert added the comment:
Tiran, that's the general approach we should follow, yes.
But the people who discussed this on #python-dev all felt a bit queasy
about the "60" fallback -- this is what caused the bug in the first
place on Guido's and my machine. (A value of
Malte Helmert added the comment:
Never mind, on Windows a different code path is chosen.
I'm now working on a patch that computes the hz value during module
initialization. So should I keep the 60 magic value? What is the
justification?
_
Tracker &l
Malte Helmert added the comment:
Here is an updated patch (os_times4.PATCH) that incorporates Christian's
suggestions. The patch includes the new unit test, so test_posix?.PATCH
need not be applied separately.
I again made the unit test a bit more lenient to allow an absolute error
of
Malte Helmert added the comment:
I'd prefer a noisy compile error, since in situations where times is
available but unusable, HAVE_TIMES shouldn't have been #defined in the
first place. (That is, I'd see that as a bug in the configure script.)
But this is turning into a bikeshe
Malte Helmert added the comment:
>> I'd prefer a noisy compile error ..
>
> That would be fine if you could verify that none of the currently
> supported platforms will be affected. I would still feel uneasy about
> refusing to build python simply because os.t
Malte Helmert added the comment:
Alexander, your one-line patch *does* affect performance on my 64-bit
Linux machine in a worse way than any other proposed patch by calling
sysconf five times. HZ may be defined on your machine, but it isn't on
my (Xeon) machine.
I checked man pages on
Malte Helmert added the comment:
Antoine, none of the recently proposed patches uses the 60 magic value.
Alexander's patch doesn't define times in that case (leading to an
AttributeError when trying to call os.times) while my patch complains
about the bogus environment during c
Malte Helmert added the comment:
s/standard library/system library/, of course.
Also, the original code is wrong in preferring HZ over the sysconf value.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Malte Helmert added the comment:
If I remove the "#define 60" line in an unmodified posixmodule.c from
trunk, I get the following compiler error:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c
Malte Helmert added the comment:
In the first line of my previous message, I mean "#define HZ 60", of course.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
Malte Helmert added the comment:
Christian, I agree on all points. Alexander's patch posixmodule.diff
satisfies those requirements.
I suggest also adding the unit test from os_times4.PATCH (but not the
changes to posixmodule.c in that patch), as this will help identify
misbehaving platfor
Malte Helmert added the comment:
Great, we're approaching closure! :-)
One final small thing: As said somewhere above, the allowed discrepancy
in test_posix4.PATCH is a bit too low for machines with only 60 ticks
per second. I uploaded a slightly more generous test_posix5.PATCH instead
Malte Helmert added the comment:
I think it's better only to only add another fallback if the unit tests
show that such platforms exist. Avoiding cruft is important, too. After
all, sysconf is a standard POSIX API, and from my (admittedly limited)
research was already available in that form
Changes by Malte Helmert <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9540/os_times4.PATCH
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Malte Helmert <[EMAIL PROTECTED]> added the comment:
Martin,
compilation indeed breaks if sysconf is available but _SC_CLK_TCK is
not. My Unix-foo is not sufficient to confidently say that this is
impossible, so my suggestion is to add defined(_SC_CLK_TCK) to the
condition of this #ifdef
Malte Helmert <[EMAIL PROTECTED]> added the comment:
OK, modified and simplified patch attached (os_times5.PATCH).
The patch and unit test (in test_posix5.PATCH) apply cleanly against the
trunk. "make test" passes on two machines I tried, including a 64-bit
Linux machine where t
Malte Helmert added the comment:
> I see. I wish that people would a) always provide complete patches in
> a single file, and b) delete files themselves that have been
> superceded by others. In any case, I have re-attached the file;
> thanks for pointing this out.
Regarding b), I
Malte Helmert added the comment:
I eyeballed the new patch and wonder if the case where text nodes are
collapsed is handled correctly. Assume that self.childNodes contains
nodes [A, B, C], where A and B are non-empty text nodes and C is a
non-text node.
The algorithm would collapse A and B
Malte Helmert added the comment:
While we're cleaning up:
data = child.data
if not data:
could be
if not child.data:
since data is not used again.
Alternatively, you could use data in place of child.data later on for a
small speed-up, but I doubt that we care about
Changes by Malte Helmert :
Removed file: http://bugs.python.org/file9513/minidom.diff
___
Python tracker
<http://bugs.python.org/issue2170>
___
___
Python-bugs-list mailin
Malte Helmert added the comment:
I removed my original patch which has been superseded by David's patch.
David, I suggest that you also remove test_minidom.patch which is
superseded by your later patch (see http://bugs.python.org/msg77766 for
policy on
Malte Helmert added the comment:
Short review: code looks good to me, patch applies cleanly to trunk,
passes tests.
@akuchling: I don't know if you remember, but this rewrite was
originally suggested by you on a bug day some time ago. I think David's
patch is ready to
58 matches
Mail list logo
