Re: [Python-Dev] [Windows, buildbot] kill_python.c mystery
Didn't you know that you signed in to run arbitrary viruses, worms, and trojan horses when you added your machine to the buildbot infrastructure :-? You just haven't seen buildbot erasing your hard disk and filling your coffee machine with tea, yet. VMware Server is free. Run buildbots in a VM. (but don't assume a VM protects you from trojans that are designed to break out of it) -g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid test suite failing
On 7/27/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, Jul 27, 2006 at 05:40:57PM +0200, Georg Brandl wrote: The UUID test suite, which wasn't run by regrtest.py until now, is now failing on some buildbots (and my machine). This should be fixed before releasing something. Looking at the failures, there seem to be two problems on Unix variants: 1) on some, '/sbin/ifconfig' prints a help message; you need 'ifconfig -a' to print information about all interfaces. 2) on Solaris 9 (the only version in the SF compile farm), I can't figure out how to make ifconfig print MAC addresses at all. Searching online finds the incantation 'arp hostname' to print the MAC. This is such a mess. There are so many different ways of determining the MAC addr on each flavour of Unix it seems hopeless to try. I fixed _ifconfig_getnode so it should work on at least: Linux, Tru64, Solaris, and HP-UX. Who knows how many more variations there are. This only fixes 1 of the 2 failures in test_uuid. The other one is due to _unixdll_getnode() failing. This is because _uuid_generate_time is None because we couldn't find it in the uuid library. This is just broken, not sure if it's the code or the test though. We should handle the case if _uuid_generate_time and the others are None better. I don't know what to do in this case. Since getnode ignores exceptions, maybe it's the test that is broken? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bad interaction of __index__ and sequence repeat
Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. This means that the above problem exists with all sequences, not just strings, given enough RAM to create such sequences with 2147483647 items. For reference, in 2.4 we correctly get an OverflowError. Argh! What should be done about it? A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 28, 2006, at 1:39 AM, Anthony Baxter wrote: I've been thinking the same thing, too. A quick chat to Neal says that he also agrees. There's still a lot more bugs popping up than I'm really comfortable with. I guess this is inevitable - there's a lot of new stuff in 2.5. Does anyone disagree with making the next release beta3? +1. It would give me more type to port and test a few of my applications to the new version. FWIW, our commercial app went pretty smoothly, mostly dealing with Py_ssize_t conversions and adopting the new PySet C API. I'm still working on Mailman but the most painful thing so far has been the conversion of exceptions to new-style classes, and even that wasn't / too/ painful. I've only done limited testing of both, but I'm encouraged that the porting effort will be minor (probably no more than a day's worth of work for both apps combined). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRMoJonEjvBPtnXfVAQJOjAP9HRbakdb39IOtFxGX/wP4QhiXAcNAbXXM hGFIJ6vC0Gp/SSlTVMYPF5oJMIzuDCIDzs4Nrbgysgfj6Ehyphei/ed8W94PHLat nh54Y0N5pvwLelHW6ChJBcIxulU8Fuj0Z9kIZCLiryTOAyXTh+t3+gZPEzWRY/tY v2hd9ERXDl8= =vK7s -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] patching pydoc?
i have a problem with pydoc in rpyc. i wanted help(obj), where obj
is a NetProxy object, to work as if it were local.
i followed the code starting from site.help to pydoc.doc, which is the
ultimate function that generates and prints the text. i expected there
would be some function in the middle that prepares the text, and
another that writes it to the pager, but to my disappointment pydoc.doc
does both.
this means i can't transfer the document to my local machine (it's
printed directly to the remote console).
therefore, i would like to split this behavior into two parts:
* render_doc - a function that returns the document text
* doc - a function that calls render_doc and sends it to the pager
this way no existing code breaks (no existing function signatures
are changed) and i gain help on remote objects.
i hope people would be in favor, as it's not such a big change anyway.
is it possible to add to 2.5?
-tomer
this is the code of pydoc, starting at line 1457
def doc(thing, title='Python Library Documentation: %s', forceload=0):
Display text documentation, given an object or a path to an object.
try:
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
pager(title % desc + '\n\n' + text.document(object, name))
except (ImportError, ErrorDuringImport), value:
print value
this is the suggested code
def render_doc(thing, title='Python Library Documentation: %s', forceload=0):
generate the text
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
return title % desc + '\n\n' + text.document(object, name)
def doc(*args, **kwargs):
Display text documentation, given an object or a path to an object.
try:
text = render_doc(*args, **kwargs)
pager(text)
except (ImportError, ErrorDuringImport), value:
print value
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Another uuid problem
I just tried building and testing 2.5 on a Solaris 10 box at work. The uuid test failed with sh: ifconfig: not found sh: ifconfig: not found sh: ifconfig: not found sh: arp: not found sh: ifconfig: not found sh: ifconfig: not found sh: ifconfig: not found sh: arp: not found In our environment at least it's uncommon for /usr/sbin to be in the PATH of non-privileged users: piggy:% type -a ifconfig -bash: type: ifconfig: not found piggy:% PATH=$PATH:/usr/sbin type -a ifconfig ifconfig is /usr/sbin/ifconfig Perhaps test_uuid needs to do a little investigation to find ifconfig and arp. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Armin Rigo wrote: Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. Clipping the result sounds like it would *never* be a good idea. What was the rationale for that? It should throw an exception. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid test suite failing
On 7/28/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 7/27/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, Jul 27, 2006 at 05:40:57PM +0200, Georg Brandl wrote: The UUID test suite, which wasn't run by regrtest.py until now, is now failing on some buildbots (and my machine). This should be fixed before releasing something. Looking at the failures, there seem to be two problems on Unix variants:1) on some, '/sbin/ifconfig' prints a help message; you need 'ifconfig -a' to print information about all interfaces.2) on Solaris 9 (the only version in the SF compile farm), I can't figure out how to make ifconfig print MAC addresses at all. Searching online finds the incantation 'arp hostname' to print the MAC.This is such a mess.There are so many different ways of determiningthe MAC addr on each flavour of Unix it seems hopeless to try.Ifixed _ifconfig_getnode so it should work on at least:Linux, Tru64, Solaris, and HP-UX.Who knows how many more variations there are.This only fixes 1 of the 2 failures in test_uuid.The other one isdue to _unixdll_getnode() failing.This is because_uuid_generate_time is None because we couldn't find it in the uuid library.This is just broken, not sure if it's the code or the testthough.We should handle the case if _uuid_generate_time and theothers are None better.I don't know what to do in this case.Since getnode ignores exceptions, maybe it's the test that is broken? My 2 cents: since there is no POSIX standard for getting a list of network interfaces, trying to account for all the platform variations is one central location is hopeless. Instead, I think the onus should be on whomever is testing this on a particular platform -- in short, on the buildbot maintainer on that platform. There could be another regrtest.py-type suite, something like platform_regrtest.py for example, which could be composed of highly platform-dependent tests such as test_uuid.py. These tests would have empty methods such as _ifconfig_getnode, which would then be defined on a per-platform basis by the buildbot maintainer on that platform. The test would obviously fail by default, unless those methods are properly defined. Or these methods could account for just one platform, as an example of what to do on other platforms. Grig ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
David Hopwood [EMAIL PROTECTED] writes: Armin Rigo wrote: Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. Clipping the result sounds like it would *never* be a good idea. What was the rationale for that? It should throw an exception. Why would you expect range(10)[:2**32-1] and range(10)[:2**32] to do different things? Cheers, mwh -- This makes it possible to pass complex object hierarchies to a C coder who thinks computer science has made no worthwhile advancements since the invention of the pointer. -- Gordon McMillan, 30 Jul 1998 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
David Hopwood wrote: Armin Rigo wrote: Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. Clipping the result sounds like it would *never* be a good idea. What was the rationale for that? It should throw an exception. A simple demonstration of the clipping behaviour that works on machines with limited memory: (2**100).__index__() 2147483647 (-2**100).__index__() -2147483648 PEP 357 doesn't even mention the issue, and the comment on long_index in the code doesn't give a rationale - it just notes that the function clips the result. Neither the PyNumber_AsIndex nor the __index__ documentation mention anything about the possibility of clipping, and there's no test case to verify this behaviour. I'm inclined to call it a bug, too, but I've cc'ed Travis to see if he can shed some light on the question - the implementation of long_index explicitly suppresses the overflow error generated by _long_as_ssize_t, so the current behaviour appears to be deliberate. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
At 07:33 AM 7/28/2006 +0200, Martin v. Löwis wrote: Phillip J. Eby wrote: I'm willing to write code that makes it PEP 302 compliant, if the release manager will bless such an addition. But if that's not acceptable, then somebody needs to produce the necessary documentation updates or revert the patch. It absolutely should not be allowed to remain in *and* undocumented because it is a backwards-incompatible change to documented behavior of Python for two major releases (2.3 and 2.4). You don't need a release manager pronouncement for that. It's a bug, changing it is a bug fix, you don't need RM permission to fix a bug. Do you have a patch ready that restores path_importer_cache behavior, yet preserves the property that it caches existence of a directory? If not, I will have to produce one. The issue is that a proper fix that caches existence requires adding new types to import.c and thus might appear to be more of a feature. I was therefore reluctant to embark upon the work without some assurance that it wouldn't be rejected as adding a last-minute feature. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Michael Hudson wrote: David Hopwood [EMAIL PROTECTED] writes: Armin Rigo wrote: Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. Clipping the result sounds like it would *never* be a good idea. What was the rationale for that? It should throw an exception. Why would you expect range(10)[:2**32-1] and range(10)[:2**32] to do different things? In that case, I believe it is the slice object that should be suppressing the overflow error (via PyErr_Occurred and PyErr_Matches) when calculating the indices for a given length, rather than having silent clipping be part of the basic implementation of long.__index__(). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
[Armin Rigo] There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. ? I don't see an invocation of __index__ or nb_index in PySequence_Repeat. To the contrary, its /incoming/ `count` argument is constrained to Py_ssize_t from the start: PyObject * PySequence_Repeat(PyObject *o, Py_ssize_t count) ... OK, I think you mean sequence_repeat() in abstract.c. That does invoke nb_index. But, as below, I don't think it should in this case. However, __index__ is defined to clip the result to fit in a Py_ssize_t. This means that the above problem exists with all sequences, not just strings, given enough RAM to create such sequences with 2147483647 items. For reference, in 2.4 we correctly get an OverflowError. Argh! What should be done about it? IMO, this is plain wrong. PEP 357 isn't entirely clear, but it is clear the author only had /slicing/ in mind (where clipping makes sense -- and which makes `__index__` a misleading name). Guido pointed out the ambiguity here: http://mail.python.org/pipermail/python-dev/2006-February/060624.html There's also an ambiguity when using simple indexing. When writing x[i] where x is a sequence and i an object that isn't int or long but implements __index__, I think i.__index__() should be used rather than bailing out. I suspect that you didn't think of this because you've already special-cased this in your code -- when a non-integer is passed, the mapping API is used (mp_subscript). This is done to suppose extended slicing. The built-in sequences (list, str, unicode, tuple for sure, probably more) that implement mp_subscript should probe for nb_index before giving up. The generic code in PyObject_GetItem should also check for nb_index before giving up. So, e.g., plain a[i] shouldn't use __index__ either if i is already int or long. I don't see any justification for invoking nb_index in sequence_repeat(), although if someone thinks it should, then as for plain indexing it certainly shouldn't invoke nb_index if the incoming count is an int or long to begin with. Ah, fudge. Contrary to Guido's advice above, I see that PyObject_GetItem() /also/ unconditionally invokes nb_index (even when the incoming key is already int or long). It shouldn't do that either (according to me). OTOH, in the long discussion about PEP 357, I'm not sure anyone except Travis was clear on whether nb_index was meant to apply only to sequence /slicing/ or was meant to apply everywhere an object gets used in an index-like context. Clipping makes sense only for the former, but it looks like the implementation treats it more like the latter. This was probably exacerbated by: http://mail.python.org/pipermail/python-dev/2006-February/060663.html [Travis] There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. [Guido] Right, absolutely. This is a mess :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On 7/28/06, Michael Hudson [EMAIL PROTECTED] wrote: Anthony Baxter [EMAIL PROTECTED] writes: Does anyone disagree with making the next release beta3? It seems like a good idea to me. I guess this will mean the final release will be pushed back a bit? Anthony and I talked about still having b3 on Aug 1. rc1 around Aug 17-18 (just before the Google sprint which Martin, Jeremy and I will be attending). Final around 24-29. We didn't discuss with Martin yet, so these dates are quite tentative. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Argh. I also find it a bug. I also feel responsible because I reviewed the patch. :-( In my recollection I tried to avoid this exact behavior. I wanted __index__() to just return the unclipped int or long value, but have a C API that clipped it for use in slice operations. It looks like I failed (the patch went through so many revisions that at some point I must've stopped caring). --Guido On 7/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: David Hopwood wrote: Armin Rigo wrote: Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with = 2GB of RAM: s = 'x' * (2**100) # works! len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. Clipping the result sounds like it would *never* be a good idea. What was the rationale for that? It should throw an exception. A simple demonstration of the clipping behaviour that works on machines with limited memory: (2**100).__index__() 2147483647 (-2**100).__index__() -2147483648 PEP 357 doesn't even mention the issue, and the comment on long_index in the code doesn't give a rationale - it just notes that the function clips the result. Neither the PyNumber_AsIndex nor the __index__ documentation mention anything about the possibility of clipping, and there's no test case to verify this behaviour. I'm inclined to call it a bug, too, but I've cc'ed Travis to see if he can shed some light on the question - the implementation of long_index explicitly suppresses the overflow error generated by _long_as_ssize_t, so the current behaviour appears to be deliberate. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: patching pydoc?
submitted patch:
https://sourceforge.net/tracker/?func=detailatid=305470aid=1530482group_id=5470
-tomer
-- Forwarded message --
From: tomer filiba [EMAIL PROTECTED]
Date: Jul 28, 2006 3:35 PM
Subject: patching pydoc?
To: python-dev@python.org
i have a problem with pydoc in rpyc. i wanted help(obj), where obj
is a NetProxy object, to work as if it were local.
i followed the code starting from site.help to pydoc.doc, which is the
ultimate function that generates and prints the text. i expected there
would be some function in the middle that prepares the text, and
another that writes it to the pager, but to my disappointment pydoc.doc
does both.
this means i can't transfer the document to my local machine (it's
printed directly to the remote console).
therefore, i would like to split this behavior into two parts:
* render_doc - a function that returns the document text
* doc - a function that calls render_doc and sends it to the pager
this way no existing code breaks (no existing function signatures
are changed) and i gain help on remote objects.
i hope people would be in favor, as it's not such a big change anyway.
is it possible to add to 2.5?
-tomer
this is the code of pydoc, starting at line 1457
def doc(thing, title='Python Library Documentation: %s', forceload=0):
Display text documentation, given an object or a path to an object.
try:
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
pager(title % desc + '\n\n' + text.document(object, name))
except (ImportError, ErrorDuringImport), value:
print value
this is the suggested code
def render_doc(thing, title='Python Library Documentation: %s', forceload=0):
generate the text
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
return title % desc + '\n\n' + text.document(object, name)
def doc(*args, **kwargs):
Display text documentation, given an object or a path to an object.
try:
text = render_doc(*args, **kwargs)
pager(text)
except (ImportError, ErrorDuringImport), value:
print value
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Tim Peters wrote: OTOH, in the long discussion about PEP 357, I'm not sure anyone except Travis was clear on whether nb_index was meant to apply only to sequence /slicing/ or was meant to apply everywhere an object gets used in an index-like context. Clipping makes sense only for the former, but it looks like the implementation treats it more like the latter. This was probably exacerbated by: http://mail.python.org/pipermail/python-dev/2006-February/060663.html [Travis] There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. [Guido] Right, absolutely. This is a mess :-) I've been trawling through the code a bit, and I don't think it's as bad as all that. All I believe is really needed is to: - remove the PyErr_Occurred() check and its body from long_index in longobject.c - add a PyErr_Occurred() check to force a -1 return from PyNumber_Index in abstract.c - add a PyErr_Occurred() and PyErr_ExceptionMatches(PyOverflowError) check to invoke PyErr_Clear() in _PyEval_SliceIndex in ceval.c. Add test cases to test_index.py to check that: (2**100).__index__() == 2**100 (-2**100).__index__() == -2**100 slice(-2**100, 2**100).indices(sys.maxint) == (0, sys.maxint, 1) a * 2**100 raises OverflowError Add test cases to test_operator.py to check that: operator.index(2**100) == 2**100 operator.index(-2**100) == -2**100 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Nick Coghlan wrote: Tim Peters wrote: OTOH, in the long discussion about PEP 357, I'm not sure anyone except Travis was clear on whether nb_index was meant to apply only to sequence /slicing/ or was meant to apply everywhere an object gets used in an index-like context. Clipping makes sense only for the former, but it looks like the implementation treats it more like the latter. This was probably exacerbated by: http://mail.python.org/pipermail/python-dev/2006-February/060663.html [Travis] There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. [Guido] Right, absolutely. This is a mess :-) I've been trawling through the code a bit, and I don't think it's as bad as all that. Damn, it really is a mess. . . nb_index returns the Pyssize_t directly, and a whole heap of the code expects errors to be signalled via returning -1 before checking PyErr_Occurred(). To get it to work without clipping everywhere, wrap_lenfunc (typeobject.c), _PyEval_SliceIndex (ceval.c), PyNumber_Index (abstract.c) and sequence_repeat (abstract.c) all had to be modified to recognize PY_SSIZE_T_MIN and PY_SSIZE_T_MAX as potential error flags (in order to clear the overflow error for _PyEval_SliceIndex, and in order to propagate the exception for the other three). And using this approach still means that (2**100).__index__() raises an OverflowError. It would probably be cleaner to change the signature of nb_index to return a PyObject *, and let the code that uses it worry about how (or even whether!) to convert PyLong results to a Py_ssize_t. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patching pydoc?
tomer filiba [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
...
therefore, i would like to split this behavior into two parts:
* render_doc - a function that returns the document text
* doc - a function that calls render_doc and sends it to the pager
this way no existing code breaks (no existing function signatures
are changed) and i gain help on remote objects.
i hope people would be in favor, as it's not such a big change anyway.
is it possible to add to 2.5?
Giving the amount of hair-tearing over uuid and __index__, this seems like
an especially bad day to ask for a new-feature variance in a time of
feature freeze ;-).
Some quick questions:
* I presume you gain the new functionality by directly calling the
factored-out render_doc and printing thru your own pager. Does everyone?
* Would making pager() a parameter of doc() make sense?
* Is pager() the only part of the original doc() that can generate
ImportError, ErrorDuringImport? If not, the try/except should be in
render_doc also or instead.
* Why generalize the doc() signature? Bad calls will be traced as caught
in render_doc instead of doc. Couldn't that potentially break a bad_call
test?
Terry Jan Reedy
this is the code of pydoc, starting at line 1457
def doc(thing, title='Python Library Documentation: %s', forceload=0):
Display text documentation, given an object or a path to an
object.
try:
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
pager(title % desc + '\n\n' + text.document(object, name))
except (ImportError, ErrorDuringImport), value:
print value
this is the suggested code
def render_doc(thing, title='Python Library Documentation: %s',
forceload=0):
generate the text
object, name = resolve(thing, forceload)
desc = describe(object)
module = inspect.getmodule(object)
if name and '.' in name:
desc += ' in ' + name[:name.rfind('.')]
elif module and module is not object:
desc += ' in module ' + module.__name__
if not (inspect.ismodule(object) or
inspect.isclass(object) or
inspect.isroutine(object) or
isinstance(object, property)):
# If the passed object is a piece of data or an instance,
# document its available methods instead of its value.
object = type(object)
desc += ' object'
return title % desc + '\n\n' + text.document(object, name)
def doc(*args, **kwargs):
Display text documentation, given an object or a path to an
object.
try:
text = render_doc(*args, **kwargs)
pager(text)
except (ImportError, ErrorDuringImport), value:
print value
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
On 7/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: Nick Coghlan wrote: Tim Peters wrote: OTOH, in the long discussion about PEP 357, I'm not sure anyone except Travis was clear on whether nb_index was meant to apply only to sequence /slicing/ or was meant to apply everywhere an object gets used in an index-like context. Clipping makes sense only for the former, but it looks like the implementation treats it more like the latter. This was probably exacerbated by: http://mail.python.org/pipermail/python-dev/2006-February/060663.html [Travis] There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. [Guido] Right, absolutely. This is a mess :-) I've been trawling through the code a bit, and I don't think it's as bad as all that. Damn, it really is a mess. . . nb_index returns the Pyssize_t directly, and a whole heap of the code expects errors to be signalled via returning -1 before checking PyErr_Occurred(). To get it to work without clipping everywhere, wrap_lenfunc (typeobject.c), _PyEval_SliceIndex (ceval.c), PyNumber_Index (abstract.c) and sequence_repeat (abstract.c) all had to be modified to recognize PY_SSIZE_T_MIN and PY_SSIZE_T_MAX as potential error flags (in order to clear the overflow error for _PyEval_SliceIndex, and in order to propagate the exception for the other three). And using this approach still means that (2**100).__index__() raises an OverflowError. It would probably be cleaner to change the signature of nb_index to return a PyObject *, and let the code that uses it worry about how (or even whether!) to convert PyLong results to a Py_ssize_t. No time to look through the code here, but IMO it's acceptable (at least for 2.5) if (2**100).__index__() raises OverflowError, as long as x[:2**100] silently clips. __index__() is primarily meant to return a value useful for indexing concrete sequences, and 2**100 isn't. Certainly the exception is preferrable to the silently truncated result currently returned. Fortunately there's some extra time since we're now going to do a third beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
[Tim] ... This is a mess :-) [Nick Coghlan] I've been trawling through the code a bit, and I don't think it's as bad as all that. [also Nick, but older wiser ;-)] Damn, it really is a mess. . . nb_index returns the Pyssize_t directly, Bingo. It's a /conceptual/ mess. Best I can make out, Travis only cared about sequence slicing (not indexing), and then the machinery got hijacked to become a more general can you faithfully act like an integer? thing -- but kept a signature that made sense only for the original slicing use (where clipping is fine). and a whole heap of the code expects errors to be signalled via returning -1 before checking PyErr_Occurred(). To get it to work without clipping everywhere, wrap_lenfunc (typeobject.c), _PyEval_SliceIndex (ceval.c), PyNumber_Index (abstract.c) and sequence_repeat (abstract.c) all had to be modified to recognize PY_SSIZE_T_MIN and PY_SSIZE_T_MAX as potential error flags (in order to clear the overflow error for _PyEval_SliceIndex, and in order to propagate the exception for the other three). And using this approach still means that (2**100).__index__() raises an OverflowError. It would probably be cleaner to change the signature of nb_index to return a PyObject *, Given that the more-general use is what everyone else either wanted, or simply /assumed/, in the original discussions, I expect it would be, although with the understanding that the PyObject * returned must be NULL (in case of error), or a Python int or long. and let the code that uses it worry about how (or even whether!) to convert PyLong results to a Py_ssize_t. A utility function or two could help, like one that converted to Py_ssize_t with clipping, and another that did the same but raised OverflowError if Py_ssize_t isn't big enough (and in the latter case a caller would do the usual business of checking for a -1 return and PyErr_Occurred()).. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
Armin Rigo wrote: In the same spirit, maybe it could be slightly re-oriented towards a dumper/loader for more than config files; for example, it could provide a safe inverse of repr() for common built-in types New version of miniconf (version 1.2.0) is out [1][2], including a unrepr() function; that's the only change this time. Michael Foord wrote: ConfigObj [3] gained an 'unrepr' mode a while back. The code is simple, and originally came from CherryPy. Thanks for the link! I completely missed ConfigObj. It indeed shares a lot with my code. At the core, it use many of the same ideas and implementation techniques... In many ways, it is also a lot more advanced, specialized than miniconf: for instance, it introduce a new, specialized Config File format, while my effort aimed at keeping things minimal. Armin Rigo wrote: If it goes in that direction, I'd suggest to rename the module to give it a name closer to existing persistence-related modules already in the stdlib. I am not especially fond of the current miniconf name either; I didn't find something more suitable, yet evocative of what it does; I would be glad to hear any suggestion you or the rest of the developers would have. Yours, -- Sylvain [EMAIL PROTECTED] The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying. [1]http://cheeseshop.python.org/pypi?:action=displayname=miniconfversion=1.2.0 [2]http://sourceforge.net/tracker/index.php?func=detailaid=1527597group_id=5470atid=355470 [3]http://www.voidspace.org.uk/python/configobj.html P.-S. I am leaving the civilization (where I have some sort of network access) from July the 29th to August the 13th: I will be glad to address any comment, bug report or suggestion Python developers might want to discuss in the meantime as soon as I will be back. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
Sylvain Fourmanoit wrote: Armin Rigo wrote: In the same spirit, maybe it could be slightly re-oriented towards a dumper/loader for more than config files; for example, it could provide a safe inverse of repr() for common built-in types New version of miniconf (version 1.2.0) is out [1][2], including a unrepr() function; that's the only change this time. Michael Foord wrote: ConfigObj [3] gained an 'unrepr' mode a while back. The code is simple, and originally came from CherryPy. Thanks for the link! I completely missed ConfigObj. It indeed shares a lot with my code. At the core, it use many of the same ideas and implementation techniques... In many ways, it is also a lot more advanced, specialized than miniconf: for instance, it introduce a new, specialized Config File format, while my effort aimed at keeping things minimal. Cool - I made the post so you could reuse the unrepr code, but I'm glad you like ConfigObj. :-) If miniconf can store and restore instances of classes (which I guess it does if you see it as an improvement of pickle ?) then it does more than ConfigObj unrepr mode - which simply allows you to store basic data-types in config files (amongst all the other things it does...). Michael http://www.voidspace.org.uk/python/index.shtml ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
Neal Norwitz wrote: Anthony and I talked about still having b3 on Aug 1. rc1 around Aug 17-18 (just before the Google sprint which Martin, Jeremy and I will be attending). Final around 24-29. We didn't discuss with Martin yet, so these dates are quite tentative. If it doesn't muck-up your workflow, I would like to see all of these dates bumped back by about a week. In particular, it may be too aggressive to expect the __index__ issue be fully resolved by 8/1. Also, I have a few error-traps to add to setobject.c and need to review one of the implementation decisions for str.rpartition(). This weekend, I'll run the head on a few third-party packages to see if their test-suites still pass -- if not, it would be nice to have a bit of time to fix whatever arises. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
On Friday 28 July 2006 00:49, Neal Norwitz wrote: Based on this comment, is it really acceptable to just document a behaviour change? ISTM there should really only be 2 choices: fix 2.5 properly or revert the change. This seemed to be Armin's position. I agree those are the only reasonable solutions. I'd rather see things fixed, but I don't know how much time Phillip has to work on it. I'll be working on the straigtening out the xmlcore issue tonight/tomorrow. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] struct module and coercing floats to integers
It seems that the pre-2.5 struct module has some additional
undocumented behavior[1] that didn't percolate into the new version:
http://python.org/sf/1530559
Python 2.4 and previous will coerce floats to integers when necessary
as such without any kind of complaint:
$ python2.4 -c import struct; print repr(struct.pack('H',
0.))
'\x00\x00'
Python 2.5 refuses to coerce float to int:
$ python2.5 -c import struct; print repr(struct.pack('H',
0.))
Traceback (most recent call last):
File string, line 1, in module
File /Users/bob/src/python/Lib/struct.py, line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for : 'float' and 'long'
The available options are to:
1. Reinstate the pre-2.5 weirdness
2. Reinstate the pre-2.5 weirdness with a DeprecationWarning
3. Break existing code that relies on undocumented behavior (seems
more like a bug than lack of specification)
Either 2 or 3 seems reasonable to me, with a preference for 3 because
none of my code depends on old bugs in the struct module :)
As far as precedent goes, the array module *used* to coerce floats
silently, but it's had a DeprecationWarning since at least Python 2.3
(but perhaps even earlier). Maybe it's time to promote that warning
to an exception for Python 2.5?
[1] The pre-2.5 behavior should really be considered a bug, the
documentation says Return a string containing the values v1, v2, ...
packed according to the given format. The arguments must match the
values required by the format exactly. I wouldn't consider arbitrary
floating point numbers to match the value required by an integer
format exactly. Floats are not in general interchangeable with
integers in Python anyway (e.g. list indexes, etc.).
-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
At 04:07 PM 7/28/2006 -0400, Fred L. Drake, Jr. wrote: On Friday 28 July 2006 00:49, Neal Norwitz wrote: Based on this comment, is it really acceptable to just document a behaviour change? ISTM there should really only be 2 choices: fix 2.5 properly or revert the change. This seemed to be Armin's position. I agree those are the only reasonable solutions. I'd rather see things fixed, but I don't know how much time Phillip has to work on it. I'll be working on the straigtening out the xmlcore issue tonight/tomorrow. I'm testing a semi-final version of the fix now. It's minimally intrusive in that it only adds an imp.NullImporter type to replace the False value, and it keeps None to mean that the built-in import machinery should be used. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
Neal Norwitz wrote: Anthony and I talked about still having b3 on Aug 1. rc1 around Aug 17-18 (just before the Google sprint which Martin, Jeremy and I will be attending). Final around 24-29. We didn't discuss with Martin yet, so these dates are quite tentative. That doesn't work for me. The final release must either happen before Aug 19, or after Sep 9, or somebody else must roll the Windows binaries. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
Phillip J. Eby wrote: The issue is that a proper fix that caches existence requires adding new types to import.c and thus might appear to be more of a feature. I was therefore reluctant to embark upon the work without some assurance that it wouldn't be rejected as adding a last-minute feature. So do you have a patch, or are going to write one? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch Against shutil.copytree Bug
Hello all,
Sourceforge is being anal and won't let me log in.
Attached is a patch for the shutil test, which would pickup bug
[1525866] Bug in shutil.copytree on Windows.
It passes against a bug-fixed shutil [1] on my XP box, and fails on an
un-fixed one.
It only tests basic functionality of copytree. I did add tests that
copystat had worked, but the mtime results were consistently off on
Windows [2] so I removed that test.
I would appreciate it if someone could post this patch to sourceforge.
IMO this bug needs fixing before 2.5 final, the fix is trivial and
shutil.copytree is broken on windows without it.
All the best,
Michael Foord
[1] Bugfix supplied by Thomas Heller and is attached to the sourceforge
bug report.
[2] And consistently off in a weird way FWIW...
76a77,103
def test_copytree_simple(self):
src_dir = tempfile.mkdtemp()
dst_dir = os.path.join(tempfile.mkdtemp(), 'destination')
open(os.path.join(src_dir, 'test.txt'), 'w').write('123')
os.mkdir(os.path.join(src_dir, 'test_dir'))
open(os.path.join(src_dir, 'test_dir', 'test.txt'), 'w').write('456')
#
try:
shutil.copytree(src_dir, dst_dir)
self.assertTrue(os.path.isfile(os.path.join(dst_dir, 'test.txt')))
self.assertTrue(os.path.isdir(os.path.join(dst_dir, 'test_dir')))
self.assertTrue(os.path.isfile(os.path.join(dst_dir, 'test_dir',
'test.txt')))
self.assertEqual(open(os.path.join(dst_dir, 'test.txt')).read(),
'123')
self.assertEqual(open(os.path.join(dst_dir, 'test_dir',
'test.txt')).read(), '456')
finally:
try:
os.remove(os.path.join(src_dir, 'test.txt'))
os.remove(os.path.join(dst_dir, 'test.txt'))
os.remove(os.path.join(src_dir, 'test_dir', 'test.txt'))
os.remove(os.path.join(dst_dir, 'test_dir', 'test.txt'))
os.removedirs(src_dir)
os.removedirs(dst_dir)
except:
pass
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] httplib and bad response chunking
So I accidentally discovered the other day that httplib does not handle a particular type of mangled HTTP response very well. In particular, it tends to blow up with an undocumented ValueError when the server screws up chunked encoding. I'm not the first to discover this, either: see http://www.python.org/sf/1486335 . digression HTTP 1.1 response chunking allows clients to know how many bytes of response to expect for dynamic content, i.e. when it's not possible to include a Content-length header. A chunked response might look like this: 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n0\r\n\r\n which means: 0x0005 bytes in first chunk, which is abcd\n 0x0004 bytes in second chunk, which is abc\n Each chunk size is terminated with \r\n; each chunk is terminated with \r\n; end of response is indicated by a chunk of 0 bytes, hence the \r\n\r\n at the end. Details in RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 /digression Anyways, what I discovered in the wild the other day was a response like this: 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n\r\n i.e. the chunk-size for the terminating empty chunk was missing. This cause httplib.py to blow up with ValueError because it tried to call int(line, 16) assuming that 'line' contained a hex number, when in fact it was the empty string. Oops. IMHO the minimal fix is to turn ValueError into HTTPException (or a subclass thereof); httplib should not raise ValueError just because some server sends a bad response. (The server in question was Apache 2.0.52 running PHP 4.3.9 sending a big hairy error page because the database was down.) Where I'm getting hung up is how far to test this stuff. I have discovered other hypothetical cases of bad chunking that cause httplib to go into an infinite loop or block forever on socket.readline(). Should we worry about those cases as well, despite not having seen them happen in the wild? More annoying, I can reproduce the block forever case using a real socket, but not using the StringIO-based FakeSocket class in test_httplib. Anyways, I've cobbled together a crude hack to test_httplib.py that exposes the problem: http://sourceforge.net/tracker/download.php?group_id=5470atid=105470file_id=186245aid=1486335 Feedback welcome. (Fixing the inadvertent ValueError is trivial, so I'm concentrating on getting the tests right first.) Oh yeah, my patch is relative to the 2.4 branch. Greg -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More tracker demos online
On Wednesday 26 July 2006 13:17, Terry Reedy wrote: Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Currently, we have two running tracker demos online: Roundup: http://efod.se/python-tracker/ Jira: http://jira.python.atlassian.com/secure/Dashboard.jspa What user name and passwords will they accept, if any? For the Roundup tracker at least you should be able to recover your password using your sourceforge email address. Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote: Phillip J. Eby wrote: The issue is that a proper fix that caches existence requires adding new types to import.c and thus might appear to be more of a feature. I was therefore reluctant to embark upon the work without some assurance that it wouldn't be rejected as adding a last-minute feature. So do you have a patch, or are going to write one? Yes, it's checked in as r50916. It ultimately turned out to be simpler than I thought; only one new type (imp.NullImporter) was required. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Travis Oliphant wrote: I say it's a bug that should be fixed. Don't clear the error, raise it. Several people have said this, but I don't think it can work. If you raise an OverflowError in __index__, the slicing code cannot know whether this meant as overflow or underflow (in a signed sense). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] httplib and bad response chunking
On Tue, 25 Jul 2006, Greg Ward wrote: [...] Where I'm getting hung up is how far to test this stuff. Stop when you run out of time ;-) I have discovered other hypothetical cases of bad chunking that cause httplib to go into an infinite loop or block forever on socket.readline(). Should we worry about those cases as well, despite not having seen them happen in the wild? More annoying, I can reproduce the block forever case using a real socket, but not using the StringIO-based FakeSocket class in test_httplib. They have been seen in the wild :-) http://python.org/sf/1411097 The IP address referenced isn't under my control, I don't know if it still provokes the error, but the problem is clear. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patching pydoc?
tomer filiba wrote: i have a problem with pydoc in rpyc. i wanted help(obj), where obj is a NetProxy object, to work as if it were local. i followed the code starting from site.help to pydoc.doc, which is the ultimate function that generates and prints the text. i expected there would be some function in the middle that prepares the text, and another that writes it to the pager, but to my disappointment pydoc.doc does both. this means i can't transfer the document to my local machine (it's printed directly to the remote console). therefore, i would like to split this behavior into two parts: * render_doc - a function that returns the document text * doc - a function that calls render_doc and sends it to the pager this way no existing code breaks (no existing function signatures are changed) and i gain help on remote objects. i hope people would be in favor, as it's not such a big change anyway. is it possible to add to 2.5? -tomer Hi Tomer, This doesn't address your small patch since the following described project is, not complete, will be either be a separate module or package, (if/when it's completed), and because it's more of a complete rewrite than not, would be ready and tested no sooner than 2.6. But you might be interested in taking a look at what I've attempted to do so far. (This is too premature to consider adding to python distribution but maybe after completing, and after it is used in the community it could be a candidate.) I am/was working on cleaning up pydoc by trying to separate the various formating, server, and output routines, because they are currently very much intertwined making enhancing and/or maintaining pydoc more difficult than it could be. This has resulted rewriting most of the top level functions, which after having some success, has been put on hold because I have other things to do that are more immediate at the moment. What I have done (so far) is separate the file pydoc.py into multiple files in order to begin to better organize the code, And rewriting each of those files so they are less interdependent on each other and more complete in them selves with the possibility of putting it back together in a single file or a package at some point. (I'm leaning on it being a package myself.) My attempt has focused on having pydoc create an intermediate xml-tree data structure that is then be used as the source to generate text, html, and other outputs. This separates the introspective and formatting functions of pydoc. The xml to html function mostly work. (some dependency link tags still need to be reimplemented.) Another improvement I've made is having the html server prepend an html search bar to each page which eliminates the need to have a separate TK search window. This makes interactively browsing with pydoc very easy and nice. :-) It also uses a style sheet to format the html pages, making it easier to change colors, indents, fonts, and borders, etc... If you are interested in working on this or would just like to take a look, let me know, I can put it in a zip file and send it to you. It's not as well organized as I would like at the moment, but the xml and html generation functions work. No attempt to create plain text output from the xml has been made yet. I intended to write the xml to text (and paging help) functions from scratch once the html output is complete and fully working. (mostly done) I think it will not be difficult to get the output very similar to the existing pydoc help text form. I'm thinking it may be better to share it at this time rather than let it sit on my hard drive and possibly get waylayed, or worse, forgotten indefinitely. If this is the right approach, and is desirable, maybe it could make a good community project. Possibly someone could post it and/or manage it someplace? It may need a bit more cleaning up before it's ready for that though. Some additional thoughts of why to do this are: I'm hoping there may be a way to run the html server on a web site to generate documentation directly (pydoc-live?) instead of pre-generating html files and placing them on the web site. (Possible?, Has that already been done?) I know pydoc html files are available on line, but I think they are all pregenerated by pydoc first then uploaded. That may be preferred in most cases because it would require less server overhead and be more secure, but live pydocs would give more immediate and dynamic feedback when a project is being updated and changed often. Another far off (and more ambitious 3.0 ?) goal may be to use the pydoc generated xml as a source to insert doc strings and other information directly into the python user manuals. That may improve both the python library manuals as well as the pydoc help information by having them more closely tied together. Inconsistencies would be found sooner. The doc strings could be the brief quick ref
Re: [Python-Dev] patching pydoc?
Giving the amount of hair-tearing over uuid and __index__, this seems like an especially bad day to ask for a new-feature variance in a time of feature freeze ;-). yeah, i guess so. * Would making pager() a parameter of doc() make sense? not at all. * I presume you gain the new functionality by directly calling the factored-out render_doc and printing thru your own pager. Does everyone? i don't quite get the question, but yes, i plan to call render_doc instead of doc, getting the doc text, and printing it on my own console using a pager/whatever. about the signature, okay, it can easily be fixed. i didn't think about that too much. about the other point -- ImportError etc -- i tried to go dumb as much as possible and not make any change that would break something. pydoc is poorly written anyway, and as ron adam noted, there is a need for at least a cleaned-up version of pydoc, or even a redesigned package. and it ought to be a package. it's a module of ~2000 lines. that's way too much for a module. i made the minimal changes needed to separate the generate text part from the generate and display part. and i kept all the semantics in tact (including who handles the errors) and therefore, i don't expect it to break any tests (after restoring the original doc signature, that is). i'd hate to wait for 2.6 for such a small change. today my solution is to replace pydoc.pager by a fake pager that hands over the result. this is of course not thread safe, as multiple threads calling help() would mix their outputs. not very likely, but i'd love to see this code go away asap. thanks for the comments, -tomer From: Terry Reedy tjreedy at udel.edu Subject: Re: patching pydoc? Newsgroups: gmane.comp.python.devel Date: 2006-07-28 18:29:50 GMT (5 hours and 27 minutes ago) tomer filiba tomerfiliba at gmail.com wrote in message news:1d85506f0607280635q3a693682l230c7821dc6f408f at mail.gmail.com... ... therefore, i would like to split this behavior into two parts: * render_doc - a function that returns the document text * doc - a function that calls render_doc and sends it to the pager this way no existing code breaks (no existing function signatures are changed) and i gain help on remote objects. i hope people would be in favor, as it's not such a big change anyway. is it possible to add to 2.5? Giving the amount of hair-tearing over uuid and __index__, this seems like an especially bad day to ask for a new-feature variance in a time of feature freeze ;-). Some quick questions: * I presume you gain the new functionality by directly calling the factored-out render_doc and printing thru your own pager. Does everyone? * Would making pager() a parameter of doc() make sense? * Is pager() the only part of the original doc() that can generate ImportError, ErrorDuringImport? If not, the try/except should be in render_doc also or instead. * Why generalize the doc() signature? Bad calls will be traced as caught in render_doc instead of doc. Couldn't that potentially break a bad_call test? Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] cgi.FieldStorage DOS (sf bug #1112549)
From the initial bugreport (http://sourceforge.net/tracker/index.php? func=detailaid=1112549group_id=5470atid=105470) Various parts of cgi.FieldStorage call its read_lines_to_outerboundary, read_lines and skip_lines methods. These methods use the readline method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a file-data part that consists of a 2GB string composed entirely of x characters (which happens to be something I did that led me to noticing this bug). This bug has been around for about a year but I just worked up a patch yesterday that applies OK against current SVN. It's attached to the issue. Would someone be so kind as to check it in? Guido has already reviewed it, I believe. - C ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Martin v. Löwis wrote: Travis Oliphant wrote: I say it's a bug that should be fixed. Don't clear the error, raise it. Several people have said this, but I don't think it can work. If you raise an OverflowError in __index__, the slicing code cannot know whether this meant as overflow or underflow (in a signed sense). Why not use IndexError for an underflow, and OverflowError for an overflow? -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Eliminating loops
I'm looking for a way of modifying the compiler to eliminate any loops and recursion from code. It's for a high speed data processing application. The alternative is a custom language that is little more than gloryfied assembly. I'd like to be able to use everything else around Python, but we can't allow the users to create more than O(1) complexity. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Eliminating loops
On 7/28/06, Charles Vaughn [EMAIL PROTECTED] wrote: I'm looking for a way of modifying the compiler to eliminate any loops and recursion from code. It's for a high speed data processing application. The alternative is a custom language that is little more than gloryfied assembly. I'd like to be able to use everything else around Python, but we can't allow the users to create more than O(1) complexity. Well, the problem is how are you going to infer how many times to unroll the loop? range() and xrange() can change since they are only built-ins. You would need type inference on some locally defined variable that was set to a syntactically defined atomic type in order to know the proper number of times to unroll the loop and that might not work for your needs (on top of being a pain to write out a list with however many values you want to have the loop iterate over). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Armin Rigo wrote: This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v-sq_repeat. Why does it do that? Shouldn't __index__ only be used for numbers which are going to be used as an index? However, __index__ is defined to clip the result to fit in a Py_ssize_t. Why is it defined to do this instead of raising OverflowError? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Tim Peters wrote: So, e.g., plain a[i] shouldn't use __index__ either if i is already int or long. I don't see any justification for invoking nb_index in sequence_repeat(), although if someone thinks it should, then as for plain indexing it certainly shouldn't invoke nb_index if the incoming count is an int or long to begin with. Hmmm. So that means anything accepting an integer index needs to do its own range checking anyway. So having __index__ do clipping is at best unnecessary and at worst counterproductive, since it could suppress an overflow or range exception that *should* be produced by the code using the index, and would be if it got the equivalent index value as an int or long directly. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Guido van Rossum wrote: In my recollection I tried to avoid this exact behavior. I wanted __index__() to just return the unclipped int or long value, but have a C API that clipped it for use in slice operations. So is there still a chance to fix it? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module and coercing floats to integers
On 7/28/06, Bob Ippolito [EMAIL PROTECTED] wrote:
http://python.org/sf/1530559
[1] The pre-2.5 behavior should really be considered a bug, the
documentation says Return a string containing the values v1, v2, ...
packed according to the given format. The arguments must match the
values required by the format exactly. I wouldn't consider arbitrary
floating point numbers to match the value required by an integer
format exactly. Floats are not in general interchangeable with
integers in Python anyway (e.g. list indexes, etc.).
While it may be a bug, it's not as hard to run into, nor as illogical
as the presentation here makes it sound. The original code[1] took a
float value between 0 and 2, and wanted to use
pack('H', round(value * 32768))
The workaround is a trivial change
pack('H', int(round(value * 32768)))
but the timeframe is less than ideal, as working code will suddenly
stop and recieve only mildly helpful error message. The fact that
round returns a float rather than an int, while intentional, does not
feature prominently in one's mine when the first version yielded the
expected results.
I would appreciate option 2 which retains compatibility but warns that
the construct is bad. I will accept any of the options, as it's clear
that floats don't make sense. It's just unfortunate that the previous
implementation let them through in a way the new implementation does
not.
[1] http://www.sacredchao.net/quodlibet/changeset/3706
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
Michael Urman wrote: The fact that round returns a float rather than an int, while intentional, does not feature prominently in one's mine when the first version yielded the expected results. As an aside, does anyone else think that it would be useful to have a builtin which rounds and converts to an int in one go? Whenever I use round(), I almost always want the result as an int, and making me do it in two steps seems unnecessarily bothersome. Since automatic float-int coercion is being increasingly disallowed, use cases for this are becoming more and more common. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Martin v. Löwis wrote: Travis Oliphant wrote: I say it's a bug that should be fixed. Don't clear the error, raise it. Several people have said this, but I don't think it can work. If you raise an OverflowError in __index__, the slicing code cannot know whether this meant as overflow or underflow (in a signed sense). It can actually, but you have to allow 3 possible error return values from nb_index (-1, PY_SSIZE_T_MIN and PY_SSIZE_T_MAX). This is ugly as hell [1], so I'm going to try to work out a patch that changes the signature of nb_index to return PyObject * (leaving the client code in the core to decide whether to clip, overflow, or leave the result alone). Cheers, Nick. [1] http://www.python.org/sf/1530738 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
Sylvain Fourmanoit wrote: Armin Rigo wrote: If it goes in that direction, I'd suggest to rename the module to give it a name closer to existing persistence-related modules already in the stdlib. I am not especially fond of the current miniconf name either; I didn't find something more suitable, yet evocative of what it does; I would be glad to hear any suggestion you or the rest of the developers would have. pyson :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
