saa p5t...@saaworld.com added the comment:
There are bigger problems here. When the code calculates the size to map
if size is passed as zero, it simply assigns the 64-bit st_size to the
size to mmap. On a 32-bit system, it is obvious that the amount to map
must be less than a 32-bit value.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Posted some doc cleanups in r67850 and r67851.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
New submission from Michael Newman michael.b.new...@gmail.com:
UnicodeEncodeError occurs for Microsoft portion of license().
Confirmed on 3 separate Windows XP computers:
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license
Martin v. Löwis mar...@v.loewis.de added the comment:
This is not a bug. The registry keys do get set, though not in
HKEY_LOCAL_MACHINE, but in HKEY_CURRENT_USER. To install quietly for all
users, you need to add ALLUSERS=1; see
http://www.python.org/download/releases/2.5/msi/
--
New submission from Hagen Fürstenau hfuerste...@gmx.net:
As reported by Dmitry Vasiliev on python-dev, a range object suddenly
becomes hash()able after an attribute access, e.g. by dir().
If I understand correctly, then the reason is that PyRange_Type doesn't
set tp_hash and PyType_Ready is not
Changes by Hagen Fürstenau hfuerste...@gmx.net:
--
keywords: +patch
Added file: http://bugs.python.org/file12400/rangehash.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Guilherme Polo ggp...@gmail.com added the comment:
You don't need to cast PyObject_HashNotImplemented to hashfunc
--
nosy: +gpolo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Hagen Fürstenau hfuerste...@gmx.net added the comment:
Why does every other place seem to do the cast? Historical reasons?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Guilherme Polo ggp...@gmail.com added the comment:
On Fri, Dec 19, 2008 at 2:02 PM, Hagen Fürstenau rep...@bugs.python.org wrote:
Hagen Fürstenau hfuerste...@gmx.net added the comment:
Why does every other place seem to do the cast? Historical reasons?
No, if you look at the functions
Hagen Fürstenau hfuerste...@gmx.net added the comment:
I'm talking about places like these:
[hag...@chage py3k]$ grep -R (hashfunc)PyObject_HashNotImplemented
Objects/*.c Modules/*.c
Objects/dictobject.c: (hashfunc)PyObject_HashNotImplemented, /*
tp_hash */
Objects/listobject.c:
Guilherme Polo ggp...@gmail.com added the comment:
On Fri, Dec 19, 2008 at 2:14 PM, Hagen Fürstenau rep...@bugs.python.org wrote:
Hagen Fürstenau hfuerste...@gmx.net added the comment:
I'm talking about places like these:
[hag...@chage py3k]$ grep -R (hashfunc)PyObject_HashNotImplemented
Hagen Fürstenau hfuerste...@gmx.net added the comment:
Here's an updated patch without the cast and a separate patch for
removing the other casts.
Added file: http://bugs.python.org/file12401/rangehash2.patch
___
Python tracker rep...@bugs.python.org
Changes by Hagen Fürstenau hfuerste...@gmx.net:
Added file: http://bugs.python.org/file12402/remove_casts.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Changes by Hagen Fürstenau hfuerste...@gmx.net:
Removed file: http://bugs.python.org/file12400/rangehash.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Mark Dickinson dicki...@gmail.com added the comment:
About the footnote:
floor(log(n, 2)) is poor code. This is not supposed to be a dramatic
statement, just a statement of fact. Its correctness is dependent on
minute details of floating point. It is poor code in exactly the same way
that
Changes by Eric Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
___
Python-bugs-list mailing
Changes by Hagen Fürstenau hfuerste...@gmx.net:
Added file: http://bugs.python.org/file12403/rangehash3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Changes by Hagen Fürstenau hfuerste...@gmx.net:
Removed file: http://bugs.python.org/file12401/rangehash2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Other possible wording:
... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``.
--
assignee: marketdickinson - rhettinger
___
Python tracker rep...@bugs.python.org
Muhammad Alkarouri malkaro...@gmail.com added the comment:
2008/12/18 Benjamin Peterson rep...@bugs.python.org:
Benjamin Peterson musiccomposit...@gmail.com added the comment:
I've uploaded a .dmg for 2.6.1 to
http://www.python.org/ftp/python/2.6.1/. Could you please test it?
Just to
Nick Coghlan ncogh...@gmail.com added the comment:
The origin of the unnecessary hashfunc casts is just me following some
of the more specific examples of filling in the tp_hash slot too closely
without checking if the cast was still needed.
I'll apply and backport Hagen's patches to 3.0 soon
New submission from Philip Jenvey pjen...@users.sourceforge.net:
Python 2.6's new msvc9compiler misbehaves when it can't find a compiler
(actually a utility of the missing compiler) in its query_vcvarsall() --
it raises an IOError instead of a typical distutils error
build tools expect a
Changes by Miki Tebeka miki.teb...@gmail.com:
--
nosy: -tebeka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4017
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
OK, the discrepancy with bytearray turns out to be fairly
straightforward: bytearray overrides the comparison operations, so
inheritance of the default object.__hash__ is automatically blocked.
range() objects don't support comparison, so they
Changes by Leo M leoofb...@gmail.com:
--
nosy: -leoofborg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4017
___
___
Python-bugs-list mailing
Mark Dickinson dicki...@gmail.com added the comment:
... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``.
I guess that could work.
One other thing: the docs for the trunk seem to suggest that we should
be using trunc here, rather than int. I'm looking at:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Patch looks good to me.
--
nosy: +amaury.forgeotdarc
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
Changes by Barry A. Warsaw ba...@python.org:
--
priority: high - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4580
___
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Fixed in r67859 (trunk), r67860 (py3k) and r67861 (3.0)
Thanks for the report!
--
nosy: +amaury.forgeotdarc
resolution: - fixed
status: open - closed
___
Python tracker
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I agree with the patch, except that DistutilsPlatformError seems more
appropriate - this function is called when the compiler object is
configured, before it is used to actually compile files.
--
nosy: +amaury.forgeotdarc
saa p5t...@saaworld.com added the comment:
Notes on the problem.
The Python mmap documentation says: If length is 0, the maximum length
of the map will be the current size of the file when mmap is called.
Currently, on a system where off_t is 64-bit and size_t is 32-bit, if
the size of the
Ohmi b...@ieee.org added the comment:
Installed on 10.5.6, IDLE ran correctly.
Nicely done.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4017
___
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Reopening: the user did not choose the -n option; this option is
always set when using edit with IDLE Windows shell command.
--
resolution: invalid -
status: closed - open
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, xrange() is hashable in Py2.6. I believe it was intended that
that carry over to Py3.0's range() objects.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
___
Python-bugs-list mailing list
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4533
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4565
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1717
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4604
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4617
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4228
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3248
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3767
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1706039
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4561
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: deferred blocker - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4449
___
Terry J. Reedy tjre...@udel.edu added the comment:
I am puzzled as to what you think is missing in the manual.
Bytes and Byte Array Methods
Bytes and bytearray objects, being “strings of bytes”, have all methods
found on strings, with the exception of encode(), format() and
isidentifier(),
New submission from Roger rdcol...@gmail.com:
Summary: Sample code for enumerate contains a syntax error. The same
code reads:
for i, season in enumerate(['Spring', 'Summer', 'Fall', 'Winter')]:
... print(i, season)
Where the parenthesis and square bracket to the left of the colon in the
Benjamin Peterson musiccomposit...@gmail.com added the comment:
Thanks for the report! Fixed in r67865.
--
nosy: +benjamin.peterson
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4703
John Machin sjmac...@users.sourceforge.net added the comment:
Terry, you are right. I missed that. My report was based on looking via
the index and finding only (str method), no (byte[sarray] method).
___
Python tracker rep...@bugs.python.org
saa p5t...@saaworld.com added the comment:
Ok, put a fork in me, 'cuz I'm done with this. The latest is that
mmap.size() is defined to return the size of the file and not the size
of the data. It tries to return it as a ssize_t, which of course, on
systems where off_t is 64-bits and ssize_t
Nick Coghlan ncogh...@gmail.com added the comment:
It has been pointed out to me that xrange() objects are hashable in 2.x,
and since these range objects are immutable, I don't believe there is
any driving reason for them not to be hashable.
At that point the question becomes one of why
Nick Coghlan ncogh...@gmail.com added the comment:
Bumping to release blocker for 3.0.1 - until I understand this better,
I'm not sure if the xrange-range hashing behaviour change between 2.x
and 3.x is a type specific problem or a general issue in the
implementation of the new approach to
54 matches
Mail list logo