date:20100607

Alfred Bovin wrote:
> I'm working on something where I need to read a (binary) file bit by bit
> and do something depending on whether the bit is 0 or 1.

Well, smallest unit you can read is an octet/byte. You then check the
individual digits of the byte using binary masks.


   f = open(...)
   data = f.read()
   for byte in data:
   for i in range(8):
   bit = 2**i & byte
   ...

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Re: Reading file bit by bit

Alfred Bovin wrote:

> I'm working on something where I need to read a (binary) file bit by bit
> and do something depending on whether the bit is 0 or 1.
> 
> Any help on doing the actual file reading is appreciated.

The logical unit in which files are written is the byte. You can split the 
bytes into 8 bits...

>>> def bits(f):
... while True:
... b = f.read(1)
... if not b: break
... b = ord(b)
... for i in range(8):
... yield b & 1
... b >>= 1
...
>>> with open("tmp.dat", "wb") as f: # create a file with some example data
... f.write(chr(0b11001010)+chr(0b1010))
>>> with open("tmp.dat", "rb") as f:
... for bit in bits(f):
... print bit
...
0
1
0
1
0
0
1
1
1
1
1
1
0
1
0
1

but that's a very inefficient approach. If you explain what you are planning 
to do we can most certainly come up with a better alternative.

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

Re: Reading file bit by bit

2010-06-07 Thread Richard Thomas

On Jun 7, 10:17 am, Peter Otten <__pete...@web.de> wrote:
> Alfred Bovin wrote:
> > I'm working on something where I need to read a (binary) file bit by bit
> > and do something depending on whether the bit is 0 or 1.
>
> > Any help on doing the actual file reading is appreciated.
>
> The logical unit in which files are written is the byte. You can split the
> bytes into 8 bits...
>
> >>> def bits(f):
>
> ...     while True:
> ...             b = f.read(1)
> ...             if not b: break
> ...             b = ord(b)
> ...             for i in range(8):
> ...                     yield b & 1
> ...                     b >>= 1
> ...>>> with open("tmp.dat", "wb") as f: # create a file with some example data
>
> ...     f.write(chr(0b11001010)+chr(0b1010))>>> with open("tmp.dat", 
> "rb") as f:
>
> ...     for bit in bits(f):
> ...             print bit
> ...
> 0
> 1
> 0
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 1
> 1
> 0
> 1
> 0
> 1
>
> but that's a very inefficient approach. If you explain what you are planning
> to do we can most certainly come up with a better alternative.
>
> Peter

You're reading those bits backwards. You want to read the most
significant bit of each byte first...

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

Re: weird pickle behavior in Python 3.1.2 + Eclipse 3.5.2

kirby.ur...@gmail.com wrote:

> On Jun 4, 9:47 am, Peter Otten <__pete...@web.de> wrote:
> 
>> I can provoke the error in "naked" Python 3 by changing the
>> Example.__module__ attribute:
>>
>> Python 3.1.1+ (r311:74480, Nov  2 2009, 15:45:00)
>> [GCC 4.4.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
> 
>> >>> import pickle
>> >>> class Example:
>>
>> ... pass
>> ...
>> >>> pickle.dumps(Example())
>>
>> b'\x80\x03c__main__\nExample\nq\x00)\x81q\x01}q\x02b.'
> 
>> >>> Example.__module__ = "builtins"
>> >>> pickle.dumps(Example())
>>
>> Traceback (most recent call last):
>> File "", line 1, in 
>> File "/usr/lib/python3.1/pickle.py", line 1358, in dumps
>> Pickler(f, protocol, fix_imports=fix_imports).dump(obj)
>> _pickle.PicklingError: Can't pickle : attribute lookup
>> builtins.Example failed
>>
>> What's the value of __module__ when you run your code in Eclipse?
>>
>> Peter
> 
> Thank you for replying.
> 
> Here's from Eclipse console:
> 
 Example.__module__
> 'builtins'
> 
 __name__
> 'builtins'
> 
> Duplicating your result in naked Python:
> 
> Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "copyright", "credits" or "license()" for more information.
 class Example:
> pass
> 
 import pickle
 Example.__module__
> '__main__'
 f = open('testpickle.pkl','wb')
 obj = Example()
 obj
> <__main__.Example object at 0x02A26690>
 pickle.dump(obj, f)
> 
 Example.__module__ = 'builtins'
 obj2 = Example()
> 
 pickle.dump(obj2, f)
> Traceback (most recent call last):
>   File "", line 1, in 
> pickle.dump(obj2, f)
>   File "C:\Python31\lib\pickle.py", line 1354, in dump
> Pickler(file, protocol, fix_imports=fix_imports).dump(obj)
> _pickle.PicklingError: Can't pickle : attribute
> lookup builtins.Example failed
> 
> So what if I'm in an Eclipse pydev console and
> change the Example.__module__ to '__main__'
> 
 import sys; print('%s %s' % (sys.executable or sys.platform,
 sys.version))
> C:\Python31\python.exe 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC
> v.1500 32 bit (Intel)]
 import pickle
 class Example:
> ... pass
> ...
 Example.__module__
> 'builtins'
 Example.__module__ = '__main__'
 obj = Example()
 obj
> <__main__.Example object at 0x029E8FD0>
 f = open('testpickle.pkl','wb')
 pickle.dump(obj, f)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Python31\lib\pickle.py", line 1354, in dump
> Pickler(file, protocol, fix_imports=fix_imports).dump(obj)
> _pickle.PicklingError: Can't pickle :
> attribute lookup __main__.Example failed

> 
> Dang.
> 
> Any insights?

Sorry, no. Consider a bug report to the pydev project.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread ant

I rather feel like I'm flogging a dead horse here, but time for
another mile...

First off, I'm not volunteering to lead this effort. I don't think
anyone should
even think about that until and unless the Python Powers That Be
actually
decide that it is worth doing. That is what I meant by 'strong
leadership'.

Second; 'A minor programming language'. According to

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Visual Basic is more popular than Python. That makes me feel that
there
is something wrong with the world.

Third: "I'm curious why you think fragmented GUI choices is a
particular
 problem for Python compared to other languages? Or why this is the
 main issue holding Python back? "
It's not a particular problem for Python compared to other languages.
It's a general problem for all programming languages. But I presume
that you read this newgroup because you think Python is in some sense
'better' than other programming languages. And I think we can make it
better still.

Fourth: " BTW, what's your plan for producing such a leader?  Because
if we
 don't have a leader it's kind of a moot point.  (I know some people
 asked you to volunteer, but I suspect you would agree that you're
not
 up to the task, so I assume you are merely a visionary and have
 someone lined up that you've somehow convince to do the dirty work
of
 leadership.) "
I'm not a visionary and I don't have someone lined up. And I am
certainly
not up to the task myself. But I have watched with interest the
process of
turning Python2.x into Python3.x.  Does that give any hints about who
I
think should be considering this topic (see first point)?


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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Nobody

On Sun, 06 Jun 2010 15:55:41 -0700, ant wrote:

> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.

You forgot:

3) Drop Tkinter and don't provide any GUI toolkit as part of the standard
library.

It seems to have worked out okay for C and C++.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Adam Tauno Williams

On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote:
> On 06/07/10 12:18, Adam Tauno Williams wrote:
> > On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote:
> >> On 06/07/10 10:48, Adam Tauno Williams wrote:
> >>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
>  On Jun 7, 10:55 am, ant  wrote:
> > My concern is simple: I think that Python is doomed to remain a minor
> > language unless we crack this problem.
>  I'm curious why you think fragmented GUI choices is a particular
>  problem for Python compared to other languages? Or why this is the
>  main issue holding Python back?
> >>> The base assumption is: there is some core issue holding Python back?  
> >>> Nah.
> >> Any thought about drag-and-drop GUI builder in IDLE?
> > Sure; someone should write one, or several.  That isn't a toolkit issue.
> Sure it is, if it's concerning ease of writing a GUI-based program using
> that particular toolkit.

Yes, because the IDE (toolchain) is lacking.  Which isn't about the
underlying toolkit - both Qt and Gtk provide the ability to load a UI
from an XML file.  Then the IDE needs to understand relating GUI events
to signal handlers in the code.  AFAIK, that doesn't exist for Python.
However the underlying functionality *does* exist, and work, and has for
some time.  I can assign a method to an event in Glade - but it is still
entirely up to the programmer to create a method with the same name and
the correct signature in the correct class - which is entirely automated
in Java / .NET IDEs.  That is a big deal as applications become larger
and more sophisticated,  it removes an enormous amount of tedium.

NOTE: Glade is obsolete, GtkBuilder is the replacement, but I can't find
anything on GtkBuilder + Python.

> > But then I don't know any of the local Python devs who use IDLE;  the
> > IDE landscape for Python is very fragmented,  which disincentives that
> > happening.  
> I don't use IDLE either, but IDLE comes by default with standard
> distribution of python.
>  .NET/C# has had preferred GUI APIs come and go and isn't exactly what
>  I'd call crossplatform, 
> >>> Well, if you use Gtk# for your GUI it is probably one of the [if not
> >>> "the"] most cross-platform development solution for complex fat-clients.
>  Looking at the state of other languages and their GUI toolkit
>  landscape, someone might even come to the conclusion that having one
>  true GUI toolkit is potentially a bad thing for a language.
> >>> +1  In the end the relationships with GUI toolkits is far more about
> >>> tool-chain and documentation then it is about language.  If there was an
> >>> awesome IDE that allowed RAD [of real complex applications] in toolkit X
> >>> then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
> >>> support for Mono/.NET is a good example;  the tool makes the toolkit
> >>> east to use - people go with the toolkit].
> >> The problem with the current GUI toolkits is their API is designed to be
> >> cross-language (i18n). I'd say, keep the current GUI toolkits, make
> >> their API easier to use (l10n).
> > Which is 'just' an implementation detail.  
> Why is a GUI toolkit *API* an *implementation detail*? 

You are missing the point.  PyQt, PyGtk, etc.. are wrappers/bindings
around Qt, Gtk, etc... respectively.  So it *is* an implementation
detail of the wrapper/binding to make the API 'pythonic'.  Changing
class names, rewriting method signatures, adding glue - is a binding
issue.

> They seems to be
> contradictory to me. The simplicity and ease of use of a library depends
> on how well-designed their API is,

Yea.  Which is an implementation detail.

>  and how "pythonic" the API appears to
> a python programmer (unittest, for example, looks more Java-ish than
> pythonic).

So... improve the binding.  That is a really silly reason to develop a
new toolkit.

-- 
Adam Tauno Williams  LPIC-1, Novell CLA

OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

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

Re: Reading file bit by bit

Ulrich Eckhardt wrote:
>data = f.read()
>for byte in data:
>for i in range(8):
>bit = 2**i & byte
>...

Correction: Of course you have to use ord() to get from the single-element
string ("byte" above) to its integral value first.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Re: Reading file bit by bit

2010-06-07 Thread Lie Ryan

On 06/07/10 19:31, Richard Thomas wrote:
> On Jun 7, 10:17 am, Peter Otten <__pete...@web.de> wrote:
>> Alfred Bovin wrote:
>>> I'm working on something where I need to read a (binary) file bit by bit
>>> and do something depending on whether the bit is 0 or 1.
>>
>>> Any help on doing the actual file reading is appreciated.
>>
>> The logical unit in which files are written is the byte. You can split the
>> bytes into 8 bits...
>>
> def bits(f):
>>
>> ... while True:
>> ... b = f.read(1)
>> ... if not b: break
>> ... b = ord(b)
>> ... for i in range(8):
>> ... yield b & 1
>> ... b >>= 1
>> ...>>> with open("tmp.dat", "wb") as f: # create a file with some example 
>> data
>>
>> ... f.write(chr(0b11001010)+chr(0b1010))>>> with open("tmp.dat", 
>> "rb") as f:
>>
>> ... for bit in bits(f):
>> ... print bit
>> ...
>> 0
>> 1
>> 0
>> 1
>> 0
>> 0
>> 1
>> 1
>> 1
>> 1
>> 1
>> 1
>> 0
>> 1
>> 0
>> 1
>>
>> but that's a very inefficient approach. If you explain what you are planning
>> to do we can most certainly come up with a better alternative.
>>
>> Peter
> 
> You're reading those bits backwards. You want to read the most
> significant bit of each byte first...

Of course that depends on the need of the OP?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Simon Hibbs

On 6 June, 23:55, ant  wrote:

>If we are to make progress, I can see two obvious approaches:
>1) Improve Tkinter to the point where it is supportable and supported
>by a good fraction of Python programmers
>or
>2) Drop Tkinter as the default and use something else.

IIRC Guido has ruled out officialy adopting a full-bore GUI toolkit
such as WxPython or PyQT, or even a supercharged verison of Tkinter,
into the standard library. There are two main reasons. One is that
doing so would more than double the standard Python distribution's
disk footprint, to no advantage for non-graphical target systems or
developers wanting to use native GUI APIs. Another is that it wouldn't
make any of the other options go away, so e.g. if PyQT were chosen,
anyone wanting to use WxPython would have to install it as well,
creating even more bloat.

GUI toolkits are major projects with their own development cycles and
roadmaps that may not match with that of the standard library. They
are also still rapidly evolving. The standard library should only
contain stable, mature code bases. Furthermore the core Python dev
team have limited resources. Increasing the officialy maintained code
base by 2x or more just isn't supportable.

Tkinter is perfectly adequate for basic GUIs. If you want something
more sophisticated there are plently of high quality, well documented
alternatives to match your platform or functionality requirements.

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

Re: Reading file bit by bit

Richard Thomas wrote:

> On Jun 7, 10:17 am, Peter Otten <__pete...@web.de> wrote:
>> Alfred Bovin wrote:
>> > I'm working on something where I need to read a (binary) file bit by
>> > bit and do something depending on whether the bit is 0 or 1.
>>
>> > Any help on doing the actual file reading is appreciated.
>>
>> The logical unit in which files are written is the byte. You can split
>> the bytes into 8 bits...
>>
>> >>> def bits(f):
>>
>> ... while True:
>> ... b = f.read(1)
>> ... if not b: break
>> ... b = ord(b)
>> ... for i in range(8):
>> ... yield b & 1
>> ... b >>= 1
>> ...>>> with open("tmp.dat", "wb") as f: # create a file with some example
>> data
>>
>> ... f.write(chr(0b11001010)+chr(0b1010))>>> with open("tmp.dat",
>> "rb") as f:
>>
>> ... for bit in bits(f):
>> ... print bit
>> ...
>> 0
>> 1
>> 0
>> 1
>> 0
>> 0
>> 1
>> 1
>> 1
>> 1
>> 1
>> 1
>> 0
>> 1
>> 0
>> 1
>>
>> but that's a very inefficient approach. If you explain what you are
>> planning to do we can most certainly come up with a better alternative.
>>
>> Peter
> 
> You're reading those bits backwards. You want to read the most
> significant bit of each byte first...
> 
> Richard.

>>> def bits(f):
... while True:
... byte = f.read(1)
... if not byte: break
... byte = ord(byte)
... for i in reversed(range(8)):
... yield byte >> i & 1
...
>>> with open("tmp.dat", "rb") as f:
... for bit in bits(f):
... print bit,
...
1 1 0 0 1 0 1 0 1 0 1 0 1 1 1 1

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

Re: Tkinter help - Why this behavior ? (py3)

2010-06-07 Thread Dodo


Le 05/06/2010 19:07, Alf P. Steinbach a écrit :

* Dodo, on 05.06.2010 15:46:

Hi,

let's consider this exemple :

from tkinter import *
from tkinter.ttk import *

class First:
def __init__(self):
self.root = Tk()
B = Button(self.root, command=self.op)
B.pack()

self.root.mainloop()

def op(self):
Second(self)
print("print")


class Second:
def __init__(self, parent):
root = Toplevel(parent.root)
root.grab_set()

root.mainloop()


First()



when I close the second window, the print is NOT executed. It's done
when I close the first window.
Why do it "freeze" my function?


First, sorry about Thunderbird 3.x messing up the quoting of the code.

Don't know what they did to introduce all those bugs, but anyway,
Thunderbird 3.x is an example that even seasoned programmers introduce
an unbelievable number of bugs, I think mostly just by repeating code
patterns blindly.

In your code above you're doing as the TB programmers presumably did,
repeating a code pattern that you've seen has worked, without fully
grokking it. The call to 'mainloop' enters a loop. A button press causes
your callback to be invoked from within that loop, but your code then
enters a new 'mainloop'.

Don't.

Except for modal dialogs the single top level 'mainloop' suffices (all
it does is to dispatch "messages" to "handlers", such as your button
press callback). So, just place a single call to 'mainloop' at the end
of your program. Remove the calls in 'First' and 'Second'.


Cheers & hth.,

- Alf




How do I create custom modal dialogs then?

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

Re: Reading file bit by bit

2010-06-07 Thread Nobody

On Mon, 07 Jun 2010 02:31:08 -0700, Richard Thomas wrote:

> You're reading those bits backwards. You want to read the most
> significant bit of each byte first...

Says who?

There is no universal standard for bit-order.

Among bitmap image formats, XBM is LSB-first while BMP and PBM are
MSB-first. OpenGL reads or writes bitmap data in either order, controlled
by glPixelStorei().

Most serial communication links (e.g. RS-232, ethernet) transmit the LSB
first, although there are exceptions (e.g. I2C uses MSB-first).

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

Re: map is useless!

2010-06-07 Thread James Mills

On Mon, Jun 7, 2010 at 9:20 AM, Steven D'Aprano
 wrote:
>> Ruby has a very nice map
>
> I'm thrilled for them. Personally I think the syntax is horrible.

I concur!

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

Re: Reading file bit by bit

Nobody wrote:
> On Mon, 07 Jun 2010 02:31:08 -0700, Richard Thomas wrote:
> 
>> You're reading those bits backwards. You want to read the most
>> significant bit of each byte first...
> 
> Says who?

Says Python:

>>> bin(192)
'0x1100'

That said, I totally agree that there is no inherently right way and I guess
Richard was just a smiley or two short in order to have correct markup in
his not-so-serious posting.

:^)

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Simple hack to get $500 to your home.

2010-06-07 Thread SUHASINI

Simple hack to get $500 to your home at http://mastidunia.tk

Due to high security risks,i have hidden the cheque link in an
image.  in that website on left side below search box, click on image
and enter your name and address where you want to receive your
cheque.please dont tell to anyone.
-- 
http://mail.python.org/mailman/listinfo/python-list

python2.5 x python2.6 in interactive mode

2010-06-07 Thread Alan

Hi there,

I have a code with a 'exit()' at the end. We run it usually as:

python2.5 -i code.py

and if everything is fine, the 'exit()' is called and there's no interactive
terminal.

However, doing the same above with python2.6 and I got:

amadeus[2738]:~/TMP% python2.6 -i thread_ping.py
Traceback (most recent call last):
  File "thread_ping.py", line 42, in 
exit()
  File "/sw/lib/python2.6/site.py", line 334, in __call__
raise SystemExit(code)
SystemExit: None
>>>

So, everything is fine except that it ended up in the interactive python
terminal. Is there a way of having the very behaviour I have with python 2.5
for my code in python 2.6?

Many thanks in advance,

Alan

-- 
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>http://www.bio.cam.ac.uk/~awd28<<
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading file bit by bit

Ulrich Eckhardt wrote:

> Nobody wrote:
>> On Mon, 07 Jun 2010 02:31:08 -0700, Richard Thomas wrote:
>> 
>>> You're reading those bits backwards. You want to read the most
>>> significant bit of each byte first...
>> 
>> Says who?
> 
> Says Python:
> 
 bin(192)
> '0x1100'

Hmm, if that's what /your/ Python says, here's mine to counter:

>>> bin(192)
'0_totally_faked_binary_0011'

;)

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

Re: Reading file bit by bit

Peter Otten wrote:
> Ulrich Eckhardt wrote:
>> Says Python:
>> 
> bin(192)
>> '0x1100'
> 
> Hmm, if that's what /your/ Python says, here's mine to counter:
> 
 bin(192)
> '0_totally_faked_binary_0011'

Argh! Of course one of my Pythons says '0b1100' and not what I mistyped
above =(

Uli
*goes and hides under a stone*

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Re: Reading file bit by bit

2010-06-07 Thread superpollo


Ulrich Eckhardt ha scritto:

Peter Otten wrote:

Ulrich Eckhardt wrote:

Says Python:


bin(192)

'0x1100'

Hmm, if that's what /your/ Python says, here's mine to counter:


bin(192)

'0_totally_faked_binary_0011'


Argh! Of course one of my Pythons says '0b1100' and not what I mistyped
above =(


mine goes like this:

>>> bin(192)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'bin' is not defined

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

Re: Missing DLL in win98

2010-06-07 Thread Jean-Michel Pichavant


Spyder42 wrote:

On Fri, 04 Jun 2010 14:03:48 -0400, Terry Reedy 
wrote:

  

On 6/4/2010 9:08 AM, Spyder42 wrote:


On Fri, 04 Jun 2010 14:50:28 +0200, Christian Heimes
  

Python 2.6 is not supported on Windows 98 and earlier. You need at least
Windows 2000 with a recent service pack.

Christian


So your response is either, you don't know if there is a fix, or 'No
way in h377.' You couldn't figure out by my post that I already knew
that?
  
Get off your high horse. Dumping on volunteer helpers is a good way to 
drive them away.


It was not obvious, without closely reading your original post, and even 
then it is not clear, that you *knew* than 2.6 was not supported on 
Win98. You could have asked 'I know 2.6+ is not officially supported in 
win98. Does anyone know a workaround other than upgrading windows or 
sticking with 2.5?". *That* would have been clear.


Terry Jan Reedy




I'm sorry, but if I asked where the nearest gas station was, I
wouldn't expect someone to answer, "You can't get there because your
out of gas."

I had a specific question and I got a non-specific non-answer. 
If they didn't know, they should not have answered.


  

It was not obvious, without closely reading your original post...



So it WAS obvious to anyone who was PAYING ATTENTION?
  
I think Terry just wanted to be kind to you by not saying you're 
completely wrong. Thing is, it was not obvious, enven for those who paid 
attention.

Life is not a dress rehersal. If you don't get it right, things like
the BP's oil spill, Chernobyl, and 3 mile island happen. Perhaps I'm
being extreme, but computer programs underly our entire civilization
today. Computers dump stock, and Billions are lost, needlessly
affecting everyones life. Trains crash, boats sink, and psychos like
me go off the deep end, because no-one is paying attention.

L8r
Spyder

  

Funny :) You almost got a Godwin point !

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Ben Finney

ant  writes:

> First off, I'm not volunteering to lead this effort. I don't think
> anyone should even think about that until and unless the Python Powers
> That Be actually decide that it is worth doing. That is what I meant
> by 'strong leadership'.

In that case, you have rather a misconception about how these things
progress. The PtB in Python won't be saying anything normative on the
matter unless there is an established code base to inspect, preferably
with an established user base of that code.

There's not a lot of point in pronouncing either way on vapourware. If
you claim it would be a useful thing to have, let's see the tangible
demonstration of that claim in the form of Python libraries.

-- 
 \  “The most common way people give up their power is by thinking |
  `\   they don't have any.” —Alice Walker |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading file bit by bit

superpollo wrote:
> mine goes like this:
> 
>  >>> bin(192)
> Traceback (most recent call last):
>File "", line 1, in 
> NameError: name 'bin' is not defined

Yep, one of mine, too. The "bin" function was new in 2.6, as were binary
number literals ("0b1100").

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Re: Tkinter help - Why this behavior ? (py3)

2010-06-07 Thread Alf P. Steinbach


* Dodo, on 07.06.2010 12:38:

Le 05/06/2010 19:07, Alf P. Steinbach a écrit :

* Dodo, on 05.06.2010 15:46:

Hi,

let's consider this exemple :

from tkinter import *
from tkinter.ttk import *

class First:
def __init__(self):
self.root = Tk()
B = Button(self.root, command=self.op)
B.pack()

self.root.mainloop()

def op(self):
Second(self)
print("print")


class Second:
def __init__(self, parent):
root = Toplevel(parent.root)
root.grab_set()

root.mainloop()


First()



when I close the second window, the print is NOT executed. It's done
when I close the first window.
Why do it "freeze" my function?


First, sorry about Thunderbird 3.x messing up the quoting of the code.

Don't know what they did to introduce all those bugs, but anyway,
Thunderbird 3.x is an example that even seasoned programmers introduce
an unbelievable number of bugs, I think mostly just by repeating code
patterns blindly.

In your code above you're doing as the TB programmers presumably did,
repeating a code pattern that you've seen has worked, without fully
grokking it. The call to 'mainloop' enters a loop. A button press causes
your callback to be invoked from within that loop, but your code then
enters a new 'mainloop'.

Don't.

Except for modal dialogs the single top level 'mainloop' suffices (all
it does is to dispatch "messages" to "handlers", such as your button
press callback). So, just place a single call to 'mainloop' at the end
of your program. Remove the calls in 'First' and 'Second'.




How do I create custom modal dialogs then?


I typed

  tkinter modal dialog

in the Firefox address bar, and it landed me on

  http://effbot.org/tkinterbook/tkinter-dialog-windows.htm


Cheers & hth.,

- Alf


--
blog at http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Steven D'Aprano

On Mon, 07 Jun 2010 03:08:19 -0700, ant wrote:

> First off, I'm not volunteering to lead this effort. I don't think
> anyone should
> even think about that until and unless the Python Powers That Be
> actually
> decide that it is worth doing. That is what I meant by 'strong
> leadership'.

You have the process backwards there. The Python-Dev team isn't going to 
push one GUI toolkit as the One True Toolkit unless the wider community 
standardises on it first.

Consider the plight of the Python developers. They're an all-volunteer 
effort, and although a handful of them are partially funded by the PSF or 
other companies like Google, they're still chronically undermanned and 
overworked. Just go and look at the bug tracker and see how many bugs 
languish for want of somebody to work on them. The last thing they're 
going to do is take on a project of the magnitude of creating a new GUI 
toolkit. A full-featured toolkit is a project at least as big as the rest 
of Python plus the standard library, and probably bigger. You're asking 
them to double their work load to suit your aesthetic judgement that none 
of the existing toolkits are good enough.

[...]
> Third: "I'm curious why you think fragmented GUI choices is a particular
>  problem for Python compared to other languages? Or why this is the main
>  issue holding Python back? "
> It's not a particular problem for Python compared to other languages.
> It's a general problem for all programming languages.

I don't see why you think so. Well, Apple believes so, and twenty years 
ago I agreed with them, but having looked at how Macintosh and it's 
consistent look-and-feel has repeatedly failed to set the world alight 
against Windows and its multitude of inconsistent GUIs, I'm no longer 
convinced by Steve Jobs' argument.

It's 2010 and despite all of Apple's marketing, design excellence and 
consumer mindshare, their share of the PC market is still about the same 
as it was in the mid-80s and well under their peak of 12% in 1993. 
(Depending on who is doing the reporting and how they calculate the 
numbers, Apple Macintosh has anything from 3% to 8% market share, not 
that much better than Linux at 1-2%. And the Linux figure is for sales, 
not installations).

It seems to me that a consistent, best-of-breed look-and-feel is good for 
creating a brand, but flexibility and choice is good for capturing a 
market.

Consistency carries it's own dangers, and what you call "fragmentation" 
simply means that GUI toolkits exist in a free market of ideas rather 
than a centrally-planned monopoly. For idiots^W those who like Gnome, 
there is PyGTK; for those who prefer their window manager to be 
perpetually in pre-beta, there is PyKDE; if you like QT, there is PyQt; 
if you have no aesthetic sense at all, there is tkinter; if you have a 
hankering for the Good Old Days programming in Hypercard on a Mac SE, 
there is Pythoncard; if you've drunk the corporate Koolaid, there are 
Jython and IronPython with their own GUI widgets; if you want the choice 
of developing for the desktop or the web, you might choose Pyjamas; and 
so on.

There is, hopefully, a GUI toolkit for everyone, and no best-of-breed 
because people will never agree on what best-of-breed would mean. You 
call this fragmentation -- I call it freedom of choice.

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

Re: Drop Table w/ MySQLdb?


On 06/06/2010 21:20, Dennis Lee Bieber wrote:

On Sun, 6 Jun 2010 11:07:25 -0400, Victor Subervi
  declaimed the following in
gmane.comp.python.general:


Hi;
I tried this:

 cursor.execute('drop table tmp%s', tmpTable)


ONCE AGAIN...

Database SCHEMA entities must be formatted using the Python %
operator. AND they should never be obtained as input from a user.

DATA ITEMS obtained from anywhere need to use parameterized query
passing so that the DB-API can safely escape them, and in the case of
MySQLdb, put quote marks around them.

SCHEMA entities are: DATABASE name, TABLE name, COLUMN name (and if
you have them, TRIGGER, PROCEDURE, and VIEW names).

The statement you have is SCHEMA manipulation.

Print this out and tape it to your monitor. The next time you get
one of these "inexplicable" error messages, review the above statements
and compare to your query. I'm sure the answer will be obvious.


Do you have edit access to the MySQLdb files? If so, open
cursors.py, find the execute method, and put in a print statement. This
does also assume you are running locally (not via a web client) so that
the output can be seen on screen.

(Mine is located in E:\Python25\Lib\site-packages\MySQLdb\cursors.py)

Look for:

-=-=-=-=-
 def execute(self, query, args=None):

 """Execute a query.

 query -- string, query to execute on server
 args -- optional sequence or mapping, parameters to use with
query.

 Note: If args is a sequence, then %s must be used as the
 parameter placeholder in the query. If a mapping is used,
 %(key)s must be used as the placeholder.

 Returns long integer rows affected, if any

 """
 from types import ListType, TupleType
 from sys import exc_info
 del self.messages[:]
 db = self._get_db()
 charset = db.character_set_name()
 if isinstance(query, unicode):
 query = query.encode(charset)
 if args is not None:
 query = query % db.literal(args)
 try:
 r = self._query(query)
 except TypeError, m:
 if m.args[0] in ("not enough arguments for format string",
  -=-=-=-=-
and change

 if args is not None:
 query = query % db.literal(args)

into
 if args is not None:
 query = query % db.literal(args)
 print query

Notice how your use of % for testing does NOT generate the same code
-- MySQLdb invokes db.literal() to escape the arguments, but you are
doing just
query = query % (args)



 cursor.execute('drop table tmp%s', tmpTable)


produces
drop table tmp'xyz'
NOT
drop table tmpxyz



Well put Sir.  Can I suggest that the OPs continual requests for 
assistance are simply not cricket? :)  Yeah, I'm a Brit, and yeah, I'm 
fed up with getting thrashed by the Aussies.


Kindest regards.

Mark Lawrence.

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

Re: Reading file bit by bit

2010-06-07 Thread Grant Edwards

On 2010-06-07, Richard Thomas  wrote:

> You're reading those bits backwards. You want to read the most
> significant bit of each byte first...

Can you explain the reasoning behind that assertion?

-- 
Grant Edwards   grant.b.edwardsYow! I can't decide which
  at   WRONG TURN to make first!!
  gmail.comI wonder if BOB GUCCIONE
   has these problems!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal


On 06/06/2010 22:11, rantingrick wrote:

On Jun 6, 2:06 pm, Mark Lawrence  wrote:

On 06/06/2010 16:31, rantingrick wrote:




On Jun 5, 9:22 pm, antwrote:



I ask the group; should we try to create a new GUI for Python, with
the following
properties?:



- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form



Yes i one hundred percent agree! The only problem is i am the only
one! Good luck finding others to climb into this boat. From the
beginning there has has been this really weird love-hate relationship
with Tkinter in the Python community. I myself experience this
emotional attachment every day as i wish for Tkinter to be more
"pretty" and "feature-rich" whilst at the same time loving it's
simplicity. Tkinter seems to be Python's whipping boy and nobody wants
to whip another, so we are stuck in limbo with a lobotomy.



Heres an idea though, why not expand Tkinter with some new really cool
widgets...? Hmmm...? That TIX package is a real PITA and could use a
re-write. Can you believe it took until py3.0 for Tkinter to get a
combobox :-O! Yea i know! :'-(


Patches are welcome at any time.  I look forward to seeing your first
contribution.

Kindest regards.

Mark Lawrence.


Hello Mark,

Are you maintaining Tkinter or Tix or both? There is a nagging issue
with Tix that needs fixing. Upon subbclassing some widgets and when
using the import Tix and import Tix as *. Maybe it is already fixed in
3.0 (i have not checked) but we need to fix it.

I am still currently rewriting Tkinter Tix and IDLE in my spare time
but got a bit busy lately. Anyhoo, i would really like to bring some
patches, upgrades, and just a general spit shining to the entire three-
plexx so let me know.


I don't maintain either, I'm looking forward to seeing you do it.

Regards.

Mark Lawrence.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread python

Ant,

Have you checked out the Dabo framework? Dabo provides a set of tools
and underlying framework that makes VB style GUI development possible
using Python.

Dabo is designed to be GUI framework independent however it currently
only supports wxPython.

Dabo has a very friendly and helpful mailing list if you want to give it
a try.

Dabo can be found here:
http://dabodev.org

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

Re: GUIs - A Modest Proposal

On 07/06/2010 04:31, Carl Banks wrote:

On Jun 5, 7:22 pm, ant wrote:

I get the strong feeling that nobody is really happy with the state of
Python GUIs.
Tkinter is not widely liked, but is widely distributed. WxPython and
PyGtk are both
powerful, but quirky in different ways. PyQt is tied to one platform.
And there are
dozens more.

Whether or not we like graphics programming, it's not going to go
away. I get the
uneasy feeling whenever I start a new project that there should be a
'better' GUI
than the ones I currently use (WxPython and PyGtk).

Fragmentation is our enemy. Our resources are being dissipated. Is it
not time to
start again? We have shown that it is possible to do the right thing,
by creating Python3.

I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form

If so, what are the next steps?

The Python SIG on GUIs closed years ago. Should that be revived?

This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
that
we eat our own babies.

But don't we owe it to the community?

Speaking for myself, PySide has resolved this issue for me. I used
PyQt for some things but didn't want to use it for everything because
of the license, but I'd be ok to use PySide for anything. It's
portable to the major systems and generally better (IMHO) than the
other toolkits.

Carl Banks

Carl,

Thanks for mentioning PySide, if I'd ever heard about it I'd forgotten.

To OP.

See the following link as to why you've got so many comments:)
http://www.symbian-freak.com/news/009/08/first_public_release_of_pyside_for_qt_and_maemo.htm

Kindest regards.

Mark Lawrence.

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

Re: Python Forum

2010-06-07 Thread python

> However, it would be nice to have an expire function so that messages that I 
> don't read for a specified time simply disappear. Do any email clients do 
> that?

I use Fastmail.fm as my email service (and browser based email client).
Fastmail supports the ability to automatically delete messages > a
specific age on a folder by folder basis. Fastmail also supports a
variety of ways to file messages into folders - from simple to
sophisticated (Sieve based).

Highly recommended!

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

PyQt signals/slots dialogs question

Hi,

I'm just starting to get to grips with PyQt, and I'm having a bit of
trouble connecting slots / signals, or understanding how I should do
so to achieve what I am after.

I am trying to write an application that will display a sequence of
dialogs, with back / next / cancel buttons to step through the
dialogs. Each dialog will capture user input, ask the user to browse
for a file, present some radio-buttons for a selection etc..

I've put the dialogs together in Designer, and I come to startup the
app with a small piece of python code, create an instance of each
dialog, and then connect up the buttons to any methods needed to
control the movement through the dialogs etc.

I'm having a brain-freeze though, and just can't figure out what I
should be doing next, or the best approach to take.

for example, Currently I am thinking I would need to connect the
clicked() signal of the Next button on dialog 1 to a method say,
'dialog1Next' that would then hide dialog1 and show dialog2.  I would
then need to connect Dialog 2's clicked() signal of its next button to
a method called 'dialog2Next' that hides dialog2 and shows dialog3
etc...

I would also, for example,  need methods for dialog2Back,
dialog2cancel, dialog1cancel etc..

I'm having trouble figuring out how to setup the connections, and
where the slot-methods should live..

I have this so far;

from PyQt4 import QtCore, QtGui
from WELCOME import Ui_Dialog as welcomeDialog
from SOURCE_TYPE_SELECT import Ui_Dialog as sourceTypeSelectDialog
from SOURCE_TYPE_CONFIRMATION import Ui_Dialog as
sourceTypeConfirmationDialog
from ACCEPT_EULA import Ui_Dialog as acceptEulaDialog
from CONFIRM_REQUIREMENTS import Ui_Dialog as
confirmRequirementsDialog
from SOURCE_BINARY_LOCATE import Ui_Dialog as sourceBinaryLocateDialog
from SOURCE_BINARY_PROBLEMS import Ui_Dialog as
sourceBinaryProblemsDialog
from OUTFILE_LOCATE import Ui_Dialog as outfileLocateDialog
from OUTFILE_PROBLEMS import Ui_Dialog as outfileProblemsDialog
from COLLECTION_PROGRESS import Ui_Dialog as collectionProgressDialog
from OUTFILE_LOCATION import Ui_Dialog as outfileLocationDialog



class StartQT4(QtGui.QDialog):
def __init__(self, parent=None):
QtGui.QWidget.__init__(self, parent)
self.Welcome = welcomeDialog()
self.Welcome.setupUi(self)
self.SourceTypeSelect = sourceTypeSelectDialog()
self.SourceTypeConfirmation = sourceTypeConfirmationDialog()
self.AcceptEula = acceptEulaDialog()
self.ConfirmRequirements=confirmRequirementsDialog()
self.SourceBinaryLocate=sourceBinaryLocateDialog()
self.SourceBinaryProblems=sourceBinaryProblemsDialog()
self.OutfileLocate=outfileLocateDialog()
self.OutfileProbelms=outfileProblemsDialog()
self.CollectionProgress=collectionProgressDialog()
self.OutfileLocation=outfileLocationDialog

#Connect up next/back/cancel etc.. buttons

??? self.Welcome.connect(self.Welcome.welcomeNext,
QtCore.SIGNAL("clicked()"),WelcomeNext)



def WelcomeNext():
#Code here to hide Welcome dialog and show SourceTypeSelect
dialog



if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
myapp = StartQT4()
myapp.show()
sys.exit(app.exec_())





My questions are, am I approaching this the right way, with a method
per action per dialog to move through the dialogs, and just how do I
setup the connections I need. I'm getting confused with scope etc. IE:
if the connect is right, and WelcomeNext fires, how can it refer to
myapp.SourceTypeSelect.show() or myapp.Welcome.hide()


Any help much appreciated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Carl Banks

On Jun 7, 3:08 am, ant  wrote:
> I rather feel like I'm flogging a dead horse here, but time for
> another mile...
>
> First off, I'm not volunteering to lead this effort. I don't think
> anyone should
> even think about that until and unless the Python Powers That Be
> actually
> decide that it is worth doing. That is what I meant by 'strong
> leadership'.
>
> Second; 'A minor programming language'. According to
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> Visual Basic is more popular than Python. That makes me feel that
> there
> is something wrong with the world.

Sloth and Envy are two of the seven deadly sins.  Not really a healthy
attitude.


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

Re: PyQt signals/slots dialogs question

2010-06-07 Thread Phil Thompson

On Mon, 7 Jun 2010 08:22:07 -0700 (PDT), AlienBaby

wrote:
> Hi,
> 
> I'm just starting to get to grips with PyQt, and I'm having a bit of
> trouble connecting slots / signals, or understanding how I should do
> so to achieve what I am after.
> 
> I am trying to write an application that will display a sequence of
> dialogs, with back / next / cancel buttons to step through the
> dialogs. Each dialog will capture user input, ask the user to browse
> for a file, present some radio-buttons for a selection etc..
> 
> I've put the dialogs together in Designer, and I come to startup the
> app with a small piece of python code, create an instance of each
> dialog, and then connect up the buttons to any methods needed to
> control the movement through the dialogs etc.
> 
> I'm having a brain-freeze though, and just can't figure out what I
> should be doing next, or the best approach to take.
> 
> for example, Currently I am thinking I would need to connect the
> clicked() signal of the Next button on dialog 1 to a method say,
> 'dialog1Next' that would then hide dialog1 and show dialog2.  I would
> then need to connect Dialog 2's clicked() signal of its next button to
> a method called 'dialog2Next' that hides dialog2 and shows dialog3
> etc...
> 
> I would also, for example,  need methods for dialog2Back,
> dialog2cancel, dialog1cancel etc..
> 
> I'm having trouble figuring out how to setup the connections, and
> where the slot-methods should live..
> 
> I have this so far;
> 
> from PyQt4 import QtCore, QtGui
> from WELCOME import Ui_Dialog as welcomeDialog
> from SOURCE_TYPE_SELECT import Ui_Dialog as sourceTypeSelectDialog
> from SOURCE_TYPE_CONFIRMATION import Ui_Dialog as
> sourceTypeConfirmationDialog
> from ACCEPT_EULA import Ui_Dialog as acceptEulaDialog
> from CONFIRM_REQUIREMENTS import Ui_Dialog as
> confirmRequirementsDialog
> from SOURCE_BINARY_LOCATE import Ui_Dialog as sourceBinaryLocateDialog
> from SOURCE_BINARY_PROBLEMS import Ui_Dialog as
> sourceBinaryProblemsDialog
> from OUTFILE_LOCATE import Ui_Dialog as outfileLocateDialog
> from OUTFILE_PROBLEMS import Ui_Dialog as outfileProblemsDialog
> from COLLECTION_PROGRESS import Ui_Dialog as collectionProgressDialog
> from OUTFILE_LOCATION import Ui_Dialog as outfileLocationDialog
> 
> 
> 
> class StartQT4(QtGui.QDialog):
> def __init__(self, parent=None):
> QtGui.QWidget.__init__(self, parent)
> self.Welcome = welcomeDialog()
> self.Welcome.setupUi(self)
> self.SourceTypeSelect = sourceTypeSelectDialog()
> self.SourceTypeConfirmation = sourceTypeConfirmationDialog()
> self.AcceptEula = acceptEulaDialog()
> self.ConfirmRequirements=confirmRequirementsDialog()
> self.SourceBinaryLocate=sourceBinaryLocateDialog()
> self.SourceBinaryProblems=sourceBinaryProblemsDialog()
> self.OutfileLocate=outfileLocateDialog()
> self.OutfileProbelms=outfileProblemsDialog()
> self.CollectionProgress=collectionProgressDialog()
> self.OutfileLocation=outfileLocationDialog
> 
> #Connect up next/back/cancel etc.. buttons
> 
> ??? self.Welcome.connect(self.Welcome.welcomeNext,
> QtCore.SIGNAL("clicked()"),WelcomeNext)
> 
> 
> 
> def WelcomeNext():
> #Code here to hide Welcome dialog and show SourceTypeSelect
> dialog
> 
> 
> 
> if __name__ == "__main__":
>   app = QtGui.QApplication(sys.argv)
>   myapp = StartQT4()
>   myapp.show()
>   sys.exit(app.exec_())
> 
> 
> 
> 
> 
> My questions are, am I approaching this the right way, with a method
> per action per dialog to move through the dialogs, and just how do I
> setup the connections I need. I'm getting confused with scope etc. IE:
> if the connect is right, and WelcomeNext fires, how can it refer to
> myapp.SourceTypeSelect.show() or myapp.Welcome.hide()
> 
> 
> Any help much appreciated.

Sounds like you are trying to build a wizard the hard way.

Use Designer to create a QWizard with the contents of each of your dialogs
as a QWizardPage.

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

Re: PyQt signals/slots dialogs question

I've made a little progress;

This appears to setup a connection that fires when the welcomeNext
button in the Welcome dialog is clicked;

self.Welcome.welcomeNext.connect(self.Welcome.welcomeNext,QtCore.SIGNAL("clicked()"),self.WelcomeNext)


In the StartQT4 class I now have the WelcomeNext method;

def WelcomeNext(self):
self.Welcome.setVisible(False)
self.SourceTypeSelect.setVisible(True)

Though I am now getting

AttributeError: 'Ui_Dialog' object has no attribute 'setVisible'

Which, is right. Because it's not really a QDialog class.

Instead of using a 'WelcomeNext' method as the slot, should I just
connect the clicked() signal to both the hide slot of the welcome
dialog and the show slot of the SourceTypeSelect dialog?  .. though
then where would any code I wanted to run say, (for the sake of
argument) between the hiding of one dialog and the showing of the
next?

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

os.path.normpath question

2010-06-07 Thread Bart

I'm using this and ran across backslash issues in one of my paths.

 archpath = os.path.normpath('E:\foo\FTP\HLS\archive')

was translating to:

 E:\lsfprod\law\uch_interfaces\FTP\HLSrchive

which caused me to start using the 'raw' declaration before the path
string like this:

 archpath = os.path.normpath(r'E:\foo\FTP\HLS\archive')

Is this the right way to use this?

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

Re: PyQt signals/slots dialogs question

On Jun 7, 4:37 pm, Phil Thompson  wrote:
> On Mon, 7 Jun 2010 08:22:07 -0700 (PDT), AlienBaby
> 
> wrote:
>
>
>
>
>
> > Hi,
>
> > I'm just starting to get to grips with PyQt, and I'm having a bit of
> > trouble connecting slots / signals, or understanding how I should do
> > so to achieve what I am after.
>
> > I am trying to write an application that will display a sequence of
> > dialogs, with back / next / cancel buttons to step through the
> > dialogs. Each dialog will capture user input, ask the user to browse
> > for a file, present some radio-buttons for a selection etc..
>
> > I've put the dialogs together in Designer, and I come to startup the
> > app with a small piece of python code, create an instance of each
> > dialog, and then connect up the buttons to any methods needed to
> > control the movement through the dialogs etc.
>
> > I'm having a brain-freeze though, and just can't figure out what I
> > should be doing next, or the best approach to take.
>
> > for example, Currently I am thinking I would need to connect the
> > clicked() signal of the Next button on dialog 1 to a method say,
> > 'dialog1Next' that would then hide dialog1 and show dialog2.  I would
> > then need to connect Dialog 2's clicked() signal of its next button to
> > a method called 'dialog2Next' that hides dialog2 and shows dialog3
> > etc...
>
> > I would also, for example,  need methods for dialog2Back,
> > dialog2cancel, dialog1cancel etc..
>
> > I'm having trouble figuring out how to setup the connections, and
> > where the slot-methods should live..
>
> > I have this so far;
>
> > from PyQt4 import QtCore, QtGui
> > from WELCOME import Ui_Dialog as welcomeDialog
> > from SOURCE_TYPE_SELECT import Ui_Dialog as sourceTypeSelectDialog
> > from SOURCE_TYPE_CONFIRMATION import Ui_Dialog as
> > sourceTypeConfirmationDialog
> > from ACCEPT_EULA import Ui_Dialog as acceptEulaDialog
> > from CONFIRM_REQUIREMENTS import Ui_Dialog as
> > confirmRequirementsDialog
> > from SOURCE_BINARY_LOCATE import Ui_Dialog as sourceBinaryLocateDialog
> > from SOURCE_BINARY_PROBLEMS import Ui_Dialog as
> > sourceBinaryProblemsDialog
> > from OUTFILE_LOCATE import Ui_Dialog as outfileLocateDialog
> > from OUTFILE_PROBLEMS import Ui_Dialog as outfileProblemsDialog
> > from COLLECTION_PROGRESS import Ui_Dialog as collectionProgressDialog
> > from OUTFILE_LOCATION import Ui_Dialog as outfileLocationDialog
>
> > class StartQT4(QtGui.QDialog):
> >     def __init__(self, parent=None):
> >         QtGui.QWidget.__init__(self, parent)
> >         self.Welcome = welcomeDialog()
> >         self.Welcome.setupUi(self)
> >         self.SourceTypeSelect = sourceTypeSelectDialog()
> >         self.SourceTypeConfirmation = sourceTypeConfirmationDialog()
> >         self.AcceptEula = acceptEulaDialog()
> >         self.ConfirmRequirements=confirmRequirementsDialog()
> >         self.SourceBinaryLocate=sourceBinaryLocateDialog()
> >         self.SourceBinaryProblems=sourceBinaryProblemsDialog()
> >         self.OutfileLocate=outfileLocateDialog()
> >         self.OutfileProbelms=outfileProblemsDialog()
> >         self.CollectionProgress=collectionProgressDialog()
> >         self.OutfileLocation=outfileLocationDialog
>
> >         #Connect up next/back/cancel etc.. buttons
>
> > ???     self.Welcome.connect(self.Welcome.welcomeNext,
> > QtCore.SIGNAL("clicked()"),WelcomeNext)
>
> > def WelcomeNext():
> >         #Code here to hide Welcome dialog and show SourceTypeSelect
> > dialog
>
> > if __name__ == "__main__":
> >    app = QtGui.QApplication(sys.argv)
> >    myapp = StartQT4()
> >    myapp.show()
> >    sys.exit(app.exec_())
>
> > My questions are, am I approaching this the right way, with a method
> > per action per dialog to move through the dialogs, and just how do I
> > setup the connections I need. I'm getting confused with scope etc. IE:
> > if the connect is right, and WelcomeNext fires, how can it refer to
> > myapp.SourceTypeSelect.show() or myapp.Welcome.hide()
>
> > Any help much appreciated.
>
> Sounds like you are trying to build a wizard the hard way.
>
> Use Designer to create a QWizard with the contents of each of your dialogs
> as a QWizardPage.
>
> Phil- Hide quoted text -
>
> - Show quoted text -

Interesting idea. I shall take a look, but there is q fair amount of
work that needs to be done between dialogs, validation and other
thoings etc..  Would a QWizard help?


As well, I would like to understand the process of coding my own so I
can build other UI's also.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt signals/slots dialogs question

My real aim here is to learn pyqt, so I would rather not the the
QWizard process until I understand myself whats going on behind the
scenes.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Lie Ryan

On 06/07/10 20:18, Adam Tauno Williams wrote:
> On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote:
>> On 06/07/10 12:18, Adam Tauno Williams wrote:
>>> But then I don't know any of the local Python devs who use IDLE;  the
>>> IDE landscape for Python is very fragmented,  which disincentives that
>>> happening.  
>> I don't use IDLE either, but IDLE comes by default with standard
>> distribution of python.
>> .NET/C# has had preferred GUI APIs come and go and isn't exactly what
>> I'd call crossplatform, 
> Well, if you use Gtk# for your GUI it is probably one of the [if not
> "the"] most cross-platform development solution for complex fat-clients.
>> Looking at the state of other languages and their GUI toolkit
>> landscape, someone might even come to the conclusion that having one
>> true GUI toolkit is potentially a bad thing for a language.
> +1  In the end the relationships with GUI toolkits is far more about
> tool-chain and documentation then it is about language.  If there was an
> awesome IDE that allowed RAD [of real complex applications] in toolkit X
> then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
> support for Mono/.NET is a good example;  the tool makes the toolkit
> east to use - people go with the toolkit].
 The problem with the current GUI toolkits is their API is designed to be
 cross-language (i18n). I'd say, keep the current GUI toolkits, make
 their API easier to use (l10n).
>>> Which is 'just' an implementation detail.  
>> Why is a GUI toolkit *API* an *implementation detail*? 
> 
> You are missing the point.  PyQt, PyGtk, etc.. are wrappers/bindings
> around Qt, Gtk, etc... respectively.  So it *is* an implementation
> detail of the wrapper/binding to make the API 'pythonic'.  Changing
> class names, rewriting method signatures, adding glue - is a binding
> issue.

binding is part of the programmer-facing API, therefore it's not an
implementation detail.

>> They seems to be
>> contradictory to me. The simplicity and ease of use of a library depends
>> on how well-designed their API is,
> 
> Yea.  Which is an implementation detail.
> 
>>  and how "pythonic" the API appears to
>> a python programmer (unittest, for example, looks more Java-ish than
>> pythonic).
> 
> So... improve the binding.  That is a really silly reason to develop a
> new toolkit.

isn't that my whole point?
-- 
http://mail.python.org/mailman/listinfo/python-list

Python + vim + spaces vs tab

2010-06-07 Thread Jean-Michel Pichavant


Hello,

Does anyone knows a way to configure vim so it automatically select to 
correct expandtab value depending on the current buffer 'way of doing' ?
I need to edit different files, some are using spaces, others tabs. 
Those belong to different projects, and changing all spaces to tabs is 
not an option for me.


I can't make vim automatically comply with the current buffer coding 
style, anyone knows if it is possible ?


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

Re: Python + vim + spaces vs tab

2010-06-07 Thread Neil Cerutti

On 2010-06-07, Jean-Michel Pichavant  wrote:
> Hello,
>
> Does anyone knows a way to configure vim so it automatically
> select to correct expandtab value depending on the current
> buffer 'way of doing' ? I need to edit different files, some
> are using spaces, others tabs. Those belong to different
> projects, and changing all spaces to tabs is not an option for
> me.
>
> I can't make vim automatically comply with the current buffer
> coding style, anyone knows if it is possible ?

:h filetypes will get you started on the right path. It'll be up
to you to program the recognition logic. Do you have a heuristic
in mind?

You will be better off converting tabbed files to be tabless,
which is pretty easy in vim.

:set expandtab
:set tabstop=N
:retab

N should be whatever value makes the file look right, usually 4
or 8.

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

Re: os.path.normpath question

Bart wrote:

> I'm using this and ran across backslash issues in one of my paths.
> 
>  archpath = os.path.normpath('E:\foo\FTP\HLS\archive')
> 
> was translating to:
> 
>  E:\lsfprod\law\uch_interfaces\FTP\HLSrchive
> 
> which caused me to start using the 'raw' declaration before the path
> string like this:
> 
>  archpath = os.path.normpath(r'E:\foo\FTP\HLS\archive')
> 
> Is this the right way to use this?

Yes, but os.path.normpath() has nothing to with it. It's just how Python 
translates any string literal to a string object, see

http://docs.python.org/reference/lexical_analysis.html#string-literals

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

Re: vector addition

2010-06-07 Thread Dan Stromberg

Call me strange, but I regard this as a good place to use a functional style
- IE, to use reduce, and furthermore I regard this as a good example of why
reduce is useful for more than just summing numbers:

#!/disc/gx/sdfw/dans/python26/bin/python

import collections

def count_first_letters(dictionary, string_):
   dictionary[string_[0]] += 1
   return dictionary

print reduce(
   count_first_letters,
   ['abc', 'def', 'air', 'ghi'],
   collections.defaultdict(int),
   )


On Sat, Jun 5, 2010 at 7:01 PM, MRAB  wrote:

> GZ wrote:
>
>> Hi,
>>
>> I am looking for a fast internal vector representation so that
>> (a1,b2,c1)+(a2,b2,c2)=(a1+a2,b1+b2,c1+c2).
>>
>> So I have a list
>>
>> l = ['a'a,'bb','ca','de'...]
>>
>> I want to count all items that start with an 'a', 'b', and 'c'.
>>
>> What I can do is:
>>
>> count_a = sum(int(x[1]=='a') for x in l)
>> count_b = sum(int(x[1]=='b') for x in l)
>> count_c = sum(int(x[1]=='c') for x in l)
>>
>> But this loops through the list three times, which can be slow.
>>
>> I'd like to have something like this:
>> count_a, count_b, count_c =
>> sum( (int(x[1]=='a',int(x[1]=='b',int(x[1]=='c')   for x in l)
>>
>> I hesitate to use numpy array, because that will literally create and
>> destroy a ton of the arrays, and is likely to be slow.
>>
>>  If you want to do vector addition then numpy is the way to go. However,
> first you could try:
>
>from collections import defaultdict
>counts = defaultdict(int)
>for x in l:
>counts[x[0]] += 1
>
> (Note that in Python indexes are zero-based.)
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt signals/slots dialogs question

On Jun 7, 5:21 pm, AlienBaby  wrote:
> My real aim here is to learn pyqt, so I would rather not the the
> QWizard process until I understand myself whats going on behind the
> scenes.

Perhaps I posted to early, but a little more perserverance and I have
managed to unthaw the brain and move forward.  I've ended up with the
following. It does what I need, and now it's working I can think
around how to implement with a better approach;


from PyQt4 import QtCore, QtGui
from WELCOME import Ui_Dialog as welcomeDialog
from SOURCE_TYPE_SELECT import Ui_Dialog as sourceTypeSelectDialog
from SOURCE_TYPE_CONFIRMATION import Ui_Dialog as
sourceTypeConfirmationDialog

..>snip<

class WelcomeDialog(QtGui.QDialog):
def __init__(self,parent=None):
QtGui.QWidget.__init__(self,parent)
self.ui=welcomeDialog()
self.ui.setupUi(self)

class SourceTypeSelect(QtGui.QDialog):
def __init__(self,parent=None):
QtGui.QWidget.__init__(self,parent)
self.ui=sourceTypeSelectDialog()
self.ui.setupUi(self)

class SourceTypeConfirmation(QtGui.QDialog):
def __init__(self,parent=None):
QtGui.QWidget.__init__(self,parent)
self.ui=sourceTypeConfirmationDialog()
self.ui.setupUi(self)


def WelcomeNext():
welcome.hide()
sourceTypeSelect.show()
def WelcomeCancel():
sys.exit()


def SourceTypeSelectNext():
sourceTypeSelect.hide()
for widget in
sourceTypeSelect.ui.availableChoices.findChildren(QtGui.QWidget):
if widget.isChecked():
print widget.text()
 
sourceTypeConfirmation.ui.selectedSourceType.setText(widget.text())
sourceTypeConfirmation.show()
def SourceTypeSelectCancel():
sys.exit()


def SourceTypeConfirmationBack():
sourceTypeConfirmation.hide()
sourceTypeSelect.show()


if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)

#Instance dialogs and connect buttons
welcome=WelcomeDialog()
 
welcome.ui.welcomeNext.connect(welcome.ui.welcomeNext,QtCore.SIGNAL("clicked()"),WelcomeNext)
 
welcome.ui.welcomeCancel.connect(welcome.ui.welcomeCancel,QtCore.SIGNAL("clicked()"),WelcomeCancel)


sourceTypeSelect=SourceTypeSelect()
 
sourceTypeSelect.ui.sourceTypeSelectNext.connect(sourceTypeSelect.ui.sourceTypeSelectNext,QtCore.SIGNAL("clicked()"),SourceTypeSelectNext)
 
sourceTypeSelect.ui.sourceTypeSelectCancel.connect(sourceTypeSelect.ui.sourceTypeSelectCancel,QtCore.SIGNAL("clicked()"),SourceTypeSelectCancel)


sourceTypeConfirmation=SourceTypeConfirmation()
 
sourceTypeConfirmation.ui.sourceTypeConfirmationBack.connect(sourceTypeConfirmation.ui.sourceTypeConfirmationBack,QtCore.SIGNAL("clicked()"),SourceTypeConfirmationBack)


welcome.show()
sys.exit(app.exec_())




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

Re: GUIs - A Modest Proposal


Ant
I agree that the current tk situation is not completely satisfactory. In 
particular, the IO facilities are inadequate and have not, to my 
knowledge, changed in a decade. Image input formats are limited. There 
is no canvas output as an image. (Output of the canvase display list as 
a dialect of postscript that not everything can read is not a substitute 
for this.)


However...
I think it important that Python come with a minimal IDE that is 
adequate for someone like me doing Python-only development. I thank the 
programmers of IDLE. So merely deleting tk/tkinter is not an option. 
Indeed, having something similar to and at least as good as IDLE for any 
candidate gui replacememt should and I think would be a requirement for 
consideration.


The problem with the big gui application frameworks are that they are 
too big. The two I have glanced at -- wx... and qt -- have much more 
than gui stuff and duplicate parts of the Python stdlib and other 3rd 
party libs.


As for a small gui written in Python, you seem to have ignored the link 
to pygui. Of course that has its own problems. Among others: it is 
incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6), 
which is the only place it could be added; the api sytle is not standard 
in Python (get_xx and set_xx methods instead of direct access or 
properties); and there is nothing yet like IDLE.


What would be required is a Python3 GUI project with multiple contributors.

Terry Jan Reedy

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

Re: Missing DLL in win98


On 6/7/2010 8:15 AM, Jean-Michel Pichavant wrote:

Spyder42 wrote:

On Fri, 04 Jun 2010 14:03:48 -0400, Terry Reedy 

It was not obvious, without closely reading your original post...



So it WAS obvious to anyone who was PAYING ATTENTION?


That is not what I said, as indicated by a further line you snipped.


I think Terry just wanted to be kind to you by not saying you're
completely wrong.


Yes, I was trying to gently educate. To put it plainer, it is the 
responsibility of question askers to make the question clear. If there 
is confusion, the asker should blame himself if anyone. Askers should, 
if saying anything, thank, not punish, anyone who responde with the 
intention of answering or helping.


Terry Jan Reedy

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

Re: Reading file bit by bit


On 6/7/2010 6:20 AM, Ulrich Eckhardt wrote:

Ulrich Eckhardt wrote:

data = f.read()
for byte in data:
for i in range(8):
bit = 2**i&  byte
...


Correction: Of course you have to use ord() to get from the single-element
string ("byte" above) to its integral value first.


In Py3 (OP did not specify), a binary file is read as bytes, which is a 
sequence of ints, and one would have to not use ord() ;=)


tjr



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

Re: Plotting in batch with no display

2010-06-07 Thread Hans Georg Schaathun

On Sat, 5 Jun 2010 16:10:01 + (UTC), Tim Harig
   wrote:
:  On 2010-06-05, Hans Georg Schaathun  wrote:
: > Raster graphics is not good enough, I will need a backend which
: > does vector graphics and pdf output.  AFAICS from the FAQ at
: > sourceforge, agg only supports raster and png.  Cairo supports
: > vector graphics and PDF, but I cannot find any information about
: > how/if it deals with X11...
: 
:  1. I am not familiar with matlab;

Good that my question did not concern matlab then :-)

:but, I have written python programs that
:   generate plots using GNUplot (which can create PDFs).  There are
:   python modules available for working with GNUplot or you can open
:   it yourself under a subprocess and send it commands through a pipe.
:   GNUplot allows you to save files directly and does not therefore
:   require X.

That certainly is an option.  I actually do have an example using
gnuplot, taken from the libsvm tools which I wanted to replace with 
a native python solution :-)  After some testing, I have concluded
though, that that's not necessary.  OTOH, gnuplot is not quite as
easy to learn as the pyplot API.

:  2. If you can generate a raster file with Matlab, you can use ImageMagick
:   (which has python bindings or could be execed directly) or other
:   conversion software to convert the file to whatever format you
:   choose.

Sorry, that's no help.  Firstly, when I started using python it was to 
avoid using matlab...  Secondly, raster graphics gives poor quality when 
it is scaled.  Raster graphics represented in PDF or EPS is no better
than raster graphics in PNG.  I need scalable vector graphics.

:  3. Depending on your requirements, you could generate a plot using
:   postscript.  Postscript is  easy to convert directly to PDF as
:   the two are closely related. As postscript is a powerful
:   language itself you can actually write the graphing routines in
:   postscript and use python to simply embed the data into the
:   postscript.

Sure, but the problem is to find the right matplotlib engine to do 
that.  We live in 2010 and Python is a new and evolving language.
It would be strange if the PS renderer is more advanced than the
PDF renderer, but if it is, I'll use it.

Ideally, I'd like the option to switch between X11 and file output
runtime, which the engine switch (matplotlib.use()) does not support.
Question is, is there an engine to do that?

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

Which objects are expanded by double-star ** operator?

2010-06-07 Thread kkumer


I have to merge two dictionaries into one, and in
a "shallow" way: changing items should be possible
by operating either on two parents or on a
new dictionary. I am open to suggestions how
to do this (values are always numbers, BTW), but
I tried to do it by creating a dict-like class that just
forwards all calls to the two parent dicts, see below.

It works, but one important thing is missing. I
am not able to expand new dictionary with 
double-star operator ** to use it as a
set of keyword arguments of a function. 
I googled a bit, but was unable to find what
property must an object have to be correctly
treated by **.

I hope the following code is self-explanatory:



import itertools

class hubDict(dict):
"""Merges two dictionaries, but not actually but just by forwarding."""

def __init__(self, da, db):
self.d1 = da
self.d2 = db

def __getitem__(self, name):
if self.d1.has_key(name):
return self.d1[name]
else:
return self.d2[name]

def __setitem__(self, name, value):
if self.d1.has_key(name):
self.d1[name] = value
else:
self.d2[name] = value

def __iter__(self):
return itertools.chain(self.d1.__iter__(), self.d2.__iter__())

def has_key(self, name):
if self.d1.has_key(name) or self.d2.has_key(name):
return True
else:
return False

def keys(self):
return self.d1.keys() + self.d2.keys()

def items(self):
return self.d1.items() + self.d2.items()

def iteritems(self):
return itertools.chain(self.d1.iteritems(), self.d2.iteritems())

def iterkeys(self):
return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())

def itervalues(self):
return itertools.chain(self.d1.itervalues(), self.d2.itervalues())

def copy(self):
print "Can't copy hubDict yet!!!"

def update(self, d):
for key in d:
self.__setitem__(key, d[key])

def popitem(self):
try:
return self.d1.popitem()
except KeyError:
return self.d2.popitem()

def __repr__(self):
return 'First: %s\nSecond: %s' % (
self.d1.__repr__(), self.d2.__repr__())


# Trying it now:

da = {'a':1}
db = {'b':2}
dh = hubDict(da, db)
def kwa(**kwargs): print kwargs

#OK
kwa(**da)

#not OK: prints empty dict
kwa(**dh)


import itertools

class hubDict(dict):
"""Merges two dictionaries, but not actually but just by forwarding."""

def __init__(self, da, db):
self.d1 = da
self.d2 = db

def __getitem__(self, name):
if self.d1.has_key(name):
return self.d1[name]
else:
return self.d2[name]

def __setitem__(self, name, value):
if self.d1.has_key(name):
self.d1[name] = value
else:
self.d2[name] = value

def __iter__(self):
return itertools.chain(self.d1.__iter__(), self.d2.__iter__())

def has_key(self, name):
if self.d1.has_key(name) or self.d2.has_key(name):
return True
else:
return False

def keys(self):
return self.d1.keys() + self.d2.keys()

def items(self):
return self.d1.items() + self.d2.items()

def iteritems(self):
return itertools.chain(self.d1.iteritems(), self.d2.iteritems())

def iterkeys(self):
return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())

def itervalues(self):
return itertools.chain(self.d1.itervalues(), self.d2.itervalues())

def copy(self):
print "Can't copy hubDict yet!!!"

def update(self, d):
for key in d:
self.__setitem__(key, d[key])

def popitem(self):
try:
return self.d1.popitem()
except KeyError:
return self.d2.popitem()

def __repr__(self):
return 'First: %s\nSecond: %s' % (
self.d1.__repr__(), self.d2.__repr__())

def __len__(self):
return self.d1.__len__() + self.d2.__len__()

# Trying it now:

da = {'a':1}
db = {'b':2}
dh = hubDict(da, db)
def kwa(**kwargs): print kwargs

#OK
kwa(**da)

#not OK: prints empty dict
kwa(**dh)

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

Re: Importing modules

2010-06-07 Thread Dan Stromberg

On Sun, Jun 6, 2010 at 8:16 PM, Ben Finney

> wrote:

> Anthony Papillion  writes:
>
> > import os
> >
> > os.path.append('$HOME/gsutils/boto')
> >
> > thinking I could then successfully do the import boto statement.
> > Nope.
>
> You'll need to give the literal path. Substitution of environment
> variables isn't performed implicitly in strings.
>
You can however use something like:

os.path.append(os.path.expanduser('~/gsutils/boto'))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: vector addition

On 06/07/2010 07:45 PM, Dan Stromberg wrote:
>
> Call me strange, but I regard this as a good place to use a functional
> style - IE, to use reduce, and furthermore I regard this as a good
> example of why reduce is useful for more than just summing numbers:
>
> #!/disc/gx/sdfw/dans/python26/bin/python
this line is shouting to be replaced with
#!/usr/bin/env python
;-)
>
> import collections
>
> def count_first_letters(dictionary, string_):
>dictionary[string_[0]] += 1
>return dictionary
>
> print reduce(
>count_first_letters,
>['abc', 'def', 'air', 'ghi'],
>collections.defaultdict(int),
>)
>
>
> On Sat, Jun 5, 2010 at 7:01 PM, MRAB  > wrote:
>
> GZ wrote:
>
> Hi,
>
> I am looking for a fast internal vector representation so that
> (a1,b2,c1)+(a2,b2,c2)=(a1+a2,b1+b2,c1+c2).
>
> So I have a list
>
> l = ['a'a,'bb','ca','de'...]
>
> I want to count all items that start with an 'a', 'b', and 'c'.
>
> What I can do is:
>
> count_a = sum(int(x[1]=='a') for x in l)
> count_b = sum(int(x[1]=='b') for x in l)
> count_c = sum(int(x[1]=='c') for x in l)
>
> But this loops through the list three times, which can be slow.
>
> I'd like to have something like this:
> count_a, count_b, count_c =
> sum( (int(x[1]=='a',int(x[1]=='b',int(x[1]=='c')   for x in l)
>
> I hesitate to use numpy array, because that will literally
> create and
> destroy a ton of the arrays, and is likely to be slow.
>
> If you want to do vector addition then numpy is the way to go.
> However,
> first you could try:
>
>from collections import defaultdict
>counts = defaultdict(int)
>for x in l:
>counts[x[0]] += 1
>
> (Note that in Python indexes are zero-based.)
>
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>
>

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

Re: Plotting in batch with no display

2010-06-07 Thread Tim Harig

On 2010-06-07, Hans Georg Schaathun  wrote:
> On Sat, 5 Jun 2010 16:10:01 + (UTC), Tim Harig
>   wrote:
>:  On 2010-06-05, Hans Georg Schaathun  wrote:
>: > Raster graphics is not good enough, I will need a backend which
>: > does vector graphics and pdf output.  AFAICS from the FAQ at
>: > sourceforge, agg only supports raster and png.  Cairo supports
>: > vector graphics and PDF, but I cannot find any information about
>: > how/if it deals with X11...
>: 
>:  1. I am not familiar with matlab;
>
> Good that my question did not concern matlab then :-)

Sorry for the disclaimer. Matlab seemed to be referenced quite a bit and
since I am not familiar with it, I am likely to misunderstand something
that might otherwise be obvious.

>:but, I have written python programs that
>:  generate plots using GNUplot (which can create PDFs).  There are
>:  python modules available for working with GNUplot or you can open
>:  it yourself under a subprocess and send it commands through a pipe.
>:  GNUplot allows you to save files directly and does not therefore
>:  require X.
>
> That certainly is an option.  I actually do have an example using
> gnuplot, taken from the libsvm tools which I wanted to replace with 
> a native python solution :-)  After some testing, I have concluded
> though, that that's not necessary.  OTOH, gnuplot is not quite as
> easy to learn as the pyplot API.

GNUplot is very easy to learn.  I started using it after reading a three
page tutorial.  After you get the idea of how it works, everything else is
just details that you can learn from the online help pages from within
GNUplot itself.

I have never actually used any API to access GNUPlot from python as I
already knew the commands anyway so I have always just given my own data
objects the capability to send the necessary commands through the pipe.
However, just looking at the demo code file for the API at:

http://gnuplot-py.sourceforge.net/

I looks like I could basically use it just based on my GNUplot knowledge.
Its really just a *very* transparent class encapsulation of the GNUplot
commands. (And it creates the same pipe that I use for my code on the
backside)

>:  3. Depending on your requirements, you could generate a plot using
>:  postscript.  Postscript is  easy to convert directly to PDF as
>:  the two are closely related. As postscript is a powerful
>:  language itself you can actually write the graphing routines in
>:  postscript and use python to simply embed the data into the
>:  postscript.
>
> Sure, but the problem is to find the right matplotlib engine to do 
> that.  We live in 2010 and Python is a new and evolving language.

I just through it out there as a possible option.  This is not the kind of
thing that is probably useful for most projects; but, it can be extremely
useful for some situations.

Having a viewing environment based on a Turing complete language means
that you can implement a flexible MVC view componet that the user can
use to manipulate the view of the data simply for the price of having
a Postscript viewer.  This leaves your application free to focus solely on
the business logic.  For comparison, think about an AJAX based web page
where the client merely receives structured data from the server (XML,
JSON, etc) and javascript on the client actually allows the user to choose
how the data is viewed.

Sending data embedded in a postscript file also means that the data is
sent, and can be independantly extracted, along with the graph image itself.

> It would be strange if the PS renderer is more advanced than the
> PDF renderer, but if it is, I'll use it.

I frankly don't know much about PDF other than it is a technology closely
related to Postscript.  I have heard it phrased that PDFs are essentially
based on Postscript technology where the loops have been "unrolled."  I
personally think of PDFs as a form of compiled Postscript where the program
is executed and the results are simply saved and there is no way to
re-execute the program using different data.

As far as the language itself, I find Postscript to be rather intriguing.
It uses a very different philosophy from Python; but, it has some really
neat features that I haven't really seen in other langauges.

> Ideally, I'd like the option to switch between X11 and file output
> runtime, which the engine switch (matplotlib.use()) does not support.
> Question is, is there an engine to do that?

GNUplot chooses its outputs by setting the "terminal" variable.  Terminal
can be set to a text terminal, a graphical terminal, or a number of
different file formats.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which objects are expanded by double-star ** operator?

On 06/07/2010 10:17 PM, kkumer wrote:
> I have to merge two dictionaries into one, and in
> a "shallow" way: changing items should be possible
> by operating either on two parents or on a
> new dictionary. I am open to suggestions how
> to do this (values are always numbers, BTW), but
> I tried to do it by creating a dict-like class that just
> forwards all calls to the two parent dicts, see below.
>
> It works, but one important thing is missing. I
> am not able to expand new dictionary with 
> double-star operator ** to use it as a
> set of keyword arguments of a function. 
> I googled a bit, but was unable to find what
> property must an object have to be correctly
> treated by **.
>   
My guess would be that this only works with dicts, and uses the internal
representation of the dict, not the python-defined methods.
I don't know what you want to do, but you might be better off creating a
special "mergeabledict" type for the parents, and then allow them to
connect, actually copying all items over. Though it might be best just
to use one single dict ;-)

> I hope the following code is self-explanatory:
>
> 
>
> import itertools
>
> class hubDict(dict):
> """Merges two dictionaries, but not actually but just by forwarding."""
>
> def __init__(self, da, db):
> self.d1 = da
> self.d2 = db
>
> def __getitem__(self, name):
> if self.d1.has_key(name):
> return self.d1[name]
> else:
> return self.d2[name]
>
> def __setitem__(self, name, value):
> if self.d1.has_key(name):
> self.d1[name] = value
> else:
> self.d2[name] = value
>
> def __iter__(self):
> return itertools.chain(self.d1.__iter__(), self.d2.__iter__())
>
> def has_key(self, name):
> if self.d1.has_key(name) or self.d2.has_key(name):
> return True
> else:
> return False
>
> def keys(self):
> return self.d1.keys() + self.d2.keys()
>
> def items(self):
> return self.d1.items() + self.d2.items()
>
> def iteritems(self):
> return itertools.chain(self.d1.iteritems(), self.d2.iteritems())
>
> def iterkeys(self):
> return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())
>
> def itervalues(self):
> return itertools.chain(self.d1.itervalues(), self.d2.itervalues())
>
> def copy(self):
> print "Can't copy hubDict yet!!!"
>
> def update(self, d):
> for key in d:
> self.__setitem__(key, d[key])
>
> def popitem(self):
> try:
> return self.d1.popitem()
> except KeyError:
> return self.d2.popitem()
>
> def __repr__(self):
> return 'First: %s\nSecond: %s' % (
> self.d1.__repr__(), self.d2.__repr__())
>
>
> # Trying it now:
>
> da = {'a':1}
> db = {'b':2}
> dh = hubDict(da, db)
> def kwa(**kwargs): print kwargs
>
> #OK
> kwa(**da)
>
> #not OK: prints empty dict
> kwa(**dh)
>
>
> import itertools
>
> class hubDict(dict):
> """Merges two dictionaries, but not actually but just by forwarding."""
>
> def __init__(self, da, db):
> self.d1 = da
> self.d2 = db
>
> def __getitem__(self, name):
> if self.d1.has_key(name):
> return self.d1[name]
> else:
> return self.d2[name]
>
> def __setitem__(self, name, value):
> if self.d1.has_key(name):
> self.d1[name] = value
> else:
> self.d2[name] = value
>
> def __iter__(self):
> return itertools.chain(self.d1.__iter__(), self.d2.__iter__())
>
> def has_key(self, name):
> if self.d1.has_key(name) or self.d2.has_key(name):
> return True
> else:
> return False
>
> def keys(self):
> return self.d1.keys() + self.d2.keys()
>
> def items(self):
> return self.d1.items() + self.d2.items()
>
> def iteritems(self):
> return itertools.chain(self.d1.iteritems(), self.d2.iteritems())
>
> def iterkeys(self):
> return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())
>
> def itervalues(self):
> return itertools.chain(self.d1.itervalues(), self.d2.itervalues())
>
> def copy(self):
> print "Can't copy hubDict yet!!!"
>
> def update(self, d):
> for key in d:
> self.__setitem__(key, d[key])
>
> def popitem(self):
> try:
> return self.d1.popitem()
> except KeyError:
> return self.d2.popitem()
>
> def __repr__(self):
> return 'First: %s\nSecond: %s' % (
> self.d1.__repr__(), self.d2.__repr__())
>
> def __len__(self):
> return self.d1.__len__() + self.d2.__len__()
>
> # Trying it now:
>
> da = {'a':1}
> db = {'b':2}
> dh = hubDict(da, db)
> def kwa(**kwargs): print kwargs
>
> #OK
> kwa(**da)
>
> #not OK: prints empty dict
> kwa(**dh)
>

Re: PyQt signals/slots dialogs question

On 06/07/2010 08:21 PM, AlienBaby wrote:
> On Jun 7, 5:21 pm, AlienBaby  wrote:
>   
>> My real aim here is to learn pyqt, so I would rather not the the
>> QWizard process until I understand myself whats going on behind the
>> scenes.
>> 
> Perhaps I posted to early, but a little more perserverance and I have
> managed to unthaw the brain and move forward.  I've ended up with the
> following. It does what I need, and now it's working I can think
> around how to implement with a better approach;
>   
I haven't done much Qt programming, and all of it in C++, but anyway:

my approach is to subclass QFrame (or, here, QDialog makes sense), and,
in the constructor, set up the UI and call connect(...). In C++, there's
a connect macro -- is there a connect function in QtCore, maybe?
"welcome.ui.welcomeNext.connect(welcome.ui.welcomeNext, ..." doesn't
look right.
>
> from PyQt4 import QtCore, QtGui
> from WELCOME import Ui_Dialog as welcomeDialog
> from SOURCE_TYPE_SELECT import Ui_Dialog as sourceTypeSelectDialog
> from SOURCE_TYPE_CONFIRMATION import Ui_Dialog as
> sourceTypeConfirmationDialog
>
> ..>snip<
>
> class WelcomeDialog(QtGui.QDialog):
> def __init__(self,parent=None):
> QtGui.QWidget.__init__(self,parent)
> self.ui=welcomeDialog()
> self.ui.setupUi(self)
>
> class SourceTypeSelect(QtGui.QDialog):
> def __init__(self,parent=None):
> QtGui.QWidget.__init__(self,parent)
> self.ui=sourceTypeSelectDialog()
> self.ui.setupUi(self)
>
> class SourceTypeConfirmation(QtGui.QDialog):
> def __init__(self,parent=None):
> QtGui.QWidget.__init__(self,parent)
> self.ui=sourceTypeConfirmationDialog()
> self.ui.setupUi(self)
>
>
> def WelcomeNext():
> welcome.hide()
> sourceTypeSelect.show()
> def WelcomeCancel():
> sys.exit()
>
>
> def SourceTypeSelectNext():
> sourceTypeSelect.hide()
> for widget in
> sourceTypeSelect.ui.availableChoices.findChildren(QtGui.QWidget):
> if widget.isChecked():
> print widget.text()
>  
> sourceTypeConfirmation.ui.selectedSourceType.setText(widget.text())
> sourceTypeConfirmation.show()
> def SourceTypeSelectCancel():
> sys.exit()
>
>
> def SourceTypeConfirmationBack():
> sourceTypeConfirmation.hide()
> sourceTypeSelect.show()
>
>
> if __name__ == "__main__":
> app = QtGui.QApplication(sys.argv)
>
> #Instance dialogs and connect buttons
> welcome=WelcomeDialog()
>  
> welcome.ui.welcomeNext.connect(welcome.ui.welcomeNext,QtCore.SIGNAL("clicked()"),WelcomeNext)
>  
> welcome.ui.welcomeCancel.connect(welcome.ui.welcomeCancel,QtCore.SIGNAL("clicked()"),WelcomeCancel)
>
>
> sourceTypeSelect=SourceTypeSelect()
>  
> sourceTypeSelect.ui.sourceTypeSelectNext.connect(sourceTypeSelect.ui.sourceTypeSelectNext,QtCore.SIGNAL("clicked()"),SourceTypeSelectNext)
>  
> sourceTypeSelect.ui.sourceTypeSelectCancel.connect(sourceTypeSelect.ui.sourceTypeSelectCancel,QtCore.SIGNAL("clicked()"),SourceTypeSelectCancel)
>
>
> sourceTypeConfirmation=SourceTypeConfirmation()
>  
> sourceTypeConfirmation.ui.sourceTypeConfirmationBack.connect(sourceTypeConfirmation.ui.sourceTypeConfirmationBack,QtCore.SIGNAL("clicked()"),SourceTypeConfirmationBack)
>
>
> welcome.show()
> sys.exit(app.exec_())
>
>
>
>
>   

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

Re: Which objects are expanded by double-star ** operator?

2010-06-07 Thread Ian Kelly

On Mon, Jun 7, 2010 at 2:17 PM, kkumer
 wrote:
>
> I have to merge two dictionaries into one, and in
> a "shallow" way: changing items should be possible
> by operating either on two parents or on a
> new dictionary. I am open to suggestions how
> to do this (values are always numbers, BTW), but
> I tried to do it by creating a dict-like class that just
> forwards all calls to the two parent dicts, see below.
>
> It works, but one important thing is missing. I
> am not able to expand new dictionary with
> double-star operator ** to use it as a
> set of keyword arguments of a function.
> I googled a bit, but was unable to find what
> property must an object have to be correctly
> treated by **.

I don't think that what you want to do here is possible.  It appears
to be hard-coded and not affected by subclassing, as evidenced by the
following snippet:

class NonDict(dict):
for attr in dict.__dict__:
if attr not in ('__init__', '__new__',):
locals()[attr] = None

d = NonDict({'a': 1})
def kwa(**kw): print kw
kwa(**d)

Prints:
{'a': 1}

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

Re: vector addition

2010-06-07 Thread Dan Stromberg

On Mon, Jun 7, 2010 at 1:16 PM, Thomas Jollans  wrote:

>  On 06/07/2010 07:45 PM, Dan Stromberg wrote:
>
>
> Call me strange, but I regard this as a good place to use a functional
> style - IE, to use reduce, and furthermore I regard this as a good example
> of why reduce is useful for more than just summing numbers:
>
> #!/disc/gx/sdfw/dans/python26/bin/python
>
> this line is shouting to be replaced with
> #!/usr/bin/env python
> ;-)
>
> I used to do that a lot, but:
1) I often have more than one version of python around.
2) It makes "ps -ef" a bit less descriptive - the command shows up as
"python" rather than the name of the script, at least in some scenarios.

So believe it or not, I've been changing -from- #!/usr/bin/env python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python + vim + spaces vs tab

2010-06-07 Thread Hans Mulder


Jean-Michel Pichavant wrote:

Hello,

Does anyone knows a way to configure vim so it automatically select to 
correct expandtab value depending on the current buffer 'way of doing' ?
I need to edit different files, some are using spaces, others tabs. 
Those belong to different projects, and changing all spaces to tabs is 
not an option for me.


I can't make vim automatically comply with the current buffer coding 
style, anyone knows if it is possible ?


If you can't get vim to automatically recognize the different styles you
have to work with, then you could look into adding a "modeline" to each
file.  Typing ":help modeline" in vim will tell you how they work.

Adding such a line to each and every file may be a bit of work, and you
may have to convince other people working on the project that "explicit
is better than implicit".

-- HansM

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Arndt Roger Schneider


Terry Reedy schrieb:


Ant
I agree that the current tk situation is not completely satisfactory. 
In particular, the IO facilities are inadequate and have not, to my 
knowledge, changed in a decade. Image input formats are limited. There 
is no canvas output as an image. (Output of the canvase display list 
as a dialect of postscript that not everything can read is not a 
substitute for this.)




Hah, You are ill-informed.
tkpath 0.3 contains a surface element, which renders vector graphics 
elements

in an off-screen tk image.

Forget postscript!
Generate SVG from  a tk canvas or --better-- from tkpath.
Jeszra (from me) generates SVG. There is also a SVG export
package available in python/tkinter, search the tkinter wiki.


However...
I think it important that Python come with a minimal IDE that is 
adequate for someone like me doing Python-only development. I thank 
the programmers of IDLE. So merely deleting tk/tkinter is not an 
option. Indeed, having something similar to and at least as good as 
IDLE for any candidate gui replacememt should and I think would be a 
requirement for consideration.



Yes, use emacs or vim, without any GUI.

The problem with the big gui application frameworks are that they are 
too big. The two I have glanced at -- wx... and qt -- have much more 
than gui stuff and duplicate parts of the Python stdlib and other 3rd 
party libs.



The question is:
What sort of devices are being used by
*normal* computer owners in the near future?

My guess: It wont be a Desktop Computer.

Will any big GUI-Framework work on those devises?

No!

Will a light-weight GUI-toolkit being ported to these
devices ?

Perhaps, but not likely.

Will any scripting language run on such devices?

Perhaps, but not likely, if then it will be
Ecmascript or a 4GL.

Will SVG run on thoses devices?

Yes, it must, because SVG is an integral part
of OEBPS, and the tiny implementation is already
part most mobile phones. Take a look at SVG for
BlackBerry for instance.



As for a small gui written in Python, you seem to have ignored the 
link to pygui. Of course that has its own problems. Among others: it 
is incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 
2.6), which is the only place it could be added; the api sytle is not 
standard in Python (get_xx and set_xx methods instead of direct access 
or properties); and there is nothing yet like IDLE.
What would be required is a Python3 GUI project with multiple 
contributors.


Terry Jan Reedy


What sort of GUI project?


On the initial proposition:
Grapical design is art and art requires an artist.
A community cannot work like an artist. The best a
community of top-class *graphical designers*  could produce
would be of mediocre quality.

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

Re: python2.5 x python2.6 in interactive mode

On 06/07/2010 01:43 PM, Alan wrote:
> Hi there,
>
> I have a code with a 'exit()' at the end. We run it usually as:
>
> python2.5 -i code.py
>
> and if everything is fine, the 'exit()' is called and there's no
> interactive terminal.
You could instead do something like this:

try:
# ...
except:
import code
code.interact()

you could even create a stub.py module, like this:

import runpy
import code
import sys
try:
mod_name = sys.argv[1]
mod_globals = {}
sys.argv = sys.argv[1:]
mod_globals = runpy.run_module(mod_name, run_name='__main__',
alter_sys=True)
except BaseException, e:
mod_globals['e'] = e
code.interact(mod_globals)

and run it with python2.6 stub.py code_module
though it's probably more useful to just use pdb.pm() instead of
code.interact here... the debugger is your friend!
>
> However, doing the same above with python2.6 and I got:
>
> amadeus[2738]:~/TMP% python2.6 -i thread_ping.py
> Traceback (most recent call last):
>   File "thread_ping.py", line 42, in 
> exit()
>   File "/sw/lib/python2.6/site.py", line 334, in __call__
> raise SystemExit(code)
> SystemExit: None
> >>>
>
> So, everything is fine except that it ended up in the interactive
> python terminal. Is there a way of having the very behaviour I have
> with python 2.5 for my code in python 2.6?
>
> Many thanks in advance,
>
> Alan
>
> -- 
> Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
> Department of Biochemistry, University of Cambridge.
> 80 Tennis Court Road, Cambridge CB2 1GA, UK.
> >>http://www.bio.cam.ac.uk/~awd28 <<

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Michael Torrie

On 06/06/2010 02:13 AM, Gabriele Lanaro wrote:
> I'd really like to s/tkinter/WxWidgets/g, the multiplatformness is (almost)
> the same but wx looks infinitely better. IMHO a good intention is to best
> the API of wx.

Does WX still do weird things like use event message maps instead of a
sane signals and slots mechanism?  Last I used it, the API wasn't very
pythonic either (PyQt isn't really pythonic either; PyGTK seems to be
much better).

WX may look better than Tkinter on the screen, but it still has problems
fitting in everywhere.  Certainly wx apps on OS X are pretty bad, though
that's mostly a developer issue.  Qt makes it a bit easier to fit in by
providing a nice API to change button orders and integrate with native
dialog boxes.

At least with Tkinter, it doesn't quite fit in anywhere so a user is
alerted to the fact that it probably won't behave as other Windows apps
do.  Then again, the Windows world is so full of inconsistent UIs and
custom widget sets that it probably doesn't matter either way.  On OS X,
though it will matter greatly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which objects are expanded by double-star ** operator?

2010-06-07 Thread Dave Angel


kkumer wrote:

I have to merge two dictionaries into one, and in
a "shallow" way: changing items should be possible
by operating either on two parents or on a
new dictionary. I am open to suggestions how
to do this (values are always numbers, BTW), but
I tried to do it by creating a dict-like class that just
forwards all calls to the two parent dicts, see below.

It works, but one important thing is missing. I
am not able to expand new dictionary with 
double-star operator ** to use it as a
set of keyword arguments of a function. 
I googled a bit, but was unable to find what

property must an object have to be correctly
treated by **.

I hope the following code is self-explanatory:



import itertools

class hubDict(dict):
"""Merges two dictionaries, but not actually but just by forwarding."""

def __init__(self, da, db):
self.d1 = da
self.d2 = db

def __getitem__(self, name):
if self.d1.has_key(name):
return self.d1[name]
else:
return self.d2[name]

def __setitem__(self, name, value):
if self.d1.has_key(name):
self.d1[name] = value
else:
self.d2[name] = value

def __iter__(self):
return itertools.chain(self.d1.__iter__(), self.d2.__iter__())

def has_key(self, name):
if self.d1.has_key(name) or self.d2.has_key(name):
return True
else:
return False

def keys(self):
return self.d1.keys() + self.d2.keys()

def items(self):
return self.d1.items() + self.d2.items()

def iteritems(self):
return itertools.chain(self.d1.iteritems(), self.d2.iteritems())

def iterkeys(self):
return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())

def itervalues(self):
return itertools.chain(self.d1.itervalues(), self.d2.itervalues())

def copy(self):
print "Can't copy hubDict yet!!!"

def update(self, d):
for key in d:
self.__setitem__(key, d[key])

def popitem(self):
try:
return self.d1.popitem()
except KeyError:
return self.d2.popitem()

def __repr__(self):
return 'First: %s\nSecond: %s' % (
self.d1.__repr__(), self.d2.__repr__())


# Trying it now:

da = {'a':1}
db = {'b':2}
dh = hubDict(da, db)
def kwa(**kwargs): print kwargs

#OK
kwa(**da)

#not OK: prints empty dict
kwa(**dh)


import itertools

class hubDict(dict):
"""Merges two dictionaries, but not actually but just by forwarding."""

def __init__(self, da, db):
self.d1 = da
self.d2 = db

def __getitem__(self, name):
if self.d1.has_key(name):
return self.d1[name]
else:
return self.d2[name]

def __setitem__(self, name, value):
if self.d1.has_key(name):
self.d1[name] = value
else:
self.d2[name] = value

def __iter__(self):
return itertools.chain(self.d1.__iter__(), self.d2.__iter__())

def has_key(self, name):
if self.d1.has_key(name) or self.d2.has_key(name):
return True
else:
return False

def keys(self):
return self.d1.keys() + self.d2.keys()

def items(self):
return self.d1.items() + self.d2.items()

def iteritems(self):
return itertools.chain(self.d1.iteritems(), self.d2.iteritems())

def iterkeys(self):
return itertools.chain(self.d1.iterkeys(), self.d2.iterkeys())

def itervalues(self):
return itertools.chain(self.d1.itervalues(), self.d2.itervalues())

def copy(self):
print "Can't copy hubDict yet!!!"

def update(self, d):
for key in d:
self.__setitem__(key, d[key])

def popitem(self):
try:
return self.d1.popitem()
except KeyError:
return self.d2.popitem()

def __repr__(self):
return 'First: %s\nSecond: %s' % (
self.d1.__repr__(), self.d2.__repr__())

def __len__(self):
return self.d1.__len__() + self.d2.__len__()

# Trying it now:

da = {'a':1}
db = {'b':2}
dh = hubDict(da, db)
def kwa(**kwargs): print kwargs

#OK
kwa(**da)

#not OK: prints empty dict
kwa(**dh)


  

From the help on "Container types",

>>The UserDict <../library/userdict.html#module-UserDict> module 
provides a DictMixin class to help create those methods from a base set 
of __getitem__() <#object.__getitem__>, __setitem__() 
<#object.__setitem__>, __delitem__() <#object.__delitem__>, and keys().

<<

and
>>It is recommended that both mappings and sequences implement the 
__contains__() <#object.__contains__> method to allow efficient use of 
the in operator; for mappings, in should be equivalent of has_key(); for 
sequences, it should search through the values. It is further 
recommended that both mappings and sequences implement the __iter__() 
<#object.__iter__> method to allow e

Re: Which objects are expanded by double-star ** operator?


The answer depends on the version:
in 2.5 "If the syntax "**expression" appears in the function call, 
"expression" must evaluate to a (subclass of) dictionary, "
in 3.1 "If the syntax **expression  appears in the function call, 
expression must evaluate to a mapping,"


ReferenceManual.Epressions.Primaries.Calls

Terry Jan Reedy

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

Re: Which objects are expanded by double-star ** operator?

kkumer wrote:

> 
> I have to merge two dictionaries into one, and in
> a "shallow" way: changing items should be possible
> by operating either on two parents or on a
> new dictionary. I am open to suggestions how
> to do this (values are always numbers, BTW), but
> I tried to do it by creating a dict-like class that just
> forwards all calls to the two parent dicts, see below.
> 
> It works, but one important thing is missing. I
> am not able to expand new dictionary with
> double-star operator ** to use it as a
> set of keyword arguments of a function.
> I googled a bit, but was unable to find what
> property must an object have to be correctly
> treated by **.

The following experiment shows that you only need to implement a keys() and 
__getitem__() method.

$ cat kw.py
class A(object):
def keys(self): return list("ab")
def __getitem__(self, key):
return 42

def f(**kw):
print(kw)

f(**A())
$ python kw.py
{'a': 42, 'b': 42}

However, if you have A inherit from dict...

$ cat kwd.py
class A(dict):
def keys(self): return list("ab")
def __getitem__(self, key):
return 42

def f(**kw):
print(kw)

f(**A())
$ python kwd.py
{}

it stops working -- probably a side-effect of some optimization.
So if you change your hubDict's base class from dict to object you should 
get the desired behaviour.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Michael Torrie

On 06/06/2010 04:55 PM, ant wrote:
> What an interesting set of responses I got!
> And - even more interesting - how few of them actually seem to think
> there is a problem, let
> alone make any attempt to move the situation forward.

You simply haven't made a case that there is a problem to be solved.
Why should a language be integrated with and married to a GUI toolkit
anyway?  Python was born in the Unix world, and the Unix philosophy of
using the tools that make sense in a modular and pipelined way is very
applicable to GUI development.

There is a case to be made for a widely portable, lowest-common
denominator UI toolkit, but that will always only fulfill limited needs
and always will be subjected to the limitations that have been specified
by several posters.

Thus for Python to really be successful in a broader sense, we need
good, solid, bindings for Cocoa, or Windows forms (whatever they are
using these days), as well as the most popular windows toolkits.  We
don't need another Swing.  As someone else mentioned, web-based
interfaces are increasingly important.  That means you have to write
your apps in a modular way that separates the GUI from the business
logic.  That way you can develop a nice GUI app and then, when there is
demand, give it a web front end.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Plotting in batch with no display


On 07/06/2010 08:41, Hans Georg Schaathun wrote:

On Sat, 5 Jun 2010 16:10:01 + (UTC), Tim Harig
 wrote:
:  On 2010-06-05, Hans Georg Schaathun  wrote:
:>  Raster graphics is not good enough, I will need a backend which
:>  does vector graphics and pdf output.  AFAICS from the FAQ at
:>  sourceforge, agg only supports raster and png.  Cairo supports
:>  vector graphics and PDF, but I cannot find any information about
:>  how/if it deals with X11...
:
:  1. I am not familiar with matlab;

Good that my question did not concern matlab then :-)

:but, I have written python programs that
:   generate plots using GNUplot (which can create PDFs).  There are
:   python modules available for working with GNUplot or you can open
:   it yourself under a subprocess and send it commands through a pipe.
:   GNUplot allows you to save files directly and does not therefore
:   require X.

That certainly is an option.  I actually do have an example using
gnuplot, taken from the libsvm tools which I wanted to replace with
a native python solution :-)  After some testing, I have concluded
though, that that's not necessary.  OTOH, gnuplot is not quite as
easy to learn as the pyplot API.


I entirely agree with this comment.



:  2. If you can generate a raster file with Matlab, you can use ImageMagick
:   (which has python bindings or could be execed directly) or other
:   conversion software to convert the file to whatever format you
:   choose.

Sorry, that's no help.  Firstly, when I started using python it was to
avoid using matlab...  Secondly, raster graphics gives poor quality when
it is scaled.  Raster graphics represented in PDF or EPS is no better
than raster graphics in PNG.  I need scalable vector graphics.

:  3. Depending on your requirements, you could generate a plot using
:   postscript.  Postscript is  easy to convert directly to PDF as
:   the two are closely related. As postscript is a powerful
:   language itself you can actually write the graphing routines in
:   postscript and use python to simply embed the data into the
:   postscript.

Sure, but the problem is to find the right matplotlib engine to do
that.  We live in 2010 and Python is a new and evolving language.
It would be strange if the PS renderer is more advanced than the
PDF renderer, but if it is, I'll use it.

Ideally, I'd like the option to switch between X11 and file output
runtime, which the engine switch (matplotlib.use()) does not support.
Question is, is there an engine to do that?

:-- George


For more specific data have you tried the matplotlib specific mailing 
list at e.g. gmane.comp.python.matplotlib.general.


Apologies if this has been suggested in this thread and I've missed it.

Kindest regards.

Mark Lawrence.

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

Re: Which objects are expanded by double-star ** operator?

2010-06-07 Thread Ian Kelly

On Mon, Jun 7, 2010 at 4:03 PM, Peter Otten <__pete...@web.de> wrote:
> The following experiment shows that you only need to implement a keys() and
> __getitem__() method.
>
> $ cat kw.py
> class A(object):
>    def keys(self): return list("ab")
>    def __getitem__(self, key):
>        return 42
>
> def f(**kw):
>    print(kw)
>
> f(**A())
> $ python kw.py
> {'a': 42, 'b': 42}

This seems to require Python 2.6.  With 2.5, you get:

Traceback (most recent call last):
  File "kw.py", line 9, in 
f(**A())
TypeError: f() argument after ** must be a dictionary

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

Python-URL! - weekly Python news and links (Jun 6)

2010-06-07 Thread Cameron Laird

QOTW:  "... it's just laziness and hubris passed off under the banner
of
agility." - Clifford Heath, on the fashion of justification of
"metaschemas"
because those darn data architects are just too slow


   Efficient way to apply a function to every element in a list,
discarding
   the results:
   http://comments.gmane.org/gmane.comp.python.general/663445/

   Counting occurrences of every item in a list:
   http://groups.google.com/group/comp.lang.python/t/317d9828b0d4c1c6

   The meaning of '\b' in regular expressions may be confusing:
   http://groups.google.com/group/comp.lang.python/t/baa73e8838858aa3

   A better algorithm for random sampling:
   http://groups.google.com/group/comp.lang.python/t/28cdc0af76be03f7

   PyUseCase helps make GUI testing maintainable:
   http://www.texttest.org/index.php?page=ui_testing

   How to pass additional arguments to __getattr__:
   http://groups.google.com/group/comp.lang.python/t/ddc79f3b0621b73d

   Properties and inheritance - looking for the simplest way to make
it work:
   http://groups.google.com/group/comp.lang.python/t/753eafbc3a3a1f19

   Inconsistent handling of StopIteration between generator
expressions
   and list, set and dict comprehensions:
   http://groups.google.com/group/comp.lang.python/t/ec5f723657352217

   Metaclass for easier __slots__ handling, and even inheriting them:
   http://groups.google.com/group/comp.lang.python/t/971cc3583988d6e2

   How to distinguish between a built-in class and a user-defined one:
   http://comments.gmane.org/gmane.comp.python.general/663296/

   Reasons not to inherit both from Decimal and float at the same
time:
   http://groups.google.com/group/comp.lang.python/t/65f5a80088c91938

   The New Wave of command line parsers is out:
   http://groups.google.com/group/comp.lang.python/t/92c3bc11302ed1e7

   Handling of sql parameters and escape characters, in two related
   questions:
   http://comments.gmane.org/gmane.comp.python.general/663514
   http://comments.gmane.org/gmane.comp.python.general/663481

   Style: how to properly indent an 'if' statement with a long
condition,
   so the end of it is clearly distinguishable from the statement that
   follows:
   http://groups.google.com/group/comp.lang.python/t/e1aac5553db5ec07

   A simple, but hard to find problem using ctypes and the _fields_
name:
   httpgroups.google.com/group/comp.lang.python/t/b22c9d412a97eb90

   Looking for big Python powered web sites and applications:
   http://groups.google.com/group/comp.lang.python67a3fdc543cf5dfa1c6
   http://groups.google.com/group/comp.lang.python/t/bc80c1bae46aba04

   A new Python web forum announcement - is it good news or bad news?
   http://groups.google.com/group/comp.lang.python/t/17011e77f9bc51c8



Everything Python-related you want is probably one or two clicks away
in
these pages:

   Python.org's Python Language Website is the traditional
   center of Pythonia
   http://www.python.org
   Notice especially the master FAQ
   http://www.python.org/doc/FAQ.html

   PythonWare complements the digest you're reading with the
   marvelous daily python url
http://www.pythonware.com/daily

   Just beginning with Python?  This page is a great place to start:
   http://wiki.python.org/moin/BeginnersGuide/Programmers

   The Python Papers aims to publish "the efforts of Python
enthusiasts":
   http://pythonpapers.org/
   The Python Magazine is a technical monthly devoted to Python:
   http://pythonmagazine.com

   Readers have recommended the "Planet" site:
   http://planet.python.org

   comp.lang.python.announce announces new Python software.  Be
   sure to scan this newsgroup weekly.
   http://groups.google.com/group/comp.lang.python.announce/topics

   Python411 indexes "podcasts ... to help people learn Python ..."
   Updates appear more-than-weekly:
   http://www.awaretek.com/python/index.html

   The Python Package Index catalogues packages.
   http://www.python.org/pypi/

   Much of Python's real work takes place on Special-Interest Group
   mailing lists
   http://www.python.org/sigs/

   Python Success Stories--from air-traffic control to on-line
   match-making--can inspire you or decision-makers to whom you're
   subject with a vision of what the language makes practical.
   http://www.pythonology.com/success

   The Python Software Foundation (PSF) has replaced the Python
   Consortium as an independent nexus of activity.  It has official
   responsibility for Python's development and maintenance.
   http://www.python.org/psf/
   Among the ways you can support PSF is with a donation.
   http://www.python.org/psf/donations/

   The Summary of Python Tracker Issues is an automatically generated
   report summarizing new bugs, closed ones, and patch submissions.
   
http://search.gmane.org/?aut

Re: GUIs - A Modest Proposal

2010-06-07 Thread Grant Edwards

On 2010-06-06, ant  wrote:
> On Jun 6, 2:22?pm, ant  wrote:
>> I get the strong feeling that nobody is really happy with the state of
>> Python GUIs.
>
>
> What an interesting set of responses I got! And - even more
> interesting - how few of them actually seem to think there is a
> problem,

I rarely write programs with GUIs.  When I do, wxPython seems to work
fine.  So you're right: I don't see a problem.

>[...]
>
> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.

How is being a "minor language" a problem?

-- 
Grant Edwards   grant.b.edwardsYow! How do I get HOME?
  at   
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal


On 6/7/2010 5:25 PM, Arndt Roger Schneider wrote:

Terry Reedy schrieb:

...


Hah, You are ill-informed.


How about 'under-informed'? That I readily admit ;-)


tkpath 0.3 contains a surface element, which renders vector graphics
elements in an off-screen tk image.


As far as I know, tkpath is either not part of the tk that comes with 
python, or not accessible via tkinter, or not documented.



Forget postscript!


Gladly!


Generate SVG from a tk canvas or --better-- from tkpath.
Jeszra (from me) generates SVG.


I found http://jeszra.sourceforge.net/
It looks interesting but not quite what I need, which is to export a tk 
canvas that I draw on with Python in a form I can import into OpenOffice.


 There is also a SVG export

package available in python/tkinter, search the tkinter wiki.


I presume you mean there is a 3rd party python add-on package that 
exports from a tk canvas. Can you be more specific as to what you meant?


Googling 'tkinter wiki' got me to http://tkinter.unpythonic.net/wiki/
wiki.python.org/moin/TkInter has a link to the same.
Searching there for 'svg' title or text has no hits.
Searching PyPI also turns up nothing obvious.

Googling further, I found canvasvg.py at
http://wm.ite.pl/proj/canvas2svg/index.html
via an answer to a question at
http://bytes.com/topic/python/answers/629332-saving-output-turtle-graphics
I will give it a try.

Terry Jan Reedy


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

PyCon Australia 2010 registration deadline reminder

2010-06-07 Thread Richard Jones

Hi everyone,

PyCon Australia 2010, to be held at the Sydney Masonic Center over the
weekend of June 26 and 27, is drawing ever closer.

REGISTRATION WILL CLOSE JUNE 22!

We will NOT be accepting registrations at the door.

Register here: http://pycon-au.org/reg

We offer two levels of registration for PyCon Australia 2010:

Full - $198
   This is the registration rate for regular attendees.
   Full registration includes one seat at the conference dinner
   on Saturday night.

Student - $44
   For students able to present a valid student card we're offering
   this reduced rate. Student registrations do not include a seat
   at the conference dinner.

Additional seats at the conference dinner may be purchased for $77
each.

All prices include GST.

Information about the registration process is on the PyCon Australia
website.


Richard Jones
PyCon Australia 2010
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Gregory Ewing


Terry Reedy wrote:
pygui ... has its own problems. ... the api sytle is not standard 
in Python (get_xx and set_xx methods instead of direct access or 
properties);


That was only true in a very early version of PyGUI. Properties
are used very extensively now.

(It uses get_xxx and set_xxx methods to *implement* properties,
but you don't call those from outside, you use normal attribute
access.)

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

Re: GUIs - A Modest Proposal

On Jun 7, 1:29 pm, Terry Reedy  wrote:
> Ant
> I agree that the current tk situation is not completely satisfactory. In
> particular, the IO facilities are inadequate and have not, to my
> knowledge, changed in a decade. Image input formats are limited. There
> is no canvas output as an image. (Output of the canvase display list as
> a dialect of postscript that not everything can read is not a substitute
> for this.)
>
> However...
> I think it important that Python come with a minimal IDE that is
> adequate for someone like me doing Python-only development. I thank the
> programmers of IDLE. So merely deleting tk/tkinter is not an option.
> Indeed, having something similar to and at least as good as IDLE for any
> candidate gui replacememt should and I think would be a requirement for
> consideration.
>
> The problem with the big gui application frameworks are that they are
> too big. The two I have glanced at -- wx... and qt -- have much more
> than gui stuff and duplicate parts of the Python stdlib and other 3rd
> party libs.
>
> As for a small gui written in Python, you seem to have ignored the link
> to pygui. Of course that has its own problems. Among others: it is
> incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6),
> which is the only place it could be added; the api sytle is not standard
> in Python (get_xx and set_xx methods instead of direct access or
> properties); and there is nothing yet like IDLE.
>
> What would be required is a Python3 GUI project with multiple contributors.
>
> Terry Jan Reedy

I STRONGLY agree with Terry here! We need a very lightweight GUI in
the stdlib that is NOT Tkinter but IS roughly the very same basic
widget set, only better!. Yes this is 2010 and any GUI should support
all the major image types out-of-the-box!! But we damn sure don't want
100mb of bloated wx killing download times of Python either!

Improving Tkinter IMO is a lost cause. We need to find a better base
and build from it. Maybe a stripped down version of wx, or something
else...? But we sure don't need an embedded TCL interpretor packaged
with Python either *YUCK*!!!

The problem is getting a large enough group of Python users to agree
on anything about GUIs. I don't think the numbers will ever be big
enough because people are only worried about getting "their preferred"
GUI into Python. But the focus should not be on getting the most
cutting edge GUI into Python --size and maintainability issues forbid
that-- no the focus should be on these qualities...

 - cross platform
 - lightweight
 - simple to use
 - not an antiquity
 - no embedded interpretors

However as i have mentioned before there will NEVER be a crowd of us
marching in the streets behind one GUI. People are just too busy to
get involved. This has to be an executive decision. The powers that be
must make the change themselves or it will never happen -- i can
guarantee that! And if this change is made python will be better off
in the end. You have my vote for change but unless someone with more
influence steps up then our laments will be but in vain.

psst, hey Guido, it's time to make your triumphant comeback to c.l.p.
We are waiting...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 7, 5:05 pm, Michael Torrie  wrote:

> Thus for Python to really be successful in a broader sense, we need
> good, solid, bindings for Cocoa, or Windows forms (whatever they are
> using these days), as well as the most popular windows toolkits.  We
> don't need another Swing.  As someone else mentioned, web-based
> interfaces are increasingly important.  That means you have to write
> your apps in a modular way that separates the GUI from the business
> logic.  That way you can develop a nice GUI app and then, when there is
> demand, give it a web front end.

Micheal makes a good point about the future web based interfaces. The
momentum is building fast for this type of thing and GUI may be
obsolete very soon. What options do we have in this arena? If were
going to move forward we should at least move in the right direction.
Seems that web based would help to satisfy the size requirement at
least. Pythoninic API, hmm, ain't seen one yet? Anybody have
suggestions...?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Michael Torrie

On 06/07/2010 09:19 PM, rantingrick wrote:
> On Jun 7, 5:05 pm, Michael Torrie  wrote:
> 
>> Thus for Python to really be successful in a broader sense, we need
>> good, solid, bindings for Cocoa, or Windows forms (whatever they are
>> using these days), as well as the most popular windows toolkits.  We
>> don't need another Swing.  As someone else mentioned, web-based
>> interfaces are increasingly important.  That means you have to write
>> your apps in a modular way that separates the GUI from the business
>> logic.  That way you can develop a nice GUI app and then, when there is
>> demand, give it a web front end.
> 
> Micheal makes a good point about the future web based interfaces. The
> momentum is building fast for this type of thing and GUI may be
> obsolete very soon. What options do we have in this arena? If were
> going to move forward we should at least move in the right direction.
> Seems that web based would help to satisfy the size requirement at
> least. Pythoninic API, hmm, ain't seen one yet? Anybody have
> suggestions...?

What I do is to make the bulk of my code in modules that I can import
into a web-based front end (say in Django), or in a GTK-based front-end
or what have you.  In other words everything is abstracted as best I can
to be independent of the GUI.  If I was writing a file manager, for
example, I'd abstract all the operations that read and wrote
directories, performed file ops, etc, so that the frontend code just
simply calls my high-level functions and methods.  Then it becomes much
easier to build a PyGTK front end, or PyQt frontend.  There's obviously
a certain amount of work that goes into the frontend, but not quite as
much as if I'd glommed everything together.

Another tactic we're trying at my work is to build web apps in Django
and then ensure that all of our apps export business logic over XMLRPC,
so we can write non-web frontends to our apps, or even scripts.  I think
RPC-like mechanisms are the key to an agile app, at least if the app is
a network-oriented app to begin with.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Stephen Hansen

>
> However as i have mentioned before there will NEVER be a crowd of us
> marching in the streets behind one GUI. People are just too busy to
> get involved. This has to be an executive decision. The powers that be
> must make the change themselves or it will never happen -- i can
> guarantee that! And if this change is made python will be better off
> in the end. You have my vote for change but unless someone with more
> influence steps up then our laments will be but in vain.
>
> psst, hey Guido, it's time to make your triumphant comeback to c.l.p.
> We are waiting...
>

Um.

And even if the Powers that Be made an executive decision-- how would that
impact anything? Hint: it wouldn't.

Guido does not have some magical ability to point, declare, and suddenly
there's time and effort expended to achieve an event. He doesn't have a
budget. He doesn't have a pool of Work Units that he can assign to a certain
task and then Minions who will go and fulfill it.

He really doesn't. If you think any of his "decisions" can result in work
being done, you're sort of entirely missing how Python has always been
developed. People donate their motivation, time and effort, to tasks. Stuff
gets done, and included in Python, when people on their own decide to
champion a feature, task, or function, if they find the feature interesting,
useful, and worth their time and effort. They do the work first. Then, Guido
lets it in or not. Usually, to avoid a lot of wasted work, they hash out a
PEP first. Then they can get it approved and then do the big effort of
implementing it (although they usually have to be motivated enough to do a
reference implementation anyways-- because a PEP for a code-change without
any code, has very little to no chance of being entered into Python unless
someone else stands up during the process and -- entirely on their own
motivation -- decides to do work).

Sure, for certain limited sorts of decisions, he can say 'We should do X!',
and there's some people who will see that X is done, if they thought it was
a good idea, were bored(from the tone of python-dev, I doubt many of them
are ever very bored. Extremely lacking in time is the more common theme), or
it wasn't to terribly involved. But usually only in terms of a larger
project or area of concern that they either consider important to
themselves, or interesting, or that they have claimed.

Python's "core team", -- isn't directed by Guido. They don't work on what
Guido tells them to work on. They're a bunch of volunteers who do things
they want to, under the nominal approval of the BDFL, but generally with the
mutual-supervision and cooperation of the other volunteers.

The only work Guido can make happen in Python is his own time Google gives
him to work on Python: and he's flat out said in the past that he hasn't
ever had any need to build a GUI app, and has no real desire to. He doesn't
know the first thing about GUI programming.

So... what's all this mean?

There are no Powers that Be.

There is a pool of exactly zero to very very small "core" development
team(using the word 'core' very vaguely, meaning primarily, 'people who do
stuff sometimes on python-dev') of Python who are knowledgeable of the state
of the art and/or interested enough in the very idea of a brand new cross
platform Pythonic GUI.

I know one of at least is interested enough to put his money where his mouth
is and has worked on implementing something as such -- PyGUI. I think,
personally, that its about the only hope you have of ever getting a
Tkinter-replacement in. No one else seems willing to do the work. Until
someone does, its just dead on arrival. The entire idea.

Unless you want to add your chips to the pile, and *do* the work, its just a
pointless conversation. Because it won't happen. Python's not a company. It
doesn't have resources that Guido can direct to tasks and see that said
tasks get done. Its volunteers, doing what they care about, under the very
vague moderation of a Benevolent Dictator.

Me? I'm entirely happy with wxPython. I need to do rich, complex
cross-platform app's which look and behave natively. For that, I need
something on the caliber and completeness of wx and qt. Any 'simple'
pythonic UI just won't cut it.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread alex23

rantingrick  wrote:
> The problem is getting a large enough group of Python users to agree
> on anything about GUIs.

No, the problem is it's a lot easier to find fault than it is to
provide a solution. And that maybe, just maybe, other people don't
want to have to do your dirty work for you.

> I don't think the numbers will ever be big
> enough because people are only worried about getting "their preferred"
> GUI into Python.

And in what way is that different from _your_ preference for not-
Tkinter?

> People are just too busy to
> get involved. This has to be an executive decision. The powers that be
> must make the change themselves or it will never happen -- i can
> guarantee that!

No. That is _not_ how open source works. This has to be _your_
decision to _do something_. It's your itch, no one else is under any
obligation to scratch it. If it's so obvious to you what is wrong
here, it should be very clear to you how to fix it. Of course, someone
who wasn't labouring under the Dunning-Kruger effect might think that
perhaps the very fact that there are so many GUI libs out there might
indicate that this isn't a readily solved problem space...

Alternatively: how much is this change worth to you? How much are you
willing to pay to see it happen?

> psst, hey Guido, it's time to make your triumphant comeback to c.l.p.
> We are waiting...

You know, you _could_ drop the incessant cult of personality obsession
and rely on yourself to resolve the problems you see

What gets me is the implicit attitude in some of these posts that it's
just so _obvious_ that something needs to be done and it's simply that
_everyone else_ is either stupid, lazy or biased towards actually
existing code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 7, 11:51 pm, alex23  wrote:



Of course i was just being theatrical alex, i hope your last post was
in the same manner. However your right about everything you said
except your accusations that i am not willing to help bring this into
reality -- i just need to find the right base... and i may have just
found it in PyGUI!!

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

My first impression of PyGUI is very good because it looks promising,
and of course has a native look and feel. Just grazing over the docs i
was very impressed. Greg has outlined some simple and clear goals
which are exactly what Python needs in a GUI. He has the vision and
quite a bit a code already written. Heck he even has an OpenGL hashed
already. From what i can see so far the API very Pythonic. I think
it's love at first sight really. I encourage others to take a look at
PyGUI and see what they think. Judge for yourself.

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

Re: if, continuation and indentation

2010-06-07 Thread Greg Couch

On May 27, 5:22 am, HH  wrote:
> I have a question about best practices when it comes to line wrapping/
> continuation and indentation, specifically in the case of an if
> statement.
>
> When I write an if statement with many conditions, I prefer to use a
> parenthesis around the whole block and get the implicit continuation,
> rather than ending each line with an escape character.  Thus, using
> the example from the style guide (http://www.python.org/dev/peps/
> pep-0008/) I would write:
>
>     if (width == 0 and
>         height == 0 and
>         color == 'red' and
>         emphasis == 'strong' or
>         highlight > 100):
>         raise ValueError("sorry, you lose")
>
> The problem should be obvious -- it's not easy to see where the
> conditional ends and the statement begins since they have the same
> indentation.  Part of the problem, I suppose, is that Emacs indents
> 'height' and the other lines in the conditional to 4 spaces (because
> of the parenthesis).  How do people deal with this situation?
>
> Thanks,
> Henrik

To show another alternative, I like:

 if (width == 0
 and height == 0
 and color == 'red'
 and emphasis == 'strong'
 or highlight > 100):
 raise ValueError("sorry, you lose")

This works because and/or can not start an expression, so it is
obvious
that they continue the expression from the previous line.  If I run
out
of room to put a full and/or clause on one line, then I'll indent the
subclause two levels.

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

Re: GUIs - A Modest Proposal

2010-06-07 Thread Ben Finney

alex23  writes:

> What gets me is the implicit attitude in some of these posts that it's
> just so _obvious_ that something needs to be done and it's simply that
> _everyone else_ is either stupid, lazy or biased towards actually
> existing code.

When deciding what code is valuable and what's not, I proudly declare a
bias toward actually existing code.

-- 
 \  “Contentment is a pearl of great price, and whosoever procures |
  `\it at the expense of ten thousand desires makes a wise and |
_o__)  happy purchase.” —J. Balguy |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Non Sequitur: Re: Python Forum

On Jun 7, 12:41 am, Steven D'Aprano  wrote:

> "Fish" can be either singular (as in "I fed the fish") or a collective
> noun ("there are many fish that live in salt water"). Plural is "fishes",
> as in "I ate three fishes", although in common use people tend to use
> fish/fishes as both plural and collective nouns.
>
> --
> Steven

Do you use the word "fishes". I don't think i've ever heard anyone use
that word -- well except for children before being corrected. I ate
three fishes just sounds wrong to me. What's the plural of sheep
Stephen :-D

@ Ben
Ok Ben you convinced me, after absorbing your arguments i do now
believe that Usenet is better.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-07 Thread Stephen Hansen

On Mon, Jun 7, 2010 at 10:34 PM, Rick Johnson  wrote:

> Hi Stephen,
>
> Great to hear from you. You're right about the powers that be, and i agree!
> I was just being a bit theatrical (i've been known to do that from time to
> time...Sorry.  ;-).
>
> I know one of at least is interested enough to put his money where his
>> mouth is and has worked on implementing something as such -- PyGUI. I think,
>> personally, that its about the only hope you have of ever getting a
>> Tkinter-replacement in. No one else seems willing to do the work. Until
>> someone does, its just dead on arrival. The entire idea.
>>
>
> Yes, i just downloaded PyGUI and it looks very promising! Greg has a great
> vision for his GUI and his very pythonic API is what we need in a GUI!
>
> I know Wx is full featured but for the stdlib we really need a meat and
> bones GUI for getting newbies up and running and also for the usability of
> Python out-of-the-box. Tkinter has had many years to improve but nobody
> wants to improve it and i think wrapping a Tcl interpretor was OK in
> Python2.x but we need to bring Python's stdlib GUI into the future.
>
> Greg has the vision, the clear set goals, and pretty nice starting code
> base. And lets not forget he IS actually "somebody" in this community who
> has influence -- unlike me ;). I think if we can get behind his effort this
> may turn out to be a good change for Python...?. I am willing to write some
> code. And i would be quite excited to be a contributor on this project.
>
> What do you think Stephen?
>

The problem is purely motivation.

There are only 24 hours in a day; from 9 to 5, my boss owns my time.
Sometimes that actually does mean I contribute to open source projects. Not
often, but sometimes. More often, it means I participate in communities,
giving back in ways I can afford-- answering questions, and such. But
generally speaking, those 8 hours don't belong to me.

Then there's the rest of the time.

It's divided between social commitments, and certain projects which I have a
long establishment with and commitments I want to uphold. Then there's the
downtime goofing off I need to maintain mental health.

In pure theory, do I think Python would benefit slightly from a "simple" GUI
available in the stdlib and out of the box, able to do many of the basics
people need? Sure. Do I find tkinter ugly and unpythonic and that such a
truly pythonic simple GUI would be nice? Sure.

However, there are some caveats.

I maintain its impossible to do "pythonic" and "really good UI".

There's a *reason* wx, qt, and such, are complicated. Real, modern,
intuitive, immersive, superbly clean, excellently functional user interfaces
that apps do -- require a complex model that does not sift down well into
'idle, easy python code'. That's not to say all programs with wx/qt are of
that caliber-- not at all. However! They provide the power you need to be
truly great UI's.

A simple UI layer, can only be ... simple. Useful, yes. However, simplicity
stands in direct opposition to comprehensive capability. Its impossible to
find a middle ground between the two: wx and qt *are* an example of an
attempt to find such a  middle ground.

My problem with a "simple GUI" in the stdlib is therefore twofold. One: I'd
never use it. I acknowledge new users would be helped in initial adoption,
but I'd never use it. Even for smaller projects. I now know wx, so, I can do
wx very fast. I can adapt and adjust it to function. And I know how to bend
it to my will if I want to do something which goes beyond its simplicity
imposes.  Two: I can't shake the feeling that it will ultimately weaken
these very newbies you're trying to help. They'll make an app, with this
simple UI, and everything will seem nice.

And their app will mature. And one day, its simply no longer supportable on
that platform, and they have to rewrite it. Rewriting is the death of
projects. I firmly believe there is *no* way to make a Pythonic, simple,
accessible UI system which is *comprehensive*, complete, fully-functional
and fully-accessible. I welcome someone smarter then I to prove me wrong.

Both wx and qt have some things to make it a lot easier to deal with. QT is
more mature in that, with its QT Designer. WX has several tools for
generating XRC UI's, so people can lay out a user interface in WX without
writing code. But its still more difficult. Still, though: although I fully
admit these platforms are more difficult and complicated, and although a
very simple thing may be wonderful for them... I wonder if we're helping
them, instead of helping them learn platforms which will /really/ open them
up to fully developing rich, modern applications.

Either way: I sympathize with the theory of creating such a simple-GUI for
stdlib inclusion. I applaud those who will do so, albeit with some
reservation. I have no motivation at all to contribute, because I feel no
personal need, and no time for charity work in this capacity. I don't have
enough time for

Re: Which objects are expanded by double-star ** operator?