Multiple posts to bypass the 140 char limit per message about python-twitter HOT 15 CLOSED

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

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?

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.

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.

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

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

Regards,
Rogério Schneider

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

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?

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.

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.

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

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

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.

That is ok the way it is. Thanks again.