[Flickr] Your upload has failed with the following message:

[Flickr Mail]

If you think you shouldn't be getting this error, you can
search our FAQs or send us a help case from
http://flickr.com/help/ and we'll do out best to help!

Thanks,

The Flickr Team

-

This information might be of use to us when diagnosing what
went wrong : 

To Address: york65g...@photos.flickr.com
Cc Address: 
>From Address:  python-list@python.org
Message
ID: <20110120080606.d05292c...@www120.flickr.mud.yahoo.com>
Parsed Addresses:   york65g...@photos.flickr.com
Handling Server:www120
Handler Version:69900OH HAI
Transaction Log:www120-1295510770.email
Logged Date:20-01-2011
User NSID:  8109696@N02
Blog Id:

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

Need advices for mysqldb connection best practice

[Romaric DEFAUX]

Hi all,


I've a problem with a mysql connection. I run a client/server 
application. Every hour, clients contact the server, send datas, and the 
server updates the database. Everything works perfectly.
But after a while, I get in trouble with my db connection. I've got the 
impression my server application "mix" the cursors...

I've got this kind of strange errors in my log :
Traceback (most recent call last):
  File "/usr/local/lib/audaxis/system_serverbox.py", line 519, in 
__update_in_db

old_serverbox.load_from_db(cursor, self.__id)
  File "/usr/local/lib/audaxis/system_serverbox.py", line 131, in 
load_from_db

self.__uuid = row['uuid']
TypeError: 'NoneType' object is unsubscriptable

Traceback (most recent call last):
  File "/usr/local/lib/audaxis/system_server.py", line 168, in process_data
result += my_serverbox.save_website_list(cursor)
  File "/usr/local/lib/audaxis/system_serverbox.py", line 1197, in 
save_website_list

old_serverbox.load_from_db(cursor, self.__id)
  File "/usr/local/lib/audaxis/system_serverbox.py", line 143, in 
load_from_db

self.__load_disk_list_from_db(cursor)
  File "/usr/local/lib/audaxis/system_serverbox.py", line 203, in 
__load_disk_list_from_db

my_disk.load_from_db(cursor, disk_id)
  File "/usr/local/lib/audaxis/system_disk.py", line 54, in load_from_db
self.__fs = row['fs']
KeyError: 'fs'

Traceback (most recent call last):
  File "/usr/local/lib/audaxis/system_serverbox.py", line 521, in 
__update_in_db

__uuid_host = self.is_virtual(cursor)
  File "/usr/local/lib/audaxis/system_serverbox.py", line 339, in 
is_virtual

result = row['uuid']
KeyError: 'uuid'

and a lot of KeyError (at every update)

The requests that produce these errors were working perfectly. And if I 
restart my server, everything is working fine again !


Here's part of my code (I removed some parts):
I create a db connection like this in my object server:
def connect():
con = MySQLdb.connect (host = "localhost", user = "myuser", passwd 
= "good_password", db = "my_db", cursorclass=DictCursor)
con.ping(True) <- this normally activate auto-reconnection (or I 
did a mistake ?)

con.cursor().execute('SET AUTOCOMMIT=1')
return con

self.__db_connection = connect()

Then, each time a client connects :
cursor = self.__db_connection.cursor()
...process the datas...
cursor.close()

So , I thought about some solutions :
- restarting the server every sometimes (but it's the worst solution in 
my mind)
- creating a connection (not only cursor) at each client connection (but 
I'm afraid it overloads the mysql server)
- trying to find where I did a mistake, and correct the bug (that why 
I'm doing by writing this list :), or send me a link that could help me 
(before writing I googled for one hour and found nothing interresting in 
my case...)


Thanks in advance for your advices !

Romaric

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

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Dave Angel]

On 01/-10/-28163 02:59 PM, Octavian Rasnita wrote:

From: "geremy condra"

On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita  wrote:



Would it be hard to introduce the possibility of adding encryption of the
bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for
Perl?

Octavian


The iron law of cryptography: there is no cryptographic solution to a
problem in which the attacker and intended recipient are the same
person.

Schemes like this are at most an annoyance to people willing to
reverse engineer your code.

Geremy Condra



I don't know how the Python bytecode works... how it is executed.

I thought that Python parses the .py file and generates the bytecode that 
doesn't contain all the necessary information for re-creating the source code.
(But that I agree, that might mean real compilation which is not the case...)

Octavian

It's not hard to experiment with.  I've written disassemblers for other 
byte-code formats, but not for Python's.  The following is pasted 
together, so it may not be completely correct.  But it's close.



Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def test(arg1, arg2):
... if arg1 < 65:
... print arg2
...
>>> import dis
>>> dis.dis(test)
  2   0 LOAD_FAST0 (arg1)
  3 LOAD_CONST   1 (65)
  6 COMPARE_OP   0 (<)
  9 JUMP_IF_FALSE9 (to 21)
 12 POP_TOP

  3  13 LOAD_FAST1 (arg2)
 16 PRINT_ITEM
 17 PRINT_NEWLINE
 18 JUMP_FORWARD 1 (to 22)
>>   21 POP_TOP
>>   22 LOAD_CONST   0 (None)
 25 RETURN_VALUE
>>>

Now, there are tools which reverse that into something pretty similar to 
python source.  But you can see even from the built-in features that 
lots of information is there.  I'd assume that something very similar is 
in the byte code files themselves.


DaveA

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

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 20, 2:22 am, "Octavian Rasnita"  wrote:
> Where do you got the conclusion that the accessibility is so poor?

By an examination of the facts.  MSAA is universally hated and all
screen readers actively have to work around it and its many
limitations (meaning that as an application programmer, you can do the
"right" thing and still get undesired behavior through no fault of
your own).  I have no clue if it's replacement is better, but I do
know few programs use it, so it's little comfort.

The situation on Linux is still an outright disaster.  Neither Qt4 nor
GTK enable accessibility functionality automatically and support from
the various distribution vendors is pretty limited.  It is improving,
however.

Accessibility still requires special effort "over and above" the norm
by the programmer whether you believe this to be the case or not.
Most programmers aren't even aware of the fact they must consider it
(a point you've made yourself before!) and hence commit various
accessibility sins.  This is mostly a cultural problem, not a
technical one, but it's still a real problem.

Plus, out of the stuff I run daily on Windows: two of the applications
are entirely inaccessible: the Adobe AIR one and the Gtk one.
Songbird, the XUL based music player, has some accessibility, but none
of the navigation controls seem to be enabled, which would make it
very difficult to actually use, I imagine.  It's also not particularly
keyboard friendly: you don't even get a visual focus indicator most of
the time, even though the focus is moving.

> But You keep telling me that it is hard to create accessible programs, which
> is false, but you don't know and don't want to try to see.
> Try to create a WxPython app that doesn't do anything but only displays some
> menus, buttons, combo boxes, list boxes, list views, tree views, text
> fields, check boxes, radio buttons... and you will see that they are very
> accessible with that screen reader I told you about, without requiring you
> to do anything special that you wouldn't do otherwise.

Applications that only display these things aren't very interesting.
And no, they still require additional effort.  Most developers can't
even be assed to get a sane tab focus order set, to say nothing of
keyboard shortcuts, accessibility descriptions / proper label
associations for buttons and other controls.

It gets even more complicated when you get away from controls only
meant to display text.  How many web pages have you visited where
images are missing alt tags?  Do you really thing those same people
are going to bother trying to do the right thing if asked to create a
desktop GUI application?  No, they're not, and you're going to get
whatever happens automatically.  Which isn't nothing (in some
toolkits), but it's also not what one really wants, either.

>
> How do you came to the conclusion that QT is accessible on all operating
> system?

By actually going out, reading, and even testing?  Qt has had
functional accessibility support on OS X and Windows since Qt3, and
functional support on Linux, OS X, and Windows since Qt4.  It even
extends to PySide, with a few limitations: you can't write custom
accessible widgets in PySide, though I'm pretty confident they'd
enable support if someone wrote a patch to enable the bindings.

> When you talk about accessibility, try it yourself and don't take the word
> of the GUI widgets developers.
>

I just did, NVDA was able to read my button text and its accessibility
description just fine, both in C++ and Python versions of my Qt
application.  I didn't bother testing Linux or OS X, but I'm sure it
would work there too.

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

Re: Should there be a 'core' python install?

[Giacomo Boffi]

"Martin P. Hellwig"  writes:

> Yep when I started looking much more at other toolkits, I started to
> like Tkinter more and more. Maybe its simplicity,

maybe the good design of Tk, 
-- 
BOMBED BY AIRCRAFT. SINKING. U-824.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Bill Felton]

On Jan 19, 2011, at 10:20 PM, Michael Torrie wrote:

> On 01/19/2011 05:01 PM, geremy condra wrote:
>> On Wed, Jan 19, 2011 at 3:04 PM, rantingrick  wrote:
>>> And you've also lost all
>>> connection with the people. I am desperately trying to to snap you out
>>> of this psychosis before it is too late! Tkinter will be the downfall
>>> of Python if we cannot muster the resolve to replace it with something
>>> that is current (or more current) technology.
> 
> I don't see the original bizarre rants for some reason (spam filter
> likely), but I have to say this is the most ridiculous thing I've heard
> in some time.  Tkinter the downfall of python?  Wow.  All of the python
> programmers I know (we use python every day at work) would  say, "what
> is tkinter?"  It's just not relevant to any of them that I know.  Google
> probably uses as much Python as anyone, and their programmers would
> probably agree.  Perhaps that's an argument to remove tkinter entirely,
> but not really a good one.
> 
With some hesitation, I feel a need to jump in here.  
I'm a complete newbie to Python.  
I'm still learning the language.  And you know what?  I've ignored Tkinter.  I 
quickly discovered the alternatives and am already working with wxPython.   
I can't believe anyone is so hung up by their own arrogance that they honestly 
believe that the mere *presence* of a gui kit inside of the standard 
distribution would prevent a newbie from learning about the existence and 
possible benefits of alternatives.  Sure, *they* can see alternatives and 
evaluate why Tkinter might not be a good choice under conditions x or y or z, 
but god forbid anyone new to the language should have to confront those issues 
or be asked to make such a decision.  How could we trust those lowly newbies to 
think *properly* about the issue!
ESPECIALLY in a language widely touted for the vast array of external libraries 
available.
The attitude that the standard distribution needs this kind of obsessive, 
hysterically blinkered, focused on irrelevant minutiae is far more likely to be 
the downfall of the language than the presence of a sub-optimal gui kit that no 
one is required to use.
As one of 'the people' who is presumably the focus of rantingrick's concern, 
let me assure him Tkinter is a non-issue.  MIchael is more in touch with my 
issues than rr, and appears to be suffering fewer disconnects from the reality 
of a programming language that ships with a large standard library and offers a 
plethora of extensions and alternatives, widely available and easy to find.

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

Re: __pycache__, one more good reason to stck with Python 2?

[John Pinner]

Hi

You have disturbe my slumber, Steven ;-)

On Jan 19, 2:42 pm, Steven D'Aprano  wrote:
> On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote:
> > It is now practically impossible to launch a Python application via a
> > .pyc file.
>
> When has that ever been possible?
>
> .pyc files are Python byte-code. You can't run them directly using Python
> (except via the import machinery), you can't run them as a script,
> they're not machine code. Unless you write a wrapper to import the file
> as a module, you can't directly execute .pyc files.

Not true. 'python myprog.pyc' has worked for as long as I have been
using Python. Whether or not it is a good idea is another matter.

Probably it would be best to check what you're saying before posting
such a bald assertion, even though you were 110% sure of what you were
saying. I've been there, done that, bought the tee-shirt.

Best wishes,

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
On Jan 20, 2:22 am, "Octavian Rasnita"  wrote:

Where do you got the conclusion that the accessibility is so poor?


By an examination of the facts.  MSAA is universally hated and all
screen readers actively have to work around it and its many
limitations (meaning that as an application programmer, you can do the
"right" thing and still get undesired behavior through no fault of
your own).  I have no clue if it's replacement is better, but I do
know few programs use it, so it's little comfort.


The Windows applications are not accessible only if they use MSAA. The 
screen readers know how to get the necessary information for making the 
interfaces accessible in other ways, but of course, it is harder for the 
screen reader manufacturers if the GUIs don't respect a standard.
And if MSAA is hated it doesn't mean that the accessibility is so poor as 
you might think.



The situation on Linux is still an outright disaster.  Neither Qt4 nor
GTK enable accessibility functionality automatically and support from
the various distribution vendors is pretty limited.  It is improving,
however.


It might be true, I don't know, because I use Linux only in command line 
mode.



Accessibility still requires special effort "over and above" the norm
by the programmer whether you believe this to be the case or not.


I don't understand how I need to "believe" this, while I made perfectly 
accessible applications without doing special efforts for making them to be 
accessible.
Of course, I don't consider something special to put a text label on a 
button, or radio button or check box.



Most programmers aren't even aware of the fact they must consider it
(a point you've made yourself before!) and hence commit various
accessibility sins.  This is mostly a cultural problem, not a
technical one, but it's still a real problem.


Yes, that's a problem but we divagate. The programmers need to take care 
about those details, like putting text labels on buttons, or tooltips for 
images, but these things are relevant only for accessible widgets. It 
*doesn't matter* if they put those labels if they use GUIS like Tk because 
they won't be accessible at all anyway.



Plus, out of the stuff I run daily on Windows: two of the applications
are entirely inaccessible: the Adobe AIR one and the Gtk one.
Songbird, the XUL based music player, has some accessibility, but none
of the navigation controls seem to be enabled, which would make it
very difficult to actually use, I imagine.  It's also not particularly
keyboard friendly: you don't even get a visual focus indicator most of
the time, even though the focus is moving.


Yes of course, Adobe's products are at most very hard accessible or not 
accessible at all and I already said that Gtk is not accessible under 
Windows, just like Tk.



But You keep telling me that it is hard to create accessible programs, 
which

is false, but you don't know and don't want to try to see.
Try to create a WxPython app that doesn't do anything but only displays 
some

menus, buttons, combo boxes, list boxes, list views, tree views, text
fields, check boxes, radio buttons... and you will see that they are very
accessible with that screen reader I told you about, without requiring you
to do anything special that you wouldn't do otherwise.


Applications that only display these things aren't very interesting.
And no, they still require additional effort.  Most developers can't
even be assed to get a sane tab focus order set,


Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl 
programmers don't need to set the tab focus because by default the tab focus 
is set in the order of the controls on the form and I thought it should be 
the same in WxPython.

So no special effort would be necessary.

Are you sure you are not confusing accessibility with usability?
Of course that an application which respects more usability rules is easier 
to use, and this means that it should have the controls with a right tab 
order, with clear text labels and so on, but we can talk about usability 
only for an accessible GUI.


JAWS screen reader has its own programming language and it can be used for 
improving the usability of a program. It can do very many things and it has 
more than 1000 functions, but it can't do anything in the case of 
inaccessible interfaces like Tk.



to say nothing of keyboard shortcuts, accessibility descriptions / proper 
label

associations for buttons and other controls.
It gets even more complicated when you get away from controls only
meant to display text.  How many web pages have you visited where
images are missing alt tags?  Do you really thing those same people
are going to bother trying to do the right thing if asked to create a
desktop GUI application?  No, they're not, and you're going to get
whatever happens automatically.  Which isn't nothing (in some
toolkits), but it's also not what one really wants, either.


Yes, that's true, but as 

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Bill Felton" 

I'm a complete newbie to Python.



To Python, or to programming in general? (Because it is important)


I'm still learning the language.  And you know what?  I've ignored 
Tkinter.



Why did you do that?


I quickly discovered the alternatives and am already working with 
wxPython.
I can't believe anyone is so hung up by their own arrogance that they 
honestly believe that the mere *presence* of a gui kit inside of the 
standard distribution would prevent a newbie from learning about the 
existence and possible benefits of alternatives.  Sure, *they* can see 
alternatives and evaluate why Tkinter might not be a good choice under 
conditions x or y or z,



Nobody said that the fact that Python promotes Tkinter *prevents" the 
beginners to learn to use another GUI.
I just say that if Python promotes Tkinter, the beginners that might not 
have experience programming in other languages might not know at all which 
is the difference between all those GUI types, and it might not know at all 
that there are more GUI types and it won't know for sure which are the 
differences between them.


And for a real beginner in programming it could be harder and less important 
to make the effort of finding and downloading and installing another GUI 
just because it offer some features which are not interesting for most 
users, so he/she will prefer using what Python offers and he/she won't know 
that that solution is bad.


Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[python]

Bill,

> I can't believe anyone is so hung up by their own arrogance that they 
> honestly believe that the mere *presence* of a gui kit inside of the standard 
> distribution would prevent a newbie from learning about the existence and 
> possible benefits of alternatives ... ESPECIALLY in a language widely touted 
> for the vast array of external libraries available. The attitude that the 
> standard distribution needs this kind of obsessive, hysterically blinkered, 
> focused on irrelevant minutiae is far more likely to be the downfall of the 
> language than the presence of a sub-optimal gui kit that no one is required 
> to use ...

+1 (very well said)

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

USA Free classified site for free ad posting !!!

[Marrina anderson tina]

We are providing free services for all !!!

Guys, are you looking for having nice opportunity to post or
submit your advertisement without any impediments! Just visit and
get gigantic chance to give free advertisement in our here !!!


Just visit at: http://www.webadlist.com/

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

difference between python and matlab

[lakshmi]

Is the programming related to image processing in python is advantageous or 
else in MATLAB 


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

getdefaultencoding - how to change this?

[Helmut Jarausch]

Hi,
I've searched the net but didn't find the information I need.
Using Python-2.7.1, I know, I can't modify defaultencoding at run time.
Python even ignores 
export PYTHONIOENCODING=ISO8859-1

locale.getdefaultlocale()[1]
returns 
'ISO8859-1'

still sys.stdout is using the ascii codec.
How can I recompile Python (itself) to change this to iso8859-1 ?
(My favourite editor cannot be told to use unicode.)

Many thanks for a hint,
Helmut.

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

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 20, 8:19 am, "Octavian Rasnita"  wrote:
> The Windows applications are not accessible only if they use MSAA. The
> screen readers know how to get the necessary information for making the
> interfaces accessible in other ways, but of course, it is harder for the
> screen reader manufacturers if the GUIs don't respect a standard.

Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful.  But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS.  That means essentially every non-MS toolkit that's been
discussed.

> And if MSAA is hated it doesn't mean that the accessibility is so poor as
> you might think.

No, but it does mean precisely what I said: application developers can
do the "right" thing and get the wrong result.

> Yes, that's a problem but we divagate.

If you believe that is a problem then you cannot say, "Accessibility
does not require special effort" without contradicting yourself.  If
it did not require effort over and above the norm, then the cultural
problem would not exist.

> Yes of course, Adobe's products are at most very hard accessible or not
> accessible at all and I already said that Gtk is not accessible under
> Windows, just like Tk.

Which means you're excluding a large swath of applications in your
analysis.

> Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl
> programmers don't need to set the tab focus because by default the tab focus
> is set in the order of the controls on the form and I thought it should be
> the same in WxPython.

It's set in the order you create the controls (with some exceptions),
which may or may not be the correct tab focus order.  Moreover, the
same FAQ I linked tells you that you need to set special styles to
support proper tab order when tabbed widgets and certain other
controls are involved, to say nothing of fall backs for certain other
controls that aren't provided automatically.

> Yes, that's true, but as I said, some GUIS like WxPython offer the
> accessibility, so those controls are visible, and it is less important if
> they are in a right tab order or if some of the controls are not labeled,
> because the screen reader can solve these things.

You've said yourself that it often requires trial and error on the
part of the user, so which is it?

> A GUI which offers accessible widgets only if they are coded specially for
> beeing accessible are not accessible at all,

That's the case with every GUI API on the planet: if you write a
custom widget you must provide accessibility support for it.  This is
nothing new.

> Have you created that QT application with its default options? Without doing
> anything special to make it accessible?

Yes, you don't have to do a thing, unless you're custom building Qt
yourself.  On Linux, you have to set QT_ACCESSIBILITY = 1, but Linux
is the exception.

> And most important, have you tested it with JAWS screen reader? (Or
> WindowEyes at least) because these are the most used screen readers.
> NVDA is pretty poor and it can't be used for very complex things (yet).
>
No, and I have zero interest in doing so.  Point was merely to
demonstrate your statement was false.

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

Part of RFC 822 ignored by email module

[Bob Kline]

I just noticed that the following passage in RFC 822:

The process of moving  from  this  folded   multiple-line
representation  of a header field to its single line represen-
tation is called "unfolding".  Unfolding  is  accomplished  by
regarding   CRLF   immediately  followed  by  a  LWSP-char  as
equivalent to the LWSP-char.

is not being honored by the email module.  The following two invocations 
of message_from_string() should return the same value, but that's not 
what happens:


>>> import email
>>> email.message_from_string("Subject: blah").get('SUBJECT')
'blah'
>>> email.message_from_string("Subject:\n blah").get('SUBJECT')
' blah'

Note the space in front of the second value returned, but missing from 
the first.  Can someone convince me that this is not a bug?


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 6:30 am, Bill Felton 
wrote:

> With some hesitation, I feel a need to jump in here. I'm a complete
> newbie to Python. I'm still learning the language. And you know
> what? I've ignored Tkinter.

Well it is really not a good idea to show your ignorance of a subject
matter directly before offering your opinion on that same subject
matter. Most people don't listen to the uninformed. Just FYI. However
lucky for you i am a fair guy and will give anyone a chance, sometimes
even two. ;-)

> I quickly discovered the alternatives and am already working with
> wxPython.

But is wxPython the correct alternative for you? What is so bad about
Tkinter exactly?. Why did you choose to skip it? There must be a
compelling reason. Why did you go out of your way to download another
GUI library when one exists in the stdlib? These are all good
questions that demand answers. So far you've offered opinion and no
facts. You said you ignored Tkinter but you did not explain why. Now
would be a good time to inject some facts into your argument.

> I can't believe anyone is so hung up by their own arrogance that
> they honestly believe that the mere *presence* of a gui kit inside
> of the standard distribution would prevent a newbie from learning
> about the existence and possible benefits of alternatives.

No one has ever said such an outlandish thing as this. You have missed
the entire point of this thread, congratulations! Now, go back and
read over the entire thread again and again until you comprehend it
completely before making another post. I look forward to your coherent
and lively discussion based on facts and not simply opinions.

> Sure, *they* can see alternatives and evaluate why Tkinter might not
> be a good choice under conditions x or y or z, but god forbid anyone
> new to the language should have to confront those issues or be asked
> to make such a decision. How could we trust those lowly newbies to
> think *properly* about the issue!

We can't. Are you actually suggestion that someone with NO experience
with ANY of the GUI library available somehow has a better insight
into choosing the best GUI library than someone who (i don't know)
ACTUALLY HAS USED ALL OF THEM! Who's sock puppet are you Bill? Really.
And if you are not a sock puppet i HOPE you are just trolling because
this is a bombastic display of ignorance!. You could not be more
*uninformed* my friend. Heck with your mindset, the "Cookie Monster"
should replace Guido as BDFL. He has NO experience with anything
besides chowing down cookies, perfect choice!

> ESPECIALLY in a language widely touted for the vast array of
> external libraries available.The attitude that the standard
> distribution needs this kind of obsessive, hysterically blinkered,
> focused on irrelevant minutiae is far more likely to be the downfall
> of the language than the presence of a sub-optimal gui kit that no
> one is required to use.

Yes, and you just hit the nail on the the head! Why leave the stdlib
full of cruft (Tkinter)?

> As one of 'the people' who is presumably the focus of rantingrick's
> concern, let me assure him Tkinter is a non-issue. MIchael is more
> in touch with my issues than rr.

FYI you are NOT one of the people that is the focus of my concern
because YOU only see the world from a limited viewpoint. And i never
proposed to solve every Python programmers problems. You completely
misunderstand my intentions (along with everyone else!). I  do not
believe in "Utopian dreams". Some people will never be happy with the
state of Python and that is OK. However, the goal is to keep the
majority happy AND keep Python "presentable" and "competitive" for the
next decade. I am sorry you don't fit into any of these categories but
that is your own fault. Why? Because you are not concerned with the
community as a whole. You are only concerned with YOURSELF. You are
displaying both selfishness and ignorance at the same time. We don't
care what selfish people think and we care even less what the ignorant
think. If you decide to become a "team player" then you will be a part
of this community. Lucky for you ignorance and selfishness are
reversible personality traits.


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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 7:48 am, pyt...@bdurham.com wrote:
> Bill,
[...snip...]

> +1 (very well said)

Yes maybe Bill should be BDFL or a core developer. He has all the
answers. But no FACTS!

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

Re: getdefaultencoding - how to change this?

[Helmut Jarausch]

On Thu, 20 Jan 2011 14:31:09 +, Helmut Jarausch wrote:

> Hi,
> I've searched the net but didn't find the information I need. Using
> Python-2.7.1, I know, I can't modify defaultencoding at run time. Python
> even ignores
> export PYTHONIOENCODING=ISO8859-1
> 
> locale.getdefaultlocale()[1]
> returns
> 'ISO8859-1'
> 
> still sys.stdout is using the ascii codec. How can I recompile Python
> (itself) to change this to iso8859-1 ? (My favourite editor cannot be
> told to use unicode.)
> 

Sorry for answering myself. One last trial did succeed.
My locale as root differed from my locale as non-root user.
After changing the root locale and recompiling Python, it works now.





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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful.  But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS.  That means essentially every non-MS toolkit that's been
discussed.


Yes, but WxPython uses wxWIDGETS and wxWIDGETS use the standard Win32 controls 
under Windows, so they are accessible.
And they use Gtk under Linux and Gtk is accessible under Linux also.

That's why I said that WxPython should be prefered.

> And if MSAA is hated it doesn't mean that the accessibility is so poor as
> you might think.

No, but it does mean precisely what I said: application developers can
do the "right" thing and get the wrong result.


Yes of course they can do that if they use the wrong tool. They can't do the 
right thing if they believe that Tk or Silverlight or Flash is accessible no 
matter if they follow the recommendations for accessibility, because the screen 
readers don't support those interfaces.

> Yes, that's a problem but we divagate.

If you believe that is a problem then you cannot say, "Accessibility
does not require special effort" without contradicting yourself.  If
it did not require effort over and above the norm, then the cultural
problem would not exist.


Nope, the cultural problem exists because the programmers use the wrong 
interface, not because they just don't make the efforts for making that 
interface more accessible.
To be more clear and not to include in the discussion many interfaces, we are 
comparing Tkinter and WxPython. Most users that require accessibility are using 
Windows and under Windows WxPython use the underlying Win32 GUI which is 
accessible, while Tk is not accessible at all, no matter what the programmers 
do in order to make the interface accessible.

> Yes of course, Adobe's products are at most very hard accessible or not
> accessible at all and I already said that Gtk is not accessible under
> Windows, just like Tk.

Which means you're excluding a large swath of applications in your
analysis.


I am not excluding anything. I said that all the Tk-based programs are 
inaccessible no matter what the programmer does to make it accessible, because 
the screen readers can't work with that interface.
And I have also said which are the accessible interfaces: wxWIDGETS (which use 
Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does 
exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the 
user installs Java Access Bridge).

Some of the interfaces created with other GUI libs might be accessible but it 
is not sure. What is sure is that the Tk-based interfaces are not accessible.


>  Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl
> programmers don't need to set the tab focus because by default the tab focus
> is set in the order of the controls on the form and I thought it should be
> the same in WxPython.

It's set in the order you create the controls (with some exceptions),
which may or may not be the correct tab focus order.  Moreover, the
same FAQ I linked tells you that you need to set special styles to
support proper tab order when tabbed widgets and certain other
controls are involved, to say nothing of fall backs for certain other
controls that aren't provided automatically.

Yes, but with or without a proper tab order, WxPython creates accessible apps, 
while Tkinter doesn't.


> Yes, that's true, but as I said, some GUIS like WxPython offer the
> accessibility, so those controls are visible, and it is less important if
> they are in a right tab order or if some of the controls are not labeled,
> because the screen reader can solve these things.

You've said yourself that it often requires trial and error on the
part of the user, so which is it?


It depends if there is a JAWS script defined. JAWS provides by default scripts 
for dozens of popular applications for making them more usable. Each user can 
create his/her own script, because JAWS include that scripting language and a 
programming interface so the user can create their own script for an 
application for improving its usability, for labeling some not-named controls, 
for reading some parts of the screen when some events occur and many other 
things.
If the user doesn't want or don't know how to create that script for improving 
the usability, he/she might need to learn how to use the application by trial 
and error, but what I want to show is that the user is *able* to use that 
application, even if the interface is not very friendly, but it would be 
absolutely impossible to use an application created with Tkinter.


> A GUI which offers accessible widgets only if they are coded specially for
> beeing accessible are not accessible at all,

That's the case with every GUI API on the planet: if you write a
custom widget you must provide accessibility support for it.  This is
nothing new.


I am not talking about 

Re: Tkinter: The good, the bad, and the ugly!

[Grant Edwards]

On 2011-01-20, Michael Torrie  wrote:

> I don't see the original bizarre rants for some reason (spam filter
> likely), but I have to say this is the most ridiculous thing I've heard
> in some time.  Tkinter the downfall of python?  Wow.  All of the python
> programmers I know (we use python every day at work) would  say, "what
> is tkinter?"  It's just not relevant to any of them that I know.  Google
> probably uses as much Python as anyone, and their programmers would
> probably agree.  Perhaps that's an argument to remove tkinter entirely,
> but not really a good one.
>
> In the meantime they happily crank out code with Django, or PyQt, or
> PyGTK, or even Tkinter--whatever tool is appropriate for the job.

Tkinter has it's flaws.  For example, the fact that it inclues a Tcl
interpreter inside the black box annoys me because I think Tcl is an
awful, awful language.  That's somewhat irrational, so perhaps that's
my flaw and not Tkinter's.

However, Tkinter is easy to use (especially for simple tasks) and it
_works_.  I wrote a moderatly complex (to me) UI in Tkinter 10+ years
ago.  It still works fine.  I couldn't say that about some wxPython
programs a quarter that old.

> Perhaps a reference to Xah Lee's web site would suffice.

:)

-- 
Grant Edwards   grant.b.edwardsYow! What GOOD is a
  at   CARDBOARD suitcase ANYWAY?
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

printing a list with non-ascii strings

[Helmut Jarausch]

Hi,

I don't understand Python's behaviour when printing a list.
The following example uses 2 German non-ascii characters.

#!/usr/bin/python
# _*_ coding: latin1 _*_
L=["abc","süß","def"]
print L[1],L

The output of L[1] is correct, while the output of L shows up as
 ['abc', 's\xfc\xdf', 'def']

How can this be changed?

Thanks for hint,
Helmut.

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

Re: Tkinter: The good, the bad, and the ugly!

[Grant Edwards]

On 2011-01-20, Octavian Rasnita  wrote:
> From: "Grant Edwards" 
 On all of my computers, wxPython uses Gtk.  There are other choices
 for wxWidget backends on Linux, but Gtk is by far the most common.
 IOW, if Gtk is bad, then wxPython is bad.
>>>
>>> Not true.
>>
>> I think you're playing a bit fast and loose with your accusations.
>
>
>:-)
> I've made no accusations,

Yes you have.  You claimed what I stated was not true.

> but I only try to inform the people about the
> accessibility of different GUI libs.
>
>> Which of my statements was "not true"?
>>
>> 1) On all of my computers wxPython uses Gtk.
>>
>> 2) There are other backend choices on Linux besides Gtk.
>>
>> 3) Gtk is by far the most common wxWidgets backend on Linux/Unix.
>>
>> 4) If Gtk is bad then wxPython is bad.
>>
>> Note that 4) follows logically from 3), so to say that 4) is "not
>> true" you have to show that 3) is "not true".
>
> The wrong conclusion is that if Gtk is bad, then WxPython is bad. Gtk
> is inaccessible under Windows, not under Linux, but WxPython doesn't
> use Gtk under Windows so WxPython is OK.

Ah.  I didn't realize we were operating under the premise that Windows
was the only OS that mattered.  Sorry.

-- 
Grant Edwards   grant.b.edwardsYow! Maybe I should have
  at   asked for my Neutron Bomb
  gmail.comin PAISLEY --
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 9:44 am, Grant Edwards  wrote:

> > The wrong conclusion is that if Gtk is bad, then WxPython is bad. Gtk
> > is inaccessible under Windows, not under Linux, but WxPython doesn't
> > use Gtk under Windows so WxPython is OK.
>
> Ah.  I didn't realize we were operating under the premise that Windows
> was the only OS that mattered.  Sorry.

Windows IS the only OS that matters WHEN we are talking about "hand
holding". Anyone who uses Unix/Linux and cries about downloading
dependencies is just doing so for sake of discrediting the opposite
position. Only the lemmings would believe such nonsense. Unix/Linux
are NOT hand holding OS's. Thats what windows is for.

And the argument presented earlier (i think Octavian) about how the
majority of accessibility users are using windows is spot on! Anyone
who also denies this fact is just contributing more BS to the "devils
advocates" here. I am not suggesting that accessibility is not
important to a small sub set of Linux users. However the fact is that
the majority of "special needs" folks use windows. And thats a fact!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: printing a list with non-ascii strings

[Benjamin Kaplan]

On Thu, Jan 20, 2011 at 10:43 AM, Helmut Jarausch wrote:

> Hi,
>
> I don't understand Python's behaviour when printing a list.
> The following example uses 2 German non-ascii characters.
>
> #!/usr/bin/python
> # _*_ coding: latin1 _*_
> L=["abc","süß","def"]
> print L[1],L
>
> The output of L[1] is correct, while the output of L shows up as
>  ['abc', 's\xfc\xdf', 'def']
>
> How can this be changed?
>
> Thanks for hint,
> Helmut.
>
>
Use Python 3 if you can. Printing a list calls the repr(). In python 2, that
showed the bytes for non-ascii characters. Python 3 will print the
characters.

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

Re: getdefaultencoding - how to change this?

[Philip Semanchuk]

On Jan 20, 2011, at 10:39 AM, Helmut Jarausch wrote:

> On Thu, 20 Jan 2011 14:31:09 +, Helmut Jarausch wrote:
> 
>> Hi,
>> I've searched the net but didn't find the information I need. Using
>> Python-2.7.1, I know, I can't modify defaultencoding at run time. Python
>> even ignores
>> export PYTHONIOENCODING=ISO8859-1
>> 
>> locale.getdefaultlocale()[1]
>> returns
>> 'ISO8859-1'
>> 
>> still sys.stdout is using the ascii codec. How can I recompile Python
>> (itself) to change this to iso8859-1 ? (My favourite editor cannot be
>> told to use unicode.)
>> 
> 
> Sorry for answering myself. One last trial did succeed.
> My locale as root differed from my locale as non-root user.
> After changing the root locale and recompiling Python, it works now.

I'm glad that worked for you. Alternatively, it seems like you can set the 
default encoding in site.py which sounds easier than recompiling Python.


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

Re: Tkinter: The good, the bad, and the ugly!

[rusi]

On Jan 20, 5:30 pm, Bill Felton 
wrote:
> With some hesitation, I feel a need to jump in here.  

This thread is now at 239 posts (and so I too hesitate...)

The arguments for size, dependencies etc are what may be termed 'sys-
ad' perspectives.
The questions of 'it looks nice/ancient etc' are user issues.

What about some programmer perspective?

Using something like VB-in-.NET allows a programmer to put up
significant uis with close to zero coding.  Many programmers would
look down on these as 'non-programmers'
[I should know: I inhabited a university CS dept for nearly 20 years
where Turing machines and lambda calculus are fashionable and getchar/
putchar programs are more hip than pleasant-looking GUIs.  Many of our
problems stem from the fact that this academic hubris is justified as
objective]

So the (to me) relevant questions relating to GUIs are for example:
1. Is glade (and others such) equal to wxpython, tkinter and other
such 'backends'?
2. Can glade (or whichever is the best such tool today) compare to VB
in .NET or does it look like a bad joke in comparison (I guess the
current thing may not be VB but WPF but I dont want to pretend to know
too much about windows)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: getdefaultencoding - how to change this?

[Robert Kern]

On 1/20/11 8:31 AM, Helmut Jarausch wrote:

Hi,
I've searched the net but didn't find the information I need.
Using Python-2.7.1, I know, I can't modify defaultencoding at run time.


You're not supposed to. It must remain 'ascii'. Otherwise, you will break dict 
lookups among other things. Can you be specific about why you think you want to 
change this? What are you trying to achieve? It looks like you are conflating a 
variety of different behaviors below.



Python even ignores
export PYTHONIOENCODING=ISO8859-1

locale.getdefaultlocale()[1]
returns
'ISO8859-1'


This does not introspect the same thing as sys.getdefaultencoding().


still sys.stdout is using the ascii codec.


This reflects your terminal settings, not sys.getdefaultencoding(). I'm not sure 
why the PYTHONIOENCODING variable isn't affecting that. It works fine for me.



How can I recompile Python (itself) to change this to iso8859-1 ?
(My favourite editor cannot be told to use unicode.)


You wouldn't want to change sys.getdefaultencoding() for this. That parameter 
affects how str and unicode objects are converted between each other without an 
explicit .encode()/.decode() call, not what encoding Python assumes for the 
parsing of the code.


Instead, you want to use an encoding declaration in each file:

http://docs.python.org/reference/lexical_analysis.html#encoding-declarations

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: getdefaultencoding - how to change this?

[Robert Kern]

On 1/20/11 9:47 AM, Philip Semanchuk wrote:


I'm glad that worked for you. Alternatively, it seems like you can set the 
default encoding in site.py which sounds easier than recompiling Python.


Never do that. It breaks dicts and makes your code non-portable.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: collections.Set Binary Reflected Operations

[Chris Kaynor]

Okay, thats what I was looking for, thanks.

In my case, I'll just implement the (needed) reflected operators in my
class.

Chris


On Wed, Jan 19, 2011 at 10:02 PM, Daniel Urban  wrote:

> On Thu, Jan 20, 2011 at 01:51, Chris Kaynor 
> wrote:
> > I am implemented a custom set-like type which interacts with some
> > third-party software when retrieving and mutating the set, and have
> derived
> > my custom type off of collections.MutableSet, however I have noticed that
> > some of the magic methods supported by the built-in set do not fully
> > function with my custom type. From this, I looked over the
> > MutableSet definition in and it seems to be missing all of the reflected
> > operators (__rsub__, __rand__, __ror__, __rxor__, and friends) for the
> > operators it has defined. I can post a simple example case if desired.
> > I am using Python 2.6.4 (with some in-house customizations), however a
> quick
> > look over the svn repository shown on python.org makes it appear that
> these
> > are also not implemented in Python 3. I was wondering if there is some
> > reason for this, or if it was merely an oversight.
> > Chris
>
> See http://bugs.python.org/issue8743 and also
> http://bugs.python.org/issue2226
>
>
> Daniel
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[MRAB]

On 20/01/2011 15:11, rantingrick wrote:

On Jan 20, 6:30 am, Bill Felton
wrote:


[snip]

As one of 'the people' who is presumably the focus of rantingrick's
concern, let me assure him Tkinter is a non-issue. MIchael is more
in touch with my issues than rr.


FYI you are NOT one of the people that is the focus of my concern
because YOU only see the world from a limited viewpoint. And i never
proposed to solve every Python programmers problems. You completely
misunderstand my intentions (along with everyone else!). I  do not
believe in "Utopian dreams". Some people will never be happy with the
state of Python and that is OK. However, the goal is to keep the
majority happy AND keep Python "presentable" and "competitive" for the
next decade. I am sorry you don't fit into any of these categories but
that is your own fault. Why? Because you are not concerned with the
community as a whole. You are only concerned with YOURSELF. You are
displaying both selfishness and ignorance at the same time. We don't
care what selfish people think and we care even less what the ignorant
think. If you decide to become a "team player" then you will be a part
of this community. Lucky for you ignorance and selfishness are
reversible personality traits.


So you're going to lead the "peasants" (your word) whether they like it
or not, and any who don't want to follow are clearly being selfish and
ignorant?

Have you ever thought that if everyone is misunderstanding your
intentions, then perhaps you're doing something wrong?

(BTW, welcome to Pythonia, Bill! Most of us are friendly. :-))
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Bill Felton]

On Jan 20, 2011, at 10:11 AM, rantingrick wrote:

> On Jan 20, 6:30 am, Bill Felton 
> wrote:
> 
>> With some hesitation, I feel a need to jump in here. I'm a complete
>> newbie to Python. I'm still learning the language. And you know
>> what? I've ignored Tkinter.
> 
> Well it is really not a good idea to show your ignorance of a subject
> matter directly before offering your opinion on that same subject
> matter. Most people don't listen to the uninformed. Just FYI. However
> lucky for you i am a fair guy and will give anyone a chance, sometimes
> even two. ;-)
> 

You are too kind. 
Given that the strong implication of your point about 'downfall' was that 
newcomers would somehow be negatively impacted by Tkinter, I would think you 
would welcome input from that part of the audience.

>> I quickly discovered the alternatives and am already working with
>> wxPython.
> 
> But is wxPython the correct alternative for you? What is so bad about
> Tkinter exactly?. Why did you choose to skip it? There must be a
> compelling reason. Why did you go out of your way to download another
> GUI library when one exists in the stdlib? These are all good
> questions that demand answers. So far you've offered opinion and no
> facts. You said you ignored Tkinter but you did not explain why. Now
> would be a good time to inject some facts into your argument.

Ah, ah, ah, not appropriate to the point at hand.
This isn't about me, this is about the absurd claim that the inclusion of 
Tkinter in the Python standard distribution is a 'downfall' point for the 
language.
I think that point has been disabused, although you may well still be sticking 
with it.

[snip]

>> [Sure, *they* can see alternatives and evaluate why Tkinter might not
>> be a good choice under conditions x or y or z, but god forbid anyone
>> new to the language should have to confront those issues or be asked
>> to make such a decision. How could we trust those lowly newbies to
>> think *properly* about the issue!
> 
> We can't. Are you actually suggestion that someone with NO experience
> with ANY of the GUI library available somehow has a better insight
> into choosing the best GUI library than someone who (i don't know)
> ACTUALLY HAS USED ALL OF THEM!

Ahs, I see, you have been infected by "the best bug". There is no such thing as 
'the best' anything absent the standard that is used to judge.  And multiple 
standards apply.

> Who's sock puppet are you Bill? Really.
> And if you are not a sock puppet i HOPE you are just trolling because
> this is a bombastic display of ignorance!.

rantingrick, meet mirror, mirror, meet rantingrick.

I can't say I'm surprised to see this kind of response from you, this leap from 
my post to the assumption that I know nothing about programming or about GUIs.
FWIW, I have 20+ years of experience with Smalltalk and am well aware of GUI 
issues and the manifold ways in which they must be approached and judged.
Your little 'one size must fit all" attitude is what will be the downfall of 
Python, or any other language infected with it.  We saw that with Smalltalk and 
its community, we see it everywhere.

[snip]

> 
> Yes, and you just hit the nail on the the head! Why leave the stdlib
> full of cruft (Tkinter)?

At least two reasons, one big one, one little one.
The little one:  because TKinter provides the base for such things as IDLE, 
which are a genuine boon to the newcomer.
The big one:  because you have somehow failed to demonstrate that Tkiinter is 
cruft.  You've demonstrated you don't like it, you've asserted, at great length 
and in a wide variety of ways and countless posts, that it is cruft, but 
somehow the proof remains absent.  Yet you whine about others not providing 
'FACTS'. 
Why should anyone listen to you on this matter, most especially when you labor 
under the tedious delusion that there is such a thing as 'the best GUI' without 
constraint.
Of course, you could always produce one...

> 
>> As one of 'the people' who is presumably the focus of rantingrick's
>> concern, let me assure him Tkinter is a non-issue. MIchael is more
>> in touch with my issues than rr.
> 
> FYI you are NOT one of the people that is the focus of my concern
> because YOU only see the world from a limited viewpoint.

EVERYONE sees the world from a limited viewpoint.  Most of us realize this, and 
find those of you who don't at least faintly annoying.



cheers,
Bill

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

Re: Tkinter: The good, the bad, and the ugly!

[Bill Felton]

On Jan 20, 2011, at 12:13 PM, MRAB wrote:

> On 20/01/2011 15:11, rantingrick wrote:
>> On Jan 20, 6:30 am, Bill Felton
>> wrote:
>> 
> [snip]
>>> As one of 'the people' who is presumably the focus of rantingrick's
>>> concern, let me assure him Tkinter is a non-issue. MIchael is more
>>> in touch with my issues than rr.
>> 
>> FYI you are NOT one of the people that is the focus of my concern
>> because YOU only see the world from a limited viewpoint. And i never
>> proposed to solve every Python programmers problems. You completely
>> misunderstand my intentions (along with everyone else!). I  do not
>> believe in "Utopian dreams". Some people will never be happy with the
>> state of Python and that is OK. However, the goal is to keep the
>> majority happy AND keep Python "presentable" and "competitive" for the
>> next decade. I am sorry you don't fit into any of these categories but
>> that is your own fault. Why? Because you are not concerned with the
>> community as a whole. You are only concerned with YOURSELF. You are
>> displaying both selfishness and ignorance at the same time. We don't
>> care what selfish people think and we care even less what the ignorant
>> think. If you decide to become a "team player" then you will be a part
>> of this community. Lucky for you ignorance and selfishness are
>> reversible personality traits.
>> 
> So you're going to lead the "peasants" (your word) whether they like it
> or not, and any who don't want to follow are clearly being selfish and
> ignorant?
> 
> Have you ever thought that if everyone is misunderstanding your
> intentions, then perhaps you're doing something wrong?
> 
> (BTW, welcome to Pythonia, Bill! Most of us are friendly. :-))\

Thanks!
And yes, I had noticed that in general this is a congenial, thoughtful, and 
helpful community.  While a lot of what is discussed is not of particular 
interest to me, there's been a lot that has been of interest and/or of value.  
So far, I'm pretty impressed with the language as well as the community.  And 
it's wonderful to be involved with a language that has such voluminous 
supporting materials of all sorts.  [I self-taught Smalltalk back in the early 
and mid-80's when there were 3 books and that's about it...]
Hopefully I'll be able to contribute code, learning materials, or such like, at 
some point ;-)

cheers,
Bill

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

Re: getdefaultencoding - how to change this?

[Helmut Jarausch]

On Thu, 20 Jan 2011 10:46:37 -0600, Robert Kern wrote:

> On 1/20/11 8:31 AM, Helmut Jarausch wrote:
>> Hi,
>> I've searched the net but didn't find the information I need. Using
>> Python-2.7.1, I know, I can't modify defaultencoding at run time.
> 
> You're not supposed to. It must remain 'ascii'. Otherwise, you will
> break dict lookups among other things. Can you be specific about why you
> think you want to change this? What are you trying to achieve? It looks
> like you are conflating a variety of different behaviors below.
> 
>> Python even ignores
>> export PYTHONIOENCODING=ISO8859-1
>>
>> locale.getdefaultlocale()[1]
>> returns
>> 'ISO8859-1'
> 
> This does not introspect the same thing as sys.getdefaultencoding().
> 
>> still sys.stdout is using the ascii codec.
> 
> This reflects your terminal settings, not sys.getdefaultencoding(). I'm
> not sure why the PYTHONIOENCODING variable isn't affecting that. It
> works fine for me.
> 
>> How can I recompile Python (itself) to change this to iso8859-1 ? (My
>> favourite editor cannot be told to use unicode.)
> 
> You wouldn't want to change sys.getdefaultencoding() for this. That
> parameter affects how str and unicode objects are converted between each
> other without an explicit .encode()/.decode() call, not what encoding
> Python assumes for the parsing of the code.
> 
> Instead, you want to use an encoding declaration in each file:
> 
> http://docs.python.org/reference/lexical_analysis.html#encoding-
declarations

Thanks Robert,
probably I wasn't too clear about my issue.
I couldn't "print" any non-ascii character to my console although
my console has an en_US.iso88591 locale.

I didn't modfiy anything in Python's source code.
I noticed that my root account still had an ASCII locale.
Now I have changed it such that the root account has the same locale
as non-root accounts. Recompiling Python under such a root account
has rectified things. Now I can print non-ascii characters if they are
properly encoded.

Thanks,
Helmut.




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

Re: Part of RFC 822 ignored by email module

[Carl Banks]

On Jan 20, 7:08 am, Bob Kline  wrote:
> I just noticed that the following passage in RFC 822:
>
>          The process of moving  from  this  folded   multiple-line
>          representation  of a header field to its single line represen-
>          tation is called "unfolding".  Unfolding  is  accomplished  by
>          regarding   CRLF   immediately  followed  by  a  LWSP-char  as
>          equivalent to the LWSP-char.
>
> is not being honored by the email module.  The following two invocations
> of message_from_string() should return the same value, but that's not
> what happens:
>
>  >>> import email
>  >>> email.message_from_string("Subject: blah").get('SUBJECT')
> 'blah'
>  >>> email.message_from_string("Subject:\n blah").get('SUBJECT')
> ' blah'
>
> Note the space in front of the second value returned, but missing from
> the first.  Can someone convince me that this is not a bug?

That's correct, according to my reading of RFC 822 (I doubt it's
changed so I didn't bother to look up what the latest RFC on that
subject is.)

The RFC says that in a folded line the whitespace on the following
line is considered a part of the line.  Relevant quite (section
3.1.1):


Each header field can be viewed as a single, logical  line  of
ASCII  characters,  comprising  a field-name and a field-body.
For convenience, the field-body  portion  of  this  conceptual
entity  can be split into a multiple-line representation; this
is called "folding".  The general rule is that wherever  there
may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead  be
inserted.  Thus, the single line

To:  "Joe & J. Harvey" , JJV @ BBN

can be represented as:

To:  "Joe & J. Harvey" ,
JJV@BBN

and

To:  "Joe & J. Harvey"
, JJV
 @BBN

and

To:  "Joe &
 J. Harvey" , JJV @ BBN

 The process of moving  from  this  folded   multiple-line
representation  of a header field to its single line represen-
tation is called "unfolding".  Unfolding  is  accomplished  by
regarding   CRLF   immediately  followed  by  a  LWSP-char  as
equivalent to the LWSP-char.


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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 10:36 am, rusi  wrote:
> On Jan 20, 5:30 pm, Bill Felton 

> > With some hesitation, I feel a need to jump in here.  
> This thread is now at 239 posts (and so I too hesitate...)

Why hesitate? Whether it be one post or a million posts, if you have
ideas, opinions, or suggestions then by all means jump in and share
them. If your words are FUD, not based on fact, or just completely
ignorant, don't worry, someone will correct you :-)

> The arguments for size, dependencies etc are what may be termed
> 'sys-ad' perspectives. The questions of 'it looks nice/ancient etc'
> are user issues. What about some programmer perspective?

Size is very important. Dependencies are very important (within
context!). So too are aesthetics just as important when considering a
"graphics" module. In the end, Python should aim to bring the best
looking, most advanced (but well tested!), scalable modules we can
muster into the stdlib. At the time of it's inclusion Guido believed
Tkinter was the best choice -- and i agree with him! However we are
talking now about ~20 years of time between then and now. Is anyone so
bombastic as to suggest that GUI has not changed significantly in that
time. And likewise, is anyone so bombastic as to suggest that the
lowly Tkinter module (and even worse TclTk) is representative of 21st
century GUI programming?  Heck, when Tkinter was added GUIs where just
in their infancy as far as popular adoption is concerned! TclTk have
lacked vision from the beginning. NEWSFLASH! They did not support
themes until version 8.5! (~2009) And they still have much work to do
if they ever want to compete with the likes of wxPython however i know
thay will never reach that level of sophistication. TclTk as a
community are not concerned about keeping up with he times, so be it!
However we should not degrade "our" stdlib and "our" community with
such backward thinking communities. We must move forward. We must pull
our heads out of the sand or mentality will be our undoing.


> Using something like VB-in-.NET allows a programmer to put up
> significant uis with close to zero coding. Many programmers would
> look down on these as 'non-programmers'

Well i don't look down on these folks i just feel they are missing out
on the richness and abstract thinking that creating the GUI mentally
evokes. However. I believe it would be of great benefit to have a
graphical GUI builder as part of any GUI package we consider for the
stdlib. Do i think it should be IN the stdlib? Probably not due to
size. But the fact that it is available for those who would like it to
be is great. My biggest complaint with Tkinter is that it lacks so
much functionality (even outside the stdlib!) that you really end up
wasting your time learning and using it. Because eventually you will
be forced to throw away everything you've learned and written and
convert to something else.


> So the (to me) relevant questions relating to GUIs are for example:
> 1. Is glade (and others such) equal to wxpython, tkinter and other
> such 'backends'? 2. Can glade (or whichever is the best such tool
> today) compare to VB in .NET or does it look like a bad joke in
> comparison (I guess the current thing may not be VB but WPF but I
> dont want to pretend to know too much about windows)

I think we need to add a graphical GUI builder to the list of
important attributes of a 21st century GUI library. Not the most
important, but still quite important. Especially if we want to
"market" Python as a GUI language. And I am not saying we should
market Python that way.

So the attributes we must demand of a 21st century GUI library are a
follows:

 * Quality Documentation (our problem really)
 * Cross Platform (their problem)
 * Rich Full Featured Widget Set. (their problem)
 * Simplistic API (our problem)
 * Scalability (their problem)
 * Accessibility (their problem)
 * Graphical GUI Builder. (Either or)

Also some attributes related to the "Big Picture" of GUI and Python:

 * Mobile and Web support
-- 
http://mail.python.org/mailman/listinfo/python-list

statement level resumable exception

[ilejn]

Hello!

I have a sequence of a function calls. Basically it looks like

f(arg1)
f(arg2)
...
f(argN)

though real arguments are complex multilayer lists.

The problem is some arguments are not known and I get NameError
exceptions.

The solutions I know
1. wrap every f call in try/except block
2. make (currently global) argument attributes of a class and use
__getattr__ to convert unknown attributes to something recognizable by
f.


Is it possible to use something more elegant?
I had a hope decorators are helpful here, though apparently they are
not ...
Suggestions?

Thanks.

PS. The question is about Python 2.4
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 20, 10:44 am, "Octavian Rasnita"  wrote:
> From: "Adam Skutt" 
> Actually, JAWS uses MSAA dead last, as I understand it, because the
> API is truly that awful.  But MSAA is necessary whenever you're not
> using a Win32 common control or most of the other stuff developed by
> MS.  That means essentially every non-MS toolkit that's been
> discussed.
>
> Yes, but WxPython uses wxWIDGETS and wxWIDGETS use the standard Win32 
> controls under Windows, so they are accessible.
> And they use Gtk under Linux and Gtk is accessible under Linux also.

wxGTK is not, though.  wxWidgets is only accessible under Windows.  Qt
is accessible under Windwos, OS X, and anything that supports AT-
SPI[1].  Yet, for some unfathomable reason, you keep promoting
wxWidgets even though it is plainly the inferior solution.

> Yes of course they can do that if they use the wrong tool. They can't do the 
> right thing if they believe that Tk or Silverlight or Flash is accessible no 
> matter if they follow the recommendations for accessibility, because the 
> screen readers don't support those interfaces.

No, even using the right tools: 
http://doc.qt.nokia.com/qq/qq24-accessibility.html#dealingwithquirks
(a few years old, but AFAIK still relevant).  It's a crap shoot even
if I use tools that support accessibility, because the APIs aren't
very good.  Some of the new APIs improve the problem, but some reading
suggests there will still be the need for a lot of special case
handling on both sides of the table.

> Nope, the cultural problem exists because the programmers use the wrong 
> interface, not because they just don't make the efforts for making that 
> interface more accessible.

No, they don't think about it, they don't test, they don't make the
necessary calls to enable accessible applications.  Plenty of
applications with poor to non-existent accessibility support are
written with toolkits that support accessibility.

> To be more clear and not to include in the discussion many interfaces, we are 
> comparing Tkinter and WxPython.

No, we're not comparing just them, because they're hardly the only
solutions.

> I am not excluding anything. I said that all the Tk-based programs are 
> inaccessible no matter what the programmer does to make it accessible, 
> because the screen readers can't work with that interface.
> And I have also said which are the accessible interfaces: wxWIDGETS (which 
> use Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does 
> exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the 
> user installs Java Access Bridge).

This is not a complete list, or even a correct list, which was my
point.

> It depends if there is a JAWS script defined.

Stop. You've insisted many times that I need to not do anything
special for making accessible applications.  Yet, JAWS has an API
entirely for the purpose of enhancing accessibility for specific
applications!  So, which is it?  If I don't need to do anything
special, then why does the API exist?  Oh right, it exists so people
can compensate for developers shortcomings.

It's very hard to take anything you say seriously when you repeatedly
get basic facts wrong and when you make claims that aren't consistent
with the facts.

> If the user doesn't want or don't know how to create that script for 
> improving the usability, he/she might need to learn how to use the 
> application by trial and error, but what I want to show is that the user is 
> *able* to use that application, even if the interface is not very friendly, 
> but it would be absolutely impossible to use an application created with 
> Tkinter.

He / she might be able to use the application.  It's a "maybe", not a
"for sure", yet you consistently imply it's the latter.

> I am not talking about custom controls. Those things are the worst thing 
> possible from the perspective of accessibility, because usually nobody cares 
> about providing accessibility features.

Yet I was talking about custom controls, and plenty of applications
use custom controls, so you cannot ignore them even if you'd wish to
do so.

> My point was that Tkinter which uses Tk is bad, and I didn't tried too many 
> QT-based applications.

No, you explicitly stated that Qt has zero accessibility support,
which is simply false.  You didn't say, "The ones I tried haven't
worked", which is certainly possible depending on version and how Qt
was compiled (since Qt is normally shipped with the application on
Windows).  You said, "But the interfaces created with Tk, Gtk and QT
are completely inaccessible."

> And I don't see what you demonstrate when you wanted to show Tkinter it is 
> comparing with WxPython...

I never said I was going to demonstrate anything between Tkinter and
wxPython.  Such a demonstrate is in your imagination.

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

Re: getdefaultencoding - how to change this?

[Philip Semanchuk]

On Jan 20, 2011, at 11:47 AM, Robert Kern wrote:

> On 1/20/11 9:47 AM, Philip Semanchuk wrote:
> 
>> I'm glad that worked for you. Alternatively, it seems like you can set the 
>> default encoding in site.py which sounds easier than recompiling Python.
> 
> Never do that. It breaks dicts and makes your code non-portable.

I've never been tempted for the very non-portability reason you cite. I didn't 
know that it would break dicts, though. Thanks for the education.

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 11:13 am, MRAB  wrote:

> So you're going to lead the "peasants" (your word) whether they like it
> or not, and any who don't want to follow are clearly being selfish and
> ignorant?

If you could read Bill's words and not find them to be overly selfish
and ignorant then i don't know what to say. He clearly stated many
times that he NEVER used Tkinter. However somehow we are to believe
that he has some "magical" insight on the merits (or lack there of) of
Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
defined as the lack of knowledge. Bill has presented just that.

However, even in light of such bombastic ignorance and selfish display
I in good humility and grace offered Bill advice on how he could
present more facts instead of just baseless opinion. I asked him very
specific questions THAT IF he would answer MIGHT inject some facts
into his baseless argument. However I bet we won't get any answers
from him.

PS: You never cease to amaze me MRAB.
-- 
http://mail.python.org/mailman/listinfo/python-list

Os designers are morons

[David Hutto]

Forgive me for the listening 'troll perspective', but is there any
simple solution to intertwining proprietary and open source
mentalities? Common ground seems to be the hardware offerings. So why
does it seem that the summit has lost it's common ground, which is the
hardware we operate on? Electricians know more about multiple
applications of energy affecting different sources than most
programmers here with there allocation and deallocation of a space on
the 'board'. Spatial concepts aren't that hard, and neither is the
allocation/deallocation concepts in spatial analysis. So, quit
arguing, and get to what you know.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Bill Felton]

On Jan 20, 2011, at 8:26 AM, Octavian Rasnita wrote:

> From: "Bill Felton" 
>> I'm a complete newbie to Python.
> 
> 
> To Python, or to programming in general? (Because it is important)

Not to rantingrick's point as I understand it.
But since you ask, new to Python, not new to programming.  >25 yrs experience, 
most of it with Smalltalk.

> 
> 
>> I'm still learning the language.  And you know what?  I've ignored Tkinter.
> 
> 
> Why did you do that?

2 main reasons -- it hasn't come up yet, and I was attracted to wxPython by the 
promise of host-compatible look&feel, and the plethora of resources available 
for self-study in my preferred modes.

> 
> 
>> I quickly discovered the alternatives and am already working with wxPython.
>> I can't believe anyone is so hung up by their own arrogance that they 
>> honestly believe that the mere *presence* of a gui kit inside of the 
>> standard distribution would prevent a newbie from learning about the 
>> existence and possible benefits of alternatives.  Sure, *they* can see 
>> alternatives and evaluate why Tkinter might not be a good choice under 
>> conditions x or y or z,
> 
> 
> Nobody said that the fact that Python promotes Tkinter *prevents" the 
> beginners to learn to use another GUI.

It's an iunavoidable implication of rantingrick's rant about Tkinter and the 
downfall of Python.
I would like to agree that only a deranged minority hold that Tkinter is either 
a 'downfall point' or prevents individuals from learning and using alternative 
GUIs.

> I just say that if Python promotes Tkinter, the beginners that might not have 
> experience programming in other languages might not know at all which is the 
> difference between all those GUI types, and it might not know at all that 
> there are more GUI types and it won't know for sure which are the differences 
> between them.

I agree.
> 
> And for a real beginner in programming it could be harder and less important 
> to make the effort of finding and downloading and installing another GUI just 
> because it offer some features which are not interesting for most users, so 
> he/she will prefer using what Python offers and he/she won't know that that 
> solution is bad.

I tend to agree, but weakly.  Python is touted for it's vast library support, 
and that library is pretty much "in your face" if you use the web to look for 
the language and resources on the language.  I have a lot of trouble believing 
that anyone smart enough to program [i.e., smart enough to tie their own shoes, 
basically] would not find and investigate those resources.
Mind you, I think more focus on Tkinter in the learning  materials would be a 
nice thing to have.  Although bear in mind I may have a skewed view of what 
counts as good introductions to GUI toolkits given my early and long exposure 
to Smalltalk...  Where's Python's toothpaste, sketchpad, etc?

cheers,
Bill

PS.  Still not used to a mailing list that sets the 'reply to' to the author, 
not the list, so inadvertently sent this only to Octavian.  Rectified herewith, 
along with a promise to pay more attention ;-)-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Part of RFC 822 ignored by email module

[Bob Kline]

On 1/20/2011 12:23 PM, Carl Banks wrote:

On Jan 20, 7:08 am, Bob Kline  wrote:

I just noticed that the following passage in RFC 822:

  The process of moving  from  this  folded   multiple-line
  representation  of a header field to its single line represen-
  tation is called "unfolding".  Unfolding  is  accomplished  by
  regarding   CRLF   immediately  followed  by  a  LWSP-char  as
  equivalent to the LWSP-char.

is not being honored by the email module.  The following two invocations
of message_from_string() should return the same value, but that's not
what happens:

  >>>  import email
  >>>  email.message_from_string("Subject: blah").get('SUBJECT')
'blah'
  >>>  email.message_from_string("Subject:\n blah").get('SUBJECT')
' blah'

Note the space in front of the second value returned, but missing from
the first.  Can someone convince me that this is not a bug?

That's correct, according to my reading of RFC 822 (I doubt it's
changed so I didn't bother to look up what the latest RFC on that
subject is.)

The RFC says that in a folded line the whitespace on the following
line is considered a part of the line.


Thanks for responding.  I think your interpretation of the RFC is the 
same is mine.  What I'm saying is that by not returning the same value 
in the two cases above the module is not "regarding CRLF immediately 
followed by a LWSP-char as equivalent to the LWSP-char."


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

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

Re: Tkinter: The good, the bad, and the ugly!

[MRAB]

On 20/01/2011 17:36, rantingrick wrote:

On Jan 20, 11:13 am, MRAB  wrote:


So you're going to lead the "peasants" (your word) whether they like it
or not, and any who don't want to follow are clearly being selfish and
ignorant?


If you could read Bill's words and not find them to be overly selfish
and ignorant then i don't know what to say. He clearly stated many
times that he NEVER used Tkinter. However somehow we are to believe
that he has some "magical" insight on the merits (or lack there of) of
Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
defined as the lack of knowledge. Bill has presented just that.

However, even in light of such bombastic ignorance and selfish display
I in good humility and grace offered Bill advice on how he could
present more facts instead of just baseless opinion. I asked him very
specific questions THAT IF he would answer MIGHT inject some facts
into his baseless argument. However I bet we won't get any answers
from him.

PS: You never cease to amaze me MRAB.


The feeling is mutual.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Nick Stinemates]

>
>
> > So you're going to lead the "peasants" (your word) whether they like it
> > or not, and any who don't want to follow are clearly being selfish and
> > ignorant?
>
> If you could read Bill's words and not find them to be overly selfish
> and ignorant then i don't know what to say. He clearly stated many
> times that he NEVER used Tkinter. However somehow we are to believe
> that he has some "magical" insight on the merits (or lack there of) of
> Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
> defined as the lack of knowledge. Bill has presented just that.
>

No, he's refuting your point that newbies are somehow paralyzed and cannot
make a decision about which toolkit they would like to use.


>
> PS: You never cease to amaze me MRAB.
>

I am also amazed.

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

Re: Tkinter: The good, the bad, and the ugly!

[Emile van Sebille]

On 1/20/2011 9:32 AM Adam Skutt said...

On Jan 20, 10:44 am, "Octavian Rasnita"  wrote:

From: "Adam Skutt"
Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful.  But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS.  That means essentially every non-MS toolkit that's been
discussed.

Yes, but WxPython uses wxWIDGETS and wxWIDGETS use the standard Win32 controls 
under Windows, so they are accessible.
And they use Gtk under Linux and Gtk is accessible under Linux also.


wxGTK is not, though.  wxWidgets is only accessible under Windows.  Qt
is accessible under Windwos, OS X, and anything that supports AT-
SPI[1].  Yet, for some unfathomable reason, you keep promoting
wxWidgets even though it is plainly the inferior solution.




The problem with QT is the license.

From http://qt.nokia.com/products/licensing/:

Qt Commercial Developer License
The Qt Commercial Developer License is the correct license to use for 
the development of proprietary and/or commercial software with Qt where 
you do not want to share any source code.


You must purchase a Qt Commercial Developer License from us or from one 
of our authorized resellers before you start developing commercial 
software as you are not permitted to begin your development with an open 
source licensed Qt version and convert to the commercially license 
version at a later . The Qt Commercial Developer License includes a 
restriction that prevents the combining of code developed with the Qt 
GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions with commercially 
licensed Qt code.


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

Re: Part of RFC 822 ignored by email module

[Bob Kline]

On 1/20/2011 12:58 PM, Dennis Lee Bieber wrote:


I'd first be concerned about the absence of the line ending sequence
specified by the RFC: carriage return (CR; \r) followed by line feed
(LF; \n).


I realized after I posted the original message that this might distract 
from the issue I'm asking about.  The module is a little sloppy about 
its own generation of CRLF tokens when it serializes messages (it leaves 
the insertion of the CR to processing further downstream), and I was 
mimicking that behavior in what I fed to the method in my example.  I 
should have avoided that problem and included the \r.  Let's pretend 
that I did: the behavior is unaffected by the absence or presence of the 
CR character.



...

However, the module does appear to trim leading whitespace that
occurs between the : and text (and the line end is considered for that
trimming, but not any whitespace after it).


Exactly.  I'm focusing on the word "equivalent" in the RFC.  Either the 
module is going to strip leading white space from the value or it's 
not.  Returning different values for the unwrapped header, depending on 
whether wrapping was present, is failing to treat the two sequences as 
equivalent.  Logically, the processing sequence should be:


  1. Unwrap the header ("Subject:\r\n foo" becomes "Subject: foo")
  2. Trim leading white space (" foo" becomes "foo")

Ideally, the behavior of trimming the leading white space would be 
reflected documentation (but it isn't).


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

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

Re: printing a list with non-ascii strings

[Peter Otten]

Helmut Jarausch wrote:

> I don't understand Python's behaviour when printing a list.
> The following example uses 2 German non-ascii characters.
> 
> #!/usr/bin/python
> # _*_ coding: latin1 _*_
> L=["abc","süß","def"]
> print L[1],L
> 
> The output of L[1] is correct, while the output of L shows up as
>  ['abc', 's\xfc\xdf', 'def']
> 
> How can this be changed?

Use unicode and follow Martin's recipe:

http://mail.python.org/pipermail/python-list/2011-January/1263783.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Bill Felton]

On Jan 20, 2011, at 1:15 PM, Nick Stinemates wrote:

> 
> > So you're going to lead the "peasants" (your word) whether they like it
> > or not, and any who don't want to follow are clearly being selfish and
> > ignorant?
> 
> If you could read Bill's words and not find them to be overly selfish
> and ignorant then i don't know what to say. He clearly stated many
> times that he NEVER used Tkinter. However somehow we are to believe
> that he has some "magical" insight on the merits (or lack there of) of
> Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
> defined as the lack of knowledge. Bill has presented just that.
> 
> No, he's refuting your point that newbies are somehow paralyzed and cannot 
> make a decision about which toolkit they would like to use. 
> 

Precisely.  I neither said nor intended the nonsense that somehow rr reads into 
my post.  Geez, he can't even count -- I believe I said once that I haven't 
used Tkinter.  But even twice or thrice would not warrant 'many times'...
Well, he does appear to be an output only device, who still hasn't output the 
canonical 'best' GUI toolset...
My point was not that Tkinter obviates all other gui toolkits, only that it 
doesn't need to be ripped out of the standard distro because it is not the 
cause of the heinous results that rr fears and never hesitates to impute to it.

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

Re: statement level resumable exception

[Chris Rebert]

On Thu, Jan 20, 2011 at 9:32 AM, ilejn  wrote:
> Hello!
>
> I have a sequence of a function calls. Basically it looks like
>
> f(arg1)
> f(arg2)
> ...
> f(argN)
>
> though real arguments are complex multilayer lists.
>
> The problem is some arguments are not known and I get NameError
> exceptions.

Why aren't they known? It's a very bad code smell to have possibly
completely-undefined variables.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: getdefaultencoding - how to change this?

[Antoine Pitrou]

On 20 Jan 2011 17:20:14 GMT
Helmut Jarausch  wrote:
> Thanks Robert,
> probably I wasn't too clear about my issue.
> I couldn't "print" any non-ascii character to my console although
> my console has an en_US.iso88591 locale.

Well, if you want a correct answer, you should paste actual code as
well as its result on your system, rather than start by asking how to
change getdefaultencoding (which you shouldn't do as explained by
others).

> I didn't modfiy anything in Python's source code.
> I noticed that my root account still had an ASCII locale.
> Now I have changed it such that the root account has the same locale
> as non-root accounts. Recompiling Python under such a root account
> has rectified things.

Recompiling Python doesn't change its behaviour wrt. locales and
encodings. All this is done at runtime.

> Now I can print non-ascii characters if they are
> properly encoded.

You can *always* print characters if they are properly encoded. What
you are asking is for Python to guess and do the encoding by itself,
which is a different matter (and a poorly supported one under 2.x;
Python 3 behaves much better in that regard).

Regards

Antoine.


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

Re: Efficient python 2-d arrays?

[Jake Biesinger]

> Thanks for the great suggestions!

On a related note, is there no way to efficiently sort a python array?


>>> x = array('f', xrange(1000))
>>> x.sort()
---
AttributeErrorTraceback (most recent call last)

/home/wbiesing/src/python-sort/ in ()

AttributeError: 'array.array' object has no attribute 'sort'

>>> type(sorted(x))


Seems like a common enough task, but no way to do it efficiently without 
scipy/numpy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: statement level resumable exception

[ilejn]

Chris,

this is a long story why arguments may be not known.
Briefly these arguments come (or may come) from XML and may be not
specified.

A function call which does not have all arguments defined must be
skipped as gracefully as possible.
What I am asking about is how to achieve this goal.

Thanks.


On Jan 20, 9:58 pm, Chris Rebert  wrote:
> On Thu, Jan 20, 2011 at 9:32 AM, ilejn  wrote:
> > Hello!
>
> > I have a sequence of a function calls. Basically it looks like
>
> > f(arg1)

> Why aren't they known? It's a very bad code smell to have possibly
> completely-undefined variables.
>
> Cheers,
> Chris
> --http://blog.rebertia.com

Best regards,
Ilja Golshtein.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: printing a list with non-ascii strings

[Arnaud Delobelle]

Helmut Jarausch  writes:

> Hi,
>
> I don't understand Python's behaviour when printing a list.
> The following example uses 2 German non-ascii characters.
>
> #!/usr/bin/python
> # _*_ coding: latin1 _*_
> L=["abc","süß","def"]
> print L[1],L
>
> The output of L[1] is correct, while the output of L shows up as
>  ['abc', 's\xfc\xdf', 'def']
>
> How can this be changed?
>
> Thanks for hint,
> Helmut.

That's because when you print a list, the code executed is roughly:

print "[" + ", ".join(repr(x) for x in L) + "]"

Now try:

print repr("süß")

I don't think this can be changed in Python 2.X.  I vaguely remember
discussions about this issue for Python 3 I think, but I can't remember
the outcome and it is different anyway as Python 3 strings are not the
same as Python 2 strings (they are the same as Python 2 unicode strings).

The issue though is that the python interpreter doesn't know what
encoding is supposed to be used for a string - a string in Python 2.X is
a sequence of bytes. If you print the string, then the terminal encodes
the bytes according to its settings, which has nothing to do with python
- so the appearance will differ according to the locale configuration of
the terminal.  However, the repr() of a string needs to be consistent
irrespective of the configuration of the terminal - so the only viable
option is to use nothing but ASCII characters.  Hence the difference.

HTH

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

Re: statement level resumable exception

[Arnaud Delobelle]

ilejn  writes:

> Hello!
>
> I have a sequence of a function calls. Basically it looks like
>
> f(arg1)
> f(arg2)
> ...
> f(argN)
>
> though real arguments are complex multilayer lists.
>
> The problem is some arguments are not known and I get NameError
> exceptions.
>
> The solutions I know
> 1. wrap every f call in try/except block
> 2. make (currently global) argument attributes of a class and use
> __getattr__ to convert unknown attributes to something recognizable by
> f.

for name in 'arg1', 'arg2', ... 'argN':
try:
arg = globals()[name]
except NameError:
continue
f(arg)

But this is a strange problem...  Sounds like you should do it
differently.

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

Re: Efficient python 2-d arrays?

[Robert Kern]

On 1/20/11 1:36 PM, Jake Biesinger wrote:

Thanks for the great suggestions!


On a related note, is there no way to efficiently sort a python array?


No.


x = array('f', xrange(1000))
x.sort()

---
AttributeErrorTraceback (most recent call last)

/home/wbiesing/src/python-sort/  in()

AttributeError: 'array.array' object has no attribute 'sort'


type(sorted(x))



Seems like a common enough task, but no way to do it efficiently without 
scipy/numpy.


It's not really common. The array module is mostly used for data accumulation 
and interchange. Most people who need to compute things over 
efficiently-implemented homogeneous arrays use numpy.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 12:17 pm, Emile van Sebille  wrote:

> The problem with QT is the license.
>
>  Fromhttp://qt.nokia.com/products/licensing/:
>
> Qt Commercial Developer License
> The Qt Commercial Developer License is the correct license to use for
> the development of proprietary and/or commercial software with Qt where
> you do not want to share any source code.

Well as far as i am concerned that takes QT out of the contest. So
that leaves WxPython and pyGTK as the only viable options that are
mature libraries. Both carry the LGPL license.

  http://www.pygtk.org/
  http://www.wxwidgets.org/about/newlicen.htm

One more is FLTK however it looks like a mirror of Tkinter so back in
the same place:

  http://pyfltk.sourceforge.net/index.php#download

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Grant Edwards" 
 WxPython is bad. Gtk
>> is inaccessible under Windows, not under Linux, but WxPython doesn't
>> use Gtk under Windows so WxPython is OK.
> 
> Ah.  I didn't realize we were operating under the premise that Windows
> was the only OS that mattered.  Sorry.

This conclusion is hatefully because you have already read that Gtk is 
accessible under Linux, so WxPython doesn't offer accessibility only for 
Windows.
>From the perspective of most of those who need accessibility however, yes, 
>Windows is most important.

Octavian


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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
> Yet, for some unfathomable reason, you keep promoting
wxWidgets even though it is plainly the inferior solution.


Inferior to what?

I would be glad if you could tell me about a portable solution which is 
accessible with JAWS and Window Eyes, the most used screen readers under 
Windows (real glad).


> Yes of course they can do that if they use the wrong tool. They can't do the 
> right thing if they believe that Tk or Silverlight or Flash is accessible no 
> matter if they follow the recommendations for accessibility, because the 
> screen readers don't support those interfaces.

No, even using the right tools: 
http://doc.qt.nokia.com/qq/qq24-accessibility.html#dealingwithquirks
(a few years old, but AFAIK still relevant).  It's a crap shoot even
if I use tools that support accessibility, because the APIs aren't
very good.  Some of the new APIs improve the problem, but some reading
suggests there will still be the need for a lot of special case
handling on both sides of the table.


Exactly. When you will read that thing on a GUI creator site it means that that 
GUI is not accessible because the screen readers don't support it yet. The GUI 
libs manufacturers will say that the screen readers are bad because they don't 
offer support for their GUI, although that GUI offers accessibility features.
Well, I don't care that the screen readers are bad and don't support some libs. 
I care only if the interfaces created with a certain GUI lib is accessible out 
of the box as WxPython is under Windows.

> Nope, the cultural problem exists because the programmers use the wrong 
> interface, not because they just don't make the efforts for making that 
> interface more accessible.

No, they don't think about it, they don't test, they don't make the
necessary calls to enable accessible applications.  Plenty of
applications with poor to non-existent accessibility support are
written with toolkits that support accessibility.

You confuse again the accessibility with the usability or you think that if a 
GUI lib offers accessibility features it is accessible. Well, a GUI lib is 
accessible only if JAWS and Window Eyes offer support for it because those are 
the screen readers used by the majority and this is because they have the most 
features.

> To be more clear and not to include in the discussion many interfaces, we are 
> comparing Tkinter and WxPython.

No, we're not comparing just them, because they're hardly the only
solutions.

We were starting from the idea that Tkinter is worse than WxPython so let's 
come to that idea and not divagate.

> I am not excluding anything. I said that all the Tk-based programs are 
> inaccessible no matter what the programmer does to make it accessible, 
> because the screen readers can't work with that interface.
> And I have also said which are the accessible interfaces: wxWIDGETS (which 
> use Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does 
> exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the 
> user installs Java Access Bridge).

This is not a complete list, or even a correct list, which was my
point.

My point was that Tkinter shouldn't be promoted by Python because it doesn't 
create accessible GUI out of the box at least for Windows as WxPython does.

> It depends if there is a JAWS script defined.

Stop. You've insisted many times that I need to not do anything
special for making accessible applications.  Yet, JAWS has an API
entirely for the purpose of enhancing accessibility for specific
applications!  So, which is it?  If I don't need to do anything
special, then why does the API exist?  Oh right, it exists so people
can compensate for developers shortcomings.

I've told you a lot of times that you confuse accessibility with usability. And 
I told you that the JAWS scripts can't make an absolutely inaccessible 
application made with Tk to be accessible.
And that's why Tkinter is bad.
The JAWS scripts can only improve the usability, can make the application be 
much friendly, but if it is not accessible, it can't make it accessible, 
because if it could do it, there would be no accessibility issues anymore.


It's very hard to take anything you say seriously when you repeatedly
get basic facts wrong and when you make claims that aren't consistent
with the facts.

Which are those facts?


> If the user doesn't want or don't know how to create that script for 
> improving the usability, he/she might need to learn how to use the 
> application by trial and error, but what I want to show is that the user is 
> *able* to use that application, even if the interface is not very friendly, 
> but it would be absolutely impossible to use an application created with 
> Tkinter.

He / she might be able to use the application.  It's a "maybe", not a
"for sure", yet you consistently imply it's the latter.

Yes, but there is a chance to be able to use that application while if the 
application is done with T

Re: statement level resumable exception

[ilejn]

Arnaud,

good idea, though I think it is not applicable in my case,
because my arg1 ... argN are "complex multilayer lists".

In reality it is not just
f(arg1),
it is more like
f([[subarg1, 'aa', subarg2], []])

Regarding your remark it is a strange problem ... well, may be it
is ;)

Thanks anyway.

On Jan 20, 10:58 pm, Arnaud Delobelle  wrote:
> ilejn  writes:
> > Hello!
>
> > I have a sequence of a function calls. Basically it looks like
>
> > f(arg1)
> > f(arg2)
> > ...
> > f(argN)
>
> > though real arguments are complex multilayer lists.
>
> > The problem is some arguments are not known and I get NameError
> > exceptions.
>
> > The solutions I know
> > 1. wrap every f call in try/except block
> > 2. make (currently global) argument attributes of a class and use
> > __getattr__ to convert unknown attributes to something recognizable by
> > f.
>
> for name in 'arg1', 'arg2', ... 'argN':
>     try:
>         arg = globals()[name]
>     except NameError:
>         continue
>     f(arg)
>
> But this is a strange problem...  Sounds like you should do it
> differently.
>
> --
> Arnaud

Best regards,
Ilja Golshtein.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 20, 1:17 pm, Emile van Sebille  wrote:
>
> The problem with QT is the license.

Qt and wxWidgets are both LGPL and equally non-starters due to
license, today. There was a hypothetical assumption on my part that
the library would be made license compatible somehow, through the
entire discussion.  I didn't think it worth mentioning because I
didn't think it all that relevant to any of the discussions that end
ed up occurring here.

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

Re: Efficient python 2-d arrays?

[Dan Stromberg]

On Thu, Jan 20, 2011 at 11:36 AM, Jake Biesinger
 wrote:
>> Thanks for the great suggestions!
>
> On a related note, is there no way to efficiently sort a python array?
>
>
 x = array('f', xrange(1000))
 x.sort()
> ---
> AttributeError                            Traceback (most recent call last)
>
> /home/wbiesing/src/python-sort/ in ()
>
> AttributeError: 'array.array' object has no attribute 'sort'
>
 type(sorted(x))
> 
>
> Seems like a common enough task, but no way to do it efficiently without 
> scipy/numpy.

Tap, tap: Is this thing on?  I keep sending messages to this list, but
no one seems to "hear" what I'm writing.

Anyway, I have a bunch of sorts in python (pure or cython, your
option) at 
http://stromberg.dnsalias.org/cgi-bin/viewvc.cgi/sorts/compare/trunk/?root=svn

The pure python versions should all work out of the box with an
array.array.  I tested the timsort on an array.array, and it worked
well.

Also, I just made a trivial modification (not checked in! ...but I did
test it) to make the cythonized timsort support sorting arrays - just
change the "list" type declarations to "object" (or perhaps
"array.array") prior to compiling.

I also just changed the license on them from GPL v3 to Apache v2.

timsort truly is a somewhat supernatural algorithm.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: statement level resumable exception

[Arnaud Delobelle]

ilejn  writes:

> Arnaud,
>
> good idea, though I think it is not applicable in my case,
> because my arg1 ... argN are "complex multilayer lists".
>
> In reality it is not just
> f(arg1),
> it is more like
> f([[subarg1, 'aa', subarg2], []])
>
> Regarding your remark it is a strange problem ... well, may be it
> is ;)
>
> Thanks anyway.

Are these lists automatically generated?

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

Re: Part of RFC 822 ignored by email module

[Martin Gregorie]

On Thu, 20 Jan 2011 12:55:44 -0500, Bob Kline wrote:

> On 1/20/2011 12:23 PM, Carl Banks wrote:
>> On Jan 20, 7:08 am, Bob Kline  wrote:
>>> I just noticed that the following passage in RFC 822:
>>>
>>>   The process of moving  from  this  folded   multiple-line
>>>   representation  of a header field to its single line
>>>   represen- tation is called "unfolding".  Unfolding  is 
>>>   accomplished  by regarding   CRLF   immediately  followed 
>>>   by  a  LWSP-char  as equivalent to the LWSP-char.
>>>
>>> is not being honored by the email module.  The following two
>>> invocations of message_from_string() should return the same value, but
>>> that's not what happens:
>>>
>>>   >>>  import email
>>>   >>>  email.message_from_string("Subject: blah").get('SUBJECT')
>>> 'blah'
>>>   >>>  email.message_from_string("Subject:\n blah").get('SUBJECT')
>>> ' blah'
>>>
>>> Note the space in front of the second value returned, but missing from
>>> the first.  Can someone convince me that this is not a bug?
>> That's correct, according to my reading of RFC 822 (I doubt it's
>> changed so I didn't bother to look up what the latest RFC on that
>> subject is.)
>>
>> The RFC says that in a folded line the whitespace on the following line
>> is considered a part of the line.
> 
> Thanks for responding.  I think your interpretation of the RFC is the
> same is mine.  What I'm saying is that by not returning the same value
> in the two cases above the module is not "regarding CRLF immediately
> followed by a LWSP-char as equivalent to the LWSP-char."
>
That's only a problem if your code cares about the composition of the 
whitespace and this, IMO is incorrect behaviour. When the separator 
between syntactic elements in a header is 'whitespace' it should not 
matter what combination of newlines, tabs and spaces make up the 
whitespace element. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 20, 3:02 pm, "Octavian Rasnita"  wrote:
> From: "Adam Skutt" > Yet, for some unfathomable reason, you 
> keep promoting
> I would be glad if you could tell me about a portable solution which is 
> accessible with JAWS and Window Eyes, the most used screen readers under 
> Windows (real glad).

I did, Qt.  I'm not yournanny and I'm not going to go test it for
you.  There are bugs in the Qt database relating to JAWS
functionality, so it others have plainly gotten it working to some
degree.  But honestly, why should I waste my time replying to you when
you're too damn lazy to even use Google?  I certainly won't be doing
so in the future.  "Lead a ignorant, thirsty horse to water, watch it
die of thirst" and all that.

> Exactly. When you will read that thing on a GUI creator site it means that 
> that GUI is not accessible because the screen readers don't support it yet.
> The GUI libs manufacturers will say that the screen readers are bad because 
> they don't offer support for their GUI, although that GUI offers 
> accessibility features.

No, that's not what that page says or means.  But I'm not going to be
able to explain it to you any more clearly, so if you'd prefer to keep
living in your own delusional, illydic world, that's your decision.
Qt has been pretty clear in painting the blame on who it belongs on,
which is not the screen reader vendors.

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 2:37 pm, Adam Skutt  wrote:
> On Jan 20, 1:17 pm, Emile van Sebille  wrote:
>
>
>
> > The problem with QT is the license.
>
> Qt and wxWidgets are both LGPL and equally non-starters due to
> license, today.

Everything out there is LGPL! But you cannot just use that argument to
keep Tkinter. So are you suggesting that we just hold on Tkinter
forver! Are you mad? Can you image Python still lugging around the
antiquated Tkinter module in 2020? That's a nightmare. You know damn
good and well that even nine years from now TclTk will be two decades
behind in development. AND SLOWER THAN EVER!

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

Re: statement level resumable exception

[Emile van Sebille]

On 1/20/2011 11:49 AM ilejn said...

Chris,

this is a long story why arguments may be not known.
Briefly these arguments come (or may come) from XML and may be not
specified.

A function call which does not have all arguments defined must be
skipped as gracefully as possible.
What I am asking about is how to achieve this goal.



I might try using sets:

required = set(('a','b','c'))
if not (required - set(locals())): f(a,b,c)

HTH,

Emile


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

Re: Google AI challenge: planet war. Lisp won.

[namekuseijin]

On Dec 22 2010, 12:46 pm, Xah Lee  wrote:
> On Dec 20, 10:06 pm, "Jon Harrop"  wrote:
>
> > Wasn't that the "challenge" where they wouldn't even accept solutions
> > written in many other languages (including both OCaml and F#)?
>
> Ocaml is one of the supported lang. See:
>
> http://ai-contest.com/starter_packages.php
>
> there are 12 teams using OCaml. See:http://ai-contest.com/rankings.php
> (click on the lang to see all teams using that lang)
>
>  Xah

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

Re: statement level resumable exception

[ilejn]

Arnaud,

these lists are not generated.

Actually these lists are a sort of interpreted programs and contain
some application logic.

Here is an example
[
[PUSH, [get_modified_interface, req]],
[TIMEOUT, 3],
[PULL, [out_interface, '']],
[PULL, [err_interface, '']],
[PULL, [out_mined_interface, req]],
]

If any interface name is unknown the list must not be invoked (in
other words, f function
call with this list must be somehow bypassed).

Thanks.


On Jan 20, 11:42 pm, Arnaud Delobelle  wrote:
> ilejn  writes:
> > Arnaud,
>
> > good idea, though I think it is not applicable in my case,
> > because my arg1 ... argN are "complex multilayer lists".
>
> > In reality it is not just
> > f(arg1),
> > it is more like
> > f([[subarg1, 'aa', subarg2], []])
>
> > Regarding your remark it is a strange problem ... well, may be it
> > is ;)
>
> > Thanks anyway.
>
> Are these lists automatically generated?
>
> --
> Arnaud

Best regards,
Ilja Golshtein.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Emile van Sebille]

On 1/20/2011 12:17 PM rantingrick said...

Well as far as i am concerned that takes QT out of the contest. So
that leaves WxPython and pyGTK as the only viable options that are
mature libraries. Both carry the LGPL license.

   http://www.pygtk.org/
   http://www.wxwidgets.org/about/newlicen.htm




You might find this interesting...

http://mail.python.org/pipermail/python-announce-list/2000-November/000572.html

Yes, it's old.  That's part of the reason you get no traction on this.

Emile

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

Re: UTF-8 question from Dive into Python 3

[jmfauth]

On Jan 19, 11:33 pm, Terry Reedy  wrote:
> On 1/19/2011 1:02 PM, Tim Harig wrote:
>
> > Right, but I only have to do that once.  After that, I can directly address
> > any piece of the stream that I choose.  If I leave the information as a
> > simple UTF-8 stream, I would have to walk the stream again, I would have to
> > walk through the the first byte of all the characters from the beginning to
> > make sure that I was only counting multibyte characters once until I found
> > the character that I actually wanted.  Converting to a fixed byte
> > representation (UTF-32/UCS-4) or separating all of the bytes for each
> > UTF-8 into 6 byte containers both make it possible to simply index the
> > letters by a constant size.  You will note that Python does the former.
>
> The idea of using a custom fixed-width padded version of a UTF-8 steams
> waw initially shocking to me, but I can imagine that there are
> specialized applications, which slice-and-dice uninterpreted segments,
> for which that is appropriate. However, it is not germane to the folly
> of prefixing standard UTF-8 steams with a 3-byte magic number,
> mislabelled a 'byte-order-mark, thus making them non-standard.
>


Unicode Book, 5.2.0, Chapter 2, Section 14, Page 51 - Paragraphe
*Unicode Signature*.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Part of RFC 822 ignored by email module

[Bob Kline]

On 1/20/2011 3:48 PM, Martin Gregorie wrote:

That's only a problem if your code cares about the composition of the
whitespace and this, IMO is incorrect behaviour. When the separator
between syntactic elements in a header is 'whitespace' it should not
matter what combination of newlines, tabs and spaces make up the
whitespace element.


That would be true for what the RFC calls "structured" fields, but not 
for the others (such as the Subject header).


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 3:06 pm, Emile van Sebille  wrote:

> You might find this interesting...
> http://mail.python.org/pipermail/python-announce-list/2000-November/0...
> Yes, it's old.  That's part of the reason you get no traction on this.

Thanks Emile. This read was both hair raising and informative.
Following is the relevant Tkinter parts posted verbatim with my
comments sprinkled throughout...


> However, this process is still in its infancy, and the announcement
> caused much worrying in the Tcl/Tk user community about the
> language's future and its continued maintenance.  This affects
> Python because Tk, through the Tkinter module, is the most GUI most
> commonly used with Python.  Tkinter is included in the source
> distribution, it's the most extensively documented, and it's the
> most portable, supported on the Big Three platforms, namely Windows,
> Unix, and MacOS.

It seems at the time (a decade ago) fantasies abounded about the
importance of Tkinter. I find it highly unlikely that Tkinter was OR
IS the "Most commonly used GUI with Python". Maybe the most commonly
used GUI library for utilities, but that's about it

> Fredrik Lundh first posted a note about the announcement, and Eric
> S. Raymond raised the question of what this meant for Tkinter: "This
> raises anew a question I've been meaning to bring up for the last
> week: is it finally time to move away from Python's dependence on
> Tcl/Tk for GUI support?"

Yes (even a decade later!).

> People were split on this question, though Guido was receptive to
> the idea ("Yes, it may be time to have this discussion again.") and
> pointed out some reasons to stick with Tkinter: "Tk has two very
> high quality widgets: the Canvas and Text widgets are unsurpassed in
> functionality and robustness by other widget sets.

Not anymore Guido!

> You can draw
> more lines or characters per second in most toolkits, but few
> toolkits offer the convenience of marks and tags, not having to deal
> with refresh events, being able to group objects, move them around,
> change attributes, etc., etc., etc."

Thats a very weak argument. While i'll agree that the tagging system
employed by the TK::Canvas widget is helpful, the same functionality
can be reproduced by the programmer very easily. And i always prefer
to work with objects as opposed to tags because of the obvious
limitations.

> Greg Wilson's reaction was "Yes please", and he went on to explain
> what factors kept him using Tkinter for a recent course:
http://www.python.org/pipermail/python-dev/2000-October/016757.html

Well that link is broken so we will never know what greg said?

> /F thought Tk was still a good choice, and said " ... and trust me,
> the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-)".  Tkinter3000
> is an improved Tk interface that /F has been working on, with  more
> flexibility and better performance.
> http://tkinter.effbot.org

Yea Frederic maybe Tkinter < exaggeration >"rocked the casba" in 2000, however we are building with steel and glass
now, not rock and stone.

> /F also hoped that the Tcl Core Team would become more receptive to
> making it easier to use Tk from other languages without Tcl having
> to be in the middle, which would let the maintainers of Tkinter and
> the Perl/Tk interface participate more in Tk's development.

Why in the world do WE -- THE Python community-- give two figs as to
how useful TclTk is to OTHER communities?

> Eric S. Raymond speculated about the success of Tcl's new
> development model: "Good for Tcl: Osterhout's rather lame attempts
> to develop under a mixed model have almost certainly come to an end
> in favor of an Apache-like model funded by big Tcl users."
> http://www.python.org/pipermail/python-dev/2000-October/016763.html
>
> Greg Ewing wondered if stdwin should be revived.  GvR and Raymond
> both thought that far too much work, and not productive of very good
> results.  "And stdwin would really look pathetic in this time", GvR
> observed.

Well Guido, just imagine how bad Tkinter will look in 10 years ;-)

> Python isn't tied very tightly to Tk, of course; well-maintained and
> reasonably complete bindings exist for many different GUI toolkits,
> such as Qt, GTk+, wxWindows, Windows MFC, and a few more.
> http://www.thekompany.com/projects/pykde/
> http://www.daa.com.au/~james/pygtk/ http://wxpython.org/
> http://http://www.oreillynet.com/pub/a/217

Well i'd have to disagree being that Tkinter is IN the STDLIB

> wxWindows is probably the most obvious second candidate, since it
> actually supports all of the Big Three platforms, and no other
> toolkit does.  Robin Dunn, author of the wxPython binding, posted to
> discuss the status of wxWindows on the Mac: "My understanding is
> that the version in CVS is nearly up to date with the features in
> the MSW and GTK versions, though I haven't had a chance to use it
> myself.  ... The next step I guess is getting it wrapped up in
> wxPython..."  http://www.python.org/piperma

ANN: ActivePython 2.6.6.18 is now available

[Sridhar Ratnakumar]

ActiveState is pleased to announce ActivePython 2.6.6.18, a complete, 
ready-to-install binary distribution of Python 2.6. Among other updates, 
this releases brings "postinstall" support to PyPM to facilitate 
installation of modules such as PyIMSL.


http://www.activestate.com/activepython/downloads

What's New in ActivePython-2.6.6.18
===

New Features & Upgrades
---

- Upgrade to Tcl/Tk 8.5.9 (`changes `_)
- Security upgrade to openssl-0.9.8q
- [MacOSX] Tkinter now requires ActiveTcl 8.5 64-bit (not Apple's Tcl/Tk 
8.5 on OSX)

- Upgrade to PyPM 1.3.0:

  - Programmatic use via ``pypm.cmd(['install', 'foo'])``
  - Support for postinstall and conditional user-notes

- Package updates:

  - pip-0.8.2


Noteworthy Changes & Bug Fixes
--

- [Windows 64-bit] `issue8275 `_: turn 
off optimization for the ctypes module

- PyPM bug fixes:

  - Fix needless truncation of output when piping (eg: ``pypm list | 
less``)

  - Respect download cache of ``*.pypm`` packages (don't redownload)
  - Bug #2: Fix pickle incompatability (sqlite) on Python 3.x



What is ActivePython?
=

ActivePython is ActiveState's binary distribution of Python. Builds for 
Windows, Mac OS X, Linux are made freely available. Solaris, HP-UX and 
AIX builds, and access to older versions are available in ActivePython 
Business, Enterprise and OEM editions:


http://www.activestate.com/python

ActivePython includes the Python core and the many core extensions: zlib 
and bzip2 for data compression, the Berkeley DB (bsddb) and SQLite 
(sqlite3) database libraries, OpenSSL bindings for HTTPS support, the 
Tix GUI widgets for Tkinter, ElementTree for XML processing, ctypes (on 
supported platforms) for low-level library access, and others. The 
Windows distribution ships with PyWin32 -- a suite of Windows tools 
developed by Mark Hammond, including bindings to the Win32 API and 
Windows COM.


ActivePython also includes a binary package manager for Python (PyPM) 
that can be used to install packages much easily. For example:


  C:\>pypm install mysql-python
  [...]

  C:\>python
  >>> import MySQLdb
  >>>

See this page for full details:

http://docs.activestate.com/activepython/2.6/whatsincluded.html

As well, ActivePython ships with a wealth of documentation for both new 
and experienced Python programmers. In addition to the core Python docs, 
ActivePython includes the "What's New in Python" series, "Dive into 
Python", the Python FAQs & HOWTOs, and the Python Enhancement Proposals 
(PEPs).


An online version of the docs can be found here:

http://docs.activestate.com/activepython/2.6/

We would welcome any and all feedback to:

activepython-feedb...@activestate.com

Please file bugs against ActivePython at:

http://bugs.activestate.com/enter_bug.cgi?product=ActivePython

Supported Platforms
===

ActivePython is available for the following platforms:

- Windows   (x86 and x64)
- Mac OS X  (x86 and x86_64; 10.5+)
- Linux (x86 and x86_64)

- Solaris/SPARC (32-bit and 64-bit) (Business, Enterprise or OEM edition 
only)
- Solaris/x86   (32-bit)(Business, Enterprise or OEM edition 
only)
- HP-UX/PA-RISC (32-bit)(Business, Enterprise or OEM edition 
only)

- HP-UX/IA-64   (32-bit and 64-bit) (Enterprise or OEM edition only)
- AIX/PowerPC   (32-bit and 64-bit) (Business, Enterprise or OEM edition 
only)


More information about the Business Edition can be found here:

http://www.activestate.com/business-edition

Custom builds are available in the Enterprise Edition:

http://www.activestate.com/enterprise-edition

Thanks, and enjoy!

The Python Team

--
Sridhar Ratnakumar
sridharr at activestate.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Part of RFC 822 ignored by email module

[Martin Gregorie]

On Thu, 20 Jan 2011 16:25:52 -0500, Bob Kline wrote:

> On 1/20/2011 3:48 PM, Martin Gregorie wrote:
>> That's only a problem if your code cares about the composition of the
>> whitespace and this, IMO is incorrect behaviour. When the separator
>> between syntactic elements in a header is 'whitespace' it should not
>> matter what combination of newlines, tabs and spaces make up the
>> whitespace element.
> 
> That would be true for what the RFC calls "structured" fields, but not
> for the others (such as the Subject header).

Subject text comparisons should work correctly if you were to split the 
subject text using the 'whitespace' definition and then reassemble it 
using a single space in place of each whitespace separator. Its either 
that or assuming that all MUAs use the same line length and all use a 
line split of "CRLF " - the whitespace that's needed to align the 
continuation with the test on the first subject line. Many MUAs will do 
that, but its unlikely that all will.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Part of RFC 822 ignored by email module

[Bob Kline]

On 1/20/2011 5:34 PM, Martin Gregorie wrote:

On Thu, 20 Jan 2011 16:25:52 -0500, Bob Kline wrote:


On 1/20/2011 3:48 PM, Martin Gregorie wrote:

That's only a problem if your code cares about the composition of the
whitespace and this, IMO is incorrect behaviour. When the separator
between syntactic elements in a header is 'whitespace' it should not
matter what combination of newlines, tabs and spaces make up the
whitespace element.

That would be true for what the RFC calls "structured" fields, but not
for the others (such as the Subject header).

Subject text comparisons should work correctly if you were to split the
subject text using the 'whitespace' definition and then reassemble it
using a single space in place of each whitespace separator. Its either
that or assuming that all MUAs use the same line length and all use a
line split of "CRLF " - the whitespace that's needed to align the
continuation with the test on the first subject line. Many MUAs will do
that, but its unlikely that all will.


Thanks.  I'm not sure everyone would agree that it's OK to collapse 
multiple consecutive spaces into one, but I'm beginning to suspect that 
those more concerned with preserving as much as possible of the original 
message are in the minority.  It sounds like my take-home distillation 
from this thread is "yes, the module ignores what the spec says about 
unfolding, but it doesn't matter."  I guess I can live with that.


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

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

Re: Tkinter: The good, the bad, and the ugly!

[Jerry Hill]

On Thu, Jan 20, 2011 at 4:52 PM, rantingrick  wrote:
>> Greg Wilson's reaction was "Yes please", and he went on to explain
>> what factors kept him using Tkinter for a recent course:
>        http://www.python.org/pipermail/python-dev/2000-October/016757.html
>
> Well that link is broken so we will never know what greg said?

I think that's referring to this email:
http://mail.python.org/pipermail/python-dev/2000-October/010046.html

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

Re: Tkinter: The good, the bad, and the ugly!

[MRAB]

On 20/01/2011 21:52, rantingrick wrote:

On Jan 20, 3:06 pm, Emile van Sebille  wrote:


[snip]

Greg Wilson's reaction was "Yes please", and he went on to explain
what factors kept him using Tkinter for a recent course:

http://www.python.org/pipermail/python-dev/2000-October/016757.html

Well that link is broken so we will never know what greg said?


[snip]
Yes:
http://mail.python.org/pipermail/python-dev/2000-October.txt
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 5:01 pm, Jerry Hill  wrote:
> On Thu, Jan 20, 2011 at 4:52 PM, rantingrick  wrote:
> >> Greg Wilson's reaction was "Yes please", and he went on to explain
> >> what factors kept him using Tkinter for a recent course:
> >        http://www.python.org/pipermail/python-dev/2000-October/016757.html
>
> > Well that link is broken so we will never know what greg said?
>
> I think that's referring to this 
> email:http://mail.python.org/pipermail/python-dev/2000-October/010046.html
>
> --
> Jerry

Thanks Jerry this was the thread i was looking for. Two points for
you ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 5:08 pm, MRAB  wrote:
> On 20/01/2011 21:52, rantingrick wrote:> On Jan 20, 3:06 pm, Emile van 
> Sebille  wrote:
>
> [snip]
> >> Greg Wilson's reaction was "Yes please", and he went on to explain
> >> what factors kept him using Tkinter for a recent course:
> >    http://www.python.org/pipermail/python-dev/2000-October/016757.html
>
> > Well that link is broken so we will never know what greg said?
>
> [snip]
> Yes:
>      http://mail.python.org/pipermail/python-dev/2000-October.txt

Sorry MRAB. I could not find Greg's reply in this mountain of Usenet
you posted a link to. You lose two points :(, oh wait, why should i be
unhappy ;-)

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 20, 5:01 pm, Jerry Hill  wrote:

> I think that's referring to this 
> email:http://mail.python.org/pipermail/python-dev/2000-October/010046.html


 Greg Wilson -
I thought about using wxPython in the most recent run of my Python
course, but
decided to stick to Tkinter because:

- There isn't a wxWindows/wxPython book (matters a lot when
organizations are
  trying to decide what to adopt for long-term use).
 Greg Wilson -

WxPython could use better docs even today (not sure of what books are
available) however when we decide to integrate wx into the stdlib that
would be the best time to write a comprihensive "python specific
tutorial/docs

 Greg Wilson -
- Tkinter came packaged with the 1.5.2 installer, wxPython didn't.
 Greg Wilson -

Duh! And if wxPython came prepackaged this post whould never have
existed eh?

 Greg Wilson -
- There aren't as many tools on top of wxPython as there are on top of
Tkinter.
  In particular, I think that a vector drawing package on top of
wxPython that
  did what Sketch does, but on Windows as well as Linux, would make a
great
  subject for a book on Python, non-trivial OO, and HCI (hint,
hint...)
 Greg Wilson -

Oh come on, this is about as weak as Guido's "tag" rant. A vector
drawing app is not a tool it's an app! An besides more "tools" or apps
will be written in wx when we integrate it into the stdlib, no doubt.
These are really ridiculous reasons for not choosing wxPython and i
suspect that you are just another one of the mindless "Tkinter"
zombies who base their judgments on friendships and constituents.

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

Re: Tkinter: The good, the bad, and the ugly!

[Nick Stinemates]

>
>  Greg Wilson -
> I thought about using wxPython in the most recent run of my Python
> course, but
> decided to stick to Tkinter because:
>
> - There isn't a wxWindows/wxPython book (matters a lot when
> organizations are
>  trying to decide what to adopt for long-term use).
>  Greg Wilson -
>
> WxPython could use better docs even today (not sure of what books are
> available) however when we decide to integrate wx into the stdlib that
> would be the best time to write a comprihensive "python specific
> tutorial/docs
>
>
I disagree. All of the ducks should be in a row* **before* making a decision
like this as it shows commitment from the community to making it happen.
Nothing happens because we wish it to.

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

Re: Part of RFC 822 ignored by email module

[Martin Gregorie]

On Thu, 20 Jan 2011 17:58:36 -0500, Bob Kline wrote:
 
> Thanks.  I'm not sure everyone would agree that it's OK to collapse
> multiple consecutive spaces into one, but I'm beginning to suspect that
> those more concerned with preserving as much as possible of the original
> message are in the minority.  It sounds like my take-home distillation
> from this thread is "yes, the module ignores what the spec says about
> unfolding, but it doesn't matter."  I guess I can live with that.
>
I've been doing stuff in this area with the JavaMail package, though not 
as yet in Python. I've learnt that you parse the headers you can extract 
values that work well for comparisons, as database keys, etc. but are not 
guaranteed to let you reconstitute the original header byte for byte. If 
preserving the message exactly as received the solution is to parse the 
message to extract the headers and MIME parts you need for the 
application to carry out its function, but keep the original, unparsed 
message so you can pass it on.

The other gotcha is assuming that the MUA author read and understood the 
RFCs. Very many barely glanced at RFCs and/or misunderstood them. 
Consequently, if you use strict parsing you'll be surprised how many 
messages get rejected for having invalid headers or MIME headers. Fot 
instance, the mistakes some MUAs make when outputting To, CC and BCC 
headers with multiple addresses have to be seen to be believed. If the 
Python e-mail module lets you, set it to use lenient parsing. If this 
isn't an option you may well find yourself having to fix up messages 
before you can parse them successfully.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

CRC 16bit function

[SANKAR .]

Hi There,

I am looking for buitin function to calculate  16 bit checksum values of the
lines in text file using python.
I could find one for 32 bit but not for 16 bit. Can some one help me?

Thanks

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

Re: __pycache__, one more good reason to stck with Python 2?

[Steven D'Aprano]

On Thu, 20 Jan 2011 05:09:50 -0800, John Pinner wrote:

> Hi
> 
> You have disturbe my slumber, Steven ;-)
> 
> On Jan 19, 2:42 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote:
>> > It is now practically impossible to launch a Python application via a
>> > .pyc file.
>>
>> When has that ever been possible?
>>
>> .pyc files are Python byte-code. You can't run them directly using
>> Python (except via the import machinery), you can't run them as a
>> script, they're not machine code. Unless you write a wrapper to import
>> the file as a module, you can't directly execute .pyc files.
> 
> Not true. 'python myprog.pyc' has worked for as long as I have been
> using Python. Whether or not it is a good idea is another matter.
> 
> Probably it would be best to check what you're saying before posting
> such a bald assertion, even though you were 110% sure of what you were
> saying. I've been there, done that, bought the tee-shirt.

Yes, thank you, I've already been corrected over this :)

But you got me thinking... how far back does this behaviour go? 
Apparently it goes back as long as I've been using Python too:

[steve@sylar ~]$ echo "print 'spam spam spam'" > spam.py
[steve@sylar ~]$ python1.5
Python 1.5.2 (#1, Apr  1 2009, 22:55:54)  [GCC 4.1.2 20070925 (Red Hat 
4.1.2-27)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import spam
spam spam spam
>>>
[steve@sylar ~]$ python1.5 spam.pyc
spam spam spam


But of course, .pyc files1.5 are version specific:


[steve@sylar ~]$ python2.5 spam.pyc
RuntimeError: Bad magic number in .pyc file


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

Re: Efficient python 2-d arrays?

[Jacob Biesinger]

On Thu, Jan 20, 2011 at 12:48 PM, Dan Stromberg  wrote:
> On Thu, Jan 20, 2011 at 11:36 AM, Jake Biesinger
>  wrote:
>>> Thanks for the great suggestions!
>>
>> On a related note, is there no way to efficiently sort a python array?
>>
>>
> x = array('f', xrange(1000))
> x.sort()
>> ---
>> AttributeError                            Traceback (most recent call last)
>>
>> /home/wbiesing/src/python-sort/ in ()
>>
>> AttributeError: 'array.array' object has no attribute 'sort'
>>
> type(sorted(x))
>> 
>>
>> Seems like a common enough task, but no way to do it efficiently without 
>> scipy/numpy.
>
> Tap, tap: Is this thing on?  I keep sending messages to this list, but
> no one seems to "hear" what I'm writing.

Hey Dan, indeed thanks for the code; I pulled it down and played
around with timsort a while ago. Timsort is indeed a beast. My current
solution is to do an argsort.  Since I can't roll with your cython
implementations (pure python *only*), this seems a bit faster than
sorting the original two lists using a modified pure-python timsort.
Something along the lines of:

args = sorted(range(len(seq1)), key=seq1.__getitem__)
seq1 = [seq1[i] for i in args]
seq2 = [seq2[i] for i in args]

but the method suffers from a fairly high memory usage (big list of
int's for args).  If this barrier is too high, I will be switching
over to your pure-python timsort.

> Anyway, I have a bunch of sorts in python (pure or cython, your
> option) at 
> http://stromberg.dnsalias.org/cgi-bin/viewvc.cgi/sorts/compare/trunk/?root=svn
>
> The pure python versions should all work out of the box with an
> array.array.  I tested the timsort on an array.array, and it worked
> well.

your pylint runs fail for me, saying you should use disable, not disable-msg.
pylint 0.23.0,
astng 0.21.1, common 0.54.0
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5]

> Also, I just made a trivial modification (not checked in! ...but I did
> test it) to make the cythonized timsort support sorting arrays - just
> change the "list" type declarations to "object" (or perhaps
> "array.array") prior to compiling.

I'm not very familiar with cython syntax-- how do you bring in the array module?
cimport array? import array? I see you need to change cdef list to
cdef array.array or something like that.  Perhaps you could send a
diff?

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

Re: Tkinter: The good, the bad, and the ugly!

[MRAB]

On 20/01/2011 23:15, rantingrick wrote:

On Jan 20, 5:08 pm, MRAB  wrote:

On 20/01/2011 21:52, rantingrick wrote:>  On Jan 20, 3:06 pm, Emile van 
Sebillewrote:

[snip]

Greg Wilson's reaction was "Yes please", and he went on to explain
what factors kept him using Tkinter for a recent course:

http://www.python.org/pipermail/python-dev/2000-October/016757.html



Well that link is broken so we will never know what greg said?


[snip]
Yes:
  http://mail.python.org/pipermail/python-dev/2000-October.txt


Sorry MRAB. I could not find Greg's reply in this mountain of Usenet
you posted a link to. You lose two points :(, oh wait, why should i be
unhappy ;-)


Did you try searching for "yes please"? It takes just seconds...
--
http://mail.python.org/mailman/listinfo/python-list

Re: CRC 16bit function

[geremy condra]

On Thu, Jan 20, 2011 at 4:03 PM, SANKAR .  wrote:
> Hi There,
>
> I am looking for buitin function to calculate  16 bit checksum values of the
> lines in text file using python.
> I could find one for 32 bit but not for 16 bit. Can some one help me?

Google's your friend.

http://efreedom.com/Question/1-1767910/Checksum-Udp-Calculation-Python

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

Re: __pycache__, one more good reason to stck with Python 2?

[Martin v. Loewis]

> I know I've seen problems executing .pyc files from the shell in the 
> past... perhaps I was conflating details of something else. Ah, I know!
> 
> [steve@sylar ~]$ chmod u+x toto.pyc
> [steve@sylar ~]$ ./toto.pyc
> : command not found ��
> ./toto.pyc: line 2: syntax error near unexpected token `('
> ./toto.pyc: line 2: `P7Mc@s dGHdS(tfooNs./
> toto.pys'

Works fine here:

martin@mira:/tmp$ cat >a.py
print "Hello, world"
martin@mira:/tmp$ python
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> import a
Hello, world
py>
martin@mira:/tmp$ chmod +x a.pyc
martin@mira:/tmp$ ./a.pyc
Hello, world

Notice that it is a Linux feature that it can support Python bytecode
as a "native" executable when properly configured.

Windows has a very similar feature, though. I think OSX can support
it as well, but I haven't tried.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

[Martin v. Loewis]

> But you got me thinking... how far back does this behaviour go? 

=
==> Release 1.1 (11 Oct 1994) <==
=

- Passing the interpreter a .pyc file as script argument will execute
  the code in that file.  (On the Mac such files can be double-clicked!)
- New module compileall generates .pyc files for all modules in a
  directory (tree) without also executing them

[Notice that "on the Mac" refers to Mac System 7 here]

===
==> Release 1.0.0 (26 January 1994) <==
===

* It is now possible to have a .pyc file without a corresponding .py
file.  (Warning: this may break existing installations if you have an
old .pyc file lingering around somewhere on your module search path
without a corresponding .py file, when there is a .py file for a
module of the same name further down the path -- the new interpreter
will find the first .pyc file and complain about it, while the old
interpreter would ignore it and use the .py file further down.)

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Efficient python 2-d arrays?

[Dan Stromberg]

On Thu, Jan 20, 2011 at 4:07 PM, Jacob Biesinger
 wrote:
> On Thu, Jan 20, 2011 at 12:48 PM, Dan Stromberg  wrote:
>> On Thu, Jan 20, 2011 at 11:36 AM, Jake Biesinger
>>  wrote:
 Thanks for the great suggestions!
>>>
>>> On a related note, is there no way to efficiently sort a python array?
>>>
>>>
>> x = array('f', xrange(1000))
>> x.sort()
>>> ---
>>> AttributeError                            Traceback (most recent call last)
>>>
>>> /home/wbiesing/src/python-sort/ in ()
>>>
>>> AttributeError: 'array.array' object has no attribute 'sort'
>>>
>> type(sorted(x))
>>> 
>>>
>>> Seems like a common enough task, but no way to do it efficiently without 
>>> scipy/numpy.
>>
>> Tap, tap: Is this thing on?  I keep sending messages to this list, but
>> no one seems to "hear" what I'm writing.
>
> Hey Dan, indeed thanks for the code; I pulled it down and played
> around with timsort a while ago. Timsort is indeed a beast. My current
> solution is to do an argsort.  Since I can't roll with your cython
> implementations (pure python *only*), this seems a bit faster than
> sorting the original two lists using a modified pure-python timsort.
> Something along the lines of:
>
> args = sorted(range(len(seq1)), key=seq1.__getitem__)
> seq1 = [seq1[i] for i in args]
> seq2 = [seq2[i] for i in args]
>
> but the method suffers from a fairly high memory usage (big list of
> int's for args).  If this barrier is too high, I will be switching
> over to your pure-python timsort.

Oh, cool.  I guess I'm not a ghost after all.  :)

And an argsort sounds like a nice solution.

>> Anyway, I have a bunch of sorts in python (pure or cython, your
>> option) at 
>> http://stromberg.dnsalias.org/cgi-bin/viewvc.cgi/sorts/compare/trunk/?root=svn
>>
>> The pure python versions should all work out of the box with an
>> array.array.  I tested the timsort on an array.array, and it worked
>> well.
>
> your pylint runs fail for me, saying you should use disable, not disable-msg.
> pylint 0.23.0,
> astng 0.21.1, common 0.54.0
> Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
> [GCC 4.4.5]

Earlier today I updated the code to deal with newer pylints -
including the disable vs disable-msg thing.  If you "svn update", you
should get these changes.

>> Also, I just made a trivial modification (not checked in! ...but I did
>> test it) to make the cythonized timsort support sorting arrays - just
>> change the "list" type declarations to "object" (or perhaps
>> "array.array") prior to compiling.
>
> I'm not very familiar with cython syntax-- how do you bring in the array 
> module?
> cimport array? import array? I see you need to change cdef list to
> cdef array.array or something like that.  Perhaps you could send a
> diff?

http://stromberg.dnsalias.org/svn/sorts/compare/branches/arrays now
has a version of timsort that expects objects (IOW, about anything,
duck typed) instead of lists.  I tried briefly to declare some of the
types to be array.array, but perhaps Cython doesn't like that - I was
getting compile-time errors from it.

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

Re: Tkinter: The good, the bad, and the ugly!

[Neil Hodgson]

Emile van Sebille:

> The problem with QT is the license.
> 
> From http://qt.nokia.com/products/licensing/:
> 
> Qt Commercial Developer License
> The Qt Commercial Developer License is the correct license to use for
> the development of proprietary and/or commercial software ...

   The LGPL version is also useful for producing commercial software.
>From the same web page:

"""
Qt GNU LGPL v. 2.1 Version
This version is available for development of proprietary and commercial
applications in accordance with the terms and conditions of the GNU
Lesser General Public License version 2.1.
"""

   Developing a proprietary (closed source) application using LGPL
libraries is normally not a problem as the only pieces of code you have
to publish are changes to those LGPL libraries, not the application
code. Most applications do not change the libraries.

   The "can't reuse LGPL code" clause is a restriction on what can be
done with the Qt Commercial Developer License not on what can be done
with the LGPL license.

   GTK+ has always been LGPL and that license has not been an obstacle
to either open source or closed source projects.

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

New instance of a class : not reset?

[Jean-Francois]

Hi,

In the following example, I don't understand why attribute 'data' is
not reset when I get the new instance of Bag
It works if I make a copy (data[:]) but I want to understand why

Thanks


class Bag(object):
def __init__(self, data = []):
self.data = data
#self.data = data[:]
def add(self, x):
self.data.append(x)

bag = Bag()
print bag.data
bag.add('toto')
print bag.data
bag = Bag()  # new instance of Bag, all attributes clear?
print bag.data   # 'toto' is still there !!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New instance of a class : not reset?

[André]

On Thursday, January 20, 2011 10:35:46 PM UTC-4, Jean-Francois wrote:
> Hi,
> 
> In the following example, I don't understand why attribute 'data' is
> not reset when I get the new instance of Bag
> It works if I make a copy (data[:]) but I want to understand why
> 
> Thanks
> 
> 
> class Bag(object):
>   def __init__(self, data = []):


See http://docs.python.org/tutorial/controlflow.html#default-argument-values
Read the text following "Important warning: The default value is evaluated only 
once.".

André

>   self.data = data
>   #self.data = data[:]
>   def add(self, x):
>   self.data.append(x)
> 
> bag = Bag()
> print bag.data
> bag.add('toto')
> print bag.data
> bag = Bag()  # new instance of Bag, all attributes clear?
> print bag.data   # 'toto' is still there !!!

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

Re: New instance of a class : not reset?

[MRAB]

On 21/01/2011 02:35, Jean-Francois wrote:

Hi,

In the following example, I don't understand why attribute 'data' is
not reset when I get the new instance of Bag
It works if I make a copy (data[:]) but I want to understand why

Thanks


class Bag(object):
def __init__(self, data = []):
self.data = data
#self.data = data[:]
def add(self, x):
self.data.append(x)

bag = Bag()
print bag.data
bag.add('toto')
print bag.data
bag = Bag()  # new instance of Bag, all attributes clear?
print bag.data   # 'toto' is still there !!!


See:
http://effbot.org/zone/default-values.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: CRC 16bit function

[Dave Angel]

On 01/-10/-28163 02:59 PM, geremy condra wrote:

On Thu, Jan 20, 2011 at 4:03 PM, SANKAR .  wrote:

Hi There,

I am looking for buitin function to calculate  16 bit checksum values of the
lines in text file using python.
I could find one for 32 bit but not for 16 bit. Can some one help me?


Google's your friend.

http://efreedom.com/Question/1-1767910/Checksum-Udp-Calculation-Python

Geremy Condra



There are at least 3 commonly used checksum algorithms that give 16bit 
results.  Two of them are CRC's, with different polynomials.  And the 
third is the one's complement that Geremy posted the link to, used in 
tcp/ip traffic.


Try http://bytes.com/topic/python/answers/27677-crc-16-a
  or
http://bytes.com/topic/python/insights/887357-python-check-crc-frame-crc-16-ccitt

The latter is likely to be extremely slow.

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

Re: examples of realistic multiprocessing usage?

[Albert van der Horst]

In article ,
Adam Tauno Williams   wrote:
>On Mon, 2011-01-17 at 13:55 +, Albert van der Horst wrote:
>> In article ,
>> Philip Semanchuk   wrote:
>> 
>> >I grepped through the code to see that it's using =
>> >multiprocessing.Listener. I didn't go any further than that because our =
>> >project is BSD licensed and the license for Gluino is unclear. Until I =
>> >find out whether or not its under an equally permissive license, I can't =
>> >borrow ideas and/or code from it.
>> You have been brain washed by the Intellectual Properties congsy.
>> Of course you can read through code to borrow idea's from it.
>
>I wouldn't; and there is no brain-washing.
>
>It is very unwise to look at GPL'd code if you are working on a non-GPL
>project; the GPL is specifically and intentionally viral.  The
>distinction between reading-through-code-and-borrowing-ideas and
>copying-code is thin and best left to lawyers.

This is what some people want you to believe. Arm twisting by
GPL-ers when you borrow their ideas? That is really unheard of.
GPL-ers are not keen on getting the most monetary award by
setting lawyers on you and go to court only reluctantly to
enforce the license.

>
>Aside: Comments to the contrary often stand-on-their-head to make such
>cases.  For example:
>
>"You do have a choice under the GPL license: you can stop using the
>stolen code and write your own, or you can decide you'd rather release
>under the GPL. But the choice is yours. If you say, I choose neither,
>then the court can impose an injunction to stop you from further
>distribution, but it won't order your code released under the GPL. ...
>Of course, you could avoid all such troubles in the first place by not
>stealing GPL code to begin with"
>

Stealing code means just that, verbatim copies. When you read this
carefully, you can see that reimplementing the stolen code is
an option. Exactly what you say is legally impossible.

It doesn't say:
   "you can stop using the stolen code, and now you're forever
   banned from writing your own, since you have seen our code"

>
>Seriously?  What that basically means is you can't use GPL'd code in a
>non-GPL'd product/project. Saying if you do it is OK, but you'll be
>required to replace the code or change your license is
>standing-on-ones-head.  Risking a forced reimplementation of a core
>component of an existing application is 'just nuts'.

GPL-code is protected under *copyright law*, not patents or some
such. That means that reimplementing idea's is okay.
That is one of the things  GPL tries to protect.
Also we recognize the fact that the wheel is reinvented all the time
and that there are a limited number of solutions to a problem.
You could easily have come up with the same idea as me.

Then you overlook another possibility. I have a lot of GPL-ed code
on my site. If you want to use some of it commercially, you
could contact me and negotiate a non-GPL license. You might be
surprised how easy I'm on you, as long as you recognize where
the code comes from. If you want to use it BSD-licensed, I
would be even more lenient (unless strategic issues are at
stake.)

So pardon me, but not even looking at code you might learn from
is pretty hysteric.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

is it a bug in exec?

[longqian9...@gmail.com]

In pyhton 3.1, I found the following code will succeed with argument 1
to 4 and fail with argument 5 to 9. It is really strange to me. I
suspect it may be a buy in exec() function. Does anyone have some idea
about it? Thanks.


t1="""
class foo:
def fun():
print('foo')
def main():
global foo
foo.fun()
main()
"""
t2="""
class foo:
def fun():
print('foo')
def main():
foo.fun()
main()
"""

import sys
import copy
if sys.argv[1]=='1':
exec(t1)
elif sys.argv[1]=='2':
exec(t2)
elif sys.argv[1]=='3':
exec(t1,{},{})
elif sys.argv[1]=='4':
exec(t2,globals(),locals())
elif sys.argv[1]=='5':
exec(t2,{},{})
elif sys.argv[1]=='6':
exec(t2,globals(),{})
elif sys.argv[1]=='7':
exec(t2,{},locals())
elif sys.argv[1]=='8':
exec(t2,copy.copy(globals()),locals())
elif sys.argv[1]=='9':
exec(t2,globals(),copy.copy(locals()))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Part of RFC 822 ignored by email module

[Carl Banks]

On Jan 20, 9:55 am, Bob Kline  wrote:
> On 1/20/2011 12:23 PM, Carl Banks wrote:
>
>
>
> > On Jan 20, 7:08 am, Bob Kline  wrote:
> >> I just noticed that the following passage in RFC 822:
>
> >>           The process of moving  from  this  folded   multiple-line
> >>           representation  of a header field to its single line represen-
> >>           tation is called "unfolding".  Unfolding  is  accomplished  by
> >>           regarding   CRLF   immediately  followed  by  a  LWSP-char  as
> >>           equivalent to the LWSP-char.
>
> >> is not being honored by the email module.  The following two invocations
> >> of message_from_string() should return the same value, but that's not
> >> what happens:
>
> >>   >>>  import email
> >>   >>>  email.message_from_string("Subject: blah").get('SUBJECT')
> >> 'blah'
> >>   >>>  email.message_from_string("Subject:\n blah").get('SUBJECT')
> >> ' blah'
>
> >> Note the space in front of the second value returned, but missing from
> >> the first.  Can someone convince me that this is not a bug?
> > That's correct, according to my reading of RFC 822 (I doubt it's
> > changed so I didn't bother to look up what the latest RFC on that
> > subject is.)
>
> > The RFC says that in a folded line the whitespace on the following
> > line is considered a part of the line.
>
> Thanks for responding.  I think your interpretation of the RFC is the
> same is mine.  What I'm saying is that by not returning the same value
> in the two cases above the module is not "regarding CRLF immediately
> followed by a LWSP-char as equivalent to the LWSP-char."

That makes sense.  The space after \n is part of the reconstructed
subject and the email module should have treated it same as if the
line hadn't been folded.  I agree that it's a bug.  The line-folding
needs to be moved earlier in the parse process.


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

Re: Part of RFC 822 ignored by email module

[Carl Banks]

On Jan 20, 9:58 am, Dennis Lee Bieber  wrote:
> On Thu, 20 Jan 2011 10:08:40 -0500, Bob Kline 
> declaimed the following in gmane.comp.python.general:
>
>
>
> > I just noticed that the following passage in RFC 822:
>
> >          The process of moving  from  this  folded   multiple-line
> >          representation  of a header field to its single line represen-
> >          tation is called "unfolding".  Unfolding  is  accomplished  by
> >          regarding   CRLF   immediately  followed  by  a  LWSP-char  as
> >          equivalent to the LWSP-char.
>
> > is not being honored by the email module.  The following two invocations
> > of message_from_string() should return the same value, but that's not
> > what happens:
>
> >  >>> import email
> >  >>> email.message_from_string("Subject: blah").get('SUBJECT')
> > 'blah'
> >  >>> email.message_from_string("Subject:\n blah").get('SUBJECT')
> > ' blah'
>
> > Note the space in front of the second value returned, but missing from
> > the first.  Can someone convince me that this is not a bug?
>
>         I'd first be concerned about the absence of the line ending sequence
> specified by the RFC: carriage return (CR; \r) followed by line feed
> (LF; \n).
>
>         \n by itself is not an RFC compliant line ending (even if writing to
> a file on Windows in text mode converts \n into \r\n). Though it does
> appear the module accepts it as such.

Well, I think that message_from_string() would have to accept any
RFC822-compatible message, since it's documented as such, but it
doesn't necessarily have to reject technically invalid ones.

Well, the RFC is concerned mainly with the transmission format, and
doesn't require libraries to force the user to input CRLF, so in
general there's no reason \n isn't acceptable if the library allows
it.

However, message_from_string() is part of the transmission (it's
documented as being able to accept RFC822-formatted messages) so it
has to respect RFC 822 formatting.  But I think it is ok for it to
accept non-compliant messages that use LF or CR.  (Any tool that isn't
brain dead should, too.)  The RFC doesn't specifically prohibit this.


>         Secondly, nothing in the spec says it trims leading whitespace from
> the unwrapped lines. In fact, all it says is that the line ending itself
> is removed from the string.
>
> >>> email.message_from_string("Subject:\r\n     blah").get('SUBJECT')
>
> '     blah'

I don't think this behavior is covered in the RFC since this happens
after transmission.  I.e., message_from_string "receives" the RFC822-
compliant message, then it's mostly free to do what it wants with it,
including stripping leading whitespace of header values.


>         However, the module does appear to trim leading whitespace that
> occurs between the : and text (and the line end is considered for that
> trimming, but not any whitespace after it).
>
> >>> email.message_from_string("Subject:      blah\r\n     
> >>> blah").get('SUBJECT')
> 'blah\r\n     blah'
> >>> email.message_from_string("Subject:      blah\r\n     
> >>> blah").get('SUBJECT')
> 'blah\r\n     blah'
> >>> email.message_from_string("Subject:      blah\r\n     blah   
> >>> ").get('SUBJECT')
>
> 'blah\r\n     blah   '>>> email.message_from_string("Subject: \r\n     blah   
> ").get('SUBJECT')
> '     blah   '

In this case the RFC does address the behavior downstream of
transmission: it says that the whitespace following a folded line is
equivalent to that line with just the whitespace, yet the email module
treats them differently.  This is unquestionably a bug.


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

Re: statement level resumable exception

[Arnaud Delobelle]

ilejn  writes:

> Arnaud,
>
> these lists are not generated.
>
> Actually these lists are a sort of interpreted programs and contain
> some application logic.
>
> Here is an example
> [
> [PUSH, [get_modified_interface, req]],
> [TIMEOUT, 3],
> [PULL, [out_interface, '']],
> [PULL, [err_interface, '']],
> [PULL, [out_mined_interface, req]],
> ]
>
> If any interface name is unknown the list must not be invoked (in
> other words, f function
> call with this list must be somehow bypassed).
>
> Thanks.

You could still use the same idea and delay evaluation of the lists. E.g.

prg1 = """[
[PUSH, [get_modified_interface, req]],
[TIMEOUT, 3],
...
"""

prg2 = """[
[OPCODE, [arguments, blah]],
...
"""

...

prgN = """..."""

for prg in prg1, prg2, ..., prgN:
try:
prg = eval(prg)
except NameError:
continue
f(prg)

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