Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Rick Johnson]

On Jun 11, 9:09 am, Mark Roseman  wrote:

> Second, there does exist at least one fairly good source of
> documentation for new users wishing to do exactly this (according to
> many, many comments I have received), though that documentation is
> admittedly buried in a sea of out-of-date information that is still all
> too easy to find.

Well you Mark you have really hit it this time.

 * Outdated tuts are contributing to the slow adoption of Python3000
 * Outdated tuts are contributing the animosity towards Tkinter.
 * Poorly written tuts are doing even more damage.

I have pointed this out before with very little feedback from our
community members. So you know what i did... about two years ago i
start a quest to rid the WWW of old and outdated tutorials. I send out
email after email; begging; pleading, and yes even brown-nosing!...
and you know how many reposes i got? Three! Yes three! And one of the
three told me to eef-off.

The other two chaps not only updated their tutorials, they even sent
me a nice Thank you letter. Oh. And the one who told me to eff-off, he
re-read my email and decided he took it out of context and then he
updated his tut also.

You see. If "I", or me rather, the despised and hated "rantingrick"
can inspire three people to contribute positively to this community,
well, just imagine what you or *gasps* GvR could do! Is any heavy
weight willing to step forward and be heard? What say you? The silence
is deafening.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Rick Johnson]

On Jun 10, 11:05 pm, rusi  wrote:

> If python is really a "language maven's" language then it does not do
> very well:
> - its not as object-oriented as Ruby (or other arcana like Eiffel)
if it were object-oreiented as Ruby, then why not use Ruby?

> - its not as functional as Haskell
if it were as functional as Haskell, then why not use Haskell?

> - its not as integrable as Lua
if it were as integrable as Lua, then why not use Lua?

> - its not as close-to-bare-metal as C
if it were as asinine as C, then why not use C?

> - etc
exactly!

> Then why is it up-there among our most popular languages? Because of
> the 'batteries included.'

No. It's up there because it does not FORCE you to program in a single
paradigm. Look. I love OOP. It works well for so many problems -- but
not for ALL problems! I like the freedom i have when using Python. I
don't get that feeling anywhere else.

> And not having a good gui-builder is a battery (cell?) that is
> lacking.

Nonsense. I'm not saying we should NEVER have a visual gui builder,
no,  but i am saying that we don't need one to be a great language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Dietmar Schwertberger]

Am 11.06.2012 01:15, schrieb Chris Angelico:

If you're a complete non-programmer, then of course that's an opaque
block of text. But to a programmer, it ought to be fairly readable -

Well, I can read the code.
But still I would not be able (or interested) to write C++/GTK code.
With my rusty C++ knowledge and a simple GUI builder, I might be able
to create the GUI, though.
Whether I could then connect the events to actions is a different
question and depends on the GUI builder. If it does not support this,
then I would just not write the software.

That's the starting point of this thread: for Python we could not
identify such a GUI editor.



it says what it does. I'm confident that anyone who's built a GUI
should be able to figure out what that's going to create, even if
you've never used GTK before. (And yes, it's not Python. Sorry. I
don't have a Python example handy.)

All the discussion about casual users being able to implement GUIs by
manually coding it is somehow based on the assumption that suitable
examples for any purpose are available.
So to me the above example seems to be the proof that suitable examples
are not available easily.



Modern UI toolkits are generally not that difficult to use. Add just a
few convenience functions (you'll see a call to a "button" function in
the above code - it creates a GTK2.Button, sets it up, and returns
it), and make a nice, well-commented configuration file that just
happens to be executed as Python, and you've made it pretty possible
for a non-programmer to knock together a GUI. They'll have learned to
write code without, perhaps, even realizing it.

Right, they are not too difficult to use for full-time programmers
or for people who want to invest a lot of time (as hobbyist).
But there are many people who just need to get things done and who
don't want to invest too many time on a simple GUI.

No matter how cool it may seem to create simple GUIs manually or to
write business letters using LaTeX: just try to persuade people to move
from Word to LaTeX for business letters...


Regards,

Dietmar

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Dietmar Schwertberger]

Am 11.06.2012 16:09, schrieb Mark Roseman:
> On the Tkinter front, I just want to reiterate two important points that
> are not nearly as well known as they should be.
>
> First, it is possible and in fact easy to do decent looking GUI's in
> Tkinter, with the caveat that you do in fact have to do things very
> slightly differently than you would have 15 years ago. Shocking, I know.
Yes, but when I have the choice between Tkinter, Qt and wx, I still
would go for wx or Qt (or stick to wx which I chose 12 years ago).
I don't see the point of chosing Tkinter over the other toolkits.


> Second, there does exist at least one fairly good source of
> documentation for new users wishing to do exactly this (according to
> many, many comments I have received), though that documentation is
> admittedly buried in a sea of out-of-date information that is still all
> too easy to find.
>
> Please see http://www.tkdocs.com and in particular the tutorial there.
The point of this thread is that Python is not attractive to casual
users who want to implement some GUI programs.
I don't see how that would change without an easy-to-use GUI builder,
no matter how good the documentation is.
Of course, it's possible to split up the documentation into many small
building blocks which the user could copy & paste together.
But then we have a poor-man's GUI builder. I doubt that it would
attract new users.

(For more straightforward tasks like hardware control / data
 acquisition I made good experiences with a Wiki-based approach
 of providing snippets. But *simple* GUIs are mainly visual and
 there should be a way to create them visually without consulting
 much documentation.)

Regards,

Dietmar


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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Dietmar Schwertberger]

Am 11.06.2012 16:14, schrieb Anssi Saari:

Wolfgang Keller  writes:


This whole cycle of "design GUI"->"generate code"->add own code to
generated code"->"run application with GUI" has always seemed very
un-pythonic to me. A dynamic, interpreted language should allow to work
in a more "lively", "direct" way to build a GUI.


What about Qt Quick? I have used it very little, but it does allow
dynamic modification of the GUI elements so that the application
changes on the fly. I don't know how pythonic it is, since the GUI is
described in QML, which combines CSS and javascript.

I have been following the Qt development as I have been using PySide
for some small projects on the Maemo platform.
Qt Quick / QML seems to enable the implementation of so-called "modern"
UIs.
It's more for people who think that HTML5/CSS/Javascript is the future
for UIs.
Well, maybe they are right for certain advanced requirements.
But for the beginner I don't see how it would help as it's even more
difficult to link the GUI to the backend code and also I don't see
how having to deal with multiple environments would make things easier.
I think that for beginners some basic controls are fine enough and
there's no need to care for fancy effects for the most non-consumer
applications.


For getting an impression about Qt Quick, have a look at
http://qt.nokia.com/qtquick/
(The slide show 1,2,3,...)


Regards,

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Dietmar Schwertberger]

Am 11.06.2012 14:01, schrieb Wolfgang Keller:

* Domain experts in fact who would need to implement loads of
software to help them get their work done but can't. And since there's
no budget for external developers, nothing get's ever done about this.

Well, typically or at least very often sooner or later something
gets done about this as someone finds out that all could be solved
using MS Excel and some macros / VBA programming.

I would prefer people to invest the same time into a Python based
solution.
But then we're back to the initial point: As long as there's no GUI
builder for Python, most people will stick to Excel / VBA / VB.


Regards,

Dietmar

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Dietmar Schwertberger]

Am 11.06.2012 06:05, schrieb rusi:

If python is really a "language maven's" language then it does not do
very well:
- its not as object-oriented as Ruby (or other arcana like Eiffel)
- its not as functional as Haskell
- its not as integrable as Lua
- its not as close-to-bare-metal as C
- etc

Depends on the definition. Maybe, that Python is not a perfect
language from an academic point of view, but it's a good choice
for anyone looking for a pragmatic programming language.



Then why is it up-there among our most popular languages? Because of
the 'batteries included.'

It's not only the batteries, but also the language itself.
As someone wrote a long time ago "Python fits my brain".


And not having a good gui-builder is a battery (cell?) that is
lacking.

It's a cell that would make it much easier to compete with other
languages/environments.
These environments need not necessarily be classical programming
language, but could also be Labview, Matlab etc.

And regarding popularity, I see very much potential.
I have been working for two high-tech companies and I have never
met anyone else using Python there.
Focus is not classical databases, but data acquisition and processing.
Many are still using VB, some are even using HT/HP-BASIC.
Quite a lot moved to Labview, some are using Matlab or thinking
about moving to it.
The ones who actually see the point the advantages of a general
purpose language moved to C#.
(Nobody is using Java in this context as it obviously would not make
any sense.)

Anyway, I don't see how people could be persuaded to use a
console-only environment, which - realistically - Python is at the
moment for most people.

From what I see, Python is recognized as a language for scripting
and maybe for web servers, but not as a general purpose language to
implement GUI software.

(To make it clear: I have been using Python as a general purpose
 language for many years.)

Regards,

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

Re: which one do you prefer? python with C# or java?

[Matej Cepl]

On 11/06/12 06:20, rusi wrote:

Hi Matěj! If this question is politically incorrect please forgive me.
Do you speak only one (natural) language -- English?
And if this set is plural is your power of expression identical in
each language?


I have written about that later ... no, I am a native Czech, but I have 
passive Russian, and active English. But there is a difference ... I can 
read and enjoy beautiful texts in Russian or English (couple of months 
read Eugen Onegin in Russian and that's just a beauty! or C.S.Lewis ... 
oh my!) but I will never be able to write professionally in these 
languages. I can write (as evidenced by this message) somehow in 
English, but I cannot imagine that I would be ever professional art 
writer or (even worse) poet. I could imagine (if spent couple of 
thousands of days working on it) that I would be a Czech professional 
writer though.


Matěj
--
http://mail.python.org/mailman/listinfo/python-list

Re: Where to set default data - where received, or where used

[Dave Angel]

On 06/11/2012 02:37 PM, Dennis Carachiola wrote:
> I'm programming a project which will use a file to save parameters
> needed by the program.  There are already two previous file formats,
> each of which can only be run by the version of the program which
> created them.  I'm trying to avoid that problem in the future.  To do
> that, I intend to use a dictionary, and default data.  I believe that
> most new versions will add parameters.
>
> Each version of the program will have reasonable default values for
> each key in the dictionary handled by that version.  If an older file
> is used, the data values in that file replace the keys that exist.
> The program then can operate on the values supplied by the older data
> file and the default values.  Conversely, if a newer file is used, the
> data in the file replaces the keys in the dictionary.  The program
> then simply doesn't access the newer data values.  I'm hoping that
> this will make the file backward and forward compatible.
>
> Here's my question.  I could do this by creating the dictionary with
> the default values, then read the file into it.  Or I could use a
> 'get' with default values at the location in the program where those
> values are used.
>
> >From what I can see, creating the dictionary with default values puts
> everything in one place.  While, supplying the default values at the
> place where they're used places the default values nearest the place
> where actually used.
>
> I can't decide on one way over the other.  Can anyone give me some
> ideas if one is a preferred method, or other criteria I've overlooked?
>
> Thanks,
>
> Den

i would do it at the point of input.  In fact, one option might be to
save an updated version of the file, with the missing fields filled in. 
By doing it all in one place, you can test whether the code works with
each external variant you intend to support, and gives you one place to
fix whatever incompatibilities you find.

You very well might discover you need a fancier algorithm than just
having default values.  For example, you might fill in missing values
with a computation based on the values you do have.  Further, if it gets
really messy, you might end up with multiple input funcitons, keyed on
the type (version) of the file.  The point is, none of the other code
should care one iota.

I certainly hope the version information for those existing files is
unambiguously stored.

-- 

DaveA

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

Sybase module 0.40 released

[Robert Boehne]

 WHAT IS IT:
The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

The module is available here:

http://downloads.sourceforge.net/python-sybase/python-sybase-0.40.tar.gz

The module home page is here:

http://python-sybase.sourceforge.net/

MAJOR CHANGES SINCE 0.39:

Modify the DateTimeAsPython output conversion to return None when NULL 
is output

support for Python without threads
Ignore additional non-error codes from Sybase (1918 and 11932)
Use outputmap in bulkcopy mode (thanks to patch by Cyrille Froehlich)
Raise exception when opening a cursor on a closed connection
Added unit tests
Added new exception DeadLockError when Sybase is in a deadlock situation
Add command properties CS_STICKY_BINDS and CS_HAVE_BINDS
Added support for inputmap in bulkcopy
reuse command and cursor when calling cursor.execute with same request
Use ct_setparam to define ct_cursor parameters types instead of ct_param
implicit conversion for CS_DATE_TYPE in CS_DATETIME_TYPE DataBuf
Adding ct_cmd_props wrapper
Increase DataBuf maxlength for params of a request when using 
CS_CHAR_TYPE params so that the buf can be reused


BUGS CORRECTED SINCE 0.39:

Corrected money type when using CS_MONEY4 (close bug 2615821)
Corrected thread locking in ct_cmd_props (thanks to patch by Cyrille 
Froehlich)
Corrected bug in type mapping in callproc (thanks to report by Skip 
Montanaro)

Correct passing None in a DataBuf (thanks to patch by Bram Kuijvenhoven)

The full ChangeLog is here:

https://python-sybase.svn.sourceforge.net/svnroot/python-sybase/tags/r0_40/ChangeLog

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

Re: which one do you prefer? python with C# or java?

[Tomasz Rola]

On Mon, 11 Jun 2012, Tomasz Rola wrote:

> If you want to delve into Java world, well, I consider Java an unbearably 
> ugly hog. When I was younger and fearless I programmed a bit in Java, but 
> nowadays, the only way I myself could swallow this would be to use some 
> other language on top of it (Scala, Clojure or Kaffe).

Uhuh, I meant Kawa, not Kaffe:

http://en.wikipedia.org/wiki/Kawa_(Scheme_implementation)

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: which one do you prefer? python with C# or java?

[Tomasz Rola]

On Sat, 9 Jun 2012, Yesterday Paid wrote:

> I'm planning to learn one more language with my python.
> Someone recommended to do Lisp or Clojure, but I don't think it's a
> good idea(do you?)
> So, I consider C# with ironpython or Java with Jython.
> It's a hard choice...I like Visual studio(because my first lang is VB6
> so I'm familiar with that)
> but maybe java would be more useful out of windows.
> 
> what do you think?

If you don't know C yet, I second recommendation to learn it. It is a very 
70-tish and 80-tish language, but it is still very relevant if you want to 
call yourself a programmer (rather than a hobbyist, with all credits due 
to clever genius hobbyists out there). There are things I would rather do 
in C than in any other language (like, writing a Python interpreter or 
Linux kernel - wait, what you say they have been written already?). Also, 
it gives one a way to handtune the code quite a lot (at expense of time, 
but this is sometimes acceptable), to the point where next choice is 
assembly (and results not necessarily better)...

Later on, since C and C++ share quite a bit, you can gradually include C++ 
elements into your code, thus writing in a kinda "bettered C" (compiled 
with C++ compiler), using constructs like "const" to make your programs 
more correct. And you will learn to not use "new" for variables, which is 
good thing. However, some C++ constructs include performance penalty, so 
it is good to not better it too much.

Later on, you could choose from the list:

- Common Lisp - "nice industrial standard" (depends on one's preferred 
definition of "nice", of course, as well as "industrial" and "standard")

- Racket - Scheme on steroids, with IDE, JIT and crossplatform-ity (I can 
think of somebody writing Python/Racket to be used in this environment but 
it is hard to imagine someone doing the other direction, so go figure ;-) 

http://www.reddit.com/r/programming/comments/i1slm/amazing_tutorial_demonstrating_the_power_of/

http://hashcollision.org/brainfudge/

)

- Haskell or Ocaml - but I have a feeling Ocaml is developing at slower 
pace now, with many people choosing Haskell (I guess they sometimes 
curse themselves for this, because behaviour of code in Haskell is a bit 
hard to predict, sometimes).

If you want to delve into Java world, well, I consider Java an unbearably 
ugly hog. When I was younger and fearless I programmed a bit in Java, but 
nowadays, the only way I myself could swallow this would be to use some 
other language on top of it (Scala, Clojure or Kaffe).

C# as a - kind of - Java clone from MS, is not really so attractive to me.

(Yes, both Java and C# have some merits in some situations, so do COBOL, 
VB and Fortran but I tend to avoid such situations and thus life gets much 
simpler).

If you would like to bend your mind a little, Racket or Forth or Smalltalk 
(in a form of SqueakVM) could do the job. Every time I read about 
Smalltalk and think how Java took over, I mentally weep.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Where to set default data - where received, or where used

[Nick Cash]

This is really up to your programming style, but I'm of the opinion that 
defining all of the default values in one place keeps maintenance easier.

Of course, if it's done differently elsewhere in your code base, I would aim 
for consistency instead.

Thanks,
Nick Cash

-Original Message-
From: python-list-bounces+nick.cash=npcinternational@python.org 
[mailto:python-list-bounces+nick.cash=npcinternational@python.org] On 
Behalf Of Dennis Carachiola
Sent: Monday, June 11, 2012 13:38
To: python-list@python.org
Subject: Where to set default data - where received, or where used

I'm programming a project which will use a file to save parameters needed by 
the program.  There are already two previous file formats, each of which can 
only be run by the version of the program which created them.  I'm trying to 
avoid that problem in the future.  To do that, I intend to use a dictionary, 
and default data.  I believe that most new versions will add parameters.

Each version of the program will have reasonable default values for each key in 
the dictionary handled by that version.  If an older file is used, the data 
values in that file replace the keys that exist.
The program then can operate on the values supplied by the older data file and 
the default values.  Conversely, if a newer file is used, the data in the file 
replaces the keys in the dictionary.  The program then simply doesn't access 
the newer data values.  I'm hoping that this will make the file backward and 
forward compatible.

Here's my question.  I could do this by creating the dictionary with the 
default values, then read the file into it.  Or I could use a 'get' with 
default values at the location in the program where those values are used.

>From what I can see, creating the dictionary with default values puts
everything in one place.  While, supplying the default values at the place 
where they're used places the default values nearest the place where actually 
used.

I can't decide on one way over the other.  Can anyone give me some ideas if one 
is a preferred method, or other criteria I've overlooked?

Thanks,

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


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

Where to set default data - where received, or where used

[Dennis Carachiola]

I'm programming a project which will use a file to save parameters
needed by the program.  There are already two previous file formats,
each of which can only be run by the version of the program which
created them.  I'm trying to avoid that problem in the future.  To do
that, I intend to use a dictionary, and default data.  I believe that
most new versions will add parameters.

Each version of the program will have reasonable default values for
each key in the dictionary handled by that version.  If an older file
is used, the data values in that file replace the keys that exist.
The program then can operate on the values supplied by the older data
file and the default values.  Conversely, if a newer file is used, the
data in the file replaces the keys in the dictionary.  The program
then simply doesn't access the newer data values.  I'm hoping that
this will make the file backward and forward compatible.

Here's my question.  I could do this by creating the dictionary with
the default values, then read the file into it.  Or I could use a
'get' with default values at the location in the program where those
values are used.

>From what I can see, creating the dictionary with default values puts
everything in one place.  While, supplying the default values at the
place where they're used places the default values nearest the place
where actually used.

I can't decide on one way over the other.  Can anyone give me some
ideas if one is a preferred method, or other criteria I've overlooked?

Thanks,

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

Re: which one do you prefer? python with C# or java?

[Alexander Blinne]

On 10.06.2012 23:27, Paul Rubin wrote:
> Here is an exercise from the book that you might like to try in Python:
> 
>   http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html#%_idx_3894
> 
> It's not easy ;-)

I liked this exercize. At first I wrote my own merger.

> def merge(*iterables):
> iterables = list(iterables)
> current = [i.next() for i in iterables]
> last = None
> while True:
> m = min(current)
> while last == m:
> p = current.index(m)
> try:
> current[p] = iterables[p].next()
> except StopIteration:
> del current[p]
> del iterables[p]
> if len(current) == 0:
> raise StopIteration
> m = min(current)
> yield m
> last = m

But then I realised the vast library of python already contained (a
faster) one (propably based upon
), which
just needed to be enhanced a little bit to allow duplicate items to be
removed:

> import heapq
> 
> def skipdups(m):
> l = k = m.next()
> yield k
> while True:
> while l == k:
> k = m.next()
> yield k
> l = k
> 
> def gen_s():
>   s = [1]
>   m = skipdups(heapq.merge(*[(lambda j: (k*j for k in s))(n) for n in 
> [2,3,5]]))
>   yield s[0]
>   while True:
>   k = m.next()
>   s.append(k)
>   yield k

Now gen_s() generates the wanted sequence.

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

Ann: New Stackless Website

[Christian Tismer]

I'm very happy to announce

==
Stackless Python has a New Website
==

Due to a great effort of the Nagare people:

http://www.nagare.org/

and namely by the tremendous work of Alain Pourier,

Stackless Python has now a new website!

This is no longer Plone based, but a nicely configured Trac site.

The switch to it has happened right now, the old website
will be around for a few days under

http://zope.stackless.com

while the new site is accessible as

http://www.stackless.com

stackless.com now allows the source to be browsed (an hourly updated
clone from hg.python.org) and includes a new issue tracker.

Please let me know if you encounter any problems.

cheers -- Chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

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

Re: Decorator Pattern with Iterator

[Ian Kelly]

On Mon, Jun 11, 2012 at 1:51 AM, Tom Harris  wrote:
> Greetings,
>
> I have a class that implements the iterator protocol, and tokenises a string
> into a series of tokens. As well as the token, it keeps track of some
> information such as line number, source file, etc.

So each processor needs to be able to access that information?  A
decorator pattern for the processors to propagate that information
down might look like this:

class TokenProcessor(object):
def __init__(self, processor):
self._processor = processor
def __call__(self, tokens):
self._tokens = tokens
return self._processor(tokens)
@property
def line_number(self):
return self._tokens.line_number
@property
def source_file(self):
return self._tokens.source_file

@TokenProcessor
def processor(tokens):
for token in tokens:
line_number = tokens.line_number
do_stuff(token, line_number)
yield token

for token in processor_1(processor_2(tokeniser)):
do_more_stuff(token)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python with xl

[Karim]

Le 11/06/2012 16:12, chebrian a écrit :

Hi,

How to append the list of data in individual column of  XL file, every
time from python script  .

In standard lib => module csv (ascii comma separated values)
In non standard => binary xl => module xlrd for reading and module xlwt 
for writing (http://www.python-excel.org/)


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

python with xl

[chebrian]

Hi,

How to append the list of data in individual column of  XL file, every
time from python script  .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Anssi Saari]

Wolfgang Keller  writes:

> This whole cycle of "design GUI"->"generate code"->add own code to
> generated code"->"run application with GUI" has always seemed very
> un-pythonic to me. A dynamic, interpreted language should allow to work
> in a more "lively", "direct" way to build a GUI.

What about Qt Quick? I have used it very little, but it does allow
dynamic modification of the GUI elements so that the application
changes on the fly. I don't know how pythonic it is, since the GUI is
described in QML, which combines CSS and javascript.


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

Re: Pythonic cross-platform GUI desingers � la Interface Builder (Re: what gui designer is everyone using)

[Mark Roseman]

 Dietmar Schwertberger  wrote:
> But the fact that Tkinter is still the standard GUI toolkit tells a lot
> about the situation...
>  ...
> Sure, I know how to code GUIs. But the learning curve is too steep
> for new users wanting to implement simple GUIs.


As is obvious to everybody, the massive interest in web-based 
applications in recent years has certainly not helped advance the state 
of the art in desktop GUI's, nor enlarged the developer population 
actively engaged in maintaining and improving desktop GUI toolkits.  

Given that, we're likely "stuck" with more or less what we have now, so 
let's make the best of it.

On the Tkinter front, I just want to reiterate two important points that 
are not nearly as well known as they should be.

First, it is possible and in fact easy to do decent looking GUI's in 
Tkinter, with the caveat that you do in fact have to do things very 
slightly differently than you would have 15 years ago. Shocking, I know.

Second, there does exist at least one fairly good source of 
documentation for new users wishing to do exactly this (according to 
many, many comments I have received), though that documentation is 
admittedly buried in a sea of out-of-date information that is still all 
too easy to find.

Please see http://www.tkdocs.com and in particular the tutorial there.

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

Decorator Pattern with Iterator

[Oscar Benjamin]

On 11 June 2012 08:51, Tom Harris  wrote:

> Greetings,
>
> I have a class that implements the iterator protocol, and tokenises a
> string into a series of tokens. As well as the token, it keeps track of
> some information such as line number, source file, etc.
>
> for tokens in Tokeniser():
>   do_stuff(token)
>
> What I want is to be able to wrap the tokeniser to add functionality to
> the base parser without subclassing, e.g.
>
> for tokens in processor(Tokeniser()):
>   do_stuff(token)
>
> Sort of Decorator pattern, so that I can chain more processors,  but I
> cannot think how to implement it. Any clues for me?
>

Maybe I've misunderstood. Is this what you're looking for?

def processer(tokens):
for token in tokens:
yield func(token)


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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Mark Lawrence]

On 11/06/2012 13:47, Kevin Walzer wrote:

Yes, Tkinter GUI's are very ugly.

http://www.codebykevin.com/phynchronicity-running.png

http://www.codebykevin.com/quickwho-main.png



At last we're getting to the crux of the matter.  Provided that the GUI 
is pretty who cares about picking appropriate algorithms for the code, 
or a sensible database design or whatever.  And heaven forbid that 
anyone suggest using a command line even if this was the better solution 
for the problem that the user wants solved.


--
Cheers.

Mark Lawrence.

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Kevin Walzer]

On 6/11/12 8:01 AM, Wolfgang Keller wrote:

Tkinter is imho honestly the very best "argument" if you want to make
potential new users turn their backs away from Python for good. Just
show them one GUI implemented with it and, hey, wait, where are you
running to...


Yes, Tkinter GUI's are very ugly.

http://www.codebykevin.com/phynchronicity-running.png

http://www.codebykevin.com/quickwho-main.png

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Wolfgang Keller]

> > What "GUI designer" would come the closest to the way that Cocoa's
> > Interface Builder works? I.e. is there any one (cross-platform) that
> > allows to actually "connect" the GUI created directly to the code
> > and make it available "live" in an IDE?
> 
> If you're developing on the Mac, PyObjC allows you to use Interface 
> Builder for developing Python apps.

I know that. And no, I haven't used Interface Builder yet myself, just
because I would need those GUIs also to run elsewhere than on my
private Mac.

> However, there are those of us who are deeply uncomfortable with IB
> and related tools, such as RealBasic and LiveCode/Runtime Revolution.

I haven't used any of these either, just because I don't like those
languages. Their syntax is ugly, static type declarations are imho
perfectly redundant for interpreted languages and besides they don't
offer me an interactive interpreter, which is an absolute must-have for
my day-to-day use of Python - "office automation", ad-hoc "information
logistics" etc. (errr, sorry for those quotation marks again... ;-).

> These tools make code organization very hard by reducing the amount
> of code written to the point of the UI working by "magic," 

Any modern GUI framework has quite a lot of "magic" going on
"behind the curtains" without that the user needs to know or understand
how it works. And this is the way it _should_ be. As long as it is well
documented how to use that "magic".

The current GUI frameworks which are available for Python require way
too much "glue code" that needs to be written by hand, imho simply
because they are primitive wrappers around frameworks for C++
developers who are used to such bulkloads of slave labour. Python as a
language is way ahead of C++, Java, C# etc. in terms of functionality
that you can implement per coding effort required , but it simply lacks
GUI frameworks and corresponding development tools that are equally
efficient.

> and/or by breaking up your code into little snippets that you can
> only view by clicking on the widget in the UI tool.

I remember reading about RAD IDEs/frameworks out there that managed to
integrate/seperate their generated code with/from user-written code
quite well. And which could even use external revision control systems
etc.. Back in the good old days of software diversity, before MS/Java
took over the whole world...

> A related issue is that using a tool such as this makes you heavily 
> dependent on that particular tool, and subject to its developers' 
> priorities, release schedule, and bugs.

This is true with _any_ language, library, framework or software. Heck,
it's even true with hardware! If this was such a show-stopper, we would
still write computer programs like this: 0100011100101010101
Well, certainly not me, in that case.

> The pace of Xcode development--with Apple making frequent changes to
> project formats in a backwards-incompatible way--is an example of
> this.

Wxwidgets/python has a reputation for frequent incompatible API changes,
too...

And Apple's "product politics", oh, well, errr, uhm, don't get me into
that... *sigh*. If only all those third-party applications for MacOS X
were available on Linux, I would happily forget about Apple's very
existence.

> One reason I prefer to code UI's by hand is because a) in Tkinter
> it's very easy to do, 

Tkinter is imho honestly the very best "argument" if you want to make
potential new users turn their backs away from Python for good. Just
show them one GUI implemented with it and, hey, wait, where are you
running to...

> I think these issues are a reason that the slick "drag-and-drop" UI 
> builders tend to be developed by commercial software shops to support 
> their language and/or IDE, but find little traction among open-source 
> developers and languages.

The point is that loads of potential "developers"(*) simply don't
ever get to use Python due to the very lack of such tools (and
corresponding frameworks).

* Domain experts in fact who would need to implement loads of
software to help them get their work done but can't. And since there's
no budget for external developers, nothing get's ever done about this.

Sincerely,

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

Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Wolfgang Keller]

> > What "GUI designer" would come the closest to the way that Cocoa's
> > Interface Builder works? I.e. is there any one (cross-platform) that
> > allows to actually "connect" the GUI created directly to the code
> > and make it available "live" in an IDE?
> >
> > This whole cycle of "design GUI"->"generate code"->add own code to
> > generated code"->"run application with GUI" has always seemed very
> > un-pythonic to me. A dynamic, interpreted language should allow to
> > work in a more "lively", "direct" way to build a GUI.
> 
> I'm curious about your point but I don't really understand it.  Could
> you try again without using any scare-quoted words?

myidea.explanation.retry()

Python has this insanely great thing that e.g. Delphi, Java, C#, Visual
Basic, etc. lack and that's called an interactive commandline
interpreter, which allows you to build GUIs while exploring/trying out
the API of a GUI framework step by step. You simply type the code for
the GUI at the python prompt and your GUI comes directly to life.
Here's an example by someone else:

http://pysnippet.blogspot.de/2010/11/getting-interactive-with-pyqt.html

Now "just" (sorry for those quotes again) imagine a GUI builder that
generates _and_ _runs_ the code (pyqt, wxpython, pygtk, whatever) for
the GUI you edit _while_ you do so.

And now imagine that this GUI builder would be integrated with the IDE
you use (I use one), so that the GUI code is run in the same
interpreter instance as the other code of your application. So that you
can directly interact with your application through the GUI you build
while you do so.

The advantage of using a GUI builder over typing the code into the
interpreter window would be that users who rarely implement a GUI(*)
would not need to re-dig into the details of the API every time. This is
especially tedious since those APIs are essentially C++ APIs wrapped
in Python and thus they are honestly simply §$%&@# to use for a certain
type of Python user(*). And the lack of Python-specific documentation,
tutorials etc. doesn't really help. Did I mention yet that just having
to read C++ example code in documentation makes me spill my last meal
over keyboard, screen etc.?

Of course there's PyGUI, but that's unfortunately far from being as
complete as PyQt or wxPython and unless someone creates something like
an equivalent of Apache Software Foundation for Python, declares PyGUI
as the canonical Python GUI framework and funds the work needed to
complete it... And then you still need a GUI builder for it. *sigh*

> Maybe given an example of creating a small text editor application
> with a GUI builder/ IDE in this Pythonic way you are hoping for.

I'm not into text editors as example applications since I don't
develop text editors, I rarely even use one. And besides, I don't think
any typical user(*) of such a GUI builder would ever implement a text
editor in his whole life.

Personally, my typical use of such a GUI builder would be for database
applications. Which make up, according to my experience, for at least
90% of all custom-built applications in companies. Today, these
applications have to be made by external, paid developers who have
typically no clue of the application domain in question. Consequently,
the applications, no matter how many pages of detailed specifications
you as the domain expert write, never do what you wanted them to do.
Although just writing the specification takes more time than it would
take to implement it myself if only the (GUI) tools and (GUI)
frameworks(**) for Python would be at the level required to make them
useful for such "developers" as me(*). And did I mention that the cost
of external developers (plus the overhead cost for interaction with
them) makes them prohibitive anyway? And did I mention that the time
required such external development (plus the overhead time for
interaction with the external developers) takes doesn't help either?

* Such as "casual" Python scripting dilettants who are not full-time
software developers but domain experts who just use Python to help get
their main work done.

** In my case of database applications, something like this:
http://www.nakedobjects.org/book/
http://www.nakedobjects.org/downloads/Pawson%20thesis.pdf

Sincerely,

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

Re: which one do you prefer? python with C# or java?

[88888 Dihedral]

Yesterday Paid於 2012年6月10日星期日UTC+8上午6時44分44秒寫道：
> I'm planning to learn one more language with my python.
> Someone recommended to do Lisp or Clojure, but I don't think it's a
> good idea(do you?)
> So, I consider C# with ironpython or Java with Jython.
> It's a hard choice...I like Visual studio(because my first lang is VB6
> so I'm familiar with that)
> but maybe java would be more useful out of windows.
> 
> what do you think?

If the goal is to write programs to be cross-platform,
then I suggest some utilities like p2c (pascal to c), and f2c (fortran to c),
and etc. to be available. 

Also source programs which are structured well with unit tests do help a lot 
in translations to other computer languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why does this leak memory?

[Ulrich Eckhardt]

Am 08.06.2012 18:02, schrieb Steve:
> Well, I guess I was confused by the terminology. I thought there were
> leaked objects _after_ a garbage collection had been run (as it said
> "collecting generation 2"). Also, "unreachable" actually appears to mean
> "unreferenced". You live n learn...

Actually I understand that differently. If you have circular references
between two objects they are both referenced. If neither is referenced
(directly or indirectly) by the current context, they are unreachable
and can be garbage-collected. Being unreferenced implies that it is
unreachable, but not vice-versa.

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

Decorator Pattern with Iterator

[Tom Harris]

Greetings,

I have a class that implements the iterator protocol, and tokenises a
string into a series of tokens. As well as the token, it keeps track of
some information such as line number, source file, etc.

for tokens in Tokeniser():
  do_stuff(token)

What I want is to be able to wrap the tokeniser to add functionality to the
base parser without subclassing, e.g.

for tokens in processor(Tokeniser()):
  do_stuff(token)

Sort of Decorator pattern, so that I can chain more processors,  but I
cannot think how to implement it. Any clues for me?

Thanks

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