Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Thomas Heller schrieb: >>> Are there others that can provide a Windows buildbot? It would probably >>> be good to have two -- and a WinXP one would be good. >> >> It certainly would be good. Unfortunately, Windows users are not that >> much engaged in the open source culture, so few of them volunteer >> (plus it's more painful, with Windows not being a true multi-user >> system). > > I'll try to setup a buildbot under WinXP. The buildbot is now working. Thomas ___ 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] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
> The buildbot is now working. Thanks for the effort. If any of the current operators of a Windows buildbot want to shut down theirs in return, please let me know. 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] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
On 5/23/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Tim Peter's machine comes and goes, depending on whether he starts > the buildbot. Alan McIntyre's machien should be mostly he reliable, > but nobody really notices if it goes away. FWIW, my current internet service is less than spectacular, and frequently vanishes for hours at a time. I will be moving it within the next 3 weeks to my new residence which--I hope--will have better service. So hopefully that will mean it becomes more reliable. ;-) Alan ___ 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 Super PEP
Dino Viehland wrote: > Just to chime in from the IronPython side (better late than never I suppose): > > If we need to get access to the frame which is calling super then we can make > that happen in IronPython. It just means that super gets treated like we > treat eval today and won't work if it's been aliased. > Being able to access the calling frame from IronPython would be really useful... Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Spealman > Sent: Sunday, April 29, 2007 12:31 PM > To: Collin Winter > Cc: Python Mailing List > Subject: Re: [Python-Dev] New Super PEP > > On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote: > >> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: >> >>> On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote: >>> What if the instance isn't called "self"? PEP 3099 states that "self will not become implicit"; it's talking about method signatures, but I think that dictum applies equally well in this case. >>> I don't use the name self. I use whatever the first argument name is, >>> found by this line of python code: >>> >>> instance_name = calling_frame.f_code.co_varnames[0] >>> >> So I can't use super with anything but the method's invocant? That >> seems arbitrary. >> > > This will be added to the open issues, but it comes back to the > problem with allow the exact same super implementation both operate in > the super(Class, Object).foo() form and also the super.__call__() form > in the new version. > > Any suggestions are welcome for how to solve this. > > Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? >>> I'll bring this up for input from PyPy and IronPython people, but I >>> don't know any Jython people. Are we yet letting the alternative >>> implementations influence so strongly what we do in CPython? I'm not >>> saying "screw them", just pointing out that there is always a way to >>> implement anything, and if its some trouble for them, well, 2.6 or 3.0 >>> targetting is far down the road for any of them yet. >>> >> It's a smell test: if a given proposal is unduly difficult for >> anything but CPython to implement, it's probably a bad idea. The >> language shouldn't go down the Perl 5 road, where python (the C >> interpreter) becomes the only thing that can implement Python (the >> language). >> > > Understandable. I still haven't contacted anyone about it on in the > PyPy or IronPython worlds, and anyone familiar with Jython who can > comment would be appreciated. Ditto for PyPy and IronPython, even > though I should be able to find some information there myself. > > -- > Read my blog! I depend on your acceptance of my opinion! I am interesting! > http://ironfroggy-code.blogspot.com/ > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dinov%40microsoft.com > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ 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 Super PEP
>>> Being able to access the calling frame from IronPython would be really
>>> useful...
We do have a -X:Frames option but it's going to hurt your performance, but for
example:
IronPython 1.0.60816 on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> def f():
... x = locals
... print x()
...
>>> f()
{'__name__': '__main__', '__builtins__': , '__doc__': None,
'site': , '
f': }
>>> ^Z
C:\Product\Released\IronPython-1.0>.\ipy.exe -X:Frames
IronPython 1.0.60816 on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> def f():
... x = locals
... print x()
...
>>> f()
{'x': }
>>> ^Z
But then we'll NEVER use the CLR stack for storing locals, but we can also
always get the calling frames.
___
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] Minor ConfigParser Change
On Saturday 26 May 2007, Joseph Armbruster wrote: > I noticed that one of the parts of ConfigParser was not using "for line > in fp" style of readline-ing :-) So, this will reduce the SLOC by 3 > lines and improve readability. However, I did a quick grep and this > type of practice appears in several other places. Before the current iteration support was part of Python, there was no way to iterate over a the way there is now; the code you've dug up is simply from before the current iteration support. (As I'm sure you know.) Is there motivation for these changes other than a stylistic preference for the newer idioms? Keeping the SLOC count down seems pretty minimal, and unimportant. Making the code more understandable is valuable, but it's not clear how much this really achieves that. In general, we try to avoid making style changes to the code since that can increase the maintenance burden (patches can be harder to produce that can be cleanly applied to multiple versions). Are there motivations we're missing? -Fred -- Fred L. Drake, Jr. ___ 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] Quoting netiquette reminder [Re: proposed which.py replacement]
Aahz wrote: > Guido has previously given himself explicit permission to violate > netiquette (including the rule about top-posting). Only in the Python mailing lists, I hope -- unless he's declared himself BDFL of the whole Internet as well. :-) I suppose he could be considered to have a right to do that, but it doesn't stop sloppy quoting practices from being annoying and inefficient. The quoting conventions that emerged in the early days did so for good reasons -- they avoid squandering bandwidth and aid clear communication. To me, it's not so much a matter of politeness, but of common sense. -- Greg ___ 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
