a splitting headache

M

Mensanator

All I wanted to do is split a binary number into two lists,
a list of blocks of consecutive ones and another list of
blocks of consecutive zeroes.

But no, you can't do that.
['', '', '1', '', '', '', '11', '']

Ok, the consecutive delimiters appear as empty strings for
reasons unknown (except for the first one). Except when they
start or end the string in which case the first one is included.

Maybe there's a reason for this inconsistent behaviour but you
won't find it in the documentation.

And the re module doesn't help.
['', '', '1', '2', '', '3', '', '', '4', '', '', '', '']

OTOH, if my digits were seperated by whitespace, I could use
str.split(), which behaves differently (but not re.split()
because it requires a string argument).
['1', '11', '111', '11']


That means I can use re to solve my problem after all.
c = '0010000110'
re.sub('0',' ',c).split() ['1', '11']
re.sub('1',' ',c).split()
['00', '0000', '0']

Would it have been that difficult to show in the documentation
how to do this?
 
M

Mel

Mensanator said:
All I wanted to do is split a binary number into two lists,
a list of blocks of consecutive ones and another list of
blocks of consecutive zeroes.

But no, you can't do that.
['', '', '1', '', '', '', '11', ''] [ ... ]
OTOH, if my digits were seperated by whitespace, I could use
str.split(), which behaves differently

Hmm. You could.

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.['00', '1', '0000', '11', '0']


Mel.
 
J

John O'Hagan

All I wanted to do is split a binary number into two lists,
a list of blocks of consecutive ones and another list of
blocks of consecutive zeroes.
[...]
That means I can use re to solve my problem after all.

['1', '11']

['00', '0000', '0']
[...]

Or without resorting to re:

c.replace('0', ' ').split()
c.replace('1', ' ').split()

Three or four times faster, too!

Regards,

John
 
P

Paul Rubin

Mensanator said:
And the re module doesn't help.
['', '', '1', '2', '', '3', '', '', '4', '', '', '', '']

filter(bool, re.split(' ', f))

You might also like:

from itertools import groupby
c = '0010000110'
print list(list(xs) for k,xs in groupby(c))
 
I

Ishwor Gurung

2009/10/16 Paul Rubin said:
You might also like:

   from itertools import groupby
   c = '0010000110'
   print list(list(xs) for k,xs in groupby(c))
Too bad groupby is only available in Python2.6+
Since you're here, any chance of getting your NDK team to look into
getting some small subset of STL, Boost into Android? :p That'd be
awesome thing you know.
 
I

Ishwor Gurung

2009/10/16 Ishwor Gurung said:
Too bad groupby is only available in Python2.6+
OK. I stand corrected ;-)
Since you're here, any chance of getting your NDK team to look into
getting some small subset of STL, Boost into Android? :p That'd be
awesome thing you know.
Yeah? Anything forthcoming in the releases to address this? thanks.
 
P

Paul Rubin

Ishwor Gurung said:
Since you're here, any chance of getting your NDK team to look into
getting some small subset of STL, Boost into Android? :p That'd be
awesome thing you know.

My what who where? You are confusing me with someone else.
 
T

Thomas

All I wanted to do is split a binary number into two lists,
a list of blocks of consecutive ones and another list of
blocks of consecutive zeroes.

But no, you can't do that.

['', '', '1', '', '', '', '11', '']

Ok, the consecutive delimiters appear as empty strings for
reasons unknown (except for the first one). Except when they
start or end the string in which case the first one is included.

Maybe there's a reason for this inconsistent behaviour but you
won't find it in the documentation.

And the re module doesn't help.

['', '', '1', '2', '', '3', '', '', '4', '', '', '', '']

OTOH, if my digits were seperated by whitespace, I could use
str.split(), which behaves differently (but not re.split()
because it requires a string argument).

['1', '11', '111', '11']

That means I can use re to solve my problem after all.
c = '0010000110'
re.sub('0',' ',c).split() ['1', '11']
re.sub('1',' ',c).split()

['00', '0000', '0']

Would it have been that difficult to show in the documentation
how to do this?


PythonWin 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin'
for further copyright information.['0', '0', '1', '0', '1', '0', '1', '1', '1', '1', '0', '0', '1', '0',
'1']
TC
 
C

Carl Banks

Too bad groupby is only available in Python2.6+
Since you're here, any chance of getting your NDK team to look into
getting some small subset of STL, Boost into Android?

Aren't Java collections bad enough? :)


Carl Banks
 
M

Mensanator

All I wanted to do is split a binary number into two lists,
a list of blocks of consecutive ones and another list of
blocks of consecutive zeroes.
But no, you can't do that.
['', '', '1', '', '', '', '11', '']
Ok, the consecutive delimiters appear as empty strings for
reasons unknown (except for the first one). Except when they
start or end the string in which case the first one is included.
Maybe there's a reason for this inconsistent behaviour but you
won't find it in the documentation.
And the re module doesn't help.
['', '', '1', '2', '', '3', '', '', '4', '', '', '', '']
OTOH, if my digits were seperated by whitespace, I could use
str.split(), which behaves differently (but not re.split()
because it requires a string argument).
['1', '11', '111', '11']
That means I can use re to solve my problem after all.
c = '0010000110'
re.sub('0',' ',c).split() ['1', '11']
re.sub('1',' ',c).split()
['00', '0000', '0']
Would it have been that difficult to show in the documentation
how to do this?

PythonWin 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin'
for further copyright information.>>> list('001010111100101')

['0', '0', '1', '0', '1', '0', '1', '1', '1', '1', '0', '0', '1', '0',
'1']

Thanks, but what I wanted was
['00','1','0','1','0','1111','00','1','0' '1'].
 
P

Paul Rubin

Mensanator said:
Thanks, but what I wanted was
['00','1','0','1','0','1111','00','1','0' '1'].
['00', '1', '0', '1', '0', '1111', '00', '1', '0', '1']

is really not that unnatural.
 
M

Mensanator

Mensanator said:
Thanks, but what I wanted was
['00','1','0','1','0','1111','00','1','0' '1'].

� � >>> c = '001010111100101'
� � >>> list(''.join(g) for k,g in groupby(c))
� � ['00', '1', '0', '1', '0', '1111', '00', '1', '0', '1']

is really not that unnatural.

I thought someone else had suggested this solution earlier.
Oh yeah, some guy named Paul Rubin. At first, I thought I
needed to keep the 1's and 0's in seperate lists, but now that
I see this example, I'm rethinking that.

Thanks, and thanks to Paul Rubin.
 
M

Mensanator

All I wanted to do is split a binary number into two lists, a list of
blocks of consecutive ones and another list of blocks of consecutive
zeroes.
But no, you can't do that.
c = '0010000110'
c.split('0')
['', '', '1', '', '', '', '11', '']
Ok, the consecutive delimiters appear as empty strings for reasons
unknown (except for the first one). Except when they start or end the
string in which case the first one is included.
Maybe there's a reason for this inconsistent behaviour but you won't
find it in the documentation.

Wanna bet? I'm not sure whether you're claiming that the behavior
is not specified in the docs or the reason for it. The behavior
certainly is specified. I conjecture you think the behavior itself
is not specified,

The problem is that the docs give a single example
['1','','2']

ignoring the special case of leading/trailing delimiters. Yes, if you
think it through, ',1,,2,'.split(',') should return ['','1','','2','']
for exactly the reasons you give.

Trouble is, we often find ourselves doing ' 1 2 '.split() which
returns
['1','2'].

I'm not saying either behaviour is wrong, it's just not obvious that
the
one behaviour doesn't follow from the other and the documentation
could be
a little clearer on this matter. It might make a bit more sense to
actually
mention the slpit(sep) behavior that split() doesn't do.
 
M

Mensanator

On Thu, 15 Oct 2009 18:18:09 -0700, Mensanator wrote:
All I wanted to do is split a binary number into two lists, a list of
blocks of consecutive ones and another list of blocks of consecutive
zeroes.
But no, you can't do that.
c = '0010000110'
c.split('0')
['', '', '1', '', '', '', '11', '']
Ok, the consecutive delimiters appear as empty strings for reasons
unknown (except for the first one). Except when they start or end the
string in which case the first one is included.
Maybe there's a reason for this inconsistent behaviour but you won't
find it in the documentation.
Wanna bet? I'm not sure whether you're claiming that the behavior is
not specified in the docs or the reason for it. The behavior certainly
is specified. I conjecture you think the behavior itself is not
specified,
The problem is that the docs give a single example
'1,,2'.split(',')
['1','','2']

ignoring the special case of leading/trailing delimiters. Yes, if you
think it through, ',1,,2,'.split(',') should return ['','1','','2','']
for exactly the reasons you give.
Trouble is, we often find ourselves doing ' 1  2  '.split() which
returns
['1','2'].
I'm not saying either behaviour is wrong, it's just not obvious that the
one behaviour doesn't follow from the other and the documentation could
be
a little clearer on this matter. It might make a bit more sense to
actually
mention the slpit(sep) behavior that split() doesn't do.

Have you _read_ the docs?
Yes.

They're quite clear on the difference
between no sep (or sep=None) and sep=something:

I disagree that they are "quite clear". The first paragraph makes no
mention of leading or trailing delimiters and they show no example
of such usage. An example would at least force me to think about it
if it isn't specifically mentioned in the paragraph.

One could infer from the second paragraph that, as it doesn't return
empty stings from leading and trailing whitespace, slpit(sep) does
for leading/trailing delimiters. Of course, why would I even be
reading
this paragraph when I'm trying to understand split(sep)?

The splitting of real strings is just as important, if not more so,
than the behaviour of splitting empty strings. Especially when the
behaviour is radically different.
['', '1', '', '', '', '11', '']

is a perfect example. It shows the empty strings generated from the
leading and trailing delimiters, and also that you get 3 empty
strings
between the '1's, not 4. When creating documentation, it is always a
good idea to document such cases.

And you'll then want to compare this to the equivalent whitespace
case:['1', '11']

And it wouldn't hurt to point this out:'010000110'

and note that it won't work with the whitespace version.

No, I have not submitted a request to change the documentation, I was
looking for some feedback here. And it seems that no one else
considers
the documentation wanting.
"If sep is given, consecutive delimiters are not grouped together and are
deemed to delimit empty strings (for example, '1,,2'.split(',') returns
['1', '', '2']). The sep argument may consist of multiple characters (for
example, '1<>2<>3'.split('<>') returns ['1', '2', '3']). Splitting an
empty string with a specified separator returns [''].

If sep is not specified or is None, a different splitting algorithm is
applied: runs of consecutive whitespace are regarded as a single
separator, and the result will contain no empty strings at the start or
end if the string has leading or trailing whitespace. Consequently,
splitting an empty string or a string consisting of just whitespace with
a None separator returns []."




 
J

John Yeung

['', '1', '', '', '', '11', '']

is a perfect example. It shows the empty strings
generated from the leading and trailing delimiters,
and also that you get 3 empty strings between the
'1's, not 4. When creating documentation, it is
always a good idea to document such cases.

It's documented. It's even in the example (that you cited yourself):

'1,,2'.split(',') returns ['1', '', '2']

There are two commas between the '1' and the '2', but "only" one empty
string between them. To me, it's obvious that

'1,,2'.split(',')

is equivalent to

'1002'.split('0')
And you'll then want to compare this to the
equivalent whitespace case:
['1', '11']

The documentation could not be more explicit that when the separator
is not specified or is None, it behaves very differently.

Have you tried to see what happens with

' 1 11 '.split(' ')

(Hint: The separator is (a kind of) white space... yet IS specified.)
I was looking for some feedback here.
And it seems that no one else considers the
documentation wanting.

This particular section of documentation, no. I have issues with some
of the documentation here and there; this is not one of those areas.

You kept using phrases in your arguments like "Yes, if you
think it through" and "An example would at least force me to think
about it". Um... are we not supposed to think?

John
 
C

Carl Banks

Have you _read_ the docs? They're quite clear on the difference
between no sep (or sep=None) and sep=something:

Even if the docs do describe the behavior adequately, he has a point
that the documents should emphasize the counterintutive split
personality of the method better.

s.split() and s.split(sep) do different things, and there is no string
sep that can make s.split(sep) behave like s.split(). That's not
unheard of but it does go against our typical expectations. It would
have been a better library design if s.split() and s.split(sep) were
different methods.

That they are the same method isn't the end of the world but the
documentation really ought to emphasize its dual nature.


Carl Banks
 
R

rurpy

Even if the docs do describe the behavior adequately, he has a point
that the documents should emphasize the counterintutive split
personality of the method better.

s.split() and s.split(sep) do different things, and there is no string
sep that can make s.split(sep) behave like s.split(). That's not
unheard of but it does go against our typical expectations. It would
have been a better library design if s.split() and s.split(sep) were
different methods.

That they are the same method isn't the end of the world but the
documentation really ought to emphasize its dual nature.

I would also offer that the example

'1,,2'.split(',') returns ['1', '', '2'])

could be improved by including a sep instance at the
beginning or end of the string, like

'1,,2,'.split(',') returns ['1', '', '2', ''])

since that illustrates another difference between the
sep and non-sep cases.
 
M

Mensanator

['', '1', '', '', '', '11', '']
is a perfect example. It shows the empty strings
generated from the leading and trailing delimiters,
and also that you get 3 empty strings between the
'1's, not 4. When creating documentation, it is
always a good idea to document such cases.

It's documented. �

What does 'it' refer to? A leading or trailing
delimiter? That's what _I_ was refering to.
It's even in the example

No, it is not.
(that you cited yourself):

� '1,,2'.split(',') returns ['1', '', '2']

There are two commas between the '1' and the '2', but "only" one empty
string between them. �To me, it's obvious that

� '1,,2'.split(',')

is equivalent to

� '1002'.split('0')

That wasn't what I was complaining about.
And you'll then want to compare this to the
equivalent whitespace case:
' 1 � �11 '.split()
['1', '11']

The documentation could not be more explicit that when the separator
is not specified or is None, it behaves very differently.

I am not complaining that it behaves differently, but
the description of said difference could be better
explained.
Have you tried to see what happens with

� ' 1 � �11 '.split(' ')

Yes, I actually did that test.
(Hint: �The separator is (a kind of) white space... yet IS specified.

And yet doesn't behave like .split(). In other words,
when specified, whitespace does not behave like
whitespace. Is it any wonder I have a headache?
)


This particular section of documentation, no. �I have issues with some
of the documentation here and there; this is not one of those areas.

You kept using phrases in your arguments like "Yes, if you
think it through" and "An example would at least force me to think
about it". �Um... are we not supposed to think?

No, you are not. Documentation isn't supposed to give
you hints so that you can work out the way things
behave. It should provide adequete explantion along
with unambiguous, complete examples. The thinking part
comes into play as you try to figure out how to apply
what you have just learned.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top