Re: [Python-Dev] Requesting that a class be a new-style class
> > This is something I've typed way too many times: > > > > Py> class C(): > > File "", line 1 > > class C(): > > ^ > > SyntaxError: invalid syntax > > > > It's the asymmetry with functions that gets to me - defining a > > function with no arguments still requires parentheses in the > > definition statement, but defining a class with no bases requires the > > parentheses to be omitted. > > Seconded. It's always irked me enough that it's the only ``apology'' > for Python syntax you'll see in the Nutshell -- top of p. 71, "The > syntax of the class statement has a small, tricky difference from that > of the def statement" etc. +1 For me, this would come-up when experimenting with mixins. Adding and removing a mixin usually entailed a corresponding change to the parentheses. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
But... only as an additional option, not as a replacement, right? Michael On Sat, 19 Feb 2005 03:01:14 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > This is something I've typed way too many times: > > > > > > Py> class C(): > > > File "", line 1 > > > class C(): > > > ^ > > > SyntaxError: invalid syntax > > > > > > It's the asymmetry with functions that gets to me - defining a > > > function with no arguments still requires parentheses in the > > > definition statement, but defining a class with no bases requires the > > > parentheses to be omitted. > > > > Seconded. It's always irked me enough that it's the only ``apology'' > > for Python syntax you'll see in the Nutshell -- top of p. 71, "The > > syntax of the class statement has a small, tricky difference from that > > of the def statement" etc. > > +1 For me, this would come-up when experimenting with mixins. Adding and > removing a mixin usually entailed a corresponding > change to the parentheses. > > > Raymond > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Prospective Peephole Transformation
Tim Peters wrote: > [Fredrik Lundh] >> wouldn't be the first time... > > How soon we forget . oh, that was in the dark ages of Python 1.4. I've rebooted myself many times since then... > Fredrik introduced a pile of optimizations special-casing the snot out > of small integers into ceval.c a long time ago iirc, you claimed that after a couple of major optimizations had been added, "there's no single optimization left that can speed up pystone by more than X%", so I came up with an "(X+2)%" optimization. you should do that more often ;-) > As a result, "i == j" in Python source code, when i and j are little > ints, is much faster than comparing i and j via any other route in > Python. which explains why my "in" vs. "or" tests showed good results for integers, but not for strings... I'd say that this explains why it would still make sense to let the code generator change "x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c are all integers. (see my earlier timeit results) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: builtin_id() returns negative numbers
Donovan Baarda wrote: > Apparently lawyers have decided that you can't give code away. Intellectual > charity is illegal :-) what else would a lawyer say? do you really expect lawyers to admit that there are ways to do things that don't involve lawyers? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Prospective Peephole Transformation
Fredrik Lundh wrote: I'd say that this explains why it would still make sense to let the code generator change "x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c are all integers. How often does that happen in real code? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] builtin_id() returns negative numbers
Donovan Baarda wrote: Seriously, on the Python lists there has been a discussion rejecting an md5sum implementation because the author "donated it to the public domain". Apparently lawyers have decided that you can't give code away. Intellectual charity is illegal :-) Despite the smiley: It is not illegal - it just does not have any legal effect. Just by saying "I am the chancellor of Germany", it does not make you the chancellor of Germany; instead, you need to go through the election processes. Likewise, saying "the public can have my code" does not make it so. Instead, you have to formulate a license that permits the public to do with the code what you think it should be allowed to do. Most people who've used the term "public domain" in the past didn't really care whether they still have the copyright - what they wanted to say is that anybody can use their work for any purpose. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Prospective Peephole Transformation
Raymond Hettinger wrote: Hmm, what if you'd teach tuples to do faster contains lookups for string or integer only content, e.g. by introducing sub-types for string-only and integer-only tuples ?! For a linear search, tuples are already pretty darned good and leave room for only microscopic O(n) improvements. The bigger win comes from using a better algorithm and data structure -- hashing beats linear search hands-down. The constant search time is faster for all n>1, resulting in much improved scalability. No tweaking of tuple.__contains__() can match it. Sets are the right data structure for fast membership testing. I would love for sets to be used internally while letting users continue to write the clean looking code shown above. That's what I was thinking off: if the compiler can detect the constant nature and the use of a common type, it could set a flag in the tuple type telling it about this feature. The tuple could then convert the tuple contents to a set internally and when the __contains__ hook is first called and use the set for the lookup. Alternatively, you could use a sub-type for a few common cases. In either case you would have to teach marshal how to treat the extra bit of information. The user won't notice all this in the Python program and can continue to write clean code (in some cases, even cleaner code than before - I usually use the keyword hack to force certain things into the locals at module load time, but would love to get rid off this). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 19 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Prospective Peephole Transformation
On Sat, Feb 19, 2005, "Martin v. L?wis" wrote: > Fredrik Lundh wrote: >> >>I'd say that this explains why it would still make sense to let the code >>generator change >>"x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c >>are all integers. > > How often does that happen in real code? Dunno how often, but I was working on some code at my company yesterday that did that -- we use a lot of ints to indicate options. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
Nick Coghlan <[EMAIL PROTECTED]> writes: > This is something I've typed way too many times: > > Py> class C(): >File "", line 1 > class C(): > ^ > SyntaxError: invalid syntax > > It's the asymmetry with functions that gets to me - defining a > function with no arguments still requires parentheses in the > definition statement, but defining a class with no bases requires the > parentheses to be omitted. Yeah, this has annoyed me for ages too. However! You obviously haven't read Misc/HISTORY recently enough :) The surprising thing is that "class C():" used to work (in fact before 0.9.4 the parens mandatory). It became a syntax error in 0.9.9, seemingly because Guido was peeved that people hadn't updated all their old code to the new syntax. I wonder if he'd like to try that trick again today :) I'd still vote for it to be changed. > Which leads in to the real question: Does this *really* need to be a > syntax error? Or could it be used as an easier way to spell "class > C(object):"? -1. Too magical, too opaque. > Then, in Python 3K, simply drop support for omitting the parentheses > from class definitions - require inheriting from ClassicClass > instead. HISTORY repeats itself... Cheers, mwh -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Some old patches
Hello, this time working up some of the patches with beards: - #751943 Adds the display of the line number to cgitb stack traces even when the source code is not available to cgitb. This makes sense in the case that the source is lying around somewhere else. However, the original patch generates a link to "file://?" on the occasion that the source file name is not known. I have created a new patch (#1144549) that fixes this, and also renames all local variables "file" in cgitb to avoid builtin shadowing. - #749830 Allows the mmap call on UNIX to be supplied a length argument of 0 to mmap the whole file (which is already implemented on Windows). However, the patch doesn't apply on current CVS, so I made a new patch (#1144555) that does. Recommend apply, unless this may cause problems on some Unices which I don't know about. - #547176 Allows the rlcompleter to complete on [] item access (constructs like sim[0]. could then be completed). As comments in the patch point out, this easily leads to execution of arbitrary code via __getitem__, which is IMHO a too big side effect of completing (though IPython does this). Recommend reject. - #645894 Allows the use of resource.getrusage time values for profile.py, which results in better timing resolution on FreeBSD. However, this may lead to worse timing resolution on other OS, so perhaps the patch should be changed to be restricted to this particular platform. - #697613 -- bug #670311 This handles the problem that python -i exits on SystemExit exceptions by introducting two new API functions. While it works for me, I am not sure whether this is too much overhead for fixing a glitch no one else complained about. - #802188 This adds a specific error message for invalid tokens after a '\' used as line continuation. While it may be helpful when the invalid token is whitespace, Python usually shows the exact location of the invalid token, so you can examine this line and find the error. On the other hand, the patch is no big deal, so if a specific error message is welcome, it may as well be applied. Enough for today... and best of all: I have no patch which I want to promote! Reinhold ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
> > This is something I've typed way too many times: > > > > Py> class C(): > >File "", line 1 > > class C(): > > ^ > > SyntaxError: invalid syntax > > > > It's the asymmetry with functions that gets to me - defining a > > function with no arguments still requires parentheses in the > > definition statement, but defining a class with no bases requires the > > parentheses to be omitted. It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-) It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
Guido van Rossum wrote: This is something I've typed way too many times: Py> class C(): File "", line 1 class C(): ^ SyntaxError: invalid syntax It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted. It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-) It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.) Fair enough - the magnitude of the semantic difference between "class C:" and "class C():" bothered me a little, too. I'll just have to remember that I can put "__metaclass__ == type" at the top of modules :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
On Sun, Feb 20, 2005 at 12:13:25PM +1000, Nick Coghlan wrote: > Guido van Rossum wrote: > >>>This is something I've typed way too many times: > >>> > >>>Py> class C(): > >>> File "", line 1 > >>>class C(): > >>>^ > >>>SyntaxError: invalid syntax > >>> > >>>It's the asymmetry with functions that gets to me - defining a > >>>function with no arguments still requires parentheses in the > >>>definition statement, but defining a class with no bases requires the > >>>parentheses to be omitted. > > > > > >It's fine to fix this in 2.5. I guess I can add this to my list of > >early oopsies -- although to the very bottom. :-) > > > >It's *not* fine to make C() mean C(object). (We already have enough > >other ways to declaring new-style classes.) > > > > Fair enough - the magnitude of the semantic difference between "class C:" > and "class C():" bothered me a little, too. I'll just have to remember that > I can put "__metaclass__ == type" at the top of modules :) I always use new style classes so I only have to remember one set of behaviors. "__metaclass__ = type" is warty, it has the "action at a distance" problem that decorators solve for functions. I didn't dig into the C but does having 'type' as metaclass guarantee the same behavior as inheriting 'object' or does object provide something type doesn't? *wince* Py3k? Faster please[*]. -Jack * a US-ism of a conservative bent, loosely translated as "change for the better? I'll get behind that." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Requesting that a class be a new-style class
> > > This is something I've typed way too many times: > > > > > > Py> class C(): > > >File "", line 1 > > > class C(): > > > ^ > > > SyntaxError: invalid syntax > > > > > > It's the asymmetry with functions that gets to me - defining a > > > function with no arguments still requires parentheses in the > > > definition statement, but defining a class with no bases requires the > > > parentheses to be omitted. > > It's fine to fix this in 2.5. Yea! Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] UserString
I noticed that UserString objects have methods that do not accept other
UserString objects as arguments:
>>> from UserString import UserString
>>> UserString('slartibartfast').count(UserString('a'))
Traceback (most recent call last):
File "", line 1, in -toplevel-
UserString('slartibartfast').count(UserString('a'))
File "C:\PY24\lib\UserString.py", line 66, in count
return self.data.count(sub, start, end)
TypeError: expected a character buffer object
>>> UserString('abc') in UserString('abcde')
Traceback (most recent call last):
File "", line 1, in -toplevel-
UserString('abc') in UserString('abcde')
File "C:\PY24\lib\UserString.py", line 35, in __contains__
return char in self.data
TypeError: 'in ' requires string as left operand
This sort of thing is easy to test for and easy to fix. The question is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
> I didn't dig into the C but does having 'type' > as metaclass guarantee the same behavior as inheriting 'object' or does object > provide something type doesn't? *wince* No, they're equivalent. __metaclass__ = type cause the base class to be object, and a base class of object causes the metaclass to be type. But I agree wholeheartedly: class C(object): is much preferred. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
