[Python-Dev] Mini-Pep: An Empty String ABC
So, apart from compatibility purposes, what is the point currently of *not* directly subclassing str? To provide your own storage format, such as a views into existing data. Whether or not this is actually practical is a different question; plenty C code tends to assume it can use the internals of str directly, which breaks on even some subclasses. -jJ ___ 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] converting the stdlib to str.format
Greg Ewing schrieb:
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
{num} occurs {num} times in this format string.format(dict(num=2))
If named arguments were to become mandatory, I'd want
to be able to write that as
...{num}format(num = 2)
You already are -- in fact, that is the only way this works.
(I'd wondered why nobody brought this error up in this discussion
before. Probably it wouldn't have been ugly enough.)
I don't see a significant speed difference between positional and keyword
arguments to format() when testing with two arguments.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
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] converting the stdlib to str.format
On 06/06/2008, Georg Brandl [EMAIL PROTECTED] wrote: Greg Ewing schrieb: Paul Moore wrote: Because the second breaks if value is a tuple: However, changing it now is going to break a huge amount of existing code that uses %-formatting, and in ways that 2to3 can't reliably fix. Keeping %-formatting but breaking a large proportion of its uses doesn't seem like a good idea to me. Exactly. If % formatting is removed in 3k, code breaks, so we keep it. Changing it now so that code breaks anyway is not productive :) Just to clarify, I'm not advocating change here. My comment (above) about code breaking was in reference to an issue with a chunk of user-level code which got clipped from the quote, and is completely unrelated to any diiscussion of changing Python. Paul. ___ 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] Modules for 2.6 inclusion
Hi, PEP 361 lists the following modules for possible inclusion in 2.6 (next to pyprocessing, which is now accepted): - winerror http://python.org/sf/1505257 (Owner: MAL) This patch has been marked as rejected, so I'll remove the entry from the PEP. - setuptools BDFL pronouncement for inclusion in 2.5: http://mail.python.org/pipermail/python-dev/2006-April/063964.html PJE's withdrawal from 2.5 for inclusion in 2.6: http://mail.python.org/pipermail/python-dev/2006-April/064145.html I guess this will be deferred? - ast http://mail.python.org/pipermail/python-dev/2008-April/078950.html If there's no objection, I'll go over the interface with Thomas, who's working on AST optimization for 2.7, to make sure the ast interface can stay the same after his branch is merged, write the docs and commit it before beta1. - bdist_deb in distutils package http://mail.python.org/pipermail/python-dev/2006-February/060926.html - bdist_egg in distutils package - pure python pgen module (Owner: Guido) Deferral to 2.6: http://mail.python.org/pipermail/python-dev/2006-April/064528.html There are also several other possible todo items in PEP 361, but they all look as if they are not required to be in before beta1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] converting the stdlib to str.format
Greg Ewing schrieb: Paul Moore wrote: Because the second breaks if value is a tuple: However, changing it now is going to break a huge amount of existing code that uses %-formatting, and in ways that 2to3 can't reliably fix. Keeping %-formatting but breaking a large proportion of its uses doesn't seem like a good idea to me. Exactly. If % formatting is removed in 3k, code breaks, so we keep it. Changing it now so that code breaks anyway is not productive :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-06-03 01:29, Gregory P. Smith wrote: On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED] wrote: I will freely admit that I haven't followed this thread in any detail, but if it were up to me, I'd have the 2.6 internal code use PyString ... Should we read this as a BDFL pronouncement and make it so? All that would mean change wise is that trunk r63675 as well as possibly r63672 and r63677 would need to be rolled back and this whole discussion over if such a big change should have happened would turn into a moot point. I would certainly welcome reverting the change. All that's needed to support PyBytes API in 2.x is a set of #defines that map the new APIs to the PyString names. That's a clean and easily understandable solution. Programmers interested in the code for a PyString API can then still look up the code in stringobject.c, e.g. to find out how a certain special case is handled or to check the ref counting - just like they did for years. Developer who want to start differentiating between mixed byte/text data and bytes-only can start using PyBytes for byte data. I would also add macros that map the PyBytes_* APIs to PyString_*, but I would not start using these internally except in code newly written for 2.6 and intended to be in the spirit of 3.0. IOW use PyString for 8-bit strings containing text, and PyBytes for 8-bit strings containing binary data. For 8-bit strings that could contain either text or data, I'd use PyString, in the spirit of 2.x. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 06 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania30 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Modules for 2.6 inclusion
On 2008-06-06 13:27, Georg Brandl wrote: Hi, PEP 361 lists the following modules for possible inclusion in 2.6 (next to pyprocessing, which is now accepted): - winerror http://python.org/sf/1505257 (Owner: MAL) This patch has been marked as rejected, so I'll remove the entry from the PEP. Note that the idea is still valid - the implementation of the module should be written in C and the patch only comes with a Python module. If anyone would like to work on a (generated) C module, please have a look at the patch. winerror is meant to provide access to the Windows error codes which are currently not available in Python. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 06 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania30 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] converting the stdlib to str.format
Nick Coghlan wrote: Greg Ewing wrote: Nick Coghlan wrote: - remove support for passing a single value to a format string without wrapping it in an iterable first But won't that clobber a large number of the simple use cases that you want to keep %-formatting for? Note the part of the proposal that allows *any* iterable on the right hand side rather than the current insistence on a tuple. So the single-value use cases can be boxed easily with a list. To my mind salvaging %-formatting requires removing the ambiguity over whether or not the right hand side will be iterated over. But then this breaks code where iterables are intended to be output using a single %s format specifier, for example. I don't see why this would be regarded as helpful. To avoid breakage I'd rather keep the %-formatting ability as it is, and label it a legacy feature, rather than salvaging it. It's going to be too tricky to convert using 2to3 otherwise. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Modules for 2.6 inclusion
2008/6/6 Georg Brandl [EMAIL PROTECTED]: Hi, PEP 361 lists the following modules for possible inclusion in 2.6 (next to pyprocessing, which is now accepted): - winerror http://python.org/sf/1505257 (Owner: MAL) This patch has been marked as rejected, so I'll remove the entry from the PEP. - setuptools BDFL pronouncement for inclusion in 2.5: http://mail.python.org/pipermail/python-dev/2006-April/063964.html PJE's withdrawal from 2.5 for inclusion in 2.6: http://mail.python.org/pipermail/python-dev/2006-April/064145.html I guess this will be deferred? - ast http://mail.python.org/pipermail/python-dev/2008-April/078950.html If there's no objection, I'll go over the interface with Thomas, who's working on AST optimization for 2.7, to make sure the ast interface can stay the same after his branch is merged, write the docs and commit it before beta1. - bdist_deb in distutils package http://mail.python.org/pipermail/python-dev/2006-February/060926.html - bdist_egg in distutils package - pure python pgen module (Owner: Guido) Deferral to 2.6: http://mail.python.org/pipermail/python-dev/2006-April/064528.html I created an issue 1 week ago (http://bugs.python.org/issue2983) suggesting the addition of the ttk module to lib-tk, and to the new tkinter package. Is there any chance to this be accepted for Python 2.6 ? There are also several other possible todo items in PEP 361, but they all look as if they are not required to be in before beta1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ 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] PEP 371: Additional Discussion
On Thu, Jun 5, 2008 at 10:08 PM, Jesse Noller [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 10:06 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Jesse Noller wrote: I meant a cleaned version of the PEP - I still have docs and tests to redo It would also be good if you could check Benjamin's patch on issue 3402 to give threading a PEP 8 compliant API and make sure the names are the same as the new names in multiprocessing. Cheers, Nick. P.S. OK, now I really am going to be offline for the next few days ;) Good idea, I'll add that to the queue - right now I'm focusing on getting the module into the build on trunk (locally) and getting all of the docs/tests updated and up to par. -jesse Just to follow up - I have added a ticket to the tracker (http://bugs.python.org/issue3050) to track current status and work, as issues are resolve both the ticket and the PEP will be updated to reflect status. I still need to (or have someone with dev privs) add dependencies to issue 3042 and 1683 -jesse ___ 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] converting the stdlib to str.format
+1 On 6/6/08, Steve Holden [EMAIL PROTECTED] wrote: Nick Coghlan wrote: Greg Ewing wrote: Nick Coghlan wrote: - remove support for passing a single value to a format string without wrapping it in an iterable first But won't that clobber a large number of the simple use cases that you want to keep %-formatting for? Note the part of the proposal that allows *any* iterable on the right hand side rather than the current insistence on a tuple. So the single-value use cases can be boxed easily with a list. To my mind salvaging %-formatting requires removing the ambiguity over whether or not the right hand side will be iterated over. But then this breaks code where iterables are intended to be output using a single %s format specifier, for example. I don't see why this would be regarded as helpful. To avoid breakage I'd rather keep the %-formatting ability as it is, and label it a legacy feature, rather than salvaging it. It's going to be too tricky to convert using 2to3 otherwise. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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 -- Sent from Gmail for mobile | mobile.google.com --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] Summary of Python tracker Issues
ACTIVITY SUMMARY (05/30/08 - 06/06/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1895 open (+28) / 12981 closed (+15) / 14876 total (+43) Open issues with patches: 575 Average duration of open issues: 708 days. Median duration of open issues: 1451 days. Open Issues Breakdown open 1872 (+27) pending23 ( +1) Issues Created Or Reopened (45) ___ tkinter, assorted fixes 06/02/08 CLOSED http://bugs.python.org/issue2906reopened gpolo patch, patch PyNumberMethods has left-over fields in Py3 06/02/08 http://bugs.python.org/issue2997reopened georg.brandl patch locale module alias table needs to be updated05/30/08 CLOSED http://bugs.python.org/issue3011created lemburg disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523 05/30/08 CLOSED http://bugs.python.org/issue3012created jameinel disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523 05/30/08 http://bugs.python.org/issue3013created jameinel patch, easy file_dealloc() assumes errno is set when EOF is returned 05/30/08 http://bugs.python.org/issue3014created johansen tkinter with wantobjects=False has been broken for some time 05/30/08 http://bugs.python.org/issue3015created gpolo patch tarfile.py incurs exception from self.chmod() when tarball has g 05/30/08 CLOSED http://bugs.python.org/issue3016created zooko Verify doc updates for the decimal module05/31/08 http://bugs.python.org/issue3017created rhettinger tkinter demos fixed 05/31/08 http://bugs.python.org/issue3018created gpolo patch Python3a5 compile failing due to high memory usage 05/31/08 CLOSED http://bugs.python.org/issue3019created segfaulthunter doctest should have lib2to3 integration 06/01/08 http://bugs.python.org/issue3020created scoder Lexical exception handlers 06/01/08 http://bugs.python.org/issue3021created pitrou patch mailbox module, two small fixes 06/01/08 http://bugs.python.org/issue3022created gpolo patch, patch Problem with invalidly-encoded command-line arguments (Unix) 06/01/08 http://bugs.python.org/issue3023created baikie Integer conversion inconsistent 06/01/08 CLOSED http://bugs.python.org/issue3024created helminthe batch/IDLE differ: print broken for chraractersascii06/01/08 CLOSED http://bugs.python.org/issue3025created jimjjewett mmap broken with large files on 64bit system 06/02/08 http://bugs.python.org/issue3026created donut if extended c module is calling Windows API waitForSingleObject, 06/02/08 CLOSED http://bugs.python.org/issue3027created patrick tokenize module: normal lines, not logical
Re: [Python-Dev] PEP 8 vs PEP 371: Additional Discussion
On Thu, Jun 5, 2008 at 8:19 PM, Jim Jewett [EMAIL PROTECTED] wrote: Guido van Rossum wrote: I consider multiprocessing a new API -- while it bears a superficial resemblance with the threading API the similarities are just that, and it should not be constrained by mistakes in that API. The justification for including it is precisely that it is *not* a new API. It is new in the stdlib. Insofar it is not new, renaming the methods is a very superficial thing. For multiple processes in general, there are competing APIs, which may well be better. The advantage of this API is that (in many cases) it is a drop-in replacement for threading. If that breaks, then there really isn't any reason to include it in the stdlib yet. I've said before, and nobody has disagreed, that while familiarity with the threading module helps people understand how to use the multiprocessing module (as opposed to other APIs, which differ more deeply than just in their method names), but that I don't expect anyone to take an existing multi-threaded app of any complexity and turn it into a multi-processing app by changing one import. This doesn't prevent changing the joint API to conform with PEP 8. But why clean this module while leaving the rest of the stdlib? Have you actually read the thread? Many arguments were put forward for cleaning up the API -- there is no need to perpetuate mistakes of the past when introducing anything new to the stdlib. Because there is a volunteer only makes sense if changes to the other modules would also be welcomed. Is there some reason to believe that changes in the threading API are much less disruptive than changes elsewhere in the stdlib? We'll keep the compatible API as long as needed. This means in 3.0 too. -- --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] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? -- --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] Mini-Pep: Simplifying the Integral ABC
2008/6/6 Guido van Rossum [EMAIL PROTECTED]: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? I have no vested interest either way, but I think someone mentioned creating a long int equivalent based on Decimal earlier in the thread. Wrappers for the gmp library might also want to do this. It's hardly the world's biggest use case, though... Paul. ___ 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] Mini-Pep: Simplifying the Integral ABC
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex ___ 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] on Python's tests (and making them better)
On Thu, 5 Jun 2008, Benjamin Peterson wrote: - reorganizing the tests into separate directories Why this one? 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] on Python's tests (and making them better)
On Fri, Jun 6, 2008 at 2:12 PM, John J Lee [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008, Benjamin Peterson wrote: - reorganizing the tests into separate directories Why this one? I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] Assumed reflexivity of rich comparison operators
Hi all, PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth clause of the proposed resolutions to concerns: The reflexivity rules *are* assumed by Python. Thus, the interpreter may swap yx with xy, y=x with x=y, and may swap the arguments of x==y and x!=y. However, if this is the case, why does Python allow the definition of both pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users have no guarantee over which will be called? Currently, if I do not want x = y to mean the same thing as y = x (and believe it or not I believe I have a good use case for doing this), there is no reliable way of doing this. However, if the decision is to not allow users to do this at all using operators (and force them to create specially named methods), what is the point of allowing the definition of both? It seems very confusing to me (and indeed I was at first very confused what was going on), to tempt users to be able to define both but give no promise that if they do, the appropriate one will be called. Does anyone have a good explanation for this? Thanks! jared ___ 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] Mini-Pep: Simplifying the Integral ABC
On Fri, Jun 6, 2008 at 11:40 AM, Alex Martelli [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; I tried this with ABC in '83. We didn't see any of the hoped-for benefits though. That's why Python has binary long integers. :-) binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? You could just raise an exception. This is common in Java when an Interface requires you implement a method you can't. Or use virtual inheritance from the Integral class and leave them unimplemented. See if anyone cares. :-) -- --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] Assumed reflexivity of rich comparison operators
On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow [EMAIL PROTECTED] wrote: PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth clause of the proposed resolutions to concerns: The reflexivity rules *are* assumed by Python. Thus, the interpreter may swap yx with xy, y=x with x=y, and may swap the arguments of x==y and x!=y. However, if this is the case, why does Python allow the definition of both pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users have no guarantee over which will be called? Currently, if I do not want x = y to mean the same thing as y = x (and believe it or not I believe I have a good use case for doing this), I find it hard to believe that your users will be happy with that though. :-) there is no reliable way of doing this. Does it help if I tell you that for x binop y we always try x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the case where y is an instance of a subclass of the class of x? However, if the decision is to not allow users to do this at all using operators (and force them to create specially named methods), what is the point of allowing the definition of both? The same reason we allow (require) you to define __add__ and __radd_. It is quite possible that for any particular binary operation x binop y, the class of x doesn't know how to implement it, and then the class of y is tried with the reversed operation. It seems very confusing to me (and indeed I was at first very confused what was going on), to tempt users to be able to define both but give no promise that if they do, the appropriate one will be called. Does anyone have a good explanation for this? I have explained it as well as I can. -- --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] Mini-Pep: Simplifying the Integral ABC
In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli [EMAIL PROTECTED] ha scritto: On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex I don't know if you are talking about BCD numbers, but they are quite inefficient and slow in x86 architecture. There are instructions only to add and subtract packed BCD numbers which uses just two decimal digits (packed in two nibbles into a single byte). For unpacked BCDs, there are instructions to add, subtract, multiply and divide numbers, but which uses only one digit at the time. So using packed BCDs to store 8 decimal digits in 32 bits, for example, requires 4 instructions to make addictions or subractions, plus the required shift mask instructions to put every couple digits into the AL register to execute BCD operations. Unpacked BCDs need double of them. Also, these instructions still use microcode to execute on modern processors, slowing down the execution pipeline (most of the simpler instructions do not require microcode, and execute directly). Last but not least, on x86-64 architecture BCD instructions were completely removed from the ISA; opcodes are assigned to new instructions. Obviously, binary operations can be performed twice faster thanks to the 64 bit registers and ALUs. The only practical advantage on using BCD numbers is the conversion-to-string operation, which can be done faster than binary numbers. Binary addition, subtraction, multiplication and division are greatly faster than BCD ones, and should be the preferred way to do integer math. Cesare ___ 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] Mini-Pep: Simplifying the Integral ABC
New idea! I missed an obvious solution. Let the binary methods in Integral be mixins instead of abstract methods. That minimizes the burden on the class implementer while providing maximum support for clients. class Integral(Rational): ... def __lshift__(self, other): self other return long(self) long(other) def __xor__(self, other): self ^ other return long(self) ^ long(other) I worried a bit about changing type, but this kind of thing is already baked into numbers.py: @property def imag(self): Real numbers have no imaginary component. return 0 @property def denominator(self): Integers have a denominator of 1. return 1 Raymond - Original Message - From: Alex Martelli [EMAIL PROTECTED] To: Guido van Rossum [EMAIL PROTECTED] Cc: Raymond Hettinger [EMAIL PROTECTED]; python-dev@python.org Sent: Friday, June 06, 2008 11:40 AM Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex ___ 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] Assumed reflexivity of rich comparison operators
On Jun 6, 2008, at 3:24 PM, Guido van Rossum wrote: On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow [EMAIL PROTECTED] wrote: PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth clause of the proposed resolutions to concerns: The reflexivity rules *are* assumed by Python. Thus, the interpreter may swap yx with xy, y=x with x=y, and may swap the arguments of x==y and x!=y. However, if this is the case, why does Python allow the definition of both pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users have no guarantee over which will be called? Currently, if I do not want x = y to mean the same thing as y = x (and believe it or not I believe I have a good use case for doing this), I find it hard to believe that your users will be happy with that though. :-) In this case, I am my users and I would be very happy with it (but I won't try to justify it :). there is no reliable way of doing this. Does it help if I tell you that for x binop y we always try x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the case where y is an instance of a subclass of the class of x? Yes, actually that explains quite a bit, and now I see that is the case I am dealing with. y is an instance of a subclass of x, but the class of x is the one that defines both the binops. I suppose it is too much to ask to only call the __reverse_binop__ if the subclass overrides it. However, if the decision is to not allow users to do this at all using operators (and force them to create specially named methods), what is the point of allowing the definition of both? The same reason we allow (require) you to define __add__ and __radd_. It is quite possible that for any particular binary operation x binop y, the class of x doesn't know how to implement it, and then the class of y is tried with the reversed operation. It seems very confusing to me (and indeed I was at first very confused what was going on), to tempt users to be able to define both but give no promise that if they do, the appropriate one will be called. Does anyone have a good explanation for this? I have explained it as well as I can. Thanks very much, at least that is enough information to work around reliably. jared ___ 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] Mini-Pep: Simplifying the Integral ABC
Make that int() instead of long() and I'm okay with it. On Fri, Jun 6, 2008 at 1:33 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: New idea! I missed an obvious solution. Let the binary methods in Integral be mixins instead of abstract methods. That minimizes the burden on the class implementer while providing maximum support for clients. class Integral(Rational): ... def __lshift__(self, other): self other return long(self) long(other) def __xor__(self, other): self ^ other return long(self) ^ long(other) I worried a bit about changing type, but this kind of thing is already baked into numbers.py: @property def imag(self): Real numbers have no imaginary component. return 0 @property def denominator(self): Integers have a denominator of 1. return 1 Raymond - Original Message - From: Alex Martelli [EMAIL PROTECTED] To: Guido van Rossum [EMAIL PROTECTED] Cc: Raymond Hettinger [EMAIL PROTECTED]; python-dev@python.org Sent: Friday, June 06, 2008 11:40 AM Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex -- --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] Mini-Pep: Simplifying the Integral ABC
From: Guido van Rossum [EMAIL PROTECTED] Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. 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] Modules for 2.6 inclusion
I created an issue 1 week ago (http://bugs.python.org/issue2983) suggesting the addition of the ttk module to lib-tk, and to the new tkinter package. Is there any chance to this be accepted for Python 2.6 ? Is it complete? In principle, it's for the mentor to decide (who would need to decide before the first beta, of course - afterwards it's for the release manager to decide). 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] on Python's tests (and making them better)
- reorganizing the tests into separate directories Why this one? I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). I personally use grep to find the place where to add a new test. 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] Modules for 2.6 inclusion
2008/6/6 Martin v. Löwis [EMAIL PROTECTED]: I created an issue 1 week ago (http://bugs.python.org/issue2983) suggesting the addition of the ttk module to lib-tk, and to the new tkinter package. Is there any chance to this be accepted for Python 2.6 ? Is it complete? In principle, it's for the mentor to decide (who would need to decide before the first beta, of course - afterwards it's for the release manager to decide). It is complete Martin. But I will wait for Fredrik's decision then, not sure if it will be soon enough tho. Regards, Martin -- -- Guilherme H. Polo Goncalves ___ 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] New Developer
Hi All, I'm a new developer with Python. I have a solid knowledge of both Python and C. Are there any tasks that would be suitable for a beginner to the Python codebase? I haven't been able to find a list of such tasks on python.org or bugs.python.org. Thanks, James Thomas --- On Fri, 6/6/08, [EMAIL PROTECTED] lt;[EMAIL PROTECTED]gt; wrote: From: [EMAIL PROTECTED] lt;[EMAIL PROTECTED]gt; Subject: Python-Dev Digest, Vol 59, Issue 24 To: python-dev@python.org Date: Friday, June 6, 2008, 2:30 PM Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Python-Dev digest...Today's Topics: 1. Re: Assumed reflexivity of rich comparison operators (Guido van Rossum) 2. Re: Mini-Pep: Simplifying the Integral ABC (Cesare Di Mauro) 3. Re: Mini-Pep: Simplifying the Integral ABC (Raymond Hettinger) 4. Re: Assumed reflexivity of rich comparison operators (Jared Flatow) 5. Re: Mini-Pep: Simplifying the Integral ABC (Guido van Rossum) 6. Re: Mini-Pep: Simplifying the Integral ABC (Raymond Hettinger) 7. Re: Modules for 2.6 inclusion (Martin v. L?wis)On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow lt;[EMAIL PROTECTED]gt; wrote: gt; PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth gt; clause of the proposed resolutions to concerns: gt; gt; The reflexivity rules *are* assumed by Python. Thus, the interpreter may gt; swap ygt;x with xlt;y, ygt;=x with xlt;=y, and may swap the arguments of x==y and gt; x!=y. gt; gt; However, if this is the case, why does Python allow the definition of both gt; pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users gt; have no guarantee over which will be called? Currently, if I do not want x gt;gt;= y to mean the same thing as y lt;= x (and believe it or not I believe I gt; have a good use case for doing this), I find it hard to believe that your users will be happy with that though. :-) gt; there is no reliable way of doing this. Does it help if I tell you that for x lt;binopgt; y we always try x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the case where y is an instance of a subclass of the class of x? gt; However, if the decision is to not allow users to do this at all using gt; operators (and force them to create specially named methods), what is the gt; point of allowing the definition of both? The same reason we allow (require) you to define __add__ and __radd_. It is quite possible that for any particular binary operation x lt;binopgt; y, the class of x doesn't know how to implement it, and then the class of y is tried with the reversed operation. gt; It seems very confusing to me (and gt; indeed I was at first very confused what was going on), to tempt users to be gt; able to define both but give no promise that if they do, the appropriate one gt; will be called. Does anyone have a good explanation for this? I have explained it as well as I can. -- --Guido van Rossum (home page: http://www.python.org/~guido/)In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli lt;[EMAIL PROTECTED]gt; ha scritto: gt; On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum lt;[EMAIL PROTECTED]gt; wrote: gt;gt; On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger lt;[EMAIL PROTECTED]gt; wrote: gt;gt;gt; Does anyone actually need an int lookalike with binary methods but gt;gt;gt; cannot just inherit from int? gt;gt; gt;gt; Does anyone actually need an int lookalike with operations like +, - gt;gt; etc. but cannot just inherit from int? If the answer is yes, is there gt;gt; a compelling reason why they wouldn't want to support binary methods gt;gt; as well? gt; gt; Yes, there's a use case for implementing long integers as arrays of gt; decimal digits -- addition is roughly as efficient as for binary gt; integers (x86 chips still have instructions to help with that), and gt; emitting as decimal digits is MUCH more efficient of course -- so if gt; I/O in decimal form is the most common operation, with a little gt; arithmetic (particularly sums), you could gain performance; binary gt; operations, however, would be as inefficient as decimal form gt; conversion is for ordinary binary ints, and not needed for the typical gt; applications that would use these decimal coded integers gt; (accounting), so why not save the implementer of such an extension gt; from having to write that unneeded and slow extra code? gt; gt; gt; Alex I don't know if you are talking about BCD numbers, but they are quite inefficient and slow in x86 architecture. There are instructions only to add and subtract packed BCD numbers which uses just two decimal
Re: [Python-Dev] New Developer
2008/6/6 James Thomas [EMAIL PROTECTED]: Hi All, I'm a new developer with Python. I have a solid knowledge of both Python and C. Are there any tasks that would be suitable for a beginner to the Python codebase? I haven't been able to find a list of such tasks on python.org or bugs.python.org. Welcome! The issue tracker [1] is *the* place to find such tasks! Note that there're some tasks tagged as easy [2], take a look! Next week we'll have a Python Bug Weekend [3], it's a good moment to gain speed. (ah, what is not welcomed are HTML mails) Regards, [1] http://bugs.python.org/ [2] http://www.taniquetil.com.ar/cgi-bin/pytickets.py?nropag=0priority=0severity=0component=0version=0keyword=6 [3] http://wiki.python.org/moin/PythonBugDay -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Mini-Pep: Simplifying the Integral ABC
Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; maybe he remembers? I'm guessing that adding __long__ was done since 2.6 supports it, and the removal of __int__ was an oversight. I also think that there's no reason to change __index__ to call long(); int() will automatically return a long as needed. Maybe changing __long__ back to __int__ is also harmless. On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: From: Guido van Rossum [EMAIL PROTECTED] Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. 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/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
Re: [Python-Dev] on Python's tests (and making them better)
Martin v. Löwis wrote: - reorganizing the tests into separate directories Why this one? I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). I personally use grep to find the place where to add a new test. I agree. There's not much chance I'd know which directory a test for a given piece of functionality is in, so instead of grepping in a single directory, I'd have to grep in all of them. Definitely more hassle. Eric. ___ 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] on Python's tests (and making them better)
On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). I personally use grep to find the place where to add a new test. I agree. There's not much chance I'd know which directory a test for a given piece of functionality is in, so instead of grepping in a single directory, I'd have to grep in all of them. Definitely more hassle. Really? Given the choice between core_language (divided into syntax and builtins) and stdlib you wouldn't know where to look? Eric. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] on Python's tests (and making them better)
Benjamin Peterson wrote: On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). I personally use grep to find the place where to add a new test. I agree. There's not much chance I'd know which directory a test for a given piece of functionality is in, so instead of grepping in a single directory, I'd have to grep in all of them. Definitely more hassle. Really? Given the choice between core_language (divided into syntax and builtins) and stdlib you wouldn't know where to look? Really. I wouldn't bother thinking about it. I'd just grep. Eric. ___ 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] on Python's tests (and making them better)
2008/6/6 Benjamin Peterson [EMAIL PROTECTED]: I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Intuitive to who taking into account which grouping? Start to group using *your* intuitive way, and a lot of people will find it unintuitive. -1 to group the tests. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] on Python's tests (and making them better)
On Jun 6, 2008, at 6:52 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). I personally use grep to find the place where to add a new test. I agree. There's not much chance I'd know which directory a test for a given piece of functionality is in, so instead of grepping in a single directory, I'd have to grep in all of them. Definitely more hassle. Really? Given the choice between core_language (divided into syntax and builtins) and stdlib you wouldn't know where to look? Eric. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. __ I'd tend to agree with ben here - a single directory for all tests does scale well and makes the purpose of each test unclear. Besides, grep -r could traverse the directory tree. +1 nested :) Jesse ___ 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] on Python's tests (and making them better)
How does 1 directory scale when one day you have possibly thousands of tests? On Jun 6, 2008, at 6:58 PM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/6/6 Benjamin Peterson [EMAIL PROTECTED]: I always find it hard to find a test I'm looking for in a directory with 365 different tests in it. Also grouping tests by function will hopefully help reduce duplication and it more intuitive. Intuitive to who taking into account which grouping? Start to group using *your* intuitive way, and a lot of people will find it unintuitive. -1 to group the tests. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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/jnoller%40gmail.com ___ 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] on Python's tests (and making them better)
Really? Given the choice between core_language (divided into syntax and builtins) and stdlib you wouldn't know where to look? Exactly so. I would not normally guess that the builtins belong to the core language - they belong to the stdlib, IMO. core language is just syntax to me, perhaps plus the data types that have literals or displays, and perhaps plus a few selected exceptions. (just to test your own intuition: when reversed() got added, was that more of a language change than when sys.meta_path got added?) 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] on Python's tests (and making them better)
How does 1 directory scale when one day you have possibly thousands of tests? I find this a theoretical question. It took 18 years to arrive at 500 test files. Assuming a linear growth, we get 1000 tests in 2025, and 2000 tests in 2060. People can worry about reorganizing them then. 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] on Python's tests (and making them better)
Martin v. Löwis wrote: How does 1 directory scale when one day you have possibly thousands of tests? I find this a theoretical question. It took 18 years to arrive at 500 test files. Assuming a linear growth, we get 1000 tests in 2025, and 2000 tests in 2060. People can worry about reorganizing them then. Personally I'd like to see packages have their own test directory. This keeps things related to each other together. Top level modules of course would have their tests in the top level test directory as they are now. I don't see any need to subdivide tests further than that. ___ 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] on Python's tests (and making them better)
2008/6/6 Ron Adam [EMAIL PROTECTED]: Martin v. Löwis wrote: How does 1 directory scale when one day you have possibly thousands of tests? I find this a theoretical question. It took 18 years to arrive at 500 test files. Assuming a linear growth, we get 1000 tests in 2025, and 2000 tests in 2060. People can worry about reorganizing them then. Personally I'd like to see packages have their own test directory. This keeps things related to each other together. Top level modules of course would have their tests in the top level test directory as they are now. I really dislike having a test directory inside a python package. You have my -1 on that idea. I don't see any need to subdivide tests further than that. ___ 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/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ 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] on Python's tests (and making them better)
Still, I don't think this should be done. Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). Yes. Grep is your friend. 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] on Python's tests (and making them better)
On Sat, 7 Jun 2008 07:32:40 am Martin v. Löwis wrote: Flat is better than nested, and adding hierarchy will make it *more* difficult to find anything (except perhaps for the one person who did the rearrangement). Do you have a filing cabinet with everything filed under F for File? *wink* I've often thought that Flat is better than nested was one of the weaker Zens... often good advice, but nearly as often not. Lists of lists and binary trees can be useful. If you've ever used an operating system with a flat file system (and I have) you'll know what a pain it is dealing with the lack of hierarchical directories. I personally use grep to find the place where to add a new test. I think, and this is just my opinion, that if you are forced to do a linear search through the entire test suite in order to find the file you want, that perhaps the test suite needs a tad better organisation. -- Steven ___ 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] Mini-Pep: Simplifying the Integral ABC
Well, it seems like Integral instances should be able to be passed to either int() or long(), so __long__ should probably stay. I have no idea why I didn't include __int__, but its absence was probably the only reason __index__ calls long() instead of int(). On Fri, Jun 6, 2008 at 3:23 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; maybe he remembers? I'm guessing that adding __long__ was done since 2.6 supports it, and the removal of __int__ was an oversight. I also think that there's no reason to change __index__ to call long(); int() will automatically return a long as needed. Maybe changing __long__ back to __int__ is also harmless. On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: From: Guido van Rossum [EMAIL PROTECTED] Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] on Python's tests (and making them better)
On Sat, 7 Jun 2008 08:58:06 am Eric Smith wrote: Really? Given the choice between core_language (divided into syntax and builtins) and stdlib you wouldn't know where to look? Really. I wouldn't bother thinking about it. I'd just grep. Since you'll do the same thing regardless of whether the tests are nested or not, I don't think you should object to the proposal. I'm against it because it will make no difference to me is not what I call a good objection. Some people might prefer to cut down their false positives by splitting the tests into sub-directories. You can still get all the false positives you want by writing grep -r -I parrot * instead of grep -I parrot * -- Steven ___ 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] on Python's tests (and making them better)
On 07Jun2008 13:24, Steven D'Aprano [EMAIL PROTECTED] wrote: | On Sat, 7 Jun 2008 07:32:40 am Martin v. Löwis wrote: | Flat is better than nested, | and adding hierarchy will make it *more* difficult to find anything | (except perhaps for the one person who did the rearrangement). | | Do you have a filing cabinet with everything filed under F for File? | *wink* No, but I always want to put things in more than one folder in my filing cabinet, and cannot. Choosing a primary axis for organisation can be arbitrary. | I've often thought that Flat is better than nested was one of the | weaker Zens... often good advice, but nearly as often not. Lists of | lists and binary trees can be useful. If you've ever used an operating | system with a flat file system (and I have) you'll know what a pain it | is dealing with the lack of hierarchical directories. Aye, but I've frequently tripped over people blithely saying general to specific for nesting without realising that the axes were orthoganal, not inherently nested. Not arguing for or against, btw. -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ ___ 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] Location of uname in os.py
Can anyone give me an idea as to where the function uname is located in os? I am unable to find it explicitly defined within the os.py file in the current svn repository. I also need to know how a call to os.uname() interacts with platform.uname(). I apologize if there is an obvious answer to this question; I just began to work on the Python project a few days ago and therefore am relatively unacqainted with the codebase. Thanks, James Thomas ___ 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
