Triage: Fixing type

+1 - I'd like to see screen names and IDs.

Important: Please do not change the default behavior of the method. I have a live
system running on those methods now and it will cause a big mess if you change the
default behavior of returning a list of ids.

To return screen names, please add it as a selectable option.

Someone else here wanted screen names and ids. Perhaps that could be a third option.

I would appreciate username along with userid

Please not _instead_of_   I use only ID and also, don't change the return value by default, we have running system 
using this new API.

Agree with this request, include screennames with IDs as an optional field that can 
be request in the method call

+1 for this, it's not technically necessary for me for the moment, but it would allow
me to give my users those links for new followers, which would be nice.

+1 for adding usernames as well as IDs

+1 I would also like name and screenname added to the IDs. This will decrease API
calls very much

Updated the summary to reflect what the change is rather than how much it is needed.
Still discussing internally.

user name & user id - still adjusting to use the system.

Adding in usernames ruins the performance of these API methods. As they are, we fetch data from a single data 
store in our architecture to return the lists of IDs. In order to provide usernames, we'd have to bog down this 
request by joining together multiple sources of data.

 Issue 348  has been merged into this issue.

 Issue 519  has been merged into this issue.

So what you're saying is that you'd rather have me send you 500 requests to reproduce this myself than one 
somewhat slow request? Relational databases are designed to fetch large quantities of information very quickly; I 
find it difficult to comprehend what makes this so impossible.

Alex, sorry, I only now saw your reply from Feb 18.

Perhaps we then need to take a different approach.

I have a need to a very light-weight method to convert the <id> to the corresponding
<screen_name>. Retrieving the full user profile to do this is a complete overkill,
and consumes far more bandwidth that necessary.

In other words, I need something like /users/convert.xml?id=id and
/users/convert.xml?screen_name=screen_name.

Why not just add the usernames to the denormalized data up front? No need for a data
join on each request.

One way or another, there needs to be an easy, *cheap* way to convert ids to
usernames (and vice-versa). It is great that you can get 5000 ids per request, but if
you cannot easily get the screen names for these, things get complicated as well as
api-intensive.

Is the "status = WontFix" final? 

Perhaps the folks at twitter are willing to reconsider adding api call(s) to
bulk-translate between screen_names and ids. In certain circumstances, this would be
extremely useful, and would cut down on a lot of calls made simply to obtain this
translation (as mentioned by several above).

Together with the Search API having different ids, this is becoming really annoying.
Please fix asap.

Adding link from the wiki: http://groups.google.com/group/twitter-development-
talk/browse_frm/thread/98f4c4d13954e8bf/4b511a0455f8bffe?
lnk=gst&q=social+graph+screen+name#4b511a0455f8bffe

I know there's been a ton of request for a followers/screen_names API,   
or a friends/screen_names one for that matter. Right now the only way   
of getting all of a user's followers is with http://twitter.com/followers/ids.xml 
  and that only renders the id's. There's no efficient way of getting   
the associated screen_names without doing hundreds/thousands/millions   
of calls or running into API rate limits. Twitter has rejected the   
creation of a followers/screen_names API due to "performance issues/ 
concerns". What if I or you want to present our app users with a human   
readable list of their followers/friends. I believe the alternative is   
a much more performance heavy approach for Twitter. What's to stop me   
from creating a 1000 (or more) unique users that my app/service uses   
to resolve id's into screen_names? That way I would have hundreds of   
thousands of API calls available each hour and could easily create a   
locally cached db of id-to-screen_name pairs. And of course I would   
have to recheck all of them every few days or so to account for   
screen_name changes, since there isn't an API for that either. All of   
this would result in millions of API calls a day, just to do something   
that Twitter could enable with one simple API... Hell, I could   
register a hundred thousand users, and create a service that maintains   
an id-to-screen_name pair db for Twitter's entire userbase and make it   
available to the dev community as a service to work around this   
issue... What do you think? Wouldn't it be much easier and beneficial   
to Twitter to enable this simple API that many of us have been asking   
for for so long now? 
I look forward to you thoughts... 
Michael 

I do remember the discussion a while back about this being unlikely to happen.

I just wonder how is everyone else getting around the lack of such a function?

If the only way right now is to pull pages & pages of statuses/friends or /followers
I would have imagined it's quite a hit on the servers.