Re: [Python-Dev] iterator API in Py3.0
Raymond Hettinger wrote: > This conversation is getting goofy. indeed. let's pray that nobody that is considering picking up Python sees this thread. ___ 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] .len() instead of __len__() (was: iterator API in Py3.0)
Hello! On Sat, Mar 04, 2006 at 04:31:26PM -0500, Phillip J. Eby wrote: > I'm not sure that "more object-oriented" should be equated with "good" in > this context, or indeed any context. :) I am sure it is. > A function is no more or less > polymorphic than a method in any case, especially if the function is > normally delegating to a slot or special method in any case. Advantages of a method over a function: -- a method is a more natural way to query or manipulate objects; -- a direct method call is faster than two-level call (len() => .__len__()); -- unnecessary cluttering of builtin namespace; the namespace should(1) contains only really global functions (__import__(), eval(), etc.) What are the advantages of a function over a method? What are disadvantages of a direct .len() instead of .__len__()? Footnote: (1) I am a perfectionist and I partially disagree with "practicality beats purity"; I would really love a small uncluttered builtin namespace in Python. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] C++ for CPython 3? (Re: str.count is slow)
Hello, > >should we perhaps switch to (careful use of) C++ in 3.0 ? > I can't see many advantages in moving to C++, but a lot of disadvantages: > > - Size increase, especially when we start using templates > - Performance decrease > - Problems with name mangling together with dynamic loading and cross > module API's > - Everything has to be build with the same compiler, binaries created > with different compilers can't interoperate > - Possibly all extensions modules have to be (re)written in C++ > - Moving to C++ will change Python's well known API substantially Same opinion. C++ is evil, please don't use it. You get a lot of new problems and nearly not benefit. Better go to jython or consider the way of pypy. -- bye by Wolfgang ___ 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] Slightly OT: Replying to posts
Just a quick question about the mechanics of replying to this list. I am a subscriber to the list, however I much prefer readiing the list archives on the web instead of having the postings delivered to my email account. Because of this, I have delivery turned off in the mailing list preferences. I particularly dislike the idea of wasting bandwidth and disk space on something that I am not going to read. However, I would like to be able to reply to posts in such a way as to have them appear in the appropriate place in the thread hierarchy. Since I don't have the original email, I cannot reply to it directly; instead I have to create a new, non-reply email and send it to the list. Simply editing the subject line to put "Re: subject" would seem to be insufficient. Does anyone have a trick for managing this? Or is there a FAQ that someone can point me to that addresses this issue? -- Talin ___ 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] iterator API in Py3.0
Phillip J. Eby a écrit : > I didn't misstate her argument or reduce it to the absurd. I simply > applied that argument consistently to similar features of Python. It's you > who is concluding that this results in absurdity; I made no such > conclusion. I'm simply pointing out that in 3.0 we should be > consistent. Either we should have ob.iter() and ob.len(), or else we > should have a builtin next(). > There is a difference though: a next() builtin would change the state of its argument, what len() ant iter() don't do. I usually prefer methods to functions for operations that modify an object. But then we have setattr and delattr :) I'd say it makes sense to go for practicallity here. Let's keep the next() method as it is, and document this as an exception. The canonical place could be section 3.3 in the language reference, but for some reason, it does not list next() right now... Cheers, BC ___ 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] .len() instead of __len__() (was: iterator API in Py3.0)
Oleg Broytmann <[EMAIL PROTECTED]> wrote: > What are disadvantages of a direct .len() instead of .__len__()? I can think of a few arguments against getting rid of double underscores in general. First, special methods are a little like keywords in that it would be nice to introduce new ones from time to time without breaking existing code. For example, using getattribute instead of __getattribute__ could have broken existing code. Another advantage to using __getattribute__ is that it's normally a method that users don't have to know about. Even if there was no problem with breaking existing code it still would be better to use underscores. Someone who doesn't yet know about the magic method could become confused when they use the name for some other purpose. Finally, there is an advantage to consistent naming. Since some special methods have double underscores, one could argue that they all should have them. Neil ___ 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] Slightly OT: Replying to posts
Talin <[EMAIL PROTECTED]> wrote: > However, I would like to be able to reply to posts in such a way as to > have them appear in the appropriate place in the thread hierarchy. The message should have a References header that contains the Message-Id of the message that you are responding to. > Does anyone have a trick for managing this? Or is there a FAQ that > someone can point me to that addresses this issue? You could use gmane.org and read the list using NNTP. Neil ___ 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] x.len() instead of len(x) in Py3.0
On Sun, Mar 05, 2006 at 06:48:22PM +, Neil Schemenauer wrote: > Oleg Broytmann <[EMAIL PROTECTED]> wrote: > > What are disadvantages of a direct .len() instead of .__len__()? > > I can think of a few arguments against getting rid of double > underscores in general. The discussion is about moving from len(sequence) to sequence.len(), not from __len__() to .len(). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Bug in from __future__ processing?
On 3/4/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Saturday 04 March 2006 15:34, Tim Peters wrote: > > Indeed! But whose arm could we twist to get them to repair the > > compiler in 2.4? I'd settle for a blurb in the next 2.4 NEWS just > > noting that 2.5 will follow the documented syntax. That may even > > be desirable, to avoid breaking working (albeit by accident) code > > across a micro release. > > I don't think a change like this should go into a 2.4.x release. It > stands a very very high chance of breaking someone's code. I _could_ > be convinced about a warning being emitted about it, though I'm not > going to have the time to figure out the new compiler to do the work. In fact I know for sure it will break code -- I believe I first ran into this with Django. Let's leave 2.4 alone (even adding a warning to 2.4.3 seems pointless) except for documenting this (not just in Misc/NEWS which is overwhelming but in the 2.4 docs for _future-_). In 2.5 it's already fixed; perhaps the 2.5 docs could mention that this was accidentally broken in 2.4. -- --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
[Python-Dev] New Future Keywords
Hi, Just a quick question: how can I add new future keywords to Python? I need to add a new (Python) keyword to the language, but there seems to be a few different source files that I need to modify. Just want to make sure I'm doing it the right way before I go unleashing a nasty broken patch into the world :) Cheers, Tom ___ 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] New Future Keywords
On 3/6/06, Thomas Lee <[EMAIL PROTECTED]> wrote: Just a quick question: how can I add new future keywords to Python? Ineed to add a new (Python) keyword to the language, but there seems tobe a few different source files that I need to modify.Just want to make sure I'm doing it the right way before I go unleashing a nasty broken patch into the world :)I wouldn't bother with a future statement until your patch has a chance of being included in Python. Adding one later is just as easy as adding one now, and you have a good chance of getting someone else to do it for you. That's what Guido did with the with-statement patch; he got Neal to do it for him ;) But if you really want to do it yourself, I would suggest grokking the with-statement future-import patch I checked in last week (written mostly by Neal Norwitz, with inspiration stolen from Michael Hudson's patch): svn diff -r42666:42667 http://svn.python.org/projects/python/trunk-- Thomas Wouters <[EMAIL PROTECTED] >Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] [Python-checkins] Python Regression Test Failures refleak (1)
On 3/5/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: test_generators leaked [255, 255, 255] references254 of those 255 leaks seem to be caused by the two recursive-generator examples at the bottom of the fun_tests doctest: fib() and the last m235() implementation. The recursiveness isn't in the generators themselves, but rather in the use of their own return values through a nested scope -- the cell objects for those values hold tee-iterators which hold (through a tee-dataobject) a reference to the generator. It doesn't look like tee-objects participate in GC, so there's no way to break the cycle. I added a quick 'close' implementation to itertools.tee, which just calls the 'close' method of whatever iterator it is tee'ing, and that does solve the issue. Considering the fairly convoluted use of generators, I guess the latter solution is acceptable (although it would be nice if tee objects did do GC, at least enough so to let the GC do its work. I haven't looked at howmuch effort that would take.) The last leak is somewhere in the coroutines_tests doctest, but I haven't taken the time to figure out where, exactly.-- Thomas Wouters <[EMAIL PROTECTED] >Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Bug in from __future__ processing?
Guido van Rossum wrote: > > I don't think a change like this should go into a 2.4.x release. It > > stands a very very high chance of breaking someone's code. I _could_ > > be convinced about a warning being emitted about it, though I'm not > > going to have the time to figure out the new compiler to do the work. > > In fact I know for sure it will break code -- I believe I first ran > into this with Django. Cheetah ? http://www.artima.com/weblogs/viewpost.jsp?thread=146606 > Let's leave 2.4 alone (even adding a warning to 2.4.3 seems pointless) > except for documenting this (not just in Misc/NEWS which is > overwhelming but in the 2.4 docs for _future-_). In 2.5 it's already > fixed; perhaps the 2.5 docs could mention that this was accidentally > broken in 2.4. agreed. ___ 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
