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

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

Exploring Python for next desktop GUI Project

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

Contents

  Exploring Python for next desktop GUI Project Noble Bell <noblebell@gmail.com> - 2014-07-24 08:57 -0700
    Re: Exploring Python for next desktop GUI Project INADA Naoki <songofacandy@gmail.com> - 2014-07-25 01:20 +0900
    Re: Exploring Python for next desktop GUI Project Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-07-24 11:22 -0500
      Re: Exploring Python for next desktop GUI Project Grant Edwards <invalid@invalid.invalid> - 2014-07-24 16:37 +0000
        Re: Exploring Python for next desktop GUI Project Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-07-24 13:17 -0500
    Re: Exploring Python for next desktop GUI Project Chris Angelico <rosuav@gmail.com> - 2014-07-25 02:18 +1000
    Re: Exploring Python for next desktop GUI Project Noble Bell <noblebell@gmail.com> - 2014-07-24 09:29 -0700
      Re: Exploring Python for next desktop GUI Project Chris Angelico <rosuav@gmail.com> - 2014-07-25 02:46 +1000
      Re: Exploring Python for next desktop GUI Project Michael Torrie <torriem@gmail.com> - 2014-07-24 15:38 -0600
    Re: Exploring Python for next desktop GUI Project Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-07-24 19:04 +0200
    Re: Exploring Python for next desktop GUI Project Chris Angelico <rosuav@gmail.com> - 2014-07-25 03:09 +1000
    Re: Exploring Python for next desktop GUI Project Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-24 19:04 +0100
    Re: Exploring Python for next desktop GUI Project Chris Angelico <rosuav@gmail.com> - 2014-07-25 04:15 +1000
    Re: Exploring Python for next desktop GUI Project Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-07-24 13:33 -0500
      Re: Exploring Python for next desktop GUI Project Grant Edwards <invalid@invalid.invalid> - 2014-07-24 21:17 +0000
    Re: Exploring Python for next desktop GUI Project Chris Angelico <rosuav@gmail.com> - 2014-07-25 04:51 +1000
      Re: Exploring Python for next desktop GUI Project Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-25 10:28 +1200
    Re: Exploring Python for next desktop GUI Project Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-07-24 21:02 +0200
      Re: Exploring Python for next desktop GUI Project Grant Edwards <invalid@invalid.invalid> - 2014-07-24 21:24 +0000
    Re: Exploring Python for next desktop GUI Project Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-07-24 14:10 -0500
    Re: Exploring Python for next desktop GUI Project Glenn Linderman <v+python@g.nevcal.com> - 2014-07-24 12:11 -0700
    Re: Exploring Python for next desktop GUI Project Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-24 13:32 -0600
      Re: Exploring Python for next desktop GUI Project Noble Bell <noblebell@gmail.com> - 2014-07-24 13:10 -0700
        Re: Exploring Python for next desktop GUI Project Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-07-24 13:46 -0700
    Re: Exploring Python for next desktop GUI Project Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-07-24 15:13 -0500
    Re: Exploring Python for next desktop GUI Project Michael Torrie <torriem@gmail.com> - 2014-07-24 15:24 -0600
    Re: Exploring Python for next desktop GUI Project Michael Torrie <torriem@gmail.com> - 2014-07-24 15:29 -0600
    Re: Exploring Python for next desktop GUI Project Michael Torrie <torriem@gmail.com> - 2014-07-24 15:32 -0600
    Re: Exploring Python for next desktop GUI Project ismeal shanshi <stuffstorehouse2014@gmail.com> - 2014-07-24 14:44 -0700
    Re: Exploring Python for next desktop GUI Project Terry Reedy <tjreedy@udel.edu> - 2014-07-24 19:25 -0400
      Re: Exploring Python for next desktop GUI Project wxjmfauth@gmail.com - 2014-07-26 00:48 -0700
    Re: Exploring Python for next desktop GUI Project Terry Reedy <tjreedy@udel.edu> - 2014-07-24 19:35 -0400
      Re: Exploring Python for next desktop GUI Project Noble Bell <noblebell@gmail.com> - 2014-07-25 06:37 -0700
    Re: Exploring Python for next desktop GUI Project Sturla Molden <sturla.molden@gmail.com> - 2014-07-25 20:04 +0000
    Re: Exploring Python for next desktop GUI Project CM <cmpython@gmail.com> - 2014-07-27 10:53 -0700
      Re: Exploring Python for next desktop GUI Project pecore@pascolo.net - 2014-07-29 00:00 +0200
        Re: Exploring Python for next desktop GUI Project Roy Smith <roy@panix.com> - 2014-07-28 18:01 -0400
          Re: Exploring Python for next desktop GUI Project pecore@pascolo.net - 2014-07-29 21:47 +0200

Page 2 of 2 — ← Prev page 1 [2]

#75173

[Multipart message — attachments visible in raw view] — view raw

On 7/24/2014 11:15 AM, Chris Angelico wrote:
> On Fri, Jul 25, 2014 at 4:04 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 24/07/2014 17:18, Chris Angelico wrote:
>>> The first one is certainly possible. Pick any of the well-known
>>> toolkits (Tkinter, wxwidgets, GTK, etc), and see how it feels. All of
>>> them are portable across the three platforms you name, so see which
>>> one is most comfortable for you to code in and produces the best
>>> results.
>>
>> s/wxwidgets/wxpython/ unless you fancy wrapping it yourself :)
>>
> Yeah that. And pygtk rather than GTK. Or I could have gone the other
> way and said Tk instead of Tkinter. One way or another, I ought to
> have been more consistent. Anyway. Pick a good toolkit, get to know
> it, and use it. Personally, I like GTK, but that's partly because its
> bindings come with Pike, and I did GUI work with Pike before I did
> with Python; the same advantage, for someone starting with Python,
> goes to Tk. But the main thing is, it's easy to be cross-platform -
> take whatever feels good to you.
>
> ChrisA
Not knowing any of these GUI platforms (although I've read some about 
Tk), I have some questions.

* Which of them use UTF-8 as their native Unicode interface?

* Which makes it easiest to discover and adjust font metrics such as 
kerning?

* Which makes it easiest to obtain bounding rectangles of a piece of text?

* Which makes it easiest to use a set of fonts such as Times (for Latin) 
and others for Cyrillic, Chinese, and Korean? Or which supplies a font 
configuration that can "just be used" for any language?

Glenn

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

#75174

On Thu, Jul 24, 2014 at 1:02 PM, Chris “Kwpolska” Warrick
<kwpolska@gmail.com> wrote:
> AFAIK, Qt follows the system style properly, and it looks quite native
> on every Windows OS.  No idea about ttk though.

My understanding is that Qt merely emulates the native LAF, although
it does a good job of it. wxPython on the other hand actually uses
native widgets wherever possible.

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

#75175

On Thursday, July 24, 2014 2:32:04 PM UTC-5, Ian wrote:
> On Thu, Jul 24, 2014 at 1:02 PM, Chris "Kwpolska" Warrick
> 
> <kwpolska@gmail.com> wrote:
> 
> > AFAIK, Qt follows the system style properly, and it looks quite native
> 
> > on every Windows OS.  No idea about ttk though.
> 
> 
> 
> My understanding is that Qt merely emulates the native LAF, although
> 
> it does a good job of it. wxPython on the other hand actually uses
> 
> native widgets wherever possible.

If I were to us wxPython then I would be limited to Python 2.x at present. If I were to use PyQt I would have to pay, as I understand the licenses, for it to use in commercial programs and/or programs that I ask for donations. If I am not mistaken PyQT is available for Python 3. I am not familiar with PySide much other than I have heard, though, it is not being updated anymore.

Coming from development experience in Java I know how notorious and ugly GUI programming can be at times.

Doing development work at my day job in java/.net I just wanted to use something at home to tinker around with and do some hobby programming and perhaps sell something or such if I develop something useful. Python has struck my fancy.

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

#75179

On Thu, 24 Jul 2014 13:10:03 -0700 (PDT)
Noble Bell <noblebell@gmail.com> wrote:
> 
> If I were to us wxPython then I would be limited to Python 2.x at present. If I were to use PyQt I would have to pay, as I understand the licenses, for it to use in commercial programs and/or programs that I ask for donations. If I am not mistaken PyQT is available for Python 3. I am not familiar with PySide much other than I have heard, though, it is not being updated anymore.
> 

I specifically switched from using wxPython to PySide when I decided
that I didn't want to keep building up more and more of my codebase on
Python 2.x., and didn't feel like wxPython Phoenix was ready for prime
time.

To the best of my knowledge, PySide is still under active
development, including as the day job for Robin Dunn, the lead
developer of wxPython.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#75176

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 24, 2014 at 2:02 PM, Chris “Kwpolska” Warrick
<kwpolska@gmail.com> wrote:
> Pretty much everyone in the world hates Tcl and Tk.  Ask your favorite
> search engine for some results.

Whee, I'm an alien! ;)

I'm not saying Tk is the best thing since sliced bread, I just don't
see what so many people seem to hate about it.

> i’ve tried to write a Tkinter thing once.  I don’t have a copy anymore
> (consciously deleted), but I vaguely remember some issues with widgets
> that do not work.  I also remember that the list of widgets is quite
> small and not enough for many projects.

I have had no issues with widgets not working.  I will admit that the
widget set is fairly small, though.  You can get more from Tix (which
is also distributed with tkinter), but I haven't had any need for that
yet.

> The best way to handle this is just choose one of the two (wxwidgets
> chose GTK 2, for example) and be considered native enough by most, as
> people don’t really mind mixing them (as there are no good Qt web
> browsers, and VLC uses Qt and not GTK)

That's fair, and I agree that Tk should probably provide "close to
GTK" and "close to QT" themes for ttk[1].  As I understand it, though,
ttk gives almost complete control over the look of individual widgets,
so if you really don't like how your widget looks, change it!

> ttk on Linux doesn’t change a thing.  It still uses the ugly, ancient,
> motif-esque style:
>
> https://www.google.com/search?q=tk+linux&tbm=isch
>
> (also, off by 10 years, motif is actually from the 1980s.)

Motif is indeed ugly, but your search for 'tk linux' doesn't tell me
anything about 'ttk linux'.  I would be interested in the results of
the script below on Linux, which I may or may not be able to try for
myself later (but can't right now).

-- 
Zach

[1] Such themes might already exist, I haven't checked.  If anyone
wants to see what themes are available and how they look, try this
(2/3 compatible, also attached in case Gmail messes it up):


import sys

try:
    import tkinter as tk
    from tkinter import ttk
except ImportError:
    import Tkinter as tk
    import ttk

class App(object):
    def __init__(self, root):
        self.root = root
        self.root.title('Theme tester')
        self.info_label = ttk.Label(self.root,
            text="Python {}.{} with Tcl/Tk {} on {}".format(
                sys.version_info[0], sys.version_info[1],
                self.root.tk.eval('info patchlevel'),
                sys.platform))
        self.info_label.pack()
        self.theme_idx = 0
        self.change_btn = ttk.Button(self.root,
                                     text='Change theme',
                                     command=self.change_theme
                                     )
        self.change_btn.pack()
        self.rb_var = tk.StringVar(self.root)
        self.radiobtn = ttk.Radiobutton(self.root,
                                        text='Radio button option 1',
                                        variable=self.rb_var,
                                        value='1')
        self.radiobtn.pack()
        self.radiobtn2 = ttk.Radiobutton(self.root,
                                         text='Radio button option 2',
                                         variable=self.rb_var,
                                         value='2')
        self.radiobtn2.pack()
        self.checkbtn = ttk.Checkbutton(self.root, text='Checkbutton')
        self.checkbtn.pack()
        self.entry = ttk.Entry(self.root)
        self.entry.insert(0, 'Entry')
        self.entry.pack()

        self.style = ttk.Style(self.root)
        self.available_themes = self.style.theme_names()

        self.theme_label = ttk.Label(self.root, text='Platform default')
        self.theme_label.pack()

    def change_theme(self):
        try:
            theme = self.available_themes[self.theme_idx]
        except IndexError:
            theme = self.available_themes[0]
            self.theme_idx = 0
        self.style.theme_use(theme)
        self.theme_label.configure(text=theme)

        self.theme_idx += 1

root = tk.Tk()
app = App(root)
root.mainloop()

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

#75182

On 07/24/2014 01:11 PM, Glenn Linderman wrote:
> Not knowing any of these GUI platforms (although I've read some about 
> Tk), I have some questions.
> 
> * Which of them use UTF-8 as their native Unicode interface?
> 
> * Which makes it easiest to discover and adjust font metrics such as 
> kerning?
> 
> * Which makes it easiest to obtain bounding rectangles of a piece of text?
> 
> * Which makes it easiest to use a set of fonts such as Times (for Latin) 
> and others for Cyrillic, Chinese, and Korean? Or which supplies a font 
> configuration that can "just be used" for any language?

Given these new requirements, I think Qt with either PyQt or PySide is
really your only choice.  See the official Qt docs (C++, but same API
and will give you an idea of what's possible):
http://qt-project.org/doc/ .  Qt is probably the best documented of any
GUI framework.  On Windows and Mac it uses the native widget drawing
dlls so things appear native.  Making them feel native will require some
attention on your part, though. For example dialog ttgbutton order,
though I think there are convenience functions for doing that.  Qt is
fully unicode throughout.  Don't worry about what encoding is used
behind the scenes generally.  You can encode to UTF-8 when writing bytes
out, and decode from UTF-8 when reading bytes in.

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

#75183

On 07/24/2014 12:51 PM, Chris Angelico wrote:
> On Fri, Jul 25, 2014 at 4:33 AM, Zachary Ware
> <zachary.ware+pylist@gmail.com> wrote:
>>> On other platforms, it also is not 100%
>>> native.
>>
>> On Windows, at least, ttk comes very very close to it.
> 
> What exactly does that mean? The Windows default UI changed
> significantly from W2K -> XP -> Win8, and each time, it's possible to
> revert to the old styling; does ttk follow the rest of the OS in that?
> And if so, does it achieve that by restricting you to a vicious subset
> of functionality that can actually be implemented natively, or does it
> try to reimplement as appropriate?

ttk, like Qt, uses the MS theming dll to do the widget drawing (buttons,
check boxes, etc).  So everything looks native.

As for actually being native, well, that means less and less every
passing year.  Windows applications use a plethora of GUI toolkits these
days.  In the old days everyone used what Win32 provided.  Then MS
started doing their own widgets in MS Office because the native ones are
a subset of desired functionality modern apps demands.  That opened the
flood gates.

So now many programs draw and control their own widgets.  It has led to
a certain amount of inconsistency, perhaps worse than we have in Linux.
 And some apps don't even bother with trying to look native anymore,
like a lot of antivirus, antimalware, and system optimization programs
(such as Advanced System Care).

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

#75184

On 07/24/2014 01:32 PM, Ian Kelly wrote:
> On Thu, Jul 24, 2014 at 1:02 PM, Chris “Kwpolska” Warrick
> <kwpolska@gmail.com> wrote:
>> AFAIK, Qt follows the system style properly, and it looks quite native
>> on every Windows OS.  No idea about ttk though.
> 
> My understanding is that Qt merely emulates the native LAF, although
> it does a good job of it. wxPython on the other hand actually uses
> native widgets wherever possible.

As I said previously in this thread, honestly this doesn't matter
anymore.  Even MS doesn't use native widgets in their own software.  Any
widget set worth its salt will draw using the theming dll so things look
consistent, but whether or not an app feels right depends on the
programmer.  Use the correct button order for the platform, the right
keyboard shortcuts, the right default button in dialog box behavior,
etc, and you'll do quite well.  OS X is a bit of a special case, but Qt
can be made to fit fairly well on OS X.

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

#75186

Herion, Ketamine,Actavis promethazine codeine 16oz and 32oz available Ketamine Oxycontine Hydrocodone xanax and medicated marijuana US- free shipping and other related products for sell at competitive prices.We do world wide shipping to any clear address.Delivery is 100% safe due to our discreetness and experience.Try our quality and experience then have a story to tell another day.

Email Address:stuffstorehouse2014 (AT) gmail.com
CONTACT NUMBER: (407)-4852249 ***** Pleas text me only

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

#75189

On 7/24/2014 3:11 PM, Glenn Linderman wrote:

> Not knowing any of these GUI platforms (although I've read some about
> Tk), I have some questions.
>
> * Which of them use UTF-8 as their native Unicode interface?

tk uses UCS-2 internally for the BMP subset. It does not display astral 
chars. tkinter iterfaces via with Python strings.

> * Which makes it easiest to discover and adjust font metrics such as
> kerning?

I believe tk can use whatever fonts are on the system. Idle gives me a 
choice of more than I want to look at.

Tk does kerning with proportional fonts, but I believe info and control 
is not user acccessible. The main available metrics are max ascender and 
descender sizes, for interline spacing.

> * Which makes it easiest to obtain bounding rectangles of a piece of text?

The Text.bbox(index) returns the bounding rectangle for a character. 
Those can be combined as desired.

> * Which makes it easiest to use a set of fonts such as Times (for Latin)
> and others for Cyrillic, Chinese, and Korean? Or which supplies a font
> configuration that can "just be used" for any language?

'any language' requires a nearly complete unicode font. One can tag 
character sequences, and configure properties, including color and font, 
that override the widget defaults. This is how Idle colorizes Python 
code by syntax category. One could just as easily tag by language or by 
alphabet.

-- 
Terry Jan Reedy

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

#75239

Le vendredi 25 juillet 2014 01:25:55 UTC+2, Terry Reedy a écrit :
[...]
> 
> 
> 
> 'any language' requires a nearly complete unicode font.
[...]


Not really.

A positive consequence of unicode is certainly to
be found in the font technology.
For plenty of reasons, fonts are becoming specialized
and luckily these specialization features are embeded in
the fonts.

The fonts may also satisfy a standard: pan-european,
MES-N, ...

D:\jm>otfinfo.exe -s c:\windows\fonts\consola.ttf
cyrl            Cyrillic
cyrl.SRB        Cyrillic/Serbian
grek            Greek
latn            Latin
latn.IPPH       Latin/Phonetic transcription--IPA conventions
latn.ROM        Latin/Romanian
latn.TRK        Latin/Turkish


D:\jm>otfinfo.exe -s d:\jm\BundesSans-Regular.otf
DFLT            Default
cyrl            Cyrillic
grek            Greek
latn            Latin
latn.AZE        Latin/Azeri
latn.CRT        Latin/Crimean Tatar
latn.MOL        Latin/Moldavian
latn.ROM        Latin/Romanian
latn.TRK        Latin/Turkish


To my knowledge, the most complete font:
(Usable to display code points/glyphs, not usable to work
with.)

D:\jm>otfinfo.exe -s c:\windows\fonts\ARIALUNI.ttf
arab            Arabic
arab.FAR        Arabic/Farsi
arab.URD        Arabic/Urdu
deva            Devanagari
gujr            Gujarati
guru            Gurmukhi
hani            CJK Ideographic
hani.JAN        CJK Ideographic/Japanese
hani.KOR        CJK Ideographic/Korean
hani.ZHS        CJK Ideographic/Chinese Simplified
hani.ZHT        CJK Ideographic/Chinese Traditional
kana            Hiragana/Katakana
kana.JAN        Hiragana/Katakana/Japanese
knda            Kannada
taml            Tamiljmf


jmf

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

#75190

On 7/24/2014 1:04 PM, Chris “Kwpolska” Warrick wrote:

> And it might be better to stay with Python 2, there are still
> things that don't work with Py3k that you might find crucial.

It is true that there are 3rd-party modules that do not work with 3.x, 
including a few that one might want to use is a new project.

It is also true that there are language features in 3.4 that do not work 
with 2.x, or 3.2- or 3.3, including some that one might want to use in a 
new project.  For instance, Unicode works much better in 3.3 than in any 
version before. That is *only* available in 3.3+.

And it is true that there are 'feature' still in 2.7 that do not work in 
3.x.  But these are mostly nuisances that we are better of without.

-- 
Terry Jan Reedy

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

#75203

On Thursday, July 24, 2014 6:35:02 PM UTC-5, Terry Reedy wrote:
> On 7/24/2014 1:04 PM, Chris "Kwpolska" Warrick wrote:
> 
> 
> 
> > And it might be better to stay with Python 2, there are still
> 
> > things that don't work with Py3k that you might find crucial.
> 
> 
> 
> It is true that there are 3rd-party modules that do not work with 3.x, 
> 
> including a few that one might want to use is a new project.
> 
> 
> 
> It is also true that there are language features in 3.4 that do not work 
> 
> with 2.x, or 3.2- or 3.3, including some that one might want to use in a 
> 
> new project.  For instance, Unicode works much better in 3.3 than in any 
> 
> version before. That is *only* available in 3.3+.
> 
> 
> 
> And it is true that there are 'feature' still in 2.7 that do not work in 
> 
> 3.x.  But these are mostly nuisances that we are better of without.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

I would like to thank everyone for their insights. You all have been most helpful. I believe that I am going to start out using Tk and Python 3.x and see where that leads me. If I find that I don't like it I will try PySide. I intend on messing around with PyGame and Django in the future as well.

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

#75210

Zachary Ware <zachary.ware+pylist@gmail.com> wrote:

> How so?  Like any other facet of programming, using Tk(inter) has it's
> frustrations, but for the most part it has always worked as expected
> for me.  Granted, I haven't done anything terribly fancy.

In my experience, tkinter and ttk is fine until you need to do something
more advanced, like using OpenGL or creating custom controls. Then it
starts to suck incredibly.

Sturla

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

#75273

On Thursday, July 24, 2014 11:57:22 AM UTC-4, Noble Bell wrote:
> I am exploring the idea of creating my next desktop GUI project in Python and would like a little advice from you folks about a couple of requirements.
> 
> 
> 
> My requirements will be:
> 
> 1. Needs to be portable across platforms with native LAF (Windows,Linux,OSX)

wxPython.

> 2. Python 2 or 3? Which will serve me better in the future?

Long term (7 years), 3.  Middle-term, either, though you may need a library that is not yet ported to 3.  wxPython Phoenix is available in a not-yet-completely-done way and people are reporting using it to make function GUIs. It is not done yet, though, and some/all of the wx.lib widgets are not available in it. 

If I were you I'd go with Python 2.7 and wxPython 2.9.x, but other options are reasonable too.
> 
> 
> Thanks in advance.
> 
> Noble

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

#75330

>> 2. Python 2 or 3? Which will serve me better in the future?
>
> Long term (7 years), [Python] 3.

I have STRONG suicidal intent and no access to treatment,
should I better learn Python 2?

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

#75331

In article <87mwbtjg9r.fsf@pascolo.net>, pecore@pascolo.net wrote:

> >> 2. Python 2 or 3? Which will serve me better in the future?
> >
> > Long term (7 years), [Python] 3.
> 
> I have STRONG suicidal intent and no access to treatment,
> should I better learn Python 2?

In that case, go with PHP.

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

#75355

Roy Smith <roy@panix.com> writes:

> In article <87mwbtjg9r.fsf@pascolo.net>, pecore@pascolo.net wrote:
>
>> >> 2. Python 2 or 3? Which will serve me better in the future?
>> >
>> > Long term (7 years), [Python] 3.
>> 
>> I have STRONG suicidal intent and no access to treatment,
>> should I better learn Python 2?
>
> In that case, go with PHP.

ah, well said! but I went with PHP already and look at me now!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web