Re: Pythonic way with more than one max possible

[Chris Rebert]

On Tue, Jul 19, 2011 at 10:10 PM, CM  wrote:
> On Jul 19, 11:17 pm, CM  wrote:
>> I have three items in a dict, like this:
>>
>> the_dict = {'a':1, 'b':2, 'c':3}
>>
>> but the vals could be anything.  I want to configure something else
>> based on the "winner" of such a dict, with these rules:

> I realize, now though, (and Chris asked about this) that I was
> imprecise in my
> rules.  They really should be stated as:
>
> 1. In this dict, if there is a UNIQUE max value, then its *key* is the
> winner.
> 2. If there are any TIES for max value, then the *key* 'b' is the
> winner by default.
>
> The point is, I am trying to determine the name of the winning
> category, either
> 'a', 'b', or 'c', not the value of its winning score.
>
> So in your solutions there is sorting by values, which makes sense.
> But how
> can I go back to keys from there?  Sorry for the mistake (but even so,
> I learned
> something already).

# still presumes at least 2 items
from heapq import nlargest
winner, runner_up = nlargest(2, the_dict, lambda k: the_dict[k])
if the_dict[winner] == the_dict[runner_up]:
   winner = 'b'

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

Re: I am fed up with Python GUI toolkits...

[Ian Kelly]

On Tue, Jul 19, 2011 at 8:12 PM, sturlamolden  wrote:
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.

Perhaps you already know this, but recent versions of wxPython allow
dialogs to be used as context managers, which destroys them when the
with block is exited.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Stefan Behnel]

Steven D'Aprano, 20.07.2011 06:28:

Python has a GIL.


Except for Jython, IronPython and PyPy.


PyPy has a GIL, too.

Stefan

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

Re: a little parsing challenge ☺

[Ian Kelly]

On Wed, Jul 20, 2011 at 12:29 AM, jmfauth  wrote:
>> Then it is hard to code precisely.
>>
>
> Not really. The trick is to count the different opener/closer
> separately.
> That is what I am doing to check balanced brackets in
> chemical formulas. The rules are howerver not the same
> as in math.

I think the difficulty is not in the algorithm, but in adhering to the
desired output when it is ambiguously described.

> But, if I want to parse a string from right to left,
> what's the trick?
> The best I found so far:
>
 s = 'abcd'
 for i, c in enumerate(reversed(s)):
> ...     print len(s) - 1 - i, c

That violates DRY, since you have reversal logic in the iterator
algebra and then again in the loop body.  I prefer to keep all such
logic in the iterator algebra, if possible.  This is one possibility,
if you don't mind it building an intermediate list:

>>> for i, c in reversed(list(enumerate(s))):
...

Otherwise, here's another non-DRY solution:

>>> from itertools import izip
>>> for i, c in izip(reversed(xrange(len(s))), reversed(s)):
...

Unfortunately, this is one space where there just doesn't seem to be a
single obvious way to do it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Steven D'Aprano]

On Wed, 20 Jul 2011 05:20 pm Stefan Behnel wrote:

> Steven D'Aprano, 20.07.2011 06:28:
>>> Python has a GIL.
>>
>> Except for Jython, IronPython and PyPy.
> 
> PyPy has a GIL, too.

Isn't it optional though?




-- 
Steven

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

Re: (Maybe off topic) Can someone explain what a finite state machine is?

[Steven D'Aprano]

On Tue, 19 Jul 2011 11:32 pm Matty Sarro wrote:

> Hey everyone. I am currently reading through an RFC, and it mentions
> that a client and server half of a transaction are embodied by finite
> state machines. I am reading through the wikipedia article for finite
> state machines, and sadly it's going a bit above my head. I don't
> really have a background in engineering, and would really love to
> understand what is being said. Does anyone have a simple way to
> explain it?

Consider a heater with a thermostat. That's a finite state machine. It's a
machine, it has a finite number of states, namely, the combinations of
these:

"on" or "off"
"too warm", "too cold" or "in-between"

The machine has transitions between states:

"if too warm, then turn off"
"if too cold, then turn on"
"if in-between, then don't change"


Here's one way to simulate such a simple FSM in Python:


import time

class Heater:
low = 0
high = 10
def __init__(self, starting_temperature=7):
self.temp = starting_temperature
self.state = "off"
def run(self):
while True:
if self.state == "on":
# Heating.
self.temp += 1
if self.state == "off":
# Slowly cooling.
self.temp -= 1
if self.temp < self.low:
print("turning on")
self.state = "on"
if self.temp > self.high:
print("turning off")
self.state = "off"
time.sleep(1)



>>> heater = Heater()
>>> heater.run()
turning on
turning off
turning on
turning off
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 9, in run
KeyboardInterrupt



More complex finite state machines can have many different states, and much
more complicated behaviour.


-- 
Steven

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

Re: I am fed up with Python GUI toolkits...

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.20 02:28 AM, Steven D'Aprano wrote:
> Isn't it optional though?
No.
http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOJojrAAoJEPiOA0Bgp4/LXdgH/RJefVrvsawewQsxMex9NlMl
IRS6lMjVMFgsXHh2V2F+DfQ0bZ9904dgsgyU3zHkfevI3Stctrr8qainxlmUxj3q
EFTzzQLUurY+tyR1sz5y9MtxWbjvOIQrZ8VN0aj/1ks+TU7fq+2d+sa+KFgMhP+k
F2TQeZhDBYhm+NE7h7MHsYhnRHtA5nWW2UByFXu/gcdrk9rB+3nqHuxj4ROh7Ots
vHbS9W/BsDver0e2Z9w4TxZ5Jb9cAjdkAqcK4Tqth0WMhvnIpnRGxM8npwD/xsKs
9jVkZhdG1BSvXdRUqLYTucA0lfTqNMh1CZtWzvOQIBqH1cdqKP+S7zdOloyti5Y=
=H+A1
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Geodetic functions library GeoDLL 32 Bit and 64 Bit

[Fred]

Hi developers,

who develops programs with geodetic functionality like world-wide coordinate 
transformations or distance calculations, can work with the latest version of 
my GeoDLL. The Dynamic Link Library can easily be used with any programming 
language to add geodetic functionality to own applications. 

GeoDLL supports 2D and 3D coordinate transformation, geodetic datum shift and 
reference system convertion, meridian strip changing, user defined coordinate 
and reference systems, distance calculation, Digital Elevation Model, NTv2 
handling, Direct / Inverse Solutions and a lot of other geodetic functions. 

The DLL has become very fast and save by forceful development in C++ with 
Microsoft Visual Studio 2010. The geodetic functions of the new version 12.05 
now are available in 32bit and 64bit architecture. 

You find a downloadable test version on http://www.killetsoft.de/p_gdla_e.htm.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[jmfauth]

On 20 juil, 09:29, Ian Kelly  wrote:

> Otherwise, here's another non-DRY solution:
>
> >>> from itertools import izip
> >>> for i, c in izip(reversed(xrange(len(s))), reversed(s)):
>
> ...
>
> Unfortunately, this is one space where there just doesn't seem to be a
> single obvious way to do it.

Well, I see. Thanks.

There is still the old, brave solution, I'm in fact using.

>>> s = 'abcd'
>>> for i in xrange(len(s)-1, -1, -1):
... print i, s[i]
...
3 d
2 c
1 b
0 a
>>>

---

DRY?  acronym for ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Steven D'Aprano]

On Wed, 20 Jul 2011 05:54 pm jmfauth wrote:

> DRY?  acronym for ?

I'd like to tell you, but I already told somebody else... 

*grins*


http://en.wikipedia.org/wiki/Don't_repeat_yourself
http://c2.com/cgi/wiki?DontRepeatYourself




-- 
Steven

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

Re: I am fed up with Python GUI toolkits...

[Steven D'Aprano]

On Wed, 20 Jul 2011 05:51 pm Andrew Berg wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
> 
> On 2011.07.20 02:28 AM, Steven D'Aprano wrote:
>> Isn't it optional though?
> No.
> http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why

Ah, my mistake, thank you. I knew PyPy had multiple garbage collectors, and
confabulated that it didn't have a GIL.

So, that's two GILs, two without for the Big Four.



-- 
Steven

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

Re: The following modules appear to be missing - py2exe

[miamia]

hello, thanks for your answer.

>  From the stuff below, you appear to be compiling for Windows.
yes

>
> > The following modules appear to be missing
> > ['Carbon', 'Carbon.Files',
> This is Mac gui stuff which you neither need nor want in a Windows
> binary. I suspect mis-specification somewhere.

ok so this is not necessary.

>
>   '_scproxy', 'fixedpoint', 'gdk', 'mx', 'unix', 'glib.
>
> compiling with gcc? You appear to be missing its glib.

I compile with py2exe and have no idea how to retrieve missing libs. I
tried to ask at
http://sourceforge.net/mailarchive/forum.php?thread_name=CABFuWSwv76-Hz-fNrqN_2__%2Bb7ZpPuBb%3DT%2B-i0-MF%2BJvjj8Fqg%40mail.gmail.com&forum_name=py2exe-users
as well and Dieter responded it is py2exe troubles with gdk and glib
packages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Thomas Jollans]

On 20/07/11 04:12, sturlamolden wrote:
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.

I wonder - what do you think of GTK+?
I've only used Qt with C++, and I've always been highly suspicious of wx
(something about the API, or the documentation… I haven't had a look at
it in a long time), but I always found PyGTK quite nice.

> 4. They might look bad (Tkinter, Swing with Jython).

Oh well.

Really, while Swing and Tkinter are particularly bad as they draw their
own widgets (instead of using a native toolkit), if you want your GUI to
look good, you'll need to write a separate GUI for each platform that
follows each platform's UI conventions.

> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)

Aye, existing GUI toolkits are mature. They work. They do the job.

> 5. No particular GUI thread synchronization is needed  -- Python has a
> GIL.

That's where you're wrong: the GIL is not a feature of Python. It is an
unfortunate implementation detail of current versions of CPython. (and
PyPy, apparently)

> 6. Expose the event loop to Python.

You can tap into the Gtk/GLib event loop. Don't other toolkits allow you
to write your own loop, using some kind of process_events() function to
take care of the GUI?

> 7. Preferably BSD-style license, not even LGPL.

Umm?

> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.

HOLD ON a second:

> 4. They might look bad (Tkinter, Swing with Jython).

> [...] , if based on "native" widgets:

What do you propose? We know what happens when you write a fresh GUI
toolkit: Swing and Tkinter show us.
The only reasonable option to create a toolkit that actually looks good
is to base it on the "usual" GUI libraries.

> The Eclipse SWT library does some of this for Java does some of this,
> though it also has flaws (e.g. manual memory management). A Python GUI
> toolkit could be partially based on the SWT code.

Okay, I haven't used SWT yet: manual memory management? Java is GC!

It is perfectly reasonable to be required to manually call some sort of
destroy() method to tell the toolkit what you no longer want the user to
see: firstly, you have the display a reference to your window, in a
manner of speaking, by showing it. Secondly, in a GC environment like a
JVM or the CLI, it could take a moment. Was that what you meant?

> Is it worth the hassle to start a new GUI toolkit project?

No.

> Or should modern deskop apps be written with something completely
> different, such as HTML5?

NO!!
Don't be silly. Even using a crappy windowing toolkit is a lot simpler
than doing the HTML/JavaScript/HTTP/etc dance.
-- 
http://mail.python.org/mailman/listinfo/python-list

total_ordering behaviour

[risboo6909]

Hello all,

I've noticed some strange behaviour of functools.total_ordering
decorator, at least it seems strange to me.

Let's consider code snippet below

import functools

@functools.total_ordering
class MyComparableType(object):

def __init__(self, value, ref):
self.value = value
self.ref = ref

def __eq__(self, other):
# compare two MyComparableType objects or MyComparableType
object and some number
if type(other) == MyComparableType:
return self.value == other.value
return self.value == other

def __gt__(self, other):
# compare two MyComparableType objects or MyComparableType
object and some number
if type(other) == MyComparableType:
return self.value > other.value
return self.value > other

foo = MyComparableType(10, None)
bar = MyComparableType(20, foo)

print foo < bar # works ok, True
print foo > bar # works ok, False
print foo > 5   # works ok, True

print foo < 8   # error! we jump into infinite recursion and
eventually get stack overflow error

It works fine in most cases but crashes when I try to check foo < 8.

As I understand the reason why this happens is because of this code in
functools.py, total_ordering decorator, which adds missing comparisons
definitions

..

'__gt__': [('__lt__', lambda self, other: other > self),
  ('__ge__', lambda self, other: not other > self),
  ('__le__', lambda self, other: not self > other)],

  ...

and python coercion rules say:

For objects x and y, first x.__op__(y) is tried. If this is not
implemented or returns NotImplemented, y.__rop__(x) is tried. If this
is also not implemented or returns NotImplemented, a TypeError
exception is raised. But see the following exception:

Exception to the previous item: if the left operand is an instance of
a built-in type or a new-style class, and the right operand is an
instance of a proper subclass of that type or class and overrides the
base’s __rop__() method, the right operand’s __rop__() method is tried
before the left operand’s __op__() method.

So it behaves like it should according to this rule and produces stack
overflow because of the infinite recursion calls in the last
comparison (foo < 8).

There is a way to fix this by replacing missing comparisons
definitions in total_ordering to be like this:

'__gt__': [('__lt__', lambda self, other: not self > other and not
self == other),
  ('__ge__', lambda self, other: self > other or self ==
other ),
  ('__le__', lambda self, other: not self > other)],

then script above will work perfectly well in all the cases and there
is just one more check added in two of three definitions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Xah Lee]

i've just cleaned up my elisp code and wrote a short elisp tutorial.

Here:

〈Emacs Lisp: Batch Script to Validate Matching Brackets〉
http://xahlee.org/emacs/elisp_validate_matching_brackets.html

plain text version follows. Please let me know what you think.

am still working on going thru all code in other langs. Will get to
the ruby one, and that perl regex, and the other fixed python ones.
(possibly also the 2 common lisp codes but am not sure they are
runnable as is or just some non-working showoff. lol)

===
Emacs Lisp: Batch Script to Validate Matching Brackets

Xah Lee, 2011-07-19

This page shows you how to write a elisp script that checks thousands
of files for mismatched brackets.


The Problem


Summary

I have 5 thousands files containing many matching pairs. I want to to
know if any of them contains mismatched brackets.


Detail

The matching pairs includes these: () {} [] “” ‹› «» 〈〉 《》 【】 〖〗 「」
『』.

The program should be able to check all files in a dir, and report any
file that has mismatched bracket, and also indicate the line number or
positon where a mismatch occurs.

For those curious, if you want to know what these brackets are, see:

• Syntax Design: Use of Unicode Matching Brackets as Specialized
Delimiters
• Intro to Chinese Punctuation with Computer Language Syntax
Perspectives

For other notes and conveniences about dealing with brackets in emacs,
see:

• Emacs: Defining Keys to Navigate Brackets
• “extend-selection” at A Text Editor Feature: Extend Selection by
Semantic Unit
• “select-text-in-quote” at Suggestions on Emacs's mark-word
Command


Solution

Here's outline of steps.

• Go thru the file char by char, find a bracket char.
• Check if the one on stack is a matching opening char. If so
remove it. Else, push the current onto the stack.
• Repeat the above till no more bracket char in the file.
• If the stack is not empty, then the file got mismatched
brackets. Report it.
• Do the above on all files.

Here's some interesting use of lisp features to implement the above.


Define Matching Pair Chars as “alist”

We begin by defining the chars we want to check, as a “association
list” (aka “alist”). Like this:

(setq matchPairs '(
   ("(" . ")")
   ("{" . "}")
   ("[" . "]")
   ("“" . "”")
   ("‹" . "›")
   ("«" . "»")
   ("【" . "】")
   ("〖" . "〗")
   ("〈" . "〉")
   ("《" . "》")
   ("「" . "」")
   ("『" . "』")
   )
  )

If you care only to check for curly quotes, you can remove elements
above. This is convenient because some files necessarily have
mismatched pairs such as the parenthesis, because that char is used
for many non-bracketing purposes (e.g. ASCII smiley).

A “alist” in lisp is basically a list of pairs (called key and value),
with the ability to search for a key or a value. The first element of
a pair is called its key, the second element is its value. Each pair
is a “cons”, like this: (cons mykey myvalue), which can also be
written using this syntax: (mykey . myvalue) for more easy reading.

The purpose of lisp's “alist” is similar to Python's dictionary or
Pretty Home Page's array. It is also similar to hashmap, except that
alist can have duplicate keys, can search by values, maintains order,
and alist is not intended for massive number of elements. Elisp has a
hashmap datatype if you need that. (See: Emacs Lisp Tutorial: Hash
Table.)

(info "(elisp) Association Lists")


Generate Regex String from alist

To search for a set of chars in emacs, we can read the buffer char-by-
char, or, we can simply use “search-forward-regexp”. To use that,
first we need to generate a regex string from our matchPairs alist.

First, we defines/declare the string. Not a necessary step, but we do
it for clarity.

(setq searchRegex "")

Then we go thru the matchPairs alist. For each pair, we use “car” and
“cdr” to get the chars and “concat” it to the string. Like this:

(mapc
 (lambda (mypair) ""
   (setq searchRegex (concat searchRegex (regexp-quote (car mypair))
"|" (regexp-quote (cdr mypair)) "|") )
   )
 matchPairs)

Then we remove the ending “|”.

(setq searchRegex (substring searchRegex 0 -1)) ; remove the ending
“|”

Then, change | it to \\|. In elisp regex, the | is literal. The “regex
or” is \|. And if you are using regex in elisp, elisp does not have a
special regex string syntax, it only understands normal strings. So,
to feed to regex \|, you need to espace the first backs

Re: Pythonic way with more than one max possible

[Thomas Jollans]

On 20/07/11 06:19, Steven D'Aprano wrote:
> On Wed, 20 Jul 2011 01:17 pm CM wrote:
> 
>> I have three items in a dict, like this:
>>
>> the_dict = {'a':1, 'b':2, 'c':3}
>>
>> but the vals could be anything.  I want to configure something else
>> based on the "winner" of such a dict, with these rules:
>>
>> 1. In this dict, if there is a UNIQUE max value, that's the winner.
>> 2. If there are any TIES for max value, b is the winner by default.
>>
>> The problem for me, as I see it, is I don't know any elegant ways to
>> do this in Python.  The max(dict) function doesn't distinguish between
>> unique and non-unique maxes.  I could go through and test the various
>> possibilities (to see if the max value had any matches in the other
>> values), but, knowing Python, there is probably something close to
>> "one way to do it".  Any suggestions?
> 
> # Untested.
> def get_winner(adict):
> values = sorted(adict.values(), reverse=True)
> if values[0] == values[1]:
> return adict['b']
> else:
> return values[0]

# Untested, with keys:
def get_winner(adict):
values = sorted(adict.items(), reverse=True,
key=(lambda k_v: k_v[1]))
if values[0][1] == values[1][1]:
return 'b'
else:
return values[0][0]

> 
> Assumes that adict has at least two items. May be slow if it has millions of
> items.
> 
> 

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

Re: I am fed up with Python GUI toolkits...

[Adam Tauno Williams]

On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote:
> What is wrong with them
> 1. Designed for other languages, particularly C++, tcl and Java.
> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> has a standard library!)

I've no idea what this means.  I happily use pygtk.

As for "application frameworks" maybe you are referring to their having
their own event-loop, etc...  They don't have any choice.  A UI toolkit
has to have an event-loop and related pluming.

Gtk builds on top of glib; which has its own event-loop etc... This
makes perfect sense to me.

> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.

Widget registration / hierarchy != memory management.

> 4. They might look bad (Tkinter, Swing with Jython).

Sorry, I think Gtk apps are very nice looking.

> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)

PyGTK just released version 3 with GObject introspection.  etk.docking
went beta a few months ago [a pygtk docking solution].  All seems pretty
alive to me.  And the developers respond to questions.

> How I would prefer the GUI library to be, if based on "native"
> widgets
> 1. Lean and mean -- do nothing but GUI. No database API, networking
> API, threading API, etc.

Sounds like PyGtk to me.  All that other stuff and you are on your own.

Although I'd like to have data-model binding.

> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.

Unreasonable.

> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up. No
> manual clean-up. Python does all the reference counting we need.

NEVER GOING TO HAPPEN.  UI's don't work that way.  They are inherently
hierarchical.  Just get over it.

> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable

Gtk supports multiple canvas modes.

> 5. No particular GUI thread synchronization is needed  -- Python has a
> GIL.

Wrong.

> 6. Expose the event loop to Python.

It is.

> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.

Why.  Pointless. That is just re-implementation.


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

Re: I am fed up with Python GUI toolkits...

[Tim Chase]

On 07/19/2011 09:12 PM, sturlamolden wrote:

How I would prefer the GUI library to be, if based on "native"
widgets:


http://xkcd.com/927/

:-)

-tkc



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

Re: I am fed up with Python GUI toolkits...

[Adam Tauno Williams]

On Wed, 2011-07-20 at 11:59 +0200, Thomas Jollans wrote:
> On 20/07/11 04:12, sturlamolden wrote:
> > 5. No particular GUI thread synchronization is needed  -- Python has a
> > GIL.
> That's where you're wrong: the GIL is not a feature of Python. It is an
> unfortunate implementation detail of current versions of CPython. (and
> PyPy, apparently)

And this GIL is certainly *not* a synchronization solution.  

Even with a GIL you can hang yourself with threads - I've verified
this. :)

> > 6. Expose the event loop to Python.
> You can tap into the Gtk/GLib event loop. 

+1

> What do you propose? We know what happens when you write a fresh GUI
> toolkit: Swing and Tkinter show us.
> The only reasonable option to create a toolkit that actually looks good
> is to base it on the "usual" GUI libraries.

+1

> It is perfectly reasonable to be required to manually call some sort of
> > Is it worth the hassle to start a new GUI toolkit project?
> No.

+1, or -1, errr.. which ever one means I agree with "no".

> > Or should modern deskop apps be written with something completely
> > different, such as HTML5
> NO!!

Barf.

Of course, Gtk [at least experimentally] supports an HTML5 canvas.  A
good UI library provides a lot beyond painting-the-screen (there are
events, and packing/geometry, etc...).  So even if you use HTML5 you are
then going to lay something on top of that [JavaScript + JQuery...].

> Don't be silly. Even using a crappy windowing toolkit is a lot simpler
> than doing the HTML/JavaScript/HTTP/etc dance.

+1


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

Re: I am fed up with Python GUI toolkits...

[Stefan Behnel]

sturlamolden, 20.07.2011 04:12:

Or should modern deskop apps be written with something completely
different, such as HTML5?


Depends. For many "desktop" apps, this is actually quite workable, with the 
additional advantage of having an Internet-/Intranet-ready implementation 
available in case you happen to need it later on.


Plus, you can take advantage of any HTML designers (as in "humans") you 
happen to have around, whereas you are often a bit on your own when you 
design a GUI using a toolkit, especially when you want it to work well in a 
cross-platform way.


Stefan

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

sphinx

[Jayron Soares]

Hi guys!
I'm trying to create method to perform query at sphinx index, can anyone
does something like this before?
I appreciate !
Ageu

-- 
*" A Vida é arte do Saber...Quem quiser saber tem que Estudar!"*

http://bucolick.tumblr.com
http://artecultural.wordpress.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Johann Hibschman]

Thomas Jollans  writes:

> On 20/07/11 04:12, sturlamolden wrote:
>> 3. Unpythonic memory management: Python references to deleted C++
>> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
>> ownership might be smart in C++, but in Python we have a garbage
>> collector.
>
> I wonder - what do you think of GTK+?
> I've only used Qt with C++, and I've always been highly suspicious of wx
> (something about the API, or the documentation… I haven't had a look at
> it in a long time), but I always found PyGTK quite nice.

GTK+ doesn't work well at all on Mac, so if "cross-platform" includes
Macs, it's not a contender.

To quote the gtk-osx.sourceforge.net page:

   Developers considering GTK+ as a cross-platform environment for new
   work are advised to evaluate other toolkits carefully before
   committing to GTK if they consider OSX an important market.

From experience, GTK apps are pretty awful on OSX.

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

Re: I am fed up with Python GUI toolkits...

[rantingrick]

On Jul 19, 9:12 pm, sturlamolden  wrote:
> What is wrong with them:
>
> 1. Designed for other languages, particularly C++, tcl and Java.

This fact bugs me but no one is willing to put forth an effort to make
things happen. So we are stuck with what we have now.

> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython).

Users should NEVER need to explicitly destroy a dialog. However it
would (should) be easy to subclass the wxDialg and create your own
logic tied to the ok and cancel buttons. See tkSimpleDialog for old
inspiration or see my threads on tkSimpleDialog improved for modern
inspiration.

> Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.

There is nothing wrong with hierarchy. Please show examples where this
relationship fails.

> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)

Well you've got to get some "like minds" together. I would be willing
to participate on something more Pythonic. PyGUI looks promising.


> How I would prefer the GUI library to be, if based on "native"
> widgets:
>
> 1. Lean and mean -- do nothing but GUI. No database API, networking
> API, threading API, etc.

PyGUI

> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.

Some heavy lifting must be done in these languages.

> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up.

I don't see how that "messes things up"?

> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable.

Hopefully you want a canvas at least. I don't think i could get by
without one. Not only is a canvas good for drawing graphics via user
input but also for creating custom widgets that the GUI does not
expose.

> 6. Expose the event loop to Python.

This would be nice.

> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.

Agreed! Wx is nice but feels too much like writing C.

> Is it worth the hassle to start a new GUI toolkit project?

It's a huge hassle and might be much better to grow/repair some
existing API's. PyGUI is one however it's very young. Tkinter could
use some re-factoring however it will always be based on an embedded
TCL interpreter doing "magic" behind the scenes.

> Or should modern deskop apps be written with something completely
> different, such as HTML5?

F___ NO! That sort of thing needs many more years to mature. Currently
we are in the beginning phases when everybody has "their" idea of what
is perfect and nobody agrees on which is best. Plus you have many
incompatibilities between the major browsers. People like to parrot
off about how cross-platform these things are compared to GUI; and
that's true only for the same version of the same browser. You just
switch from OS incompatibility to browser incompatibility.


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

Re: I am fed up with Python GUI toolkits...

[rantingrick]

On Jul 19, 9:44 pm, Kevin Walzer  wrote:

> > 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> > has a standard library!)
>
> Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit
> specifically designed for scripting languages.

Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a
TCL interpreter. You statements are misleading.

> > 3. Unpythonic memory management: Python references to deleted C++
> > objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> > ownership might be smart in C++, but in Python we have a garbage
> > collector.
>
> Again, so? Again, this isn't applicable to Tk.

He did not even mention Tk in that block, do you have a TK persecution
complex?

> > 4. They might look bad (Tkinter, Swing with Jython).
>
> Then again, they might not.  A lot depends on the skill of the
> developer. I write highly polished commercial apps with Tk GUI's. I'm
> sick of developers blaming their ugly apps on the toolkit rather than
> their own lack of design training and/or skills.

This is true. Lots of people lack the skill to create professional
quality GUI applications however lots of GUI devs lack the skill to
create clean and intuitive API's also. Tkinter/TclTk and WxPython
\WxWidgets has lots of warts in this respect.

> > 5. All projects to write a Python GUI toolkit die before they are
> > finished. (General lack of interest, bindings for Qt or wxWidgets
> > bloatware are mature, momentum for web development etc.)
>
> That's right. People issue a clarion call for a new GUI toolkit, then
> discover that even a so-called "ugly, limited, minimalist" toolkit like
> Tk has twenty years of development behind it. And people think they can
> duplicate this effort in a few months by starting a flame war on
> comp.lang.python?

Just because someone wants to entertain ideas for a new GUI does mean
they are starting flame wars. I would say out all the responses so far
YOURS is the most emotional.

> > 1. Lean and mean -- do nothing but GUI. No database API, networking
> > API, threading API, etc.
>
> Presenting...Tk.

True Tkinter does no Database, networking, threading, etc. However i
would not call an embedded TCl interpreter "lean and mean".

> > 2. Do as much processing in Python as possible. No more native code
> > (C, C++, Cython) than needed.
>
> And what's wrong with native (ie. compiled) code? Python is written in
> native code, isn't it? To extend Python in significant ways, it is often
> necessary to drop down into native code.

I will agree with Kevin here. Hey, he's not ALWAYS wrong you know;
just most of the time! ;-)

> > 6. Expose the event loop to Python.
>
> Presenting...Tk.

Tk's event binding (whist quite powerful) is also quite overwhelming
in the sheer number of event sequences alone and leads to spaghetti
code. See my recent thread about the subject.

> > 8. Written for Python in Python -- not bindings for a C++ or tcl
> > toolkit.
>
> Well, that's the holy grail, but given the history of other toolkits,
> you'll reach a comparable level of maturity in 2031.

I think it could happen much sooner if people got serious. However it
won't happen tomorrow for sure.


> > Is it worth the hassle to start a new GUI toolkit project?
>
> Not unless you want to reinvent the wheel yet again.

The old "reinvent the wheel" argument is only valid when wheels
already exists. Currently we have triangles (or maybe pentagons) but
no wheels.

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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 11:59, Thomas Jollans  wrote:

> I wonder - what do you think of GTK+?

PyGTK with GLADE is the easier to use, but a bit awkward looking on
Windows and Mac. (Not to mention the number of dependencies that must
be installed, inclusing a GTK runtime.)

> Really, while Swing and Tkinter are particularly bad as they draw their
> own widgets

GTK and Qt do that as well.


> > The Eclipse SWT library does some of this for Java does some of this,
> > though it also has flaws (e.g. manual memory management). A Python GUI
> > toolkit could be partially based on the SWT code.
>
> Okay, I haven't used SWT yet: manual memory management? Java is GC!

So is Python, yet wxPython require manual destruction of dialogs as
well.



> It is perfectly reasonable to be required to manually call some sort of
> destroy() method to tell the toolkit what you no longer want the user to
> see

Yes, but not to avoid a memory leak.


Sturla

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

Re: I am fed up with Python GUI toolkits...

[Grant Edwards]

On 2011-07-20, Thomas Jollans  wrote:

>> 5. No particular GUI thread synchronization is needed  -- Python has a
>> GIL.
>
> That's where you're wrong: the GIL is not a feature of Python. It is an
> unfortunate implementation detail of current versions of CPython. (and
> PyPy, apparently)

And there are always people trying to figure out how to get rid of it.
So far the cures have been worse than the disease, but that may not
always be the case...

-- 
Grant Edwards   grant.b.edwardsYow! ... the HIGHWAY is
  at   made out of LIME JELLO and
  gmail.commy HONDA is a barbequeued
   OYSTER!  Yum!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Grant Edwards]

On 2011-07-20, Adam Tauno Williams  wrote:
> On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote:
>> What is wrong with them
>> 1. Designed for other languages, particularly C++, tcl and Java.
>> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
>> has a standard library!)
>
> I've no idea what this means.  I happily use pygtk.

I agree.  PyGTK works great -- on platforms where GTK works great.

-- 
Grant Edwards   grant.b.edwardsYow! !!  I am having fun!!!
  at   
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Mel]

sturlamolden wrote:
> On 20 Jul, 11:59, Thomas Jollans  wrote:

>> It is perfectly reasonable to be required to manually call some sort of
>> destroy() method to tell the toolkit what you no longer want the user to
>> see

> Yes, but not to avoid a memory leak.

OTOH, if you intend to re-use the Dialog object, it's not a memory leak.

Mel.

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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 11:59, Thomas Jollans  wrote:

> Okay, I haven't used SWT yet: manual memory management? Java is GC!
>
> It is perfectly reasonable to be required to manually call some sort of
> destroy() method to tell the toolkit what you no longer want the user to
> see: firstly, you have the display a reference to your window, in a
> manner of speaking, by showing it. Secondly, in a GC environment like a
> JVM or the CLI, it could take a moment. Was that what you meant?

A .hide() method is warranted, but not a .destory() method to
deallocate C resources. Python calls tp_dealloc when needed.

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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 16:17, Mel  wrote:

> OTOH, if you intend to re-use the Dialog object, it's not a memory leak.

It cannot be reused if you don't have any references pointing to it.
Sure it is nice to have dialogs that can be hidden and re-displayed,
but only those that can be accessed again.

tp_dealloc should free any C resources the object is holding. There is
no need to save anything beyond the call to tp_dealloc. Before the
call to tp_dealloc any C resources should be kept, for the reason you
mentioned.

That is why the parent-child method of clean-up is at odds with the
Python garbage collection.


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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 13:04, Adam Tauno Williams  wrote:

> > 3. Instances of extension types can clean themselves up on
> > deallocation. No parent-child ownership model to mess things up. No
> > manual clean-up. Python does all the reference counting we need.
>
> NEVER GOING TO HAPPEN.  UI's don't work that way.  They are inherently
> hierarchical.  Just get over it.

Swing relies on the Java GC. Tkinter also does this correct.

A hierarchy is nice for event processing an layout management, but not
for memory mangement.

C resources should be freed by Python calling tp_dealloc, not by the
parent calling a .destroy() method on it's children.

Python is not C++, so we have a method to automatically reclaim C
resources. I don't want a toolkit to deallocate objects while Python
still holds references to them (PyQt) or require a manual call to
deallocate a widget tree (wxPython).

Python knows when it's time to deallocate C resources, and then makes
a call to the tp_dealloc member of the type object.



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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 13:08, Tim Chase  wrote:

> http://xkcd.com/927/
>
> :-)

Indeed.

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

Re: I am fed up with Python GUI toolkits...

[rantingrick]

On Jul 20, 9:27 am, sturlamolden  wrote:
> On 20 Jul, 16:17, Mel  wrote:
>
> > OTOH, if you intend to re-use the Dialog object, it's not a memory leak.
>
> It cannot be reused if you don't have any references pointing to it.
> Sure it is nice to have dialogs that can be hidden and re-displayed,
> but only those that can be accessed again.

I find that keeping a dialog alive (and hidden) is bad practice EXCEPT
in the case where a dialog will be used many, many times in an
application. Since that kind of re-usage is rare destroying the dialog
and freeing the graphical resources it consumes is important.

However a dialog should handle it's own state. That is, and
application should never have to keep up with dialog default values
and re-insert then every time, NO, the dialog should do this all by
itself.

My solution is to create a simple container class that creates and
destroys the dialog as needed (when show is called) however keeps a
state of the last user inputs so the main application does not have
to.

class Dialog():
def __init__(self):
self.state = []
# the dialog IS NOT created here!

def show(self):
# Create the dialog here
# and load any initial values
# from self.state.

def cb_okbutton(self):
# Process the inputs, store the
# current values in self.state
# and destroy.

def cb_cancelbutton(self)
# destroy the dialog.

This is a proper design pattern for all GUI dialogs.

*school-bell*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[Thomas Jollans]

On 20/07/11 15:47, sturlamolden wrote:
> On 20 Jul, 11:59, Thomas Jollans  wrote:
> 
>> I wonder - what do you think of GTK+?
> 
> PyGTK with GLADE is the easier to use, but a bit awkward looking on
> Windows and Mac. (Not to mention the number of dependencies that must
> be installed, inclusing a GTK runtime.)

Don't know about Mac, I was under the impression that GTK was fine on
Windows these days.

You can bundle GTK+ just as easily as Qt or Wx. It might, of course, be
less usual.

>> Really, while Swing and Tkinter are particularly bad as they draw their
>> own widgets
> 
> GTK and Qt do that as well.

Qt uses the native libraries on Windows and OSX.
-- 
http://mail.python.org/mailman/listinfo/python-list

problem in compiling the module in VC2010

[llwaeva]

Hi all,
  I am compiling the example with MCVS2010

#include "Python.h"

static PyObject *
ex_foo(PyObject *self, PyObject *args)
{
printf("Hello, world\n");
Py_INCREF(Py_None);
return Py_None;
}

static PyMethodDef example_methods[] = {
{"foo", ex_foo, METH_VARARGS, "foo() doc string"},
{NULL, NULL}
};

static struct PyModuleDef examplemodule = {
PyModuleDef_HEAD_INIT,
"example",
"example module doc string",
-1,
example_methods,
NULL,
NULL,
NULL,
NULL
};

PyMODINIT_FUNC
PyInit_example(void)
{
return PyModule_Create(&examplemodule);
}


But it reports the following message:

error LNK2001: unresolved external symbol __imp___Py_NoneStruct
error LNK2019: unresolved external symbol __imp__PyModule_Create2
referenced in function _PyInit_example

My os is windows 7 64-bit. Compiler: VC2010



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

Re: total_ordering behaviour

[Ian Kelly]

On Wed, Jul 20, 2011 at 4:18 AM, risboo6909  wrote:
> Hello all,
>
> I've noticed some strange behaviour of functools.total_ordering
> decorator, at least it seems strange to me.

Looks like this is already known and fixed as of March:

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

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 17:21, Thomas Jollans  wrote:

> Don't know about Mac, I was under the impression that GTK was fine on
> Windows these days.

GTK looks awful on Windows, requires a dozen of installers (non of
which comes from a single source), is not properly stabile (nobody
cares?), and does not work on 64-bit.

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

Re: problem in compiling the module in VC2010

[Christian Heimes]

Am 20.07.2011 17:33, schrieb llwa...@gmail.com:
> Hi all,
>   I am compiling the example with MCVS2010

VC 2010 is not officially supported.

Christian

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

Re: total_ordering behaviour

[risboo6909]

On Jul 20, 7:39 pm, Ian Kelly  wrote:
> On Wed, Jul 20, 2011 at 4:18 AM, risboo6909  wrote:
> > Hello all,
>
> > I've noticed some strange behaviour of functools.total_ordering
> > decorator, at least it seems strange to me.
>
> Looks like this is already known and fixed as of March:
>
> http://bugs.python.org/issue10042

Thanks, you right, I didn't notice that this bug has already been fixed
-- 
http://mail.python.org/mailman/listinfo/python-list

SMS

[TERESA G]

One method you can use is to connect to an SMS API provider from your
web application, which will enable you to send SMS via an internet
connection, typically using a protocol like HTTP; You can try Nexmo
SMS API,  it supports HTTP REST and SMPP and we have documentation
published in our website with information and examples on how to
connect and send, which for a programmer in any language can be pretty
simple.

http://nexmo.com/documentation/libs/index.html

Examples for Python are still to come to the documentation page,
however, you can try github and find code to send sms for python in
github. e.g. https://github.com/marcuz/pynexmo

With Nexmo, you can send to 200 countries, and it has Long Numbers
available in a few countries for inbound traffic.You need to have a
CallBack URL for inbound to which Nexmo sends a request for each
incoming message to your long number.

It is a pay as you go service, so you decide how much you need to buy
to send SMS (pricing per country/operator is on the website). For
inbound, you pay per long number monthly (not per message). The end
user does not pay for receiving.

http://nexmo.com

Hope this helps.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Uri Guttman]

a better parsing challenge. how can you parse usenet to keep this troll
from posting on the wrong groups on usenet? first one to do so, wins the
praise of his peers. 2nd one to do it makes sure the filter stays in
place. all the rest will be rewarded by not seeing the troll anymore.

anyone who actually engages in a thread with the troll should parse
themselves out of existance.

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
  Perl Developer Recruiting and Placement Services  -
-  Perl Code Review, Architecture, Development, Training, Support ---
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 06:28, Steven D'Aprano  wrote:

> Have you tried Tkinter version 8.0 or better, which offers a native look and
> feel?

Python 2.7.2 |EPD 7.1-1 (64-bit)| (default, Jul  3 2011, 15:34:33)
[MSC v.1500 64 bit (AMD64)] on win32
Type "packages", "demo" or "enthought" for more information.
>>> import Tkinter
>>> Tkinter.TkVersion
8.5


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

Re: (Maybe off topic) Can someone explain what a finite state machine is?

[rusi]

On Jul 19, 6:32 pm, Matty Sarro  wrote:
> Hey everyone. I am currently reading through an RFC, and it mentions
> that a client and server half of a transaction are embodied by finite
> state machines. I am reading through the wikipedia article for finite
> state machines, and sadly it's going a bit above my head. I don't
> really have a background in engineering, and would really love to
> understand what is being said. Does anyone have a simple way to
> explain it?

Yes... "background in engineering" is what a layperson would assume
from the words "finite state machine" but this is not really so
(unless you think math is the same as engineering) because the words
were invented by mathematicians (no normal engineer would call a
machine an 'automaton' -- the original name!)

So assuming and staying within python a natural example would be what
is called lexical analysis or tokenizing.

Say you have a line of python like:

def foo(count,   x  ="if nothing is given") # catch a comment anyone?

the python interpreter in its lexical analysis phase breaks this up as
|def|foo|(|count|,|x||=|"if nothing is given"|)|

Some of the things it does are:
1. Separating between all these tokens or lexemes
2. Distinguishing identifiers like foo, count, x (there's no
difference at this stage) from keywords like def
3. Discarding spaces but after using them to separate 'def' from 'foo'
4. Identifying special symbols like ( , = etc
5. Throwing away the comment

Now how does python know that the catch in the comment (or the if in
the string) are not the python keywords?

Well this is where the notion of state comes in:
It starts in a default or normal state but when it sees the " it goes
to (or is it gotos?) a state which we may call InsideStringState. In
this state everything is swallowed up indiscriminately until the next
"  Likewise an InCommentState would swallow up everything from # to
newline.

So to tokenize python it would be natural to think with 3 states:
Normal, InString and InComment

Of course in real programming languages there would be many more
states than 3.
eg What happens when the machine is in InString state and you
encounter a backslash?

Or more hairy example: Say you have a language like C whose comments
are /*... */
Now when you see a / is it a divide symbol or a comment?
All such problems get solved by introducing suitable states like
MaybeComment


In short, dont focus your attention on 'machine' but on 'state' and
you should be fine
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[rantingrick]

On Jul 19, 11:28 pm, Steven D'Aprano  wrote:
>
> Have you tried Tkinter version 8.0 or better, which offers a native look and
> feel?

Steven, you have no buisness offering advice on Tkinter since you
yourself have proclaimed that YOU NEVER used the module and never
will. Stick to what you know please.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Geodetic functions library GeoDLL 32 Bit and 64 Bit

[Lutz Horn]

Hi,

do you think this is the right place to advertise proprietary and
commercial software?

Lutz

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

ANN: ActivePython 3.2.1.2 is now available

[Sridhar Ratnakumar]

ActiveState is pleased to announce ActivePython 3.2.1.2, a complete, 
ready-to-install binary distribution of Python 3.2.

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


What's New in ActivePython-3.2.1.2
==

(combining with the very recently released 3.2.1.1)

New Features & Upgrades
---

- Upgrade to Python 3.2.1 (`release notes
  `__)
- Upgrade to pythonselect 1.3 which supports Windows
- Include virtualenv (1.6.3) and pip (1.0.2)
- Upgrade to PyPM 1.3.5:

  - [Windows] `Bug #89474 `_:
automatically expand %APPDATA%\Python\Scripts
  - Bug #90382: --no-ignore option to fail immediately for missing packages

- Upgraded the following packages:

  - Distribute-0.6.19

Noteworthy Changes & Bug Fixes
--

- PyPM:

  - `sudo pypm ..` should always use root user's BE license file
  - Bug #89540: `uninstall` command now properly removes symlinks
  - Bug #89648: shebang fixer skips symlinks 
  - Upgrade SQLAlchemy to 0.6.8
  - Upgrade to six 1.0.0


What is ActivePython?
=

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

  http://www.activestate.com/python

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

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

  C:\>pypm install numpy
  [...]

  C:\>python
  >>> import numpy.linalg
  >>>

See this page for full details:

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

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

An online version of the docs can be found here:

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

We would welcome any and all feedback to:

  activepython-feedb...@activestate.com

Please file bugs against ActivePython at:

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

Supported Platforms
===

ActivePython is available for the following platforms:

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

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

More information about the Business Edition can be found here:

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

Custom builds are available in the Enterprise Edition:

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

Thanks, and enjoy!

The Python Team

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

A little complex usage of Beautiful Soup Parsing Help!

[SAKTHEESH]

I am using Beautiful Soup to parse a html to find all text that is Not
contained inside any anchor elements

I came up with this code which finds all links within href but not the
other way around.

How can I modify this code to get only plain text using Beautiful
Soup, so that I can do some find and replace and modify the soup?

for a in soup.findAll('a',href=True):
print a['href']


Example:


  test1 
 
 test2
 
 
   This should be identified

   Identify me 1

   Identify me 2
This paragraph should be
identified .
 


Output:

This should be identified
Identify me 1
Identify me 2
This paragraph should be identified.

I am doing this operation to find text not within `` : then
find "Identify" and do replace operation with "Replaced"

So the final output will be like this:


  test1 
 
 test2
 
 
   This should be identified

   Repalced me 1

   Replaced me 2
This paragraph should be
identified .
 


Thanks for your time and help !
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[rusi]

On Jul 20, 9:31 pm, "Uri Guttman"  wrote:
> a better parsing challenge. how can you parse usenet to keep this troll
> from posting on the wrong groups on usenet? first one to do so, wins the
> praise of his peers. 2nd one to do it makes sure the filter stays in
> place. all the rest will be rewarded by not seeing the troll anymore.
>
> anyone who actually engages in a thread with the troll should parse
> themselves out of existance.

Goedelian paradox: Is this thread in existence?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Randal L. Schwartz]

> "Uri" == Uri Guttman  writes:

Uri> a better parsing challenge. how can you parse usenet to keep this troll
Uri> from posting on the wrong groups on usenet? first one to do so, wins the
Uri> praise of his peers. 2nd one to do it makes sure the filter stays in
Uri> place. all the rest will be rewarded by not seeing the troll anymore.

Uri> anyone who actually engages in a thread with the troll should parse
Uri> themselves out of existance.

Since the newsgroups: line is not supposed to have spaces in it, that
makes both his post and your post invalid.  Hence, filter on invalid
posts.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic way with more than one max possible

[CM]

Thanks, everyone.  Very helpful!

Che

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

Re: list(), tuple() should not place at "Built-in functions" in documentation

[Terry Reedy]

On 7/20/2011 2:21 AM, Stefan Behnel wrote:

Terry Reedy, 19.07.2011 18:31:

Chapter 5 is mostly about the behavior of built-in class instances. For
some classes, like range, instances only come from class calls and the
behavior of instances is intimately tied to the constructor arguments.
Having the constructor described in C.5 might be useful.


I strongly disagree.


Wow. Strongly disagreeing with a mild statement like 'might be useful' 
is really strong. But let me explain (using slice rather than range). 
Three of the four non-special attributes of the slice objects produced 
by the slice() function are the three arguments of the function. (The 
fourth is an obscure method.) So the function and its result object are 
closely tied together, and unusually so. Hence it *might* be useful to 
discuss that particular pair together, especially since both are used 
rarely and always together. This is a rather minimal concession to the OP.


But the overall thrust and conclusion of both that post of mine and the 
previous one is that 'function' in 'built-in functions' is best 
understood generically as including objects of type 'type' as well as 
objects of 'builtin_function_or_method' (and any other built-in callable 
if there happen to be any). So the rest of your post is strong agreement 
with what I have said since the beginning of the thread.


What one needs to know about range is that it produces a non-iterator 
re-iterable virtual sequence object that supports a basic subset of the 
sequence operations. The function belongs in the function chapter and 
the sequence object in the sequence section of the classes chapter.


The OP's point makes more sense in the context of other languages that 
make an artificial distinction between functions and constructors and 
require that the latter be preceded by keyword new. I prefer Python's 
uniformity.


--
Terry Jan Reedy

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

Re: a little parsing challenge ☺

[Jason Earl]

On Wed, Jul 20 2011, Randal L. Schwartz wrote:

>> "Uri" == Uri Guttman  writes:
>
> Uri> a better parsing challenge. how can you parse usenet to keep this troll
> Uri> from posting on the wrong groups on usenet? first one to do so, wins the
> Uri> praise of his peers. 2nd one to do it makes sure the filter stays in
> Uri> place. all the rest will be rewarded by not seeing the troll anymore.
>
> Uri> anyone who actually engages in a thread with the troll should parse
> Uri> themselves out of existance.
>
> Since the newsgroups: line is not supposed to have spaces in it, that
> makes both his post and your post invalid.  Hence, filter on invalid
> posts.

I suspect that the spaces you are seeing are being added by Gnus.  I see
them too (and I see them in your post as well), but they disappear when
I use "C-u g" and view the source of the posts.

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

Re: I am fed up with Python GUI toolkits...

[Phlip]

On Jul 20, 10:32 am, rantingrick  wrote:

> Steven, you have no buisness offering advice on Tkinter since you
> yourself have proclaimed that YOU NEVER used the module and never
> will. Stick to what you know please.

Allow me.

Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
GUIs scratchy window with grooves and lines everywhere.

Tkinter is awesome because you can nest anything inside anything else,
and it has an elaborate & extendable properties system.

Oh, and you can TDD it. Unlike some more "modern" GUIs I could
mention...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 22:58, Phlip  wrote:

> Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> GUIs scratchy window with grooves and lines everywhere.

The widget set is limited compared to GTK or Qt, though it has the
most common GUI controls, and it does not look that bad with the
recent ttk styling (it actually doesn't look like Motif anymore). But
it does not have a good GUI builder (that I know of).

Sturla


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

Re: I am fed up with Python GUI toolkits...

[Corey Richardson]

Excerpts from Phlip's message of Wed Jul 20 16:58:08 -0400 2011:
> On Jul 20, 10:32am, rantingrick  wrote:
> 
> > Steven, you have no buisness offering advice on Tkinter since you
> > yourself have proclaimed that YOU NEVER used the module and never
> > will. Stick to what you know please.
> 
> Allow me.
> 
> Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> GUIs scratchy window with grooves and lines everywhere.
> 

Themed Tk (TTK) has come a far way. I'll leave the research for you, however,
as I can not give this post the time it deserves.

-- 
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
 -- Abraham Lincoln


signature.asc
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 20 Jul, 22:58, Phlip  wrote:

> Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> GUIs scratchy window with grooves and lines everywhere.

And using it with OpenGL has been impossible since Python 2.2 (or
whatever).

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

Re: I am fed up with Python GUI toolkits...

[Phlip]

On Jul 20, 3:13 pm, sturlamolden  wrote:

> On 20 Jul, 22:58, Phlip  wrote:
>
> > Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> > GUIs scratchy window with grooves and lines everywhere.
>
> The widget set is limited compared to GTK or Qt, though it has the
> most common GUI controls, and it does not look that bad with the
> recent ttk styling (it actually doesn't look like Motif anymore). But
> it does not have a good GUI builder (that I know of).

Oh, and you can TDD it, too...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[sturlamolden]

On 21 Jul, 00:52, Phlip  wrote:

> Oh, and you can TDD it, too...

No, I can't TDD with Tkinter. All my tests fail when there is no
OpenGL support (Togl is gone). For TDD to work, the tests must have a
chance of passing.



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

Tkinter in Python has native widgets (was: I am fed up with Python GUI toolkits...)

[Ben Finney]

Phlip  writes:

> Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> GUIs scratchy window with grooves and lines everywhere.

Applications have been written that look like that, sure. Many of them
were *written* in the 1980s and 1990s, so the wonder is not how they
look but that they still work today at all.

To continue supporting those old applications, written with the
assumption that the widgets will look like Motif, Tk must default to
looking like ugly old Motif.

But it simply is not true that Tk applications *must* look like Motif,
or even close. We have for a long time had the “themed Tk” extension
http://wiki.tcl.tk/14796> which makes themed and/or native widgets
in Tk.

Python's Tkinter has this at the ‘tkinter.ttk’ module
http://docs.python.org/py3k/library/tkinter.ttk.html>, or for
Python 2 at http://pypi.python.org/pypi/pyttk>.

> Oh, and you can TDD it. Unlike some more "modern" GUIs I could
> mention...

Yes, the ability to test one's GUI from unit test code is a huge plus.

-- 
 \   “Everyone is entitled to their own opinions, but they are not |
  `\entitled to their own facts.” —US Senator Pat Moynihan |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[rantingrick]

RE: *Ben Finney changes thread subject*

Please everyone, do not change the subject of someone's thread because
it's considered rude. Thank you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What Programing Language are the Largest Website Written In?

[igotmumps]

On Jul 13, 1:04 pm, ccc31807  wrote:
> On Jul 12, 7:54 am, Xah Lee  wrote:
>
> > maybe this will be of interest.
>
> > 〈What Programing Language Are the Largest Website Written 
> > In?〉http://xahlee.org/comp/website_lang_popularity.html
>
> About five years ago, I did some pretty extensive research, and
> concluded that the biggest sites were written serverside with JSP.
> Obviously, this wouldn't include The Biggest site, but if you were a
> big, multinational corporation, or listed on the NYSE, you used JSP
> for your web programming.
>
> I doubt very seriously PHP is used for the biggest sites -- I'd still
> guess JSP, or maybe a MS technology (not VB), but it's only a guess.
>
> CC.

I believe Facebook uses a PHP/C compiler.  i.e. the site is written in
PHP, but compiled down to C/C++...

MZ

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

Re: changing thread topics (was: I am fed up with Python GUI toolkits...)

[Tim Chase]

On 07/20/2011 08:17 PM, rantingrick wrote:


RE: *Ben Finney changes thread subject*

Please everyone, do not change the subject of someone's thread because
it's considered rude. Thank you.


Right...do not change the subject because it's considered rude. 
Change it because the topic drifted from the original topic and a 
fitting subject line helps people decide whether they want to 
read any subsequent sub-threads.  That's just email etiquette as 
old as the tubes.


-tkc


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

Re: What Programing Language are the Largest Website Written In?

[Michael Steinfeld]

2011/7/20 igotmumps :
> On Jul 13, 1:04 pm, ccc31807  wrote:
>> On Jul 12, 7:54 am, Xah Lee  wrote:
>>
>> > maybe this will be of interest.
>>
>> > 〈What Programing Language Are the Largest Website Written 
>> > In?〉http://xahlee.org/comp/website_lang_popularity.html
>>
>> About five years ago, I did some pretty extensive research, and
>> concluded that the biggest sites were written serverside with JSP.
>> Obviously, this wouldn't include The Biggest site, but if you were a
>> big, multinational corporation, or listed on the NYSE, you used JSP
>> for your web programming.
>>
>> I doubt very seriously PHP is used for the biggest sites -- I'd still
>> guess JSP, or maybe a MS technology (not VB), but it's only a guess.
>>
>> CC.
>
> I believe Facebook uses a PHP/C compiler.  i.e. the site is written in
> PHP, but compiled down to C/C++...
>
> MZ


not all sites use one language exclusively. For example, facebook
status updates use their python non blocking web server "Tornado". Not
sure if that means the interface code is python but just putting that
out there.

Where I work, the majority of the site is ruby, about 70% and 30%
python. Many ad-hoc parts of the site use different languages
(primarily python) to provide data for reports.



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

Re: I am fed up with Python GUI toolkits...

[rantingrick]

RE: *Tim Chase changes topic and talks smack*

On Jul 20, 8:38 pm, Tim Chase  wrote:
> On 07/20/2011 08:17 PM, rantingrick wrote:
>
> > RE: *Ben Finney changes thread subject*
>
> > Please everyone, do not change the subject of someone's thread because
> > it's considered rude. Thank you.
>
> Right...do not change the subject because it's considered rude.
> Change it because the topic drifted from the original topic and a
> fitting subject line helps people decide whether they want to
> read any subsequent sub-threads.  That's just email etiquette as
> old as the tubes.

What about the etiquette of staying on topic? The only person who is
OFFICIALLY allowed to change the subject matter of a thread is the OP.
Sure some folks might make an off topic post here and there however i
find it bombastically rude when folks just change a topic of thread
they do not own.

How would you like it if i came to your house and wrote my name on
your refrigerator door, or used your toilet without asking, or slept
in your bed? I would not do that because i have manners. Feel free to
make yourself comfortable but don't put you feet on the coffee table.
-- 
http://mail.python.org/mailman/listinfo/python-list

Changing subject sucks. Re: I am fed up with Python GUI toolkits...

[Phlip]

On Jul 20, 6:17 pm, rantingrick  wrote:
> RE: *Ben Finney changes thread subject*
>
> Please everyone, do not change the subject of someone's thread because
> it's considered rude. Thank you.

No it isn't. Rambling off on a new topic under the wrong subject is
rude.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[alex23]

rantingrick  wrote:
> The old "reinvent the wheel" argument is only valid when wheels
> already exists. Currently we have triangles (or maybe pentagons) but
> no wheels.

No, currently we have a small handful of people who feel the wheels
are triangles but have done nothing more than complain about it, while
those who don't feel likewise continue to cycle on them smoothly.

The "reinvent the wheel" argument is only valid when the affected
people do something other than whine.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am fed up with Python GUI toolkits...

[alex23]

rantingrick  wrote:
> What about the etiquette of staying on topic?

Such as raising your personal opinion of online etiquette in a thread
on GUI toolkits?

As always, there's what you say, and there's what you do, and never
the twain shall meet.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing subject sucks. Re: I am fed up with Python GUI toolkits...

[Steven D'Aprano]

On Thu, 21 Jul 2011 12:34 pm Phlip wrote:

> On Jul 20, 6:17 pm, rantingrick  wrote:
>> RE: *Ben Finney changes thread subject*
>>
>> Please everyone, do not change the subject of someone's thread because
>> it's considered rude. Thank you.
> 
> No it isn't. Rambling off on a new topic under the wrong subject is
> rude.


Ha ha, rantingrick lecturing others on rudeness! How cute!

Or hypocritical. Sometimes I get those two confused.


-- 
Steven

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

Re: I am fed up with Python GUI toolkits...

[Cameron Simpson]

On 20Jul2011 19:06, rantingrick  wrote:
| 
| RE: *Tim Chase changes topic and talks smack*
| 
| On Jul 20, 8:38 pm, Tim Chase  wrote:
| > On 07/20/2011 08:17 PM, rantingrick wrote:
| >
| > > RE: *Ben Finney changes thread subject*
| >
| > > Please everyone, do not change the subject of someone's thread because
| > > it's considered rude. Thank you.
| >
| > Right...do not change the subject because it's considered rude.
| > Change it because the topic drifted from the original topic and a
| > fitting subject line helps people decide whether they want to
| > read any subsequent sub-threads.  That's just email etiquette as
| > old as the tubes.
| 
| What about the etiquette of staying on topic? The only person who is
| OFFICIALLY allowed to change the subject matter of a thread is the OP.
| Sure some folks might make an off topic post here and there however i
| find it bombastically rude when folks just change a topic of thread
| they do not own.

You're labouring under a misapprehension. The OP doesn't "own" the
thread. Starting a thread on a public list is like throwing a party.
People are going to come. And talk, damn their impudence!

It is good to stay near the topic, but threads will inevitably drift
unless they're talking about something utterly trite. It is good of an
author to mark his/her departure from the main topic, should it be
significant, with a subject change. Or even a new thread.

| How would you like it if i came to your house

You can stop there, thanks.

You continue to confuse a cooperative anarchy with some kind of
stringent autocracy or heavily premoderated forum or something.
As with your docstring formatting opinions or your spaces-vs-tabs
opinions: mandating behaviour is a little pointless - it can't be
enforced, few directives are unambiguously one sidedly good and so
mandating stuff is divisive and will drive people away.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

It's quite difficult to remind people that all this stuff was here for a
million years before people. So the idea that we are required to manage it is
ridiculous. What we are having to manage is us.
- Bill Ballantine, marine biologist
-- 
http://mail.python.org/mailman/listinfo/python-list