Looking for PYTHONs to read syntax find different casing of a variable and to cross reference variables

[Jon K Peck]

I think the principles behind a coding standard could be agreed on, but there would never be a consensus on exactly how they translate into coding rules.  There is a long history of such standards for popular programming languages, but they quickly fall into disuse.  IBM does not have any such standards for SPSS syntax.  There are some implicit guidelines as embodied in the Syntax Editor such as avoiding abbreviations and the autoindent toolbar button, but they only affect behavior in the syntax window.  And, of course, for syntax designed in the last few years, abbreviations are not allowed.

"Batch style" formatting is still honored by the back end in most places, but it is considered obsolete.  Dialog boxes always generate syntax that will work in either mode.  There is no place in Statistics where batch mode syntax is actually necessary, although the equally obsolete INCLUDE command expects it.  The replacement INSERT command has been available since V13 (I designed it.)

A related note: avoiding the use of the CHAR.* functions means that bridging code page and Unicode mode operation is doomed to fail for other than for plain 7-bit ascii characters in some kinds of string operations, and Unicode is the future.  Those functions have been in place since V16, and dialog boxes in the COMPUTE family do not offer or use the old byte-oriented versions.  These functions abstract from bytes to characters, which are much easier to deal with and work the same way for code page and Unicode modes.  Some people think this matters only for the large character set Asian writing systems (Japanese, Korean, traditional and simplified Chinese), but accented European characters, Russian, Hebrew, Arabic, etc are also affected.



Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        Jon K Peck/Chicago/IBM@IBMUS,
Cc:        "[hidden email]" <[hidden email]>
Date:        05/13/2013 06:57 AM
Subject:        Re: Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables

---

Jon,

What's your take on the "community" developing their own standard?  Does IBM have anything "in-house" that dictates how syntax should or shouldn't be written - or are do you just reference the syntax guides/howtos already written for SPSS?

Sent from my iPhone

On May 13, 2013, at 8:31 AM, Jon K Peck <peck@...> wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
peck@...
phone: [phone]




From:        "J. R. Carroll" <jrc.csus@...>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <fomcl@...> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[Jon K Peck]

There is a sort of style guide for Python, known as PEP-8.
http://www.python.org/dev/peps/pep-0008/

I think of it as good advice rather than as a prescription.  I tend to use it mutatis mutandis for my R code as well.


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        Jon K Peck/Chicago/IBM@IBMUS,
Cc:        "[hidden email]" <[hidden email]>
Date:        05/13/2013 07:01 AM
Subject:        Re: Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables

---

And... For anyone that likes "Easter Eggs", the poem below is officially referenced as PEP-20, but you can also see it by importing a module called "this"

>>> import this

"The Zen of Python"

[...]



Sent from my iPhone

On May 13, 2013, at 8:31 AM, Jon K Peck <peck@...> wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
peck@...
phone: [phone]




From:        "J. R. Carroll" <jrc.csus@...>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <fomcl@...> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[David Marso]

Don't tell me:  python according to Worf?
==

Albert-Jan Roskam wrote

_______________________________
> From: J. R. Carroll <[hidden email]>
>To: [hidden email]
>Sent: Monday, May 13, 2013 3:00 PM
>Subject: Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables
>
>
>
>And... For anyone that likes "Easter Eggs", the poem below is officially referenced as PEP-20, but you can also see it by importing a module called "this"
>
>
>>>> import this


Off-topic: The source code is kind of fun

>>> import this, inspect
....

>>> print inspect.getsource(this)
s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print "".join([d.get(c, c) for c in s])

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[J. R. Carroll]

OT:  For those who are interested in going deeper into the rabbit hole that is Python, PEP-8 is a must read, but there are a handful of other PEP articles that address styling in more depth, for instance:  http://www.python.org/dev/peps/pep-0257/.  I've seen others, but I think those two are the champions of styling.

So, if you're trying to learn Python, PEP-8 is a solid start, but don't stop there!

There are also a few books recently published (one for 2.7 and one for 3.3) that are titled "Writing Idiomatic Python".  I haven't gone through all of it, as a lot of the content appears to be old-hat stuff to someone in the field of Python, but so far it's pointed out a few tricks!

http://www.jeffknupp.com/blog/2012/10/04/writing-idiomatic-python/

----


J. R. Carroll

Cell:  [phone]

www.jrcresearch.net

www.ontvp.com

Email: [hidden email]

          [hidden email]

          [hidden email]

On Mon, May 13, 2013 at 9:43 AM, Jon K Peck <[hidden email]> wrote:

There is a sort of style guide for Python, known as PEP-8.
http://www.python.org/dev/peps/pep-0008/

I think of it as good advice rather than as a prescription.  I tend to use it mutatis mutandis for my R code as well.

Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: <a href="tel:[phone]" value="[phone]" target="_blank">720-342-5621




From:        "J. R. Carroll" <[hidden email]>

To:        Jon K Peck/Chicago/IBM@IBMUS,
Cc:        "[hidden email]" <[hidden email]>

Date:        05/13/2013 07:01 AM
Subject:        Re: Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables

---

And... For anyone that likes "Easter Eggs", the poem below is officially referenced as PEP-20, but you can also see it by importing a module called "this"

>>> import this

"The Zen of Python"

[...]



Sent from my iPhone

On May 13, 2013, at 8:31 AM, Jon K Peck <[hidden email]> wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: <a href="tel:[phone]" value="[phone]" target="_blank">720-342-5621




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.