Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
Phillip J. Eby wrote: > At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote: >> I've changed the behaviour in r56520 to simply leave the alterations to >> sys in place when the function terminates. While this is a definite >> change to the interface (and hence not a candidate for direct >> backporting), I think the difference is small enough for the 2.5 to 2.6 >> transition. > > Your fix is a definite improvement for me, my "run any importable" patch > is looking a lot better. There's just one problem left, which is that > runpy is overwriting sys.argv[0] even if it doesn't need to. So, when > running from a zipfile, sys.argv[0] ends up None, which is wrong. > > However, if I ask runpy not to mess with sys, it creates a new module > namespace to run the code in, bringing me right back to square one > (i.e., not being run in __main__). Any thoughts? > > My fallback at this point would be to add an option to run_module() to > request that sys.argv[0] be used in place of calling _get_filename(). > It seems ugly to do that, though, if only because there are already so > many arguments to that function. Adding a get_filename() method to ZipImporter objects would get you something better than None in sys.argv[0] (specifically, you would see /__main__.py) For a reason I mentioned below, another idea I've had is to tweak the run_module semantics again and state that if __name__ already exists in sys.modules, then the code will be executed in the existing module, rather than in a new module (regardless of the value of the alter_sys argument). This would mean that the -m switch would always use the builtin __main__ module, instead of creating a new module the way it does now. This would not only fix your current problem, but also avoid any potential issues associated with having sys.modules["__main__"] refer to a different module while the interpreter is starting up (e.g. while running sitecustomize.py, and while doing any package imports needed to locate the module to be executed). I'm actually becoming more and more in favour of reverting run_module back to its 2.5 semantics and adding a separate function that does the right thing for the -m switch. It is really starting to look like the useful behaviour for a module namespace based execfile equivalent and the -m switch aren't as closely aligned as I thought they were back when I wrote PEP 338. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Terminology of "Iterable" and "Iterator"
I got into a discussion about this, which made me think it would make sense to formalize a distinction between "iterable" and "iterator". To nearly any python developer I talk with, we can define them as: iterable - An object which can be passed to the built-in iter() function, which returns an iterator. iterator - An object with a .next() method, which is used to invoke the iteration. An iterator _should_ also be an iterable, and will nearly always return itself as its own iterator. Now, the current documentation makes no distinction, and we see this in the docstring for iter(), which is curious: iter(collection) -> iterator This might indicate that it is using "collection" where I would say "iterable". Also, the same docstring makes mention of something being an iterator _or_ a sequence, so I also should bring up that it may be antiquated, yes? -- 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/archive%40mail-archive.com
Re: [Python-Dev] Terminology of "Iterable" and "Iterator"
Calvin Spealman wrote: > This might indicate that it is using "collection" where I would say > "iterable". Also, the same docstring makes mention of something being > an iterator _or_ a sequence, so I also should bring up that it may be > antiquated, yes? http://docs.python.org/dev/lib/typeiter.html That page describes the same two categories you do, but doesn't actually use the word 'iterable' for the first category (i.e. anything with an __iter__ method). So, yes, I think updating the docs to use the common terminology for both categories would be a good thing. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Failure on assorted buildbots - Address already in use
Andrew Bennetts wrote:
> Facundo Batista wrote:
>> 2007/7/24, Nick Coghlan <[EMAIL PROTECTED]>:
>> Maybe the tests should be changed to use a not-so-standard port.
>
> Or use port 0 to let the operating system pick a free port:
>
> >>> import socket
> >>> s = socket.socket()
> >>> s.bind(("127.0.0.1", 0))
> >>> s.getsockname()
> ('127.0.0.1', 42669)
>
> -Andrew.
I've changed test_urllib2_localnet to work this way - we'll see if it
improves matters.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Failure on assorted buildbots - Address already in use
Nick Coghlan wrote:
> Andrew Bennetts wrote:
>> Or use port 0 to let the operating system pick a free port:
>>
>> >>> import socket
>> >>> s = socket.socket()
>> >>> s.bind(("127.0.0.1", 0))
>> >>> s.getsockname()
>> ('127.0.0.1', 42669)
>>
>> -Andrew.
>
> I've changed test_urllib2_localnet to work this way - we'll see if it
> improves matters.
Yep, looks like that did the trick. Facundo, a similar change may help
with the GSoC project you're mentoring (the new smtplib tests failed on
at least one of the buildbots).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Terminology of "Iterable" and "Iterator"
The docs do make a distinction and generally follow the definitions given in the glossary for the tuturial. In the case of iter(collection), I prefer the current wording because the target object need not support __iter__, it is sufficient to supply a sequential __getitem__ method. Raymond - Original Message - From: "Calvin Spealman" <[EMAIL PROTECTED]> To: "Python Mailing List" Sent: Wednesday, July 25, 2007 5:18 AM Subject: [Python-Dev] Terminology of "Iterable" and "Iterator" >I got into a discussion about this, which made me think it would make > sense to formalize a distinction between "iterable" and "iterator". To > nearly any python developer I talk with, we can define them as: > > iterable - An object which can be passed to the built-in iter() > function, which returns an iterator. > > iterator - An object with a .next() method, which is used to invoke > the iteration. An iterator _should_ also be an iterable, and will > nearly always return itself as its own iterator. > > Now, the current documentation makes no distinction, and we see this > in the docstring for iter(), which is curious: > >iter(collection) -> iterator > > This might indicate that it is using "collection" where I would say > "iterable". Also, the same docstring makes mention of something being > an iterator _or_ a sequence, so I also should bring up that it may be > antiquated, yes? > > -- > 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/python%40rcn.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
Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
At 08:29 PM 7/25/2007 +1000, Nick Coghlan wrote: >Phillip J. Eby wrote: > > At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote: > >> I've changed the behaviour in r56520 to simply leave the alterations to > >> sys in place when the function terminates. While this is a definite > >> change to the interface (and hence not a candidate for direct > >> backporting), I think the difference is small enough for the 2.5 to 2.6 > >> transition. > > > > Your fix is a definite improvement for me, my "run any importable" patch > > is looking a lot better. There's just one problem left, which is that > > runpy is overwriting sys.argv[0] even if it doesn't need to. So, when > > running from a zipfile, sys.argv[0] ends up None, which is wrong. > > > > However, if I ask runpy not to mess with sys, it creates a new module > > namespace to run the code in, bringing me right back to square one > > (i.e., not being run in __main__). Any thoughts? > > > > My fallback at this point would be to add an option to run_module() to > > request that sys.argv[0] be used in place of calling _get_filename(). > > It seems ugly to do that, though, if only because there are already so > > many arguments to that function. > >Adding a get_filename() method to ZipImporter objects would get you >something better than None in sys.argv[0] (specifically, you would see >/__main__.py) That's not the goal, actually; I want runpy to leave sys.argv[0] alone, so that we maintain the invariant that invoking sys.executable with sys.argv will re-run the same effective program. (And pointing to __main__.py inside the zipfile won't work!) >I'm actually becoming more and more in favour of reverting run_module >back to its 2.5 semantics and adding a separate function that does the >right thing for the -m switch. +1; just make sure it has a way to request *not* overwriting sys.argv[0]. ___ 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] Failure on assorted buildbots - Address already in use
2007/7/25, Nick Coghlan <[EMAIL PROTECTED]>: > Yep, looks like that did the trick. Facundo, a similar change may help > with the GSoC project you're mentoring (the new smtplib tests failed on > at least one of the buildbots). Yes! Alan is already working in this (he sent me today a patch, :). Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Terminology of "Iterable" and "Iterator"
Raymond Hettinger schrieb: > The docs do make a distinction and generally follow the definitions given in > the glossary for the tuturial. > > In the case of iter(collection), I prefer the current wording because the > target object need not support __iter__, it is sufficient to supply a > sequential __getitem__ method. But as "collection" is never used in that meaning anywhere else, it could as well be iter(object). bike-shed-ly yrs, 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 [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] Terminology of "Iterable" and "Iterator"
Raymond Hettinger wrote: > In the case of iter(collection), I prefer the current wording because the > target object need not support __iter__, it is sufficient > to supply a sequential __getitem__ method. Seems to me that should be included in the definition of an iterable -- i.e. anything for which iter() works is an iterable. -- 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
