Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #19232 > unrolled thread

Trouble with internationalized path under windows

Back to article view | Back to comp.lang.python

Contents

  Trouble with internationalized path under windows Jacob Hallén <jacob.hallen@sotospeak.se> - 2012-01-22 21:08 +0100
    Re: Trouble with internationalized path under windows Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-22 12:52 -0800
      Re: Trouble with internationalized path under windows Michael Torrie <torriem@gmail.com> - 2012-01-22 17:47 -0700
        Re: Trouble with internationalized path under windows Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-22 17:49 -0800
          Re: Trouble with internationalized path under windows Chris Angelico <rosuav@gmail.com> - 2012-01-23 19:17 +1100

#19232 — Trouble with internationalized path under windows

I have a problem which ought to have an obvious solution, but I haven't found 
one despite searching for many hours. The problem occurs on Windows.

This is a version of my problem reduced to its essentials:

I have a file foo.py::

import bar

and a file bar.py :

baz = 42

If I store these two files  in say C:\Users\Admin\test everything works fine.

If I store them in C:\Users\Admin\testф, I get an import error when running 
foo.py. The letter at the end of test is a Russian "F", if it looks strange on 
your terminal.

Am using WIndows 7 with a Swedish locale. The program uses Unicode 
successfully internally, and the Windows help says that the locale only 
applies to non-Unicode programs. I have tried with using characters from the 
Latin-1 character set in the path, ones that are not in the ASCII character 
set. In this case, things work fine.

What am  missing?

[toc] | [next] | [standalone]

#19237

On Jan 22, 2:08 pm, Jacob Hallén <jacob.hal...@sotospeak.se> wrote:

> If I store these two files  in say C:\Users\Admin\test everything works fine.
>
> If I store them in C:\Users\Admin\testф, I get an import error when running
> foo.py. The letter at the end of test is a Russian "F", if it looks strange on
> your terminal.

If *only* i had a penny for every problem that Unicode caused... maybe
i could i buy a 76,000 sqft mansion, because, people should not be
forced to sleep in the same room twice!

Unicode is just another Utopian nightmare. When will the lemmings
realize that character encoding IS NOT the root of the problem? You
will NEVER find the holy grail of encodings that will solve the
collaborative issue because the PROBLEM is multiplicity! Self induced!

[toc] | [prev] | [next] | [standalone]

#19243

On 01/22/2012 01:52 PM, Rick Johnson wrote:
> On Jan 22, 2:08 pm, Jacob Hallén <jacob.hal...@sotospeak.se> wrote:
> 
>> If I store these two files  in say C:\Users\Admin\test everything works fine.
>>
>> If I store them in C:\Users\Admin\testф, I get an import error when running
>> foo.py. The letter at the end of test is a Russian "F", if it looks strange on
>> your terminal.
> 
> If *only* i had a penny for every problem that Unicode caused... maybe
> i could i buy a 76,000 sqft mansion, because, people should not be
> forced to sleep in the same room twice!
> 
> Unicode is just another Utopian nightmare. When will the lemmings
> realize that character encoding IS NOT the root of the problem? You
> will NEVER find the holy grail of encodings that will solve the
> collaborative issue because the PROBLEM is multiplicity! Self induced!

Um, face palm.  I'm so embarrassed for you Rick.  The problem appears
not be with programming or handling character sets or anything like
that.  Then you go on to say let's stick to English?  Just wow.  At
least you are being entertaining for now.

I once argued to limit Python identifiers to latin letters only, but at
least that made some sort of sense (lowest-common denominator) and it
had nothing to do with running in an internationalized environment or
dealing with unicode or utf-8 -encoded text files.

The OP's problem definitely sounds like a Python bug on Windows to me.
I've never had similar problems on other internationalized OS's like
Linux or OS X.

How can you be Python's savior when you want to discount out of hand at
least have of Python's users?

[toc] | [prev] | [next] | [standalone]

#19247

On Jan 22, 6:47 pm, Michael Torrie <torr...@gmail.com> wrote:
> I once argued to limit Python identifiers to latin letters only, but at
> least that made some sort of sense (lowest-common denominator) and it
> had nothing to do with running in an internationalized environment or
> dealing with unicode or utf-8 -encoded text files.
> [...]
> How can you be Python's savior when you want to discount out of hand at
> least [half] of Python's users?

I don't want to limit ANYONE's usage of Python, quite the contrary. My
crusade against Unicode is to the benefit of all peoples of this
planet. Actually my crusade is even greater than Unicode itself. It's
a crusade for unity. The problem with humans is that we just simply
accept most things too easily. We never stop to ask ourselves "why"?

<tangential meanderings>
Did you know that when a driver's car breaks down on a lonely county
road he has a significantly higher chance of receiving help from
passers-by than a driver broke down on a busy highway? Why does this
happen? I'll tell you why -- and it's not because "country folk" are
more helpful than "city folk".

The reason is blind acceptance. The reason is lack of
inquisitiveness.

Many of the folks who drive by on the major freeway want to stop and
help, but they don't because they convince themselves that since SO
MANY folks are driving by, surely *somebody* will stop and help. Well,
the problem is, everyone imagines the same outcome and the poor sap
broke down on the interstate NEVER receives any help.
</tangential meanderings>

The fact is, Unicode is nothing more than a monkey patch for language
multiplicity. A multiplicity that is perpetuated on the masses due to
a blind adherence to the cult of xenophobia. My mission is plant seeds
of inquisitiveness in the minds of these people. To help them
understand that they do not need to suffer the under the pain of
multiplicity any longer. And finally, to help them understand that we
must destroy multiplicity before we can evolve to the next level.

[toc] | [prev] | [next] | [standalone]

#19251

On Mon, Jan 23, 2012 at 12:49 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> The fact is, Unicode is nothing more than a monkey patch for language
> multiplicity. A multiplicity that is perpetuated on the masses due to
> a blind adherence to the cult of xenophobia.

I agree. We need to abolish all languages but one, and let that one
language be at once a natural language, an algebraic language, a
programming language, and unprintable language (because let's face it,
once you do the rest, most people will demand profanity). Once again,
when there is a need, the solution can be found.

http://esolangs.org/wiki/Ook!

This is a very simple language; anyone could learn it in a day. It is
also an expressive language - it can be mathematically proven to be as
powerful as any other on the market (more so than many!). Rick, don't
fork Python; fork Ook and be the true savior of the world!

Chris Angelico

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web