[issue23850] Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER
Changes by Giacomo Alzetta giacomo.alze...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python type: - enhancement versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23850 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23850] Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER
New submission from Giacomo Alzetta: Python2.7 documentation is missing critical information regarding the backporting of the new-buffer protocol. There is no mention whatsoever of the Py_TPFLAGS_HAVE_NEWBUFFER flag which is required to implement it. The only way to discover it is by reading the sources of the built-ins or stdlib. -- messages: 239895 nosy: Giacomo.Alzetta priority: normal severity: normal status: open title: Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23850 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21782] hashable documentation error: shouldn't mention id
New submission from Giacomo Alzetta: The documentation for hashable in the glossary (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) is incorrect: they all compare unequal (except with themselves), **and their hash value is their id().** It is *not* true that their hash is their id (see relevant SO question: http://stackoverflow.com/questions/24249729/user-defined-class-hash-and-id-and-doc) Also the documentation for __hash__ (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) doesn't even mention id(). -- assignee: docs@python components: Documentation messages: 220746 nosy: Giacomo.Alzetta, docs@python priority: normal severity: normal status: open title: hashable documentation error: shouldn't mention id type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21782] hashable documentation error: shouldn't mention id
Giacomo Alzetta added the comment: their hash value is their id() seems quite clearly stating that: class A: pass ... a = A() hash(a) == id(a) should be true, but: hash(a) == id(a) False (both in python2 and in python3) The python 2 documentation for the __hash__ special method *does* state that the default implementation returns a value derived by id(). I believe there is an inconsistency. In the python2 glossary it should say: their hash value is derived from their id() While in python3 it shouldn't mention id() at all, since the documentation for __hash__ doesn't mention it at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20902] Which operand is preferred by set operations? Missing information in the documentation
Giacomo Alzetta added the comment: I asked this because, for example, in Haskell it *is* a well-defined behaviour (see its documentation at: http://hackage.haskell.org/package/containers-0.5.4.0/docs/Data-Set.html): the left operand is preferred by all operations. In fact, working with Haskell, I also have used such behaviour in the past. For example when writing a simple type-checker it's quite convenient to use such behaviour when handling environments where you want inner blocks to hide outer variables. Not defining such behaviour means that you must re-implement the wheel in order to achieve the correct behaviour. In any case, this information should be made explicit in the docs, whether we want to make the behaviour defined or not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20902 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20902] Which operand is preferred by set operations? Missing information in the documentation
New submission from Giacomo Alzetta:
Currently the documentation for set (at:
http://docs.python.org/2/library/stdtypes.html#set) does not mention which
operand is preferred when performing the usual binary operations.
For example the following sample code doesn't have a defined result according
to the documentation:
class MyObj:
def __init__(self, key, value):
self.key = key
self.value = value
def __key(self):
return self.key
def __hash__(self):
return hash(self.__key())
def __eq__(self, other):
return type(self) is type(other) and self.__key() == other.__key()
a = {MyObj(1, 'a')}
b = {MyObj(1, 'b')}
print((a b).pop().value) # 'a' or 'b'?
As far as I can tell currently there is no rule about this. Intersection
prefers the second operand, while union prefers the first. These are the only
operations where this is important since they include common elements.
I believe that this kind of information ought to be included explicitly near
such operations. At the very least, if the behaviour should really be somehow
undefined, it should be stated there so that people don't rely on such
behaviour.
The same should be stated for |= and =, since the first will not modify common
elements while the latter will.
PS: I can't find any resource about the formatting of issues (e.g. if and which
syntax is used for code blocks. Sorry for that.
--
assignee: docs@python
components: Documentation
messages: 213305
nosy: Giacomo.Alzetta, docs@python
priority: normal
severity: normal
status: open
title: Which operand is preferred by set operations? Missing information in the
documentation
type: enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20902
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18750] '' % [1] doesn't fail
Giacomo Alzetta added the comment: Note that the documentation for formatting with %, found here: http://docs.python.org/2/library/stdtypes.html#string-formatting-operations, states: If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary). Note how it explicitly states that in an expression: format % value there are two different cases: - If format contains *exactly one* format specifier, then value can be any non-tuple item and it will be formatted as is. Otherwise, value MUST be either tuple or a mapping. In your example '' contains 0 format specifiers, hence you MUST use either a tuple or a dict. Any other object triggers undefined behaviour(in particular depending on whether the object define __geitem__ or not the formatting might or might not raise an exception etc.) AFAIK only few people know this, hence changing the code could potentially break a lot of code for apparently no reason. Since people should start to move to str.format instead of % this wart may not be worth fixing. -- nosy: +bakuriu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16273] f.tell() returning negative number on Windows build
Giacomo Alzetta added the comment:
I can reproduce a similar behaviour, but instead of negative values I obtain
huge values(which may as well be a negative unsigned converted to a python
int).
See this stackoverflow question:
http://stackoverflow.com/questions/15934950/python-file-tell-giving-strange-numbers
If it doesn't use ftell() then this might mean that there is a new bug in the
current implementation? I can reproduce the results of the questioner, on a
windows7 machine with python3.3.0, with the following code:
with open('C:/Users/Giacomo/test', 'wb') as f:
f.write(b'hello\r\n\r\n-data1:blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah\r\n\r\n\r\n-data2:blah blah blah blah
blah blah blah blah blah blah blah\r\n-data3: Empty\r\n\r\n-data4: Empty')
with open('C:/Users/Giacomo/test', 'rt') as f:
for line in iter(f.readline, ''):
print(f.tell())
Which outputs:
7
9
18446744073709551714
99
101
164
179
181
194
As I explained in my answer I thought the 1844... was due to the ftell() bug,
but if that's not it I'm at a loss. Could you explain this results with the
current implementation?
By the way: it seems to be a python3.3 bug, since python3.2.3 is not affected.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16273
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16273] f.tell() returning negative number on Windows build
Giacomo Alzetta added the comment: The documentation for python 3.3.1 states, at http://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files, states: f.tell() returns an integer giving the file object’s current position in the file, **measured in bytes from the beginning of the file**. And regarding files opened in text mode the only statement is: In text files (those opened without a b in the mode string), only seeks relative to the beginning of the file are allowed (the exception being seeking to the very file end with seek(0, 2)). Even though in the io module it is documented that it may not be the number of bytes. I think the former documentation should be changed, since it's simply wrong. Sorry for the disturb, but in the beginning I thought it was related. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16273] f.tell() returning negative number on Windows build
Giacomo Alzetta added the comment: I can't find any mention of this behaviour in python3's documentation, nor any reference to ftell(). Is it only well hidden or was it deleted by accident? -- nosy: +bakuriu status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
