Re: After C++, what with Python?

[Tim Harig]

On 2011-01-16, John Nagle  wrote:
> On 1/15/2011 10:48 PM, Aman wrote:
>> @nagle Means you are suggesting me not to proceed with Python because I've 
>> had experience with C++?
>
>No, Python is quite useful, but on the slow side.  If you're I/O
> bound, not time critical, or otherwise not performance constrained,
> it's quite useful.  The language is really quite good, but there's
> some excessive dynamism which has caused every attempt at an optimizing
> implementation to fail.

Those who are concerned about performance should check out Go.
Garbage collection, duck typing, and compiles to a native binary.
It creates a great middle ground between C++ and Python.  Any C and/or
Python programmer will feel right at home with the language.  It is
still a young language; but, I have been using it for some useful things.

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

Re: After C++, what with Python?

[Paul Rubin]

Tim Harig  writes:
> Those who are concerned about performance should check out Go.
> Garbage collection, duck typing, and compiles to a native binary.
> It creates a great middle ground between C++ and Python.  Any C and/or
> Python programmer will feel right at home with the language.  It is
> still a young language; but, I have been using it for some useful things.

Go has some nice aspects but it is much lower level than Python.  If you
want a statically typed, compiled language closer to Python's level, I
know of some projects that have switched from Python to Ocaml.  If you
want dynamic types, I guess there's Dylan, Lisp, or possibly Erlang.
There is also Haskell, but I think using it takes a much different
mind-set than Python usually brings out.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [python-committers] [RELEASED] Python 3.2 rc 1

[Mark Summerfield]

On Sun, 16 Jan 2011 08:33:41 +0100
Georg Brandl  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On behalf of the Python development team, I'm very happy to announce
> the first release candidate of Python 3.2.
[snip]

Regarding http://docs.python.org/dev/whatsnew/3.2.html

- in the first argparse example the comment says "one of four allowed
  values", but the choices list has only three items so I wonder if this
  is correct?

- in the coverage of PEP  code points are written as u and u00FF
  which is non-standard; one standard way to write them is U+ and
  U+00FF

I love the clickable table of built-in functions in functions.html.

On debian testing 64-bit make test resulted in:
...
[349/349] test_zlib
328 tests OK.
21 tests skipped:
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_gdb
test_kqueue test_ossaudiodev test_smtpnet test_socketserver
test_startfile test_timeout test_tk test_ttk_guionly
test_urllib2net test_urllibnet test_winreg test_winsound
test_xmlrpc_net test_zipfile64
Those skips are all expected on linux2.
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' 
mode='a' encoding='UTF-8'>

which looks pretty good:-)

However, I hit a problem with relative imports not working (compared
with 3.1). I have to go now but will try to produce a small example if I
can.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0321680561
http://www.qtrac.eu/py3book.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Issue 1602, cp65001, powershell and python3 crash

[jmfauth]

After having read the discussion about the issue 1602,
http://bugs.python.org/issue1602, I came to the idea
to test Python with the PowerShell. I thought, it
could help and manage "unicode" better than the
std "dosbox" does

My experience with PowerShell is closed to zero, so
take the following as a flat raw information.

1) Setup the coding in PowerShell (font: Consolas)

PS D:\jm> $OutputEncoding


IsSingleByte  : True
BodyName  : us-ascii
EncodingName  : US-ASCII
HeaderName: us-ascii
WebName   : us-ascii
WindowsCodePage   : 1252
IsBrowserDisplay  : False
IsBrowserSave : False
IsMailNewsDisplay : True
IsMailNewsSave: True
EncoderFallback   : System.Text.EncoderReplacementFallback
DecoderFallback   : System.Text.DecoderReplacementFallback
IsReadOnly: True
CodePage  : 20127

PS D:\jm> chcp 65001
Page de codes active : 65001

PS D:\jm> $OutputEncoding = [Console]::OutputEncoding
PS D:\jm> $OutputEncoding


BodyName  : utf-8
EncodingName  : Unicode (UTF-8)
HeaderName: utf-8
WebName   : utf-8
WindowsCodePage   : 1200
IsBrowserDisplay  : True
IsBrowserSave : True
IsMailNewsDisplay : True
IsMailNewsSave: True
IsSingleByte  : False
EncoderFallback   : System.Text.EncoderReplacementFallback
DecoderFallback   : System.Text.DecoderReplacementFallback
IsReadOnly: True
CodePage  : 65001


So far, so good. It seems I can enter and display "unicode
characters" (as opposed to cp850).

PS D:\jm> echo 'abc逜Üß'
abc逜Üß
PS D:\jm> chcp
Page de codes active : 65001
PS D:\jm>

2) Python test

PS D:\jm> c:\python31\python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard
streams
LookupError: unknown encoding: cp65001

This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
PS D:\jm>

Obviously and expectedly Python does not recognize cp65001.
That's not the problem.

The main concern is, Python crashes with the usual msgbox,
"python.exe has stopped working ..." .

win7 pro (32 bits), Swiss French setup, cp850/cp1252, Python 3.1.2 .

Take this a raw information and do not ask me what's happen
behind the scene.

Last minute info:
Python 3.2.rc1: same behaviour.

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

Re: After C++, what with Python?

[Stefan Behnel]

John Nagle, 16.01.2011 07:03:

Threading is supported
but thread concurrency is marginal. The most common implementation is
a naive interpreter with reference counting backed up by a mark
and sweep garbage collector. Performance is about 1/60 of
optimized C code.

That's Python.


Since the OP is new to Python (and thus also to this group), it's worth 
noting that the above is what John Nagle commonly claims to be important 
about Python. It doesn't match everybody's POV.


For most other people, the essence is that Python is actually fun to work 
with. And if you come from a C++ background, you will happily appreciate 
how simple programming can be. You will also appreciate learning about 
Cython, which is the straight forward way for you to write Python code that 
interfaces with C++ natively.


Stefan

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

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

[Tim Harig]

On 2011-01-16, Paul Rubin  wrote:
> Tim Harig  writes:
>> Those who are concerned about performance should check out Go.
>> Garbage collection, duck typing, and compiles to a native binary.
>> It creates a great middle ground between C++ and Python.  Any C and/or
>> Python programmer will feel right at home with the language.  It is
>> still a young language; but, I have been using it for some useful things.
>
> Go has some nice aspects but it is much lower level than Python.  If you

It is a little lower; but, I wouldn't say much lower.  My Go code is
much more similar in concept, feel, and size to my Python code then it
is to my C code.

> want a statically typed, compiled language closer to Python's level, I
> know of some projects that have switched from Python to Ocaml.  If you

I have head good things about Ocaml; but, I have never taken the time to
learn the language myself.  It never reached a critical mass of interest
from me to consider adopting it.  One of the things that gives me hope
for Go is that it is backed by Google so I expect that it may gain some
rather rapid adoption.  It has made enough of a wake to grab one of
Eweek's 18 top languages for 2011.

http://www.eweek.com/c/a/Application-Development/Java-C-C-Top-18-Programming-Languages-for-2011-480790/

> want dynamic types, I guess there's Dylan, Lisp, or possibly Erlang.

I am a big fan of Erlang and it's ability to create fault tolerant
systems; but, it isn't really a general purpose programming language.
It also runs inside of a VM which means that it doesn't produce native
binary.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sun, 16 Jan 2011 09:47:35 +, Tim Harig wrote:

> One of the things that gives me hope
> for Go is that it is backed by Google so I expect that it may gain some
> rather rapid adoption.  It has made enough of a wake to grab one of
> Eweek's 18 top languages for 2011.

If the author thinks that Go is a "tried and true" (his words, not mine) 
language "where programmers can go to look for work", I think he's 
fooling himself.

When I design my new language, I will make sure I choose a name such that 
any attempt to search for it on job sites will produce oodles and oodles 
and oodles of false positives, all the better to ensure that simple-
minded "top language of ..." surveys will give a massively inflated job 
count.

I think I'll call it "Salary".



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

Re: Does Python 3.1 accept \r\n in compile()?

[jmfauth]

Just an info, addendum.

>>> sys.version
'3.2rc1 (r32rc1:88035, Jan 15 2011, 21:05:51) [MSC v.1500 32 bit
(Intel)]'
>>> compile('if True:\r\nprint(999)\r\n', '', 'exec')

 at 0x023CA610, file "", line 2>
>>> exec(compile('if True:\r\nprint(999)\r\n', '', 'exec'))
999
>>>


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

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

[Tim Harig]

On 2011-01-16, Steven D'Aprano  wrote:
> On Sun, 16 Jan 2011 09:47:35 +, Tim Harig wrote:
>
>> One of the things that gives me hope
>> for Go is that it is backed by Google so I expect that it may gain some
>> rather rapid adoption.  It has made enough of a wake to grab one of
>> Eweek's 18 top languages for 2011.
>
> If the author thinks that Go is a "tried and true" (his words, not mine) 
> language "where programmers can go to look for work", I think he's 
> fooling himself.

No I wouldn't say that it has reached market penetration yet; but, it
has more momentum then any language I am familiar with.  I wouldn't be
at all surprised to see it becoming quite common in the next five years.

How long has it taken Python to reach its present level of market
penetration?  And, I still don't see a huge amount of professional Python
use outside of web developement.  Go has only been public for less then
a year.

Personally, I think the time is ripe for a language that bridges the
gap between ease of use dynamic languages with the performance and
distribution capabilities of a full systems level language.  This is after
all the promise the VM based languages made but never really fulfilled.
It is also high time for a fully concurrent language fully capable of
taking advantage of multicore processors without having to deal with the
inherent dangers of threading.  There are several good choices available
for both a even a few that fit both bills; but, few of them have the
support of a company like Google that is capable of the push required
to move the language into the mainstream.

> When I design my new language, I will make sure I choose a name such that 
> any attempt to search for it on job sites will produce oodles and oodles 
> and oodles of false positives, all the better to ensure that simple-
> minded "top language of ..." surveys will give a massively inflated job 
> count.

I would agree that Go wasn't the best idea for a language name from the
search perspective.  One would have though a company like Google would have
been cognizant of those limitations...
-- 
http://mail.python.org/mailman/listinfo/python-list

Functions Not Fun (yet)-please help!

[Cathy James]

Dear all,

I can't thank you enough for taking time from your busy schedules to assist
me (and others) in my baby steps with Python. Learning about functions now
and wondering about some things commented in my code below. Maybe someone
can break it down for me and show me why i cant print the function i
created. I am using IDLE, saved it as .py

def my_func(a, b="b is a default" ,c="c is another default"):
print (a)
print (b)
print (c)


#printing the function itself:

#1. assign value to a only, b and c as default:
a= "testing"
print (my_func(a,b,c)) #why does program say c is not defined, tho default
in function above?
#2. assign a and b only, c is default
print my_func(a="testing a", b="testing b")
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Adam Skutt]

On Jan 14, 5:17 pm, Albert van der Horst 
wrote:
>
> I really don't follow that. You need a tremendous set to write gimp.
> Obviously you won't write gimp in Python.
>

You need a tremendous set to write /the majority of the applications
on your computer/.

On my desktop right now, I have running:
* Google Chrome
* TweetDeck
* PuTTY
* Pidgin
* Game for Windows Launcher
* Free Download Manager
* Steam Client
* A Windows Control Panel Window

None of those applications could be written with his proposed widget
set, he's literally 0/7 on running applications.  If the situation
isn't the same on your computer then your application usage is highly
unusual or you don't understand what widgets are used to construct
your applications.  You've just told me that Python would no longer be
suitable for constructing the majority of GUI applications on the
planet.

> Now you want to jot together three cooperating screens to specify
> some properties for say bluetooth. The proposed set is ample for
> that, no?

Yes, but why would I ever do such a thing?  Such things are provided
for me by the operating system already, pretty much regardless of
platform.  His widget set is quite truly only good for OS utilities,
but I already have those.  I generally don't need nor want more of
them.  Neither do Python users, because the majority of us aren't
writing OS utilities.

That leaves the logical equivalent of traditional terrible, awful
Visual Basic applications left, and even Microsoft gives them a full
widget set (and "real" programming language) now in VB.NET.  The
effort involved in segmentation doesn't make things any easier and
doesn't save them, the library authors, much of anything.

> Such things make up a substantial part of the applications
> as far as numbers is concerned. They are probably written by
> people who don't want to dive very deeply into GUI.
> (Maybe they are more bluetooth experts than GUI-experts, what
> would you say?)
>

I could list every application on the my computer and make a table of
which ones would be workable given the list above, but I can already
tell you that the answer is, "Not very many, and most of the ones that
can were written by MS".  And I'm entirely ignoring issues like
theming as well.  Adding a few additional layout controls would expand
the list a moderate deal, but that's going to be true pretty much
regardless of which 3 or 4 additional widgets you pick.

And this ignores the obvious, "You'd still need a full WxWidgets
install in order to build the minimized set, so all you've saved is a
few .py files" part of the argument, which is just as compelling, if
not more so.

Really, if you believe the case to be otherwise, I truly believe you
aren't paying attention to your own computer(s), or don't understand
how the applications you use are constructed.  What's out there isn't
interesting, it's what people use that's interesting, and people tend
to use GUIs that are moderately to highly complicated.

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

Re: Functions Not Fun (yet)-please help!

[Emile van Sebille]

On 1/16/2011 6:49 AM Cathy James said...

Dear all,

I can't thank you enough for taking time from your busy schedules to assist
me (and others) in my baby steps with Python. Learning about functions now
and wondering about some things commented in my code below. Maybe someone
can break it down for me and show me why i cant print the function i
created. I am using IDLE, saved it as .py

def my_func(a, b="b is a default" ,c="c is another default"):
 print (a)
 print (b)
 print (c)


#printing the function itself:

#1. assign value to a only, b and c as default:
a= "testing"
print (my_func(a,b,c)) #why does program say c is not defined, tho default
in function above?


Because c is not defined in the scope outside the function where you are 
passing the variables into my_func. To see the effect of the defaults, 
call with only 'a', as otherwise any variables you pass in must have 
been previously defined.


>>> print (my_func(a))
testing
b is a default
c is another default
None
>>>

Emile


#2. assign a and b only, c is default
print my_func(a="testing a", b="testing b")





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

[PYTHON] threading: Parallel processing

[Moses]

Hi All,

Is there is a way to print or use the value of new in the main function of
the script below?


from thread import start_new_thread, allocate_lock

num_threads = 0
thread_started = False
lock = allocate_lock()

def heron(a):
global num_threads, thread_started
lock.acquire()
num_threads += 1
thread_started = True
lock.release()
"""Calculates the square root of a"""
eps = 0.001
old = 1
new = 1
while True:
old,new = new, (new + a/new) / 2.0
print old, new
if abs(new - old) < eps:
break
lock.acquire()
num_threads -= 1
lock.release()
return new

start_new_thread(heron,(81,))
start_new_thread(heron,(999,))
start_new_thread(heron,(1733,))


while not thread_started:
pass
while num_threads > 0:
pass

Thanks,

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

Re: After C++, what with Python?

[David Boddie]

On Sunday 16 January 2011 08:35, geremy condra wrote:

> On Sat, Jan 15, 2011 at 9:30 PM, Aman  wrote:

>> It would be great if you people could guide me as to what to proceed with
>> and how.
> 
> Here's what I would do:

[Snip advice]

Maybe it would be good to expand the Getting Started material in the
Python Wiki with your advice, Geremy. It would save you the trouble
of having to type it all over again the next time a similar question
is asked.

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

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

[rantingrick]

On Jan 16, 9:18 am, Adam Skutt  wrote:

> You need a tremendous set to write /the majority of the applications
> on your computer/.

[...snip incessant rambling...]

Adam your post is so incoherent that i cannot decide if you are FOR or
AGAINST changing the current Tkinter GUI module into a wxPython GUI
module. And this widget set that you keep referring to is a bit vague
also. So i will quote myself because i *think* this may be what "it"
referres to...

###
# Start Quote by Rick #
###
Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...
Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar
...thats all you need in the std library "widget wise".
#
# End Quote by Rick #
#

If you cannot relize that this is exactly what we have now in Tkinter
then you need to go and read the source for Tkinter. Oh hell, i'd
better do it for you. Watch this...

>>> f = open('C:\\Python26\\Lib\\lib-tk\\Tkinter.py')
>>> s = f.read()
>>> f.close()
>>> import re
>>> re.findall(r'class (\w+)\(', s)
['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 'BaseWidget',
'Widget', 'Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry',
'Frame', 'Label', 'Listbox', 'Menu', 'Menubutton', 'Message',
'Radiobutton', 'Scale', 'Scrollbar', 'Text', 'OptionMenu',
'PhotoImage', 'BitmapImage', 'Spinbox', 'LabelFrame', 'PanedWindow',
'Studbutton', 'Tributton']

Now what seems to be missing from my proposed widget set that hampers
you from re-creating every GUI app on your computer? And just in case
you did not notice "my proposed wxPython module" includes the exact
same widget set. Ok, Ok, i let out image support but in my mind PIL
should handle all of that. The IntVar, StringVar, and BooleanVar
classes are non-applicable in a wx GUI. So just for your sake i shall
"lower the bar of comprehension"...

>>> tkclasses = re.findall(r'class (\w+)\(', s)
>>> omit = ['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 
>>> 'BaseWidget', 'Widget', 'Frame', 'Message', 'OptionMenu', 'LabelFrame', 
>>> 'PanedWindow', 'Studbutton', 'Tributton']
>>> [x for x in tkclasses if x not in omit]
['Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry', 'Label',
'Listbox', 'Menu', 'Menubutton', 'Radiobutton', 'Scale', 'Scrollbar',
'Text', 'PhotoImage', 'BitmapImage', 'Spinbox']

There you have it. The same exact widget set we have now. Sure you
cannot re-create every GUI app on your stinking computer however if
you download the 3rd party wxPython extension module not only will you
be able to re-create every GUI app on your stinking computer it will
wipe your backside too! (psst: "it" refers to wxPython)

i hope you learned something from this exercise Adam.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Developing a program to make a family tree.

[rantingrick]

On Jan 15, 3:43 pm, Michael Hunter  wrote:

> I think you are probably coming at this from the wrong direction.
> Either you want to solve your family tree problem in the easiest way
> possible in which case there are already packages available or you
> want to develop this because you want to do the project to learn
> (more) python, etc.  Assuming the later the fact you have to ask the
> question in the way you did means you are short on software design
> experience and don't know much about the problem domain (genealogy).
> Additionally you probably havn't written much code although you came
> here so you probably have a little experience.  That is triple death.
> You need to hold a couple of those variables stable.  I'd suggest
> finding a existing open source genealogy program and use bug fixing as
> a way to learn basics about the package and then try to add a feature
> as a way of learning something about software design.


While i mostly agree with this statement i must also whole-heart-ly
disagree.

 I have many projects that i am currently "developing" that are far
beyond my skill set at this time. However this "lack of experience"
within the problem domain does not scare me away. Actually i want to
learn how many things work "under the hood". So what i do is develop
and design until i hit a wall. Then i move over to another project and
develop and design until i hit another wall. Sometimes i have to go
back and re-write the hole thing, but hey, its part of the learning
curve.

 And in the process something interesting always happens... I find
that solving one problem lends knowledge and insight into another
completely different problem. This technique may not be for the weak
of heart but it works well for me. I like a challenge. I also like to
learn. So this drives me to keep going.

I can tell you that i have written code i previously thought was
impossible for me to create. Nothing is impossible if you want it bad
enough or if you can manage to live long enough! :). Sadly even if
your thirst for knowledge is unquenchable, your life will be quenched
in due time :(. But i do not want to image a world where we all live
forever, what a nightmare!

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

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

[Kevin Walzer]

On 1/16/11 11:30 AM, rantingrick wrote:



###
# Start Quote by Rick #
###
Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...
Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar
...thats all you need in the std library "widget wise".


Rick,

So, after all this discussion, your idea (it's not quite a proposal 
since you haven't initiated the PEP process for it)  boils down to 
replacing Tkinter in the stdlib with a very stripped-down subset of 
wxPython?


I'm not quite clear on what this accomplishes. Some of these widgets in 
Tkinter are ugly, but they have themed (ttk) equivalents (such as label, 
entry, button) that wrap native widgets in a manner similar to wxPython. 
So there's no real advantage to wx here.


Your suggestion that developers who want a larger widget set can 
download the entire wxPython package is, again, answered by the 
observation that numerous Tk extensions, with Tkinter wrappers, exist to 
expand the standard Tk widget set. And there are pure-Python extension 
packages that are not dependent on binary Tk extensions, cf. Python 
Megawidgets. Again, no real advantage to wxPython.


Your initial criticism that Python's standard GUI toolkit should not 
dependent on the priorities and development schedule of an outside 
project (Tcl/Tk) seems to have gone by the wayside here, because 
wxPython is an outside project (led by Robin Dunn) that is in turn 
dependent on the timeline of yet another outside project--wxWidgets, the 
underlying C++ library.


Finally, there are licensing issues to consider. Tcl/Tk's license is 
very liberal, BSD-style, and it is quite similar to Python's. wxWidget's 
library is basically LGPL with a couple of exceptions to make it 
friendlier to proprietary software. Could code under such a license be 
gracefully included in the stlib?


--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: [python-committers] [RELEASED] Python 3.2 rc 1

[Terry Reedy]

On 1/16/2011 4:10 AM, Mark Summerfield wrote:


Regarding http://docs.python.org/dev/whatsnew/3.2.html

- in the first argparse example the comment says "one of four allowed
   values", but the choices list has only three items so I wonder if this
   is correct?

- in the coverage of PEP  code points are written as u and u00FF
   which is non-standard; one standard way to write them is U+ and
   U+00FF


Both fixed.


I love the clickable table of built-in functions in functions.html.


I do too.


On debian testing 64-bit make test resulted in:
...
However, I hit a problem with relative imports not working (compared
with 3.1). I have to go now but will try to produce a small example if I
can.


--
Terry Jan Reedy

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

Re: Issue 1602, cp65001, powershell and python3 crash

[Terry Reedy]

On 1/16/2011 4:22 AM, jmfauth wrote:

After having read the discussion about the issue 1602,
http://bugs.python.org/issue1602, I came to the idea
to test Python with the PowerShell. I thought, it
could help and manage "unicode" better than the
std "dosbox" does

My experience with PowerShell is closed to zero, so
take the following as a flat raw information.

1) Setup the coding in PowerShell (font: Consolas)

PS D:\jm>  $OutputEncoding


IsSingleByte  : True
BodyName  : us-ascii
EncodingName  : US-ASCII
HeaderName: us-ascii
WebName   : us-ascii
WindowsCodePage   : 1252
IsBrowserDisplay  : False
IsBrowserSave : False
IsMailNewsDisplay : True
IsMailNewsSave: True
EncoderFallback   : System.Text.EncoderReplacementFallback
DecoderFallback   : System.Text.DecoderReplacementFallback
IsReadOnly: True
CodePage  : 20127

PS D:\jm>  chcp 65001
Page de codes active : 65001

PS D:\jm>  $OutputEncoding = [Console]::OutputEncoding
PS D:\jm>  $OutputEncoding


BodyName  : utf-8
EncodingName  : Unicode (UTF-8)
HeaderName: utf-8
WebName   : utf-8
WindowsCodePage   : 1200
IsBrowserDisplay  : True
IsBrowserSave : True
IsMailNewsDisplay : True
IsMailNewsSave: True
IsSingleByte  : False
EncoderFallback   : System.Text.EncoderReplacementFallback
DecoderFallback   : System.Text.DecoderReplacementFallback
IsReadOnly: True
CodePage  : 65001


So far, so good. It seems I can enter and display "unicode
characters" (as opposed to cp850).

PS D:\jm>  echo 'abc逜Üß'
abc逜Üß
PS D:\jm>  chcp
Page de codes active : 65001
PS D:\jm>

2) Python test

PS D:\jm>  c:\python31\python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard
streams
LookupError: unknown encoding: cp65001

This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
PS D:\jm>

Obviously and expectedly Python does not recognize cp65001.
That's not the problem.

The main concern is, Python crashes with the usual msgbox,
"python.exe has stopped working ..." .

win7 pro (32 bits), Swiss French setup, cp850/cp1252, Python 3.1.2 .

Take this a raw information and do not ask me what's happen
behind the scene.

Last minute info:
Python 3.2.rc1: same behaviour.


Could you add this report, slightly condensed, to the issue?


--
Terry Jan Reedy


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

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

[rantingrick]

On Jan 16, 11:39 am, Kevin Walzer  wrote:

First of all welcome back to the discussion Kevin. You and i both
appreciate and use Tkinter extensively and your input is most welcome
here. You are a smart and level headed fella which makes for good
discussion. Thanks for that! Ok, let the battle begin! :-)

> So, after all this discussion, your idea (it's not quite a proposal
> since you haven't initiated the PEP process for it)  boils down to
> replacing Tkinter in the stdlib with a very stripped-down subset of
> wxPython?

Exactly (almost). However I need to stress that nothing will be lost
to the user when this change happens! On the contrary, much will be
gained. You're going to have the same basic capabilities as you have
now in the stdlib with Tkinter HOWEVER, you can download all the
feature rich goodies that only wx can offer.

> I'm not quite clear on what this accomplishes. Some of these widgets in
> Tkinter are ugly, but they have themed (ttk) equivalents (such as label,
> entry, button) that wrap native widgets in a manner similar to wxPython.
> So there's no real advantage to wx here.

This statement is uninformed Kevin. Wx needs no themed widgets because
the default widgets where created equal from day one. TclTk has always
been behind in look and feel. Yes we do now FINALLY have themed
widgets however this does not make TclTk equal to wxPython in any
shape or form. Kevin i ask that you and everyone else who may be
interested in this community to download the wxPython demo. This demo
(which is a work of art in it's own right!) will be all you need to
understand the vast differences between TclTk and wxPython. You can
get it here...

http://www.wxpython.org/download.php#stable

If for some reason you cannot download this beautiful demo, then at
least look at the awesome screen shots here...

http://www.wxpython.org/screenshots.php


> Your suggestion that developers who want a larger widget set can
> download the entire wxPython package is, again, answered by the
> observation that numerous Tk extensions, with Tkinter wrappers, exist to
> expand the standard Tk widget set. And there are pure-Python extension
> packages that are not dependent on binary Tk extensions, cf. Python
> Megawidgets. Again, no real advantage to wxPython.

Wrong. Even with the hodgepodge of third party downloads and extension
packages Tkinter cannot hold a candle to the professional quality of
wxPython. Again i urge you to at least download the demo and see for
yourself. WxPython is a massive library of almost any widget you can
imagine using in the 21st century. All of the hard work has been done
for you, no need to create your own custom widgets again and again. Do
yourself a favor and download the demo. Here it is again...

http://www.wxpython.org/download.php#stable


> Your initial criticism that Python's standard GUI toolkit should not
> dependent on the priorities and development schedule of an outside
> project (Tcl/Tk) seems to have gone by the wayside here, because
> wxPython is an outside project (led by Robin Dunn) that is in turn
> dependent on the timeline of yet another outside project--wxWidgets, the
> underlying C++ library.

Yes, we will always be at the mercy of another development community
unless we build a real Python GUI. Well newsflash, that dream is not
going to happen because we would need to re-invent the wheel many
times over and not to mention the long bug fix time-line. However
let's get back to reality and compare wxPython to TclTk+Tkinter.

First of all wxPython IS a part of the Python community. They DO care
about Python and Python only. Yes WxWidgets IS NOT part of our
community, however the widget set is so mature that we don't need to
worry about version releases. We could live off the current widget set
unchanged for many years to come!! Compare that to TclTk who only
cares about TclTk and the fact that TclTk is not ANYWHERE near the
maturity of wxPython. With Tkinter we WILL need to update as new
widgets and functionality come into being.  Oh did i forget to give
you a link to the beautiful wxDemo, ok here it is...

   http://www.wxpython.org/download.php#stable


> Finally, there are licensing issues to consider. Tcl/Tk's license is
> very liberal, BSD-style, and it is quite similar to Python's. wxWidget's
> library is basically LGPL with a couple of exceptions to make it
> friendlier to proprietary software. Could code under such a license be
> gracefully included in the stlib?

Well we need the license lawyers to weigh in on that aspect. If
wxPythons license is weighed and found wanting then we must consider
something else. However, i will tell you that nothing else exists that
can match the maturity, cross-platform, and feature rich-ness of wx.
If someone knows of any such package by all means speak up!

In any event, the time to start looking for something more appropriate
to this community in the 21st century has long passed. We have allowed
Tkinter to rot and grow pun

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

[Terry Reedy]

On 1/16/2011 11:30 AM, rantingrick wrote:


Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar
...thats all you need in the std library "widget wise".


Once IDLE is revised to use some of the widgets in ttk that are not in 
tk (such as Notebook) the set would need expansion. But the details of 
any such set are irrelevant to the main problems of replacement.


--
Terry Jan Reedy

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

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

[Kevin Walzer]

On 1/16/11 1:27 PM, rantingrick wrote:

On Jan 16, 11:39 am, Kevin Walzer  wrote:

First of all welcome back to the discussion Kevin. You and i both
appreciate and use Tkinter extensively and your input is most welcome
here. You are a smart and level headed fella which makes for good
discussion. Thanks for that! Ok, let the battle begin! :-)


Glad to be back.


Wrong. Even with the hodgepodge of third party downloads and extension
packages Tkinter cannot hold a candle to the professional quality of
wxPython. Again i urge you to at least download the demo and see for
yourself. WxPython is a massive library of almost any widget you can
imagine using in the 21st century. All of the hard work has been done
for you, no need to create your own custom widgets again and again. Do
yourself a favor and download the demo. Here it is again...


I'm quite familiar with the wxPython demo. I've got the latest 
incarnation, from 2.9.x, installed on my machine. The latest version is 
quite nice, especially with the AUI widgets, and the underlying 
wxWidgets libraries are finally up-to-date on my Mac as they access the 
Cocoa frameworks, rather than the deprecated Carbon frameworks.


However, wxPython does lack some things on my Mac, which I have been 
able to implement in Tk. Specifically:


1. My Tkinter apps can access the Mac's Services menu, which provides a 
form of inter-application communication that allows one application to 
send data to another and have the target application perform some 
manipulation of that data. wxPython does not support this feature of the 
Mac.


2. Any wxPython application that attempts to display the filesystem on 
the Mac looks out-of-place because wx has no support for displaying 
native icons on the Mac, though it can display them in Windows.  Tk on 
the Mac has a few different ways of displaying icons natively.


3. wxPython applications do not make use of common window flags on the 
Mac, such as sheets and drawers. Tk provides native support for some of 
this, and extension packages provide further support.


So: while wxPython is quite capable of creating handsome applications, 
even on the Mac, there are subtle things about wxPython applications 
that make them feel not quite native, regardless of how rich the overall 
widget set is.


Part of my preference for Tkinter is that, under the hood, Tk is much, 
much easier to extend than wxWidgets. I have written several libraries 
in Objective-C, using Tk's C API, that hook into various aspects of 
native Mac functionality, such as the Services menu. Once this 
functionality is accessible from Tk, it's trivial to write a Python 
wrapper for it; it's often as easy as 'root.tk.call', 'nativetclcode here'.


As I understand it, extending wxWidgets requires coding in C++, and then 
you'd need to run your code through SWIG in some fashion to be able to 
access it from wxPython. In short, there are several more steps, and 
it's likely more complicated at each step.  For various reasons, the 
things I think are missing from wxWidgets (native icons, sheets/drawers, 
etc.) are not considered important by the core wxWidget developers, or 
implementing them is a low priority.



Well we need the license lawyers to weigh in on that aspect. If
wxPythons license is weighed and found wanting then we must consider
something else. However, i will tell you that nothing else exists that
can match the maturity, cross-platform, and feature rich-ness of wx.
If someone knows of any such package by all means speak up!


Well, PyQt comes to mind. Qt is better at native Mac implementation than 
wx in many respects (window flags, accessing native Mac icons), and 
overall it is a richer framework (its support for WebKit is amazing), 
but PyQt remains licensed under the GPL, which makes it off-limits for 
the stdlib. Plus, there are other Python-Qt implementations out there 
(PySide) that may claim some of PyQt's mindshare in the future.


--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

examples of realistic multiprocessing usage?

[TomF]

I'm trying to multiprocess my python code to take advantage of multiple 
cores.  I've read the module docs for threading and multiprocessing, 
and I've done some web searches.  All the examples I've found are too 
simple: the processes take simple inputs and compute a simple value.  
My problem involves lots of processes, complex data structures, and 
potentially lots of results.  It doesn't map cleanly into a Queue, 
Pool, Manager or Listener/Client example from the python docs.


Instead of explaining my problem and asking for design suggestions, 
I'll ask: is there a compendium of realistic Python multiprocessing 
examples somewhere?  Or an open source project to look at?


Thanks,
-Tom

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

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

[rantingrick]

On Jan 16, 12:49 pm, Terry Reedy  wrote:

> Once IDLE is revised to use some of the widgets in ttk that are not in
> tk (such as Notebook) the set would need expansion.

The IDLE library has had a NoteBook widget for ages. They just choose
to call it TabPages instead. And what is a NoteBook exactly? Well a
Notebook is a compound widget consisting of a "main frame that holds
two sub frames -- which are a "tab" frame and "pages" frame. When any
"tab" is clicked the page it is linked to is either *raised-to-the-top-
of-the-stack* OR *made-visible* depending on the design. Each "tab"
within the "tab frame" is a Radiobutton. Technically you could even
consider a RadioButton as a compound widget consisting of a button and
a label widget. And one could even dissect further the components of
any such widget however we must stop at some point. The widgets i
outlined are the highest of the lowest you'd want to consider.

I believe compound widgets have no business in the stdlib. When Guido
included Tkinter in the stdlib it was mainly for ease of introductory
GUI programming to the uninitiaed and for batteries included. However
since we do have a "batteries included" mantra we will need to hash
out which compound widgets should be included in the stdlib -- at a
later time! At this time the discussion needs to focus on defending OR
replacing Tkinter with something better. And my position is that we
cannot keep lugging around this ancient TclTk library.

> But the details of
> any such set are irrelevant to the main problems of replacement.

Not exactly. Once a library has been chosen we will need to consider a
small subset for inclusion in the stdlib and ONE large extension
library. So these problems are very relevant -- albeit out of
chronological order.



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

Re: examples of realistic multiprocessing usage?

[Adam Tauno Williams]

> Instead of explaining my problem and asking for design suggestions, 
> I'll ask: is there a compendium of realistic Python multiprocessing 
> examples somewhere? 

Not that I've ever seen.

> Or an open source project to look at?

OpenGroupware Coils uses multiprocessing [in conjunction with AMQ].


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

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

[rantingrick]

On Jan 16, 12:59 pm, Kevin Walzer  wrote:

> I'm quite familiar with the wxPython demo. I've got the latest
> incarnation, from 2.9.x, installed on my machine. The latest version is
> quite nice, especially with the AUI widgets, and the underlying
> wxWidgets libraries are finally up-to-date on my Mac as they access the
> Cocoa frameworks, rather than the deprecated Carbon frameworks.

Glad to hear that! :)

> However, wxPython does lack some things on my Mac, which I have been
> able to implement in Tk. Specifically:
>
> 1. My Tkinter apps can access the Mac's Services menu, which provides a
> form of inter-application communication that allows one application to
> send data to another and have the target application perform some
> manipulation of that data. wxPython does not support this feature of the
> Mac.

Ok so you're complaining about a "Mac specific" missing functionality?

> 2. Any wxPython application that attempts to display the filesystem on
> the Mac looks out-of-place because wx has no support for displaying
> native icons on the Mac, though it can display them in Windows.  Tk on
> the Mac has a few different ways of displaying icons natively.

Ok, even if it looks "out of place" this is another "Mac Specific"
problem.

> 3. wxPython applications do not make use of common window flags on the
> Mac, such as sheets and drawers. Tk provides native support for some of
> this, and extension packages provide further support.

"Mac Specific"

> So: while wxPython is quite capable of creating handsome applications,
> even on the Mac, there are subtle things about wxPython applications
> that make them feel not quite native, regardless of how rich the overall
> widget set is.

I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.

> As I understand it, extending wxWidgets requires coding in C++, and then
> you'd need to run your code through SWIG in some fashion to be able to
> access it from wxPython. In short, there are several more steps, and
> it's likely more complicated at each step.  For various reasons, the
> things I think are missing from wxWidgets (native icons, sheets/drawers,
> etc.) are not considered important by the core wxWidget developers, or
> implementing them is a low priority.

Well this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?

> Well, PyQt comes to mind. Qt is better at native Mac implementation than
> wx in many respects (window flags, accessing native Mac icons), and
> overall it is a richer framework (its support for WebKit is amazing),
> but PyQt remains licensed under the GPL, which makes it off-limits for
> the stdlib. Plus, there are other Python-Qt implementations out there
> (PySide) that may claim some of PyQt's mindshare in the future.

I am willing to support any GUI library that will move us forward and
TclTk is dead weight. I like the feature rich nature of wx however i
will consider others if a "compelling" argument is put forward.
-- 
http://mail.python.org/mailman/listinfo/python-list

Not clear about the dot notation

[Zeynel]

What does vote.vote refer to in this snippet?

def txn():
quote = Quote.get_by_id(quote_id)
vote = Vote.get_by_key_name(key_names = user.email(), parent =
quote)
if vote is None:
vote = Vote(key_name = user.email(), parent = quote)
if vote.vote == newvote:
return
quote.votesum = quote.votesum - vote.vote + newvote
vote.vote = newvote

from here: http://code.google.com/appengine/articles/overheard.html
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Functions Not Fun (yet)-please help!

[Joe Goldthwaite]

Hi Kathy,

 

The defaults only get assigned when you leave them out of the list. This
will work the way you want by setting b & c to the defaults.

 

print my_func(a)

 

When  you try this;

 

a = "testing"

b = "defaults"

print my_func(a, b, c)

 

You get an undefined error on c.  This is because at this point, c has been
created but hasn't had anything assigned to it.  In other words, you're
actually passing the undefined c variable from here into my_func.

  _  

From: python-list-bounces+joe=goldthwaites@python.org
[mailto:python-list-bounces+joe=goldthwaites@python.org] On Behalf Of
Cathy James
Sent: Sunday, January 16, 2011 7:49 AM
To: python-list@python.org
Subject: Functions Not Fun (yet)-please help!

 

Dear all,

 

I can't thank you enough for taking time from your busy schedules to assist
me (and others) in my baby steps with Python. Learning about functions now
and wondering about some things commented in my code below. Maybe someone
can break it down for me and show me why i cant print the function i
created. I am using IDLE, saved it as .py

 

def my_func(a, b="b is a default" ,c="c is another default"):
print (a)
print (b)
print (c)


#printing the function itself:

#1. assign value to a only, b and c as default:
a= "testing"
print (my_func(a,b,c)) #why does program say c is not defined, tho default
in function above?
#2. assign a and b only, c is default
print my_func(a="testing a", b="testing b")

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

Re: Not clear about the dot notation

[TomF]

On 2011-01-16 11:59:11 -0800, Zeynel said:


What does vote.vote refer to in this snippet?

def txn():
quote = Quote.get_by_id(quote_id)
vote = Vote.get_by_key_name(key_names = user.email(), parent =
quote)
if vote is None:
vote = Vote(key_name = user.email(), parent = quote)
if vote.vote == newvote:
return
quote.votesum = quote.votesum - vote.vote + newvote
vote.vote = newvote

from here: http://code.google.com/appengine/articles/overheard.html


vote refers to the Vote instance.
vote.vote refers to the instance variable in that instance:
      vote: The value of 1 for like, -1 for dislike.

Confusing choice of names, in my opinion.

-Tom

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

Re: Not clear about the dot notation

[Ian Kelly]

On 1/16/2011 12:59 PM, Zeynel wrote:

What does vote.vote refer to in this snippet?


"vote" is an instance of the Vote class, and "vote.vote" is the value of 
the "vote" attribute on that instance.  In this case, that will be an int.


More precisely, "vote.vote" is a value managed by the "vote" descriptor 
on the "Vote" class, a Google App Engine IntegerProperty.


Cheers,
Ian

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

Re: Not clear about the dot notation

[Zeynel]

On Jan 16, 3:24 pm, TomF  wrote:

> vote refers to the Vote instance.

So he must have instatiated previously like

vote = Vote()

is this correct?

So I have a model

class Item(db.Model):
title = db.StringProperty()
url = db.StringProperty()
date = db.DateTimeProperty(auto_now_add=True)
author = db.UserProperty()

and to write to the database I do

item = Item()
item.title = self.request.get("title")
item.url = self.request.get("url")
item.author = users.get_current_user()
item.put()
self.redirect("/newest")

so his vote.vote is like my item.url ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: examples of realistic multiprocessing usage?

[Philip Semanchuk]

On Jan 16, 2011, at 2:05 PM, TomF wrote:

> I'm trying to multiprocess my python code to take advantage of multiple 
> cores.  I've read the module docs for threading and multiprocessing, and I've 
> done some web searches.  All the examples I've found are too simple: the 
> processes take simple inputs and compute a simple value.  My problem involves 
> lots of processes, complex data structures, and potentially lots of results.  
> It doesn't map cleanly into a Queue, Pool, Manager or Listener/Client example 
> from the python docs.
> 
> Instead of explaining my problem and asking for design suggestions, I'll ask: 
> is there a compendium of realistic Python multiprocessing examples somewhere? 
>  Or an open source project to look at?


A colleague pointed me to this project the other day. 

http://gluino.com/


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.

Hope it's of some help to you, though.

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

Re: Not clear about the dot notation

[TomF]

On 2011-01-16 12:44:35 -0800, Zeynel said:


On Jan 16, 3:24 pm, TomF  wrote:


vote refers to the Vote instance.


So he must have instatiated previously like

vote = Vote()

is this correct?


Yes.



So I have a model

class Item(db.Model):
title = db.StringProperty()
url = db.StringProperty()
date = db.DateTimeProperty(auto_now_add=True)
author = db.UserProperty()

and to write to the database I do

item = Item()
item.title = self.request.get("title")
item.url = self.request.get("url")
item.author = users.get_current_user()
item.put()
self.redirect("/newest")

so his vote.vote is like my item.url ?


I believe so.  Though you're now talking about an extension to db.Model 
which looks like it's doing a lot more behind the scenes than a simple 
variable access.


-Tom

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

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

[rantingrick]

On Jan 16, 5:03 am, Tim Harig  wrote:

> Personally, I think the time is ripe for a language that bridges the
> gap between ease of use dynamic languages with the performance and
> distribution capabilities of a full systems level language.  

Bravo!

> This is after
> all the promise the VM based languages made but never really fulfilled.
> It is also high time for a fully concurrent language fully capable of
> taking advantage of multicore processors without having to deal with the
> inherent dangers of threading.

Bravissimo!!

> There are several good choices available
> for both a even a few that fit both bills; but, few of them have the
> support of a company like Google that is capable of the push required
> to move the language into the mainstream.

Maybe. I have skimmed over Go and while it looks "somewhat" promising
i always miss the batteries included and elegant syntax of Python. Of
course the language is still young so i hope they plan to invest into
it.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sun, 16 Jan 2011 07:18:16 -0800, Adam Skutt wrote:

[...]

I'm afraid I found most of your post hard to interpret, because you 
didn't give sufficient context for me to understand it. You refer to "his 
proposed widget set", but with no clue as to who he is, or what the 
widget set is, or what essential widgets you continue missing. I can 
guess "he" is rantingrick, but am not sure -- there's only so much of his 
time-wasting I can read before reaching for the killfile. Rantingrick 
believes he is doing us a service by haranguing us incessantly into 
scratching *his* poorly thought-out itches, regardless of practicality or 
actual need.

But putting that aside, I'd like to comment on a few points:

[...]
> If the situation isn't
> the same on your computer then your application usage is highly unusual
> or you don't understand what widgets are used to construct your
> applications.  You've just told me that Python would no longer be
> suitable for constructing the majority of GUI applications on the
> planet.

No, that does not follow. Unless "he" (I'll assume it is rantingrick) has 
proposed hunting down and destroying all third-party GUI tool sets, what 
you've been told is that *one specific* tool set is unsuitable for 
constructing the majority of GUI apps.


[...]
> Really, if you believe the case to be otherwise, I truly believe you
> aren't paying attention to your own computer(s), or don't understand how
> the applications you use are constructed.  What's out there isn't
> interesting, it's what people use that's interesting, and people tend to
> use GUIs that are moderately to highly complicated.

Well, true, but people tend to *use* the parts of the GUIs that are 
simple and basic. Not only do the big complicated apps get all the press 
even when they are actually a niche product (everyone knows about 
Photoshop, but more people use MS Paint) but it's a truism that most 
people use something like 20% of the functionality of big, complicated 
GUI apps. Most people use Microsoft Word or OpenOffice for little more 
than text editing with formatting.

It's easy for power users to overestimate how much of their complicated 
GUIs are actually used by the average user. Or even the *above* average 
user.

I suspect that a variation of Zipf's Law probably holds for GUI 
complexity -- if you rank the widgets in order of most to least commonly 
used, I expect that you'll see actual use drop away rapidly and at an 
accelerated rate. E.g. the widget in second place might be used roughly 
half as often as the widget in first place place, the widget in third 
place one third as often, the widget in fourth place one quarter as 
often, and so forth.


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

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

[Terry Reedy]

On 1/16/2011 1:27 PM, rantingrick wrote:


least look at the awesome screen shots here...

 http://www.wxpython.org/screenshots.php


I did. Well, they say, "Beauty is in the eye of the beholder!". To me, 
these are mostly awesomely ugly, ugly, ugly. Shot 1: Ugly gray field 
followed by shot2: ugly black on gray. These first two examples look 
like Windows 95/8 -- ie, 20th century look, not 21st.


Based on this page, wxwidgets would be a regression from tk. Current 
tkinter on Windows looks like it use native Windows windows. IDLE on 
WinXP looks like a WinXP app; on Windows 7 it looks like a Windows 7 
app. If wxwidgets/wxpython does the same, this page hides it very well. 
And this is apparently an update from 'the old Screen shots' page.


The above is based on presented looks. I have no idea whether, to what 
extent, and how easily one could duplicate the layout and performance of 
the examples with tk. There are, however, other problems with wx that I 
have and will point out in other posts.


--
Terry Jan Reedy

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

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

[Adam Skutt]

On Jan 16, 11:30 am, rantingrick  wrote:

> Adam your post is so incoherent that i cannot decide if you are FOR or
> AGAINST changing the current Tkinter GUI module into a wxPython GUI
> module. And this widget set that you keep referring to is a bit vague
> also.

If you found my post incoherent then you shouldn't be attempting to
respond, you should ask me to fucking clarify!  Funny how when I ask
you technical questions you refuse to respond, but when you find my
post incoherent you find plenty of time to attempt to twist my words
to support your own mental masturbation.

> If you cannot relize that this is exactly what we have now in Tkinter
> then you need to go and read the source for Tkinter. Oh hell, i'd
> better do it for you. Watch this...

As I already told you, if you think that what's contained only in
TkInter is relevant or interesting, then you're hopelessly lost.  In
fact, you're outright trolling.  Python's standard library don't only
include TkInter so only talking about TkInter is entirely
disingenuous.

> Now what seems to be missing from my proposed widget set that hampers
> you from re-creating every GUI app on your computer?

Go download the applications and run them yourself!  If you can't
figure it out from a visual examination, you lack the competence to
bring forward your proposal.  Being able to identify what widgets are
used to create an application is a fundamental, rudimentary skill.  If
you lack that skill, you're tacitly calling all of your credibility
(not that you haven't already done a fine job of demolishing any
assumed credibility on your part) into question.

> Ok, Ok, i let out image support but in my mind PIL
> should handle all of that.

It fundamentally cannot.  That's not how image rendering in native
widgets works.

> There you have it. The same exact widget set we have now. Sure you
> cannot re-create every GUI app on your stinking computer however if
> you download the 3rd party wxPython extension module not only will you
> be able to re-create every GUI app on your stinking computer it will
> wipe your backside too! (psst: "it" refers to wxPython)
>

Again, I've already responded to this in detail, in other postings,
posted serious and detailed technical questions, and asked for your
clarifications.  So instead of posting the same tired, idiotic tripe,
why don't you go find those postings, read them, and respond to them?
Your refusal and/or inability to do so harms your position immensely.

> i hope you learned something from this exercise Adam.

I'm not the one who needs to learn anything.

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

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

[geremy condra]

On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig  wrote:
> On 2011-01-16, Steven D'Aprano  wrote:
>> If the author thinks that Go is a "tried and true" (his words, not mine)
>> language "where programmers can go to look for work", I think he's
>> fooling himself.
>
> No I wouldn't say that it has reached market penetration yet; but, it
> has more momentum then any language I am familiar with.  I wouldn't be
> at all surprised to see it becoming quite common in the next five years.

I would be very surprised if this were the case. As you point out,
languages typically have very long incubation times before they reach
any kind of serious market penetration. This seems doubly true for a
relatively narrowly targeted language that is in many ways on the
wrong side of history.

> How long has it taken Python to reach its present level of market
> penetration?  And, I still don't see a huge amount of professional Python
> use outside of web developement.  Go has only been public for less then
> a year.

Python's very widely used for scripting and related tasks, and has a
pretty big user base in academia and the sciences.

> Personally, I think the time is ripe for a language that bridges the
> gap between ease of use dynamic languages with the performance and
> distribution capabilities of a full systems level language.

I agree. That does not make Go that language, and many of the choices
made during Go's development indicate that they don't think it's that
language either. I'm speaking specifically of its non-object model,
lack of exceptions, etc.

>This is after all the promise the VM based languages made but never
> really fulfilled. It is also high time for a fully concurrent language fully
> capable of taking advantage of multicore processors without having to
> deal with the inherent dangers of threading.  There are several good
> choices available for both a even a few that fit both bills; but, few of
> them have the support of a company like Google that is capable of the
> push required to move the language into the mainstream.

You might be right, but I doubt we'll know one way or the other in the
next 5 years. Personally, I'm hoping that functional language use
continues to grow.

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

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

[Kevin Walzer]

On 1/16/11 2:44 PM, rantingrick wrote:



Ok so you're complaining about a "Mac specific" missing functionality?


Um, yes.


Ok, even if it looks "out of place" this is another "Mac Specific"
problem.


Yes, it sure does. "Mac-specific"=="important."



3. wxPython applications do not make use of common window flags on the
Mac, such as sheets and drawers. Tk provides native support for some of
this, and extension packages provide further support.


"Mac Specific"


Ditto.






I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.


Rick, your statements here are entirely untroubled by facts.:-) First of 
all, Mac OS X *is* Unix, at least according to The Open Group, which 
controls the UNIX trademark and is actually in charge of certifying an 
OS as valid UNIX.  Next, in terms of market share, Apple's machines 
exceeded 10% of the U.S. market (placing them third in shipments behind 
HP and Dell), and run about 4-5% of the market globally. (See 
http://bit.ly/cqxl6L.) In any event, it's a bit more than 0.25%. 
(Actually, according to http://bit.ly/c4PBlm, Linux comes in at around 
0.77%, while Mac OS X comes int around 5%.)




Well this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?


I have commit rights to the Tk core, so it's much easier for me to 
submit bug fixes and patches there. It's not worth my while to do the 
same for wxWidgets.


--Kevin


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

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

[Adam Skutt]

On Jan 16, 6:04 pm, Steven D'Aprano  wrote:
> > If the situation isn't
> > the same on your computer then your application usage is highly unusual
> > or you don't understand what widgets are used to construct your
> > applications.  You've just told me that Python would no longer be
> > suitable for constructing the majority of GUI applications on the
> > planet.
>
> No, that does not follow. Unless "he" (I'll assume it is rantingrick) has
> proposed hunting down and destroying all third-party GUI tool sets, what
> you've been told is that *one specific* tool set is unsuitable for
> constructing the majority of GUI apps.
>

If you're going to expect me to be that pedantic, then pay me the
courtesy of taking the time to find the necessary context.
Nevertheless, it's not the least bit unreasonable to address
deficiencies in the standard library as deficiencies in the language,
like it or not; and since rick's proposal involves regressing the
standard library..

> > Really, if you believe the case to be otherwise, I truly believe you
> > aren't paying attention to your own computer(s), or don't understand how
> > the applications you use are constructed.  What's out there isn't
> > interesting, it's what people use that's interesting, and people tend to
> > use GUIs that are moderately to highly complicated.
>
> Well, true, but people tend to *use* the parts of the GUIs that are
> simple and basic. Not only do the big complicated apps get all the press
> even when they are actually a niche product (everyone knows about
> Photoshop, but more people use MS Paint) but it's a truism that most
> people use something like 20% of the functionality of big, complicated
> GUI apps. Most people use Microsoft Word or OpenOffice for little more
> than text editing with formatting.

First, you can't even build MS Paint from Rick's set / the TkInter set
alone, so you're already way off mark (even ignoring the ribbon in the
latest versions).

Second, relevance?  If I cannot ship the application with only 20% of
the functionality, then your point is meaningless.  Plus, look at my
list more closely: TweetDeck is really little more than a bunch of
listboxes stuck side by side, but we cannot even construct that
without replicating what would be considered standard widgets (mostlu
layout widgets, but still, that's the hardest stuff to get right and
therefore the most important stuff to include).  It is not, from a GUI
L&F perspective, "complicated".  Yet, I still need quite a few widgets
in order to assemble it and make it work.  And many of those widgets
need fairly rich functionality: buttons must support text and images,
listboxes must support embedding more than text, text controls must
support hyperlinks, the various layout panes must support scrollbars,
sizing, and dynamic updates.

> I suspect that a variation of Zipf's Law probably holds for GUI
> complexity -- if you rank the widgets in order of most to least commonly
> used, I expect that you'll see actual use drop away rapidly and at an
> accelerated rate. E.g. the widget in second place might be used roughly
> half as often as the widget in first place place, the widget in third
> place one third as often, the widget in fourth place one quarter as
> often, and so forth.

Perhaps, but the drop off isn't relevant till we approach well over 30
widgets, at least, quite arguably more (since GUI toolkits include
both things that are common, and things that absolutely suck to
program, even if they're not used often).

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

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

[Adam Skutt]

On Jan 16, 2:17 pm, rantingrick  wrote:
> The IDLE library has had a NoteBook widget for ages. They just choose
> to call it TabPages instead. And what is a NoteBook exactly? Well a
> Notebook is a compound widget consisting of a "main frame that holds
> two sub frames -- which are a "tab" frame and "pages" frame. When any
> "tab" is clicked the page it is linked to is either *raised-to-the-top-
> of-the-stack* OR *made-visible* depending on the design. Each "tab"
> within the "tab frame" is a Radiobutton.

You need an eye exam if you actually believe what you just wrote.
TabLayouts are not just two frames and radiobuttons inside a bigger
frame.  To even say that is disingenuous and insulting to every human
who's ever used one.

> I believe compound widgets have no business in the stdlib.

All widgets are compound widgets, ergo you believe no widgets should
be in the stdlib.

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

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

[rantingrick]

On Jan 16, 5:14 pm, Terry Reedy  wrote:
> On 1/16/2011 1:27 PM, rantingrick wrote:
>
> > least look at the awesome screen shots here...
>
> >      http://www.wxpython.org/screenshots.php
>
> I did. Well, they say, "Beauty is in the eye of the beholder!". To me,
> these are mostly awesomely ugly, ugly, ugly. Shot 1: Ugly gray field
> followed by shot2: ugly black on gray. These first two examples look
> like Windows 95/8 -- ie, 20th century look, not 21st.

Now hold on Terry because you are overreacting just a bit here. If you
remember i had requested that everyone download the beautiful demo and
only look at the screen shots as a last resort. It seems you went to
the screenshots page and went home in a huff. However let's
investigate the screen shots with a little more clarity shall we?

#
# Shot1 #
#
 This shot shows the most minimal wx GUI, that is, a simple Toplevel
window and nothing more. And if you took the time to read the captions
above that said... "Here is a screen shot of the "minimal" wxPython
application:"... and the screenshot below that said... "Okay, so it is
very minimal, but it is small enough that the source should be
understandable without somebody holding your hand... Take a peek."...
you probably would not have jumped to such bombastic conclusions.

##
# Shot 2 #
##
 This shot merely builds on shot one. Nothing fancy. They were not
trying to woo you with the most fancy GUI coding available from shot
one (psst: THAT IS WHAT THE DEMO IS FOR!). You must remember that
screen shots are for inquisitive and possible future users. If you
continue to follow along with the shots you'll see the complexity
increase with each shot. It seems to me that "easy intoduction" was
the focus of the screenshots not "selfish vanity" (psst: THAT IS WHAT
THE DEMO IS FOR!)

> Based on this page, wxwidgets would be a regression from tk.

Yes one might come to that conclusion if they are as shallow as you
seem to be behaving Terry. However i urge you to download the wxPython
demo and then give me an honest opinion. but only AFTER you have spent
at least one hour familiarizing yourself with all the feature richness
of this great GUI library. Heck each widget has an overview page, a
source code page, and a demo page all wrapped up into a nice GUI. No
GUI in the world is this user friendly! Geesh!

> Current
> tkinter on Windows looks like it use native Windows windows. IDLE on
> WinXP looks like a WinXP app; on Windows 7 it looks like a Windows 7
> app. If wxwidgets/wxpython does the same, this page hides it very well.
> And this is apparently an update from 'the old Screen shots' page.

I'll agree this screenshots page needs an update. However (like me)
the wxPython folks probably put more time into the demo and thought
that most people would at least download it before jumping to
conclusions about the screenshots without sufficient data. Oh, did i
give you the demo link. No? Well here it is again...

http://www.wxpython.org/download.php#stable

> The above is based on presented looks. I have no idea whether, to what
> extent, and how easily one could duplicate the layout and performance of
> the examples with tk.

Tkinter and all of TclTk cannot hold a matchstick to WxPython in
feature richness. Anyone who says otherwise is ill-informed!

> There are, however, other problems with wx that I
> have and will point out in other posts.

Please elaborate, these are free and open forums as far as know...?
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[rantingrick]

On Jan 16, 5:16 pm, Adam Skutt  wrote:

[...snip: emotionally nonsensical hyperbole...]

Adam. Arguing with you is like masturbating with a cheese-grater...
slightly amusing, but mostly painful. I don't have the energy to chase
my tail like you do.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[geremy condra]

On Sun, Jan 16, 2011 at 4:12 PM, rantingrick  wrote:
>
> I don't have the energy to chase my tail like you do.

Hahahahahahahaha. Troll.

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

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

[rantingrick]

On Jan 16, 6:59 pm, geremy condra  wrote:
> Hahahahahahahaha. Troll.


Coming from someone who actually gives advice on how to troll more
efficiently... now that is ironic!

###
# Geremy Condra From: I strongly dislike Python 3 #
###
Eh, 3 troll points out of 10. Bonus awarded for the gratuitous sexual
reference, but the deductions for lack of finesse more than overcame
it. Some suggestions for next time:
  * use proper punctuation- it lends your posts an air of
seriousness.
  * use the weakest arguments presented- it infuriates those who
support the position you're trolling from as well.
  * overly dramatic statements are a dead giveaway.

Hmm. So i take it you are some sort of *expert* on the matter of
trolling then?

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

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

[geremy condra]

On Sun, Jan 16, 2011 at 5:50 PM, rantingrick  wrote:
> On Jan 16, 6:59 pm, geremy condra  wrote:
>> Hahahahahahahaha. Troll.
>
>
> Coming from someone who actually gives advice on how to troll more
> efficiently... now that is ironic!
>
> ###
> # Geremy Condra From: I strongly dislike Python 3 #
> ###
> Eh, 3 troll points out of 10. Bonus awarded for the gratuitous sexual
> reference, but the deductions for lack of finesse more than overcame
> it. Some suggestions for next time:
>  * use proper punctuation- it lends your posts an air of
> seriousness.
>  * use the weakest arguments presented- it infuriates those who
>    support the position you're trolling from as well.
>  * overly dramatic statements are a dead giveaway.
>
> Hmm. So i take it you are some sort of *expert* on the matter of
> trolling then?

I've read most of your threads, yes.

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

Re: examples of realistic multiprocessing usage?

[Adam Skutt]

On Jan 16, 2:05 pm, TomF  wrote:
> Instead of explaining my problem and asking for design suggestions,
> I'll ask: is there a compendium of realistic Python multiprocessing
> examples somewhere?  Or an open source project to look at?

There are tons, but without even a knowledge domain, it's difficult to
recommend much of anything.  Multiprocessing for I/O (e.g., web
serving) tends to look different and be structured differently from
multiprocessing for CPU-intensive tasking (e.g., digital signal
processing), and both look different from things with specific
requirements w.r.t latency (e.g., video game server, hard-real time
applications) or other requirements.

Even the level at which you parallel process can change things
dramatically.  Consider the simple case of matrix multiplication.  I
can make the multiplication itself parallel; or assuming I have
multiple sets of matricies I want to multiply (common), I can make
execute each multiplication in parallel.  Both solutions look
different, and a solution that uses both levels of parallelism
frequently will look different still.

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

Re: examples of realistic multiprocessing usage?

[Dan Stromberg]

On Sun, Jan 16, 2011 at 11:05 AM, TomF  wrote:
> I'm trying to multiprocess my python code to take advantage of multiple
> cores.  I've read the module docs for threading and multiprocessing, and
> I've done some web searches.  All the examples I've found are too simple:
> the processes take simple inputs and compute a simple value.  My problem
> involves lots of processes, complex data structures, and potentially lots of
> results.  It doesn't map cleanly into a Queue, Pool, Manager or
> Listener/Client example from the python docs.
>
> Instead of explaining my problem and asking for design suggestions, I'll
> ask: is there a compendium of realistic Python multiprocessing examples
> somewhere?  Or an open source project to look at?

I'm unaware of a big archive of projects that use multiprocessing, but
maybe one of the free code search engines could help with that.

It sounds like you're planning to use mutable shared state, which is
generally best avoided if at all possible, in concurrent programming -
because mutable shared state tends to slow down things quite a bit.

But if you must have mutable shared state that's more complex than a
basic scalar or homogeneous array, I believe the multiprocessing
module would have you use a "server process manager".
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

On 1/16/2011 6:58 PM, rantingrick wrote:

On Jan 16, 5:14 pm, Terry Reedy  wrote:

On 1/16/2011 1:27 PM, rantingrick wrote:


least look at the awesome screen shots here...



  http://www.wxpython.org/screenshots.php


I did. Well, they say, "Beauty is in the eye of the beholder!". To me,
these are mostly awesomely ugly, ugly, ugly. Shot 1: Ugly gray field
followed by shot2: ugly black on gray. These first two examples look
like Windows 95/8 -- ie, 20th century look, not 21st.





remember i had requested that everyone download the beautiful demo and
only look at the screen shots as a last resort.


You called them 'awesome'. I did not expect 'awesomely ugly'.

Screenshots are the first thing for someone to look at, to see WHAT THE 
APP LOOKS LIKE, and to decide whether one wants to bother to download, 
switch to admin, install, run, and uninstall (and hope that that really 
disinstalls everything). I looked and decided that what I saw (except 
for the Mac example), was too ugly to bother with, at least for now.


One of the criticisms against tk has been that it is 'ugly' compared to 
other other guis. Comparing current tk against the screenshots, I saw 
the reverse.


If the screenshots are awesomely unfair to wx, because they are actually 
12 years old and RD and the wxpython community cannot be bothered to 
update them at least to merely 7 years old, that is their fault, not 
mine for taking them at their presentation.



#
# Shot1 #
#
  This shot shows the most minimal wx GUI, that is, a simple Toplevel
window and nothing more.


And to me it is ugly compared to a minimal tk GUI.


##
# Shot 2 #
##
  This shot merely builds on shot one. Nothing fancy.


And it is ugly compared to the equivalent tk example.

> However i urge you to download the wxPython

demo and then give me an honest opinion.


If you think the site is bad, send me a ONE better screenshot, or link 
thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge 
Robin to update the page.


But until wx is either a serious contender for the stdlib, or I have 
personal need of a modern gui system, or I become curious enough about 
wx, compared to other things I have already downloaded and not looked 
at, I have little reason to spend more time with it. I already know that 
some people like wx and swear by it and have even had the vague idea 
that it somehow should replace tk.



I'll agree this screenshots page needs an update. However (like me)
the wxPython folks probably put more time into the demo and thought


If Python developers gave that excuse to not update decade-old examples 
in the doc, you would probably rant about it for a week;-).


Instead, we are updating text and examples as problems are discovered 
and we can get to them. I improved some years-old text and examples just 
last week. 3.2 will have hundreds of other improvements.



There are, however, other problems with wx that I
have and will point out in other posts.



Please elaborate, these are free and open forums as far as know...?


There are two issues: some interface to wxwidgets, and wxpython as that 
interface or the base therefore.


As to wxpython: for starters, it is written in Python2, not Python3. It 
is owned by Roben Dunn and he has shown no interest that I know of in 
having it in the stdlib. Given what that would mean in terms of loss of 
control of interface, code style, docs, release schedule, repository, 
and so on, I would not either if I had done what he has done.


A wxinter written for the stdlib in Python3, possibly based on ctypes 
rather than swig or the equivalent, might be a stdlib candidate, 
somewhat independently of the fate of tkinter. But no one has 
volunteered and you yourself suggested that such are unlikely.


--
Terry Jan Reedy

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

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

[rantingrick]

On Jan 16, 9:45 pm, Terry Reedy  wrote:

> You called them 'awesome'. I did not expect 'awesomely ugly'.
> Screenshots are the first thing for someone to look at, to see WHAT THE
> APP LOOKS LIKE, and to decide whether one wants to bother to download,
> switch to admin, install, run, and uninstall (and hope that that really
> disinstalls everything). I looked and decided that what I saw (except
> for the Mac example), was too ugly to bother with, at least for now.

Ok, Ok, i concede. The screenshots are horrendous, atrocious, and
utterly reprehensible. I should never had posted a link to such a
horrible example of wx. Trust me wx is much more beautiful than that!

> One of the criticisms against tk has been that it is 'ugly' compared to
> other other guis. Comparing current tk against the screenshots, I saw
> the reverse.

Ok, but read on because i may be able to convince you with some new
screenshots...

> If you think the site is bad, send me a ONE better screenshot, or link
> thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge
> Robin to update the page.

Ok, try this...

http://juicereceiver.sourceforge.net/screenshots/index.php

and this...

http://www.sensi.org/~ak/pyslsk/pyslsk6.png

and this (wxWidgets)...

http://www.wxwidgets.org/about/screensh.htm

> If Python developers gave that excuse to not update decade-old examples
> in the doc, you would probably rant about it for a week ;-).

Agreed. These horrible screenshots need to be updated yesterday! Or
just redirect to the wxwidgets screenshots if they are too lazy.

> There are two issues: some interface to wxwidgets, and wxpython as that
> interface or the base therefore.
>
> As to wxpython: for starters, it is written in Python2, not Python3. It
> is owned by Roben Dunn and he has shown no interest that I know of in
> having it in the stdlib. Given what that would mean in terms of loss of
> control of interface, code style, docs, release schedule, repository,
> and so on, I would not either if I had done what he has done.

Agreed. However we NEED Roben Dunn to keep doing what he is doing now.
And we need the people who are investing (maybe wasting) energy on
Tkinter to focus on a small subset of wx for stdlib inclusion. Roben
can keep his BDFL title, and Python can be updated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: examples of realistic multiprocessing usage?

[TomF]

On 2011-01-16 19:16:15 -0800, Dan Stromberg said:


On Sun, Jan 16, 2011 at 11:05 AM, TomF  wrote:

I'm trying to multiprocess my python code to take advantage of multiple
cores.  I've read the module docs for threading and multiprocessing, and
I've done some web searches.  All the examples I've found are too simple:
the processes take simple inputs and compute a simple value.  My problem
involves lots of processes, complex data structures, and potentially lots of
results.  It doesn't map cleanly into a Queue, Pool, Manager or
Listener/Client example from the python docs.

Instead of explaining my problem and asking for design suggestions, I'll
ask: is there a compendium of realistic Python multiprocessing examples
somewhere?  Or an open source project to look at?


I'm unaware of a big archive of projects that use multiprocessing, but
maybe one of the free code search engines could help with that.

It sounds like you're planning to use mutable shared state, which is
generally best avoided if at all possible, in concurrent programming -
because mutable shared state tends to slow down things quite a bit.

I'm trying to avoid mutable shared state since I've read the cautions 
against it.  I think it's possible for each worker to compute changes 
and return them back to the parent (and have the parent coordinate all 
changes) without too much overhead.  So far It looks like 
multiprocessing.Pool.apply_async is the best match to what I want.


One difficulty is that there is a queue of work to be done and a queue 
of results to be incorporated back into the parent; there is no 
one-to-one correspondence between the two.  It's not obvious to me how 
to coordinate the queues in a natural way to avoid deadlock or 
starvation.




But if you must have mutable shared state that's more complex than a
basic scalar or homogeneous array, I believe the multiprocessing
module would have you use a "server process manager".


I've looked into Manager but I don't really understand the trade-offs.
-Tom

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

Re: examples of realistic multiprocessing usage?

[Adam Skutt]

On Jan 16, 11:39 pm, TomF  wrote:
> One difficulty is that there is a queue of work to be done and a queue
> of results to be incorporated back into the parent; there is no
> one-to-one correspondence between the two.  It's not obvious to me how
> to coordinate the queues in a natural way to avoid deadlock or
> starvation.
>

Depends on what you are doing.  If you can enqueue all the jobs before
waiting for your results, then two queues are adequate.  The first
queue is jobs to be accomplished, the second queue is the results.
The items you put on the result queue have both the result and some
sort of id so the results can be ordered after the fact.  Your parent
thread of execution (thread hereafter) then:

1. Adds jobs to the queue
2. Blocks until all the results are returned.  Given that you
suggested that there isn't a 1:1 correspondence between jobs and
results, have the queue support a message saying, 'Job X is done'.
You're finished when all jobs send such a message.
3. Sorts the results into the desired ordered.
4. Acts on them.

If you cannot enqueue all the jobs before waiting for the results, I
suggest turning the problem into a pipeline, such that the thread
submitting the jobs and the thread acting on the results are
different: submitter -> job processor -> results processor.

Again though, the devil is in the details and without more details,
it's hard to suggest an explicit approach.  The simplest way to avoid
contention between two queues is to just remove it entirely (by
converting the processing to a single pipeline like I suggested).  If
that is not possible, then I suggest moving to pipes (or some other
form of I/O based IPC) and asynchronous I/O.  But I'd only do that if
I really couldn't write a pipeline.

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

Re: Not clear about the dot notation

[Tim Roberts]

Zeynel  wrote:

>On Jan 16, 3:24 pm, TomF  wrote:
>
>> vote refers to the Vote instance.
>
>So he must have instatiated previously like
>
>vote = Vote()

No, it's the line immediately above the one you asked about:

if vote is None:
vote = Vote(key_name = user.email(), parent = quote)
if vote.vote == newvote:
return

If "vote" is empty, it creates a Vote object and assigns it to "vote".  It
then checks the "vote" member of that object.

>class Item(db.Model):
>title = db.StringProperty()
>url = db.StringProperty()
>date = db.DateTimeProperty(auto_now_add=True)
>author = db.UserProperty()
>
>and to write to the database I do
>
>item = Item()
>item.title = self.request.get("title")
>item.url = self.request.get("url")
>item.author = users.get_current_user()
>item.put()
>self.redirect("/newest")
>
>so his vote.vote is like my item.url ?

Exactly.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: examples of realistic multiprocessing usage?

[TomF]

On 2011-01-16 20:57:41 -0800, Adam Skutt said:


On Jan 16, 11:39 pm, TomF  wrote:

One difficulty is that there is a queue of work to be done and a queue
of results to be incorporated back into the parent; there is no
one-to-one correspondence between the two.  It's not obvious to me how
to coordinate the queues in a natural way to avoid deadlock or
starvation.



Depends on what you are doing.  If you can enqueue all the jobs before
waiting for your results, then two queues are adequate.  The first
queue is jobs to be accomplished, the second queue is the results.
The items you put on the result queue have both the result and some
sort of id so the results can be ordered after the fact.  Your parent
thread of execution (thread hereafter) then:

1. Adds jobs to the queue
2. Blocks until all the results are returned.  Given that you
suggested that there isn't a 1:1 correspondence between jobs and
results, have the queue support a message saying, 'Job X is done'.
You're finished when all jobs send such a message.
3. Sorts the results into the desired ordered.
4. Acts on them.

If you cannot enqueue all the jobs before waiting for the results, I
suggest turning the problem into a pipeline, such that the thread
submitting the jobs and the thread acting on the results are
different: submitter -> job processor -> results processor.
Adam


Thanks for your reply.  I can enqueue all the jobs before waiting for 
the results, it's just that I want the parent to process the results as 
they come back.  I don't want the parent to block until all results are 
returned.  I was hoping the Pool module had a test for whether all 
processes were done, but I guess it isn't hard to keep track of that 
myself.


-Tom

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

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

[Octavian Rasnita]

From: "Steven D'Aprano" 
Sent: Monday, January 17, 2011 1:04 AM
Subject: Re: Tkinter: The good, the bad, and the ugly!


Well, true, but people tend to *use* the parts of the GUIs that are
simple and basic. Not only do the big complicated apps get all the press
even when they are actually a niche product (everyone knows about
Photoshop, but more people use MS Paint) but it's a truism that most
people use something like 20% of the functionality of big, complicated
GUI apps. Most people use Microsoft Word or OpenOffice for little more
than text editing with formatting.




True, but the most important thing is that those apps need to work and these 
days the portability of programs is also important for making them available 
to as many people as possible.


wxWIDGETS are portable and also pretty accessible for those who need to use 
screen readers which is not the case of purely native widgets as the Win32 
GUI standard controls or the libraries like Tk, GTK or QT.


Octavian

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

Re: [OT] Python like lanugages

[Paul Rubin]

geremy condra  writes:
> I agree. That does not make Go that language, and many of the choices
> made during Go's development indicate that they don't think it's that
> language either. I'm speaking specifically of its non-object model,
> lack of exceptions, etc 
> You might be right, but I doubt we'll know one way or the other in the
> next 5 years. Personally, I'm hoping that functional language use
> continues to grow.

You know, the functional programming community seems to think of OOP as
a 1990's thing that didn't work out.  Most things that can be done with
OOP, can be done with higher-order functions and bounded polymorphism
like in Haskell.

I'm not sure, but I don't think Erlang has exceptions in the sense we're
used to.  Someone mentioned Erlang uses a VM, but I think there is a
native compiler called HIPE.  Of course there is still a fairly
substantial runtime system, but that's true of any language with a
garbage collector and so forth.

Scala seems like an interesting language that is maybe a bit more
"practical" than Haskell.  I want to try writing something in it.  Yes
it's JVM-bound but maybe the Java aspects can be decoupled somehow.
-- 
http://mail.python.org/mailman/listinfo/python-list