[ python-Bugs-1265100 ] sequence slicing documentation incomplete
Bugs item #1265100, was opened at 2005-08-20 16:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: sequence slicing documentation incomplete
Initial Comment:
Here's what points (3) and (5) of the Sequence Types[1]
documentation say now:
"""
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
...
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j
is greater than len(s), use len(s). If i or j are
omitted then they become ``end'' values (which end
depends on the sign of k). Note, k cannot be zero.
"""
I'd like to replace that second-to-last sentence in
point (5), which uses the vague word "end'' in its
description, with something more explicit. I'd like it
to read something like:
"""
If k is positive and i or j is omitted, they will be
replaced with 0 and len(s) respectively. If k is
negative and i or j is omitted, they will be replaced
with -1 and -len(s)-1 respectively. Note that these
replacements happen before the rule from point (3) is
applied.
"""
I'd also like to put an example with point (5) to show
this behavior in action. Something like:
"""
So for example::
>>> seq = 'abcde'
>>> len(seq)
5
>>> 'edc' == seq[:1:-1] == seq[-1:1:-1]
True
>>> 'ca' == seq[2::-2] == seq[2:-5-1:-2]
True
Note however that manually applying the rule from point
(3) (adding len(s) to any i or j that is negative)
works for i, but does not work for j::
>>> seq[5-1:1:-1]
'edc'
>>> seq[2:-1:-2]
''
This is because Python sees the -1 in the j position
and applies the rule from point (3) again.
"""
One of the motivations for this patch is to be able to
explain the difference in behavior between sequence
slicing and slice.indices(), e.g.
>>> seq[::-2]
'eca'
>>> slice(None, None, -2).indices(5)
(4, -1, -2)
>>> seq[4:-1:-2]
''
Right now, I think the documentation is too vague to be
able to make it clear why slices behave differently.
If this patch is accepted, I'll work on a patch for
slice objects that explains the differences.
[1] http://docs.python.org/lib/typesseq.html
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 04:29
Message:
Logged In: YES
user_id=80475
-0
The docs read better with "vague" words like "end". Making
the description more mathematical may make it more precise
but will also make it harder to just read and understand.
The wording suggested above is fathomable only after you
already understand how slicing works. It is the "vague"
words that help achieve the understanding in the first place.
Also, I do not want to clutter this section with examples
intended to compare and contrast slices versus
slice.indices. It would be okay to add a brief comparative
example to the docs for slice.indices(). Understanding the
latter is aided by a comparison. In contrast, you can get
pretty good with slices and know nothing about
slice.indices() which is a somewhat challenging method.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt
Bugs item #1242657, was opened at 2005-07-21 17:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 06:10 Message: Logged In: YES user_id=80475 Okay, fixed in several places. This little fragment occurred in a number of places including code listextend(), map(), zip(), filter(), and PySequence_Tuple(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249837 ] container methods raise KeyError not IndexError
Bugs item #1249837, was opened at 2005-08-01 15:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Raymond Hettinger (rhettinger) Summary: container methods raise KeyError not IndexError Initial Comment: See: http://www.python.org/doc/2.3.5/ref/sequence-types.html, which says, for example, that __getitem__(self, key) should raise an IndexError if key is not in the container. However, built-in dicts raise KeyError instead, and http:// www.python.org/doc/2.3.5/lib/module-exceptions.html#l2h-289 implies that this is the correct behavior. This appears to be incorrect in the current documentation as well as in the 2.3.5 docs. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 06:28 Message: Logged In: YES user_id=80475 Okay. Fixed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-01 16:54 Message: Logged In: YES user_id=80475 Both the behavior and the docs are correct. However, the docs are not especially clear on this point. Will add a clarifying note that KeyError is the appropriate error for mapping types when the key is not found. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207379 ] class property fset not working
Bugs item #1207379, was opened at 2005-05-23 17:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Master_Jaf (master_jaf)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: class property fset not working
Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 06:35
Message:
Logged In: YES
user_id=80475
Stay close to the definition in the tutorial's glossary:
"""
new-style class
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
"""
Also, the 2.2 comment should be in standard form markup:
\versionadded{}
"classes" ==> "class"
Overall, -0 on the update. Ideally, the tutorial should be
kept free of the more advanced concepts like properties,
static methods, descriptors, and whatnot.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 05:27
Message:
Logged In: YES
user_id=1188172
Attaching a patch for the Tutorial. It adds the following
sentence:
+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-26 13:59
Message:
Logged In: YES
user_id=1140154
>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)
So my suggestions for adding info to the documentation:
"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.
"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
[]
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 11:37
Message:
Logged In: YES
user_id=593130
For people who learned Python with old-style classes, it
is 'obvious' that properties are a new addition that came with and
work with new-style classes. Can you suggest specific places in
the docs where clarification could be made? Or should be close
this?
(I suspect that setting is more complicated than getting but would
not have expected even the get method to work.)
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-24 07:27
Message:
Logged In: YES
user_id=1140154
After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
Fine. OK, understood..
I'm tending to agree with mwh's opinion, that this is a
documentation bug, although I don't fully understand why the
GET descriptor is working but unlikly not the SET descriptor.
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-24 02:58
Message:
Logged In: YES
user_id=6656
At the very limit, this is a documentation bug. Why did you think
properties could be attached to old-style classes?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.o
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-12 12:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Alan (aisaac0)
Assigned to: Raymond Hettinger (rhettinger)
Summary: zip incorrectly and incompletely documented
Initial Comment:
See the zip documentation:
http://www.python.org/dev/doc/devel/lib/built-in-funcs.html
i. documentation refers to sequences not to iterables
ii. The other problem is easier to explain by example.
Let it=iter([1,2,3,4]).
What is the result of zip(*[it]*2)?
The current answer is: [(1,2),(3,4)],
but it is impossible to determine this from the docs,
which would allow [(1,3),(2,4)] instead (or indeed
other possibilities).
The example expresses the solution to an actual need,
so the behavior should be documented or warned against,
I believe.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 07:00
Message:
Logged In: YES
user_id=80475
Changed sequences to iterables.
Left the evaluation order as an unspecified, implementation
specific detail.
--
Comment By: Alan (aisaac0)
Date: 2005-03-06 16:36
Message:
Logged In: YES
user_id=1025672
> The OP's problem should be left as a code smell
indicating a misuse of functionals.
Left how? I did not propose any change in behavior
or intent. I only asked that the behavior shd either
i. be determinate and documented, or
ii. be acknowledged in the docs as indeterminate
as a caution not to rely on current behavior
which seems natural but I take it not guaranteed.
(Ideally the docs would link to a helpful explanation
of why it is appropriate not to guarantee the
behavior.)
The fact that this question came up is evidence,
IMO, that the docs are incomplete. (I'm not the
only one who was puzzled.)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-16 20:10
Message:
Logged In: YES
user_id=80475
The first sentence becomes even less clear with the "in the
same order" wording.
The note about truncating to the shortest sequence length is
essential and should not have been dropped.
The py2.4 change note is in a standard form
(\versionchanged{} following the explanation of current
behavior) and should not have been altered.
The part that addresses the OP's concern is too specific to
the his one example and is unclear unless you know about
that example. The wording is discomforting, doesn't add new
information, and is somewhat not obvious in its meaning.
I suggest simply changing "sequence" to "iterable".
There is no sense in stating that the order of combination
is undefined. It doesn't help with the OP's original desire
to be able to predict the outcome of the example. However,
it does have the negative effect of making a person question
whether they've understood the preceding description of what
actually zip() does do.
zip() is about lockstep iteration and the docs should serve
those users as straight-forwardly as possible. The OP's
issue on the other hand only comes up when trying funky
iterator magic -- adding a sentence about undefined ordering
doesn't help one bit.
There is a lesson in all this. These tools were borrowed
from the world of functional programming which is all about
programming that is free of side-effects. The OP's problem
should be left as a code smell indicating a misuse of
functionals.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 19:03
Message:
Logged In: YES
user_id=593130
I agree that the zip doc needs improvement. Confusion will
continue until it is. Here is my suggested rewrite:
---
zip([iterable1, ...])
Return a list of tuples, where the i-th tuple contains the i-th
element from each input in the same order as the inputs.
With no arguments, return an empty list (before 2.4, a
TypeError was raised instead.) With a single input, return a
list of 1-tuples. With multiple inputs, the output length is
that of the shorted input. When multiple input lengths are
equal, zip(i1, ...) is similar to map(None, i1, ...), but there is
no padding when otherwise. The result of zipping a volatile
iterable with itself is undefined. New in 2.0.
---
There you have it. More information is about 15% fewer
words. The reduction came from greatly condensing the
overwordy sente
[ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file
Bugs item #1191043, was opened at 2005-04-27 09:34
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris AtLee (catlee)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: bz2 RuntimeError when decompressing file
Initial Comment:
The following code:
echo -n Testing123 | bzip2 > test.bz2
python -c "import bz2; lines =
bz2.BZ2File('test.bz2').readlines()"
produces this output:
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used
Tested on Python 2.4.1 (debian unstable - April 1
2005), and Python 2.3.5 (debian unstable - May 26 2005)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 07:03
Message:
Logged In: YES
user_id=80475
Reinhold, do you want to take this one?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-14 09:55
Message:
Logged In: YES
user_id=11375
Calling .readline() works fine, though. The problem wasn't
apparent with a quick look at the readlines() code.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 07:14
Message:
Logged In: YES
user_id=80475
Okay, I see. Will look into it.
--
Comment By: Chris AtLee (catlee)
Date: 2005-04-28 07:00
Message:
Logged In: YES
user_id=186532
How is test.bz2 not a valid bz2 file? The command line tool
"bzcat" or "bunzip2" can operate properly on it. Using
BZ2File("test.bz2").read() works properly, it's just the
readlines() call that breaks.
Try this out:
import bz2
bz2.BZ2File("test.bz2","w").write("testing123")
# This works fine
assert bz2.BZ2File("test.bz2").read() == "testing123"
# This raises a RuntimeError
assert bz2.BZ2File("test.bz2").readlines() == ["testing123"]
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 02:06
Message:
Logged In: YES
user_id=80475
The looks like correct behavior to me. The test.bz2 file is
not in a valid bz2 format. I suspect that you've misread
the BZ2File API which is intended for reading and writing
uncompressed data to and from a file in a bz2 format (where
the data is stored in compressed form).
If this interpretation of the bug report is correct, please
mark as not-a-bug and close.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207379 ] class property fset not working
Bugs item #1207379, was opened at 2005-05-24 00:02
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Master_Jaf (master_jaf)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: class property fset not working
Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-21 16:17
Message:
Logged In: YES
user_id=1188172
What am I to do? Correct the patch and apply, or close this
as Rejected?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 13:35
Message:
Logged In: YES
user_id=80475
Stay close to the definition in the tutorial's glossary:
"""
new-style class
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
"""
Also, the 2.2 comment should be in standard form markup:
\versionadded{}
"classes" ==> "class"
Overall, -0 on the update. Ideally, the tutorial should be
kept free of the more advanced concepts like properties,
static methods, descriptors, and whatnot.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 12:27
Message:
Logged In: YES
user_id=1188172
Attaching a patch for the Tutorial. It adds the following
sentence:
+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-26 20:59
Message:
Logged In: YES
user_id=1140154
>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)
So my suggestions for adding info to the documentation:
"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.
"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
[]
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 18:37
Message:
Logged In: YES
user_id=593130
For people who learned Python with old-style classes, it
is 'obvious' that properties are a new addition that came with and
work with new-style classes. Can you suggest specific places in
the docs where clarification could be made? Or should be close
this?
(I suspect that setting is more complicated than getting but would
not have expected even the get method to work.)
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-24 14:27
Message:
Logged In: YES
user_id=1140154
After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
Fine. OK, understood..
I'm tending to agree with mwh's opinion, that this is a
documentation bug, although I don't fully understand why the
GET descriptor is working but unlikly not the SET descriptor.
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-24 09:58
Message:
Logged In: YES
user_id=6656
At the very limit, this is a documentation bug. Why did you think
properties could be attached to old-style classes?
--
[ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file
Bugs item #1191043, was opened at 2005-04-27 16:34
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris AtLee (catlee)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: bz2 RuntimeError when decompressing file
Initial Comment:
The following code:
echo -n Testing123 | bzip2 > test.bz2
python -c "import bz2; lines =
bz2.BZ2File('test.bz2').readlines()"
produces this output:
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used
Tested on Python 2.4.1 (debian unstable - April 1
2005), and Python 2.3.5 (debian unstable - May 26 2005)
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-21 16:19
Message:
Logged In: YES
user_id=1188172
Fixed, also for xreadlines(). Problem was that the code, if
there were no newlines in a chunk read from the file,
assumed that the buffer was too small.
Modules/bz2module.c r1.25
Lib/test/test_bz2.py r1.18
Please review the fix!
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 14:03
Message:
Logged In: YES
user_id=80475
Reinhold, do you want to take this one?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-14 16:55
Message:
Logged In: YES
user_id=11375
Calling .readline() works fine, though. The problem wasn't
apparent with a quick look at the readlines() code.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 14:14
Message:
Logged In: YES
user_id=80475
Okay, I see. Will look into it.
--
Comment By: Chris AtLee (catlee)
Date: 2005-04-28 14:00
Message:
Logged In: YES
user_id=186532
How is test.bz2 not a valid bz2 file? The command line tool
"bzcat" or "bunzip2" can operate properly on it. Using
BZ2File("test.bz2").read() works properly, it's just the
readlines() call that breaks.
Try this out:
import bz2
bz2.BZ2File("test.bz2","w").write("testing123")
# This works fine
assert bz2.BZ2File("test.bz2").read() == "testing123"
# This raises a RuntimeError
assert bz2.BZ2File("test.bz2").readlines() == ["testing123"]
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 09:06
Message:
Logged In: YES
user_id=80475
The looks like correct behavior to me. The test.bz2 file is
not in a valid bz2 format. I suspect that you've misread
the BZ2File API which is intended for reading and writing
uncompressed data to and from a file in a bz2 format (where
the data is stored in compressed form).
If this interpretation of the bug report is correct, please
mark as not-a-bug and close.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-983069 ] md5 and sha1 modules should use openssl implementation
Feature Requests item #983069, was opened at 2004-06-30 15:50 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=983069&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: md5 and sha1 modules should use openssl implementation Initial Comment: the MD5 and SHA-1 modules should use the OpenSSL library to perform the hashing when it is available (always these days; python ships with basic ssl socket support using openssl). OpenSSL includes and keeps up with highly optimized versions of the hash algorithms for various architectures. They should always perform the same or better than the python shamodule and md5module implementations. -- >Comment By: Gregory P. Smith (greg) Date: 2005-08-21 11:57 Message: Logged In: YES user_id=413 hashlib module supporting this has been committed to python cvs head. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=983069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207379 ] class property fset not working
Bugs item #1207379, was opened at 2005-05-24 00:02
Message generated for change (Comment added) made by master_jaf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Master_Jaf (master_jaf)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: class property fset not working
Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.
--
>Comment By: Master_Jaf (master_jaf)
Date: 2005-08-21 22:55
Message:
Logged In: YES
user_id=1140154
I agree with rhettinger, that there is no need to put
advanced things like properties in the tutorial.
But I still think, that the property explanation in "Python
Lib. Ref."
could be a bit more precise.
IMHO it's not enough to say "Return a property attribute for
new-style classes..." because it does not prohibit
explicitly the usage in "old style classes".
Suggestion:
"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
[]
New in Python 2.2. Properties only can be applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-21 16:17
Message:
Logged In: YES
user_id=1188172
What am I to do? Correct the patch and apply, or close this
as Rejected?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 13:35
Message:
Logged In: YES
user_id=80475
Stay close to the definition in the tutorial's glossary:
"""
new-style class
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
"""
Also, the 2.2 comment should be in standard form markup:
\versionadded{}
"classes" ==> "class"
Overall, -0 on the update. Ideally, the tutorial should be
kept free of the more advanced concepts like properties,
static methods, descriptors, and whatnot.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 12:27
Message:
Logged In: YES
user_id=1188172
Attaching a patch for the Tutorial. It adds the following
sentence:
+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-26 20:59
Message:
Logged In: YES
user_id=1140154
>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)
So my suggestions for adding info to the documentation:
"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.
"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
[]
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 18:37
Message:
Logged In: YES
user_id=593130
For people who learned Python with old-style classes, it
is 'obvious' that properties are a new addition that came with and
work with new-style classes. Can you suggest specific places in
the docs where clarification could be made? Or should be close
this?
(I suspect that setting is more complicated than getting but would
not have expected even the get method to work.)
--
Comment By: Master_Jaf (master_jaf)
Date: 2005-05-24 14:27
Message:
Logged In: YES
user_id=1140154
After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.
