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

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

Python discussed in Nature

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

Contents

  Python discussed in Nature Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-12 19:46 +1100
    Re: Python discussed in Nature Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-12 09:19 +0000
    Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-12 01:31 -0800
      Re: Python discussed in Nature Fabien <fabien.maussion@gmail.com> - 2015-02-12 12:07 +0100
        Re: Python discussed in Nature Marko Rauhamaa <marko@pacujo.net> - 2015-02-12 13:25 +0200
          Re: Python discussed in Nature Fabien <fabien.maussion@gmail.com> - 2015-02-12 12:33 +0100
            Re: Python discussed in Nature Marko Rauhamaa <marko@pacujo.net> - 2015-02-12 16:39 +0200
              Re: Python discussed in Nature Chris Angelico <rosuav@gmail.com> - 2015-02-13 02:59 +1100
                Re: Python discussed in Nature Marko Rauhamaa <marko@pacujo.net> - 2015-02-12 18:56 +0200
                  Re: Python discussed in Nature Chris Angelico <rosuav@gmail.com> - 2015-02-13 04:08 +1100
                  Re: Python discussed in Nature Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-13 14:07 +1100
              Re: Python discussed in Nature Sturla Molden <sturla.molden@gmail.com> - 2015-02-13 23:58 +0100
                Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-14 00:39 -0800
        Re: Python discussed in Nature John Ladasky <john_ladasky@sbcglobal.net> - 2015-02-12 10:29 -0800
          Re: Python discussed in Nature Chris Angelico <rosuav@gmail.com> - 2015-02-13 05:37 +1100
            Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-13 02:03 -0800
          Re: Python discussed in Nature Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-13 14:11 +1100
            Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-12 23:05 -0800
            Re: Python discussed in Nature John Ladasky <john_ladasky@sbcglobal.net> - 2015-02-13 11:40 -0800
              Re: Python discussed in Nature Chris Angelico <rosuav@gmail.com> - 2015-02-14 09:45 +1100
                Re: Python discussed in Nature giacomo boffi <pecore@pascolo.net> - 2015-02-15 22:09 +0100
                  Re: Python discussed in Nature Chris Angelico <rosuav@gmail.com> - 2015-02-16 09:16 +1100
          Re: Python discussed in Nature Rustom Mody <rustompmody@gmail.com> - 2015-02-12 20:07 -0800
            Re: Python discussed in Nature Terry Reedy <tjreedy@udel.edu> - 2015-02-13 00:24 -0500
            Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-12 23:02 -0800
              Re: Python discussed in Nature wxjmfauth@gmail.com - 2015-02-13 01:36 -0800
    Re: Python discussed in Nature Ethan Furman <ethan@stoneleaf.us> - 2015-02-12 10:48 -0800

Page 1 of 2  [1] 2  Next page →

#85571 — Python discussed in Nature

"Nature", one of the world's premier science journals, has published an 
excellent article about programming in Python:

http://www.nature.com/news/programming-pick-up-python-1.16833


-- 
Steve

[toc] | [next] | [standalone]

#85572

On 12/02/2015 08:46, Steven D'Aprano wrote:
> "Nature", one of the world's premier science journals, has published an
> excellent article about programming in Python:
>
> http://www.nature.com/news/programming-pick-up-python-1.16833
>

Interesting.  I'll leave someone more diplomatic than myself to reply to 
the comment at the end of the article.

-- 
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]

#85573

Le jeudi 12 février 2015 09:46:52 UTC+1, Steven D'Aprano a écrit :
> "Nature", one of the world's premier science journals, has published an 
> excellent article about programming in Python:
> 
> http://www.nature.com/news/programming-pick-up-python-1.16833
> 
> 
> -- 
> Steve

D:\>c:\python35\python.exe
Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb  7 2015, 17:58:38) [MSC v.1900 32 bit
 (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('abcoeé EURO')


D:\>echo 'abcéoe EURO' crash
'abcéoe EURO' crash

D:\>

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

#85574

On 12.02.2015 10:31, wxjmfauth@gmail.com wrote:
[some OT stuffs about unicode]

... what a coincidence then that a huge majority of scientists 
(including me) dont care AT ALL about unicode. But since scientists are 
not paid to rewrite old code, the scientific world is still stuck to 
python 2. It's a pitty, given how easy it is to write py2/py3 compatible 
scientific tools.

Thanks for the link to the article steven!

Fabien

(sorry for the OT & sorry for feeding the t....)

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

#85575

Fabien <fabien.maussion@gmail.com>:

> ... what a coincidence then that a huge majority of scientists
> (including me) dont care AT ALL about unicode.

You shouldn't, any more than you care about ASCII or 2's-complement
encoding. Things should just work.

> But since scientists are not paid to rewrite old code, the scientific
> world is still stuck to python 2. It's a pitty, given how easy it is
> to write py2/py3 compatible scientific tools.

What's a pity is that Python3 chose to ignore the seamless transition
path. It would have been nice, for example, to have all Python 3 code
explicitly mark its dialect (a .py3 extension, a magic import or
something) and then allow legacy Py2 code and Py3 code coexist the same
way C and C++ can coexist.


Marko

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

#85576

On 12.02.2015 12:25, Marko Rauhamaa wrote:
> Fabien<fabien.maussion@gmail.com>:
>
>> >... what a coincidence then that a huge majority of scientists
>> >(including me) dont care AT ALL about unicode.
> You shouldn't, any more than you care about ASCII or 2's-complement
> encoding. Things should just work.

And they do! Since almost one year in writing scientific python code, 
not a single problem. I wouldnt even know about issues if i didnt read 
some posts here.

>> >But since scientists are not paid to rewrite old code, the scientific
>> >world is still stuck to python 2. It's a pitty, given how easy it is
>> >to write py2/py3 compatible scientific tools.
> What's a pity is that Python3 chose to ignore the seamless transition
> path. It would have been nice, for example, to have all Python 3 code
> explicitly mark its dialect (a .py3 extension, a magic import or
> something) and then allow legacy Py2 code and Py3 code coexist the same
> way C and C++ can coexist.

But this was exactly my point! Today in 2015 it's incredibly easy to 
write py2/py3 code for a scientist. The whole SciPy track has done the 
transition. Not an issue anymore either, for me at least (python 
youngster ;-)

Fabien

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

#85583

Fabien <fabien.maussion@gmail.com>:

> But this was exactly my point! Today in 2015 it's incredibly easy to
> write py2/py3 code for a scientist. The whole SciPy track has done the
> transition. Not an issue anymore either, for me at least (python
> youngster ;-)

I write both Py2 and Py3 code, but I keep the two worlds hermetically
separated from each other.


Marko

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

#85586

On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Fabien <fabien.maussion@gmail.com>:
>
>> But this was exactly my point! Today in 2015 it's incredibly easy to
>> write py2/py3 code for a scientist. The whole SciPy track has done the
>> transition. Not an issue anymore either, for me at least (python
>> youngster ;-)
>
> I write both Py2 and Py3 code, but I keep the two worlds hermetically
> separated from each other.

One of my students wrote some code for Python 3, and when I went to
test it, I typed 'python scriptname' out of habit (most of my students
use Py2)... and it almost perfectly worked. The only part that didn't
was a class definition that didn't explicitly subclass object, and
then used @property. Just changing that class declaration would have
made his code 2/3 compatible - and he didn't put any effort into it at
all. He literally made his code *accidentally*
(almost-)Py2-compatible.

You don't need to be afraid of the gap.

ChrisA

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

#85590

Chris Angelico <rosuav@gmail.com>:

> On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> I write both Py2 and Py3 code, but I keep the two worlds hermetically
>> separated from each other.
>
> [...]
>
> You don't need to be afraid of the gap.

No problem. When I write Py3, I write Py3. When I write Py2, I write
Py2. When I write bash, I write bash. When I write C, I write C.

Who's afraid of the Big Bad Wolf:

========================================================================
$ python3
Python 3.4.1 (default, Nov  3 2014, 14:38:10) 
[GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path = [ '/usr/lib64/python2.7' ] + sys.path
>>> import re
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/re.py", line 240
    raise TypeError, "first argument must be string or compiled pattern"
                   ^
SyntaxError: invalid syntax
>>> import xmllib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/xmllib.py", line 813
    print 'xml: encoding =',encoding,'standalone =',standalone
                          ^
SyntaxError: invalid syntax
========================================================================


Marko

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

#85593

On Fri, Feb 13, 2015 at 3:56 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> $ python3
> Python 3.4.1 (default, Nov  3 2014, 14:38:10)
> [GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.path = [ '/usr/lib64/python2.7' ] + sys.path

Interesting for intellectual curiosity, but not particularly
significant. All you prove is that the 2.7 stdlib is designed for
compatibility with older 2.x Pythons (or, looking the other way,
nobody wants pointless code churn in working code).

The best way to write 2/3 compatible code is to write 3.x code first.
Then just adhere to a few simple rules (eg always subclass object),
and the bulk of your code will work just fine. You might need to toss
in some explicit __future__ directives (print_function if you don't
stick to "exactly one string argument to print", and division if you
don't want to have to worry about the differences), and if you do this
a lot, you might want to pick up the 'six' library or equivalent, but
other than that, there's really not much to deal with.

ChrisA

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

#85624

Marko Rauhamaa wrote:

> Chris Angelico <rosuav@gmail.com>:
> 
>> On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> I write both Py2 and Py3 code, but I keep the two worlds hermetically
>>> separated from each other.
>>
>> [...]
>>
>> You don't need to be afraid of the gap.
> 
> No problem. When I write Py3, I write Py3. When I write Py2, I write
> Py2. When I write bash, I write bash. When I write C, I write C.

Do you get confused by the difference between talking to Americans and
talking to Britons? The differences between American and British English is
a better analogy for the differences between Python 2 and 3 than the
differences between C and bash.

Especially if you target 2.7 and 3.3+, it is almost trivially easy to write
multi-dialect Python 2 and 3 code in the same code base. The trickiest part
is not a language change at all, but remembering that the names of some
standard library modules have changed.

Nobody here is suggesting that there are no differences between Python 2 and
3, but suggesting that those differences are of the same order of magnitude
as those between bash and C is ridiculous. The common subset of the Python
language is far greater than the differences between the versions.



-- 
Steven

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

#85664

On 12/02/15 15:39, Marko Rauhamaa wrote:

> I write both Py2 and Py3 code, but I keep the two worlds hermetically
> separated from each other.


In SciPy world we run the same code on Python 2 and Python 3.

Sturla

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

#85673

Le vendredi 13 février 2015 23:58:58 UTC+1, Sturla Molden a écrit :
> On 12/02/15 15:39, Marko Rauhamaa wrote:
> 
> > I write both Py2 and Py3 code, but I keep the two worlds hermetically
> > separated from each other.
> 
> 
> In SciPy world we run the same code on Python 2 and Python 3.
> 

========

Yes, until...

>>> print 'abcßxyzé'.upper()
ABC¿XYZÉ

>>> 'abcßxyz'.upper()
'ABCßXYZ'

>>> 'abcßdef'.upper()
'ABCSSDEF'

---

>>> jmUpper('abcßxyz')
'ABCẞXYZ'
>>>


Face it 90% of the Python code is not working out of
the box (even "serious applications") making the
apps simply not usable.

Unfortunately, it's not this nice article, written
by a us/ascii user(s), who is (are) not even aware of the
situation, that will "save" the situation.

Terrible to say, but that's the reality.

I was also an "CDC ascii" [*] user. It was 30-35 years
ago. Now I'm testing STIX/XITS fonts with a Tex unicode
engine (and a little bit more).

[*] PASCAL User Manual and Report, Kathleen Jensen,
Niklaus Wirth, SPRINGER-VERLAG.

jmf

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

#85602

On Thursday, February 12, 2015 at 3:08:10 AM UTC-8, Fabien wrote:

> ... what a coincidence then that a huge majority of scientists 
> (including me) dont care AT ALL about unicode. But since scientists are 
> not paid to rewrite old code, the scientific world is still stuck to 
> python 2.

I'm a scientist.  I'm a happy Python 3 user who migrated from Python 2 about two years ago.

And I use Unicode in my Python.  In implementing some mathematical models which have variables like delta, gamma, and theta, I decided that I didn't like the line lengths I was getting with such variable names.  I'm using δ, γ, and θ instead.  It works fine, at least on my Ubuntu Linux system (and what scientist doesn't use Linux?).  I also have special mathematical symbols, superscripted numbers, etc. in my program comments.  It's easier to read 2x³ + 3x² than 2*x**3 + 3*x**2.

I am teaching someone Python who is having a few problems with Unicode on his Windows 7 machine.  It would appear that Windows shipped with a less-than-complete Unicode font for its command shell.  But that's not Python's fault.

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

#85603

On Fri, Feb 13, 2015 at 5:29 AM, John Ladasky
<john_ladasky@sbcglobal.net> wrote:
> It works fine, at least on my Ubuntu Linux system (and what scientist doesn't use Linux?).  I also have special mathematical symbols, superscripted numbers, etc. in my program comments.  It's easier to read 2x³ + 3x² than 2*x**3 + 3*x**2.
>
> I am teaching someone Python who is having a few problems with Unicode on his Windows 7 machine.  It would appear that Windows shipped with a less-than-complete Unicode font for its command shell.  But that's not Python's fault.
>

Yes, Windows's default terminal/console does have issues. If all your
text is staying within the BMP, you may be able to run it within IDLE
to get somewhat better results; or PowerShell may help. But as you
say, that's not Python's fault.

Fortunately, it's not difficult to write a GUI program that
manipulates Unicode text, or something that works entirely with files
and leaves the display up to something else (maybe a good text editor,
or a web browser). All your internals are working perfectly, it's just
the human interface that's a bit harder. And only on flawed/broken
platforms.

ChrisA

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

#85636

Le jeudi 12 février 2015 19:38:44 UTC+1, Chris Angelico a écrit :
> On Fri, Feb 13, 2015 at 5:29 AM, John Ladasky
> <john_ladasky@sbcglobal.net> wrote:
> > It works fine, at least on my Ubuntu Linux system (and what scientist doesn't use Linux?).  I also have special mathematical symbols, superscripted numbers, etc. in my program comments.  It's easier to read 2x³ + 3x² than 2*x**3 + 3*x**2.
> >
> > I am teaching someone Python who is having a few problems with Unicode on his Windows 7 machine.  It would appear that Windows shipped with a less-than-complete Unicode font for its command shell.  But that's not Python's fault.
> >
> 
> Yes, Windows's default terminal/console does have issues. If all your
> text is staying within the BMP, you may be able to run it within IDLE
> to get somewhat better results; or PowerShell may help. But as you
> say, that's not Python's fault.
> 
> Fortunately, it's not difficult to write a GUI program that
> manipulates Unicode text, or something that works entirely with files
> and leaves the display up to something else (maybe a good text editor,
> or a web browser). All your internals are working perfectly, it's just
> the human interface that's a bit harder. And only on flawed/broken
> platforms.
> 

The windows terminal may not be very friendly
(and it's not broken).
From a unicode point of view, I belong to those, who
finds the windows/unicode ecosystem excellent and very
coherent (utf-16).

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

#85626

John Ladasky wrote:

> And I use Unicode in my Python.  In implementing some mathematical models
> which have variables like delta, gamma, and theta, I decided that I didn't
> like the line lengths I was getting with such variable names.  I'm using
> δ, γ, and θ instead.  It works fine, at least on my Ubuntu Linux system
> (and what scientist doesn't use Linux?).  I also have special mathematical
> symbols, superscripted numbers, etc. in my program comments.  It's easier
> to read 2x³ + 3x² than 2*x**3 + 3*x**2.


Oooh! What is your font of choice for this?



-- 
Steven

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

#85631

Le vendredi 13 février 2015 04:12:01 UTC+1, Steven D'Aprano a écrit :
> 
> 
> Oooh! What is your font of choice for this?
> 

I recommended many times to toy a little bit
with a TeX unicode engines. It's a very nice
way to learn Unicode.

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

#85654

On Thursday, February 12, 2015 at 7:12:01 PM UTC-8, Steven D'Aprano wrote:
> John Ladasky wrote:
> 
> > And I use Unicode in my Python.  In implementing some mathematical models
> > which have variables like delta, gamma, and theta, I decided that I didn't
> > like the line lengths I was getting with such variable names.  I'm using
> > δ, γ, and θ instead.  It works fine, at least on my Ubuntu Linux system
> > (and what scientist doesn't use Linux?).  I also have special mathematical
> > symbols, superscripted numbers, etc. in my program comments.  It's easier
> > to read 2x³ + 3x² than 2*x**3 + 3*x**2.
> 
> 
> Oooh! What is your font of choice for this?

Steven, I'm trying to answer your question.  It's proving to be harder than I expected.

The default font that the Geany program editor uses on my Ubuntu system renders everything I've tried.  When I look up that font in Geany's Preferences menu, it is called, simply, "monospace".

However, when I browse through fonts using the Ubuntu (14.04, 64-bit) Font Viewer, I do not find a font with that simple name.  I find several fonts whose name includes "mono" in the string: Liberation Mono, Nimbus Mono, Ubuntu Mono, etc.  All these fonts are listed as alternate choices in Geany's font selection menu.

Any Unicode that I use in my Python also renders nicely in the Ubuntu terminal.    In the Terminal Profile Preferences, the "use the system fixed width font" check box is selected.

So, it would appear that I'm using a font that the OS is selecting for me.  Which font that is, I'm still trying to figure out.

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

#85663

On Sat, Feb 14, 2015 at 6:40 AM, John Ladasky
<john_ladasky@sbcglobal.net> wrote:
> The default font that the Geany program editor uses on my Ubuntu system renders everything I've tried.  When I look up that font in Geany's Preferences menu, it is called, simply, "monospace".
>

That's a font alias. Unfortunately, I've never yet figured out a
straight-forward way to snap the pointer; the best I can suggest is to
go through your concrete font names and find one that looks the same.

I use the same "Monospace" font for my MUD client's default. It's a
good solid default, and I can guarantee that it "exists" on all
systems, even if specific other fonts might not (especially given that
I support three popular OSes). On my Debian system, it looks like
"Monospace" == "DejaVu Sans Mono", so you could try looking at that.

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web