[Python-Dev] a feature i'd like to see in python #1: better iteration control
many times writing somewhat complex loops over lists i've found the need to sometimes delete an item from the list. currently there's no easy way to do so; basically, you have to write something like i = 0 while i < len(list): el = list[i] ...do something... if el should be deleted: del list[i] else: i += 1 note that you can't write for x in list: or even for i in xrange(len(list)): note also that you need to do some trickiness to adjust the index appropriately when deleting. i'd much rather see something like: for x:iter in list: ...do something... if x should be deleted: iter.delete() the idea is that you have a way of retrieving both the element itself and the iterator for the element, so that you can then call methods on the iterator. it shouldn't be too hard to implement iter.delete(), as well as iter.insert() and similar functions. (the recent changes to the generator protocol in 2.5 might help.) the only question then is how to access the iterator. the syntax i've proposed, with `x:iter', seems fairly logical (note that parallels with slice notation, which also uses a colon) and doesn't introduce any new operators. (comma is impossible since `for x,iter in list:' already has a meaning) btw someone is probably going to come out and say "why don't you just use a list comprehension with an `if' clause? the problems are [1] i'd like this to be destructive; [2] i'd like this to work over non-lists as well, e.g. hash-tables; [3] list comprehensions work well in simple cases, but in more complicated cases when you may be doing various things on each step, and might not know whether you need to delete or insert an element until after you've done various other things, a list comprehension would not fit naturally; [4] this mechanism is extendible to insertions, replacements and other such changes as well as just filterings. ben ___ 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] a feature i'd like to see in python #2: indexing of match objects
this one is fairly simple. if `m' is a match object, i'd like to be able to write m[1] instead of m.group(1). (similarly, m[:] should return the same as list(m.groups()).) this would remove some of the verbosity of regexp code, with probably a net gain in readability; certainly no loss. ben ___ 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] a feature i'd like to see in python #1: better iteration control
On Sun, Dec 03, 2006 at 06:24:17AM -0600, Ben Wing wrote: > many times writing somewhat complex loops over lists i've found the need > to sometimes delete an item from the list. currently there's no easy > way to do so; basically, you have to write something like > > i = 0 > while i < len(list): > el = list[i] > ...do something... > if el should be deleted: > del list[i] > else: > i += 1 > > note that you can't write > > for x in list: > > or even > > for i in xrange(len(list)): > > note also that you need to do some trickiness to adjust the index > appropriately when deleting. > > i'd much rather see something like: > > for x:iter in list: > ...do something... > if x should be deleted: > iter.delete() > > the idea is that you have a way of retrieving both the element itself > and the iterator for the element, so that you can then call methods on > the iterator. it shouldn't be too hard to implement iter.delete(), as > well as iter.insert() and similar functions. (the recent changes to the > generator protocol in 2.5 might help.) > > the only question then is how to access the iterator. the syntax i've > proposed, with `x:iter', seems fairly logical (note that parallels with > slice notation, which also uses a colon) and doesn't introduce any new > operators. (comma is impossible since `for x,iter in list:' already has > a meaning) > > btw someone is probably going to come out and say "why don't you just > use a list comprehension with an `if' clause? the problems are [1] i'd > like this to be destructive; Just use slice assignment. l = list(xrange(100)) l2 = [x for x in l if x > 50] l[:] = l2[:] > [2] i'd like this to work over non-lists as well, e.g. hash-tables; There in is the sucky part; iterator protocol is simple; what you're proposing is extending iterators so that they recall the last value (else iter.delete() would not do anything), which... eh. Think it sucks, to say the least ;) Simple example of where this gets ugly is in iterating over a file. >[3] list comprehensions work well in simple > cases, but in more complicated cases when you may be doing various > things on each step, and might not know whether you need to delete or > insert an element until after you've done various other things, a list > comprehension would not fit naturally; Slice assignments work fine here. > [4] this mechanism is extendible > to insertions, replacements and other such changes as well as just > filterings. Yes it is, except the new 'iterator' isn't as extendable to arbitrary sequences after. Also is ignoring the fact that doing in place deletion of lists as you walk can get massively costly quick; worst case, quad for removal (hence collections.deque existing). ~harring pgp1wNWIKrLn7.pgp Description: PGP signature ___ 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] a feature i'd like to see in python #1: better iteration control
Ben Wing schrieb: > i'd much rather see something like: > > for x:iter in list: > ...do something... > if x should be deleted: > iter.delete() You can easily implement that feature yourself if you need it, at least for lists (or sequences that support integer indexing): class deletable_iter: def __init__(self, sequence): self.sequence = sequence self.last = -1 def __iter__(self): return self def next(self): self.last += 1 try: return self.sequence[self.last] except IndexError: raise StopIteration def delete_last(self): del self.sequence[self.last] self.last -= 1 You use this class like this: x = [1,2,3,4,5,6,7,8] y = deletable_iter(x) for i in y: print i if i%2 == 0: y.delete_last() print x This cannot be generalized for the iteration protocol, because it might not be possible for the iterator to delete an element after it has returned it. Notice that this version "supports" multiple invocations of delete_last in a single step; it may be useful to allow at most one deletion, and raise an exception if a second deletion is attempted. Even if the deletion was added to the iterator protocol (which would require a PEP, IMO), I don't think the syntax should be changed. If you want access to the iterator in the loop, you should explicitly assign it to a variable before entering the loop. 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] a feature i'd like to see in python #2: indexing of match objects
Ben Wing schrieb: > this one is fairly simple. if `m' is a match object, i'd like to be > able to write m[1] instead of m.group(1). (similarly, m[:] should return > the same as list(m.groups()).) this would remove some of the verbosity > of regexp code, with probably a net gain in readability; certainly no loss. Please post a patch to sf.net/projects/python (or its successor). Several issues need to be taken into account: - documentation and test cases must be updated to integrate the new API - for slicing, you need to consider not only omitted indices, but also "true" slices (e.g. m[1:5]) - how should you deal with negative indices? - should len(m) be supported? 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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: > Several issues need to be taken into account: the most important issue is that if you want an object to behave as a sequence of something, you need to decide what that something is before you start tinkering with the syntax. under Ben's simple proposal, m[:][1] and m[1] would be two different things. I'm not sure that's a good idea, really. ___ 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] a feature i'd like to see in python #1: better iteration control
On 12/3/06, Ben Wing <[EMAIL PROTECTED]> wrote: > many times writing somewhat complex loops over lists i've found the need > to sometimes delete an item from the list. currently there's no easy > way to do so; basically, you have to write something like As I don't believe there's any need for a language extension, I've posted my approach to this on comp.lang.python: http://groups.google.com/group/comp.lang.python/browse_thread/thread/724aa6bcf021cfad/c4c629bd1bacc12b#c4c629bd1bacc12b Note that deleting from the list as you iterate over it tends to have very poor performance for larger lists. My post includes some timings, demonstrating this. -- Adam Olsen, aka Rhamphoryncus ___ 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] a feature i'd like to see in python #2: indexing of match objects
Fredrik Lundh schrieb: > the most important issue is that if you want an object to behave as a > sequence of something, you need to decide what that something is before > you start tinkering with the syntax. > > under Ben's simple proposal, m[:][1] and m[1] would be two different > things. I'm not sure that's a good idea, really. Ah, right; I misread his proposal as saying that m[:] should return [m[0]] + list(m.groups()) (rather, I expected that m.groups() would include m.group(0)). To answer your first question: it is clearly groups that you want to index, just as the .group() method indexes groups. The typical equivalences should hold, of course, e.g. m[1:5][1] == m[2] etc. 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] a feature i'd like to see in python #2: indexing of match objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 3, 2006, at 9:22 AM, Martin v. Löwis wrote: > Ben Wing schrieb: >> this one is fairly simple. if `m' is a match object, i'd like to be >> able to write m[1] instead of m.group(1). (similarly, m[:] should >> return >> the same as list(m.groups()).) this would remove some of the >> verbosity >> of regexp code, with probably a net gain in readability; certainly >> no loss. > > Please post a patch to sf.net/projects/python (or its successor). > > Several issues need to be taken into account: > - documentation and test cases must be updated to integrate the new > API > - for slicing, you need to consider not only omitted indices, but also > "true" slices (e.g. m[1:5]) > - how should you deal with negative indices? > - should len(m) be supported? what about m['named_group_1'] etc? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRXL2LnEjvBPtnXfVAQILTwP/SRfvOXXhUXIBK52ByqwuhCwF+K/HfEYu 0+j/L3WQXFE4sZ1CHT6TaMT/K6tbhE7zuGamKmk1+CtSPQAKluwJ8d2/y6Ubp4KE S24sP8NOzKgDg/aTn5zFS/Up7HDfhMIWGCLbg5rY+/Bl48skEkqeo4w07XKwJzky CvxsrJb4wQY= =OPjI -END PGP SIGNATURE- ___ 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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: > Ah, right; I misread his proposal as saying that m[:] should return > [m[0]] + list(m.groups()) (rather, I expected that m.groups() would > include m.group(0)). match groups are numbered 1..N, not 0..(N-1), in both the API and in the RE syntax (and we don't have much control over the latter). > To answer your first question: it is clearly groups that you want > to index, just as the .group() method indexes groups. so what should len(m) do? ___ 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] a feature i'd like to see in python #2: indexing of match objects
Barry Warsaw schrieb: >> Several issues need to be taken into account: >> - documentation and test cases must be updated to integrate the new API >> - for slicing, you need to consider not only omitted indices, but also >> "true" slices (e.g. m[1:5]) >> - how should you deal with negative indices? >> - should len(m) be supported? > > what about m['named_group_1'] etc? That should also be taken into consideration; I suggest to support it. 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] a feature i'd like to see in python #2: indexing of match objects
On Sun, Dec 03, 2006, "Martin v. L?wis" wrote: > Ben Wing schrieb: >> >> this one is fairly simple. if `m' is a match object, i'd like to be >> able to write m[1] instead of m.group(1). (similarly, m[:] should return >> the same as list(m.groups()).) this would remove some of the verbosity >> of regexp code, with probably a net gain in readability; certainly no loss. > > Please post a patch to sf.net/projects/python (or its successor). Given the list of issues and subsequent discussion so far, I think a PEP will be required. This needs more documentation than the typical patch. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Member of the Groucho Marx Fan Club ___ 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 and the Linux Standard Base (LSB)
Hi Andrew, On Fri, Dec 01, 2006 at 03:27:09PM +1100, Andrew Bennetts wrote: > In both the current Debian and Ubuntu releases, the "python2.4" binary package > includes distutils. Ah, distutils are distributed in the base package now, but not the 'config' subdirectory of a standard library's normal installation, which makes distutils a bit useless. I should go and file a bug, I guess. The reason why I did not do it so far, is that the fact that no one did tends to show that they really think distributing 'config' is not the "right" thing to do. A reasoning along the lines of: "this subdir contains include files, so it should go in the python-dev package". I'm not too interested in fighting this kind of preconception. A bientot, Armin. ___ 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] a feature i'd like to see in python #2: indexing of match objects
Aahz schrieb: >>> this one is fairly simple. if `m' is a match object, i'd like to be >>> able to write m[1] instead of m.group(1). (similarly, m[:] should return >>> the same as list(m.groups()).) this would remove some of the verbosity >>> of regexp code, with probably a net gain in readability; certainly no loss. >> Please post a patch to sf.net/projects/python (or its successor). > > Given the list of issues and subsequent discussion so far, I think a PEP > will be required. This needs more documentation than the typical patch. I disagree. So far, nobody has spoken against the proposed feature. It's really a small addition of a new method to an existing type. Entire classes have been added to the standard library without a PEP. People can still criticize the patch when its posted (and it's not clear that the OP is even willing to produce a patch). 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] Python and the Linux Standard Base (LSB)
Armin Rigo schrieb: > Ah, distutils are distributed in the base package now, but not the > 'config' subdirectory of a standard library's normal installation, which > makes distutils a bit useless. > > I should go and file a bug, I guess. The reason why I did not do it so > far, is that the fact that no one did tends to show that they really > think distributing 'config' is not the "right" thing to do. A reasoning > along the lines of: "this subdir contains include files, so it should go > in the python-dev package". I'm not too interested in fighting this > kind of preconception. It really depends on what you are trying to do with distutils. If you want to package or install a distutils module, you need much more than distutils: you may also need a compiler, you may need the complete set of Python header files, and you may need header files for the libraries your package depends on. So if you use distutils to install a package, it's IMO reasonable to require that the -dev package is installed. People use distutils for other purposes today as well, and these purposes might be supported now. 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] a feature i'd like to see in python #2: indexing of match objects
Fredrik Lundh schrieb:
>> Ah, right; I misread his proposal as saying that m[:] should return
>> [m[0]] + list(m.groups()) (rather, I expected that m.groups() would
>> include m.group(0)).
>
> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
> RE syntax (and we don't have much control over the latter).
py> m = re.match("a(b)","ab")
py> m.group(0)
'ab'
py> m.group(1)
'b'
>> To answer your first question: it is clearly groups that you want
>> to index, just as the .group() method indexes groups.
>
> so what should len(m) do?
That's a question: should len be supported at all? If so, it's clear
that len(m) == len(m[:]).
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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote:
>> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
>> RE syntax (and we don't have much control over the latter).
>
> py> m = re.match("a(b)","ab")
> py> m.group(0)
> 'ab'
> py> m.group(1)
> 'b'
0 isn't a group, it's an alias for the full match.
___
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] a feature i'd like to see in python #1: betteriteration control
"Ben Wing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > many times writing somewhat complex loops over lists i've found the need > to sometimes delete an item from the list. currently there's no easy > way to do so; basically, you have to write something like > > i = 0 > while i < len(list): > el = list[i] > ...do something... > if el should be deleted: >del list[i] > else: >i += 1 My view: while loops are the standard construct for iteration. They give you complete control over the control variable(s). Hence no need for 'better iteration control'. The above is easy enough and quite clear. > note that you can't write > > for x in list: > > or even > > for i in xrange(len(list)): For loops are for the common case of straightforwardly iterating over a sequence. They are efficient both to write and execute. Let's not mess with them. -1 > note also that you need to do some trickiness to adjust the index > appropriately when deleting. Iterate in reverse and no index adjustment is needed Terry Jan Reedy ___ 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] a feature i'd like to see in python #2: indexing of match objects
Fredrik Lundh schrieb:
>>> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
>>> RE syntax (and we don't have much control over the latter).
>> py> m = re.match("a(b)","ab")
>> py> m.group(0)
>> 'ab'
>> py> m.group(1)
>> 'b'
>
> 0 isn't a group, it's an alias for the full match.
So what is the proper term for the things that the .group() method
returns? According to
http://docs.python.org/lib/match-objects.html
it returns "subgroups of the match".
So the things to be indexed in this proposal are subgroups of the
match.
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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote:
> Fredrik Lundh schrieb:
match groups are numbered 1..N, not 0..(N-1), in both the API and in the
RE syntax (and we don't have much control over the latter).
>>> py> m = re.match("a(b)","ab")
>>> py> m.group(0)
>>> 'ab'
>>> py> m.group(1)
>>> 'b'
>> 0 isn't a group, it's an alias for the full match.
>
> So what is the proper term for the things that the .group() method
> returns? According to
>
> http://docs.python.org/lib/match-objects.html
>
> it returns "subgroups of the match".
>
> So the things to be indexed in this proposal are subgroups of the
> match.
>
Precisely. But your example had only one group "(b)" in it, which is
retrieved using m.group(1). So the subgroups are numbered starting from
1 and subgroup 0 is a special case which returns the whole match.
I know what the Zen says about special cases, but in this case the rules
were apparently broken with impunity.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
___
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] a feature i'd like to see in python #2: indexing of match objects
Steve Holden schrieb: > Precisely. But your example had only one group "(b)" in it, which is > retrieved using m.group(1). So the subgroups are numbered starting from > 1 and subgroup 0 is a special case which returns the whole match. > > I know what the Zen says about special cases, but in this case the rules > were apparently broken with impunity. Well, the proposal was to interpret m[i] as m.group(i), for all values of i. I can't see anything confusing with that. 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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: >> I know what the Zen says about special cases, but in this case the rules >> were apparently broken with impunity. > > Well, the proposal was to interpret m[i] as m.group(i), for all values > of i. I can't see anything confusing with that. it can quickly become rather confusing if you also interpret m[:] as m.groups(), not to mention if you add len() and arbitrary slicing to the mix. what about m[] and m[i,j,k], btw? ___ 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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: > Steve Holden schrieb: >> Precisely. But your example had only one group "(b)" in it, which is >> retrieved using m.group(1). So the subgroups are numbered starting from >> 1 and subgroup 0 is a special case which returns the whole match. >> >> I know what the Zen says about special cases, but in this case the rules >> were apparently broken with impunity. > > Well, the proposal was to interpret m[i] as m.group(i), for all values > of i. I can't see anything confusing with that. > I don't suppose that would be any more confusing than the present case. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] a feature i'd like to see in python #2: indexing of match objects
Fredrik Lundh wrote: > Martin v. Löwis wrote: > >>> I know what the Zen says about special cases, but in this case the rules >>> were apparently broken with impunity. >> >> Well, the proposal was to interpret m[i] as m.group(i), for all values >> of i. I can't see anything confusing with that. > > it can quickly become rather confusing if you also interpret m[:] as > m.groups(), not to mention if you add len() and arbitrary slicing to > the mix. what about m[] and m[i,j,k], btw? What about them? They aren't supposed to be supported by every object that allows subscript, are they? And why not just not implement len()? As for the [:] <-> groups() issue, [:] would have to be consistent with indexing and return the whole match and the subgroups. (Or, the API could be overhauled completely of course, remember it's Py3k.) Georg ___ 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] a feature i'd like to see in python #2: indexing of match objects
Georg Brandl wrote: > (Or, the API could be overhauled completely of course, remember it's Py3k.) Erm, no, it's not. Strike that remark. Georg ___ 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] a feature i'd like to see in python #2: indexing of match objects
Fredrik Lundh schrieb: > it can quickly become rather confusing if you also interpret m[:] as > m.groups(), not to mention if you add len() and arbitrary slicing to > the mix. what about m[] and m[i,j,k], btw? I take it that you are objecting to that feature, then? 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] a feature i'd like to see in python #2: indexing of match objects
Steve Holden wrote: > So the subgroups are numbered starting from > 1 and subgroup 0 is a special case which returns the whole match. But the subgroups can be nested too, so it's not really as special as all that. -- Greg ___ 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] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote:
> Aahz schrieb:
>
this one is fairly simple. if `m' is a match object, i'd like to be
able to write m[1] instead of m.group(1). (similarly, m[:] should return
the same as list(m.groups()).) this would remove some of the verbosity
of regexp code, with probably a net gain in readability; certainly no loss.
>>> Please post a patch to sf.net/projects/python (or its successor).
>>>
>> Given the list of issues and subsequent discussion so far, I think a PEP
>> will be required. This needs more documentation than the typical patch.
>>
>
> I disagree. So far, nobody has spoken against the proposed feature. It's
> really a small addition of a new method to an existing type. Entire
> classes have been added to the standard library without a PEP. People
> can still criticize the patch when its posted (and it's not clear that
> the OP is even willing to produce a patch).
>
>
i've never worked up a python patch before, but i imagine this wouldn't
be too hard.
it seems that m[1] should be m.group(1), and everything else should
follow. i forgot about m[0] when making my slice proposal; i suppose
then that m[:] should just do what we expect, and m[1:] = m.groups().
len(m) = 1 + number of groups, m['name'] = m.group('name').
the only strangeness here is the numbering of groups starting at 1, and
making 0 be a special case. this isn't any more (or less) of a problem
for the indexing form than it is for m.group(), and it's well known from
various other languages. we could always consider making groups start
at 0 for python 3000, but this seems to me like a gratuitous
incompatibility with the rest of the world.
ben
___
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] a feature i'd like to see in python #1: better iteration control
Brian Harring wrote: > On Sun, Dec 03, 2006 at 06:24:17AM -0600, Ben Wing wrote: > >> many times writing somewhat complex loops over lists i've found the need >> to sometimes delete an item from the list. currently there's no easy >> way to do so; basically, you have to write something like >> >> i = 0 >> while i < len(list): >> el = list[i] >> ...do something... >> if el should be deleted: >> del list[i] >> else: >> i += 1 >> >> note that you can't write >> >> for x in list: >> >> or even >> >> for i in xrange(len(list)): >> >> note also that you need to do some trickiness to adjust the index >> appropriately when deleting. >> >> i'd much rather see something like: >> >> for x:iter in list: >> ...do something... >> if x should be deleted: >> iter.delete() >> >> the idea is that you have a way of retrieving both the element itself >> and the iterator for the element, so that you can then call methods on >> the iterator. it shouldn't be too hard to implement iter.delete(), as >> well as iter.insert() and similar functions. (the recent changes to the >> generator protocol in 2.5 might help.) >> >> the only question then is how to access the iterator. the syntax i've >> proposed, with `x:iter', seems fairly logical (note that parallels with >> slice notation, which also uses a colon) and doesn't introduce any new >> operators. (comma is impossible since `for x,iter in list:' already has >> a meaning) >> >> btw someone is probably going to come out and say "why don't you just >> use a list comprehension with an `if' clause? the problems are [1] i'd >> like this to be destructive; >> > > Just use slice assignment. > > l = list(xrange(100)) > l2 = [x for x in l if x > 50] > l[:] = l2[:] > > >> [2] i'd like this to work over non-lists as well, e.g. hash-tables; >> > > There in is the sucky part; iterator protocol is simple; what you're > proposing is extending iterators so that they recall the last value > (else iter.delete() would not do anything), which... eh. > > Think it sucks, to say the least ;) > > Simple example of where this gets ugly is in iterating over a file. > > with some more thought i see that a language extension to `for' isn't needed, as you can write something like it = iter(foo) for x in it: ... but i still don't see why supporting iter.delete() is so wrong. clearly it doesn't need to work on files or other such things where it doesn't make sense. before you diss this completely, note that java supports exactly the same thing: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html remove public void *remove*() Removes from the underlying collection the last element returned by the iterator (optional operation). This method can be called only once per call to next. The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this method. *Throws:* |UnsupportedOperationException <../../java/lang/UnsupportedOperationException.html>| - if the remove operation is not supported by this Iterator. |IllegalStateException <../../java/lang/IllegalStateException.html>| - if the next method has not yet been called, or the remove method has already been called after the last call to the next method. ___ 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] features i'd like [Python 3000] ... #3: fix super()
i don't like the current super() at all. having to type super(Foo, self).__init__(...) is messy, hard to remember, and error-prone. it also introduces an unfortunate dependency in that the name of the class (Foo) has to be hard-coded in the call, and if you change the class name you also have to go and change all super() calls -- more chances for errors. as a result, i imagine there's a strong urge to just hardcode the name of the parent -- a bad idea, and the reason why super() was introduced in the first place. instead, `super' should work like in other languages. a couple of ideas: -- super.meth(args) calls the superclass method `meth', in the same way that super(Foo, self).meth(args) currently works. (this is the same syntax as in java. this probably requires making `super' be a keyword, although it might be possible to hack this by examining the current call stack.) -- as an alternative or in addition, super(args) would work like super.meth(args) if we're currently inside of `meth' in a subclass. i suspect that 90% of the time or more, `super' is used to chain to the superclass version of an overridden method, and this optimizes for the common case. it makes for one less possibility of misspelling `__init__' and one less thing that requires renaming if a method is renamed or code copied to another method (granted, this isn't such a big deal as in the case of class renaming). if the form `super.meth(args)' isn't also supported, then a call of this sort would have to be made through the introspection API. (i think it would be a good idea to have this functionality available through the introspection API, in any case. currently i don't see any obvious way in module `inspect' to find out which class a call to `super(...).meth(...)' is invoked on, although maybe a loop with inspect.getmro() and hasattr() would work. it would be nice to have a function like inspect.getsuper(class, 'meth'), i think.) ben ___ 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] a feature i'd like to see in python #1: better iteration control
On Sun, Dec 03, 2006 at 08:35:58PM -0600, Ben Wing wrote: > but i still don't see why supporting iter.delete() is so wrong. clearly > it doesn't need to work on files or other such things where it doesn't > make sense. > > before you diss this completely, note that java supports exactly the > same thing: > > http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html Not all iterators would support remove; that right there is a bit of an issue since right now, the only exception you need to expect for iterator protocol is StopIteration being thrown when the iterator has nothing more to yield. So, it's no longer simpler, which is a bit of a con in my opinion. Question is, where _would_ it work? Doesn't really make much sense for generators (doable with 2.5, but most generators are just that, generators, not modifiable views), doesn't make sense for itertools.* for the most part, since it's combination of iterators. For dict; it actually *cannot* work. You can't remove keys from a dict as you're iterating over it (can change the val of a key, but not remove the key). So iter.delete would require fair bit of changes internally to dict, either tracking what it's yielded already, or forcing iterkeys to actually be iter(keys()) (creating an intermediate list), which is worse for memory usage and general performance. Set's suffer the same thing; can't change what it contains while iterating, have to restart the iteration after a removal/addition. Tuples are immutable, so end of discusion there. Leaves lists... which personally, I view as a mostly bad thing to be doing anyways. Trying to pop an item out of the middle of a list results in shifting everything right of it one spot to the left; this sucks from a performance standpoint, again, worst case, quad. Now... occasionally, have to do it admittedly. But it's not something you actaully want to be doing in your code all that much- admittedly generating a new list to avoid that hit also sucks somewhat, but the worst case there is far more behaved, a temp trade of space vs runtime. What I'm trying to get at is that what iter(list).next().delete() would do isn't a good thing to paper over, it makes the op look like it costs nothing when it can cost a _lot_. Unless I'm missing something, the only real usage of this is a list (could do it on files also, although that would suffer the same issue as a list, just worse via truncate calls). Would work better on collections.deque, but deque is a linked list and used rather selectively. So... why add it, if it's basically for one major type, and it's not a good idea to blindly do such an action on that type in the first place? ~harring pgpRxoOMQd1ba.pgp Description: PGP signature ___ 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] a feature i'd like to see in python #1: better iteration control
Brian Harring wrote: > On Sun, Dec 03, 2006 at 08:35:58PM -0600, Ben Wing wrote: > >> but i still don't see why supporting iter.delete() is so wrong. clearly >> it doesn't need to work on files or other such things where it doesn't >> make sense. >> >> before you diss this completely, note that java supports exactly the >> same thing: >> >> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html >> > > Not all iterators would support remove; that right there is a bit of > an issue since right now, the only exception you need to expect for > iterator protocol is StopIteration being thrown when the iterator has > nothing more to yield. > > So, it's no longer simpler, which is a bit of a con in my opinion. > well, it's not like adding a new exception to any existing iterator method. it would only occur if you call iter.delete() in the wrong context. > For dict; it actually *cannot* work. You can't remove keys from a > dict as you're iterating over it (can change the val of a key, but not > remove the key). So iter.delete would require fair bit of changes > internally to dict, either tracking what it's yielded already, or > forcing iterkeys to actually be iter(keys()) (creating an intermediate > list), which is worse for memory usage and general performance. > > Set's suffer the same thing; can't change what it contains while > iterating, have to restart the iteration after a removal/addition. > > Leaves lists... which personally, I view as a mostly bad thing to be > doing anyways. Trying to pop an item out of the middle of a list > results in shifting everything right of it one spot to the left; this > sucks from a performance standpoint, again, worst case, quad. > > Now... occasionally, have to do it admittedly. But it's not something > you actaully want to be doing in your code all that much- admittedly > generating a new list to avoid that hit also sucks somewhat, but the > worst case there is far more behaved, a temp trade of space vs > runtime. > > What I'm trying to get at is that what iter(list).next().delete() > would do isn't a good thing to paper over, it makes the op look like > it costs nothing when it can cost a _lot_. > i do see your point. i was trying to remember what i ended up doing when i ran into this issue before, and in fact i ended up just making a new list and appending all the elements i didn't want to delete. i see you'd get N^2 behavior if you deleted lots of elements from a list, but you get the same thing currently if you call `del list[i]' a lot; it's not obvious that iter.delete() actually "papers over" the cost any more than `del list[i]' does. > Unless I'm missing something, the only real usage of this is a list > (could do it on files also, although that would suffer the same > issue as a list, just worse via truncate calls). Would work better on > collections.deque, but deque is a linked list and used rather > selectively. > > i actually think now this would be best for hash tables and such. copying a large hash table is a real drag, and using the iterator protocol is the *only* way to iterate over the elements of a hash table. in fact, i imagine this is exactly why java added this functionality. certainly in lisp, the `maphash' function explicitly allows you to delete the current element being iterated over, for the same reason. however, for hash tables there's no reason to use iter.delete(). you should just be able to write `del hash[x]'. is this disallowed currently? if so, it seems like something that should be fixed. > So... why add it, if it's basically for one major type, and it's > not a good idea to blindly do such an action on that type in the first > place? > ok, i see your point and i retract the suggestion. ben ___ 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] [NPERS] Re: a feature i'd like to see in python #1: betteriteration control
Terry Reedy wrote: > Iterate in reverse and no index adjustment is needed > > > a good idea, thanks. ___ 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] Makefile.pre.in Patch
The attached patch ensures that the $(DESTDIR) exists before installing the built binaries. It has been tested on Mac OS X. The patch is attached. -- Cheers, Hasan Diwan <[EMAIL PROTECTED]> Makefile.patch Description: Binary data ___ 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] features i'd like [Python 3000?] ... #4: interpolated strings ala perl
sorry to be casting multiple ideas at once to the list. i've been
looking into other languages recently and reading the recent PEP's and
such and it's helped crystallize ideas about what could be better about
python.
i see in PEP 3101 that there's some work going on to fix up the string
formatting capabilities of python. it looks good to me but it still
doesn't really address the lack of a simple interpolated string
mechanism, as in perl or ruby. i find myself constantly writing stuff like
text="Family: %s" % self.name
maybe_errout("%s, line %s: %s\n" % (title, lineno, errstr))
def __str__(self):
return "CCGFeatval(%s, parents=%s, licensing=%s)" % (
(self.name, self.parents, self.licensing))
and lots of similar examples that are just crying out for perl-style
variable interpolation. the proposals in PEP 3101 don't help much; i'd
get instead something like
maybe_errout("{0}, line {1}: {2}\n".format(title, lineno, errstr))
which isn't any better than the current % notation, or something like
maybe_errout("{title}, line {lineno}: {errstr}\n".format(title=title,
lineno=lineno, errstr=errstr))
where i have to repeat each interpolated variable three times. yuck
yuck yuck.
how about something nice like
maybe_errout(i"[title], line [lineno]: [errstr]\n")
or (with the first example above)
text=i"Family: [self.name]"
or (third example above)
def __str__(self):
return i"CCGFeatval([self.name], parents=[self.parents],
licensing=[self.licensing])"
the advantage of these is the same as for all such interpolations: the
interpolated variable is logically placed exactly where it will be
substituted, rather than somewhere else, with the brain needing to do
some additional cross-referencing.
`i' in front of a string indicates an "interpolated" string just like
`r' in the same position means "raw string". if you think this is too
invisible, you could maybe use `in' or something easier to see.
however, i could see a case being made for combining both `i' and `r' on
the same string, and so using a single letter seems to make the most sense.
formatting params can follow, e.g.
print i"The value of [stock[x]] is [stockval[x]:%6.2f]"
some comments:
1. i suggest brackets here so as to parallel but not interfere with PEP
3101, which uses braces; PEP 3101 is somewhat orthogonal to this
proposal and the two might want to coexist. i think using something
like brackets or braces is better than perl's $ convention (it
explicitly indicates the boundaries of the interpolation) and simpler
than ruby's #{...} or make's ${...}; since strings are only interpolated
if you specifically indicate this, there's less need to use funny
characters to avoid accidental interpolation.
2. as shown in the last example, format specifiers can be added to an
interpolation, as in PEP 3101. maybe the % is unnecessary.
3. as shown in various examples, things other than just straight
variables can be interpolated. the above examples include array/hash
references and object attributes. it's not exactly clear what should
and shouldn't be allowed. one possibility is just to allow an arbitrary
expression. PEP 3101 isn't going to do this because it's working on
existing strings (including ones that may come from the user), and so
allowing arbitrary expressions could lead to security holes. but here,
we're talking about immediate strings, so security holes of this sort
should not a concern.
4. the semantics of an interpolated string are exactly that of a series
of string concatenations, e.g.
return i"CCGFeatval([self.name], parents=[self.parents],
licensing=[self.licensing])"
is equivalent to
return "CCGFeatval(" + self.name + ", parents=" + self.parents + ",
licensing=" + self.licensing + ")"
ben
___
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] features i'd like [Python 3000?] ... #4: interpolated strings ala perl
Ben Wing wrote: > [interpolated strings] btw if people think this idea is good, i can certainly write it up in PEP form. ben ___ 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] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: >> it can quickly become rather confusing if you also interpret m[:] as >> m.groups(), not to mention if you add len() and arbitrary slicing to >> the mix. what about m[] and m[i,j,k], btw? > > I take it that you are objecting to that feature, then? I haven't seen a complete and self-consistent proposal yet, so that's not easy to say. ___ 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
