Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #61889 > unrolled thread

GUI:-please answer want to learn GUI programming in python , how should i proceed.

Back to article view | Back to comp.lang.python

Contents

  GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Jai <jaiprakashsingh213@gmail.com> - 2013-12-14 04:12 -0800
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-14 23:25 +1100
      Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Jai <jaiprakashsingh213@gmail.com> - 2013-12-14 04:46 -0800
      Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. rurpy@yahoo.com - 2013-12-14 09:42 -0800
        Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 18:11 +0000
        Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-14 13:10 -0700
    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-14 18:05 +0100
      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 17:54 +0000
      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-14 13:01 -0700
        Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-14 22:59 +0000
          Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Grant Edwards <invalid@invalid.invalid> - 2013-12-15 14:53 +0000
            Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-15 17:01 +0000
              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-16 09:06 +1100
                Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Kevin Walzer <kw@codebykevin.com> - 2013-12-16 09:55 -0500
                  Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-17 02:20 +1100
                    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Kevin Walzer <kw@codebykevin.com> - 2013-12-16 10:32 -0500
                      Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-17 03:10 +1100
                        Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Grant Edwards <invalid@invalid.invalid> - 2013-12-16 16:46 +0000
                          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-17 03:52 +1100
                            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Grant Edwards <invalid@invalid.invalid> - 2013-12-16 17:04 +0000
                              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Christian Gollwitzer <auriocus@gmx.de> - 2013-12-16 23:12 +0100
                              Re: GUI:-please answer want to learn GUI programming in python ,   how should i proceed. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-17 11:37 +1300
                                Re: GUI:-please answer want to learn GUI programming in python ,   how should i proceed. Grant Edwards <invalid@invalid.invalid> - 2013-12-17 04:27 +0000
                        Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Christian Gollwitzer <auriocus@gmx.de> - 2013-12-16 23:06 +0100
                          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-17 09:40 +1100
                            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Christian Gollwitzer <auriocus@gmx.de> - 2013-12-17 10:33 +0100
                              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-18 00:19 +1100
                          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Terry Reedy <tjreedy@udel.edu> - 2013-12-16 19:10 -0500
                          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 04:21 +0000
              Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-16 21:37 -0800
                Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-17 16:47 +1100
                Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 05:48 +0000
                  Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. wxjmfauth@gmail.com - 2013-12-16 23:58 -0800
                    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 08:33 +0000
                      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. wxjmfauth@gmail.com - 2013-12-17 01:18 -0800
                        Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 09:44 +0000
                    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Steven D'Aprano <steve@pearwood.info> - 2013-12-17 09:29 +0000
                      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 09:39 +0000
                        Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 11:13 +0000
                          Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Robert Kern <robert.kern@gmail.com> - 2013-12-17 13:03 +0000
                            Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. wxjmfauth@gmail.com - 2013-12-17 06:02 -0800
                              Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. wxjmfauth@gmail.com - 2013-12-17 06:43 -0800
                                Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 14:52 +0000
                          Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 13:47 +0000
                      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. wxjmfauth@gmail.com - 2013-12-17 04:19 -0800
                      Fwd: GUI:-please answer want to learn GUI programming in python , how should i proceed. Igor Korot <ikorot01@gmail.com> - 2013-12-17 05:28 -0800
                Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Christian Gollwitzer <auriocus@gmx.de> - 2013-12-17 09:11 +0100
      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-14 13:04 -0700
        Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-15 16:33 +0100
          Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-15 10:19 -0700
          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-12-15 18:52 +0100
            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:26 +0100
          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-15 17:59 +0000
      Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Ned Deily <nad@acm.org> - 2013-12-14 12:36 -0800
      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Terry Reedy <tjreedy@udel.edu> - 2013-12-14 16:00 -0500
      Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Jeremy Sanders <jeremy@jeremysanders.net> - 2013-12-16 09:28 +0100
    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Tamer Higazi <tameritoke2@arcor.de> - 2013-12-16 02:34 +0200
    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-16 01:18 +0000
    Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Tamer Higazi <tameritoke2@arcor.de> - 2013-12-16 06:09 +0200
      Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:07 +0100
        Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Terry Reedy <tjreedy@udel.edu> - 2013-12-17 13:11 -0500
          Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-23 18:59 +0100
            Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-23 11:05 -0800
              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-24 06:14 +1100
              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 19:22 +0000
              Please stop the trolling Terry Reedy <tjreedy@udel.edu> - 2013-12-23 15:53 -0500
                Re: Please stop the trolling wxjmfauth@gmail.com - 2013-12-24 02:22 -0800
                  Re: Please stop the trolling Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-24 14:58 +0000
                  Re: Please stop the trolling Ned Batchelder <ned@nedbatchelder.com> - 2013-12-24 10:28 -0500
                  Re: Please stop the trolling Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-24 15:55 +0000
                  Re: Please stop the trolling Ned Batchelder <ned@nedbatchelder.com> - 2013-12-24 11:04 -0500
              Re: Please stop the trolling Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 23:52 +0000
              Re: Please stop the trolling Joshua Landau <joshua@landau.ws> - 2013-12-26 07:58 +0000
    Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-15 21:51 -0700
      Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:01 +0100
    Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-15 21:55 -0700
    Re: GUI:-please answer  want to learn GUI programming in python , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-15 21:56 -0700
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-16 15:57 +1100
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-16 16:08 +1100
      Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:00 +0100
        Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-17 11:06 -0700
          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-17 11:00 -0800
            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 19:33 +0000
            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-18 01:24 -0800
              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 16:45 +0000
            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-19 00:10 -0800
              Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 08:25 +0000
                Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-19 01:10 -0800
                  Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 09:23 +0000
          Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 16:32 +0100
            Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-20 03:20 +1100
            Re: GUI:-please answer want to learn GUI programming in python , 
 how should i proceed. Dave Angel <davea@davea.name> - 2013-12-20 01:30 -0500
            Re: Re: GUI:-please answer want to learn GUI programming in python ,  how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-20 17:57 +1100
              Re: GUI:-please answer want to learn GUI programming in python ,  how should i proceed. Martin Schöön <martin.schoon@gmail.com> - 2013-12-20 17:52 +0000
                Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-20 18:00 +0000
                  Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Martin Schöön <martin.schoon@gmail.com> - 2013-12-21 13:25 +0000
                Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. wxjmfauth@gmail.com - 2013-12-20 10:34 -0800
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-16 09:42 +0000
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Chris Angelico <rosuav@gmail.com> - 2013-12-16 22:58 +1100
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-16 13:58 +0000
    Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. 88888 Dihedral <dihedral88888@gmail.com> - 2013-12-16 08:34 -0800
      Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:00 +0100
        Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Michael Torrie <torriem@gmail.com> - 2013-12-17 11:13 -0700
          Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 16:10 +0100
            Re: GUI:-please answer  want to learn GUI programming in python  , how should i proceed. Ned Batchelder <ned@nedbatchelder.com> - 2013-12-19 10:22 -0500
    Re: GUI:-please answer want to learn GUI programming in python , how should i proceed. Dan Stromberg <drsalists@gmail.com> - 2013-12-23 11:24 -0800

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#62106 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

Am 16.12.13 18:04, schrieb Grant Edwards:
> On 2013-12-16, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Dec 17, 2013 at 3:46 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>>>    * The "everything is a string" view of the world is severly
>>>      limiting if you're not just processing strings.
>>
>> I wasn't sure if that was the case, from what I was seeing. Are there
>> any aggregate types at all?
>
> There are arrays with string keys (similar to Python dictionaries).

Aggregate types are indeed a weak point, but still there are lists 
(since ever) and dicts (since 8.5, ~6 years) with value semantics. 
Arrays are distinct from dicts and provide no value semantics, i.e. you 
cannot pass them around. Today these issues are overcome by using dicts 
or some OO framework.

	Christian

[toc] | [prev] | [next] | [standalone]

#62111 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

Grant Edwards wrote:
> On 2013-12-16, Chris Angelico <rosuav@gmail.com> wrote:
> 
>> Are there
>> any aggregate types at all?
> 
> There are arrays with string keys (similar to Python dictionaries).

Well... sort of. They can only hold strings, not other arrays.
They're not first-class entities: you can't pass them around
or keep them in local variables; they're always global. (And
there are no modules, so global is *truly* global.)

In short, they're a very poor substitute for having real data
structures.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#62149 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On 2013-12-16, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
> Grant Edwards wrote:
>> On 2013-12-16, Chris Angelico <rosuav@gmail.com> wrote:
>> 
>>> Are there
>>> any aggregate types at all?
>> 
>> There are arrays with string keys (similar to Python dictionaries).
>
> Well... sort of. They can only hold strings, not other arrays.
> They're not first-class entities: you can't pass them around
> or keep them in local variables; they're always global. (And
> there are no modules, so global is *truly* global.)

It's worse that I remembered -- I must have repressed most of
my Tcl memories.

> In short, they're a very poor substitute for having real data
> structures.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#62105 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

Let the flame war begin!
Am 16.12.13 17:10, schrieb Chris Angelico:
> Here's the Tcl procedure that I tweaked. This is from gitk; I find the
> word diff not all that useful, but a character diff at times is very
> useful. I haven't found a way to configure the word diff regex through
> gitk's options, so I tweaked it in the source code.
>
> proc getblobdiffs {ids} {
>      global blobdifffd diffids env
>      global diffinhdr treediffs
>      global diffcontext
>      global ignorespace
>      global worddiff
>      global limitdiffs vfilelimit curview
>      global diffencoding targetline diffnparents
>      global git_version currdiffsubmod
> .....

 > }

I'm a long time Tcl developer who has just picked up Python recently; so 
my view is tinted from the other side.

First off, gitk is a huge unstructured mess. You are not obliged to 
write programs like this in Tcl, at least not today. All these global 
statements give already a hint, that this is a procedural thing. Think 
of Python, where classes are stripped. Tcl has object oriented 
frameworks for years. If you use Snit, e.g., all those globals are not 
needed because they are really instance variables.

> First off, everything's done with commands, rather than assignment
> ("set diffinhdr 0"), which is very shell-style and not very
> programming-style.

This is just syntax and purely a matter of taste.

> Can live with that, though even shells can use
> equals signs for simplicity. Similarly, the shell style of adorning
> variable usage feels messy. There are string literals, some of which
> contain interpolated variables; there are dollar-sign adorned
> variables; and then there are other words. What are the other words?
> Are they implicit strings (as they would be in, say, bash)?

Yes, they are, and it doesn't feel strange if you are used to it. Tcl's 
syntax rules are very compact. Tclers see this as an advantage.

> Secondly, what does this do?
>      if {$worddiff ne [mc "Line diff"]}
>
> I *think* it means 'if $worddiff is not equal to "Line diff" (this
> code is executed for the options "Markup words" and "Color words", but
> what's the mc do?

It does command substitution (indeed the brackets [] do) and is one of 
the key concepts of Tcl. mc is probably the command from msgcat which 
translates i18n strings. Complaining about these basic things is like 
complaining about indentation in Python.

> This is where, IMO, Python tends to be a lot clearer. It's easy to see
> what's an object and what's a method on it, and every bare word is
> either a local name or a standard built-in name. I'm sure Tcl's a
> great language, but I'd rather not have to drop out of Python into it
> if I can help it. :)

Python has some advantages over Tcl. To name a few, references, list 
comprehensions, real classes, clean module support, extensive extensions 
such as matplotlib/scipy. But Tcl also has some strengths.

First off, the syntax is quite flexible, and so things like list 
comprehensions[1] or classes[2] can be implemented in Tcl itself. 
Second, it's great at interactive use because at a command prompt, you 
don't want to type all those () call operators, "quotes" and obey 
indentation just to get a simple loop running. Third, its implementation 
features a few unique things:

* Stubs. Compile a C extension against 8.1 and load it into 8.6. This 
actually works. 8.1 was nearly 15 years ago!

* Safe interpreters. Sometimes requested here for Python, you can create 
a slave interpreter in Tcl that is restricted and cannot do disk I/O, 
has limited execution time etc. You can precisely control which commands 
are passed on to the slave.

* Interpreters in threads. There is no GIL, Tcl interpreters are thread 
safe and more than one can coexist in a process and run concurrently. 
This is accessible from script level through the Threads package.

* Very easy deployment: Starkits/Tclkits bundle an interpreter within a 
single executable. Similar to what pyinstaller does. But in my 
experience, it's much easier to pack all dependencies into a starkit 
than it is with pyinstaller. You can get a rather full-fledged 
interpreter with GUI support into a few megabytes, and I've never seen 
it fail.

Happy flaming,

	Christian

[1] http://wiki.tcl.tk/12574
[2] http://wiki.tcl.tk/3963

[toc] | [prev] | [next] | [standalone]

#62113 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On Tue, Dec 17, 2013 at 9:06 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> Let the flame war begin!

I'll try to avoid flamage :)

> First off, gitk is a huge unstructured mess. You are not obliged to write
> programs like this in Tcl, at least not today. All these global statements
> give already a hint, that this is a procedural thing. Think of Python, where
> classes are stripped. Tcl has object oriented frameworks for years. If you
> use Snit, e.g., all those globals are not needed because they are really
> instance variables.

Ah, okay. Don't take gitk as representative. Got it. Unfortunately
there are quite a few languages that I've experienced from, really,
only one program that I've tried to modify (Scheme almost falls in
that category too - all I've ever used it for is LilyPond scripting,
and not much of that), and I'm aware that's not really a fair look at
the language.

>> First off, everything's done with commands, rather than assignment
>> ("set diffinhdr 0"), which is very shell-style and not very
>> programming-style.
>
> This is just syntax and purely a matter of taste.

Yeah. Like I said,

>> Can live with that

. But my rule of thumb with bash scripts is: If it exceeds a page or
two in length, it's probably time it got rewritten in an application
language. When a program is the size of gitk (>10KLOC), the benefits
relating to interactive use (as you mention below) become less
significant, and benefits relating to discoverability of the more
obscure features become more significant.

> It does command substitution (indeed the brackets [] do) and is one of the
> key concepts of Tcl. mc is probably the command from msgcat which translates
> i18n strings. Complaining about these basic things is like complaining about
> indentation in Python.

Okay. Now, how am I to figure out where this command comes from? It's
not a host command (typing "mc" at the bash prompt comes up failure),
and it's not defined in the script itself (at least, I can't find
"proc mc" anywhere); is it a Tcl built-in? Where do I start looking?

(Yes, I'm aware this is a problem in any language. I'm not now raising
a point in the Python vs Tcl debate, I'm just asking out of
curiosity.)

> Tcl also has some strengths.
>
> First off, the syntax is quite flexible, and so things like list
> comprehensions[1] or classes[2] can be implemented in Tcl itself. Second,
> it's great at interactive use because at a command prompt, you don't want to
> type all those () call operators, "quotes" and obey indentation just to get
> a simple loop running. Third, its implementation features a few unique
> things:

Yeah, that's nice for the interactive interpreter... but I already
have bash for that, and Python's not far off. I've used interactive
Pike and REXX interpreters, which are both more demanding than Python
(in terms of syntax requirements and such), so I'm perfectly happy
with Python; but if you're used to something even lighter, then sure,
use something that lets you type almost nothing. No problem. I just
think that - as mentioned above - a ten thousand line program should
be aiming more at maintainability than ease of manual typing.

> * Safe interpreters. Sometimes requested here for Python, you can create a
> slave interpreter in Tcl that is restricted and cannot do disk I/O, has
> limited execution time etc. You can precisely control which commands are
> passed on to the slave.

Cool. Not enough for me to choose the language unless I really REALLY
needed that feature, but there was one time in my programming career
when that was true, so we'll count that a win.

> * Interpreters in threads. There is no GIL, Tcl interpreters are thread safe
> and more than one can coexist in a process and run concurrently. This is
> accessible from script level through the Threads package.

Nice, though Python's threading and/or multiprocessing can do 90% of
what people want. Side point: What about Tk? Can you (a) run separate
GUI threads for separate windows? (b) manipulate widgets created by
another thread?

> * Very easy deployment: Starkits/Tclkits bundle an interpreter within a
> single executable. Similar to what pyinstaller does. But in my experience,
> it's much easier to pack all dependencies into a starkit than it is with
> pyinstaller. You can get a rather full-fledged interpreter with GUI support
> into a few megabytes, and I've never seen it fail.

Never really needed this, but for the people who do, I'm sure that's a
fairly big deal.

So there definitely are some advantages that Tcl has over Python. Put
against them is a superior object model, a large corpus of first-class
object types (dict, set, list, etc[1]), and a syntax that more clearly
differentiates names and strings without making variable references
look like a lot more than they are.

Huge room in the world for both languages to exist and thrive.

ChrisA

[1] What is an etc() in Python?

[toc] | [prev] | [next] | [standalone]

#62170 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

Am 16.12.13 23:40, schrieb Chris Angelico:
> On Tue, Dec 17, 2013 at 9:06 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
>> Let the flame war begin!
>
> I'll try to avoid flamage :)

:) So let's vigorously discuss about facts;)

> But my rule of thumb with bash scripts is: If it exceeds a page or
> two in length, it's probably time it got rewritten in an application
> language. When a program is the size of gitk (>10KLOC), the benefits
> relating to interactive use (as you mention below) become less
> significant, and benefits relating to discoverability of the more
> obscure features become more significant.

I do not know, whether bash has means to structure large programs, I 
suppose not. Tcl has (see below), and concerning discoverability, see 
also below.

>> It does command substitution (indeed the brackets [] do) and is one of the
>> key concepts of Tcl. mc is probably the command from msgcat which translates
>> i18n strings. Complaining about these basic things is like complaining about
>> indentation in Python.
>
> Okay. Now, how am I to figure out where this command comes from? It's
> not a host command (typing "mc" at the bash prompt comes up failure),
> and it's not defined in the script itself (at least, I can't find
> "proc mc" anywhere); is it a Tcl built-in? Where do I start looking?

Usually, I run the program in tkcon, an excellent interactive shell for 
Tcl. There you type "edit mc", and it shows you the definition, plus you 
can change it, send it back to the program and see how the modified 
program behaves now (without restarting it!) Under the hood, it executes 
commands like "info commands", "info args", "info body", which do the 
work. If it tells you that there is no such thing as "mc", it came from 
a compiled extension (a C procedure). Indeed, in this case you are out 
of luck, to my knowledge there is no info which extension loads that 
thing. But you could observe it before startup by putting up a command 
trace (some sort of callback) on "mc".

In the gitk case, mc comes from these lines:

	package require msgcat
	namespace import ::msgcat::mc

Now, be prepared: These lines do almost the same as

	import msgcat
	from msgcat import mc

would do in Python.

*What is this? I heard Tcl has no modules?* Don't listen to these 
people, today (well, namespaces exist since 8.0, 1997, packages date 
back further) you can use namespaces and packages to structure your 
programs and separate data. And because Tcl is highly introspective, you 
can ask about almost everything:

(src) 61 % namespace import
mc
(src) 62 % namespace origin mc
::msgcat::mc
(src) 63 %

(there is only one imported command in gitk, namespace import returns a 
list)


About globals: Yes "global" gives you a true global, but namespaces have 
namespace variables, which you should use instead. The awkward thing is 
that you need to import these (as the globals) into every proc which 
uses them, but by using an OO framework such as Snit, this burden is 
taken away from the programmer.

Still Python *has* advantages here. If there is a docstring, you can get 
help() about the unknown thing, it has a type() and in Tcl, the package 
author is responsible for wrapping the package content into a namespace. 
Something like "import Tkinter as Tk" is not possible in Tcl (well, you 
could rename the namespace, but if not carefully written, it may break 
the package).

>> * Interpreters in threads. There is no GIL, Tcl interpreters are thread safe
>> and more than one can coexist in a process and run concurrently. This is
>> accessible from script level through the Threads package.
>
> Nice, though Python's threading and/or multiprocessing can do 90% of
> what people want. Side point: What about Tk? Can you (a) run separate
> GUI threads for separate windows? (b) manipulate widgets created by
> another thread?

You can't run Tk more than once, that applies to almost every toolkit I 
know. But you can pass a message to the main thread to do it for you. 
This is quite easy; it looks like

thread::send -async $main [list doit $somedata]

You pass an arbitrary Tcl command which executes in the main thread as 
soon as it is idle. In fact, because of the embedded event loop in Tcl 
(not bound to Tk), you rarely need threads at all. Asynchronous I/O is 
very easy in Tcl (fileevent command).

That one question here with replicating nc to control a device would be 
a textbook example of fileevent usage in Tcl.

> So there definitely are some advantages that Tcl has over Python. Put
> against them is a superior object model, a large corpus of first-class
> object types (dict, set, list, etc[1]), and a syntax that more clearly
> differentiates names and strings without making variable references
> look like a lot more than they are.

Lists and dicts exist in Tcl as first class objects. You just can't tell 
them apart from strings. Sets are in tcllib. Python is more strongly 
typed than Tcl in that respect, which can be an advantage. Specifically 
doing math is easier in an evaluation based syntax than in a command 
based syntax, this sometimes sucks in Tcl.

> Huge room in the world for both languages to exist and thrive.

Yes, you name it. I wish people who criticize Tcl would not use their 
knowledge from 15 years ago; that beast has evolved. I'm not complaining 
about Python 1.0 either. And I wish Tcl would be used more often for 
large-scale programs, such that the idioms really develop.


	Christian

> [1] What is an etc() in Python?

Is this a quizzy question? I have no idea.

[toc] | [prev] | [next] | [standalone]

#62184 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On Tue, Dec 17, 2013 at 8:33 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> Am 16.12.13 23:40, schrieb Chris Angelico:
>> But my rule of thumb with bash scripts is: If it exceeds a page or
>> two in length, it's probably time it got rewritten in an application
>> language. When a program is the size of gitk (>10KLOC), the benefits
>> relating to interactive use (as you mention below) become less
>> significant, and benefits relating to discoverability of the more
>> obscure features become more significant.
>
> I do not know, whether bash has means to structure large programs, I suppose
> not. Tcl has (see below), and concerning discoverability, see also below.

You can create functions, which then effectively become new commands.
You can source (the . command) another file, which mostly is a
#include style of thing. But mainly, a bash script is doing exactly
what would happen at the interactive shell (modulo environment
differences - your interactive shell might well have a different $PATH
or something, but command execution still follows the same rules). If
I look at a bash script and see it execute "bc", I can type "man bc"
and have a reasonable chance of it being the same thing.

> In the gitk case, mc comes from these lines:
>
>         package require msgcat
>         namespace import ::msgcat::mc
>
> Now, be prepared: These lines do almost the same as
>
>         import msgcat
>         from msgcat import mc
>
> would do in Python.

Okay. Now that you've told me that, I can find those lines... down the
very bottom of the script. The first thing I did when trying to figure
this out was to go to the top of the file and search for "mc", and I
didn't find a definition.

In Python, it's conventional to put imports at the top, so this would
have worked. (Unless there's a "from x import *", but this is
precisely why that's frowned upon.) Is the convention different in
Tcl, or is gitk just laid out unhelpfully?

> You can't run Tk more than once, that applies to almost every toolkit I
> know. But you can pass a message to the main thread to do it for you. This
> is quite easy; it looks like
>
> thread::send -async $main [list doit $somedata]

Everything I ever did on OS/2 allowed GUI operations from multiple
threads. The C APIs, I think, were restricted to manipulating each
widget from the thread that created it (or at least, you could confuse
yourself thoroughly if you didn't; I always just stuck to "this
window, this thread"); VX-REXX allowed any thread to manipulate any
object belonging to that process. If you send a message to a widget,
its thread will handle it (and yours will block until you get a
response - or you can post a message, which doesn't block); this
functions the same whether it's a thread in your process or one in
another process.

> You pass an arbitrary Tcl command which executes in the main thread as soon
> as it is idle. In fact, because of the embedded event loop in Tcl (not bound
> to Tk), you rarely need threads at all. Asynchronous I/O is very easy in Tcl
> (fileevent command).

I learned to love async processing a couple of years ago with Pike.
You just return a negative number from main(), which normally has no
meaning, and it goes into a back-end event loop. (And there are other
ways to invoke the back-end.) That can then handle callbacks from
files/sockets, clock-based timeouts ("call this function in X
seconds"), GUI events, pretty much everything (except signals - they
interrupt everything else, as they should). It takes a bit of getting
your head around, if you're used to thread-based programming (as I had
been for a decade or so), but it's so convenient.

>> So there definitely are some advantages that Tcl has over Python. Put
>> against them is a superior object model, a large corpus of first-class
>> object types (dict, set, list, etc[1]), and a syntax that more clearly
>> differentiates names and strings without making variable references
>> look like a lot more than they are.

>> [1] What is an etc() in Python?
>
> Is this a quizzy question? I have no idea.

I mentioned four of Python's fundamental types: the dict, the set, the
list, and the etc. :)

> Lists and dicts exist in Tcl as first class objects. You just can't tell
> them apart from strings. Sets are in tcllib. Python is more strongly typed
> than Tcl in that respect, which can be an advantage. Specifically doing math
> is easier in an evaluation based syntax than in a command based syntax, this
> sometimes sucks in Tcl.

Having grown up with REXX, I completely understand the concept of
"everything is a string" (though REXX does have compound variables,
which aren't quite lists, aren't quite dicts, and aren't quite sets,
and definitely aren't quite multidimensional anything, but are their
own beast with unique semantics); and having since met Python and Pike
and other such languages, I prefer object semantics. The only
first-class type in REXX is the string; a compound variable is a
different sort of name, not a different sort of value, so you can't
actually pass an array as an argument. What you have to do is pass the
_name_ of the compound variable, so it's a lot fiddlier.

>> Huge room in the world for both languages to exist and thrive.
>
> Yes, you name it. I wish people who criticize Tcl would not use their
> knowledge from 15 years ago; that beast has evolved. I'm not complaining
> about Python 1.0 either. And I wish Tcl would be used more often for
> large-scale programs, such that the idioms really develop.

That's true of every language, but sometimes the community adopts
habits based on the early versions and those habits don't change.
Coding styles and best-practices are nearly as much a part of the
language ecosystem as semantics and standard library - a typical Ruby
application has piles and piles and PILES of dependencies (gems),
whereas a typical Python program will need maybe just a couple of
non-standard modules. Is that a fundamental difference between the
languages? Unless the Ruby standard library is positively minimalist,
I don't think it is. It's just the way the community works... which
changes very, very slowly. Maybe in 2015 there'll be a version of Ruby
with a hundred times as much in its stdlib as the current versions
have, but people will still use their favorite gems, because they're
used to them. Python programs will still tend to have shorter chains
of dots in their method calls than Java programs will have, even if
Python were to get compile-time lookups. C programs will still tend to
crash, even if C gets a refcounting garbage collector... hmm, that
one's already happened, and yep, still true. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#62119 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On 12/16/2013 5:40 PM, Chris Angelico wrote:

> Nice, though Python's threading and/or multiprocessing can do 90% of
> what people want. Side point: What about Tk? Can you (a) run separate
> GUI threads for separate windows? (b) manipulate widgets created by
> another thread?

When running tk via tkinter, limiting tkinter/tk calls to the main 
thread is the safest thing to do. I do not know whether the problems 
people have had doing otherwise are due to Python or inherent in tk itself.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#62148 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On 16/12/2013 22:06, Christian Gollwitzer wrote:
> Let the flame war begin!
>

Surely proper flame wars should have inflammatory titles like this 
https://archive.org/details/SeanKellyRecoveryfromAddiction ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62155

On Sunday, December 15, 2013 11:01:53 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 15 Dec 2013 14:53:45 +0000, Grant Edwards wrote:
> > On 2013-12-14, Steven D'Aprano wrote:
> >
> > You seem to be equating "was compiled from" with "includes an
> > implemenation of".  Do you say that CPython "ships with C"?
>
> Well, when you take my comments out of their context, that
> does seem to be a totally stupid thing to say. But in
> context, it's only *mostly* stupid, and mostly stupid
> means a little bit sensible *wink* The context was a
> complaint, or at least expression of surprise, that Python
> use Tcl for a GUI, this being contrasted with
> (paraphrasing the legions of people who have expressed
> surprise about this in the past) "some hypothetical GUI
> written in Python". But in practice, it won't be written
> in Python, it will be likely written in C or some other
> low-level language with some interface to Python. The main
> difference between this hypothetical "Python GUI" and Tcl
> is that Tcl is a Turing-complete interpreter which lives
> in it's own process.

And how many times would you take advantage of that "turning
complete" functionality in reality? My answer... ZERO! How
many Tcl calls have you, or anybody, made that did have
direct business with creating or managing a TK gui? HOW
MANY???

We don't need that functionality, we ALREADY have a
language... it's called Python and the syntax is MUCH
better. All we want is a damn GUI.

And trying to justify TCL as legit because "Tcl just calls C
routines" is ludicrous. If the intention is to extend C
routines, then by gawd EXTEND them. Don't go writing a whole
new turning complete monstrosity and forcing all calls to
travel through it's front door, sit in waiting room until
it's eyes bleed, before finally exiting out the back door on
it's way to "Cees-ville".

Why should i give a damn about Tcl? All it does is get in my
way. OTOH, if Tcl where more like a Vegas Casino for high
rollers, i might be inclined to overlook the "superfluous
pit-stop". A free luxury room , free all you can eat buffet,
free call girls, etc... but it has no endearing qualities.

[toc] | [prev] | [next] | [standalone]

#62156 — Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

On Tue, Dec 17, 2013 at 4:37 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> We don't need that functionality, we ALREADY have a
> language... it's called Python and the syntax is MUCH
> better. All we want is a damn GUI.
>
> And trying to justify TCL as legit because "Tcl just calls C
> routines" is ludicrous.

Python already ships with another language interpreter - actually,
several wrapped up into one. It's called the pickle module. There's
nothing fundamentally wrong with calling on another language; I was
just curious about it, is all.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62157

On 17/12/2013 05:37, Rick Johnson wrote:
>
> We don't need that functionality, we ALREADY have a
> language... it's called Python and the syntax is MUCH
> better. All we want is a damn GUI.
>

Then write it, dear Rick, dear Rick, dear Rick, then write it, dear 
Rick, dear Rick, write it.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62160

From all the toolkits, wxPython is probably the most
interesting. I used all versions from 2.0 (?) up to 2.8. Then
it has been decided to go unicode.

Let see in the wx interactive intepreter, it is only
the top of the iceberg. (Py27, wxPy294)

>>> len('ሴЃ')
5

---

It has alos been decided to rework wxPython and create
wxPhoenix, unicode of course.

Impossible to put a Python string correctly in a widget
supposed to handle text. The design mistake is more
deeper than in wx29 (unicode).

I do not know the present status, but as the mistake
is a consequence of a unicode non understanding (plus
a little bit Python, plus a little bit wxWidgets), I doubt
that some improvement happened.

I attempted to explain unicode...

jmf

[toc] | [prev] | [next] | [standalone]

#62166

On 17/12/2013 07:58, wxjmfauth@gmail.com wrote:
>  From all the toolkits, wxPython is probably the most
> interesting. I used all versions from 2.0 (?) up to 2.8. Then
> it has been decided to go unicode.
>
> Let see in the wx interactive intepreter, it is only
> the top of the iceberg. (Py27, wxPy294)
>
>>>> len('ሴЃ')
> 5
>
> ---
>
> It has alos been decided to rework wxPython and create
> wxPhoenix, unicode of course.
>
> Impossible to put a Python string correctly in a widget
> supposed to handle text. The design mistake is more
> deeper than in wx29 (unicode).
>
> I do not know the present status, but as the mistake
> is a consequence of a unicode non understanding (plus
> a little bit Python, plus a little bit wxWidgets), I doubt
> that some improvement happened.
>
> I attempted to explain unicode...
>
> jmf
>

wxPython 3 (Phoenix) will be the first version that supports Python 3. 
This will obviously mean that for the first time, wxPython will be able 
to take full advantage of the superb PEP393 Flexible String 
Representation (FSR) which is available in Python 3.3+.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62168

Le mardi 17 décembre 2013 09:33:24 UTC+1, Mark Lawrence a écrit :
> On 17/12/2013 07:58, wxjmfauth@gmail.com wrote:
> 
> >  From all the toolkits, wxPython is probably the most
> 
> > interesting. I used all versions from 2.0 (?) up to 2.8. Then
> 
> > it has been decided to go unicode.
> 
> >
> 
> > Let see in the wx interactive intepreter, it is only
> 
> > the top of the iceberg. (Py27, wxPy294)
> 
> >
> 
> >>>> len('ሴЃ')
> 
> > 5
> 
> >
> 
> > ---
> 
> >
> 
> > It has alos been decided to rework wxPython and create
> 
> > wxPhoenix, unicode of course.
> 
> >
> 
> > Impossible to put a Python string correctly in a widget
> 
> > supposed to handle text. The design mistake is more
> 
> > deeper than in wx29 (unicode).
> 
> >
> 
> > I do not know the present status, but as the mistake
> 
> > is a consequence of a unicode non understanding (plus
> 
> > a little bit Python, plus a little bit wxWidgets), I doubt
> 
> > that some improvement happened.
> 
> >
> 
> > I attempted to explain unicode...
> 
> >
> 
> > jmf
> 
> >
> 
> 
> 
> wxPython 3 (Phoenix) will be the first version that supports Python 3. 
> 
> This will obviously mean that for the first time, wxPython will be able 
> 
> to take full advantage of the superb PEP393 Flexible String 
> 
> Representation (FSR) which is available in Python 3.3+.
> 
> 
> 
> -- 
> 
> My fellow Pythonistas, ask not what our language can do for you, ask 
> 
> what you can do for our language.
> 
> 

I'm very happy for you.
You should at least serialized the tasks.

- wxPhoenix (wrapper of wxWidgets) is one thing
- wxPhoenix for Python3 / Python2 is something else
- Ditto for the FSR
- Ditto for "unicode"

For your information, that's at those times I decided
to have a look at the Qt derivatives, it was a very,
very good idea.

jmf

[toc] | [prev] | [next] | [standalone]

#62173

On 17/12/2013 09:18, wxjmfauth@gmail.com wrote:
> Le mardi 17 décembre 2013 09:33:24 UTC+1, Mark Lawrence a écrit :
>> On 17/12/2013 07:58, wxjmfauth@gmail.com wrote:
>>
>>>   From all the toolkits, wxPython is probably the most
>>
>>> interesting. I used all versions from 2.0 (?) up to 2.8. Then
>>
>>> it has been decided to go unicode.
>>
>>>
>>
>>> Let see in the wx interactive intepreter, it is only
>>
>>> the top of the iceberg. (Py27, wxPy294)
>>
>>>
>>
>>>>>> len('ሴЃ')
>>
>>> 5
>>
>>>
>>
>>> ---
>>
>>>
>>
>>> It has alos been decided to rework wxPython and create
>>
>>> wxPhoenix, unicode of course.
>>
>>>
>>
>>> Impossible to put a Python string correctly in a widget
>>
>>> supposed to handle text. The design mistake is more
>>
>>> deeper than in wx29 (unicode).
>>
>>>
>>
>>> I do not know the present status, but as the mistake
>>
>>> is a consequence of a unicode non understanding (plus
>>
>>> a little bit Python, plus a little bit wxWidgets), I doubt
>>
>>> that some improvement happened.
>>
>>>
>>
>>> I attempted to explain unicode...
>>
>>>
>>
>>> jmf
>>
>>>
>>
>>
>>
>> wxPython 3 (Phoenix) will be the first version that supports Python 3.
>>
>> This will obviously mean that for the first time, wxPython will be able
>>
>> to take full advantage of the superb PEP393 Flexible String
>>
>> Representation (FSR) which is available in Python 3.3+.
>>
>>
>>
>> --
>>
>> My fellow Pythonistas, ask not what our language can do for you, ask
>>
>> what you can do for our language.
>>
>>
>
> I'm very happy for you.
> You should at least serialized the tasks.
>
> - wxPhoenix (wrapper of wxWidgets) is one thing
> - wxPhoenix for Python3 / Python2 is something else
> - Ditto for the FSR
> - Ditto for "unicode"
>
> For your information, that's at those times I decided
> to have a look at the Qt derivatives, it was a very,
> very good idea.
>
> jmf
>

I haven't the faintest idea what your words above are meant to mean. 
Your communication skills are clearly lacking, as you also still insist 
on sending us double spaced google crap.  Do you not understand the 
instructions here https://wiki.python.org/moin/GoogleGroupsPython ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62169

On Mon, 16 Dec 2013 23:58:15 -0800, wxjmfauth wrote:

> From all the toolkits, wxPython is probably the most interesting. I used
> all versions from 2.0 (?) up to 2.8. Then it has been decided to go
> unicode.
> 
> Let see in the wx interactive intepreter, it is only the top of the
> iceberg. (Py27, wxPy294)
> 
>>>> len('ሴЃ')
> 5


What does that have to do with wxPython? It looks like you're just mis-
using Python 2.7.

In Python 2.7, 'ሴЃ' is not a Unicode string, it is a byte string. The 
exact bytes you get are not well-defined but on many systems you may get 
a UTF-8 encoded byte string:


py> sys.version
'2.7.4 (default, Apr 18 2013, 17:48:59) \n[GCC 4.4.5]'
py> for b in 'ሴЃ':
...     print hex(ord(b)), b
... 
0xe1 
0x88 �
0xb4 �
0xd0 
0x83 �


If you use a Unicode string instead:

py> for c in u'ሴЃ':
...     print hex(ord(c)), c
... 
0x1234 ሴ
0x403 Ѓ

py> for b in u'ሴЃ'.encode('utf-8'):
...     print hex(ord(b)), b
... 
0xe1 
0x88 �
0xb4 �
0xd0 
0x83 �



Even if it is true that wxPython cannot handle Unicode text, you haven't 
shown it here.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#62172

On 17/12/2013 09:29, Steven D'Aprano wrote:
>
> Even if it is true that wxPython cannot handle Unicode text, you haven't
> shown it here.
>

Personally I am convinced that wxPython can't handle unicode for the 
simple reason that it doesn't yet support Python 3 and we all know that 
Python 2 and unicode don't mix.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62179

On Tue, 17 Dec 2013 09:39:06 +0000, Mark Lawrence wrote:

> Personally I am convinced that wxPython can't handle unicode for the
> simple reason that it doesn't yet support Python 3 and we all know that
> Python 2 and unicode don't mix.

I don't think this is right. The Unicode support in Python 2 isn't as 
good as in Python 3, but it is still pretty good. You just have to 
remember to use the u prefix on your strings.

If it is true that wxPython cannot handle Unicode -- and I see no 
evidence that this is correct -- then it is due to the underlying wx* 
library, not Python 2.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#62183

On 2013-12-17 11:13, Steven D'Aprano wrote:
> On Tue, 17 Dec 2013 09:39:06 +0000, Mark Lawrence wrote:
>
>> Personally I am convinced that wxPython can't handle unicode for the
>> simple reason that it doesn't yet support Python 3 and we all know that
>> Python 2 and unicode don't mix.
>
> I don't think this is right. The Unicode support in Python 2 isn't as
> good as in Python 3, but it is still pretty good. You just have to
> remember to use the u prefix on your strings.
>
> If it is true that wxPython cannot handle Unicode -- and I see no
> evidence that this is correct --

It most certainly is not. wxPython has handled Unicode (via `unicode` strings) 
for many, many years now.

-- 
Robert Kern

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web