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:
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
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
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:
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;
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
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
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
-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()).)
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
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
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,
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
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
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
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
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.
/F
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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:
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
37 matches
Mail list logo
