Re: Issue with MySQLdb wrapper

[jmg3000]

On May 15, 7:22 pm, Gerard M <[EMAIL PROTECTED]> wrote:
> Hi guys I have a big problem with this wrapper im using Ubuntu 7.04
> and I want to install python-MySQLdb, I used synaptics and it is
> installed, but when I try to do>>> import MySQLdb
>
> and  I get this error:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "MySQLdb/__init__.py", line 19, in 
> import _mysql
> ImportError: No module named _mysql

Looks like the install of MySQLdb is botched up. You might try and use
the Ubuntu package management tool to check your installation for
correctness. If that tells you everything is ok and it's still busted,
you might try to uninstall, then reinstall MySQLdb.

If that still doesn't work, you probably should ask about this on one
of the Ubuntu forums.

> so I tried to download it from the site and install it from the .tar
> file but I failed because when I run
>
> #~/Desktop/MySQL-python-1.2.2$ python setup.py install
>
> [snip]

In general, my guess is that, unless you have a good reason not to,
you should probably not install fairly standard python packages by-
hand like that on Ubuntu. There should be an Ubuntu package for what
you need, and if there is, you should stick with that. If it fails,
the Ubuntu folks will want to know about it.

---John

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trying to choose between python and java

[Michael Bentley]

On May 15, 2007, at 8:21 PM, Anthony Irwin wrote:

> I saw on the python site a slide from 1999 that said that python was
> slower then java but faster to develop with is python still slower
> then java?

I guess that all depends on the application.  Whenever I have a  
choice between using something written in Java -- and *anything else*  
-- I choose the non-Java option because the JVM is such a hog-beast.   
Sure, once it is running, it may run at a nice clip (which is not my  
experience but I don't want to seem argumentative) but loading the  
Java environment is a pain.  Perfect example is with Aptana, which I  
*really* like -- but if I want to use it, I've got to shut everything  
else off -- and it still brings my poor old machine to its knees  
(note: my computer doesn't actually have knees).

I've never developed in Java though.  Lots of people do, so it must  
have it's merits.

Michael

---
The Rules of Optimization are simple.
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
  -Michael A. Jackson


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
> But they aren't new risks and problems, that's the point. So far, every 
> single objection raised ALREADY EXISTS in some form or another. 

No. The problem "The traceback shows function names having characters
that do not display on most systems' screens" for example does not exist
today, to the best of my knowledge. And "in some form or another"
basically means that the PEP would create more possibilities for things
to go wrong. That things can already go wrong today does not mean that
it does not matter if we create more occasions were things can go wrong
even worse.

> There's 
> all this hysteria about the problems the proposed change will cause, but 
> those problems already exist. When was the last time a Black Hat tried to 
> smuggle in bad code by changing an identifier from xyz0 to xyzO?

Agreed, I don't think intended malicious use of the proposed feature
would be a big problem.

>> I think it is not. I think that the problem only really applies to very
>> isolated use-cases. 
> 
> Like the 5.5 billion people who speak no English.

No. The X people who speak "no English" and program in Python. I think X
actually is very low (close to zero), because programming in Python
virtually does require you to know some English, wether you can use
non-ASCII characters in identifiers or not. It is naive to believe that
you can program in Python without understanding any English once you can
use your native characters in identifiers. That will not happen. Please
understand that: You basically *must* know some English to program in
Python, and the reason for that is not that you cannot use non-ASCII
identifiers.

I admit that there may be occasions where you have domain-specific terms
that are hard to translate into English for a programmer. But is it
really not feasible to use an ASCII transliteration in these cases? This
does not seem to have been such a big problem so far, or else we would
have seen more discussions about it, I think.

>> So isolated that they do not justify a change to
>> mainline Python. If someone thinks that non-ASCII identifiers are really
>> needed, he could maintain a special Python branch that supports them. I
>> doubt that there would be alot of demand for it.
> 
> Maybe so. But I guarantee with a shadow of a doubt that if the change 
> were introduced, people would use it -- even if right now they say they 
> don't want it.

Well, that is exactly what I would like to avoid ;-)

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Iron Python

[Tim Roberts]

BartlebyScrivener <[EMAIL PROTECTED]> wrote:
>On May 15, 5:22 am, John Machin <[EMAIL PROTECTED]> wrote:
>> > > Anybody tried it?
>>
>> > Me.
>>
>> Me too.
>
>Anybody like it?

I think it is a fascinating development, but it is aiming in a different
direction.  To a certain extent, you have to separate the Python language
from the Python standard library.  IronPython has the entire Python
language, and it will run most (but not all) of the standard library we're
all accustomed to, but the real fun of IronPython is that you have the
entire .NET class framework available from Our Favorite Language.

Considering all of the junk that regularly comes out of Redmond, I think
that the Windows Presentation Foundation (formerly called "Avalon") is one
of the most interesting things they've produced in a long time.  IronPython
will give me the opportunity to really dig into WPF without having to drink
the C# kool-aid.
-- 
Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Dijkstra Shortest Path

[Gabriel Genellina]

En Wed, 16 May 2007 00:39:20 -0300, Hugo Ferreira <[EMAIL PROTECTED]>  
escribió:

> While trying to optimize this:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/119466
>
> ... and still have a fast edge lookup, I've done the following tweaks:

I've replaced that strange deeply nested list with an old-fashioned tuple  
and got about a 10% improvement (over a small graph, 60 nodes). But you  
really should try the effect with larger objects.

 def findPath(self, start, end):
q = [(0, start, ())]  # Heap of (cost, path_head, path_rest).
visited = set()   # Visited vertices.

# Eliminate the dots pattern
push, pop, add = heapq.heappush, heapq.heappop, visited.add
G, E = self.G, self.E

while True:
   (cost, v1, path) = pop(q)
   if v1 not in visited:
  add(v1)
  path += (v1,)

  if v1 == end: return path

  for (v2, e) in G[v1].iteritems():
  if v2 not in visited:
push(q, (cost + E[e], v2, path))

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
>> Any program that uses non-English identifiers in Python is bound to
>> become gibberish, since it *will* be cluttered with English identifiers
>> all over the place anyway, wether you like it or not.
> 
> It won't be gibberish to the people who speak the language.

Hmmm, did you read my posting? By my experience, it will. I wonder: is
English an acquired language for you?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: url question - extracting (2 types of) domains

[Michael Bentley]

On May 15, 2007, at 9:04 PM, lazy wrote:

> Hi,
> Im trying to extract the domain name from an url. lets say I call
> it full_domain and significant_domain(which is the homepage domain)
>
> Eg: url=http://en.wikipedia.org/wiki/IPod ,
> full_domain=en.wikipedia.org ,significant_domain=wikipedia.org
>
> Using urlsplit (of urlparse module), I will be able to get the
> full_domain, but Im wondering how to get significant_domain. I will
> not be able to use like counting the number of dots. etc
>
> Some domains maybe like foo.bar.co.in (where significant_domain=
> bar.co.in)
> I have around 40M url list. Its ok, if I fallout in few(< 1%) cases.
> Although I agree that measuring this error rate itself is not clear,
> maybe just based on ituition.
>
> Anybody have clues about existing url parsers in python to do this.
> Searching online couldnt help me much other than
> the urlparse/urllib module.
>
> Worst case is to try to build a table of domain
> categories(like .com, .co.il etc and look for it in the suffix rather
> than counting dots and just extract the part till the preceding dot),
> but Im afraid if I do this, I might miss some domain category.

The best way I know to get an *authoritive* answer is to start with  
the full_domain and try a whois lookup.  If it returns no records,  
drop everything before the first dot and try again.  Repeat until you  
get a good answer -- this is the significant_domain.

hth,
Michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
> If comments are allowed to be none English, then why are identifier not?

I don't need to be able to type in the exact characters of a comment in
order to properly change the code, and if a comment does not display on
my screen correctly, I am not as fscked as badly as when an identifier
does not display (e.g. in a traceback).

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Gregor Horvath]

René Fleschenberg schrieb:

> today, to the best of my knowledge. And "in some form or another"
> basically means that the PEP would create more possibilities for things
> to go wrong. That things can already go wrong today does not mean that
> it does not matter if we create more occasions were things can go wrong
> even worse.

Following this logic we should not add any new features at all, because 
all of them can go wrong and can be used the wrong way.

I love Python because it does not dictate how to do things.
I do not need a ASCII-Dictator, I can judge myself when to use this 
feature and when to avoid it, like any other feature.

Gregor
-- 
http://mail.python.org/mailman/listinfo/python-list

setting an attribute

[7stud]

"When you bind (on either a class or an instance) an attribute whose
name is not special...you affect only the __dict__ entry for the
attribute(in the class or instance, respectively)."

In light of that statement, how would one explain the output of this
code:

class Test(object):
x = [1, 2]

def __init__(self):
self.x[0] = 10

print Test.__dict__#{.'x':[1,2]}
t = Test()
print t.x  #[10, 2]
print t.__dict__   #{}
print Test.__dict__#{.'x':[10,2]...}

It looks to me like self.x[0] is binding on an instance whose
attribute name is not special, yet it doesn't affect any __dict__
entry for the attribute in the instance--instead it is affecting a
__dict__ entry for the attribute in the class.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

[EMAIL PROTECTED] schrieb:
> I'm not sure how you conclude that no problem exists.
> - Meaningful identifiers are critical in creating good code.

I agree.

> - Non-english speakers can not create or understand
>   english identifiers hence can't create good code nor
>   easily grok existing code.

I agree that this is a problem, but please understand that is problem is
_not_ solved by allowing non-ASCII identifiers!

> Considering the vastly greater number of non-English
> spreakers in the world, who are not thus unable to use
> Python effectively, seems like a problem to me.

Yes, but this problem is not really addressed by the PEP. If you want to
do something about this:
1) Translate documentation.
2) Create a way to internationalize the standard library (and possibly
the language keywords, too). Ideally, create a general standardized way
to internationalize code, possibly similiar to how people
internationalize strings today.

When that is done, non-ASCII identifiers could become useful. But of
course, doing that might create a hog of other problems.

> That all programers know enough english to create and
> understand english identifiers is currently speculation or
> based on tiny personaly observed samples.

It is based on a look at the current Python environment. You do *at
least* have the problem that the standard library uses English names.
This assumes that there is documentation in the native language that is
good enough (i.e. almost as good as the official one), which I can tell
is not the case for German.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Raffaele Salmaso]

After reading all thread, and based on my experience (I'm italian, 
english is not my native language)

Martin v. Löwis wrote:

> - should non-ASCII identifiers be supported?
yes
> - why?
Years ago I've read C code written by a turkish guy, and all identifiers 
were transliteration of arab (persian? don't know) words.
What I've understand of this code? Nothing. 0 (zero ;) ). Not a word.
It would have been different if it was used unicode identifiers? Not at all.

> - would you use them if it was possible to do so?
yes

-- 
()_() | NN KAPISCO XK' CELLHAVETE T'ANNTO CN ME SL | +
(o.o) | XK' SKRIVO 1 P'HO VELLOCE MA HALL'ORA DITTELO  | +---+
'm m' | KE SIETE VOI K CI HAVVETE PROBBLEMI NO PENSATECI   |  O  |
(___) | HE SENZA RANKORI CIA   |
raffaele punto salmaso at gmail punto com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
> René Fleschenberg schrieb:
> 
>> today, to the best of my knowledge. And "in some form or another"
>> basically means that the PEP would create more possibilities for things
>> to go wrong. That things can already go wrong today does not mean that
>> it does not matter if we create more occasions were things can go wrong
>> even worse.
> 
> Following this logic we should not add any new features at all, because
> all of them can go wrong and can be used the wrong way.

No, that does not follow from my logic. What I say is: When thinking
about wether to add a new feature, the potential benefits should be
weighed against the potential problems. I see some potential problems
with this PEP and very little potential benefits.

> I love Python because it does not dictate how to do things.
> I do not need a ASCII-Dictator, I can judge myself when to use this
> feature and when to avoid it, like any other feature.

*That* logic can be used to justify the introduction of *any* feature.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorting troubles

[Aether . Singularity]

On May 15, 11:54 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Mon, 14 May 2007 21:45:26 -0700, seyensubs wrote:
> > Ah, I see, just slicing it like that.. nice! But after doing some timing
> > tests, the version that's in place and using partitions is about twice
> > faster than the non hybrid qSort. The hybrid one, with insertionsSort
> > used for smaller lists works faster, but in a weird way. When given
> > lists of 2000, the best bet to is to set the threshold to 14, but when
> > given a list of 4, 14 is slow, but a threshold of 200(less or more
> > is slower, again) makes it about 8 times faster than a normal qSort, and
> > 4 times faster than an in-place qSort, using a self -defined
> > partitioning alg.
>
> > Making a hybrid out of the in-place partitioned qSort makes it a bit
> > faster, but not by much compared to the other hybrid which uses list
> > comprehensions.
>
> > Teach said that the optimal threshold in hybrids is 14-16, but guess he
> > wasn't so right after all =\\ The overhead of using insertion sort on a
> > longer list turns out to be faster than just piling on recursions, when
> > confronted with bigger lists.
>
> Teach may have been thinking of languages where comparing items is fast
> and moving data is slow; Python is the opposite, comparisons invoke a
> whole bucket-full of object-oriented mechanism, while moving data just
> means moving pointers.
>
> It needs to be said, just in case... this is a good learning exercise,
> but don't use this in real code. You aren't going to get within a bull's
> roar of the performance of the built-in sort method. Tim Peter's
> "timsort" is amazingly powerful; you can read about it here:
>
> http://pythonowns.blogspot.com/2002_07_28_pythonowns_archive.html#797...
>
> http://svn.python.org/projects/python/trunk/Objects/listsort.txt
>
> --
> Steven.

Yeah, I know any stuff your average CS student will crank out is way
below anything in-built in the core language and libraries. After all,
smart, experienced people worked on those a lot more than me on
these :)

The blog post is dead, but the .txt is alive(it's the svn of
python.org, after all). Gonna read it but looks a bit beyond my level
of comprehension, for now anyway.

Thanks for all the answers! ..oh, got a 10(out of 10) points in class
for the program. Writing stuff in a language no one else learns at the
university and doing 5 versions of quickSort to test performance
must've paid off. Thanks again :)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Tue, 15 May 2007 17:35:11 +0200, Stefan Behnel  
<[EMAIL PROTECTED]> wrote:
> Eric Brunel wrote:
>> On Tue, 15 May 2007 15:57:32 +0200, Stefan Behnel
>>> In-house developers are rather for this PEP as they see the advantage  
>>> of
>>> expressing concepts in the way the "non-techies" talk about it.
>>
>> No: I *am* an "in-house" developer. The argument is not
>> public/open-source against private/industrial. As I said in some of my
>> earlier posts, any code can pass through many people in its life, people
>> not having the same language. I dare to say that starting a project
>> today in any other language than english is almost irresponsible: the
>> chances that it will get at least read by people not talking the same
>> language as the original coders are very close to 100%, even if it
>> always stays "private".
>
> Ok, so I'm an Open-Source guy who happens to work in-house. And I'm a
> supporter of PEP 3131. I admit that I was simplifying in my round-up. :)
>
> But I would say that "irresponsible" is a pretty self-centered word in  
> this
> context. Can't you imagine that those who take the "irresponsible"  
> decisions
> of working on (and starting) projects in "another language than English"  
> are
> maybe as responsible as you are when you take the decision of starting a
> project in English, but in a different context? It all depends on the  
> specific
> constraints of the project, i.e. environment, developer skills, domain,  
> ...
>
> The more complex an application domain, the more important is clear and
> correct domain terminology. And software developers just don't have  
> that. They
> know their own domain (software development with all those concepts,  
> languages
> and keywords), but there is a reason why they develop software for those  
> who
> know the complex professional domain in detail but do not know how to  
> develop
> software. And it's a good idea to name things in a way that is  
> consistent with
> those who know the professional domain.
>
> That's why keywords are taken from the domain of software development and
> identifiers are taken (mostly) from the application domain. And that's  
> why I
> support PEP 3131.

You keep eluding the question: even if the decisions made at the project  
start seem quite sensible *at that time*, if the project ends up  
maintained in Korea, you *will have* to translate all your identifiers to  
something displayable, understandable and typable by (almost) anyone,  
a.k.a ASCII-English... Since - as I already said - I'm quite convinced  
that any application bigger than the average quick-n-dirty throwable  
script is highly likely to end up in a different country than its original  
coders', you'll end up losing the time you appeared to have gained in the  
beginning. That's what I called "irresponsible" (even if I admit that the  
word was a bit strong...).

Anyway, concerning the PEP, I've finally "put some water in my wine" as we  
say in French, and I'm not so strongly against it now... Not for the  
reasons you give (so we can continue our flame war on this ;-) ), but  
mainly considering Python's usage in a learning context: this is a valid  
reason why non-ASCII identifiers should be supported. I just wish I'll get  
a '--ascii-only' switch on my Python interpreter (or any other means to  
forbid non-ASCII identifiers and/or strings and/or comments).
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tkFileDialog.askopenfilename()

[martin . laloux]

look at  "Basic Tkinter dialogs" from python cookbook at

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438123

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> [EMAIL PROTECTED] schrieb:
>> I'm not sure how you conclude that no problem exists.
>> - Meaningful identifiers are critical in creating good code.
> 
> I agree.
> 
>> - Non-english speakers can not create or understand
>>   english identifiers hence can't create good code nor
>>   easily grok existing code.
> 
> I agree that this is a problem, but please understand that is problem is
> _not_ solved by allowing non-ASCII identifiers!

Well, as I said before, there are three major differences between the stdlib
and keywords on one hand and identifiers on the other hand. Ignoring arguments
does not make them any less true.

So, the problem is partly tackled by the people who face it by writing
degenerated transliterations and language mix in identifiers, but it would be
*solved* by means of the language if Unicode identifiers were available.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Stefan Behnel wrote:

> René Fleschenberg wrote:
>> We all know what the PEP is about (we can read). The point is: If we do
>> not *need* non-English/ASCII identifiers, we do not need the PEP. If the
>> PEP does not solve an actual *problem* and still introduces some
>> potential for *new* problems, it should be rejected. So far, the
>> "problem" seems to just not exist. The burden of proof is on those who
>> support the PEP.
> 
> The main problem here seems to be proving the need of something to people who
> do not need it themselves. So, if a simple "but I need it because a, b, c" is
> not enough, what good is any further prove?

Maybe all the (potential) programmers that can't understand english and
would benefit from the ability to use non-ASCII characters in identifiers
could step up and take part in this debate.  In an english speaking
newsgroup…  =:o)

There are potential users of Python who don't know much english or no
english at all.  This includes kids, old people, people from countries
that have "letters" that are not that easy to transliterate like european
languages, people who just want to learn Python for fun or to customize
their applications like office suites or GIS software with a Python
scripting option.

Some people here seem to think the user base is or should be only from the
computer science domain.  Yes, if you are a programming professional it
may be mandatory to be able to write english identifiers, comments and
documentation, but there are not just programming professionals out there.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> Gregor Horvath schrieb:
>> If comments are allowed to be none English, then why are identifier not?
> 
> I don't need to be able to type in the exact characters of a comment in
> order to properly change the code, and if a comment does not display on
> my screen correctly, I am not as fscked as badly as when an identifier
> does not display (e.g. in a traceback).

Then get tools that match your working environment.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

~!~ Britneys New BOOB job fails Silcone Valley everywhere!!!!

[deepbroke7]

http://scargo.in/2007/05/attorney-lawyers-say-whats-in-your.html -
Britneys Boob job spurs lawsuit.!!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[gatti]

Martin v. Lowis wrote:
> Lorenzo Gatti wrote:
>> Not providing an explicit listing of allowed characters is inexcusable
>> sloppiness.

> That is a deliberate part of the specification. It is intentional that
> it does *not* specify a precise list, but instead defers that list
> to the version of the Unicode standard used (in the unicodedata
> module).

Ok, maybe you considered listing characters but you earnestly decided
to follow an authority; but this reliance on the Unicode standard is
not a merit: it defers to an external entity (UAX 31 and the Unicode
database) a foundation of Python syntax.
The obvious purpose of Unicode Annex 31 is defining a framework for
parsing the identifiers of arbitrary programming languages, it's only,
in its own words, "specifications for recommended defaults for the use
of Unicode in the definitions of identifiers and in pattern-based
syntax". It suggests an orderly way to add tens of thousands of exotic
characters to programming language grammars, but it doesn't prove it
would be wise to do so.

You seem to like Unicode Annex 31, but keep in mind that:
- it has very limited resources (only the Unicode standard, i.e. lists
and properties of characters, and not sensible programming language
design, software design, etc.)
- it is culturally biased in favour of supporting as much of the
Unicode character set as possible, disregarding the practical
consequences and assuming without discussion that programming language
designers want to do so
- it is also culturally biased towards the typical Unicode patterns of
providing well explained general algorithms, ensuring forward
compatibility, and relying on existing Unicode standards (in this
case, character types) rather than introducing new data (but the
character list of Table 3 is unavoidable); the net result is caring
even less for actual usage.

>> The XML standard is an example of how listings of large parts of the
>> Unicode character set can be provided clearly, exactly and (almost)
>> concisely.

> And, indeed, this is now recognized as one of the bigger mistakes
> of the XML recommendation: they provide an explicit list, and fail
> to consider characters that are unassigned. In XML 1.1, they try
> to address this issue, by now allowing unassigned characters in
> XML names even though it's not certain yet what those characters
> mean (until they are assigned).

XML 1.1 is, for practical purposes, not used except by mistake. I
challenge you to show me XML languages or documents of some importance
that need XML 1.1 because they use non-ASCII names.
XML 1.1 is supported by many tools and standards because of buzzword
compliance, enthusiastic obedience to the W3C and low cost of
implementation, but this doesn't mean that its features are an
improvement over XML 1.0.

>>> ``ID_Continue`` is defined as all characters in ``ID_Start``, plus
>>> nonspacing marks (Mn), spacing combining marks (Mc), decimal number
>>> (Nd), and connector punctuations (Pc).
>>
>> Am I the first to notice how unsuitable these characters are?

> Probably. Nobody in the Unicode consortium noticed, but what
> do they know about suitability of Unicode characters...

Don't be silly. These characters are suitable for writing text, not
for use in identifiers; the fact that UAX 31 allows them merely proves
how disconnected from actual programming language needs that document
is.

In typical word processing, what characters are used is the editor's
problem and the only thing that matters is the correctness of the
printed result; program code is much more demanding, as it needs to do
more (exact comparisons, easy reading...) with less (straightforward
keyboard inputs and monospaced fonts instead of complex input systems
and WYSIWYG graphical text). The only way to work with program text
successfully is limiting its complexity.
Hard to input characters, hard to see characters, ambiguities and
uncertainty in the sequence of characters, sets of hard to distinguish
glyphs and similar problems are unacceptable.

It seems I'm not the first to notice a lot of Unicode characters that
are unsuitable for identifiers. Appendix I of the XML 1.1 standard
recommends to avoid variation selectors, interlinear annotations (I
missed them...), various decomposable characters, and "names which are
nonsensical, unpronounceable, hard to read, or easily confusable with
other names".
The whole appendix I is a clear admission of self-defeat, probably the
result of committee compromises.  Do you think you could do better?

Regards,
Lorenzo Gatti



-- 
http://mail.python.org/mailman/listinfo/python-list

A new project.

[colin . barnette]

I am interested in organizing and taking part in a project that would
create a virtual world much like the one described in Neal
Stephenson's 'Snow Crash'.  I'm not necessarily talking about
something 3d and I'm not talking about a game either.  Like a MOO,
only virtual.  And each 'user' is allocated space with which they are
free to edit in any way, within the confines of that space.  I know
Second Life and others come to mind when you think of this, but
Frankly Second Life came off as sloppy to me.  I want people to be
able to code their own objects and environments with the ease of
Python.

I don't know forget the suggestions, anything is on the table, but
there are just so many half-hearted and weak commercial attempts at
this I feel that it's time to get Python involved in the game and do
it right.

If anyone has any interest, ideas, comments or otherwise, e-mail me.
If some interest is shown we'll start a board, a site, an IRC channel
or whatever we have to do to meet and get the ball rolling. :)

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
> Steven D'Aprano wrote:
>> I would find it useful to be able to use non-ASCII characters for heavily
>> mathematical programs. There would be a closer correspondence between the
>> code and the mathematical equations if one could write D(u*p) instead of
>> delta(mu*pi).
> 
> Just as one risk here:
> When reading the above on Google groups, it showed up as "if one could
> write ?(u*p)..."
> When quoting it for response, it showed up as "could write D(u*p)".
> 
> I'm sure that the symbol you used was neither a capital letter d nor a
> question mark.
> 
> Using identifiers that are so prone to corruption when posting in a
> rather popular forum seems dangerous to me--and I'd guess that a lot
> of source code highlighters, email lists, etc have similar problems.
> I'd even be surprised if some programming tools didn't have similar
> problems.

So, it was google groups that continuously corrupted the good UTF-8 
posts by force converting them to ISO-8859-1?

Of course, there's also the possibility that it is a problem on *your* 
side so, to be fair I've launched google groups and looked for this 
thread. And of course the result was that Steven's post displayed 
perfectly. I didn't try to reply to it of course, no need to clutter 
that thread anymore than it is.

-- 
Δ(µ*π)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Tue, 15 May 2007 21:07:30 +0200, Pierre Hanser  
<[EMAIL PROTECTED]> wrote:
> hello
>
> i work for a large phone maker, and for a long time
> we thought, very arrogantly, our phones would be ok
> for the whole world.
>
> After all, using a phone uses so little words, and
> some of them where even replaced with pictograms!
> every body should be able to understand appel, bis,
> renvoi, mévo, ...
>
> nowdays we make chinese, corean, japanese talking
> phones.
>
> because we can do it, because graphics are cheaper
> than they were, because it augments our market.
> (also because some markets require it)
>
> see the analogy?

Absolutely not: you're talking about internationalization of the  
user-interface here, not about the code. There are quite simple ways to  
ensure users will see the displays in their own language, even if the  
source code is the same for everyone. But your source code will not  
automagically translate itself to the language of the guy who'll have to  
maintain it or make it evolve. So the analogy actually seems to work  
backwards: if you want any coder to be able to read/understand/edit your  
code, just don't write it in your own language...
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> Then get tools that match your working environment.

Integration with existing tools *is* something that a PEP should
consider. This one does not do that sufficiently, IMO.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting an attribute

[Bruno Desthuilliers]

7stud a écrit :
> "When you bind (on either a class or an instance) an attribute whose
> name is not special...you affect only the __dict__ entry for the
> attribute(in the class or instance, respectively)."
> 
> In light of that statement, how would one explain the output of this
> code:
> 
> class Test(object):
> x = [1, 2]
> 
> def __init__(self):
> self.x[0] = 10
> 
> print Test.__dict__#{.'x':[1,2]}
> t = Test()
> print t.x  #[10, 2]
> print t.__dict__   #{}
> print Test.__dict__#{.'x':[10,2]...}
> 
> It looks to me like self.x[0] is binding on an instance whose
> attribute name is not special,


self.x[0] = 10 doesn't bind self.x - it's just syntactic sugar for 
self.x.__setitem__(0, 10) (which itself is syntactic sugar for 
list.__setitem__(self.x, 0, 10))

> yet it doesn't affect any __dict__
> entry for the attribute in the instance

Of course. The name 'x' is looked up in the instance, then in the class. 
Since there's no binding (only a method call on a class attribute), 
instance's dict is not affected.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

[EMAIL PROTECTED] wrote:
> I even sometimes
> read code snippets on email lists and websites from my handheld, which
> is sadly still memory-limited enough that I'm really unlikely to
> install anything approaching a full set of Unicode fonts.

One of the arguments against this PEP was that it seemed to be impossible to
find either transliterated identifiers in code or native identifiers in Java
code using a web search. So it is very unlikely that you will need to upgrade
your handheld as it is very unlikely for you to stumble into such code.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>>> - Non-english speakers can not create or understand
>>>   english identifiers hence can't create good code nor
>>>   easily grok existing code.
>> I agree that this is a problem, but please understand that is problem is
>> _not_ solved by allowing non-ASCII identifiers!
> 
> Well, as I said before, there are three major differences between the stdlib
> and keywords on one hand and identifiers on the other hand. Ignoring arguments
> does not make them any less true.

BTW: Please stop replying to my postings by E-Mail (in Thunderbird, use
"Reply" in stead of "Reply to all").

I agree that keywords are a different matter in many respects, but the
only difference between stdlib interfaces and other intefaces is that
the stdlib interfaces are part of the stdlib. That's it. You are still
ignoring the fact that, contrary to what has been suggested in this
thread, it is _not_ possible to write "German" or "Chinese" Python
without cluttering it up with many many English terms. It's not only the
stdlib, but also many many third party libraries. Show me one real
Python program that is feasibly written without throwing in tons of
English terms.

Now, very special environments (what I called "rare and isolated"
earlier) like special learning environments for children are a different
matter. It should be ok if you have to use a specially patched Python
branch there, or have to use an interpreter option that enables the
suggested behaviour. For general programming, it IMO is a bad idea.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get a control over a window

[Duncan Booth]

Tom Gur <[EMAIL PROTECTED]> wrote:

> I was wondering how do I get control over a window (Win32).
> to be more specific, I need to find a handle to a window of a certain
> program and minimize the window.
> 

Here's a function which returns a list of all windows where the class is 
'PuTTY' or the title contains a particular string:

from win32gui import EnumWindows, GetClassName, EnumChildWindows
from win32ui import CreateWindowFromHandle, MessageBox

def toplevelWindows():
res = []
def callback(hwnd, arg):
name = GetClassName(hwnd)
w = CreateWindowFromHandle(hwnd)
title = w.GetWindowText()
if "'s password:" in title or name=='PuTTY':
res.append(w)
EnumWindows(callback, 0)
return res

You can minimize a window once you have found it by calling ShowWindow 
(or SetWindowPlacement).

If you don't want to depend on Python's win32 extensions being installed 
then you can also do the same thing using ctypes.

In either case be very careful that you are only picking up the windows 
you wanted to find as enumerating top level windows will return a lot of hidden 
windows and if you start messing with these you will probably need to reboot 
your system.

Here's something adapted from some stuff where I was playing with ctypes 
(so you could probably cut out a lot of crud). It's a complete program 
which will find a Firefox window with a specified string in the title 
and minimize it (without the test for the classname it will also minimize 
the command window you run it from).


- minimize.py -
#
# Minimize a specified window.
#
import sys
import ctypes
from ctypes import *

def _stdcall(dllname, restype, funcname, *argtypes):
# a decorator for a generator.
# The decorator loads the specified dll, retrieves the
# function with the specified name, set its restype and argtypes,
# it then invokes the generator which must yield twice: the first
# time it should yield the argument tuple to be passed to the dll
# function (and the yield returns the result of the call).
# It should then yield the result to be returned from the
# function call.
def decorate(func):
api = getattr(WinDLL(dllname), funcname)
api.restype = restype
api.argtypes = argtypes

def decorated(*args, **kw):
iterator = func(*args, **kw)
nargs = iterator.next()
if not isinstance(nargs, tuple):
nargs = (nargs,)
try:
res = api(*nargs)
except Exception, e:
return iterator.throw(e)
return iterator.send(res)
return decorated
return decorate

from ctypes.wintypes import HWND #, RECT, POINT
LPARAM = c_ulong

class metaENUM(type(ctypes.c_int)):
def __init__(cls, name, bases, namespace):
'''Convert enumeration names into attributes'''
names = namespace.get('_names_', {})
if hasattr(names, 'keys'):
for (k,v) in names.items():
setattr(cls, k, cls(v))
names[v]=k
else:
for (i,k) in enumerate(names):
setattr(cls, k, cls(i))
super(metaENUM, cls).__init__(name, bases, namespace)

class ENUM(ctypes.c_int):
'''Enumeration base class. Set _names_ attribute to a list
of enumeration names (counting from 0)
or a dictionary of name:value pairs.'''
__metaclass__ = metaENUM
def __str__(self):
return self.__repr__(fmt="%(value)s")

def __repr__(self, fmt="<%(name)s %(value)s>"):
try:
return self._names_[self.value]
except:
return fmt % dict(name=self.__class__.__name__, value=self.value)
def __int__(self):
return self.value

class BITMASK(ENUM):
'''Some Microsoft 'enums' are actually bitmasks with several bits or'd 
together'''
def __repr__(self, fmt="<%(name)s %(value)s>"):
v = self.value
values = []
while v:
bit = v&(~v+1)
try:
values.append(self._names_[bit])
except (KeyError, IndexError):
values.append(fmt % dict(name=self.__class__.__name__, 
value=self.value))
v &= ~bit
if not values:
return '0'
return '|'.join(values)
def __or__(self, other):
return type(self)(int(self.value)|int(other.value))

class SHOWCMD(ENUM):
_names_ = '''SW_HIDE SW_NORMAL SW_SHOW_MINIMIZED SW_SHOW_MAXIMIZED
SW_SHOW_NOACTIVATE SW_SHOW SW_MINIMIZE SW_SHOWMINNOACTIVE
SW_SHOWNA SW_RESTORE SW_SHOWDEFAULT SW_FORCEMINIMIZE'''.split()

class WindowPlacementFlags(BITMASK):
_names_ = dict(WPF_SETMINPOSITION = 1,
WPF_RESTORETOMAXIMIZED = 2,
WPF_ASYNCWINDOWPLACEMENT = 4)

class Structure(ctypes.Structure):
"""As ctypes Structure but with added repr and comparison testing"""
def __repr__(self):
return "%s(%s)" % (self.__class__.__name__,

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Marc 'BlackJack' Rintsch schrieb:
> There are potential users of Python who don't know much english or no
> english at all.  This includes kids, old people, people from countries
> that have "letters" that are not that easy to transliterate like european
> languages, people who just want to learn Python for fun or to customize
> their applications like office suites or GIS software with a Python
> scripting option.

Make it an interpreter option that can be turned on for those cases.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Eric Brunel wrote:
> reason why non-ASCII identifiers should be supported. I just wish I'll
> get a '--ascii-only' switch on my Python interpreter (or any other means
> to forbid non-ASCII identifiers and/or strings and/or comments).

I could certainly live with that as it would be the right way around. Support
Unicode by default, but allow those who require the lowest common denominator
to enforce it.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> *Your* logic can be used to justify dropping *any* feature.

No. I am considering both the benefits and the problems. You just happen
to not like the outcome of my considerations [again, please don't reply
by E-Mail, I read the NG].

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Wed, 16 May 2007 02:14:58 +0200, Steven D'Aprano  
<[EMAIL PROTECTED]> wrote:

> On Tue, 15 May 2007 09:09:30 +0200, Eric Brunel wrote:
>
>> Joke aside, this just means that I won't ever be able to program math in
>> ADA, because I have absolutely no idea on how to do a 'pi' character on
>> my keyboard.
>
> Maybe you should find out then? Personal ignorance is never an excuse for
> rejecting technology.

My "personal ignorance" is fine, thank you; how is yours?: there is no  
keyboard *on Earth* allowing to type *all* characters in the whole Unicode  
set. So my keyboard may just happen to provide no means at all to type a  
greek 'pi', as it doesn't provide any to type Chinese, Japanese, Korean,  
Russian, Hebrew, or whatever character set that is not in usage in my  
country. And so are all keyboards all over the world.

Have I made my point clear or do you require some more explanations?
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Distributing programs depending on third party modules.

[Bruno Desthuilliers]

Kevin Walzer a écrit :
> Bruno Desthuilliers wrote:
> 
>>> What platform are you doing this on? On the Linux platform, 
>>> "dependency hell" of this sort is pretty much unavoidable,
>>
>> Yes it is. EasyInstall works just fine.
> 
> You can install a beast like PyQt with easy_install? Meaning, that it 
> will download and build/install not just the PyQt bits, but also Qt 
> itself, sip, and all the other foundational components?

Are these components packaged in such a way to support easy_install ?-)

No, of course, easy_install doesn't *actually* support this (while 
AFAICT, it technically *could* do the job). I was talking about 
dependencies between Python packages.

If you want support for such external dependencies, emerge 
(Gentoo-Linux) is your friend - and believe me, it's really impressive.

Note that if you go that way, neither Windows nor MacOS X are actually 
able to cleanly manage such dependencies (which is why the usual 
solution on these platforms - or at least on Windows - is to just bundle 
everything in a single big package). FWIW, I sure had much more trouble 
with "DLHell" on Windows than on Gentoo or Ubuntu.

> If easy_install 
> handles all that, I'm impressed.

I'm already impressed by the whole setuptools package.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting an attribute

[half . italian]

On May 16, 12:34 am, 7stud <[EMAIL PROTECTED]> wrote:
> "When you bind (on either a class or an instance) an attribute whose
> name is not special...you affect only the __dict__ entry for the
> attribute(in the class or instance, respectively)."
>
> In light of that statement, how would one explain the output of this
> code:
>
> class Test(object):
> x = [1, 2]
>
> def __init__(self):
> self.x[0] = 10
>
> print Test.__dict__#{.'x':[1,2]}
> t = Test()
> print t.x  #[10, 2]
> print t.__dict__   #{}
> print Test.__dict__#{.'x':[10,2]...}
>
> It looks to me like self.x[0] is binding on an instance whose
> attribute name is not special, yet it doesn't affect any __dict__
> entry for the attribute in the instance--instead it is affecting a
> __dict__ entry for the attribute in the class.

I think it's following scope rules.  It can't find an attribute for
self.x in the instance.  It then checks the class for the var and
finds it and sets it there.  It would error otherwise...

>>> class Test(object):
... def __init__(self):
... self.x[0] =7
...
>>> t = Test()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __init__
AttributeError: 'Test' object has no attribute 'x'

~Sean

-- 
http://mail.python.org/mailman/listinfo/python-list

iteration doesn't seem to work ??

[stef]

hello,

can someone tell me why the following iteration doesn't work,
and
how I should replace empty strings in a list with a default value.

 >>> v
['123', '345', '', '0.3']
 >>> for items in v:
...   if items=='':
...   items='3'
...
 >>>
 >>> v
['123', '345', '', '0.3']
 >>>

thanks,
Stef Mientki
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trying to choose between python and java

[Bruno Desthuilliers]

[EMAIL PROTECTED] a écrit :
> On May 15, 5:16 pm, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
>> Beliavsky a écrit :
>>
>>
>>
>>> On May 15, 1:30 am, Anthony Irwin <[EMAIL PROTECTED]> wrote:
>>> 
 #5 someone said that they used to use python but stopped because the
 language changed or made stuff depreciated (I can fully remember
 which) and old code stopped working. Is code written today likely to
 still work in 5+ years or do they depreciate stuff and you have to update?
>>> Because Python 3 will change the syntax of print to disallow
>>> print "Hello, world."
>>> a substantial fraction of Python programs in existence, including all
>>> of my programs, will be broken. Draw your own conclusions.
>> The fact that Py3K will be a "big cleanup" release is not new - it has
>> been clear for some years now that this would be the first release that
>> would break compatibility.
> 
> Eliminating core libraries breaks compatibility.  Getting rid of regex
> was very traumatic, and I still find myself occasionally patching up
> code because of that change.  To be fair, regex was deprecated for
> many versions before it was dropped (and warned loudly of the coming
> change), and Java's been notably worse at maintaining backward
> compatibility.  But saying it's the first release that breaks
> compatibility isn't true unless you have a very limited definition of
> compatibility.

Looks like you're right on this - there have been at least one 
"compatibility-break" release before. As far as I'm concerned, I have 
been totally unaffected by this change, which is probably why I don't 
even remember it.

>> Still GvR and the team seem to be making
>> their best to not avoid as much breakage as possible, clearly document
>> what will break, and if possible provide tools to ease migration.
> 
> Absolutely.
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> Stefan Behnel schrieb:
 - Non-english speakers can not create or understand
   english identifiers hence can't create good code nor
   easily grok existing code.
>>> I agree that this is a problem, but please understand that is problem is
>>> _not_ solved by allowing non-ASCII identifiers!
>> Well, as I said before, there are three major differences between the stdlib
>> and keywords on one hand and identifiers on the other hand. Ignoring 
>> arguments
>> does not make them any less true.
> 
> I agree that keywords are a different matter in many respects, but the
> only difference between stdlib interfaces and other intefaces is that
> the stdlib interfaces are part of the stdlib. That's it. You are still
> ignoring the fact that, contrary to what has been suggested in this
> thread, it is _not_ possible to write "German" or "Chinese" Python
> without cluttering it up with many many English terms. It's not only the
> stdlib, but also many many third party libraries. Show me one real
> Python program that is feasibly written without throwing in tons of
> English terms.
> 
> Now, very special environments (what I called "rare and isolated"
> earlier) like special learning environments for children are a different
> matter. It should be ok if you have to use a specially patched Python
> branch there, or have to use an interpreter option that enables the
> suggested behaviour. For general programming, it IMO is a bad idea.

Ok, let me put it differently.

You *do not* design Python's keywords. You *do not* design the stdlib. You *do
not* design the concepts behind all that. You *use* them as they are. So you
can simply take the identifiers they define and use them the way the docs say.
You do not have to understand these names, they don't have to be words, they
don't have to mean anything to you. They are just tools. Even if you do not
understand English, they will not get in your way. You just learn them.

But you *do* design your own software. You *do* design its concepts. You *do*
design its APIs. You *do* choose its identifiers. And you want them to be
clear and telling. You want them to match your (or your clients) view of the
application. You do not care about the naming of the tools you use inside. But
you do care about clarity and readability in *your own software*.

See the little difference here?

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> Marc 'BlackJack' Rintsch schrieb:
>> There are potential users of Python who don't know much english or no
>> english at all.  This includes kids, old people, people from countries
>> that have "letters" that are not that easy to transliterate like european
>> languages, people who just want to learn Python for fun or to customize
>> their applications like office suites or GIS software with a Python
>> scripting option.
> 
> Make it an interpreter option that can be turned on for those cases.

No. Make "ASCII-only" an interpreter option that can be turned on for the
cases where it is really required.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg schrieb:
> Gregor Horvath schrieb:
>> René Fleschenberg schrieb:
>>
>>> today, to the best of my knowledge. And "in some form or another"
>>> basically means that the PEP would create more possibilities for things
>>> to go wrong. That things can already go wrong today does not mean that
>>> it does not matter if we create more occasions were things can go wrong
>>> even worse.
>> Following this logic we should not add any new features at all, because
>> all of them can go wrong and can be used the wrong way.
> 
> No, that does not follow from my logic. What I say is: When thinking
> about wether to add a new feature, the potential benefits should be
> weighed against the potential problems. I see some potential problems
> with this PEP and very little potential benefits.
> 
>> I love Python because it does not dictate how to do things.
>> I do not need a ASCII-Dictator, I can judge myself when to use this
>> feature and when to avoid it, like any other feature.
> 
> *That* logic can be used to justify the introduction of *any* feature.

*Your* logic can be used to justify dropping *any* feature.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Distributing programs depending on third party modules.

[David Boddie]

On May 16, 7:44 am, Tina I <[EMAIL PROTECTED]> wrote:

> A binary would be ideal. I'll look into the freeze modules and
> Pyinstaller. Even if they don't handle huge things like Qt it would be a
> step in the right direction if it handles smaller third part modules.
> And maybe the smartest thing to do would be to dump PyQt and just
> go for tkinter, however ugly it is :/

It's may be worth reading this message before making such a drastic
decision:

http://www.riverbankcomputing.com/pipermail/pyqt/2007-May/016092.html

David ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iteration doesn't seem to work ??

[half . italian]

On May 16, 1:41 am, stef <[EMAIL PROTECTED]> wrote:
> hello,
>
> can someone tell me why the following iteration doesn't work,
> and
> how I should replace empty strings in a list with a default value.
>
>  >>> v
> ['123', '345', '', '0.3']
>  >>> for items in v:
> ...   if items=='':
> ...   items='3'
> ...
>  >>>
>  >>> v
> ['123', '345', '', '0.3']
>  >>>
>
> thanks,
> Stef Mientki

Inside the loop, 'items' is no longer referencing the list...its a
string.

>>> v = ['123', '4', '567', '']
>>> for i in v:
... print type(i)
...
...

This works

>>> for j,i in enumerate(v):
... if i=='':
... v[j] = '3'
...
>>> v
['123', '4', '567', '3']
>>>

~Sean

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Ben]

On May 15, 11:25 pm, Stefan Behnel <[EMAIL PROTECTED]>
wrote:
> René Fleschenberg wrote:
> > Javier Bezos schrieb:
> >>> But having, for example, things like open() from the stdlib in your code
> >>> and then öffnen() as a name for functions/methods written by yourself is
> >>> just plain silly. It makes the code inconsistent and ugly without
> >>> significantly improving the readability for someone who speaks German
> >>> but not English.
> >> Agreed. I always use English names (more or
> >> less :-)), but this is not the PEP is about.
>
> > We all know what the PEP is about (we can read). The point is: If we do
> > not *need* non-English/ASCII identifiers, we do not need the PEP. If the
> > PEP does not solve an actual *problem* and still introduces some
> > potential for *new* problems, it should be rejected. So far, the
> > "problem" seems to just not exist. The burden of proof is on those who
> > support the PEP.
>
> The main problem here seems to be proving the need of something to people who
> do not need it themselves. So, if a simple "but I need it because a, b, c" is
> not enough, what good is any further prove?
>
> Stefan

For what it's worth, I can only speak English (bad English schooling!)
and I'm definitely +1 on the PEP. Anyone using tools from the last 5
years can handle UTF-8

Cheers,
Ben

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iteration doesn't seem to work ??

[stef]

hello Sean,

thanks very much for the explanation and solution.

cheers,
Stef Mientki

[EMAIL PROTECTED] wrote:
> On May 16, 1:41 am, stef <[EMAIL PROTECTED]> wrote:
>   
>> hello,
>>
>> can someone tell me why the following iteration doesn't work,
>> and
>> how I should replace empty strings in a list with a default value.
>>
>>  >>> v
>> ['123', '345', '', '0.3']
>>  >>> for items in v:
>> ...   if items=='':
>> ...   items='3'
>> ...
>>  >>>
>>  >>> v
>> ['123', '345', '', '0.3']
>>  >>>
>>
>> thanks,
>> Stef Mientki
>> 
>
> Inside the loop, 'items' is no longer referencing the list...its a
> string.
>
>   
 v = ['123', '4', '567', '']
 for i in v:
 
> ... print type(i)
> ...
> ...
>
> This works
>
>   
 for j,i in enumerate(v):
 
> ... if i=='':
> ... v[j] = '3'
> ...
>   
 v
 
> ['123', '4', '567', '3']
>   
>
> ~Sean
>
>   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: url question - extracting (2 types of) domains

[lazy]

Thanks.
Hmm, the url list is quite huge(40M). I think it will take a lot of
time,for a whois lookup I guess. But yeah,
thats seems to be a good way. Probably I will try it with a smaller
set (10K) and see the time it takes.
If not, I guess I will just build a table of known
domains(.com,.org,.co.il etc ) and then I can find the
root domain(significant_domain) atleast for those and I hope majority
of them fall into this :)


On May 16, 12:32 am, Michael Bentley <[EMAIL PROTECTED]>
wrote:
> On May 15, 2007, at 9:04 PM, lazy wrote:
>
>
>
> > Hi,
> > Im trying to extract the domain name from an url. lets say I call
> > it full_domain and significant_domain(which is the homepage domain)
>
> > Eg: url=http://en.wikipedia.org/wiki/IPod,
> > full_domain=en.wikipedia.org ,significant_domain=wikipedia.org
>
> > Using urlsplit (of urlparse module), I will be able to get the
> > full_domain, but Im wondering how to get significant_domain. I will
> > not be able to use like counting the number of dots. etc
>
> > Some domains maybe like foo.bar.co.in (where significant_domain=
> > bar.co.in)
> > I have around 40M url list. Its ok, if I fallout in few(< 1%) cases.
> > Although I agree that measuring this error rate itself is not clear,
> > maybe just based on ituition.
>
> > Anybody have clues about existing url parsers in python to do this.
> > Searching online couldnt help me much other than
> > the urlparse/urllib module.
>
> > Worst case is to try to build a table of domain
> > categories(like .com, .co.il etc and look for it in the suffix rather
> > than counting dots and just extract the part till the preceding dot),
> > but Im afraid if I do this, I might miss some domain category.
>
> The best way I know to get an *authoritive* answer is to start with
> the full_domain and try a whois lookup.  If it returns no records,
> drop everything before the first dot and try again.  Repeat until you
> get a good answer -- this is the significant_domain.
>
> hth,
> Michael


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quote aware split

[Diez B. Roggisch]

Ondrej Baudys wrote:

> Hi,
> 
> After trawling through the archives for a simple quote aware split
> implementation (ie string.split-alike that only splits outside of
> matching quote) and coming up short,  I implemented a quick and dirty
> function that suits my purposes.



Maybe using the csv module together with cStringIO would be more
straightforward.

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Gregor Horvath]

René Fleschenberg schrieb:

>> I love Python because it does not dictate how to do things.
>> I do not need a ASCII-Dictator, I can judge myself when to use this
>> feature and when to avoid it, like any other feature.
> 
> *That* logic can be used to justify the introduction of *any* feature.
> 

No. That logic can only be used to justify the introduction of a feature 
that brings freedom.

Who are we to dictate the whole python world how to spell an identifier?

Gregor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Interesting list Validity (True/False)

[Gabriel Genellina]

En Wed, 16 May 2007 03:16:59 -0300, [EMAIL PROTECTED]  
<[EMAIL PROTECTED]> escribió:

> On May 15, 7:07 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
> wrote:

>>  import gmpy
>>  a = 2**177149-1
>>  b = gmpy.mpz(2**177149-1)
>>  a==b
>> > True
>>  print '%d' % (b)
>>
>> > Traceback (most recent call last):
>> >   File "", line 1, in 
>> > print '%d' % (b)
>> > TypeError: int argument required
>>
>> > So although the comparison operator is smart enough to realize
>> > the equivalency of numeric types and do the type conversion,
>> > the print statement isn't so smart.
>>
>> This is up to the gmpy designers/writers/maintainers. Anyone writing a
>> class chooses which features to implement, which ones to omit, how to
>> implement them, etc. The code may contain bugs, may not be efficient,  
>> may
>> not behave exactly as the users expect, may not have anticipated all  
>> usage
>> scenarios, a long etc. In this case, probably the gmpy writers have  
>> chosen
>> not to allow to convert to int, and they may have good reasons to not do
>> that (I don't know what platform are you working in, but I feel that  
>> your
>> b object is somewhat larger than sys.maxint...).
>
> Then how does this work?
>
 print '%d' % (long(gmpy.mpz(2**177149-1)))
> 1454...<53320 digits snipped>...3311
>
> I honestly don't understand why there's a problem here.
> If print can handle arbitrary precision longs without
> a problem, why does it fail on mpzs > sys.maxint?
> If the gmpy writers are not allowing the conversion,
> then why do small mpz values work? Something smells
> inconsistent here.

Python (builtin) "integral numbers" come on two flavors: int and long.  
ints correspond to the C `long` type usually, and have a limited range, at  
least from -2**31 to 2**31-1; most operations have hardware support (or at  
least it's up to the C compiler). Long integers are a totally different  
type, they have unlimited range but are a lot slower, and all operations  
must be done "by hand". See http://docs.python.org/ref/types.html

If you say "%d" % something, Python first tries to see if `something` is a  
long integer -not to *convert* it to a long integer, just to see if the  
object *is* a long integer. If it's a long, it's formatted accordingly.
If not, Python sees if `something` is a plain integer. If not, it sees if  
it's a number (in this context, that means that the structure describing  
its type contains a non-NULL tp_as_number member) and tries to *convert*  
it to an integer. Notice that if the object whas not originally a long  
integer, no attempt is made to convert it to a long using the nb_long  
member - just a plain integer conversion is attempted.
It's at this stage that a large mpz object may fail - when its value can't  
fit in a plain integer, it raises an OverflowError and the "%d" formatting  
fails.
If you force a conversion to long integer, using long(mpz(...)) as above,  
the % operator sees a long integer from start and it can be formatted  
without problems.

I don't know if this asymmetric behavior is a design decision, a historic  
relic, a change in protocol (is nb_int allowed now to return a  
PyLongObject, but not before?), a "nobody cares" issue, or just a bug.  
Perhaps someone else can give an opinion - and certainly I may be wrong, I  
had never looked at the PyString_Format function internal details before  
(thanks for providing an excuse!).

As a workaround you can always write "%d" % long(mpznumber) when you want  
to print them (or perhaps "%s" % mpznumber, which might be faster).

> How is it that
>
 print '%d' % (1.0)
> 1
>
> doesn't make a type mismatch? Obviously, the float
> got changed to an int and this had nothing to do with
> gmpy. Is it the print process responsible for doing
> the conversion? Maybe I should say invoking the
> conversion? Maybe the gmpy call tries to literally
> convert to an integer rather than sneakily substitute
> a long?

Same as above: is the argument a long integer? no. is it a number? yes.  
Convert to int. No errors? Apply format.

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[[EMAIL PROTECTED]]

Ben wrote:
> On May 15, 11:25 pm, Stefan Behnel <[EMAIL PROTECTED]>
> wrote:
> > Rene Fleschenberg wrote:
> > > Javier Bezos schrieb:
> > >>> But having, for example, things like open() from the stdlib in your code
> > >>> and then o:ffnen() as a name for functions/methods written by yourself 
> > >>> is
> > >>> just plain silly. It makes the code inconsistent and ugly without
> > >>> significantly improving the readability for someone who speaks German
> > >>> but not English.
> > >> Agreed. I always use English names (more or
> > >> less :-)), but this is not the PEP is about.
> >
> > > We all know what the PEP is about (we can read). The point is: If we do
> > > not *need* non-English/ASCII identifiers, we do not need the PEP. If the
> > > PEP does not solve an actual *problem* and still introduces some
> > > potential for *new* problems, it should be rejected. So far, the
> > > "problem" seems to just not exist. The burden of proof is on those who
> > > support the PEP.
> >
> > The main problem here seems to be proving the need of something to people 
> > who
> > do not need it themselves. So, if a simple "but I need it because a, b, c" 
> > is
> > not enough, what good is any further prove?
> >
> > Stefan
>
> For what it's worth, I can only speak English (bad English schooling!)
> and I'm definitely +1 on the PEP. Anyone using tools from the last 5
> years can handle UTF-8

The falsehood of the last sentence is why I'm moderately against this
PEP.  Even examples within this thread don't display correctly on
several of the machines I have access too (all of which are less than
5 year old OS/browser environments).  It strikes me a similar to the
arguments for quoted-printable in the early 1990s, claiming that
everyone can view it or will be able to soon--and even a decade
_after_ "everyone can deal with latin1 just fine" it was still causing
massive headaches.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[[EMAIL PROTECTED]]

Christophe wrote:
> [EMAIL PROTECTED] a ecrit :
> > Steven D'Aprano wrote:
> >> I would find it useful to be able to use non-ASCII characters for heavily
> >> mathematical programs. There would be a closer correspondence between the
> >> code and the mathematical equations if one could write D(u*p) instead of
> >> delta(mu*pi).
> >
> > Just as one risk here:
> > When reading the above on Google groups, it showed up as "if one could
> > write ?(u*p)..."
> > When quoting it for response, it showed up as "could write D(u*p)".
> >
> > I'm sure that the symbol you used was neither a capital letter d nor a
> > question mark.
> >
> > Using identifiers that are so prone to corruption when posting in a
> > rather popular forum seems dangerous to me--and I'd guess that a lot
> > of source code highlighters, email lists, etc have similar problems.
> > I'd even be surprised if some programming tools didn't have similar
> > problems.
>
> So, it was google groups that continuously corrupted the good UTF-8
> posts by force converting them to ISO-8859-1?
>
> Of course, there's also the possibility that it is a problem on *your*
> side

Well, that's part of the point isn't it?  It seems incredibly naive to
me to think that you could use whatever symbol was intended and have
it show up, and the "well fix your machine!" argument doesn't fly.  A
lot of the time programmers have to look at stack traces on end-user's
machines (whatever they may be) to help debug.  They have to look at
code on the (GUI-less) production servers over a terminal link.  They
have to use all kinds of environments where they can't install the
latest and greatest fonts.  Promoting code that becomes very hard to
read and debug in real situations seems like a sound negative to me.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[[EMAIL PROTECTED]]

Stefan Behnel wrote:
> [EMAIL PROTECTED] wrote:
> > I even sometimes
> > read code snippets on email lists and websites from my handheld, which
> > is sadly still memory-limited enough that I'm really unlikely to
> > install anything approaching a full set of Unicode fonts.
>
> One of the arguments against this PEP was that it seemed to be impossible to
> find either transliterated identifiers in code or native identifiers in Java
> code using a web search. So it is very unlikely that you will need to upgrade
> your handheld as it is very unlikely for you to stumble into such code.

Sure, if the feature isn't going to be used then it won't present
problems.  I can't really see much of an argument for a PEP that isn't
going to be used, though, and if it is used then it's worthwhile to
think about the implications of having code that many common systems
simply can't deal with (either displaying it incorrectly or actually
corrupting files that pass through them).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
>> Unless you are 150% sure that there will *never* be the need for a
>> person who does not know your language of choice to be able to read or
>> modify your code, the language that "fits the environment best" is
>> English.
> 
> Just a touch of hyperbole perhaps?
> 
> You know, it may come to a surprise to some people that English is not 
> the only common language. In fact, it only ranks third, behind Mandarin 
> and Spanish, and just above Arabic. Although the exact number of speakers 
> vary according to the source you consult, the rankings are quite stable: 
> Mandarin, Spanish, then English. Any of those languages could equally 
> have claim to be the world's lingua franca.

For a language to be a (or the) lingua franca, the sheer number of
people who speak it is actually not as important as you seem to think.
Its use as an international exchange language is the decisive criterion
-- definitely not true for Mandarin, and for Spanish not nearly as much
as for English.

Also, there can be different "linguae francae" for different fields.
English definitely is the lingua franca of programming. But that is
actually off topic. Programming languages are not the same as natural
languages. I was talking about program code, not about works of literature.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Neil Hodgson]

Lorenzo Gatti:

> Ok, maybe you considered listing characters but you earnestly decided
> to follow an authority; but this reliance on the Unicode standard is
> not a merit: it defers to an external entity (UAX 31 and the Unicode
> database) a foundation of Python syntax.

PEP 3131 uses a similar definition to C# except that PEP 3131 
disallows formatting characters (category Cf). See section 9.4.2 of
http://www.ecma-international.org/publications/standards/Ecma-334.htm

Neil
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tkinter button state = DISABLED

[Hendrik van Rooyen]

 "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:

>Maybe there is a confusion here. You code above means that, when the event
>"The leftmost MOUSE BUTTON was released" happens over your BUTTON WIDGET
>b, your function will be called.

I have never seen this working in Tkinter, unless the button was pressed on the
widget
in question - and worse, once you have clicked down on a ButtonRelease binding
you can move the mouse pointer anywhere you like, even out of the application
and when you release it, the bound function is called...

Its either a bug or a feature, I don't know.

- Hendrik





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

 "Michael Yanowitz" <[EMAIL PROTECTED]> wrote;


> Let me guess - the next step will be to restrict the identifiers
> to be at most 6 characters long.

No that is way too restrictive - you need at least eight,
but they must be from the first 80 in the ASCII set - 
i.e. - capitals only 

Caps lock on, start coding - lovely names like
VAR001, VAR002,  etc...

Hey come to think of it - maybe 6 is good enough...

; - )

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

 "Méta-MCI" <[EMAIL PROTECTED]> wrote:


> Hi!
>
> - should non-ASCII identifiers be supported? why?
> - would you use them if it was possible to do so? in what cases?
>
> Yes.
>
> JScript  can use letters with accents in identifiers
> XML (1.1)  can use letters with accents in tags
> C# can use letters with accents in variables
> SQL: MySQL/MS-Sql/Oralcle/etc. can use accents in fields or request
> etc.
> etc.
>
> Python MUST make up for its lost time.
>

All those lemmings are jumping over a cliff!
I must hurry to keep up!

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

"Eric Brunel" <[EMAIL PROTECTED]> wrote:

>So what? Does it mean that it's acceptable for the standard library and
>keywords to be in English only, but the very same restriction on
>user-defined identifiers is out of the question? Why? If I can use my own
>language in my identifiers, why can't I write:
>
>classe MaClasse:
>   définir __init__(moi_même, maListe):
> moi_même.monDictionnaire = {}
> pour i dans maListe:
>   moi_même.monDictionnaire[i] = Rien
>
>For a French-speaking person, this is far more readable than:
>
>class MaClasse:
>   def __init__(self, maListe):
> self.monDictionnaire = {}
> for i in maListe:
>   self.monDictionnaire[i] = None
>
>Now, *this* is mixing apples and peaches... And this would look even
>weirder with a non-indo-european language...
>

I don't have any French, but I support this point absolutely - having
native identifiers is NFG if you can't also have native reserved words.

You may be stuck with English sentence construction though. - Would
be hard, I would imagine, to let the programmer change the word order,
or to incorporate something as weird as the standard double negative
in Afrikaans...

We say things that translate literally to:  "I am not a big man not.", and it
is completely natural, so the if statements should follow the pattern.

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

"Stefan Behnel" <[EMAIL PROTECTED]> wrote:

.:) This is not about "technical" English, this is about domain specific
>English. How big is your knowledge about, say, biological terms or banking
>terms in English? Would you say you're capable of modelling an application
>from the domain of biology, well specified in a large German document, in
>perfect English terms?
>
>And: why would you want to do that?

Possibly because it looks better and reads easier than
a dog ugly mix of perfectly good German words
all mixed up with English keywords in an English
style of sentence construction?

- Hendrik

--
"Hier sind wir unter uns"  ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

 <[EMAIL PROTECTED]> wrote:


> 
> "Hendrik van Rooyen" <[EMAIL PROTECTED],,,.co.za> wrote in message
> news:[EMAIL PROTECTED]
> 
> > <[EMAIL PROTECTED]> wrote:
> 
> [I fixed the broken attribution in your quote]
> 
Sorry about that - I deliberately fudge email addys...


> First "while" is a keyword and will remain "while" so
> that has nothing to do with anything.

I think this cuts right down to why I oppose the PEP.
It is not so much for technical reasons as for aesthetic 
ones - I find reading a mix of languages horrible, and I am
kind of surprised by the strength of my own reaction.

If I try to analyse my feelings, I think that really the PEP 
does not go far enough, in a sense, and from memory
it seems to me that only E Brunel, R Fleschenberg and
to a lesser extent the Martellibot seem to somehow think 
in a similar way as I do, but I seem to have an extreme 
case of the disease...

And the summaries of reasons for and against have left 
out objections based on this feeling of ugliness of mixed 
language.

Interestingly, the people who seem to think a bit like that all 
seem to be non native English speakers who are fluent in
English.

While the support seems to come from people whose English
is perfectly adequate, but who are unsure to the extent that they
apologise for their "bad" English.

Is this a pattern that you have identified? - I don't know.

I still don't like the thought of the horrible mix of "foreign"
identifiers and English keywords, coupled with the English 
sentence construction.  And that, in a nutshell, is the main 
reason for my rather vehement opposition to this PEP.

The other stuff about sharing and my inability to even type
the OP's name correctly with the umlaut is kind of secondary
to this feeling of revulsion.

"Beautiful is better than ugly"

- Hendrik



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

"HYRY" <[EMAIL PROTECTED]> wrote:


> If non-ASCII identifiers becomes true, I think it will be the best
> gift for Children who donot know English.

How do you feel about the mix of English keywords and Chinese?
How does the English - like "sentences " look to a Chinese?

Would you support the extension of this PEP to include Chinese
Keywords?

Would that be a lesser or greater gift?

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
> Christophe wrote:
>> [EMAIL PROTECTED] a ecrit :
>>> Steven D'Aprano wrote:
 I would find it useful to be able to use non-ASCII characters for heavily
 mathematical programs. There would be a closer correspondence between the
 code and the mathematical equations if one could write D(u*p) instead of
 delta(mu*pi).
>>> Just as one risk here:
>>> When reading the above on Google groups, it showed up as "if one could
>>> write ?(u*p)..."
>>> When quoting it for response, it showed up as "could write D(u*p)".
>>>
>>> I'm sure that the symbol you used was neither a capital letter d nor a
>>> question mark.
>>>
>>> Using identifiers that are so prone to corruption when posting in a
>>> rather popular forum seems dangerous to me--and I'd guess that a lot
>>> of source code highlighters, email lists, etc have similar problems.
>>> I'd even be surprised if some programming tools didn't have similar
>>> problems.
>> So, it was google groups that continuously corrupted the good UTF-8
>> posts by force converting them to ISO-8859-1?
>>
>> Of course, there's also the possibility that it is a problem on *your*
>> side
> 
> Well, that's part of the point isn't it?  It seems incredibly naive to
> me to think that you could use whatever symbol was intended and have
> it show up, and the "well fix your machine!" argument doesn't fly.  A
> lot of the time programmers have to look at stack traces on end-user's
> machines (whatever they may be) to help debug.  They have to look at
> code on the (GUI-less) production servers over a terminal link.  They
> have to use all kinds of environments where they can't install the
> latest and greatest fonts.  Promoting code that becomes very hard to
> read and debug in real situations seems like a sound negative to me.

Who displays stack frames? Your code. Whose code includes unicode 
identifiers? Your code. Whose fault is it to create a stack trace 
display procedure that cannot handle unicode? You. Even if you don't 
make use of them, you still have to fix the stack trace display 
procedure because the exception error message can include unicode text 
*today*

You should know that displaying and editing UTF-8 text as if it was 
latin-1 works very very well.

Also, Terminals have support for UTF-8 encodings already. Or you could 
always use kate+fish to edit your script on the distant server without 
such problems (fish is a KDE protocol used to access a computer with ssh 
as if it was a hard disk and kate is the standard text/code editor) It's 
a matter of tools.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Hendrik van Rooyen wrote:
> "Beautiful is better than ugly"

Good point. Today's transliteration of German words into ASCII identifiers
definitely looks ugly. Time for this PEP to be accepted.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Gregor Horvath]

[EMAIL PROTECTED] schrieb:

> code on the (GUI-less) production servers over a terminal link.  They
> have to use all kinds of environments where they can't install the
> latest and greatest fonts.  Promoting code that becomes very hard to
> read and debug in real situations seems like a sound negative to me.

If someone wants to debug a Chinese program, he has in almost all cases 
obviously already installed the correct fonts and his machine can handle 
unicode.

Maybe yours and mine not, but I doubt that we are going to debug a 
chinese program.

I have debugged German programs (not python) with unicode characters in 
it for years and had no problem at all, because all customers and me 
have obviously German machines.

Gregor


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
>> *That* logic can be used to justify the introduction of *any* feature.
>>
> 
> No. That logic can only be used to justify the introduction of a feature
> that brings freedom.

That is any feature that you are not forced to use. So let's get gotos
and the like. Every programming language dictates some things. This is
not a bad thing.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

[EMAIL PROTECTED] wrote:
> Stefan Behnel wrote:
>> [EMAIL PROTECTED] wrote:
>>> I even sometimes
>>> read code snippets on email lists and websites from my handheld, which
>>> is sadly still memory-limited enough that I'm really unlikely to
>>> install anything approaching a full set of Unicode fonts.
>> One of the arguments against this PEP was that it seemed to be impossible to
>> find either transliterated identifiers in code or native identifiers in Java
>> code using a web search. So it is very unlikely that you will need to upgrade
>> your handheld as it is very unlikely for you to stumble into such code.
> 
> Sure, if the feature isn't going to be used then it won't present
> problems.

Thing is, this feature *is* going to be used. Just not by projects that you
are likely to stumble into. Most OpenSource projects will continue to stick to
English-only, and posts to English-speaking newsgroups will also stick to
English. But Closed-Source programs and posts to non-English newsgroups *can*
use this feature if their developers want. And you still wouldn't even notice.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Gregor Horvath]

Hendrik van Rooyen schrieb:

> It is not so much for technical reasons as for aesthetic 
> ones - I find reading a mix of languages horrible, and I am
> kind of surprised by the strength of my own reaction.

This is a matter of taste.
In some programs I use German identifiers (not unicode). I and others 
like the mix. My customers can understand the code better. (They are 
only reading it)

> 
> "Beautiful is better than ugly"

Correct.
But why do you think you should enforce your taste to all of us?

With this logic you should all drive Alfa Romeos!

Gregor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[HYRY]

> How do you feel about the mix of English keywords and Chinese?
> How does the English - like "sentences " look to a Chinese?
>
> Would you support the extension of this PEP to include Chinese
> Keywords?
>
> Would that be a lesser or greater gift?
>

Because the students can remember some English words, Mixing
characters is not a problem. But it's difficult to express their own
thought or logic in English or Pinyin(only mark the pronunciation of
the Chinese character).
As my experience, I found mixing identifiers of Chinese characters and
keywords of English is very easy for reading.
Because the large difference between Chinese characters and ASCII
characters, I can  distinguish my identifiers with keywords and
library words quickly.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Neil Hodgson]

Eric Brunel:

> ... there is no 
> keyboard *on Earth* allowing to type *all* characters in the whole 
> Unicode set. 

My keyboard in conjunction with the operating system (US English 
keyboard on a Windows XP system) allows me to type characters from any 
language. I haven't learned how to type these all quickly but I can get 
through a session of testing Japanese input by myself. Its a matter of 
turning on different keyboard layouts through the "Text Services and 
Input Languages" control panel. Then there are small windows called 
Input Method Editors that provide a mapping from your input to the 
target language. Other platforms provide similar services.

Neil
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

 "Stefan Behnel" <[EMAIL PROTECTED]> wrote:


> Hendrik van Rooyen wrote:
> > "Beautiful is better than ugly"
> 
> Good point. Today's transliteration of German words into ASCII identifiers
> definitely looks ugly. Time for this PEP to be accepted.
> 

Nice out of context quote. :-)

Now look me in the eye and tell me that you find
the mix of proper German and English keywords
beautiful.

And I will call you a liar.

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>> Now, very special environments (what I called "rare and isolated"
>> earlier) like special learning environments for children are a different
>> matter. It should be ok if you have to use a specially patched Python
>> branch there, or have to use an interpreter option that enables the
>> suggested behaviour. For general programming, it IMO is a bad idea.
> 
> Ok, let me put it differently.
> 
> You *do not* design Python's keywords. You *do not* design the stdlib. You *do
> not* design the concepts behind all that. You *use* them as they are. So you
> can simply take the identifiers they define and use them the way the docs say.
> You do not have to understand these names, they don't have to be words, they
> don't have to mean anything to you. They are just tools. Even if you do not
> understand English, they will not get in your way. You just learn them.

I claim that this is *completely unrealistic*. When learning Python, you
*do* learn the actual meanings of English terms like "open",
"exception", "if" and so on if you did not know them before. It would be
extremely foolish not to do so. You do care about these names and you do
want to know their meaning if you want to write anything more in your
life than a 10-line throw-away script.

> But you *do* design your own software. You *do* design its concepts. You *do*
> design its APIs. You *do* choose its identifiers. And you want them to be
> clear and telling. You want them to match your (or your clients) view of the
> application. You do not care about the naming of the tools you use inside. But
> you do care about clarity and readability in *your own software*.

I do care about the naming of my tools. I care alot. Part of why I like
Python is that it resisted the temptation to clutter the syntax up with
strange symbols like Perl. And I do dislike the decorator syntax, for
example.

Also, your distinction between "inside" and "your own" is nonsense,
because the "inside" does heavily leak into the "own". It is impossible
to write "your own software" with clarity and readability by your
definition (i.e. in your native language). Any real Python program is a
mix of identifiers you designed yourself and identifiers you did not
design yourself. And I think the ones chosen by yourself are even often
in the minority. It is not feasible in practice to just learn what the
"other" identifiers do without understanding their names. Not for
general programming. The standard library is already too big for that,
and most real programs use not only the standard library, but also third
party libraries that have English APIs.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Christophe schrieb:

> Who displays stack frames? Your code. 

Wrong.

> Whose code includes unicode
> identifiers? Your code. 

Wrong.

> Whose fault is it to create a stack trace
> display procedure that cannot handle unicode? You. 

Wrong. If you never have to deal with other people's code,
congratulations to you. Many other people have to. And no, I can usualy
not just tell the person to fix his code. I need to deal with it.

> Even if you don't
> make use of them, you still have to fix the stack trace display
> procedure because the exception error message can include unicode text
> *today*

The error message can, but at least the function names and other
identifiers can not.

> You should know that displaying and editing UTF-8 text as if it was
> latin-1 works very very well.s

No, this only works for those characters that are in the ASCII range.
For all the other characters it does not work well at all.

> Also, Terminals have support for UTF-8 encodings already. 

Some have, some have not. And you not only need a terminal that can
handle UTF-8 data, you also need a font that has a glyph for all the
characters you need to handle, and you may also need a way to actualy
enter those characters with your keyboard.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Splitting a quoted string.

[mosscliffe]

I am looking for a simple split function to create a list of entries
from a string which contains quoted elements.  Like in 'google'
search.

eg  string = 'bob john "johnny cash" 234 june'

and I want to have a list of ['bob', 'john, 'johnny cash', '234',
'june']

I wondered about using the csv routines, but I thought I would ask the
experts first.

There maybe a simple function, but as yet I have not found it.

Thanks

Richard

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

René Fleschenberg a écrit :
> Christophe schrieb:
>> You should know that displaying and editing UTF-8 text as if it was
>> latin-1 works very very well.s
> 
> No, this only works for those characters that are in the ASCII range.
> For all the other characters it does not work well at all.

This alone shows you don't know enouth about UTF-8 to talk about it. 
UTF-8 will NEVER use < 128 chars to describe multibyte chars. When you 
parse a UTF-8 file, each space is a space, each \n is an end of line and 
each 'Z' is a 'Z'.

>> Also, Terminals have support for UTF-8 encodings already. 
> 
> Some have, some have not. And you not only need a terminal that can
> handle UTF-8 data, you also need a font that has a glyph for all the
> characters you need to handle, and you may also need a way to actualy
> enter those characters with your keyboard.

Ever heard of the famous "cut/paste"? I use it all the time, even when 
handling standard ASCII english code. It greatly cuts down my ability to 
make some typo while writing code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quote aware split

[BJörn Lindqvist]

How is the code different from shlex.split?

-- 
mvh Björn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Christophe schrieb:
> René Fleschenberg a écrit :
>> Christophe schrieb:
>>> You should know that displaying and editing UTF-8 text as if it was
>>> latin-1 works very very well.s
>>
>> No, this only works for those characters that are in the ASCII range.
>> For all the other characters it does not work well at all.
> 
> This alone shows you don't know enouth about UTF-8 to talk about it.
> UTF-8 will NEVER use < 128 chars to describe multibyte chars. When you
> parse a UTF-8 file, each space is a space, each \n is an end of line and
> each 'Z' is a 'Z'.

So? Does that mean that you can just display UTF-8 "as if it was
Latin-1"? No, it does not. It means you can do that for exactly those
characters that are in the ASCII range. For all the others, you can not.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> Stefan Behnel schrieb:
>>> Now, very special environments (what I called "rare and isolated"
>>> earlier) like special learning environments for children are a different
>>> matter. It should be ok if you have to use a specially patched Python
>>> branch there, or have to use an interpreter option that enables the
>>> suggested behaviour. For general programming, it IMO is a bad idea.
>> Ok, let me put it differently.
>>
>> You *do not* design Python's keywords. You *do not* design the stdlib. You 
>> *do
>> not* design the concepts behind all that. You *use* them as they are. So you
>> can simply take the identifiers they define and use them the way the docs 
>> say.
>> You do not have to understand these names, they don't have to be words, they
>> don't have to mean anything to you. They are just tools. Even if you do not
>> understand English, they will not get in your way. You just learn them.
> 
> I claim that this is *completely unrealistic*. When learning Python, you
> *do* learn the actual meanings of English terms like "open",

Fine, then go ahead and learn their actual meaning in two languages (Python
and English). My point is: you don't have to. You only need to understand
their meaning in Python. Whether or not English can help here or can be useful
in your later life is completely off-topic.


>> But you *do* design your own software. You *do* design its concepts. You *do*
>> design its APIs. You *do* choose its identifiers. And you want them to be
>> clear and telling. You want them to match your (or your clients) view of the
>> application. You do not care about the naming of the tools you use inside. 
>> But
>> you do care about clarity and readability in *your own software*.
> 
> I do care about the naming of my tools. I care alot. Part of why I like
> Python is that it resisted the temptation to clutter the syntax up with
> strange symbols like Perl. And I do dislike the decorator syntax, for
> example.
> 
> Also, your distinction between "inside" and "your own" is nonsense,
> because the "inside" does heavily leak into the "own". It is impossible
> to write "your own software" with clarity and readability by your
> definition (i.e. in your native language). Any real Python program is a
> mix of identifiers you designed yourself and identifiers you did not
> design yourself. And I think the ones chosen by yourself are even often
> in the minority. It is not feasible in practice to just learn what the
> "other" identifiers do without understanding their names. Not for
> general programming. The standard library is already too big for that,
> and most real programs use not only the standard library, but also third
> party libraries that have English APIs.

Ok, I think the difference here is that I have practical experience with
developing that way and I am missing native identifiers in my daily work. You
don't have that experience and therefore do not feel that need. And you know
what? That's perfectly fine. I'm not criticising that at all. All I'm
criticising is that people without need for this feature are trying to prevent
those who need it and want to use it *where it is appropriate* from actually
getting this feature into the language.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iteration doesn't seem to work ??

[Ant]

On May 16, 9:41 am, stef <[EMAIL PROTECTED]> wrote:
> hello,
>
> can someone tell me why the following iteration doesn't work,
> and
> how I should replace empty strings in a list with a default value.

See the other reponse for the why. Here's another how, using list
comprehension.:

1 > v = ['123', '345', '', '0.3']
2 > v = [x if x else '3' for x in v]
3 > v
3 = ['123', '345', '3', '0.3']

Note that this replaces the list, so won't be appropriate for
modifying a list passed in from elsewhere.

--
Ant...

http://antroy.blogspot.com/


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Distributing programs depending on third party modules.

[Tina I]

David Boddie wrote:
> On May 16, 7:44 am, Tina I <[EMAIL PROTECTED]> wrote:
> 
>> A binary would be ideal. I'll look into the freeze modules and
>> Pyinstaller. Even if they don't handle huge things like Qt it would be a
>> step in the right direction if it handles smaller third part modules.
>> And maybe the smartest thing to do would be to dump PyQt and just
>> go for tkinter, however ugly it is :/
> 
> It's may be worth reading this message before making such a drastic
> decision:
> 
> http://www.riverbankcomputing.com/pipermail/pyqt/2007-May/016092.html
> 
> David ;-)
> 
Oh... now I feel stupid... I'm on the PyQt list but somehow missed that 
topic.
Thanks!

Tina
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[André]

"Years ago", i wrote RUR-PLE  (a python learning environment based on
Karel the Robot).
Someone mentioned using RUR-PLE to teach programming in Chinese to
kids.  Here's a little text extracted from the English lessons (and an
even smaller one from the Turkish one).  I believe that this is
relevant to this discussion.
==
While the creators of Reeborg designed him so that he obeys
instructions in English, they realised that not everyone understands
English. So, they gave him the ability to easily learn a second
language. For example, if we want to tell someone to "move forward" in
French, we would say "avance". We can tell Reeborg that "avance" is a
synonym of "move" simply by writing
avance = move.
The order here is important; the known command has to be on the right,
and the new one has to be on the left. Note that we don't have any
parentheses "()" appearing since the parentheses would tell Reeborg
that we want him to obey an instruction; here, we are simply teaching
him a new word. When we want Reeborg to follow the new instruction, we
will use avance().
[snip]

If you want, you can also teach Reeborg a synonym for turn_off. Or,
you may give synonyms in a language other than French if you prefer,
even creating your own language. Then, watch Reeborg as he obeys
instructions written in your language.
[snip]
Note that, if English is not your favourite language, you can always
create a synonym in your language, as long as you define it first,
before using it. However, the synonym you introduce must use the
English alphabet (letters without any accents). For example, in
French, one might define vire_a_gauche = turn_left and use
vire_a_gauche() to instruct the robot to turn left.

--(this last paragraph, now translated in Turkish)

Eğer İngilizce sizin favori diliniz değilse komutları her zaman kendi
dilinizde de tanımlayabilirsiniz, ancak kendi dilinizde tanımladığınız
komutları oluştururken yalnızca İngiliz alfabesindeki 26 harfi
kullanabilirsiniz. Örneğin Türkçede sola dönüş için sola_don =
turn_left kullanılmalıdır (ö yerine o kullanılmış dikkat ediniz). Bu
tanımlamayı yaptıktan sonra Reeborg'u sola döndürmek için sola_don()
komutunu kullanabilirsiniz.
=
I don't read Turkish, but I notice the number 26 there (plus a many
accented letters in the text), suspecting it refers to a small English
alphabet.   It always bugged me that I could not have proper robot
commands in French.


While I would not use any non-ascii characters in my coding project
(because I like to be able to get bug reports [and patch!] from
others), I would love to be able to rewrite the lessons for RUR-PLE
using commands in proper French, rather than the bastardized purely
ascii based version.  And I suspect it would be even more important in
Chinese...

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Splitting a quoted string.

[Paul Melis]

Paul Melis wrote:
> Hi,
> 
> mosscliffe wrote:
> 
>> I am looking for a simple split function to create a list of entries
>> from a string which contains quoted elements.  Like in 'google'
>> search.
>>
>> eg  string = 'bob john "johnny cash" 234 june'
>>
>> and I want to have a list of ['bob', 'john, 'johnny cash', '234',
>> 'june']
>>
>> I wondered about using the csv routines, but I thought I would ask the
>> experts first.
>>
>> There maybe a simple function, but as yet I have not found it.
> 
> 
> Here a not-so-simple-function using regular expressions. It repeatedly 
> matched two regexps, one that matches any sequence of characters except 
> a space and one that matches a double-quoted string. If there are two 
> matches the one occurring first in the string is taken and the matching 
> part of the string cut off. This is repeated until the whole string is 
> matched. If there are two matches at the same point in the string the 
> longer of the two matches is taken. (This can't be done with a single 
> regexp using the A|B operator, as it uses lazy evaluation. If A matches 
> then it is returned even if B would match a longer string).

Here a slightly improved version which is a bit more compact and which 
removes the quotes on the matched output quoted string.

import re

def split_string(s):

pat1 = re.compile('[^" ]+')
pat2 = re.compile('"([^"]*)"')

parts = []

m1 = pat1.search(s)
m2 = pat2.search(s)
while m1 or m2:

if m1 and m2:
if m1.start(0) < m2.start(0):
match = 1
elif m2.start(0) < m1.start(0):
match = 2
else:
if len(m1.group(0)) > len(m2.group(0)):
match = 1
else:
match = 2
elif m1:
match = 1
else:
match = 2

if match == 1:
part = m1.group(0)
s = s[m1.end(0):]
else:
part = m2.group(1)
s = s[m2.end(0):]

parts.append(part)

m1 = pat1.search(s)
m2 = pat2.search(s)

return parts

print split_string('bob john "johnny cash" 234 june')
print split_string('"abc""abc"')
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Splitting a quoted string.

[Paul Melis]

Hi,

mosscliffe wrote:
> I am looking for a simple split function to create a list of entries
> from a string which contains quoted elements.  Like in 'google'
> search.
> 
> eg  string = 'bob john "johnny cash" 234 june'
> 
> and I want to have a list of ['bob', 'john, 'johnny cash', '234',
> 'june']
> 
> I wondered about using the csv routines, but I thought I would ask the
> experts first.
> 
> There maybe a simple function, but as yet I have not found it.

Here a not-so-simple-function using regular expressions. It repeatedly 
matched two regexps, one that matches any sequence of characters except 
a space and one that matches a double-quoted string. If there are two 
matches the one occurring first in the string is taken and the matching 
part of the string cut off. This is repeated until the whole string is 
matched. If there are two matches at the same point in the string the 
longer of the two matches is taken. (This can't be done with a single 
regexp using the A|B operator, as it uses lazy evaluation. If A matches 
then it is returned even if B would match a longer string).

import re

def split_string(s):

pat1 = re.compile('[^ ]+')
pat2 = re.compile('"[^"]*"')

parts = []

m1 = pat1.search(s)
m2 = pat2.search(s)
while m1 or m2:

if m1 and m2:
# Both match, take match occurring earliest in the 
string
p1 = m1.group(0)
p2 = m2.group(0)
if m1.start(0) < m2.start(0):
part = p1
s = s[m1.end(0):]
elif m2.start(0) < m1.start(0):
part = p2
s = s[m2.end(0):]   
else:
# Both match at the same string position, take 
longest match
if len(p1) > len(p2):
part = p1
s = s[m1.end(0):]
else:
part = p2
s = s[m2.end(0):]
elif m1:
part = m1.group(0)
s = s[m1.end(0):]
else:
part = m2.group(0)
s = s[m2.end(0):]

parts.append(part)

m1 = pat1.search(s)
m2 = pat2.search(s)

return parts

 >>> s = 'bob john "johnny cash" 234 june'
 >>> split_string(s)
['bob', 'john', '"johnny cash"', '234', 'june']
 >>>


Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic login to website (newbie)

[phishboh]

On 15 Mai, 16:25, "Tim Williams" <[EMAIL PROTECTED]> wrote:
> The frame URL ishttp://www.expekt.com/contenttop.jsp,  you could try
> navigating directly to the frame to see if it helps
>
> website = "http://www.expekt.com/contenttop.jsp";
> ie.navigate(website)
> ie.textBoxSet('user', 'MyLogin')
> ie.textBoxSet('pass', 'MyPassword')
> ie.buttonClick('actn')

Thanks a lot, it helped! (after also changing the last line to
ie.buttonClick('login'))

Next, I'd like to follow links within the website, but I ran into
similar problems again.
The following code navigates me to the desired website:

# python.org
ie = cPAMIE.PAMIE()
website = "http://www.python.org";
ie.navigate(website)
ie.textBoxSet('q', 'pamie')
ie.buttonClick('submit')
ie.linkClick('Agile Testing with Python Test Frameworks')

But nothing happens when using the any of the linkClick commands in
the code below (I'd like to click the "odds" link in the upper menu):
# expekt.com
ie = cPAMIE.PAMIE()
website = "http://www.expekt.com/eng";
ie.navigate(website)
ie.linkClick(' odds')
#ie.linkClick('odds')
#ie.linkClick('http://www.expekt.com/livebetting/index.jsp')
#ie.linkClick('subMenusport1')

I guess that I have to do something like "in the frame called 'menu',
follow the link called 'odds'" (and similar for login; in the frame
called 'contenttop', enter 'MyLogin' in the text box called 'user' and
'MyPassword' in the text box called 'pass').

Any ideas on how to accomplish this?

Code samples (and/or documentation) to
* launch IE (succeeded: IE =
win32com.client.DispatchEx('InternetExplorer.Application.1'))
* navigate to website (succeeded: IE.Navigate(website))
* fill in specific text box(es) in specific frame(s) and submit (need
support)
* follow specific link(s) in specific frame(s) (need support)
using win32.client (or PAMIE or other) would be very welcome!

Any help highly appreciated. Thanks!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Splitting a quoted string.

[Duncan Booth]

mosscliffe <[EMAIL PROTECTED]> wrote:

> I am looking for a simple split function to create a list of entries
> from a string which contains quoted elements.  Like in 'google'
> search.
> 
> eg  string = 'bob john "johnny cash" 234 june'
> 
> and I want to have a list of ['bob', 'john, 'johnny cash', '234',
> 'june']
> 
> I wondered about using the csv routines, but I thought I would ask the
> experts first.
> 
> There maybe a simple function, but as yet I have not found it.

You probably need to specify the problem more completely. e.g. Can the 
quoted parts of the strings contain quote marks? If so how what are the 
rules for escaping them. Do two spaces between a word mean an empty field 
or still a single string delimiter.

Once you've worked that out you can either use re.split with a suitable 
regular expression, or use the csv module specifying your desired dialect:

>>> class mosscliffe(csv.Dialect):
delimiter = ' '
quotechar = '"'
doublequote = False
skipinitialspace = False
lineterminator = '\r\n'
quoting = csv.QUOTE_MINIMAL


>>> csv.register_dialect("mosscliffe", mosscliffe)
>>> string = 'bob john "johnny cash" 234 june'
>>> for row in csv.reader([string], dialect="mosscliffe"):
print row


['bob', 'john', 'johnny cash', '234', 'june']

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Wed, 16 May 2007 12:22:01 +0200, Neil Hodgson  
<[EMAIL PROTECTED]> wrote:

> Eric Brunel:
>
>> ... there is no keyboard *on Earth* allowing to type *all* characters  
>> in the whole Unicode set.
>
> My keyboard in conjunction with the operating system (US English  
> keyboard on a Windows XP system) allows me to type characters from any  
> language. I haven't learned how to type these all quickly but I can get  
> through a session of testing Japanese input by myself. Its a matter of  
> turning on different keyboard layouts through the "Text Services and  
> Input Languages" control panel. Then there are small windows called  
> Input Method Editors that provide a mapping from your input to the  
> target language. Other platforms provide similar services.

Funny you talk about Japanese, a language I'm a bit familiar with and for  
which I actually know some input methods. The thing is, these only work if  
you know the transcription to the latin alphabet of the word you want to  
type, which closely match its pronunciation. So if you don't know that 売り 
場 is pronounced "uriba" for example, you have absolutely no way of  
entering the word. Even if you could choose among a list of characters,  
are you aware that there are almost 2000 "basic" Chinese characters used  
in the Japanese language? And if I'm not mistaken, there are several tens  
of thousands characters in the Chinese language itself. This makes typing  
them virtually impossible if you don't know the language and/or have the  
correct keyboard.
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quote aware split

[John Machin]

On May 16, 10:50 am, "Ondrej Baudys" <[EMAIL PROTECTED]> wrote:

> # last slice will be of the form chars[last:] which we couldnt do above

Who are "we"? Here's another version with the "couldn't do" problem
fixed and a few minor enhancements:

def qsplit2(chars, sep=",", quote="'"):
""" Quote aware split """
assert sep != quote
can_split = True
splitpoints = [-1] # ie. separator char found before first
letter ;)
for index, c in enumerate(chars):
if c == quote:
can_split = not can_split
elif c == sep and can_split:
splitpoints.append(index)
if not can_split:
raise ValueError("Unterminated quote")
splitpoints.append(len(chars))
# slice chars by splitpoints *omitting the separator*
slices = [chars[splitpoints[i]+1:splitpoints[i+1]]
for i in range(len(splitpoints)-1)]
return slices

Cheers,
John

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Carsten Haese]

On Wed, 16 May 2007 09:12:40 +0200, René Fleschenberg wrote
> The X people who speak "no English" and program in Python. I 
> think X actually is very low (close to zero), because programming in 
> Python virtually does require you to know some English, wether you 
> can use non-ASCII characters in identifiers or not. It is naive to 
> believe that you can program in Python without understanding any 
> English once you can use your native characters in identifiers. That 
> will not happen. Please understand that: You basically *must* know 
> some English to program in Python, and the reason for that is not 
> that you cannot use non-ASCII identifiers.

There is evidence against your assertions that knowing some English is a
prerequisite for programming in Python and that people won't use non-ASCII
identifiers if they could. Go read the posts by "HYRY" on this thread, a
teacher from China, who teaches his students programming in Python, and they
don't know any English. They *do* use non-ASCII identifiers, and then they use
a cleanup script the teacher wrote to replace the identifiers with ASCII
identifiers so that they can actually run their programs. This disproves your
assertion on both counts.

-Carsten

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: tkFileDialog.askopenfilename()

[Hamilton, William]

> From: [EMAIL PROTECTED]
> 
> Hi,
> When I call tkFileDialog.askopenfilename() , the dialog box opens with
> the current directory as the default directory. Is it possible to open
> the dialog box with a directory other than the current directory. Can
> we pass in  a user defined starting directory.
> Thanks
> Rahul
> 

This link has a decent amount of info about the various dialog modules.
http://www.pythonware.com/library/tkinter/introduction/x1164-data-entry.htm


---
-Bill Hamilton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Ross Ridge]

Ross Ridge schrieb:
> non-ASCII identifiers.  While it's easy to find code where comments use
> non-ASCII characters, I was never able to find a non-made up example
> that used them in identifiers.

Gregor Horvath  <[EMAIL PROTECTED]> wrote:
>If comments are allowed to be none English, then why are identifier not?

In the code I was looking at identifiers were allowed to use non-ASCII
characters.  For whatever reason, the programmers choose not use non-ASCII
indentifiers even though they had no problem using non-ASCII characters
in commonets.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Garbage Collector in Zope 2.8

[[EMAIL PROTECTED]]

Hi. Can anyone tell me how to run garbage collector in zope manually
in zope runtime?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

You have misread my statements.

Carsten Haese schrieb:
> There is evidence against your assertions that knowing some English is a
> prerequisite for programming 

I think it is a prerequesite for "real" programming. Yes, I can imagine
that if you use Python as a teaching tool for Chinese 12 year-olds, then
it might be nice to be able to spell identifiers with Chinese
characters. However, IMO this is such a special use-case that it is
justified to require the people who need this to explicitly enable it,
by using a patched interpreter or by enabling an interpreter option for
example.

> in Python and that people won't use non-ASCII
> identifiers if they could. 

I did not assert that at all, where did you get the impression that I
do? If I were convinced that noone would use it, I would have not such a
big problem with it. I fear that it *will* be used "in the wild" if the
PEP in its current form is accepted and that I personally *will* have to
deal with such code.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Splitting a quoted string.

[mosscliffe]

Thank you very much for all for your replies.

I am now much wiser to using regex and CSV.

As I am quite a newbie, I have had my 'class' education improved as
well.

Many thanks again

Richard

On May 16, 12:48 pm, Duncan Booth <[EMAIL PROTECTED]>
wrote:
> mosscliffe <[EMAIL PROTECTED]> wrote:
> > I am looking for a simple split function to create a list of entries
> > from a string which contains quoted elements.  Like in 'google'
> > search.
>
> > eg  string = 'bob john "johnny cash" 234 june'
>
> > and I want to have a list of ['bob', 'john, 'johnny cash', '234',
> > 'june']
>
> > I wondered about using the csv routines, but I thought I would ask the
> > experts first.
>
> > There maybe a simple function, but as yet I have not found it.
>
> You probably need to specify the problem more completely. e.g. Can the
> quoted parts of the strings contain quote marks? If so how what are the
> rules for escaping them. Do two spaces between a word mean an empty field
> or still a single string delimiter.
>
> Once you've worked that out you can either use re.split with a suitable
> regular expression, or use the csv module specifying your desired dialect:
>
> >>> class mosscliffe(csv.Dialect):
>
> delimiter = ' '
> quotechar = '"'
> doublequote = False
> skipinitialspace = False
> lineterminator = '\r\n'
> quoting = csv.QUOTE_MINIMAL
>
> >>> csv.register_dialect("mosscliffe", mosscliffe)
> >>> string = 'bob john "johnny cash" 234 june'
> >>> for row in csv.reader([string], dialect="mosscliffe"):
>
> print row
>
> ['bob', 'john', 'johnny cash', '234', 'june']


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[George Sakkis]

On May 13, 11:44 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:

> (snipped)
>
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?

Initially I was on -1 but from this thread it seems that many closed
(or semi-closed) environments would benefit from such a change. I'm
still concerned though about the segregation this feature encourages.
In my (admittedly limited) experience on non-english-speaking
environments, everyone used to have some basic command of english and
was encouraged to use proper english identifiers; OTOH, the hodgepodge
of english keywords/stdlib/3rd party symbols with transliterated to
ascii application identifiers was being looked down as clumsy and in
fact less readable.

Bottom line, -0.

> - would you use them if it was possible to do so? in what cases?

No, and I would refuse to maintain code that did use them*.

George


* Unless I start teaching programming to preschoolers or something.

-- 
http://mail.python.org/mailman/listinfo/python-list

Execute commands from file

[tmp123]

Hello,

Thanks for your time.

We have very big files with python commands (more or less, 50
commands each file).

It is possible to execute them command by command, like if the
commands was typed one after the other in a interactive session?

( Better using command flags than with an small script like "while 1:
input()")

Thanks a lot.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Jochen Schulz]

* René Fleschenberg:
> Stefan Behnel schrieb:
>> 
>> [...] They are just tools. Even if you do not
>> understand English, they will not get in your way. You just learn them.
> 
> I claim that this is *completely unrealistic*. When learning Python, you
> *do* learn the actual meanings of English terms like "open",
> "exception", "if" and so on if you did not know them before.

This is certainly true for easy words like "open" and "in". But there
are a lot of counterexamples.

When learning something new, you always learn a lot of new concepts and
you get to know how they are called in this specific context. For
example, when you learn to program, you might stumble upon the idea of
"exceptions", which you can raise/throw and except/catch. But even if
you know how to use that concept and understand what it does, you do not
necessarily know the "usual" meaning of the word outside of your domain.

As far as I can tell, quite often these are the terms that even enter
the native language without any translation (even though there are
perfect translations for the words in their original meaning).  German
examples are "exceptions", "client" and "server", "mail", "hub" and
"switch", "web" and many, many more. Nobody who uses these terms has to
know their exact meaning in his native language as long as he speaks to
Germans or stays in the domain where he learned them.

I read a lot of English text every day but I am sometimes still
surprised to learn that a word I already knew has a meaning outside
of computing. "Hub" is a nice example for that. I was very surprised to
learn that even my bike has this. ;-)

J.
-- 
If I was Mark Chapman I would have shot John Lennon with a water pistol.
[Agree]   [Disagree]
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Splitting a quoted string.

[Gerard Flanagan]

On May 16, 12:42 pm, mosscliffe <[EMAIL PROTECTED]> wrote:
> I am looking for a simple split function to create a list of entries
> from a string which contains quoted elements.  Like in 'google'
> search.
>
> eg  string = 'bob john "johnny cash" 234 june'
>
> and I want to have a list of ['bob', 'john, 'johnny cash', '234',
> 'june']
>
> I wondered about using the csv routines, but I thought I would ask the
> experts first.
>
> There maybe a simple function, but as yet I have not found it.
>

See 'split' from 'shlex' module:

>>> s = 'bob john "johnny cash" 234 june'
>>> import shlex
>>> shlex.split(s)
['bob', 'john', 'johnny cash', '234', 'june']
>>>


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Sion Arrowsmith]

Steven D'Aprano  <[EMAIL PROTECTED]> wrote:
>On Tue, 15 May 2007 09:09:30 +0200, Eric Brunel wrote:
>> Joke aside, this just means that I won't ever be able to program math in
>> ADA, because I have absolutely no idea on how to do a 'pi' character on
>> my keyboard.
>Maybe you should find out then? Personal ignorance is never an excuse for 
>rejecting technology.

The funny thing is, I could have told you exactly how to type a 'pi'
character 18 years ago, when my main use of computers was typesetting
on a Mac. These days ... I've just spent 20 minutes trying to find out
how to insert one into this text (composed in emacs on a remote
machine, connected via ssh from konsole).

-- 
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
   "Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
   her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: removing common elemets in a list

[Carsten Haese]

On Tue, 2007-05-15 at 23:17 -0700, [EMAIL PROTECTED] wrote:
> Hi,
>  Suppose i have a list v which collects some numbers,how do i
> remove the common elements from it ,without using the set() opeartor.
>   Thanks

If the list is sorted, you can weed out the duplicates with
itertools.groupby:

>>> import itertools
>>> L = [1,2,3,3,4,4,5]
>>> [k for (k,_) in itertools.groupby(L, lambda x:x)]
[1, 2, 3, 4, 5]

HTH,

-- 
Carsten Haese
http://informixdb.sourceforge.net


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Javier Bezos]

"Eric Brunel" <[EMAIL PROTECTED]> escribió en el mensaje

> Funny you talk about Japanese, a language I'm a bit familiar with and for
> which I actually know some input methods. The thing is, these only work if
> you know the transcription to the latin alphabet of the word you want to
> type, which closely match its pronunciation. So if you don't know that ??
> ? is pronounced "uriba" for example, you have absolutely no way of
> entering the word.

Actually, you can draw the character (in XP, at
least) entirely or in part and the system shows a
list of them with similar shapes. IIRC, there is
a similar tool on Macs. Of course, I'm not saying
this allows to enter kanji in a easy and fast way,
but certainly it's not impossible at all, even if
you don't know the pronunciation.

Javier
---
http://www.texytipografia.com




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Execute commands from file

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, tmp123 wrote:

> We have very big files with python commands (more or less, 50
> commands each file).
> 
> It is possible to execute them command by command, like if the
> commands was typed one after the other in a interactive session?

Take a look at the `code` module in the standard library:

In [31]: code?
Type:   module
Base Class: 
String Form:
Namespace:  Interactive
File:   /usr/lib/python2.4/code.py
Docstring:
Utilities needed to emulate Python's interactive interpreter.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Sion Arrowsmith]

Hendrik van Rooyen <[EMAIL PROTECTED]> wrote:
>I still don't like the thought of the horrible mix of "foreign"
>identifiers and English keywords, coupled with the English 
>sentence construction.

How do you think you'd feel if Python had less in the way of
(conventionally used) English keywords/builtins. Like, say, Perl?

-- 
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
   "Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
   her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
-- 
http://mail.python.org/mailman/listinfo/python-list