<pre>
 # -*- coding: 1251 -*-

import locale

locale.setlocale(locale.LC_ALL, ".1251") #locale name may be Windows specific?

#-----------------------------------------------
print chr(184), chr(168)
assert  chr(255).upper() == chr(223) #OK
assert  chr(184).upper() == chr(168) #fail
#-----------------------------------------------
assert  'q'.upper() == 'Q' #OK 
assert  'ж'.upper() == 'Ж' #OK
assert  'Ж'.upper() == 'Ж' #OK
assert  'я'.upper() == 'Я' #OK
assert  u'ё'.upper() == u'Ё' #OK (locale independent)
assert  'ё'.upper() == 'Ё' #fail
</pre>

I suppose incorrect realization of uppercase like 

<pre>
if ('a' <= c && c <= 'я')
  return c+'Я'-'я'
</pre>

symbol 'ё' (184 in cp1251) is not in range 'a'-'я'

C-CRT library fucntion toupper('Ñ‘') works properly, if I set setlocale(LC_ALL, ".1251")

sorry, I mean 
toupper((int)(unsigned char)'Ñ‘') 
not just  toupper('Ñ‘') 

forgot to mention used python version - http://www.python.org/ftp/python/2.5/python-2.5.msi

You can see the implementation of .upper in

http://svn.python.org/projects/python/tags/r25/Objects/stringobject.c
(function string_upper)

Off-hand, I cannot see anything wrong in that code. It definitely does *not* use c+'Я'-'я'.

well, C:
----------------------------

#include <locale.h>
#include <stdio.h>
#include <assert.h>

int main()
{
  int i = 184;
  char *old = setlocale(LC_CTYPE, ".1251");
  assert(old);
  printf("%d -> %d\n", i, _toupper(i));   
  printf("%d -> %d\n", i, toupper(i));   
}

----------------------------
C ouput: 
184 -> 152
184 -> 168

so, _toupper and upper are different functions. MSDN does not mention nothing about difference, except that 'toupper' is "ANSI compatible" :(



File Added: toupper.zip

----------------------------------------------
standard header ctype.h:

#define _toupper(_c)    ( (_c)-'a'+'A' )


----------------------------------------------
CRT file toupper.c:



/* define function-like macro equivalent to _toupper()
 */
#define mkupper(c)  ( (c)-'a'+'A' )



int __cdecl _toupper (
        int c
        )
{
        return(mkupper(c));
}

( http://www.everfall.com/paste/id.php?j13ernl40i9e )

suggestion: replace _toupper with toupper. Performance may degrade ( a lot thread locks/MultiByteToWideChar/other code for every non-ASCII lowercase symbol). Sugestion for optimization: setup "int toupper_table[256]"  (and other tables) in everycall to setlocale.

May be related to issue 1633600.

I've tried to see if this is still an issue but frankly can't make head nor tail out of it :(  Any locale gurus up for this?

the OP is right: str.upper is supposed to be locale-dependent
http://docs.python.org/library/stdtypes.html#str.upper

But the implementation uses _toupper() which is a macro with Visual Studio, and obviously not locale-dependent:

#define _toupper(_Char)    ( (_Char)-'a'+'A' )

Am I correct in saying that fixing this wouldn't help much as there are known issues with locales on Windows, e.g. #10466 ?

No, the issues with locale on Windows have to do with the locale names.  Locale otherwise works fine on windows.

With Python3 .upper() is locale-independent for unicode and bytes strings.
For serious work with non-ascii text Python3 is strongly recommended anyway, so I suggest to close this issue.

I agree that it's better not to touch this in 2.x.