[Python-Dev] interested in google intership..
Sir, I am a computer science student studying in India. I have maintained a good academic record throughtout my engineering. I would like to associate myself with GOOGLE. I will be glad if you let me know how to apply for GOOGLE INTERSHIP.. given a chance i would prove to be an asset to your firm.Yourhelp might provide a new dimension to my career. Please help. Thank you -- SILKY SINGH ___ 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] interested in google intership..
On Nov 21, 2007 6:02 AM, cave girl <[EMAIL PROTECTED]> wrote: > Sir, > I am a computer science student studying in India. I have maintained a good > academic record throughtout my engineering. I would like to associate myself > with GOOGLE. I will be glad if you let me know how to apply for GOOGLE > INTERSHIP.. given a chance i would prove to be an asset to your firm.Your > help might provide a new dimension to my career. Please help. > Thank you This mailing list is for the Python programming language, not Google. You can use Google to search for the proper page on Google's web site: http://www.google.com/support/jobs/bin/static.py?page=students.html&sid=intern . -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (11/14/07 - 11/21/07) 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. 1328 open (+20) / 11638 closed (+21) / 12966 total (+41) Open issues with patches: 418 Average duration of open issues: 693 days. Median duration of open issues: 806 days. Open Issues Breakdown open 1322 (+19) pending 6 ( +1) Issues Created Or Reopened (42) ___ Magic class member variable initialization with lists11/14/07 CLOSED http://bugs.python.org/issue1443created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 CLOSED http://bugs.python.org/issue1444created jgsack patch SystemError accessing uninitialised cell contents11/15/07 http://bugs.python.org/issue1445created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448created weck patch make msi work the vs 2005(MSVC8)11/15/07 CLOSED http://bugs.python.org/issue1449created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450created weck patch SSL patch for Python 300011/15/07 CLOSED http://bugs.python.org/issue1451created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454created cortesi VS2008, quick hack for distutils.msvccompiler11/17/07 http://bugs.python.org/issue1455created tiran py3k, patch unexpected iterator behavior with removal11/18/07 CLOSED http://bugs.python.org/issue1456created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457created taleinat installer crashes on attempted cancellation 11/18/07 http://bugs.python.org/issue1458created JosephArmbruster Bugs lost on migration from Sourceforge 11/18/07 CLOSED http://bugs.python.org/issue1459created gagenellina codecs utf7 decoding error 11/19/07 CLOSED http://bugs.python.org/issue1460created arnimar 0**0 should raise an error 11/19/07 CLOSED http://bugs.python.org/issue1461created jmgillet About this document refers to SourceForge tracker11/19/07
[Python-Dev] Tracker summary emails
Is it only me who thinks that the current daily summaries are a bit frequent? Would it be possible to reduce the frequency to, say, once a week? I can set up a filter to simply ditch the things, but I thought I'd check what other people's views are before I did. 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] Should we do away with unbound methods in Py3k?
I'm asking a Py3k question on python-dev because I'd like to have
opinions from people who haven't thought about Py3k much yet. Consider
the following example:
class C:
def foo(self): pass
C.foo(42)
This currently fails with this error message:
TypeError: unbound method foo() must be called with C instance as
first argument (got int instance instead)
This message is called when isinstance(self, C) returns False, where
self is the first argument passed to the unbound method.
That's nice, but there is a cost associated with this: the expression
"C.foo" can't just return the function object "foo", it has to wrap it
in an unbound method object. In Py3k the cost of calling an unbound
method object goes up, because the isinstance() check may be
overloaded. This typically happens when the class C uses the special
metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119).
in Py3k the I/O stream classes are perhaps the most common use case.
Given that the error is of limited value and that otherwise the
unbound method behaves exactly the same as the original function
object, I'd like to see if there are strenuous objections against
dropping unbound method objects altogether (or at least not using them
in this case), so that explicit super calls (via the unbound method)
may go a little faster. Also, it would make it easier to fix this
issue: http://bugs.python.org/issue1109
To illustrate the cost of the isinstance() overloading, step through
this simple program with Py3k:
import abc, pdb
class Base(metaclass=abc.ABCMeta):
@abc.abstractmethod
def foo(self):
pass
class C(Base):
def foo(self):
Base.foo(self)
c = C()
pdb.run("c.foo()")
--
--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] Tracker summary emails
> Is it only me who thinks that the current daily summaries are a bit > frequent? Would it be possible to reduce the frequency to, say, once a > week? Only if the person in charge of it changes the cron job. Feel free to submit a bug report at http://psf.upfronthosting.co.za/roundup/meta (I thought there was one already, but I can't find it right now). Help in administrating the roundup installation is urgently desired; there is currently no active maintenance of this site (which makes me wonder whether we should have used Jira instead of roundup, as the company offering it had also offered hosting and active maintenance) FWIW, help in adminstration is desired for *all* hosts on *.python.org (web, mailing lists, PyPI, ...) 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] Tracker summary emails
2007/11/21, "Martin v. Löwis" <[EMAIL PROTECTED]>: > Help in administrating the roundup installation is urgently desired; > there is currently no active maintenance of this site (which makes me > wonder whether we should have used Jira instead of roundup, as the > company offering it had also offered hosting and active maintenance) > > FWIW, help in adminstration is desired for *all* hosts on *.python.org > (web, mailing lists, PyPI, ...) Is somewhere the description of these hosts? Are they debian, solaris, or what? Which web server do they have? Etc. This way, we can search for help in our sysadmins friends. Better: if you have a description, I'd post a request for help in the Python Argentina list. 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] Tracker summary emails
On Nov 21, 2007, at 5:58 PM, Paul Moore wrote: > Is it only me who thinks that the current daily summaries are a bit > frequent? Would it be possible to reduce the frequency to, say, once a > week? > > I can set up a filter to simply ditch the things, but I thought I'd > check what other people's views are before I did. Not only are they once a day, but every day's report contains the preceeding 7 days worth of changes. I had assumed it was just a bug in the script, since it seems utterly useless. James ___ 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] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > I'm asking a Py3k question on python-dev because I'd like to have > opinions from people who haven't thought about Py3k much yet. Consider > the following example: > > class C: > def foo(self): pass > > C.foo(42) > > This currently fails with this error message: > > TypeError: unbound method foo() must be called with C instance as > first argument (got int instance instead) > > This message is called when isinstance(self, C) returns False, where > self is the first argument passed to the unbound method. > > That's nice, but there is a cost associated with this: the expression > "C.foo" can't just return the function object "foo", it has to wrap it > in an unbound method object. In Py3k the cost of calling an unbound > method object goes up, because the isinstance() check may be > overloaded. This typically happens when the class C uses the special > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > in Py3k the I/O stream classes are perhaps the most common use case. > > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case), so that explicit super calls (via the unbound method) > may go a little faster. Also, it would make it easier to fix this > issue: http://bugs.python.org/issue1109 > On occasions I've found it a drag that you *can't* call unbound methods with a different type. Python normally allows duck typing and this is one place it actually places type restrictions... I'd be happy to see this restriction go. :-) Michael Foord ___ 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] Tracker summary emails
On 21/11/2007, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Is it only me who thinks that the current daily summaries are a bit > > frequent? Would it be possible to reduce the frequency to, say, once a > > week? > > Only if the person in charge of it changes the cron job. Feel free to > submit a bug report at > > http://psf.upfronthosting.co.za/roundup/meta Done. Issue 168. Thanks for the pointer. 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] [python] Should we do away with unbound methods in Py3k?
On Nov 21, 2007 4:33 PM, Michael Foord <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I'm asking a Py3k question on python-dev because I'd like to have > > opinions from people who haven't thought about Py3k much yet. Consider > > the following example: > > > > class C: > > def foo(self): pass > > > > C.foo(42) > > > > This currently fails with this error message: > > > > TypeError: unbound method foo() must be called with C instance as > > first argument (got int instance instead) > > > > This message is called when isinstance(self, C) returns False, where > > self is the first argument passed to the unbound method. > > > > That's nice, but there is a cost associated with this: the expression > > "C.foo" can't just return the function object "foo", it has to wrap it > > in an unbound method object. In Py3k the cost of calling an unbound > > method object goes up, because the isinstance() check may be > > overloaded. This typically happens when the class C uses the special > > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > > in Py3k the I/O stream classes are perhaps the most common use case. > > > > Given that the error is of limited value and that otherwise the > > unbound method behaves exactly the same as the original function > > object, I'd like to see if there are strenuous objections against > > dropping unbound method objects altogether (or at least not using them > > in this case), so that explicit super calls (via the unbound method) > > may go a little faster. Also, it would make it easier to fix this > > issue: http://bugs.python.org/issue1109 > > > > On occasions I've found it a drag that you *can't* call unbound methods > with a different type. Python normally allows duck typing and this is > one place it actually places type restrictions... > > I'd be happy to see this restriction go. :-) I agree. Though I'd like to know what happens when I do something like:: >>> class C(object): ... def __setitem__(self, key, value): ... print key, value ... >>> c = C() >>> dict.update(c, foo='bar') Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'update' requires a 'dict' object but received a 'C' I assume the code will fail (though it would be really cool if it didn't). How will it fail? STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > I'm asking a Py3k question on python-dev because I'd like to have > opinions from people who haven't thought about Py3k much yet. Consider > the following example: > > class C: > def foo(self): pass > > C.foo(42) > > This currently fails with this error message: > > TypeError: unbound method foo() must be called with C instance as > first argument (got int instance instead) > > This message is called when isinstance(self, C) returns False, where > self is the first argument passed to the unbound method. > > That's nice, but there is a cost associated with this: the expression > "C.foo" can't just return the function object "foo", it has to wrap it > in an unbound method object. In Py3k the cost of calling an unbound > method object goes up, because the isinstance() check may be > overloaded. This typically happens when the class C uses the special > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > in Py3k the I/O stream classes are perhaps the most common use case. Could we check for "real" inheritance first, and call __instancecheck__ only when the previous is false? It would speed-up the common cases. Or is there really a use case for a derived class to appear as NOT being a subclass of its base class? -- Amaury Forgeot d'Arc ___ 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] Should we do away with unbound methods in Py3k?
If I understand correctly, this would negate the need for staticmethod() when accessing the function via the class (and not instances) since the main effect of that is to prevent the wrapping. (And since I consider instance.somestaticmeth() as even less idiomatic Python that class.somestaticmeth(), I should think staticmethod then could go also.) This change would certainly reinforce the idea that in Python, methods are just functions with a special access. It might quiet the calls for 'implicit' self. It would make Python slightly easier to learn, I think, since the reason for unbound method wrapping is not obvious. From what you said, it is a sacrifice of speed for safety. But this is the only place I can think of where an argument type-check is automatically applied to user-written functions. So, +whatever from me for making Python slightly simpler. tjr ___ 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] Should we do away with unbound methods in Py3k?
At 01:41 AM 11/22/2007 +0100, Amaury Forgeot d'Arc wrote: >Could we check for "real" inheritance first, and call >__instancecheck__ only when the previous is false? It would speed-up >the common cases. +1. >Or is there really a use case for a derived class to appear as NOT >being a subclass of its base class? The only reason to do this would be to work around badly written code, but IMO the cure is worse than the disease at that point. The lookup sequence should probably be something like: 1. type(ob) is cls 2. issubclass(type(ob), cls) 3. ob.__class__ is cls 4. issubclass(ob.__class__, cls) 5. ob.__instancecheck__(cls) Where issubclass() checks __mro__ before calling the subclass check method, and #3 and #4 can be skipped if ob.__class__ is type(ob). ___ 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] Should we do away with unbound methods in Py3k?
Phillip J. Eby wrote: > The lookup sequence should probably be something like: > >1. type(ob) is cls >2. issubclass(type(ob), cls) But can't issubclass be overridden as well? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case) Fine by me. I've always thought they were of dubious value in the first place. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should we do away with unbound methods in Py3k?
On Nov 21, 2007 4:58 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > If I understand correctly, this would negate the need for staticmethod() > when accessing the function via the class (and not instances) since the > main effect of that is to prevent the wrapping. (And since I consider > instance.somestaticmeth() as even less idiomatic Python that > class.somestaticmeth(), I should think staticmethod then could go also.) Not quite. You can evolve an API from an instancemethod into a staticmethod without changing the call sites. Also (unlike Java or C++) you can override a staticmethod, and self.somestaticmeth() will look it up in self.__class__. > This change would certainly reinforce the idea that in Python, methods are > just functions with a special access. It might quiet the calls for > 'implicit' self. Doubt it. :-) > It would make Python slightly easier to learn, I think, since the reason > for unbound method wrapping is not obvious. From what you said, it is a > sacrifice of speed for safety. But this is the only place I can think of > where an argument type-check is automatically applied to user-written > functions. I think historically we didn't always have unbound methods; I believe I introduced them (in the 1.x days I think) to catch what was mostly a hypothetical error case. > So, +whatever from me for making Python slightly simpler. Thanks. I like this better than changing the definition of isinstance(). -- --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] Should we do away with unbound methods in Py3k?
At 03:48 PM 11/22/2007 +1300, Greg Ewing wrote: >Phillip J. Eby wrote: > > The lookup sequence should probably be something like: > > > >1. type(ob) is cls > >2. issubclass(type(ob), cls) > >But can't issubclass be overridden as well? Yes, which is why I spelled it that way, and mentioned that 'issubclass()' should check class identity and __mro__ before falling through to the special method check. ___ 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] Should we do away with unbound methods in Py3k?
On Nov 21, 2007 4:25 PM, Steven Bethard <[EMAIL PROTECTED]> wrote: > Though I'd like to know what happens when I do something like:: > > >>> class C(object): > ... def __setitem__(self, key, value): > ... print key, value > ... > >>> c = C() > >>> dict.update(c, foo='bar') > Traceback (most recent call last): > File "", line 1, in > TypeError: descriptor 'update' requires a 'dict' object but received a 'C' > > I assume the code will fail (though it would be really cool if it > didn't). How will it fail? I expect it won't change -- built-in types use a different mechanism. -- --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] Tracker summary emails
> Is somewhere the description of these hosts? Not that I know of; you'll have to ask. > Are they debian, solaris, > or what? Which web server do they have? Etc. They are mostly Debian systems, with Apache, and other debian packages installed. I don't know what bugs.python.org runs, but I believe it's Linux also. 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
