Multiple posts to bypass the 140 char limit per message

[GoogleCodeExporter]

I made this patch so the user, instead of receiving an error
on posting a message over the limit of 140 chars, will be let to
post multiple and recursive messages to complete his post.

Example post:
--
# The start of this test. TODO SOLVED! (breaking long/big messages, but not
the words/links!) Posting from python-twitter->

# ...(http://code.google.com/p/py...) patched in my ipython
(http://ipython.scipy.org/moin/) shell. This is a message bigger than->

# ...140 chars, the limitation for individual messages here in Twitter.
This little patch I made a few minutes ago is for breaking this big->

# ...messages into little ones (140 chars each), putting these "..." and
"->" markers to signal that this post is to be "continued" in the->

# ...next post. The post order is reverse, so, the last part of the
splitted message is sent first to the Twitter, so to read it, aggregating->

# ... the separated parts, is easily done. Motivation? To post freely
without having to count bytes. The end of this test.
--

Patch attached. Made to fit into rev 126 (current for today).

Thank you for this awesome module.

Regards,
Rogério Schneider

Original issue reported on code.google.com by stockrt on 19 Feb 2009 at 3:02

Attachments:

• patch-multiple-posts-rev126.diff

[GoogleCodeExporter]

Hmm. We probably should do something like this. Maybe with an 'auto_split' flag 
or
something?

Original comment by dclinton on 19 Feb 2009 at 4:07

• Changed state: Accepted

[GoogleCodeExporter]

I believe this should be automatic, so the user didn't get bored with error 
messages,
or, instead of an error, raise an alert, asking the user to use this 
'auto_split'
flag/feature for larger messages than 140c, sure.
Should I submit a patch with this flag?
Any other observations?

Original comment by stockrt on 19 Feb 2009 at 4:16

[GoogleCodeExporter]

I'd vote for an 'auto_split' flag like dclinton suggested. The 140 character 
limit is
well-known, and people would probably expect to have some kind of warning or 
error
that they hit that limit unless they explicitly chose to have their messages 
split up.

Original comment by brad.cav...@gmail.com on 19 Feb 2009 at 7:06

[GoogleCodeExporter]

I agree with dclinton and brad.cavanagh...there should be an optional parameter 
to
PostUpdate to enable this behavior.  By default it should raise an error as 
before. 
Principle of least surprise: user text should not be munged unless user 
requested the
munging feature be turned on.

I really like the sample output; this is an attractive way of splitting 
updates, and
I like that you did it at word boundaries.

Original comment by marcmagus@gmail.com on 20 Feb 2009 at 3:59

[GoogleCodeExporter]

Original comment by marcmagus@gmail.com on 20 Feb 2009 at 4:00

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

People, there is the patch using an option flag for the api.PostUpdate() method:

..
+  def PostUpdate(self, text, auto_split=False):
..
+    if len(text) > max_size and not auto_split:
+      raise TwitterError("Text must be less than or equal to %d characters. 
Consider
using 'auto_split' option." % max_size)
..

Regards,
Rogério Schneider

Original comment by stockrt on 23 Feb 2009 at 5:25

Attachments:

• patch-auto_split-rev131.diff

[GoogleCodeExporter]

Hey, here is a patch working with the latest rev132, commited today. I did the 
merge,
and testing was ok.

Regards,
Rogério Schneider

Original comment by stockrt on 26 Feb 2009 at 3:53

Attachments:

• patch-auto_split-rev132.diff

[GoogleCodeExporter]

I have some comments about the code itself.  Are you comfortable with me 
changing
things before applying it?

Original comment by dclinton on 26 Feb 2009 at 4:08

[GoogleCodeExporter]

For sure I am! You can change this the way you need to better fit python-twitter
standards.
The comments you have, can you share?

Original comment by stockrt on 26 Feb 2009 at 4:12

[GoogleCodeExporter]

I checked in my own implementation of this in r133:

  http://code.google.com/p/python-twitter/source/detail?r=133

I decided to create a new method called 'PostUpdates', rather than use an
'auto_split' flag on the original 'PostUpdate' method.  The reason being that
multiple updates require a list of Status instances as a return value, where as 
the
existing PostUpdates returns only a single instance. So rather than have one 
method
return both a list and a single Status, I just created a new method.

Please review the changes at your convenience.

Original comment by dclinton on 1 Mar 2009 at 8:11

• Changed state: Fixed

[GoogleCodeExporter]

Also just added the feature to provide a continuation string to messages that 
are
split.  It defaults to None, but try calling PostUpdates with continuation=' 
…' for a
nice example.

Original comment by dclinton on 1 Mar 2009 at 10:36

[GoogleCodeExporter]

The implementation is very nice. I confess I didn't know 'textwrap' module 
before.
Another learning time for me. Multiple results as return are also the correct 
way to
do it.
Thanks for commiting.

Regards,
Rogério Schneider

Original comment by stockrt on 2 Mar 2009 at 3:03

[GoogleCodeExporter]

DeWitt, I would like to observe some points in this solution.
- You didn't place a 'reverse post order', so it would be more easy to read the 
posts
in user's page. First line of the splited message should be posted by last.
- The 'continuation' is placed in the wrong place, if we try to revert the post
order. for example, the last post should not have this continuation, since it 
is the
last post.
My code addressed this issues, can you check?

Regards,
Rogério Schneider

Original comment by stockrt on 2 Mar 2009 at 3:46

[GoogleCodeExporter]

Thanks, Rogério.  I don't reverse on purpose because the posts will arrive in
chronological ordering, which feels more correct in the normal use case. 
Reversing
just so they show up in order top to bottom in certain clients (like 
twitter.com)
seems like the wrong fix. If you feel strongly about this I could add a 
'reverse'
option that defaults to False.

Original comment by dclinton on 2 Mar 2009 at 4:06

[GoogleCodeExporter]

That is ok the way it is. Thanks again.

Original comment by stockrt on 6 Mar 2009 at 2:54