Re: [Python-Dev] itertools addition: getitem()
Guido van Rossum wrote: > On 7/9/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Also, as a practical matter, I think it is a bad idea to introduce >> __getitem__ style access to itertools because the starting point >> moves with each consecutive access: >> >> # access items 0, 2, 5, 9, 14, 20, ... >> for i in range(10): >> print getitem(iterable, i) >> >> Worse, this behavior changes depending on whether the iterable >> is re-iterable (a string would yield consecutive items while a >> generator would skip around as shown above). >> >> Besides being a bug factory, I think the getitem proposal would >> tend to steer people down the wrong road, away from more >> natural solutions to problems involving iterators. A basic step >> in learning the language is to differentiate between sequences >> and general iterators -- we should not conflate the two. > > But doesn't the very same argument also apply against islice(), which > you just offered as an alternative? Exactly. > PS. If Walter is also at EuroPython, maybe you two could discuss this in > person? Sorry, I won't be at EuroPython. Servus, Walter ___ 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] PEP 366 - Relative imports from main modules
Brett Cannon wrote:
> On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> As with the current ``__name__`` attribute, setting ``__package__`` will
>> be the responsibility of the PEP 302 loader used to import a module.
>> Loaders which use ``imp.new_module()`` to create the module object will
>> have the new attribute set automatically to
>> ``__name__.rpartition('.')[0]``.
>
> Is this really the best semantics for this? Let's say I have
> A/B/__init__.py and A/B/C.py. With these semantics I would have A.B
> having __package__ be 'A' and A.B.C having 'A.B'.
>
> While I agree that the A.B.C setting is correct, is the A.B value what
> is truly desired? Is an __init__ module really to be considered part
> of the above package? I always viewed the __init__ module as part of
> its own package. Thus I expected A.B to have __package__ set to
> 'A.B'.
Good point - PEP 328 makes it explicit that __init__.py is treated like
any other module in the package for purposes of relative imports, so the
semantics you suggest are the ones required. I hadn't actually thought
about this case, as it wasn't relevant when the new attribute applied
only to the main module.
However, those semantics mean that we won't be able to automatically add
the new attribute inside imp.new_module(), as that function doesn't know
whether or not the new module is a package.
> Beyond just what I expected, the reason I bring this up is that if
> __package__ had the semantics I am suggesting, it is trivial to
> discover what modules are the package __init__ modules (as
> ``__package__ == __name__``) compared to being a submodule
> (``__package__ and __package__ != __name__``). As of right now you
> can only do that if you examine __file__ for __init__.py(c), but that
> is highly dependent on how the module was loaded. It might be nice if
> what kind of module (top-level, package, or submodule) something is
> based on its metadata.
This part of the argument isn't relevant though, as it's already trivial
to determine whether or not a module is a package by checking for a
__path__ attribute. That's what PEP 302 specifies, and it is how the
relative import machinery currently determines whether to use __name__
or __name__.rpartition('.')[0] as the base for relative imports.
Given the above limitations, I propose that we document the new
attribute as follows:
"If the module global __package__ exists when executing an import
statement, it is used to determine the base for relative imports,
instead of the __name__ and __path__ attributes. This attribute may be
set by the interpreter before a module is executed - whether or not it
is set automatically in a given module is implementation dependent."
And for the CPython implementation, I propose that we set the new attribute:
1. When the main module is executed using the -m switch
2. When a relative import is executed and the attribute is not yet set
This will allow any module which uses relative imports to benefit from
the micro-optimisation of caching the package name in normal modules
(regardless of how the module gets loaded), as well as allowing relative
imports from the main module (which is the main goal of the PEP).
With the way PEP 302 hands off creation of the module and execution of
its code to the loader objects, I don't see any way to guarantee that
__package__ will always be set - this seems like a reasonable compromise.
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] Summary of Tracker Issues
On 08/07/07, Steve Holden <[EMAIL PROTECTED]> wrote: > This script appears to have been producing exactly the same output since > June 9. I can't believe it's useful information. It has one positive aspect for me - it's reassured me that the spate of spam which hit the new tracker a month or two ago has been successfully stopped... Paul. ___ 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] itertools addition: getitem()
From: "Guido van Rossum" <[EMAIL PROTECTED]> > But doesn't the very same argument also apply against islice(), which > you just offered as an alternative? Not really. The use cases for islice() typically do not involve repeated slices of an iterator unless it is slicing off the front few elements on each pass. In contrast, getitem() is all about grabbing something other than the frontmost element and seems to be intended for repeated calls on the same iterator. And its support for negative indices seems somewhat weird in the context of general purpose iterators: getitem(genprimes(), -1). I'll study Walter's use case but my instincts say that adding getitem() will do more harm than good. 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] PEP 366 - Relative imports from main modules
On 7/9/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> As with the current ``__name__`` attribute, setting ``__package__`` will
> >> be the responsibility of the PEP 302 loader used to import a module.
> >> Loaders which use ``imp.new_module()`` to create the module object will
> >> have the new attribute set automatically to
> >> ``__name__.rpartition('.')[0]``.
> >
> > Is this really the best semantics for this? Let's say I have
> > A/B/__init__.py and A/B/C.py. With these semantics I would have A.B
> > having __package__ be 'A' and A.B.C having 'A.B'.
> >
> > While I agree that the A.B.C setting is correct, is the A.B value what
> > is truly desired? Is an __init__ module really to be considered part
> > of the above package? I always viewed the __init__ module as part of
> > its own package. Thus I expected A.B to have __package__ set to
> > 'A.B'.
>
> Good point - PEP 328 makes it explicit that __init__.py is treated like
> any other module in the package for purposes of relative imports, so the
> semantics you suggest are the ones required. I hadn't actually thought
> about this case, as it wasn't relevant when the new attribute applied
> only to the main module.
>
> However, those semantics mean that we won't be able to automatically add
> the new attribute inside imp.new_module(), as that function doesn't know
> whether or not the new module is a package.
>
Good point.
> > Beyond just what I expected, the reason I bring this up is that if
> > __package__ had the semantics I am suggesting, it is trivial to
> > discover what modules are the package __init__ modules (as
> > ``__package__ == __name__``) compared to being a submodule
> > (``__package__ and __package__ != __name__``). As of right now you
> > can only do that if you examine __file__ for __init__.py(c), but that
> > is highly dependent on how the module was loaded. It might be nice if
> > what kind of module (top-level, package, or submodule) something is
> > based on its metadata.
>
> This part of the argument isn't relevant though, as it's already trivial
> to determine whether or not a module is a package by checking for a
> __path__ attribute. That's what PEP 302 specifies, and it is how the
> relative import machinery currently determines whether to use __name__
> or __name__.rpartition('.')[0] as the base for relative imports.
>
=) The lesson here is be careful when emailing on vacation as you
might not think everything through. =)
> Given the above limitations, I propose that we document the new
> attribute as follows:
>
> "If the module global __package__ exists when executing an import
> statement, it is used to determine the base for relative imports,
> instead of the __name__ and __path__ attributes.
That's fine. __path__ actually isn't used to resolve relative imports
into absolute ones anyway; it's used only as a substitute to sys.path
when importing within a package.
> This attribute may be
> set by the interpreter before a module is executed - whether or not it
> is set automatically in a given module is implementation dependent."
>
> And for the CPython implementation, I propose that we set the new attribute:
>1. When the main module is executed using the -m switch
>2. When a relative import is executed and the attribute is not yet set
>
> This will allow any module which uses relative imports to benefit from
> the micro-optimisation of caching the package name in normal modules
> (regardless of how the module gets loaded), as well as allowing relative
> imports from the main module (which is the main goal of the PEP).
>
> With the way PEP 302 hands off creation of the module and execution of
> its code to the loader objects, I don't see any way to guarantee that
> __package__ will always be set - this seems like a reasonable compromise.
It could be set after the import, but you are right that the loaders
will not necessarily set it before executing code. You might be able
to use the reload requirement of using an existing dict if the module
is in sys.modules somehow, but that just sounds like asking for
trouble.
-Brett
___
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] itertools addition: getitem()
Raymond Hettinger wrote:
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
>> But doesn't the very same argument also apply against islice(), which
>> you just offered as an alternative?
>
> Not really. The use cases for islice() typically do not involve
> repeated slices of an iterator unless it is slicing off the front
> few elements on each pass. In contrast, getitem() is all about
> grabbing something other than the frontmost element and seems
> to be intended for repeated calls on the same iterator.
That wouldn't make sense as getitem() consumes the iterator! ;)
But seriously: perhaps the name getitem() is misleading? What about
item() or pickitem()?
> And its
> support for negative indices seems somewhat weird in the
> context of general purpose iterators: getitem(genprimes(), -1).
This does indeed make as much sense as sum(itertools.count()).
> I'll study Walter's use case but my instincts say that adding
> getitem() will do more harm than good.
Here's the function in use (somewhat invisibly, as it's used by the
walknode() method). This gets the oldest news from Python's homepage:
>>> from ll.xist import parsers, xfind
>>> from ll.xist.ns import html
>>> e = parsers.parseURL("http://www.python.org";, tidy=True)
>>> print e.walknode(html.h2 & xfind.hasclass("news"))[-1]
Google Adds Python Support to Google Calendar Developer's Guide
Get the first comment line from a python file:
>>> getitem((line for line in open("Lib/codecs.py") if
line.startswith("#")), 0)
'### Registry and builtin stateless codec functions\n'
Create a new unused identifier:
>>> def candidates(base):
... yield base
... for suffix in count(2):
... yield "%s%d" % (base, suffix)
...
>>> usedids = set(("foo", "bar"))
>>> getitem((i for i in candidates("foo") if i not in usedids), 0)
'foo2'
Servus,
Walter
___
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] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 392 open ( +7) / 3792 closed ( +2) / 4184 total ( +9)
Bugs: 1042 open (+13) / 6757 closed (+13) / 7799 total (+26)
RFE : 263 open ( +1) / 292 closed ( +1) / 555 total ( +2)
New / Reopened Patches
__
"%d" format handling for long values (2007-06-25)
http://python.org/sf/1742669 opened by Gabriel Genellina
Read Write lock (2007-06-27)
http://python.org/sf/1744382 opened by Yaakov Nemoy
Improve exception pickling support (2007-06-27)
http://python.org/sf/1744398 opened by Eric Huss
Patch for feat. 713877 Expose callbackAPI in readline module (2007-06-27)
http://python.org/sf/1744456 opened by strank
IPv6 Interface naming/indexing functions (2007-07-02)
http://python.org/sf/1746656 opened by Michael Meier
Limiting data copy in xmlrpclib (2007-07-04)
http://python.org/sf/1747670 opened by Gael Le Mignot
Extra optional argument to os.path.expandvars (2007-07-06)
http://python.org/sf/1748960 opened by Geoffrey Bache
New byte packing format for the struct module (2007-07-07)
http://python.org/sf/1749662 opened by Robert Zeh
itertools.getitem() (2007-07-08)
http://python.org/sf/1749857 opened by Walter Dörwald
Patches Closed
__
Fix for duplicate "preferences" menu-OS X (2007-04-03)
http://python.org/sf/1693258 closed by ronaldoussoren
Mac OS X: libtool (2007-03-03)
http://python.org/sf/1673122 closed by ronaldoussoren
New / Reopened Bugs
___
Incorrect docs for optparse OptionParser add_help_option (2007-06-23)
http://python.org/sf/1742164 opened by Forest Wilkinson
ZipFile.writestr writes incorrect extended local headers (2007-06-23)
http://python.org/sf/1742205 opened by alexis
Documentation for BaseHTTPServer.HTTPServer (2007-06-25)
http://python.org/sf/1742837 opened by Brandon Mintern
Pickling of exceptions broken (2007-06-25)
http://python.org/sf/1742889 opened by Jim Fulton
shlex handles 'None' poorly (2007-06-25)
CLOSED http://python.org/sf/1742901 opened by Seth Vidal
can't run single lamba funcs as unittest (2007-06-25)
http://python.org/sf/1742940 opened by timmeh
conditional expressions vs. () and * in call arguments. (2007-06-26)
CLOSED http://python.org/sf/1743665 opened by Mike Meyer
Some incorrect national characters (Polish) in unicodedata (2007-06-26)
CLOSED http://python.org/sf/1743795 opened by admindomeny
Examples dropped from PDF version of docs (2007-06-26)
http://python.org/sf/1743846 opened by Terry Carroll
cvs.get_dialect() return a class object (2007-06-28)
http://python.org/sf/1744580 opened by Christian Kristukat
Newline skipped in "for line in file" (2007-06-28)
http://python.org/sf/1744752 opened by Rune Devik
DoS smtpd vulnerability (2007-06-28)
http://python.org/sf/1745035 opened by billiejoex
2.5.1 curses panel segfault in new_panel on aix 5.3 (2007-06-29)
http://python.org/sf/1745108 opened by Mattias Wadenstein
pdtri gives wrong results (2007-06-29)
CLOSED http://python.org/sf/1745178 opened by Nikke Knatterton
Filename providing cross platform capability (2007-06-29)
CLOSED http://python.org/sf/1745533 reopened by loewis
Filename providing cross platform capability (2007-06-29)
CLOSED http://python.org/sf/1745533 opened by Damian
Bad attributes/data handling in SGMLib (2007-06-30)
http://python.org/sf/1745761 opened by Alvaro Lopez
class mutex doesn't do anything atomically (2007-07-01)
http://python.org/sf/1746071 opened by David Benbennick
long.__str__ is quadratic time (2007-07-01)
http://python.org/sf/1746088 opened by David Benbennick
AMD64 installer does not place python25.dll in system dir (2007-07-02)
http://python.org/sf/1746880 opened by Roger Upole
chown broken on 64bit (2007-07-04)
http://python.org/sf/1747858 opened by Neal D. Becker
Module-level stack scopes have incorrect bindings. (2007-07-04)
http://python.org/sf/1748015 opened by Nefarious CodeMonkey, Jr.
inspect.getargspec fails on built-in or slot wrapper methods (2007-07-04)
http://python.org/sf/1748064 opened by Michael A. Hawker
str.join() intercepts UnicodeDecodeError raised by iterator (2007-07-05)
CLOSED http://python.org/sf/1748292 opened by Christoph Zwerschke
imaplib cannot handle mailboxes with ACL: lrs (2007-07-07)
http://python.org/sf/1749512 opened by Florian Friesdorf
PLATFORM macro in PC/pyconfig.h already defined by Apache (2007-07-07)
http://python.org/sf/1749567 opened by Adal Chiriliuc
expanduser("~") on Windows looks for HOME first (2007-07-07)
http://python.org/sf/1749583 opened by Edward Diener
os.getlogin should use the DISPLAY and not the tty (2007-07-08)
http://python.org/sf/1750013 opened by
