[ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py
Feature Requests item #1476166, was opened at 2006-04-25 18:32
Message generated for change (Comment added) made by phd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
>Assigned to: Georg Brandl (gbrandl)
Summary: Add SeaMonkey to webbrowser.py
Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",
"mozilla-firebird",
"firebird",
"mozilla", "netscape") in the
register_X_browsers().
--
>Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 13:26
Message:
Logged In: YES
user_id=4799
Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after
if sys.platform[:3] == "win":
...
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 20:31
Message:
Logged In: YES
user_id=849994
Added in rev. 45780.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 17:46 Message generated for change (Comment added) made by markshep You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- >Comment By: Mark Sheppard (markshep) Date: 2006-05-03 11:38 Message: Logged In: YES user_id=1512331 Thanks for closing this bug without giving me a chance to follow up! The problem isn't caused by a limitation of my machine - it's got 3 GiB of RAM. I've done some more testing on this and the problem only appears when connected to a server running certain SMB implementations: The local Windows XP machine A remote Windows XP machine Samba 3.0.22 on Linux When connected to servers running the following SMB implementations the problem isn't present: Windows NT 4.0 Server Windows Server 2000 Windows Server 2003 Standard Edition As this error is being returned by the underlying fread() call the proper place for it to be fixed is there, but the chances of Microsoft doing so for Windows XP are negligible. As you're trying to provide a cross-platform language then having to put up with OS's undocumented warts is just part of the job. As it's entirely possible for you to implement a work-around for this problem Python I think you should. One of reasons for using a high level language like Python is to be insulated from system quirks likes this. If you're refusing to smooth over these quirks where possible then you're undermining that reason. The documentation for Python's read() method on a file handle already says "Note that this method may call the underlying C function fread() more than once", so this possibility is already catered for in the documentation. As this problem only affects remotely mounted filesystems the workaround need only be used for such filesystems. You can determine whether or not a drive is a network one by using the GetDriveType() Windows call. -- Comment By: Tim Peters (tim_one) Date: 2006-05-03 02:45 Message: Logged In: YES user_id=31435 Sorry, I'm closing this as "3rd Party, Won't Fix". It's certainly not Python's doing that Microsoft's stdio implementation has peculiar undocumented warts (Python just calls the platform C's fread() here), so at best this is a request for enhancement rather than a Python bug. If there is a bug here, it's Microsoft's bug, and then the proper source for a fix is also Microsoft. This is especially true since the two people who have tried this here don't see the same behavior -- we don't even know what "the bug" is. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-02 20:00 Message: Logged In: YES user_id=21627 I could reproduce the write problem on XPSP2; I get the Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns (from GetLastError). I can't reproduce the fread problem, though: in Python, f.read(90*2**20) just returns with a 90MiB string. So it could be a limitation of your machine (e.g. it might not have enough memory), or of the server machine. I'm hesitant to add a work-around for that into Python if this isn't a system limitation. Performing multiple reads is also bad: what happens if the first read succeeds, and the second one fails? It might be that the system *really* is out of resources. -- Comment By: Mark Sheppard (markshep) Date: 2006-05-02 11:48 Message: Logged In: YES user_id=1512331 I'm running Windows XP. I've been unable to find any documentation about this exact problem - only that fwrite thing. But my testing shows that it works if I do file.read(67076095), but throws an exception with file.read(67076096). I'm not suggesting limiting all reads from Python. All I'm suggesting is that under the hood the Windows implementation of Python's read() call actually uses multiple fread() (or whatever) calls if more than 67076095 bytes need to be read. That's all. No interface changes. -
[ python-Feature Requests-1481036 ] IOBaseError
Feature Requests item #1481036, was opened at 2006-05-03 14:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1481036&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: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: IOBaseError Initial Comment: Maybe there should be a common base Exception class "IOBaseError" for : EnvironmentError(IOError, OSError), EOFError, socket.error, socket.sslerror, ftplib.all_errors, etc. Nice as it and not all IO sublibs have to be imported to catch such errors. See a recent need in patch #1481032 . I have this need very often in mixed IO apps and am forced to except naked (and being exposed to pythonic AttribError's etc. ) -robert -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1481036&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: Open
Resolution: None
>Priority: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19
Message:
Logged In: YES
user_id=1188172
Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448042 ] Defining a class with __dict__ brakes attributes assignment
Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&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: Wont Fix
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment
Initial Comment:
When defining a class with __dict__ attribute, its
instances can't rebind their __dict__ attributes.
--
class C(object): __dict__ = {}
obj = C()
obj.a = object()
import gc
gc.get_referrers(obj.a) # => [{'a': }]
obj.__dict__ = {} # doesn't really bind new __dict__
vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but
without "a"}
obj.a # => (no exception
!)
gc.get_referrers(obj.a) # => [{'a': , '__dict__': {}}]
--
Although neither class nor object has an attribute "a",
it's still accessible. It's also not possible to rebind
__dict__ in that object, as it gets inside real object
attributes dictionary.
This behaviour has been tested on Python 2.2, 2.3 and
2.4, but may as well affect earlier versions.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:39
Message:
Logged In: YES
user_id=849994
Okay, Armin Rigo and zseil convinced me that this is not a bug.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-03-19 13:50
Message:
Logged In: YES
user_id=1326842
Maybe this shows that it is actually a feature?
>>> class C(object):
... pass
...
'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:
>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'
This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.
Since 'type' is an instance of itself, it also has it:
>>> type_dict_descriptor = type.__dict__['__dict__']
And we can see, that it is responsible for creating
the C's __dict__ attribute:
>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True
As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:
>>> type(C.__dict__).__name__
'dictproxy'
Now in your case, you create a class attribute '__dict__':
>>> class D(C):
... __dict__ = {'a': 1}
...
Which basically does something like:
>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
... '__dict__': {'a': 1},
... '__doc__': "set to None by type if not provided",
... '__module__': "globals()['__name__'] if missing",
... '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)
The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:
>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True
What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:
>>> C.__dict__['__dict__']
>>> E.__dict__['__dict__']
{'a': 1}
Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}
Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:
>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2
If you inherit directly from object, which doesn't have
this descriptor:
>>> object.__dict__['__dict__']
Traceback (most recent call last):
File "", line 1, in ?
KeyError: '__dict__'
there would be no way of accesing instance's dictinary.
But since we inherited from class C, we can stil acces it:
>>> C_dict_descriptor.__get__(e)
{'a': 2, '__dict__': {}}
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 17:57
Message:
Logged In: YES
user_id=849994
Reopening. This is a bug, confirmed by Alex Martelli.
--
Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 13:01
Message:
Logged In: YES
user_id=1310227
To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
I
[ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py
Feature Requests item #1476166, was opened at 2006-04-25 14:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Georg Brandl (gbrandl)
Summary: Add SeaMonkey to webbrowser.py
Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",
"mozilla-firebird",
"firebird",
"mozilla", "netscape") in the
register_X_browsers().
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:46
Message:
Logged In: YES
user_id=849994
Done in r45889.
--
Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 09:26
Message:
Logged In: YES
user_id=4799
Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after
if sys.platform[:3] == "win":
...
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:31
Message:
Logged In: YES
user_id=849994
Added in rev. 45780.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib?
Feature Requests item #1472176, was opened at 2006-04-18 09:28
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: "idna" encoding (drawing unicodedata) necessary in httplib?
Initial Comment:
httplib employs the "idna" encoding. that leads to
errors in py2exe/cxfreeze. And if forced into the
installer, it draws the 400kB+ unicodedata.pyd (on Win)
in innocent small apps. Otherwise no normal technical
modules draw the unicodedata.
Is that really necessary?
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:03
Message:
Logged In: YES
user_id=849994
Slightly reformatted version of patch applied in rev. 45890.
--
Comment By: kxroberto (kxroberto)
Date: 2006-04-19 09:41
Message:
Logged In: YES
user_id=972995
a patch attached
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-18 09:59
Message:
Logged In: YES
user_id=38388
I agree - in most cases, ASCII will be used for hostnames
(where the idna encoding is being used in httplib).
A little helper function to first try .encode('ascii') and
then revert to .encode('idna') would do wonders.
Patches are welcome !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's
Bugs item #1472191, was opened at 2006-04-18 09:49 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&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.5 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Kuba KoÅczyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'clear' command doesn't clear selected bp's Initial Comment: Pdb 'clear x' command doesn't clear selected breakpoints that are already set: $ ./python -m pdb ../test.py > /home/xyz/python/test.py(3)() -> def t(x): (Pdb) break 5 Breakpoint 1 at /home/xyz/python/test.py:5 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /home/xyz/python/test.py:5 (Pdb) clear 1 No breakpoint numbered 1 (Pdb) ... for i in numberlist: * if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): print 'No breakpoint numbered', i ... Each i is a string and it's compared to 0 and len(...), so condition * is always True. The fix is trivial: * if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)): Fix is in #1472184 -- >Comment By: Georg Brandl (gbrandl) Date: 2006-05-03 18:13 Message: Logged In: YES user_id=849994 Thanks for the report. This is fixed in rev. 45891, 45892(2.4). Additionally, for such small changes please do not file a bug and a patch report. Opening just one bug and attaching the patch is fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1385040 ] compiler module does not detect a syntax error
Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&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: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error
Initial Comment:
import compiler
compiler.parse("def foo(a=1,b): pass")
Gives:
Module(None, Stmt([Function(None, 'foo', ['a', 'b'],
[Const(1)], 0, None, Stmt([Pass()]))]))
However, the python interpreter itself barks for the
same code:
SyntaxError: non-default argument follows default
argument
-Harri
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:19
Message:
Logged In: YES
user_id=849994
Thanks for spotting the quirk.
Applied as rev. 45893. test_compiler passes fine here.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 07:21
Message:
Logged In: YES
user_id=33168
Any reason you do:
not i >= len(nodelist)
instead of:
i < len(nodelist)
?
The patch seems fine if everything passes with -u compiler
test_compiler.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 20:20
Message:
Logged In: YES
user_id=849994
Attaching patch. Please review.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 21:59
Message:
Logged In: YES
user_id=33168
FYI.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1480678 ] mmap tries to truncate special files
Bugs item #1480678, was opened at 2006-05-02 16:56 Message generated for change (Comment added) made by aerojockey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Open Resolution: None Priority: 5 Submitted By: Carl Banks (aerojockey) Assigned to: Nobody/Anonymous (nobody) Summary: mmap tries to truncate special files Initial Comment: One Unix, the resize() method of an mmap object calls ftruncate to also resize the associated file. Problem is, ftruncate fails if the fd refers to a special file. This is a problem for someone trying to resize an anonymous memory map using /dev/zero. Apparently hasn't been fixed in 2.5 (based on SVN and changelogs) but I haven't tested it. -- >Comment By: Carl Banks (aerojockey) Date: 2006-05-03 14:19 Message: Logged In: YES user_id=1515186 Well, since resizing an anonymous array seems a reasonable thing to do, and because it worked in Python 2.3, I presumed that the error was an oversight, and not intended behavior. If it is, in fact, intended behavior, then ok, though I don't agree with it. (It's not as if /dev/zero has fixed size that doesn't change; it's inherently sizeless.) -- Comment By: Tim Peters (tim_one) Date: 2006-05-03 02:13 Message: Logged In: YES user_id=31435 Ya, this isn't a bug: resize() is documented as changing the size of _both_ the map and the file. If the size of the file can't be changed, then of course resize() will fail. aerojockey: can't you simply close your current map and create a new map with the size you want? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-03 01:21 Message: Logged In: YES user_id=33168 I don't understand what the problem is. ISTM if you resize a special file an exception will be raised. Is that not the case? What do you expect to happen? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1481296 ] long(float('nan'))!=0L
Bugs item #1481296, was opened at 2006-05-03 13:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L
Initial Comment:
on all platforms I can test long(float('nan'))=0L
But on maxos X intel long(float('nan'))!=0L
it returns:
0L
This is a problem because:
>>> 344 - long(float('nan'))
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1480678 ] mmap tries to truncate special files
Bugs item #1480678, was opened at 2006-05-02 16:56 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Carl Banks (aerojockey) Assigned to: Nobody/Anonymous (nobody) Summary: mmap tries to truncate special files Initial Comment: One Unix, the resize() method of an mmap object calls ftruncate to also resize the associated file. Problem is, ftruncate fails if the fd refers to a special file. This is a problem for someone trying to resize an anonymous memory map using /dev/zero. Apparently hasn't been fixed in 2.5 (based on SVN and changelogs) but I haven't tested it. -- >Comment By: Tim Peters (tim_one) Date: 2006-05-03 15:02 Message: Logged In: YES user_id=31435 I have to confess I don't know _why_ resize() changes the size of the file too, and think that's a debatable design decision. But when code is working as intended and as documented, by definition that's not "a bug". The reason "it worked" in Python 2.3 is explained in bug 728515: http://www.python.org/sf/728515 As it says there, it was a bug that resize() resized the file on Windows, but neglected to do so on Unixish boxes at the time. That bug was fixed by making it resize the file on Unixish boxes too. Since the intent here is clear (albeit questionable) and documented, I'm closing this as not-a-bug. -- Comment By: Carl Banks (aerojockey) Date: 2006-05-03 14:19 Message: Logged In: YES user_id=1515186 Well, since resizing an anonymous array seems a reasonable thing to do, and because it worked in Python 2.3, I presumed that the error was an oversight, and not intended behavior. If it is, in fact, intended behavior, then ok, though I don't agree with it. (It's not as if /dev/zero has fixed size that doesn't change; it's inherently sizeless.) -- Comment By: Tim Peters (tim_one) Date: 2006-05-03 02:13 Message: Logged In: YES user_id=31435 Ya, this isn't a bug: resize() is documented as changing the size of _both_ the map and the file. If the size of the file can't be changed, then of course resize() will fail. aerojockey: can't you simply close your current map and create a new map with the size you want? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-03 01:21 Message: Logged In: YES user_id=33168 I don't understand what the problem is. ISTM if you resize a special file an exception will be raised. Is that not the case? What do you expect to happen? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1481296 ] long(float('nan'))!=0L
Bugs item #1481296, was opened at 2006-05-03 14:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L
Initial Comment:
on all platforms I can test long(float('nan'))=0L
But on maxos X intel long(float('nan'))!=0L
it returns:
0L
This is a problem because:
>>> 344 - long(float('nan'))
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap
--
>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 15:09
Message:
Logged In: YES
user_id=31435
Try it on Windows and you'll get:
>>> long(float('nan'))
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): nan
Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python. You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1481347 ] parse_makefile doesn't handle $$ correctly
Bugs item #1481347, was opened at 2006-05-03 21:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481347&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: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Han-Wen Nienhuys (hanwen)
Assigned to: Nobody/Anonymous (nobody)
Summary: parse_makefile doesn't handle $$ correctly
Initial Comment:
In Makefiles, a $$ should expand into a literal $
distutils.sysconfig doesn't deal with this.
>>> print open('a.make').read ()
FOO = $${bar} bla bla
>>> sysconfig.parse_makefile ('a.make')
{'FOO': '$ bla bla', 'bar': ''}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481347&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: Open
Resolution: None
Priority: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 06:42
Message:
Logged In: YES
user_id=21627
It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version.
I'd like Gustavo Carneiro to comment.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19
Message:
Logged In: YES
user_id=1188172
Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive
Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.
Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.
A fix would be for python to internally use multiple
reads so as to not exceed this limit.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-05-04 02:18
Message:
Logged In: YES
user_id=31435
markshep: As you discovered, closing the report doesn't
stop you from following up. It just reflects the reality
that I don't consider this to be a Python bug, and am
opposed to trying to worm around it inside Python.
Like many people who have just been burned by a platform
quirk, I think you're over-selling the severity of the
problem while ignoring the costs of worming around it.
Adding piles of Windows-specific code to what's _currently_
a simple and uniform implementation is an ongoing
maintenance headache, not least because that code will stick
around long after the next version of Windows has removed
the cause for it. In the meantime it complicates the code
with obscure platform-specific hacks, reducing the
reliability of the code because it also reduces the code's
clarity. The code can't be sanely tested by Python's
standard test suite either (it apparently requires a Windows
network to provoke, and the test suite assumes no such
thing), and untested hack-code is a horrible idea over time.
While it's true that the docs allow for multiple reads under
the covers, it's talking about cases like file objects
returned by a popen() call or a socket makefile() call when
read() is passed a `size` argument, or when read() is called
with no `size` argument (so it's impossible to know in
advance how large a buffer may be needed to reach EOF). The
entire reading code for an explicitly-sized read on a
genuine file is a single
return fread(buf, 1, n, stream);
call today, and on all platforms.
It doesn't look like this can end with reading either: MS
documents a similar problem with writing, and I expect you
want to see that hacked around too (or, if not, you're
pretty selective ;-)). Pain spreads.
In return, what's the benefit? The fact that it _is_ so
hard to find anything via Google about this strongly
suggests to me that trying to read more than 64MB in one
gulp across a vulnerable Windows combo is mighty rare. If
it happens, the failure isn't silent, an explicit exception
is raised letting the programmer know it didn't work. While
I appreciate that's irritating, it's not a disaster, and a
programmer who cares can worm around it on their own ("so
don't do that -- read < 64MB per gulp yourself").
Obviously, I'm not going to pursue this. Since I'm one of
the few people who "does" Windows code for the core, that
does cut the chance that anyone will. If you want to pursue
it, the best chance is to supply a patch implementing it,
and get someone else to review it. A stronger case could be
made if, e.g., there was evidence that Perl or PHP or Ruby
or VB or C# or ... intend to worm (or have wormed) around it.
--
Comment By: Mark Sheppard (markshep)
Date: 2006-05-03 06:38
Message:
Logged In: YES
user_id=1512331
Thanks for closing this bug without giving me a chance to
follow up!
The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.
I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:
The local Windows XP machine
A remote Windows XP machine
Samba 3.0.22 on Linux
When connected to servers running the following SMB
implementations the problem isn't present:
Windows NT 4.0 Server
Windows Server 2000
Windows Server 2003 Standard Edition
As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.
As you're trying to provide a cross-platform language then
having to put up with OS's undocumented warts is just part
of the job. As it's entirely possible for you to implement
a work-around for this problem Python I think you should.
One of
