Re: PEP 3131: Supporting Non-ASCII Identifiers

[Hendrik van Rooyen]

 "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote:

>Martin v. Löwis a écrit :
>> So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported?
>
>No.

Agreed - I also do not think it is a good idea

>
>> why?
>
>Because it will definitivly make code-sharing impossible. Live with it
>or else, but CS is english-speaking, period. I just can't understand
>code with spanish or german (two languages I have notions of)
>identifiers, so let's not talk about other alphabets...
>

The understanding aside, it seems to me that the maintenance nightmare is
more irritating, as you are faced with stuff you can't type on your
keyboard,  without resorting to look up tables and  ... sequences.
And then you could still be wrong, as has been pointed out for capital
A and Greek alpha.

Then one should consider the effects of this on the whole issue of shared
open source python programs, as Bruno points out, before we argue that
I should not be "allowed" access to Greek, or French and German code
with umlauts and other diacritic marks, as someone else has done.

I think it is best to say nothing of Saint Cyril's script.

I think that to allow identifiers to be "native", while the rest of the
reserved words in the language remains ASCII English kind of
defeats the object of making the python language "language friendly".
It would need something like macros to enable the definition of
native language terms for things like "while", "for", "in", etc...

And we have been through the Macro thingy here, and the consensus
seemed to be that we don't want people to write their own dialects.

I think that the same arguments apply here.

>NB : I'm *not* a native english speaker, I do *not* live in an english
>speaking country, and my mother's language requires non-ascii encoding.
>And I don't have special sympathy for the USA. And yes, I do write my
>code - including comments - in english.
>

My case is similar, except that we are supposed to have eleven official
languages. - When my ancestors fought the English at Spion Kop*,
we could not even spell our names - and here I am defending the use of
this disease that masquerades as a language, in the interests of standardisation
of  communication and ease of sharing and maintenance.

BTW - Afrikaans also has stuff like umlauts - my keyboard cannot type them
and I rarely miss it, because most of my communication is done in English.

- Hendrik

* Spion Kop is one of the few battles in history that went contrary to the
common usage whereby both sides claim victory.  In this case, both sides
claimed defeat.  "We have suffered a small reverse..." - Sir Redvers Buller,
who was known afterwards as Sir Reverse Buller, or the Ferryman of the
Tugela.  To be fair, it was the first war with trenches in it, and nobody
knew how to handle them.



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

Jessica Simpson Sports new "Boob Job"!!!@

[ready . or . special2]

http://jessicasboobs.blogspot.com/2007/05/jessica-simpson-furious-after-john.html
- Have a look and see what I mean its a boob job you just can't afFORD
to miss out on!!

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

Re: Interesting list Validity (True/False)

[Gabriel Genellina]

En Sun, 13 May 2007 23:45:22 -0300, [EMAIL PROTECTED]  
<[EMAIL PROTECTED]> escribió:
> On May 13, 2:09?pm, Carsten Haese <[EMAIL PROTECTED]> wrote:

>> There are no exceptions.
> "...and when I say none, I mean there is a certain amount."

One of the beautiful things about Python that I like, is how few  
exceptions it has; most things are rather regular.

-- 
Gabriel Genellina

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

Re: Removing part of string

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, saif.shakeel
wrote:

> Hi,
> I am parsing an xml file ,and one part of structure looks
> something like this:
> 
> -  PhysicalLink="Infotainment_Control_Bus_CAN">
>   Infotainment_Control_Bus_CAN_TIMEOUT_AX
>   Timeout N_As/N_Ar
>   Time from transmit request until a CAN frame transmit
> confirmation is received.
>   
> 
>   In my code i am extracting the data within
> ,which is Timeout N_As/N_Ar.These tags repeat and will have
> different timer names..like
> 
> -  PhysicalLink="Infotainment_Control_Bus_CAN">
>   Infotainment_Control_Bus_CAN_TIMEOUT_BS
>   Timeout N_Bs
>   Time that the transmitter of a multi-frame message
> shall wait to receive a flow control (FC) frame before timing out with
> a network layer error.
>   
> 
>  I need to remove the words Timeout from the data,and
> take only the abbrevation..i.e.N_As/N_bs like that .In short i have to
> remove the words which come with name Time,and also the space which
> comes next to it.
> and take only the abbreviation.Can someone help me in this.

You can test for the prefix with the `startswith()` method and use string
slicing to create a new string without the prefix:

In [3]: prefix = 'Timeout '

In [4]: longname = 'Timeout N_Bs'

In [5]: longname.startswith(prefix)
Out[5]: True

In [6]: longname = longname[len(prefix):]

In [7]: longname
Out[7]: 'N_Bs'

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Jarek Zgoda]

Alexander Schmolck napisał(a):

>>> So, please provide feedback, e.g. perhaps by answering these
>>> questions:
>>> - should non-ASCII identifiers be supported? why?
>> No, because "programs must be written for people to read, and only
>> incidentally for machines to execute". Using anything other than "lowest
>> common denominator" (ASCII) will restrict accessibility of code. This is
>> not a literature, that requires qualified translators to get the text
>> from Hindi (or Persian, or Chinese, or Georgian, or...) to Polish.
>>
>> While I can read the code with Hebrew, Russian or Greek names
>> transliterated to ASCII, I would not be able to read such code in native.
> 
> Who or what would force you to? Do you currently have to deal with hebrew,
> russian or greek names transliterated into ASCII? I don't and I suspect this
> whole panic about everyone suddenly having to deal with code written in kanji,
> klingon and hieroglyphs etc. is unfounded -- such code would drastically
> reduce its own "fitness" (much more so than the ASCII-transliterated chinese,
> hebrew and greek code I never seem to come across), so I think the chances
> that it will be thrust upon you (or anyone else in this thread) are minuscule.

I often must read code written by people using some kind of cyrillic
(Russians, Serbs, Bulgarians). "Native" names transliterated to ascii
are usual artifacts and I don't mind it.

> BTW, I'm not sure if you don't underestimate your own intellectual faculties
> if you think couldn't cope with greek or russian characters. On the other hand
> I wonder if you don't overestimate your ability to reasonably deal with code
> written in a completely foreign language, as long as its ASCII -- for anything
> of nontrivial length, surely doing anything with such code would already be
> orders of magnitude harder?

While I don't have problems with some of non-latin character sets, such
as greek and cyrillic (I was attending school in time when learning
Russian was obligatory in Poland and later I learned Greek), there are a
plenty I wouldn't be able to read, such as Hebrew, Arabic or Persian.

-- 
Jarek Zgoda

"We read Knuth so you don't have to."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Paul Rubin wrote:

> Alexander Schmolck <[EMAIL PROTECTED]> writes:
>> Plenty of programming languages already support unicode identifiers, 
> 
> Could you name a few?  Thanks.

Haskell.  AFAIK the Haskell Report says so but the compilers don't
supported it last time I tried.  :-)

Ciao,
Marc 'BlackJack' Rintsch

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

Re: Basic question

[Gabriel Genellina]

En Mon, 14 May 2007 02:05:47 -0300, Alex Martelli <[EMAIL PROTECTED]> escribió:

> Gabriel Genellina <[EMAIL PROTECTED]> wrote:

>> But that's not the same as requested - you get a plain list, and the
>> original was a list of lists:
> Are we talking about the same code?!  What I saw at the root of this
> subthread was, and I quote:

[...code painfully building a plain list...]

Oh, sorry, I got confused with another reply then.

>> And thanks for my "new English word of the day": supererogatory :)
> You're welcome!  Perhaps it's because I'm not a native speaker of
> English, but I definitely do like to widen my vocabulary (and others').

Me too!

-- 
Gabriel Genellina

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

Re: Removing part of string

[half . italian]

On May 13, 10:56 pm, [EMAIL PROTECTED] wrote:
> Hi,
> I am parsing an xml file ,and one part of structure looks
> something like this:
>
> -  PhysicalLink="Infotainment_Control_Bus_CAN">
>   Infotainment_Control_Bus_CAN_TIMEOUT_AX
>   Timeout N_As/N_Ar
>   Time from transmit request until a CAN frame transmit
> confirmation is received.
>   
>
>   In my code i am extracting the data within
> ,which is Timeout N_As/N_Ar.These tags repeat and will have
> different timer names..like
>
> -  PhysicalLink="Infotainment_Control_Bus_CAN">
>   Infotainment_Control_Bus_CAN_TIMEOUT_BS
>   Timeout N_Bs
>   Time that the transmitter of a multi-frame message
> shall wait to receive a flow control (FC) frame before timing out with
> a network layer error.
>   
>
>  I need to remove the words Timeout from the data,and
> take only the abbrevation..i.e.N_As/N_bs like that .In short i have to
> remove the words which come with name Time,and also the space which
> comes next to it.
> and take only the abbreviation.Can someone help me in this.
>  Thanks

Did you get elementtree working?

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Neil Hodgson]

Martin v. Löwis:

> This PEP suggests to support non-ASCII letters (such as accented
> characters, Cyrillic, Greek, Kanji, etc.) in Python identifiers.

I support this to ease integration with other languages and 
platforms that allow non-ASCII letters to be used in identifiers. Python 
has a strong heritage as a glue language and this has been enabled by 
adapting to the features of various environments rather than trying to 
assert a Pythonic view of how things should work.

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

Re: How to do basic CRUD apps with Python

[g_teodorescu]

walterbyrd a scris:
> With PHP, libraries, apps, etc. to do basic CRUD are everywhere. Ajax
> and non-Ajax solutions abound.
>
> With Python, finding such library, or apps. seems to be much more
> difficult to find.
>
> I thought django might be a good way, but I can not seem to get an
> answer on that board.
>
> I would like to put together a CRUD grid with editable/deletable/
> addable fields, click on the headers to sort. Something that would
> sort-of looks like an online  spreadsheet. It would be nice if the
> fields could be edited in-line, but it's not entirely necessary.
>
> Are there any Python libraries to do that sort of thing? Can it be
> done with django or cherrypy?
>
> Please, don't advertise your PHP/Ajax apps.

Try SqlSoup from SqlAlchemy. I can send examples in PyQt4.

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

Re: How to do basic CRUD apps with Python

[g_teodorescu]

walterbyrd a scris:
> With PHP, libraries, apps, etc. to do basic CRUD are everywhere. Ajax
> and non-Ajax solutions abound.
>
> With Python, finding such library, or apps. seems to be much more
> difficult to find.
>
> I thought django might be a good way, but I can not seem to get an
> answer on that board.
>
> I would like to put together a CRUD grid with editable/deletable/
> addable fields, click on the headers to sort. Something that would
> sort-of looks like an online  spreadsheet. It would be nice if the
> fields could be edited in-line, but it's not entirely necessary.
>
> Are there any Python libraries to do that sort of thing? Can it be
> done with django or cherrypy?
>
> Please, don't advertise your PHP/Ajax apps.

SqlAlchemy-SqlSoup Example:


# SqlSoup. CRUD with one table
from sqlalchemy.ext.sqlsoup import SqlSoup


# connection: 'postgres://user:[EMAIL PROTECTED]:port/db_name'
db = SqlSoup('postgres://postgres:[EMAIL PROTECTED]:5432/testdb')

# read data
person = db.person.select()
print person

# index is not the same with primary key !!!
print person[0].firstname

# write in column firstname
person[0].firstname = "George"

# effective write
db.flush()

print person[0]

print db.person.count()

for i in range(0, db.person.count()):
print person[i]

db.person.insert(id=1000, firstname='Mitu')
db.flush

# after insert, reload mapping:
person = db.person.select()

# delete:
# record select
mk = db.person.selectone_by(id=1000)
# delete
db.delete(mk)
db.flush()

person = db.person.select()

print person


"""
FROM DOCUMENTATION:

===
SqlSoup
===

Introduction

SqlSoup provides a convenient way to access database tables without
having to
declare table or mapper classes ahead of time.

Suppose we have a database with users, books, and loans tables
(corresponding to
the PyWebOff dataset, if you're curious).
For testing purposes, we'll create this db as follows:

>>> from sqlalchemy import create_engine
>>> e = create_engine('sqlite:///:memory:')
>>> for sql in _testsql: e.execute(sql) #doctest: +ELLIPSIS
<...

Creating a SqlSoup gateway is just like creating an SqlAlchemy engine:

>>> from sqlalchemy.ext.sqlsoup import SqlSoup
>>> db = SqlSoup('sqlite:///:memory:')

or, you can re-use an existing metadata:

>>> db = SqlSoup(BoundMetaData(e))

You can optionally specify a schema within the database for your
SqlSoup:

# >>> db.schema = myschemaname

Loading objects

Loading objects is as easy as this:

>>> users = db.users.select()
>>> users.sort()
>>> users
[MappedUsers(name='Joe Student',email='[EMAIL PROTECTED]',
password='student',classname=None,admin=0),
 MappedUsers(name='Bhargan Basepair',email='[EMAIL PROTECTED]',
password='basepair',classname=None,admin=1)]

Of course, letting the database do the sort is better
(".c" is short for ".columns"):

>>> db.users.select(order_by=[db.users.c.name])
[MappedUsers(name='Bhargan Basepair',email='[EMAIL PROTECTED]',
password='basepair',classname=None,admin=1),
 MappedUsers(name='Joe Student',email='[EMAIL PROTECTED]',
password='student',classname=None,admin=0)]

Field access is intuitive:

>>> users[0].email
u'[EMAIL PROTECTED]'

Of course, you don't want to load all users very often.
Let's add a WHERE clause.
Let's also switch the order_by to DESC while we're at it.

>>> from sqlalchemy import or_, and_, desc
>>> where = or_(db.users.c.name=='Bhargan Basepair',
db.users.c.email=='[EMAIL PROTECTED]')
>>> db.users.select(where, order_by=[desc(db.users.c.name)])
[MappedUsers(name='Joe Student',email='[EMAIL PROTECTED]',
password='student',classname=None,admin=0),
 MappedUsers(name='Bhargan Basepair',email='[EMAIL PROTECTED]',
password='basepair',classname=None,admin=1)]

You can also use the select...by methods if you're querying on a
single column.
This allows using keyword arguments as column names:

>>> db.users.selectone_by(name='Bhargan Basepair')
MappedUsers(name='Bhargan Basepair',email='[EMAIL PROTECTED]',
password='basepair',classname=None,admin=1)

Select variants

All the SqlAlchemy Query select variants are available.
Here's a quick summary of these methods:

* get(PK): load a single object identified by its primary key
(either a scalar, or a tuple)
* select(Clause, **kwargs): perform a select restricted by the
Clause
argument; returns a list of objects.
The most common clause argument takes the form
"db.tablename.c.columname == value."
The most common optional argument is order_by.
* select_by(**params): select methods ending with _by allow using
bare
column names. (columname=value) This feels more natural to
most Python
programmers; the downside is you can't specify order_by or
other
select options.
* selectfirst, selectfirst_by: returns only the first object
found;
eq

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Sun, 13 May 2007 21:10:46 +0200, Stefan Behnel  
<[EMAIL PROTECTED]> wrote:
[snip]
> Now, I am not a strong supporter (most public code will use English
> identifiers anyway)

How will you guarantee that? I'm quite convinced that most of the public  
code today started its life as private code earlier...

> So, introducing non-ASCII identifiers is just a
> small step further. Disallowing this does *not* guarantee in any way that
> identifiers are understandable for English native speakers. It only  
> guarantees
> that identifiers are always *typable* by people who have access to latin
> characters on their keyboard. A rather small advantage, I'd say.

I would certainly not qualify that as "rather small". There have been  
quite a few times where I had to change some public code. If this code had  
been written in a character set that did not exist on my keyboard, the  
only possibility would have been to copy/paste every identifier I had to  
type. Have you ever tried to do that? It's actually quite simple to test  
it: just remove on your keyboard a quite frequent letter ('E' is a good  
candidate), and try to update some code you have at hand. You'll see that  
it takes 4 to 5 times longer than writing the code directly, because you  
always have to switch between keyboard and mouse far too often. In  
addition to the unnecessary movements, it also completely breaks your  
concentration. Typing foreign words transliterated to english actually  
does take longer than typing "proper" english words, but at least, it can  
be done, and it's still faster than having to copy/paste everything.

So I'd say that it would be a major drawback for code sharing, which - if  
I'm not mistaken - is the basis for the whole open-source philosophy.
-- 
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: How to do basic CRUD apps with Python

[g_teodorescu]

walterbyrd a scris:
> With PHP, libraries, apps, etc. to do basic CRUD are everywhere. Ajax
> and non-Ajax solutions abound.
>
> With Python, finding such library, or apps. seems to be much more
> difficult to find.
>
> I thought django might be a good way, but I can not seem to get an
> answer on that board.
>
> I would like to put together a CRUD grid with editable/deletable/
> addable fields, click on the headers to sort. Something that would
> sort-of looks like an online  spreadsheet. It would be nice if the
> fields could be edited in-line, but it's not entirely necessary.
>
> Are there any Python libraries to do that sort of thing? Can it be
> done with django or cherrypy?
>
> Please, don't advertise your PHP/Ajax apps.

SqlAlchemy - SqlSoup - PyQt4 (fragment) example:

import sys
from PyQt4.Qt import *
from PyQt4 import uic
from avc.avcqt4 import *
from sqlalchemy.ext.sqlsoup import SqlSoup

from ui_db import Ui_DbForm

class DbForm(QWidget,AVC):
def __init__(self, parent=None):
QWidget.__init__(self,parent)

self.ui = Ui_DbForm()
self.ui.setupUi(self)

# current index
self.crtIndex = 0
self.crtPk = 0

# avc variables, same names as form widgets (lineEdit, combo,
etc)
self.edtId = 0
self.edtFirstName = ""
self.edtLastName = ""
self.edtSalary = 0.0

self.connect(self.ui.btnQuit, SIGNAL("clicked()"),
 qApp, SLOT("quit()"))

self.connect(self.ui.btnFirst, SIGNAL("clicked()"),
self.goFirst)
self.connect(self.ui.btnPrior, SIGNAL("clicked()"),
self.goPrior)
self.connect(self.ui.btnNext, SIGNAL("clicked()"),
self.goNext)
self.connect(self.ui.btnLast, SIGNAL("clicked()"),
self.goLast)

self.connect(self.ui.btnSave, SIGNAL("clicked()"),
self.doSave)
self.connect(self.ui.btnAdd, SIGNAL("clicked()"), self.doAdd)
self.connect(self.ui.btnDel, SIGNAL("clicked()"),
self.doDel)

# connection: 'postgres://user:[EMAIL PROTECTED]:port/db_name'
self.db = SqlSoup('postgres://postgres:[EMAIL PROTECTED]:5432/
testdb')

self.goFirst()



def goFirst(self):
self.crtIndex = 0
self.doRead(self.crtIndex)

def goPrior(self):
if self.crtIndex > 0:
self.crtIndex = self.crtIndex - 1
else:
self.crtIndex = 0
self.doRead(self.crtIndex)

def goNext(self):
maxIndex = self.db.person.count() - 1
if self.crtIndex < maxIndex:
self.crtIndex = self.crtIndex + 1
else:
self.crtIndex = maxIndex
self.doRead(self.crtIndex)

def goLast(self):
maxIndex = self.db.person.count() - 1
self.crtIndex = maxIndex
self.doRead(self.crtIndex)

def doSave(self):
if self.crtPk == 0:
# aflu pk-ul si adaug o inregistrare goala
newPk = self.db.engine.execute("select
nextval('person_id_seq')").fetchone()[0]
self.crtPk = newPk
self.db.person.insert(id=self.crtPk, firstname='',
lastname='', salary=0.0)
self.db.flush()
person = self.db.person.selectone_by(id=self.crtPk)
person.firstname = self.edtFirstName
person.lastname = self.edtLastName
person.salary = self.edtSalary
self.db.flush()

def doAdd(self):
self.crtPk = 0
self.edtId = self.crtPk
self.edtFirstName = ""
self.edtLastName = ""
self.edtSalary = 0.0
# inregistrarea trebuie salvata explicit
# prin apasarea butonului "Save"

def doDel(self):
mk = self.db.person.selectone_by(id=self.crtPk)
self.db.delete(mk)
self.db.flush()
self.goNext()

def doRead(self, index):
person = self.db.person.select()
self.edtId = person[index].id
self.edtFirstName = person[index].firstname
self.edtLastName = person[index].lastname
self.edtSalary  = person[index].salary
# invariant pt. toate operatiile, mai putin adaugare
inregistrare
# pk-ul nu se poate modifica prin edtId !!!
self.crtPk = person[index].id


if __name__ == "__main__":
app = QApplication(sys.argv)
# QApplication.setStyle(QStyleFactory.create("Cleanlooks"))
QApplication.setStyle(QStyleFactory.create("Plastique"))
form = DbForm()
form.avc_init()
form.show()
sys.exit(app.exec_())

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Sun, 13 May 2007 23:55:11 +0200, Bruno Desthuilliers  
<[EMAIL PROTECTED]> wrote:

> Martin v. Löwis a écrit :
>> PEP 1 specifies that PEP authors need to collect feedback from the
>> community. As the author of PEP 3131, I'd like to encourage comments
>> to the PEP included below, either here (comp.lang.python), or to
>> [EMAIL PROTECTED]
>>  In summary, this PEP proposes to allow non-ASCII letters as
>> identifiers in Python. If the PEP is accepted, the following
>> identifiers would also become valid as class, function, or
>> variable names: Löffelstiel, changé, ошибка, or 売り場
>> (hoping that the latter one means "counter").
>>  I believe this PEP differs from other Py3k PEPs in that it really
>> requires feedback from people with different cultural background
>> to evaluate it fully - most other PEPs are culture-neutral.
>>  So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported?
>
> No.
>
>> why?
>
> Because it will definitivly make code-sharing impossible. Live with it  
> or else, but CS is english-speaking, period. I just can't understand  
> code with spanish or german (two languages I have notions of)  
> identifiers, so let's not talk about other alphabets...

+1 on everything.

> NB : I'm *not* a native english speaker, I do *not* live in an english  
> speaking country,

... and so am I (and this happens to be the same country as Bruno's...)

> and my mother's language requires non-ascii encoding.

... and so does my wife's (she's Japanese).

> And I don't have special sympathy for the USA. And yes, I do write my  
> code - including comments - in english.

Again, +1. Even when writing code that appears to be "private" at some  
time, one *never* knows what will become of it in the future. If it ever  
goes public, its chances to evolve - or just to be maintained - are far  
bigger if it's written all in english.
-- 
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

[Stefan Behnel]

Eric Brunel wrote:
> Even when writing code that appears to be "private" at some
> time, one *never* knows what will become of it in the future. If it ever
> goes public, its chances to evolve - or just to be maintained - are far
> bigger if it's written all in english.
>
> --python -c "print ''.join([chr(154 - ord(c)) for c in
> 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

Oh well, why did *that* code ever go public?

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Eric Brunel wrote:
> On Sun, 13 May 2007 21:10:46 +0200, Stefan Behnel
> <[EMAIL PROTECTED]> wrote:
> [snip]
>> Now, I am not a strong supporter (most public code will use English
>> identifiers anyway)
> 
> How will you guarantee that? I'm quite convinced that most of the public
> code today started its life as private code earlier...

Ok, so we're back to my original example: the problem here is not the
non-ASCII encoding but the non-english identifiers.

If we move the problem to a pure unicode naming problem:

How likely is it that it's *you* (lacking a native, say, kanji keyboard) who
ends up with code that uses identifiers written in kanji? And that you are the
only person who is now left to do the switch to an ASCII transliteration?

Any chance there are still kanji-enabled programmes around that were not hit
by the bomb in this scenario? They might still be able to help you get the
code "public".

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Alex Martelli schrieb:
> Aldo Cortesi <[EMAIL PROTECTED]> wrote:
> 
>> Thus spake Steven D'Aprano ([EMAIL PROTECTED]):
>>
>>> If you're relying on cursory visual inspection to recognize harmful code,
>>> you're already vulnerable to trojans.
>> What a daft thing to say. How do YOU recognize harmful code in a patch
>> submission? Perhaps you blindly apply patches, and then run your test suite 
>> on
>> a quarantined system, with an instrumented operating system to allow you to
>> trace process execution, and then perform a few weeks worth of analysis on 
>> the
>> data?
>>
>> Me, I try to understand a patch by reading it. Call me old-fashioned.
> 
> I concur, Aldo.  Indeed, if I _can't_ be sure I understand a patch, I
> don't accept it -- I ask the submitter to make it clearer.
> 
> Homoglyphs would ensure I could _never_ be sure I understand a patch,
> without at least running it through some transliteration tool.  I don't
> think the world of open source needs this extra hurdle in its path.

But then, where's the problem? Just stick to accepting only patches that are
plain ASCII *for your particular project*. And if you want to be sure, put an
ASCII encoding header in all source files (which you want to do anyway, to
prevent the same problem with string constants).

The PEP is only arguing to support this decision at a per-project level rather
than forbidding it at the language level. This makes sense as it moves the
power into the hands of those people who actually use it, not those who
designed the language.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Bruno Desthuilliers wrote:
> but CS is english-speaking, period.

That's a wrong assumption. I understand that people can have this impression
when they deal a lot with Open Source code, but I've seen a lot of places
where code was produced that was not written to become publicly available (and
believe me, it *never* will become Open Source). And the projects made strong
use of identifiers with domain specific names. And believe me, those are best
expressed in a language your client knows and expresses concepts in. And this
is definitely not the language you claim to be the only language in CS.

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

Re: Asyncore Help?

[Daniel Nogradi]

> I am working on the networking code for a small Multiplayer RPG I'm
> working on. I currently have some basic code using threads, but it
> seems like asyncore would be far better suited for my needs. However,
> I have trouble finding a solid example for what I need. Python.org and
> other sites provide simple examples, but they appear more intended for
> servers that simply send one peice of data to the client.
>
> I want to have a server program that is willing to accept commands
> sent from the client, and repeatedly wait for data and respond.
> Maintaining a long term connection until the client is done playing.
>
> Besides this I am also stuck with dealing with TCP data streams. I can
> receive and send the data (using threads, not yet with asynocore), but
> I am unsure how to deal with the streamlike nature of TCP (and would
> prefer to use TCP over UDP). I would like to have it so that the
> client sends the server a command (such as update position), and then
> the data, and have the server update that information on its side
> accordingly.
>
> While basic socket work was rather easy to deal with, this has proved
> significantly more difficult. Are there any good free sources for
> information on Asyncore, and dealing with TCP?

The twisted project might also be a good place for anything related to
python and networking: http://twistedmatrix.com/trac/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anton Vredegoor]

In article <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...
> Martin v. Löwis:
> 
> > This PEP suggests to support non-ASCII letters (such as accented
> > characters, Cyrillic, Greek, Kanji, etc.) in Python identifiers.
> 
> I support this to ease integration with other languages and 
> platforms that allow non-ASCII letters to be used in identifiers. Python 
> has a strong heritage as a glue language and this has been enabled by 
> adapting to the features of various environments rather than trying to 
> assert a Pythonic view of how things should work.
> 
> Neil
> 
Ouch! Now I seem to be disagreeing with the one who writes my editor. 
What will become of me now?

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

Re: Asyncore Help?

[Nick Craig-Wood]

Erik Max Francis <[EMAIL PROTECTED]> wrote:
>  Paul Kozik wrote:
> 
> > While basic socket work was rather easy to deal with, this has proved
> > significantly more difficult. Are there any good free sources for
> > information on Asyncore, and dealing with TCP?
> 
>  You haven't said specifically what you're having a problem with.  The 
>  more general name for asyncore/asynchat is Medusa, and there are some 
>  resources with more examples available here:
> 
>   http://www.nightmare.com/medusa/
>   http://www.amk.ca/python/code/medusa.html

There is also twisted of course if we are talking about async
networking libraries.

  http://twistedmatrix.com/trac/

The learning curve of twisted is rather brutal, but it will do
everything you want and a whole lot more!  I haven't tried Medusa, but
I've done several things with twisted.  It takes a bit of getting your
head round but you'll be impressed with the speed.

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Nick Craig-Wood]

Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>  So, please provide feedback, e.g. perhaps by answering these
>  questions:

Firstly on the PEP itself:

It defines characters that would be allowed.  However not being up to
speed on unicode jargon I don't have a clear idea about which
characters those are.  A page with some examples or even all possible
allowed characters would be great, plus some examples of disallowed
characters.

>  - should non-ASCII identifiers be supported? why?

Only if PEP 8 was amended to state that ASCII characters only should
be used for publically released / library code.  I'm quite happy with
Unicode in comments / docstrings (but that is supported already).

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

My initial reaction is that it would be cool to use all those great
symbols.  A variable called OHM etc! However on reflection I think it
would be a step back for the easy to read nature of python.

My worries are :-

a) English speaking people would invent their own dialects of python
which looked like APL with all those nice Unicode mathematical
operators / Greek letters you could use as variable/function names.  I
like the symbol free nature of python which makes for easy
comprehension of code and don't want to see it degenerate.

b) Unicode characters would creep into the public interface of public
libraries.  I think this would be a step back for the homogeneous
nature of the python community.

c) the python keywords are in ASCII/English.  I hope you weren't
thinking of changing them?

...

In summary, I'm not particularly keen on the idea; though it might be
all right in private.  Unicode identifiers are allowed in java though,
so maybe I'm worrying too much ;-)

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Asyncore Help?

[Michael Bentley]

On May 14, 2007, at 4:30 AM, Nick Craig-Wood wrote:

> The learning curve of twisted is rather brutal

:-)

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

Re: Asyncore Help?

[Jarek Zgoda]

Daniel Nogradi napisał(a):

> The twisted project might also be a good place for anything related to
> python and networking: http://twistedmatrix.com/trac/

Twisted eats babies for breakfast, although it also kills all known
germs(TM). ;)

-- 
Jarek Zgoda

"We read Knuth so you don't have to."
-- 
http://mail.python.org/mailman/listinfo/python-list

multi threaded SimpleXMLRPCServer

[Vyacheslav Maslov]

Hi, all!

I need multi threaded version of SimpleXMLRPCServer. Does python library 
already have implementation of this one? Or i need to implement multi 
threading by myself?

Which way is the simpliest?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Removing part of string

[saif . shakeel]

On May 14, 1:04 pm, [EMAIL PROTECTED] wrote:
> On May 13, 10:56 pm, [EMAIL PROTECTED] wrote:
>
>
>
>
>
> > Hi,
> > I am parsing an xml file ,and one part of structure looks
> > something like this:
>
> > -  > PhysicalLink="Infotainment_Control_Bus_CAN">
> >   Infotainment_Control_Bus_CAN_TIMEOUT_AX
> >   Timeout N_As/N_Ar
> >   Time from transmit request until a CAN frame transmit
> > confirmation is received.
> >   
>
> >   In my code i am extracting the data within
> > ,which is Timeout N_As/N_Ar.These tags repeat and will have
> > different timer names..like
>
> > -  > PhysicalLink="Infotainment_Control_Bus_CAN">
> >   Infotainment_Control_Bus_CAN_TIMEOUT_BS
> >   Timeout N_Bs
> >   Time that the transmitter of a multi-frame message
> > shall wait to receive a flow control (FC) frame before timing out with
> > a network layer error.
> >   
>
> >  I need to remove the words Timeout from the data,and
> > take only the abbrevation..i.e.N_As/N_bs like that .In short i have to
> > remove the words which come with name Time,and also the space which
> > comes next to it.
> > and take only the abbreviation.Can someone help me in this.
> >  Thanks
>
> Did you get elementtree working?- Hide quoted text -
>
> - Show quoted text -

Thanks for thr replies.It helped a lot.
Regarding the element tree problem,the module error is gone but a new
problem has appeared,which i have posted in new thread,

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

Element tree errors

[saif . shakeel]

HI,
   The following code is for replacing the strings localid with
"datapackageid" in an xml document.:

from xml.etree.ElementTree import ElementTree as et

file_input = raw_input("Enter The ODX File Path:")
(shortname,ext)=os.path.splitext(file_input)
test_file=shortname+"testxml.xml"

input_xml = open(file_input,'r')

tree = et.parse(input_xml)

for t in tree.getiterator("SERVICEPARAMETER"):
if t.get("Semantics") == "localId":
t.set("Semantics", "dataPackageID")

tree.write(test_file)

 The python ver is 2.5.there is no module error
now,but when i run i get this error:

Traceback (most recent call last):
  File "C:\Documents and Settings\pzchfr\Desktop\test.py", line 12, in

tree = et.parse(input_xml)
TypeError: unbound method parse() must be called with ElementTree
instance as first argument (got file instance instead)

  I am passing the input file from user to be parsed
which seems to be incorrect,Can someone help me.
  Thanks

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel  
<[EMAIL PROTECTED]> wrote:

> Eric Brunel wrote:
>> On Sun, 13 May 2007 21:10:46 +0200, Stefan Behnel
>> <[EMAIL PROTECTED]> wrote:
>> [snip]
>>> Now, I am not a strong supporter (most public code will use English
>>> identifiers anyway)
>>
>> How will you guarantee that? I'm quite convinced that most of the public
>> code today started its life as private code earlier...
>
> Ok, so we're back to my original example: the problem here is not the
> non-ASCII encoding but the non-english identifiers.

As I said in the rest of my post, I do recognize that there is a problem  
with non-english identifiers. I only think that allowing these identifiers  
to use a non-ASCII encoding will make things worse, and so should be  
avoided.

> If we move the problem to a pure unicode naming problem:
>
> How likely is it that it's *you* (lacking a native, say, kanji keyboard)  
> who
> ends up with code that uses identifiers written in kanji? And that you  
> are the
> only person who is now left to do the switch to an ASCII transliteration?
>
> Any chance there are still kanji-enabled programmes around that were not  
> hit
> by the bomb in this scenario? They might still be able to help you get  
> the
> code "public".

Contrarily to what one might think seeing the great achievements of  
open-source software, people willing to maintain public code and/or make  
it evolve seem to be quite rare. If you add burdens on such people - such  
as being able to read and write the language of the original code writer,  
or forcing them to request a translation or transliteration from someone  
else -, the chances are that they will become even rarer...
-- 
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

A Call for Professional Trainers of Python

[Jeff Rush]

I am seeking to organize the list of those, both individuals and companies,
who offer training on Python and related frameworks and technologies.

This is for those who provide this, typically to businesses, as part of their
professional offerings, in order to provide an answer to Forrester Research.
 They are surveying the various dynamic programming languages and want to
know, essentially, how easily can an IT manager get his people trained up on
Python in comparison to other languages.

There is a wiki page at:

  http://wiki.python.org/moin/PythonTraining

with some training organizations.  If your information is already there *and
current*, no response is necessary.  But if you are not mentioned, please
update that wiki page so we can get an accurate accounting and perhaps send
business your way.

Thanks,

Jeff Rush
Python Advocacy Coordinator
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Eric Brunel wrote:
> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel
>> Any chance there are still kanji-enabled programmes around that were
>> not hit
>> by the bomb in this scenario? They might still be able to help you get
>> the
>> code "public".
> 
> Contrarily to what one might think seeing the great achievements of
> open-source software, people willing to maintain public code and/or make
> it evolve seem to be quite rare. If you add burdens on such people -
> such as being able to read and write the language of the original code
> writer, or forcing them to request a translation or transliteration from
> someone else -, the chances are that they will become even rarer...

Ok, but then maybe that code just will not become Open Source. There's a
million reasons code cannot be made Open Source, licensing being one, lack of
resources being another, bad implementation and lack of documentation being
important also.

But that won't change by keeping Unicode characters out of source code.

Now that we're at it, badly named english identifiers chosen by non-english
native speakers, for example, are a sure way to keep people from understanding
the code and thus from being able to contribute resources.

I'm far from saying that all code should start using non-ASCII characters.
There are *very* good reasons why a lot of projects are well off with ASCII
and should obey the good advice of sticking to plain ASCII. But those are
mainly projects that are developed in English and use English documentation,
so there is not much of a risk to stumble into problems anyway.

I'm only saying that this shouldn't be a language restriction, as there
definitely *are* projects (I know some for my part) that can benefit from the
clarity of native language identifiers (just like English speaking projects
benefit from the English language). And yes, this includes spelling native
language identifiers in the native way to make them easy to read and fast to
grasp for those who maintain the code.

It should at least be an available option to use this feature.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Neil Hodgson]

Anton Vredegoor:

> Ouch! Now I seem to be disagreeing with the one who writes my editor. 
> What will become of me now?

It should be OK. I try to keep my anger under control and not cut 
off the pixel supply at the first stirrings of dissent.

It may be an idea to provide some more help for multilingual text 
such as allowing ranges of characters to be represented as hex escapes 
or character names automatically. Then someone who only normally uses 
ASCII can more easily audit patches that could contain non-ASCII characters.

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

Re: Element tree errors

[John Machin]

On May 14, 7:56 pm, [EMAIL PROTECTED] wrote:
> HI,
>The following code is for replacing the strings localid with
> "datapackageid" in an xml document.:
>
> from xml.etree.ElementTree import ElementTree as et

Note there are *two* occurrences of ElementTree in what you have
above. The first is the *module* with the parse function that that you
are looking for. The second is a *class*.

Try this:

import xml.etree.ElementTree as et
input_xml = open(file_input,'r')
tree = et.parse(input_xml)

or this:

from xml.etree.ElementTree import parse
input_xml = open(file_input,'r')
tree = parse(input_xml)




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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Nick Craig-Wood
wrote:

> My initial reaction is that it would be cool to use all those great
> symbols.  A variable called OHM etc!

This is a nice candidate for homoglyph confusion.  There's the Greek
letter omega (U+03A9) Ω and the SI unit symbol (U+2126) Ω, and I think
some omegas in the mathematical symbols area too.

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

Seeking Four Code Samples for Forrester Research Survey

[Jeff Rush]

In working up a response to the survey being conducted by Forrester Research
on dynamic languages, there is a section wherein they want to see code
samples.  The samples must include all code written for the example, and URLs
to any frameworks or modules used.

Their objective is to see how efficient/elegant the language is for
developers.  This is one area in which Python should excel.

1) Render a simple Web page containing text, data, and graphics, as
   specified in this wireframe mockup:

   http://dfwpython.org/uploads/Forrester/WireframeShot-1.jpg

   With the myriad number of web frameworks for Python, this is hard but
   let's pick those a few that are most expressive, as the person
   evaluating it may not be familiar with Python per se, but be looking
   for readability.

2) Invoke a simple Web service and format/display the results.

   This can be either web services or REST, whichever one looks cleanest.

3) Create a mash-up that overlays local temperature data onto a Google map.

4) Create a simple form for data submission with fields and drop down
   selects and a submit button, as specified in this wireframe mockup.
   At least one field should be validated.

   http://dfwpython.org/uploads/Forrester/WireframeShot-2.jpg

To help our community's standing in the survey, and perhaps promotion of your
favorite web framework, please consider picking one of these or providing a
trimmed down example of existing code.  Send it via private email to me, and
I'll get it included in the survey response.  Forrester's deadline to us is by
the end of this week, May 18th.

Thanks,

Jeff Rush
Python Advocacy Coordinator

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

Re: How to do basic CRUD apps with Python

[Bruno Desthuilliers]

walterbyrd a écrit :
> With PHP, libraries, apps, etc. to do basic CRUD are everywhere. Ajax
> and non-Ajax solutions abound.
> 
> With Python, finding such library, or apps. seems to be much more
> difficult to find.
> 
> I thought django might be a good way, but I can not seem to get an
> answer on that board.
> 
> I would like to put together a CRUD grid with editable/deletable/
> addable fields, click on the headers to sort. Something that would
> sort-of looks like an online  spreadsheet. It would be nice if the
> fields could be edited in-line, but it's not entirely necessary.
> 
> Are there any Python libraries to do that sort of thing? Can it be
> done with django or cherrypy?

You may want to have a look at turbogears's widgets.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marco Colombo]

I suggest we keep focused on the main issue here, which is "shoud non-
ascii identifiers be allowed, given that we already allow non-ascii
strings literals and comments?"

Most arguments against this proposal really fall into the category
"ascii-only source files". If you want to promote code-sharing, then
you should enfore quite restrictive policies:
- 7-bit only source files, so that everyone is able to correctly
display and _print_ them (somehow I feel that printing foreign glyphs
can be harder than displaying them) ;
- English-only, readable comments _and_ identifiers (if you think of
it, it's really the same issue, readability... I know no Coding Style
that requires good commenting but allows meaningless identifiers).

Now, why in the first place one should be allowed to violate those
policies? One reason is freedom. Let me write my code the way I like
it, and don't force me writing it the way you like it (unless it's
supposed to be part of _your_ project, then have me follow _your_
style).

Another reason is that readability is quite a relative term...
comments that won't make any sense in a real world program, may be
appropriate in a 'getting started with' guide example:

# this is another way to increment variable 'a'
a += 1

we know a comment like that is totally useless (and thus harmful) to
any programmer (makes me think "thanks, but i knew that already"), but
it's perfectly appropriate if you're introducing that += operator for
the first time to a newbie.

You could even say that most string literals are best made English-
only:

print "Ciao Mondo!"

it's better written:

print _("Hello World!")

or with any other mean to allow the i18n of the output. The Italian
version should be implemented with a .po file or whatever.

Yet, we support non-ascii encodings for source files. That's in order
to give authors more freedom. And freedom comes at a price, of course,
as non-ascii string literals, comments and identifiers are all harmful
to some extents and in some contexts.

What I fail to see is a context in which it makes sense to allow non-
ascii literals and non-ascii comments but _not_ non-ascii identifiers.
Or a context in which it makes sense to rule out non-ascii identifiers
but not string literals and comments. E.g. would you accept a patch
with comments you don't understand (or even that you are not able to
display correctly)? How can you make sure the patch is correct, if you
can't read and understand the string literals it adds?

My point being that most public open source projects already have
plenty of good reasons to enforce an English-only, ascii-only policy
on source files. I don't think that allowing non-ascii indentifiers at
language level would hinder thier ability to enforce such a policy
more than allowing non-ascii comments or literals did.

OTOH, I won't be able to contribute much to a project that already
uses, say, Chinese for comments and strings. Even if I manage to
display the source code correctly here, still I won't understand much
of it. So I'm not losing much by allowing them to use Chinese for
identifiers too.
And whether it was a mistake on their part not to choose an "English
only, ascii only" policy it's their call, not ours, IMHO.

.TM.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

Neil Hodgson <[EMAIL PROTECTED]> writes:

> Paul Rubin wrote:
>>> Plenty of programming languages already support unicode identifiers, 
>>
>> Could you name a few?  Thanks.
>
>C#, Java, Ecmascript, Visual Basic.

(i.e. everything that isn't a legacy or niche language)

scheme (major implementations such as PLT and the upcoming standard), the most
popular common lisp implementations, haskell[1], fortress[2], perl 6 and I 
should
imagine (but haven't checked) all new java or .NET based languages (F#,
IronPython, JavaFX, Groovy, etc.) as well -- the same goes for XML-based
languages.

(i.e. everything that's up and coming, too)

So as Neil said, I don't think keeping python ASCII and interoperable is an
option. I don't happen to think the anti-unicode arguments that have been
advanced so far terribly convincing so far[3], but even if they were it
wouldn't matter much -- the ability of functioning as a painless glue language
has always been absolutely vital for python.

cheers

'as

Footnotes: 
[1]  

[2]  

[3]  Although I do agree that mechanisms to avoid spoofing and similar
 problems (what normalization scheme and constraints unicode identifiers
 should be subjected to) merit careful discussion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __dict__ for instances?

[Bruno Desthuilliers]

Ivan Voras a écrit :
> Bruno Desthuilliers wrote:
> 
>>> "WARNING: "on_button_clicked" not callable or a tuple"
>> Please post the relevant code and the full traceback.
> 
> The code:
> 
> Class W:
>  def __init__(self):
>  self.xml = gtk.glade.XML("glade/mainwin.glade")
>  self.window = self.xml.get_widget("mainwin")
>  self.xml.signal_autoconnect(self)
> 
> w = W()
> gtk.main()
> 
> The error (not an exception, only the message appears and the handler
> doesn't work):
> 
> ** (finstall.py:7551): WARNING **: handler for 'on_button_next_clicked'
> not callable or a tuple

Is this the full message, or did you skip the preceding lines ?

> (the file has some 20 lines, not 7551)
> 
Is "finstall.py" the name of your file ? If yes, I'd suspect something 
wrong with your sys.path or like...





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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Laurent Pointal]

Martin v. Löwis a écrit :
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
> 
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
> 
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
> 
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?
> - would you use them if it was possible to do so? in what cases?

I strongly prefer to stay with current standard limited ascii for 
identifiers.

Ideally, it would be agreable to have variables like greek letters for 
some scientific vars, for french people using éèçà in names...

But... (I join common obections):

* where are-they on my keyboard, how can I type them ?
(i can see french éèçà, but us-layout keyboard dont know them, imagine 
kanji or greek)

* how do I spell this cyrilic/kanji char ?

* when there are very similar chars, how can I distinguish them?
(without dealing with same representation chars having different unicode 
names)

* is "amédé" variable and "amede" the same ?

* its an anti-KISS rule.

* not only I write code, I read it too, and having such variation 
possibility in names make code really more unreadable.
(unless I learn other scripting representation - maybe not a bad thing 
itself, but its not the objective here).

* I've read "Restricting the language to ASCII-only identifiers does
not enforce comments and documentation to be English, or the identifiers
actually to be English words, so an additional policy is necessary,
anyway."
But even with comments in german or spanish or japanese, I can guess to 
identify what a (well written) code is doing with its data. It would be 
very difficult with unicode spanning identifiers.


==> I wouldn't use them.


So, keep ascii only.
Basic ascii is the lower common denominator known and available 
everywhere, its known by all developers who can identify these chars 
correctly (maybe 1 vs I or O vs 0 can get into problems with uncorrect 
fonts).


Maybe, make default file-encoding to utf8 and strings to be unicode 
strings by default (with a s"" for basic strings by example), but this 
is another problem.


L.Pointal.

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

Re: Path python versions and Macosx

[andrea]

On 12 Mag, 01:09, [EMAIL PROTECTED] wrote:
> On May 11, 1:36 pm, andrea <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi everyone,
> > I use python on macosx with textmate as editor (great program).
>
> > I also use macport to install unix programs from the command line and
> > I find it great too.
> > Well I would like to have all my modules in the path when I'm using
> > textmate AND when I use the commandline (ipython), but because
> > textmate and the command line use different python versions they also
> > search in different places..
>
> > I found somewhere to write .pythonrc.py like this
>
> > #!/usr/bin/env python
> > import sys
> > PATH='/opt/local/lib/python2.4/site-packages/'
> > sys.path.append(PATH)
> > del sys
>
> > But it doesn't work either, I also tried to append this
> > PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:/opt/
> > local/lib/python2.4/site-packages:${PATH}
> > to .bash_profile but nothing.
>
> > Where should I set this variables??
>
> > Thanks a lot
>
> You can set environment variables for gui apps with this 
> freeware:http://www.versiontracker.com/dyn/moreinfo/macosx/15073
>
> You can edit some text files as well, but this thing just makes it
> much easier.
>
> ~Sean

Ok thanks, but why it doesn't work setting the .bash_profile?? What
should I set manually theorically?? The problem is also that I have
many modules for python 2.4 and trying to import them from the 2.5 of
course gives errors..
I installed them with macports (compiling), how can I make them switch
to 2.5???
thanks

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Marco Colombo wrote:
> I suggest we keep focused on the main issue here, which is "shoud non-
> ascii identifiers be allowed, given that we already allow non-ascii
> strings literals and comments?"
> 
> Most arguments against this proposal really fall into the category
> "ascii-only source files". If you want to promote code-sharing, then
> you should enfore quite restrictive policies:
> - 7-bit only source files, so that everyone is able to correctly
> display and _print_ them (somehow I feel that printing foreign glyphs
> can be harder than displaying them) ;
> - English-only, readable comments _and_ identifiers (if you think of
> it, it's really the same issue, readability... I know no Coding Style
> that requires good commenting but allows meaningless identifiers).
> 
> Now, why in the first place one should be allowed to violate those
> policies? One reason is freedom. Let me write my code the way I like
> it, and don't force me writing it the way you like it (unless it's
> supposed to be part of _your_ project, then have me follow _your_
> style).
> 
> Another reason is that readability is quite a relative term...
> comments that won't make any sense in a real world program, may be
> appropriate in a 'getting started with' guide example:
> 
> # this is another way to increment variable 'a'
> a += 1
> 
> we know a comment like that is totally useless (and thus harmful) to
> any programmer (makes me think "thanks, but i knew that already"), but
> it's perfectly appropriate if you're introducing that += operator for
> the first time to a newbie.
> 
> You could even say that most string literals are best made English-
> only:
> 
> print "Ciao Mondo!"
> 
> it's better written:
> 
> print _("Hello World!")
> 
> or with any other mean to allow the i18n of the output. The Italian
> version should be implemented with a .po file or whatever.
> 
> Yet, we support non-ascii encodings for source files. That's in order
> to give authors more freedom. And freedom comes at a price, of course,
> as non-ascii string literals, comments and identifiers are all harmful
> to some extents and in some contexts.
> 
> What I fail to see is a context in which it makes sense to allow non-
> ascii literals and non-ascii comments but _not_ non-ascii identifiers.
> Or a context in which it makes sense to rule out non-ascii identifiers
> but not string literals and comments. E.g. would you accept a patch
> with comments you don't understand (or even that you are not able to
> display correctly)? How can you make sure the patch is correct, if you
> can't read and understand the string literals it adds?
> 
> My point being that most public open source projects already have
> plenty of good reasons to enforce an English-only, ascii-only policy
> on source files. I don't think that allowing non-ascii indentifiers at
> language level would hinder thier ability to enforce such a policy
> more than allowing non-ascii comments or literals did.
> 
> OTOH, I won't be able to contribute much to a project that already
> uses, say, Chinese for comments and strings. Even if I manage to
> display the source code correctly here, still I won't understand much
> of it. So I'm not losing much by allowing them to use Chinese for
> identifiers too.
> And whether it was a mistake on their part not to choose an "English
> only, ascii only" policy it's their call, not ours, IMHO.

Very well written.

+1

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Duncan Booth]

Alexander Schmolck <[EMAIL PROTECTED]> wrote:

> scheme (major implementations such as PLT and the upcoming standard),
> the most popular common lisp implementations, haskell[1], fortress[2],
> perl 6 and I should imagine (but haven't checked) all new java or .NET
> based languages (F#, IronPython, JavaFX, Groovy, etc.) as well -- the
> same goes for XML-based languages.
> 

Just to confirm that: IronPython does accept non-ascii identifiers. From 
"Differences between IronPython and CPython":

> IronPython will compile files whose identifiers use non-ASCII
> characters if the file has an encoding comment such as "# -*- coding:
> utf-8 -*-".  CPython will not compile such a file in any case.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Duncan Booth wrote:
> Alexander Schmolck <[EMAIL PROTECTED]> wrote:
> 
>> scheme (major implementations such as PLT and the upcoming standard),
>> the most popular common lisp implementations, haskell[1], fortress[2],
>> perl 6 and I should imagine (but haven't checked) all new java or .NET
>> based languages (F#, IronPython, JavaFX, Groovy, etc.) as well -- the
>> same goes for XML-based languages.
>>
> 
> Just to confirm that: IronPython does accept non-ascii identifiers. From 
> "Differences between IronPython and CPython":
> 
>> IronPython will compile files whose identifiers use non-ASCII
>> characters if the file has an encoding comment such as "# -*- coding:
>> utf-8 -*-".  CPython will not compile such a file in any case.

Sounds like CPython would better follow IronPython here.

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

Re: GUI tutorial

[David Boddie]

On May 14, 2:57 am, BartlebyScrivener <[EMAIL PROTECTED]> wrote:
> On May 13, 12:51 pm, John K Masters <[EMAIL PROTECTED]>
> wrote:
>
> > Can someone point me in the direction of a good tutorial on programming
> > python with a GUI?
>
> Alan Gauld added a gui programming tutorial to his main course.
>
> http://www.freenetpages.co.uk/hp/alan.gauld/
>
> It's a frame page so I can't link directly, but select "GUI
> Programming" under Advanced Topics on the left.

It may be worth pointing out that the information about licensing on
that page
is a little vague and inaccurate in places. PyGTK is actually licensed
under
the GNU LGPL, not the GPL, and both PyQt and PyGTK can be used to
create
commercial applications as long as those applications are not closed
source.

David

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

Re: multi threaded SimpleXMLRPCServer

[Facundo Batista]

Vyacheslav Maslov wrote:

> I need multi threaded version of SimpleXMLRPCServer. Does python library 
> already have implementation of this one? Or i need to implement multi 
> threading by myself?

Don't know, but maybe this helps.

Here's a framework I implemented, where you have a job with multiple
parts. You have a server that you deploy in several machines, and a
client that feeds the jobs to the servers, actually getting distributed
processing.

  http://www.taniquetil.com.ar/plog/post/1/59

Regards,

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


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

Re: multi threaded SimpleXMLRPCServer

[Stefan Behnel]

Vyacheslav Maslov wrote:
> I need multi threaded version of SimpleXMLRPCServer. Does python library
> already have implementation of this one? Or i need to implement multi
> threading by myself?
> 
> Which way is the simpliest?

Twisted has XML-RPC support:

http://twistedmatrix.com/trac/

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

Re: GUI tutorial

[Jarek Zgoda]

BartlebyScrivener napisał(a):

>> Can someone point me in the direction of a good tutorial on programming
>> python with a GUI?
> 
> Alan Gauld added a gui programming tutorial to his main course.
> 
> http://www.freenetpages.co.uk/hp/alan.gauld/
> 
> It's a frame page so I can't link directly, but select "GUI
> Programming" under Advanced Topics on the left.

wxPython section of this tutorial seems bit outdated (the code resembles
what was required in time of wxPython 2.4). Anyway, the explanation of
event-driven approach is essential.

-- 
Jarek Zgoda

"We read Knuth so you don't have to."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI tutorial

[Jarek Zgoda]

John K Masters napisał(a):

> Can someone point me in the direction of a good tutorial on programming
> python with a GUI? I'm just starting out with python and have written a
> few scripts successfully but would like to add a graphical front end to
> them to make it easier for my work colleagues, most of whom have never
> used a command line, to use.

Each of GUI frameworks/libraries has its own tutorial and some even more
than one... The choice is directly related to what library you would use.

-- 
Jarek Zgoda

"We read Knuth so you don't have to."
-- 
http://mail.python.org/mailman/listinfo/python-list

Beginner question: module organisation

[Mail . To . Nathaniel]

Hello :)

I am new to python and I don't have much expirience in object-oriented
technologies neither.

The problem is the following: I have to create a simple python
template script that will always follow the same algorithm, let's say:
- read a mesh
- transform the mesh (let's say, refine)

The last step should be a kind of a black box:
- the same input data format
- some algorithme inside
- the same output data format

A number of different refine methods should be implemented. The end-
user must be able to write easily a new method and call it from the
base script without any major change.

Something like this would be a solution (no classes created, no OO
programming):
- a module defining REFINE1(mesh), REFINE2(mesh), ...
- in the script:
  from MODULE import REFINE2 as REFINE
  REFINE(mesh)

Is it a proper solution for this kind of problem? How would you
implement this kind of task?

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

Yet Another Software Challenge

[Thierry]

For those interested in programming riddles, I would like to
announce a new programming challenge I'm just launching at
http://software.challenge.googlepages.com

This challenge is in its early stage and thus set to be continuously
improved.

I would be especially interested in your comments and feedbacks about
this initiative and its relevance.

Enjoy!

Thierry

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Paul McGuire]

On May 14, 4:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>
> A variable called OHM etc!
> --
> Nick Craig-Wood <[EMAIL PROTECTED]> --http://www.craig-wood.com/nick

Then can 'lambda' -> 'λ' be far behind?  (I know this is a keyword
issue, not covered by this PEP, but I also sense that the 'lambda'
keyword has always been ranklesome.)

In my own personal English-only experience, I've thought that it would
be helpful to the adoption of pyparsing if I could distribute class
name translations, since so much of my design goal of pyparsing is
that it be somewhat readable as in:

integer = Word(nums)

is 'an integer is a word composed of numeric digits'.

By distributing a translation file, such as:

Palabra = Word
Grupo = Group
etc.

a Spanish-speaker could write their own parser using:

numero = Palabra(nums)

and this would still pass the "fairly easy-to-read" test, for that
user.  While my examples don't use any non-ASCII characters, I'm sure
the issue would come up fairly quickly.

As to the responder who suggested not mixing ASCII/Latin with, say,
Hebrew in any given identifier, this is not always possible.  On a
business trip to Israel, I learned that there are many terms that do
not have Hebrew correspondents, and so Hebrew technical literature is
sprinkled with English terms in Latin characters.  This is especially
interesting to watch being typed on a terminal, as the Hebrew
characters are written on the screen right-to-left, and then an
English word is typed by switching the editor to left-to-right mode.
The cursor remains in the same position and the typed Latin characters
push out to the left as they are typed.  Then typing in right-to-left
mode is resumed, just to the left of the Latin characters just
entered.

-- Paul

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

Re: Basic question

[Max M]

Dmitry Dzhus skrev:
>> Actually I'm trying to convert a string to a list of float numbers:
>> str = '53,20,4,2' to L = [53.0, 20.0, 4.0, 2.0]
> 
> str="53,20,4,2"
> map(lambda s: float(s), str.split(','))
> 
> Last expression returns: [53.0, 20.0, 4.0, 2.0]

The lambda is not needed there, as float is a callable.

map(float, str.split(','))

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yet Another Software Challenge

[Paul McGuire]

On May 14, 8:14 am, Thierry <[EMAIL PROTECTED]> wrote:
> For those interested in programming riddles, I would like to
> announce a new programming challenge I'm just launching 
> athttp://software.challenge.googlepages.com
>
> This challenge is in its early stage and thus set to be continuously
> improved.
>
> I would be especially interested in your comments and feedbacks about
> this initiative and its relevance.
>
> Enjoy!
>
> Thierry

A small typo in your instructions: ".hml" should be ".html".

-- Paul

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

Re: Yet Another Software Challenge

[Paul McGuire]

On May 14, 8:14 am, Thierry <[EMAIL PROTECTED]> wrote:
> For those interested in programming riddles, I would like to
> announce a new programming challenge I'm just launching 
> athttp://software.challenge.googlepages.com
>
> This challenge is in its early stage and thus set to be continuously
> improved.
>
> I would be especially interested in your comments and feedbacks about
> this initiative and its relevance.
>
> Enjoy!
>
> Thierry

More feedback:

In Riddle 2, the "global" declarations are unnecessary, as you are
only referencing the globally-defined vars for read.

Also in Riddle 2, I would replace
for s in alphabet: indices[s] = alphabet.index(s)
with
indices = dict( (s,i) for i,s in enumerate(alphabet) )

(I see part of your Python Challenge as giving new Pythoners something
to cut their teeth on, and so this is an opportunity for giving
examples of good style.)

I do enjoy these challenges, they are quite addicting. :)

-- Paul

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Duncan Booth]

Stefan Behnel <[EMAIL PROTECTED]> wrote:

>> Just to confirm that: IronPython does accept non-ascii identifiers.
>> From "Differences between IronPython and CPython":
>> 
>>> IronPython will compile files whose identifiers use non-ASCII
>>> characters if the file has an encoding comment such as "# -*-
>>> coding: utf-8 -*-".  CPython will not compile such a file in any
>>> case. 
> 
> Sounds like CPython would better follow IronPython here.

I cannot find any documentation which says exactly which non-ASCII 
characters IronPython will accept. 
I would guess that it probably follows C# in general, but it doesn't 
follow C# identifier syntax exactly (in particular the leading @ to 
quote keywords is not supported).

The C# identifier syntax from 
http://msdn2.microsoft.com/en-us/library/aa664670(VS.71).aspx 
I think it differs from the PEP only in also allowing the Cf class of 
characters:

identifier:
available-identifier
@   identifier-or-keyword
available-identifier:
An identifier-or-keyword that is not a keyword
identifier-or-keyword:
identifier-start-character   identifier-part-charactersopt
identifier-start-character:
letter-character
_ (the underscore character U+005F) 
identifier-part-characters:
identifier-part-character
identifier-part-characters   identifier-part-character
identifier-part-character:
letter-character
decimal-digit-character
connecting-character
combining-character
formatting-character
letter-character:
A Unicode character of classes Lu, Ll, Lt, Lm, Lo, or Nl
A unicode-escape-sequence representing a character of classes Lu, Ll, Lt, 
Lm, Lo, or Nl
combining-character:
A Unicode character of classes Mn or Mc
A unicode-escape-sequence representing a character of classes Mn or Mc
decimal-digit-character:
A Unicode character of the class Nd
A unicode-escape-sequence representing a character of the class Nd
connecting-character:
A Unicode character of the class Pc
A unicode-escape-sequence representing a character of the class Pc
formatting-character:
A Unicode character of the class Cf
A unicode-escape-sequence representing a character of the class Cf

For information on the Unicode character classes mentioned above, see 
The Unicode Standard, Version 3.0, section 4.5.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multi threaded SimpleXMLRPCServer

[c james]

I use a variation of the following.  Clean and straight forward.

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


Vyacheslav Maslov wrote:
> Hi, all!
> 
> I need multi threaded version of SimpleXMLRPCServer. Does python library 
> already have implementation of this one? Or i need to implement multi 
> threading by myself?
> 
> Which way is the simpliest?

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

Re: Time

[HMS Surprise]

Thanks for posting. I sure am sorry that I wasted your time. I should
have started the post stating I am using jython 2.2.3 and apparently
it has no datetime module. But I will keep datetime in mind for future
reference.

Since I had no datetime I cobbled out the following. Seems to work
thus far. Posted here for the general amusement of the list.

Regards,

jvh



from time import *
s = '05/11/2007 1:23 PM'
t = s.split()
mdy = t[0].split('/')

hrMn = t[1].split(':')
if t[2] == 'PM':
hrMn[0] = int(hrMn[0]) + 12

tuple =(int(mdy[2]), int(mdy[0]), int(mdy[1]), hrMn[0], int(hrMn[1]),
0,0,0,0)
print tuple

eTime = mktime(tuple)
print 'eTime', eTime

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

Re: Time

[kyosohma]

On May 14, 9:00 am, HMS Surprise <[EMAIL PROTECTED]> wrote:
> Thanks for posting. I sure am sorry that I wasted your time. I should
> have started the post stating I am using jython 2.2.3 and apparently
> it has no datetime module. But I will keep datetime in mind for future
> reference.
>
> Since I had no datetime I cobbled out the following. Seems to work
> thus far. Posted here for the general amusement of the list.
>
> Regards,
>
> jvh
>
> 
>
> from time import *
> s = '05/11/2007 1:23 PM'
> t = s.split()
> mdy = t[0].split('/')
>
> hrMn = t[1].split(':')
> if t[2] == 'PM':
> hrMn[0] = int(hrMn[0]) + 12
>
> tuple =(int(mdy[2]), int(mdy[0]), int(mdy[1]), hrMn[0], int(hrMn[1]),
> 0,0,0,0)
> print tuple
>
> eTime = mktime(tuple)
> print 'eTime', eTime

Since jython works with Java, why not use Java's time/datetime
modules? Various links abound. Here are a few:

http://www.raditha.com/blog/archives/000552.html
http://www.xmission.com/~goodhill/dates/deltaDates.html
http://www.velocityreviews.com/forums/t149657-find-difference-in-datetime-variables.html

Maybe those will give you some hints.

Mike

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

Re: Time

[HMS Surprise]

> if t[2] == 'PM':
> hrMn[0] = int(hrMn[0]) + 12
>


Oops, should be:
hrMn[0] = int(hrMn[0]
if t[2] == 'PM':
hrMn[0] += 12


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

Re: Time

[HMS Surprise]

On May 14, 9:09 am, [EMAIL PROTECTED] wrote:
> On May 14, 9:00 am, HMS Surprise <[EMAIL PROTECTED]> wrote:
>
>
>
> > Thanks for posting. I sure am sorry that I wasted your time. I should
> > have started the post stating I am using jython 2.2.3 and apparently
> > it has no datetime module. But I will keep datetime in mind for future
> > reference.
>
> > Since I had no datetime I cobbled out the following. Seems to work
> > thus far. Posted here for the general amusement of the list.
>
> > Regards,
>
> > jvh
>
> > 
>
> > from time import *
> > s = '05/11/2007 1:23 PM'
> > t = s.split()
> > mdy = t[0].split('/')
>
> > hrMn = t[1].split(':')
> > if t[2] == 'PM':
> > hrMn[0] = int(hrMn[0]) + 12
>
> > tuple =(int(mdy[2]), int(mdy[0]), int(mdy[1]), hrMn[0], int(hrMn[1]),
> > 0,0,0,0)
> > print tuple
>
> > eTime = mktime(tuple)
> > print 'eTime', eTime
>
> Since jython works with Java, why not use Java's time/datetime
> modules? Various links abound. Here are a few:
>
> http://www.raditha.com/blog/archives/000552.htmlhttp://www.xmission.com/~goodhill/dates/deltaDates.htmlhttp://www.velocityreviews.com/forums/t149657-find-difference-in-date...
>
> Maybe those will give you some hints.
>
> Mike

Excellent idea.

Thanks Mike.


jvh

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

Re: Time

[HMS Surprise]

On May 14, 9:22 am, HMS Surprise <[EMAIL PROTECTED]> wrote:
> > if t[2] == 'PM':
> > hrMn[0] = int(hrMn[0]) + 12
>
> Oops, should be:
> hrMn[0] = int(hrMn[0]
> if t[2] == 'PM':
> hrMn[0] += 12

Oops +=1, should be:
 hrMn[0] = int(hrMn[0]
 if t[2] == 'PM':
 hrMn[0] += 12

Need more starter fluid, coffee please!!!

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

deployment scripts

[Erin]

Does anyone have experience developing deployment scripts with Jython?

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[gatti]

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


> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").

I am strongly against this PEP. The serious problems and huge costs
already explained by others are not balanced by the possibility of
using non-butchered identifiers in non-ASCII alphabets, especially
considering that one can write any language, in its full Unicode
glory, in the strings and comments of suitably encoded source files.
The diatribe about cross language understanding of Python code is IMHO
off topic; if one doesn't care about international readers, using
annoying alphabets for identifiers has only a marginal impact. It's
the same situation of IRIs (a bad idea) with HTML text (happily
Unicode).

> - should non-ASCII identifiers be supported? why?
No, they are useless.
> - would you use them if it was possible to do so? in what cases?
No, never.
Being Italian, I'm sometimes tempted to use accented vowels in my
code, but I restrain myself because of the possibility of annoying
foreign readers and the difficulty of convincing every text editor I
use to preserve them

> Python code is written by many people in the world who are not familiar
> with the English language, or even well-acquainted with the Latin
> writing system.  Such developers often desire to define classes and
> functions with names in their native languages, rather than having to
> come up with an (often incorrect) English translation of the concept
> they want to name.

The described set of users includes linguistically intolerant people
who don't accept the use of suitable languages instead of their own,
and of compromised but readable spelling instead of the one they
prefer.
Most "people in the world who are not familiar with the English
language" are much more mature than that, even when they don't write
for international readers.

> The syntax of identifiers in Python will be based on the Unicode
> standard annex UAX-31 [1]_, with elaboration and changes as defined
> below.

Not providing an explicit listing of allowed characters is inexcusable
sloppiness.
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.

> ``ID_Start`` is defined as all characters having one of the general
> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
> letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers
> (Nl), plus the underscore (XXX what are "stability extensions" listed in
> UAX 31).
>
> ``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? Many of
these would be utterly invisible ("variation selectors" are Mn) or
displayed out of sequence (overlays are Mn),  or normalized away
(combining accents are Mn) or absurdly strange and ambiguous (roman
numerals are Nl, for instance).

Lorenzo Gatti


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Eric Brunel wrote:
>> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel
>>> Any chance there are still kanji-enabled programmes around that were
>>> not hit
>>> by the bomb in this scenario? They might still be able to help you get
>>> the
>>> code "public".
>> Contrarily to what one might think seeing the great achievements of
>> open-source software, people willing to maintain public code and/or make
>> it evolve seem to be quite rare. If you add burdens on such people -
>> such as being able to read and write the language of the original code
>> writer, or forcing them to request a translation or transliteration from
>> someone else -, the chances are that they will become even rarer...
> 
> Ok, but then maybe that code just will not become Open Source. There's a
> million reasons code cannot be made Open Source, licensing being one, lack of
> resources being another, bad implementation and lack of documentation being
> important also.
> 
> But that won't change by keeping Unicode characters out of source code.

Nope, but adding unicode glyphs support for identifiers will only make 
things worse, and we (free software authors/users/supporters) 
definitively *don't* need this.

> Now that we're at it, badly named english identifiers chosen by non-english
> native speakers, for example, are a sure way to keep people from understanding
> the code and thus from being able to contribute resources.

Broken English is certainly better than German or French or Italian when 
it comes to sharing code.

> I'm far from saying that all code should start using non-ASCII characters.
> There are *very* good reasons why a lot of projects are well off with ASCII
> and should obey the good advice of sticking to plain ASCII. But those are
> mainly projects that are developed in English and use English documentation,
> so there is not much of a risk to stumble into problems anyway.
> 
> I'm only saying that this shouldn't be a language restriction, as there
> definitely *are* projects (I know some for my part) that can benefit from the
> clarity of native language identifiers (just like English speaking projects
> benefit from the English language).

As far as I'm concerned, I find "frenglish" source code (code with 
identifiers in French) a total abomination. The fact is that all the 
language (keywords, builtins, stdlib) *is* in English. Unless you 
address that fact, your PEP is worthless (and even if you really plan to 
do something about this, I still find it a very bad idea for reasons 
already exposed).

The fact is also that anyone at least half-serious wrt/ CS will learn 
technical English anyway. And, as other already pointed, learning 
technical English is certainly not the most difficult part when it comes 
to programming.

> And yes, this includes spelling native
> language identifiers in the native way to make them easy to read and fast to
> grasp for those who maintain the code.

Yes, fine. So we end up with a code that's a mix of English (keywords, 
builtins, stdlib, almost if not all third-part libs) and native 
language. So, while native speakers will still have to deal with 
English, non-native speakers won't be able to understand anything. Talk 
about a great idea...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A newbie question about FileDialog in wxPython

[kyosohma]

On May 11, 1:24 pm, "OhKyu Yoon" <[EMAIL PROTECTED]> wrote:
> Hi!
> I am opening files using the wx.FileDialog in wxPython.
> I want to modify the FileDialog such that some information about a
> highlighted file is displayed before I decide to open the file.
> This is what I tried:
>
> class ModifiedFileDialog(wx.FileDialog):
> def __init__(self,parent,message,wildcard,style):
> wx.FileDialog(self,parent,message,"","",wildcard,style)
> width,height = self.GetSizeTuple()
> self.SetSizeWH(width,height+100)
> # and so on...
>
> I get an error when I try to change the size or make other changes.
> Could someone tell me how to make this work or direct me to some reference?
> Thank you.

I don't know the answer either, but the people on the wxPython user's
group probably will: http://www.wxpython.org/maillist.php

Please post the question there too.

Mike

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Bruno Desthuilliers wrote:
>> but CS is english-speaking, period.
> 
> That's a wrong assumption. 

I've never met anyone *serious* about programming and yet unable to read 
and write CS-oriented technical English.

> I understand that people can have this impression
> when they deal a lot with Open Source code, but I've seen a lot of places
> where code was produced that was not written to become publicly available (and
> believe me, it *never* will become Open Source).

Yeah, fine. This doesn't mean that all and every people that may have to 
work on this code is a native speaker of the language used - or even 
fluent enough with it.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Mon, 14 May 2007 12:17:36 +0200, Stefan Behnel  
<[EMAIL PROTECTED]> wrote:
> Eric Brunel wrote:
>> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel
>>> Any chance there are still kanji-enabled programmes around that were
>>> not hit
>>> by the bomb in this scenario? They might still be able to help you get
>>> the
>>> code "public".
>>
>> Contrarily to what one might think seeing the great achievements of
>> open-source software, people willing to maintain public code and/or make
>> it evolve seem to be quite rare. If you add burdens on such people -
>> such as being able to read and write the language of the original code
>> writer, or forcing them to request a translation or transliteration from
>> someone else -, the chances are that they will become even rarer...
>
> Ok, but then maybe that code just will not become Open Source. There's a
> million reasons code cannot be made Open Source, licensing being one,  
> lack of
> resources being another, bad implementation and lack of documentation  
> being
> important also.
>
> But that won't change by keeping Unicode characters out of source code.

Maybe; maybe not. This is one more reason for a code preventing it from  
becoming open-source. IMHO, there are already plenty of these reasons, and  
I don't think we need a new one...

> Now that we're at it, badly named english identifiers chosen by  
> non-english
> native speakers, for example, are a sure way to keep people from  
> understanding
> the code and thus from being able to contribute resources.

I wish we could have an option forbidding these also ;-) But now, maybe  
some of my own code would no more execute when it's turned on...

> I'm far from saying that all code should start using non-ASCII  
> characters.
> There are *very* good reasons why a lot of projects are well off with  
> ASCII
> and should obey the good advice of sticking to plain ASCII. But those are
> mainly projects that are developed in English and use English  
> documentation,
> so there is not much of a risk to stumble into problems anyway.
>
> I'm only saying that this shouldn't be a language restriction, as there
> definitely *are* projects (I know some for my part) that can benefit  
> from the
> clarity of native language identifiers (just like English speaking  
> projects
> benefit from the English language). And yes, this includes spelling  
> native
> language identifiers in the native way to make them easy to read and  
> fast to
> grasp for those who maintain the code.

My point is only that I don't think you can tell right from the start that  
a project you're working on will stay private forever. See Java for  
instance: Sun said for quite a long time that it wasn't a good idea to  
release Java as open-source and that it was highly unlikely to happen. But  
it finally did...

You could tell that the rule should be that if the project has the  
slightest chance of becoming open-source, or shared with people not  
speaking the same language as the original coders, one should not use  
non-ASCII identifiers. I'm personnally convinced that *any* industrial  
project falls into this category. So accepting non-ASCII identifiers is  
just introducing a disaster waiting to happen.

But now, I have the same feeling about non-ASCII strings, and I - as a  
project leader - won't ever accept a source file which has a "_*_ coding  
_*_" line specifying anything else than ascii... So even if I usually  
don't buy the "we're already half-dirty, so why can't we be the dirtiest  
possible" argument, I'd understand if this feature went into the language.  
But I personnally won't ever use it, and forbid it from others whenever  
I'll be able to.

> It should at least be an available option to use this feature.

If it's actually an option to the interpreter, I guess I'll just have to  
alias python to 'python --ascii-only-please'...
-- 
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: Recursion limit problems

[elventear]

On May 11, 11:54 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> Without seeing the full code and the exception traceback, my guess is that
> your __hash__ somehow calls itself due to a refence loop in your object.  A
> simple example of a loop:
> a = []; a.append(a)
> Now, list objects are not hashable, but if they were, and the hash were
> value based (like your), then hash(a) would call hash(a) would call
> hash(a)

You were right, I had forgotten that in some instances I had some data
that recursively pointed to the source. Thanks!

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

Re: Recursion limit problems

[elventear]

On May 12, 12:25 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 11 May 2007 19:17:57 -0300, elventear <[EMAIL PROTECTED]>  
> escribió:
> "The only required property is that objects which compare equal have the  
> same hash value; it is advised to somehow mix together (e.g., using  
> exclusive or) the hash values for the components of the object that also  
> play a part in comparison of objects. If a class does not define a  
> __cmp__() method it should not define a __hash__() operation either; if it  
> defines __cmp__() or __eq__() but not __hash__(), its instances will not  
> be usable as dictionary keys. If a class defines mutable objects and  
> implements a __cmp__() or __eq__() method, it should not implement  
> __hash__(), since the dictionary implementation requires that a key's hash  
> value is immutable (if the object's hash value changes, it will be in the  
> wrong hash bucket)."

Thanks for the information. I have a doubt regarding the wording in
the paragraph on top.

Since I am defining a hash for my object, it makes sense that I should
be able to define equality. But I am not sure about inequality, in my
specific case. The paragraph above mentions that __cmp__ should be
defined if I define a __hash__, but in the default behaviour of
__cmp__ inequality is included. So what should I do? Also why is
equality necessary to be defined? Do dicts only use __hash__ or do
they use equality as well?

Thanks!

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Michel Claveau]

Hi !

> - should non-ASCII identifiers be supported? why?
> - would you use them if it was possible to do so? in what cases?

Yes.
And, more: yes yes yes

Because:

1) when I connect Python to j(ava)Script, if the pages "connected" 
contains objects with non-ascii characters, I can't use it ; snif...

2) when I connect Python to databases, if there are fields (columns) 
with emphatic letters, I can't use class properties for drive these 
fields.  Exemples:
 "cité" (french translate of "city")
 "téléphone"  (for phone)



And, because non-ASCII characters are possible, they are no-obligatory 
; consequently guys (snobs?) want stay in pure-ASCII dimension will 
can.

* sorry for my bad english *





-- 
@-salutations

Michel Claveau


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anders J. Munch]

Eric Brunel wrote:
> You could tell that the rule should be that if the project has the 
> slightest chance of becoming open-source, or shared with people not 
> speaking the same language as the original coders, one should not use 
> non-ASCII identifiers. I'm personnally convinced that *any* industrial 
> project falls into this category. So accepting non-ASCII identifiers is 
> just introducing a disaster waiting to happen.

Not at all.  If the need arises, you just translate the whole thing.  Contrary 
to popular belief, this is a quick and easy thing to do.

So YAGNI applies, and even if you find that you do need it, you may still have 
won on the balance! As the time saved by using your native language just might 
outweigh the time spent translating.

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

Sorting troubles

[seyensubs]

I have the following implementations of quicksort and insertion sort:

def qSort(List):
if List == []: return []
return qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
   qSort([x for x in List[1:] if x>=List[0]])

def insertSort(List):
for i in range(1,len(List)):
value=List[i]
j=i
while List[j-1]>value and j>0:
List[j]=List[j-1]
j-=1
List[j]=value

Now, the quickSort does not modify the original list, mostly because
it works on products and concatenations, rather than alterations.
The insertion sort, however, does modify the list. Now, to give
results, they should be called in such a way( A is an unsorted list)
A=qSort(A)
# the insertion sort does not require this,
insertSort(A)

I would like to know how can I modify the qSort function such that it
affects the list directly inside
I have tried doing it like this

def qSort(List):
if List == []: return []
List = qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
   qSort([x for x in List[1:] if x>=List[0]])
return List

while processing, the list changes, but those changes remain inside
the function, so that once it's over, if nothis catches the return,
the original List remains unchanged.

If not a solution, I would like to at least know why it does what it
does. I so understand that List(above) is only a reference to the
actual data(a list), but I'm not passing a copy of the data to the
function, but the actual reference(hence, insertSort does
modifications). But then how can I change, inside the function, the
object List is referencing to? If I can't modify the original list,
maybe I can make the variable List point to another list? But changes
inside the function are local. Sorry if this is a bit confusing.

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

Re: Beginner question: module organisation

[Nick Vatamaniuc]

On May 14, 9:09 am, [EMAIL PROTECTED] wrote:
> Hello :)
>
> I am new to python and I don't have much expirience in object-oriented
> technologies neither.
>
> The problem is the following: I have to create a simple python
> template script that will always follow the same algorithm, let's say:
> - read a mesh
> - transform the mesh (let's say, refine)
>
> The last step should be a kind of a black box:
> - the same input data format
> - some algorithme inside
> - the same output data format
>
> A number of different refine methods should be implemented. The end-
> user must be able to write easily a new method and call it from the
> base script without any major change.
>
> Something like this would be a solution (no classes created, no OO
> programming):
> - a module defining REFINE1(mesh), REFINE2(mesh), ...
> - in the script:
>   from MODULE import REFINE2 as REFINE
>   REFINE(mesh)
>
> Is it a proper solution for this kind of problem? How would you
> implement this kind of task?

Why not OO? This is a good problem for OO. For example: there is a
base class (BaseMesh)  that will take care of loading your
mesh,provide a generic (possibly empty)  refine() method,  output the
mesh and have a bunch of utility functions. You can put that in a
module like meshing.py.

Then the user will do:

from meshing import BaseMesh
class UsersMesh(BaseMesh):
def __init__(self,...):
 BaseMesh.__init__(self,...)
 etc. initializer...
def refine(self,...):
  ...user's refine method would go here...
--

So for each different refine() method the user can derive a new class
from BaseMesh and overload the refine(...) method.

Hope that helps,
-Nick Vatamaniuc


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anders J. Munch]

Hendrik van Rooyen wrote:
> And we have been through the Macro thingy here, and the consensus
> seemed to be that we don't want people to write their own dialects.

Macros create dialects that are understood only by the three people in your 
project group.  It's unreasonable to compare that to a "dialect" such as 
Mandarin, which is exclusive to a tiny little clique of one billion people.

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

Re: which is more pythonic/faster append or +=[]

[7stud]

On May 10, 2:39 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> 7studwrote:
> >> Is there any documentation for the syntax you used with timeit?
>
> > This is the syntax the docs describe:
> [snip
> > python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
> [snip]
> > Then in the examples in section 10.10.2
> [snip]
> > timeit.py 'try:' '  str.__nonzero__' 'except AttributeError:' '  pass'
> [snip]
> > and then there is Alex Martelli's syntax:
> [snip]
> > python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
>
> The following three things are equivalent:
>  python /path/to/.py
>  /path/to/.py # assuming the OS knows how to exec it
>  python -m# assuming  is on sys.path
>
> So that just leaves the differences between:
>  [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
>  'try:' '  str.__nonzero__' 'except AttributeError:' '  pass'
>  'L=range(3); n=23' 'x=L[:]; x.append(n)'
>
> Those look pretty similar to me (aside from the fact that they're
> testing different things). Each argument in single quotes is a line of
> the code you want timed.
>

Thanks.

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

Re: Asyncore Help?

[Bjoern Schliessmann]

Nick Craig-Wood wrote:

>   http://twistedmatrix.com/trac/
> 
> The learning curve of twisted is rather brutal, 

NACK, the tutorial is -- IMHO -- rather easy if you are used to
writing Python code and doing asynchronous programming. 



> but it will do everything you want and a whole lot more!

That's true. More Twisted, less work (and less headache). IMHO.

Regards,


Björn

-- 
BOFH excuse #242:

Software uses US measurements, but the OS is in metric...

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[rurpy]

On May 14, 9:53 am, Michel Claveau
<[EMAIL PROTECTED]> wrote:
> > - should non-ASCII identifiers be supported? why?
> > - would you use them if it was possible to do so? in what cases?
>
> Yes.
> And, more: yes yes yes
>
> Because:
>
> 1) when I connect Python to j(ava)Script, if the pages "connected"
> contains objects with non-ascii characters, I can't use it ; snif...
>
> 2) when I connect Python to databases, if there are fields (columns)
> with emphatic letters, I can't use class properties for drive these
> fields.  Exemples:
>  "cité" (french translate of "city")
>  "téléphone"  (for phone)
>
> And, because non-ASCII characters are possible, they are no-obligatory
> ; consequently guys (snobs?) want stay in pure-ASCII dimension will
> can.
>
> * sorry for my bad english *

Can a discussion about support for non-english identifiers (1)
conducted in a group where 99.9% of the posters are fluent
speakers of english (2), have any chance of being objective
or fair?

Although probably not-sufficient to overcome this built-in
bias, it would be interesting if some bi-lingual readers would
raise this issue in some non-english Python discussion
groups to see if the opposition to this idea is as strong
there as it is here.

(1) No quibbles about the distintion between non-english
and non-ascii please.
(2) Several posters have claimed non-native english speaker
status to bolster their position, but since they are clearly at
or near native-speaker levels of fluency, that english is not
their native language is really irrelevant.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Jarek Zgoda schrieb:
> Stefan Behnel napisał(a):
> 
>>> While I can read the code with Hebrew, Russian or Greek names
>>> transliterated to ASCII, I would not be able to read such code in native.
>> Then maybe it was code that was not meant to be read by you?
> 
> OK, then. As a code obfuscation measure this would fit perfectly.

I actually meant it as a measure for clarity and readability for those who are
actually meant to *read* the code.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Jakub Stolarski]

On May 13, 5:44 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> - should non-ASCII identifiers be supported? why?
No. It's good convention to stick with english. And if we stick with
english, why we should need non-ASCII characters? Any non-ASCII
character makes code less readable. We never know if our code became
public.

> - would you use them if it was possible to do so? in what cases?
No. I don't see any uses. I'm Polish. Polish-english mix looks funny.

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

Re: Sorting troubles

[Thomas Nelson]

On May 14, 11:05 am, [EMAIL PROTECTED] wrote:
> I have the following implementations of quicksort and insertion sort:
>
> def qSort(List):
> if List == []: return []
> return qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
>qSort([x for x in List[1:] if x>=List[0]])
>
> def insertSort(List):
> for i in range(1,len(List)):
> value=List[i]
> j=i
> while List[j-1]>value and j>0:
> List[j]=List[j-1]
> j-=1
> List[j]=value
>
> Now, the quickSort does not modify the original list, mostly because
> it works on products and concatenations, rather than alterations.
> The insertion sort, however, does modify the list. Now, to give
> results, they should be called in such a way( A is an unsorted list)
> A=qSort(A)
> # the insertion sort does not require this,
> insertSort(A)
>
> I would like to know how can I modify the qSort function such that it
> affects the list directly inside
> I have tried doing it like this
>
> def qSort(List):
> if List == []: return []
> List = qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
>qSort([x for x in List[1:] if x>=List[0]])
> return List
>
> while processing, the list changes, but those changes remain inside
> the function, so that once it's over, if nothis catches the return,
> the original List remains unchanged.
>
> If not a solution, I would like to at least know why it does what it
> does. I so understand that List(above) is only a reference to the
> actual data(a list), but I'm not passing a copy of the data to the
> function, but the actual reference(hence, insertSort does
> modifications). But then how can I change, inside the function, the
> object List is referencing to? If I can't modify the original list,
> maybe I can make the variable List point to another list? But changes
> inside the function are local. Sorry if this is a bit confusing.

The thing is that [x for x in List[1:]...] is a brand new list created
by iterating over the old one.
How about:
qSortHelp(List):
newlist = qSort(List)
for i, val in enumerate(newlist):
List[i] = val
You have to iterate over one more time, but this sorts the list in
place.
HTH,
Tom

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

PEP 3131: Ascii-English is like coca-cola!

[Pierre Hanser]

This pep is not technical, or at least not only. It has
larger implications about society model we want.

Let me explain with an analogy:
let's compare 'ascii english' to coca-cola.

It's available nearly everywhere.

It does not taste good at first try, and is especially
repulsive to young children.

It's cheap and you don't expect much of it.

You know you can drink some in case of real need.

It's imperialist connotation is widely accepted(?)

But it's not good as your favorite beverage, beer, wine, ...

The world is full of other possibilities. Think, in case
of necessity you could even have to drink tea with yack
butter in himalaya! in normal circonstances, you should
never see any, but in extreme situation you may have to!

Were is freedom in such a world you could only drink coca?

I DON'T WANT TO HAVE TO DRINK COCA AT HOME ALL THE TIME.

and this pep is a glorious occasion to get free from it.


[disclaimer: coca is used here as the generic name it became,
and no real offense is intended]

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anton Vredegoor]

Neil Hodgson wrote:
> Anton Vredegoor:
> 
>> Ouch! Now I seem to be disagreeing with the one who writes my editor. 
>> What will become of me now?
> 
> It should be OK. I try to keep my anger under control and not cut 
> off the pixel supply at the first stirrings of dissent.

Thanks! I guess I won't have to make the obligatory Sovjet Russia joke 
now :-)

> It may be an idea to provide some more help for multilingual text 
> such as allowing ranges of characters to be represented as hex escapes 
> or character names automatically. Then someone who only normally uses 
> ASCII can more easily audit patches that could contain non-ASCII characters.

Now that I read about IronPython already supporting some larger 
character set I feel like I'm somewhat caught in a side effect of an 
embrace and extend scheme.

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

Re: Sorting troubles

[Nick Vatamaniuc]

On May 14, 12:05 pm, [EMAIL PROTECTED] wrote:
> I have the following implementations of quicksort and insertion sort:
>
> def qSort(List):
> if List == []: return []
> return qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
>qSort([x for x in List[1:] if x>=List[0]])
>
> def insertSort(List):
> for i in range(1,len(List)):
> value=List[i]
> j=i
> while List[j-1]>value and j>0:
> List[j]=List[j-1]
> j-=1
> List[j]=value
>
> Now, the quickSort does not modify the original list, mostly because
> it works on products and concatenations, rather than alterations.
> The insertion sort, however, does modify the list. Now, to give
> results, they should be called in such a way( A is an unsorted list)
> A=qSort(A)
> # the insertion sort does not require this,
> insertSort(A)
>
> I would like to know how can I modify the qSort function such that it
> affects the list directly inside
> I have tried doing it like this
>
> def qSort(List):
> if List == []: return []
> List = qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
>qSort([x for x in List[1:] if x>=List[0]])
> return List
>
> while processing, the list changes, but those changes remain inside
> the function, so that once it's over, if nothis catches the return,
> the original List remains unchanged.
>
> If not a solution, I would like to at least know why it does what it
> does. I so understand that List(above) is only a reference to the
> actual data(a list), but I'm not passing a copy of the data to the
> function, but the actual reference(hence, insertSort does
> modifications). But then how can I change, inside the function, the
> object List is referencing to? If I can't modify the original list,
> maybe I can make the variable List point to another list? But changes
> inside the function are local. Sorry if this is a bit confusing.

It does what it does because in the return statement when you
concatenate qsort(...x<..)+List[0:1]+qsort(...x>=..) you create a new
list. In the insertion sort you modify the values of the list directly
by doing List[j]=List[j-1] or List[j]=value.

If you just have to have the list modified in place, create another
wrapper function that calls your qsort and then will copy all data
from the result into the original list and you are done. Something
like:
def qsort_in_place(L):
   sortedL=qsort(L)
   for (i,x) in enumerate(sortedL):
 L[i]=x

Cheers,
-Nick Vatamaniuc

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

Re: deployment scripts

[kyosohma]

On May 14, 9:32 am, Erin <[EMAIL PROTECTED]> wrote:
> Does anyone have experience developing deployment scripts with Jython?

What do you mean by "deployment scripts"? What do you want to deploy?
Jython? A different program from Jython? Or do you mean packaging a
Jython program you wrote?

We need more info to be more helpful!

Mike

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

Re: GUI tutorial

[John K Masters]

On 15:03 Mon 14 May , Jarek Zgoda wrote:
> John K Masters napisał(a):
> 
> > Can someone point me in the direction of a good tutorial on programming
> > python with a GUI? I'm just starting out with python and have written a
> > few scripts successfully but would like to add a graphical front end to
> > them to make it easier for my work colleagues, most of whom have never
> > used a command line, to use.
> 
> Each of GUI frameworks/libraries has its own tutorial and some even more
> than one... The choice is directly related to what library you would use.

Thanks to all for the advice. I shall start with Py-GTK and see how it
goes.

Regards, John
-- 
War is God's way of teaching Americans geography
Ambrose Bierce (1842 - 1914)
-- 
http://mail.python.org/mailman/listinfo/python-list

tkinter button state = DISABLED

[rahulnag22]

I have created a button widget with a button click binding. The button
initially has a state=disabled. I can see the greyed out version of
the button in the GUI. But If I click on the button it still invokes
the callback/binding function.

Any suggestions as to why the callback is being invoked even though
the button has a disabled state. It looks like-

b=Button(frame,  text = "Button", state = 'disabled')

b.bind("",
lambda
event :
function()
)

Thanks
Rahul

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

Re: Sorting troubles

[seyensubs]

I see. I figured that list comprehensions made another list(duh), but
I thought I could relink the object(List) to the new list and keep it
once the function ended.

Is it possible to pass a reference(to an object.. Like 'List',
basically) to a function and change the reference to point to
something created inside a function? Or all data unreturned from a
function is lost and no references kept?(The second, I'd guess, since
it's local temporary scope, but you never know, maybe Python can :) )

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

Re: Jessica Simpson Sports new "Boob Job"!!!@

[wb]

On May 14, 2:09 am, [EMAIL PROTECTED] wrote:


If her boobs getting any bigger she won't be able to stand up.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Terry Reedy]

"Stefan Behnel" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Sounds like CPython would better follow IronPython here.

One could also turn the argument around and say that there is no need to 
follow IronPython; people who want non-ASCII identifiers can just juse 
IronPython.




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

Re: tkinter button state = DISABLED

[Peter Otten]

[EMAIL PROTECTED] wrote:

> I have created a button widget with a button click binding. The button
> initially has a state=disabled. I can see the greyed out version of
> the button in the GUI. But If I click on the button it still invokes
> the callback/binding function.
> 
> Any suggestions as to why the callback is being invoked even though
> the button has a disabled state. It looks like-
> 
> b=Button(frame,  text = "Button", state = 'disabled')
> 
> b.bind("",
> lambda
> event :
> function()
> )

Well, the /mouse/ button /was/ released. Do you know about the alternative?

b = Button(..., command=function) # no bind(), no lambda

It behaves like you expect. 

Peter

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

=// Homeland Security on High Alert!!

[ready . or . special3]

http://freewindowsvista.blogspot.com/ - With a class action lawsuit
looming, three politicians question the head of the Department of
Homeland Security about the lost hard drive. The laptop was never
found...

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Michel Claveau]

And  Il1 O0 ?

-- 
@-salutations

Michel Claveau


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

Re: Recursion limit problems

[Terry Reedy]

"elventear" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
On May 12, 12:25 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 11 May 2007 19:17:57 -0300, elventear <[EMAIL PROTECTED]>
> escribió:
> "The only required property is that objects which compare equal have the
> same hash value; it is advised to somehow mix together (e.g., using
> exclusive or) the hash values for the components of the object that also
> play a part in comparison of objects. If a class does not define a
> __cmp__() method it should not define a __hash__() operation either; if 
> it

I suspect/believe that the above should be __cmp__() or __eq__() both for 
uniformity with the usage below and also because objects do not need to be 
ordered (__cmp__) to be used as dict keys.

> defines __cmp__() or __eq__() but not __hash__(), its instances will not
> be usable as dictionary keys. If a class defines mutable objects and
> implements a __cmp__() or __eq__() method, it should not implement
> __hash__(), since the dictionary implementation requires that a key's 
> hash
> value is immutable (if the object's hash value changes, it will be in the
> wrong hash bucket)."

Thanks for the information. I have a doubt regarding the wording in
the paragraph on top.

Since I am defining a hash for my object, it makes sense that I should
be able to define equality. But I am not sure about inequality, in my
specific case. The paragraph above mentions that __cmp__ should be
defined if I define a __hash__, but in the default behaviour of
__cmp__ inequality is included. So what should I do? Also why is
equality necessary to be defined? Do dicts only use __hash__ or do
they use equality as well?
===

Dicts first compare hashes and if they are equal, then check equality.  If 
two unequal strings have the same hash value, as is possible of course 
(given only 2**32 possible hashes and many more possible strings), both can 
still be used as different keys.  Ditto for unequal numbers.  Or for a 
number and string with equal hashes.  And so on.  The first quoted 
sentence, about mixing, is directed at minimizing such hash collisions.

Terry Jan Reedy



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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Michel Claveau
wrote:

> And  Il1 O0 ?

Hm, we should ban digits from identifier names.  :-)

Ciao,
Marc 'BlackJack' Rintsch

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

Re: Sorting troubles

[Terry Reedy]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
|I have the following implementations of quicksort and insertion sort:
|
| def qSort(List):
|if List == []: return []
|return qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
|   qSort([x for x in List[1:] if x>=List[0]])
|
| def insertSort(List):
|for i in range(1,len(List)):
|value=List[i]
|j=i
|while List[j-1]>value and j>0:
|List[j]=List[j-1]
|j-=1
|List[j]=value
|
| Now, the quickSort does not modify the original list, mostly because
| it works on products and concatenations, rather than alterations.
| The insertion sort, however, does modify the list. Now, to give
| results, they should be called in such a way( A is an unsorted list)
| A=qSort(A)
| # the insertion sort does not require this,
| insertSort(A)
|
| I would like to know how can I modify the qSort function such that it
| affects the list directly inside
| I have tried doing it like this
|
| def qSort(List):
|if List == []: return []
|List = qSort([x for x in List[1:] if x< List[0]]) + List[0:1] + \
|   qSort([x for x in List[1:] if x>=List[0]])
|return List
|
| while processing, the list changes, but those changes remain inside
| the function, so that once it's over, if nothis catches the return,
| the original List remains unchanged.
|
| If not a solution, I would like to at least know why it does what it
| does. I so understand that List(above) is only a reference to the
| actual data(a list), but I'm not passing a copy of the data to the
| function, but the actual reference(hence, insertSort does
| modifications). But then how can I change, inside the function, the
| object List is referencing to? If I can't modify the original list,
| maybe I can make the variable List point to another list? But changes
| inside the function are local. Sorry if this is a bit confusing.

The traditional way to do qsort in place (ignoring possible variations):

def  qsort(List, start=0, stop=None):
  if start >= stop: return
  if stop == None: stop = len(List)
  p = partition(List, start, stop) # p = index of pivot/partition item
  qsort(List, start, p)
  qsort(List, p+1, stop)

where partition puts elements less that pivot value before the pivot value 
and greater values after.

You could instead call your function qSorted to indicate that it returns a 
sorted copy ;-)

Terry Jan Reedy



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

Re: Time

[Gabriel Genellina]

En Mon, 14 May 2007 11:27:35 -0300, HMS Surprise <[EMAIL PROTECTED]>  
escribió:

> On May 14, 9:22 am, HMS Surprise <[EMAIL PROTECTED]> wrote:
>
> Oops +=1, should be:
>  hrMn[0] = int(hrMn[0]
>  if t[2] == 'PM':
>  hrMn[0] += 12
>
> Need more starter fluid, coffee please!!!

Still won't work for 12 AM nor 12 PM...

-- 
Gabriel Genellina

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

Re: Interesting list Validity (True/False)

[[EMAIL PROTECTED]]

On May 13, 8:24 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Sat, 12 May 2007 21:50:12 -0700, [EMAIL PROTECTED] wrote:

I intended to reply to this yesterday, but circumstances
(see timeit results) prevented it.

> >> > Actually, it's this statement that's non-sensical.
>
> >> > 
> >> > "if arg==True" tests whether the object known as arg is equal to the
> >> > object known as True.
> >> > 
>
> >> Not at all, it makes perfect sense. X == Y always tests whether the
> >> argument X is equal to the object Y regardless of what X and Y are.
>
> > Except for the exceptions, that's why the statement is wrong.
>
> But there are no exceptions.


Sec 2.2.3:
Objects of different types, *--->except<---* different numeric types
and different string types, never compare equal;



> X == Y tests for equality. If it returns
> True, then the objects are equal by definition. That's what equal means in
> Python.
>
> One can abuse the technology to give nonsensical results:
>
> class EqualToEverything(object):
> def __eq__(self, other):
> return True
>
> >>> x = EqualToEverything()
> >>> x == 1.0
> True
> >>> x == [2.9, "hello world"]
>
> True
>
> but that's no different from any language that allows you to override
> operators.
>
> >> > None of these four examples are "equal" to any other.
>
> >> That's actually wrong, as you show further down.
>
> > No, it's not, as I show further down.
>
> But you show no such thing.
>
> Or, to put it another way:
>
> Did! Did not! Did! Did not! Did! Did not! ...
>
> >>  a = 1
> >>  b = (1,)
> >>  c = [1]
> >>  d = gmpy.mpz(1)
>
> [snip]
>
> >>  a==d
> >> > True
>
> >> See, a and d are equal.
>
> > No, they are not "equal".
>
> Of course they are. It says so right there: "a equals d" is true.

Ok, but they are an exception to the rule "different types compare
False".

>
> > Ints and mpzs should NEVER
> > be used together in loops, even though it's legal.
>
> Why ever not? If you need an mpz value in order to do something, and no
> other data type will do, what would you suggest? Just give up and say
> "Don't do this, because it is Bad, m'kay?"

It's not the mpzs you shouldn't use, its the ints. I also stessed
"in loops". Replacing an integer literal with a variable still
requires a coercion, so it doesn't matter if n + 1 occurs outside
a loop.

>
> > The ints
> > ALWAYS have to be coerced to mpzs to perform arithmetic
> > and this takes time...LOTS of it.
>
> Really? Just how much time?

Can't say, had to abort the following.
Returns the count of n/2 and 3n+1 operations [1531812, 854697].

import gmpy

def collatz(a):
ONE = gmpy.mpz(1)
TWO = gmpy.mpz(2)
TWE = gmpy.mpz(3)
a = gmpy.mpz(a)
t = 0
u = 0
done = 0
while done==0:
f = gmpy.scan1(a,0)
if f>0:
a = a >> f
u += f
else:
if a==1:
done = 1
else:
a = a*TWE + ONE
t += 1
return [u,t]

def collatz2(a):
t = 0
u = 0
done = 0
while done==0:
f = gmpy.scan1(a,0)
if f>0:
a = a >> f
u += f
else:
if a==1:
done = 1
else:
a = a*3 + 1
t += 1
return [u,t]

def test():
collatz(2**177149-1)

def test2():
collatz2(2**177149-1)

if __name__=='__main__':
from timeit import Timer
t = Timer("a = test()", "from __main__ import test")
u = Timer("b = test2()", "from __main__ import test2")
print t.timeit(10)
print u.timeit(10)

##723.430377542
##*ABORTED after 20 hours*


>
> timeit.Timer("x == y", "import gmpy; x = 1; y = gmpy.mpz(1)").repeat()
> timeit.Timer("x == y", "x = 1; y = 1").repeat()
>
> I don't have gmpy installed here,

Good Lord! How do you solve a Linear Congruence? :-)

> so I can't time it, but I look forward
> to seeing the results, if you would be so kind.

I had a lot of trouble with this, but I think I finally got a
handle on it. I had to abort the previous test after 20+ hours
and abort a second test (once I figured out to do your example)
on another machine after 14+ hours. I had forgotten just how
significant the difference is.

import timeit

##t = timeit.Timer("a == b", "a = 1; b = 1")
##u = timeit.Timer("c == d", "import gmpy; c = 1; d =
gmpy.mpz(1)")
##t.repeat()
##[0.22317417437132372, 0.22519314605627253, 0.22474588250741367]
##u.repeat()
##[0.59943819675405763, 0.5962260566636246, 0.60122920650529466]

Unfortunately, this is not a very useful test, since mpz
coercion appears to vary ny the size of the number involved.
Although changing t to

##t = timeit.Timer("a == b", "a = 2**177149-1; b = 2**177149-1")

still produces tractable results
##t.repeat()
##[36.323597552202841, 34.727026758987506, 34.574566320579862]

the same can't be said for mpz coercion:

##u = timeit.Timer("c == d", "import gmpy; c = 2**177149-1; d =
gmpy.mpz(2**

track cpu usage of linux application

[Fabian Braennstroem]

Hi,

I would like to track the cpu usage of a couple of
programs using python. Maybe it works somehow with
piping 'top' to python read the cpu load for a greped
application and clocking the the first and last
appearence. Is that a good approach or does anyone have
a more elegant way to do that?

Greetings!
 Fabian

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Marc 'BlackJack' Rintsch schrieb:
> In <[EMAIL PROTECTED]>, Michel Claveau
> wrote:
> 
>> And  Il1 O0 ?
> 
> Hm, we should ban digits from identifier names.  :-)

Ah, good idea - and capital letters also. After all, they are rare enough in
English to just plain ignore their existance.

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

RE: PEP 3131: Supporting Non-ASCII Identifiers

[Michael Yanowitz]

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

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Stefan Behnel
Sent: Monday, May 14, 2007 2:53 PM
To: python-list@python.org
Subject: Re: PEP 3131: Supporting Non-ASCII Identifiers


Marc 'BlackJack' Rintsch schrieb:
> In <[EMAIL PROTECTED]>, Michel Claveau
> wrote:
>
>> And  Il1 O0 ?
>
> Hm, we should ban digits from identifier names.  :-)

Ah, good idea - and capital letters also. After all, they are rare enough in
English to just plain ignore their existance.

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


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