docstringargs: Python module for setting up argparse

[Chris Angelico]

Looking for comments, recommendations, advice that I've just wasted
half a day on something utterly useless, whatever it be!

I've just posted a new (single-module) package to PyPI that simplifies
the creation of an argparse UI for a program that consists of a number
of subcommands. It uses function docstrings and, optionally,
annotations, to put together the necessary argparse configs, without
needing all the names to be written out lots of times.

https://github.com/Rosuav/docstringargs
https://pypi.python.org/pypi/docstringargs

Examples are in the source tree:
https://github.com/Rosuav/docstringargs/blob/master/demo.py
https://github.com/Rosuav/docstringargs/blob/master/demo_anno.py

As this is the first project I've pushed up to PyPI, it's entirely
possible - even likely - that I've made a blooper in the metadata
somewhere. It does appear to install fine using pip, but I don't know
if something's going to cause problems down the line somewhere. All
advice gratefully received.

Is this something worth pursuing?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Apr 20, 2015 at 12:54 PM, Steven D'Aprano
>  wrote:
>> On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote:
>> Python has a noncanonical textual representation?
>>
>> What is a noncanonical textual representation, and where can I see
>> some?
>
> I think what Marko means is that there is a textual way to represent
> Python source code, and there are multiple files that represent
> identical Python programs, hence "noncanonical". If you have two UTF-8
> encoded files that contain the same text, they will have the exact
> same bytes in them, because UTF-8 defines a canonical byte
> representation for text. You can't say that about Python source.

Yes, more than one Python source file produces an identical AST, and
none of them is obviously the "normal form."


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: need help removing 'dev-r0' part from a python package

[suren shrestha]

On Monday, April 20, 2015 at 10:00:26 AM UTC+5:45, Chris Angelico wrote:
> On Mon, Apr 20, 2015 at 1:57 PM,   wrote:
> > My package 'webpreview'[https://github.com/ludbek/webpreview] has new 
> > version '1.0.3'. I used 'sdist' to bundle it. Unfortunately it names it 
> > 'webpreview-1.0.3dev-r0.tar.gz' instead of 'webpreview-1.0.3.tar.gz' making 
> > it unsuitable to upload to pypi.
> >
> > What is causing sdist to append 'dev' stuff in the package. The source can 
> > be available in the link above. Thanx for you help.
> 
> I'm not an expert on PyPI uploads, but I'm guessing this might be it:
> 
> https://github.com/ludbek/webpreview/blob/master/setup.cfg
> 
> [egg_info]
> tag_build = dev
> tag_svn_revision = true
> 
> "r0" looks like a Subversion revision identifier, and you're tagging
> it with "dev".
> 
> ChrisA


Thanx ChrisA, I will remove it and see what happens :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: need help removing 'dev-r0' part from a python package

[Ben Finney]

sth@gmail.com writes:

> My package 'webpreview'[https://github.com/ludbek/webpreview] has new
> version '1.0.3'. I used 'sdist' to bundle it.

I'll assume you are using a ‘./setup.py’ program to define and generate
the distribution.

The ‘setup’ function in that program takes a ‘version’ parameter. What
value is your program passing to that parameter? What generates that
value?

-- 
 \ Fry: “Take that, poor people!”  Leela: “But Fry, you’re not |
  `\ rich.”  Fry: “No, but I will be someday, and then people like |
_o__)  me better watch out!” —Futurama |
Ben Finney

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

Re: need help removing 'dev-r0' part from a python package

[Chris Angelico]

On Mon, Apr 20, 2015 at 1:57 PM,   wrote:
> My package 'webpreview'[https://github.com/ludbek/webpreview] has new version 
> '1.0.3'. I used 'sdist' to bundle it. Unfortunately it names it 
> 'webpreview-1.0.3dev-r0.tar.gz' instead of 'webpreview-1.0.3.tar.gz' making 
> it unsuitable to upload to pypi.
>
> What is causing sdist to append 'dev' stuff in the package. The source can be 
> available in the link above. Thanx for you help.

I'm not an expert on PyPI uploads, but I'm guessing this might be it:

https://github.com/ludbek/webpreview/blob/master/setup.cfg

[egg_info]
tag_build = dev
tag_svn_revision = true

"r0" looks like a Subversion revision identifier, and you're tagging
it with "dev".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

need help removing 'dev-r0' part from a python package

[sth . srn]

My package 'webpreview'[https://github.com/ludbek/webpreview] has new version 
'1.0.3'. I used 'sdist' to bundle it. Unfortunately it names it 
'webpreview-1.0.3dev-r0.tar.gz' instead of 'webpreview-1.0.3.tar.gz' making it 
unsuitable to upload to pypi.

What is causing sdist to append 'dev' stuff in the package. The source can be 
available in the link above. Thanx for you help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Mon, Apr 20, 2015 at 1:28 PM, Rustom Mody  wrote:
>> If you have a ten-file project that's identifying a key function
>> globally as 'f', then you already have a problem. If your names are
>> more useful and informative, a global search-and-replace will do the
>> job.
>
> Are you sure your global search-and-replace will do a proper job inside
> strings and comments?

Yep! Any occurrence inside a string literal or comment is generally
going to be referring to the same function, and thus should be
renamed. Can your system handle _that_? Example:

def add_grab(widget):
"""Add a widget to the grabbed widgets"""

def remove_grab(widget):
"""Undo the effect of add_grab() on a given widget"""
# Note that multiple add_grab() calls will add multiple instances,
# so we remove only the first.

Every occurrence of add_grab here is referring to the function. If you
do a global search-and-replace, they'll be caught automatically. With
your non-text magic, you'd need to explicitly implement this as a
feature. Text files make life easier!

>> What's your point, though?
>
> Point?
>
> Nnotions like identifier (and dozens of others) are straightforwardly
> present and available inside the python implementation.
> However the language implementation is a hard-n-high silo
> For the programmer accessing the language through an editor these notions are
> not available unless hi-power explosives are used to punch holes in the silo
> -- eg open Cpython sources.

Would it help if Python grew a function like Pike's
Function.defined(), which tells you exactly where, even in C source,
something was defined? I don't honestly see that looking in the
CPython source is such a common need that it begs for assistance, and
I definitely don't see how a non-text source code format would improve
on it. Feel like elaborating?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Monday, April 20, 2015 at 8:34:12 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody  wrote:
> > The key thing to make this work is that the tab needs to be a reasonably 
> > solid
> > non-leaky abstraction for denoting an indent.
> > As soon as you allow both tabs and spaces all the interminable bikeshedding 
> > starts
> >
> 
> Whatever you change, there will be stuff for people to argue about.
> Trust me, that's nothing to do with the nature of programming
> languages... it's about the nature of people.
> 
> > In many ways this is like the browser wars.
> > If browsers had been made like half-decent compilers then non-compliant html
> > wouldn't render and would get corrected on short order.
> > Instead browsers overreach themselves to be nice (to users) and end up being
> > horrible to web-developers who now need to maintain 1 dozen browsers × 2 
> > dozen versions.
> >
> > Likewise all the overreaching to be allow 'free-form' layout puts paid to 
> > all
> > attempts at richer structure comprehending tools.
> > As a quick example try this:
> > You've a 10-file python project in which you want to replace function 'f'
> > by function 'longname'
> > How easy is it?
> >
> > I am ready to bet that if you use IE-ish its easy if you use classic editors
> > not so.
> 
> If you have a ten-file project that's identifying a key function
> globally as 'f', then you already have a problem. If your names are
> more useful and informative, a global search-and-replace will do the
> job.

Are you sure your global search-and-replace will do a proper job inside
strings and comments?

> 
> What's your point, though?

Point?

Nnotions like identifier (and dozens of others) are straightforwardly
present and available inside the python implementation.
However the language implementation is a hard-n-high silo
For the programmer accessing the language through an editor these notions are
not available unless hi-power explosives are used to punch holes in the silo
-- eg open Cpython sources.

The Smalltalks and Lisps organized the world differently -- the programmer was
inside the silo with the corresponding advantages of power and disadvantages of
imprisonment.

I (and I guess BartC) like to dream of a Utopia that is powerful and free
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:54 PM, Steven D'Aprano
 wrote:
> On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote:
>
>> Lisp has a noncanonical textual representation just like Python.
>
> Python has a noncanonical textual representation?
>
> What is a noncanonical textual representation, and where can I see some?

I think what Marko means is that there is a textual way to represent
Python source code, and there are multiple files that represent
identical Python programs, hence "noncanonical". If you have two UTF-8
encoded files that contain the same text, they will have the exact
same bytes in them, because UTF-8 defines a canonical byte
representation for text. You can't say that about Python source.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody  wrote:
> The key thing to make this work is that the tab needs to be a reasonably solid
> non-leaky abstraction for denoting an indent.
> As soon as you allow both tabs and spaces all the interminable bikeshedding 
> starts
>

Whatever you change, there will be stuff for people to argue about.
Trust me, that's nothing to do with the nature of programming
languages... it's about the nature of people.

> In many ways this is like the browser wars.
> If browsers had been made like half-decent compilers then non-compliant html
> wouldn't render and would get corrected on short order.
> Instead browsers overreach themselves to be nice (to users) and end up being
> horrible to web-developers who now need to maintain 1 dozen browsers × 2 
> dozen versions.
>
> Likewise all the overreaching to be allow 'free-form' layout puts paid to all
> attempts at richer structure comprehending tools.
> As a quick example try this:
> You've a 10-file python project in which you want to replace function 'f'
> by function 'longname'
> How easy is it?
>
> I am ready to bet that if you use IE-ish its easy if you use classic editors
> not so.

If you have a ten-file project that's identifying a key function
globally as 'f', then you already have a problem. If your names are
more useful and informative, a global search-and-replace will do the
job.

What's your point, though? Somewhere along the way, you need to have
identifiers, and those identifiers need to explain *to the human* what
code you're referring to. Whether they're line labels in assembly
language, memory locations in machine code, linker relocation table
entries, fully-qualified module/class/method names, or simple flat
identifiers, they exist as much for the humans as for the compiler. If
you change the basic syscall from INT 21 to CALL __SYSTEM, everyone
who uses your code needs to change his/her *head* to cope with your
change. There is fundamentally no tool which can do this for you.

You can add a level of indirection to program loading by having the
function name turn into some sort of internal identifier when you save
the source file, and then you can rename the function in one place.
Great! But somehow you still need to have humans recognize which
functions they want to call. Do they have to point-and-click to pick a
function? I've used IDEs like that, and they are a pain.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote:

> Lisp has a noncanonical textual representation just like Python.

Python has a noncanonical textual representation?

What is a noncanonical textual representation, and where can I see some?



-- 
Steven

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

Re: Best search algorithm to find condition within a range

[Steven D'Aprano]

On Mon, 20 Apr 2015 12:56 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> Yay! I'm not the only one who uses or likes Forth!
> 
> Out of interest, is Forth different from PostScript? I have done some
> small-time programming in PostScript but nothing in Forth.


Both Forth and PostScript are concatenative stack-based languages with a
reverse Polish notation syntax. Other than that, I imagine that they are
very different. I have zero experience with Postscript and only a little
with Forth (enough to know that I like it more in principle than practice),
so the following is mostly inferred rather than from experience.

Postscript is interpreted, with strong dynamic typing, Lisp-like data
structures, and garbage collection. It is designed for generating vector
images. It can be used for general purpose programming, but that's not its
strong suit.

Technically, Forth is also interpreted, but that may be misleading if you
think of it in traditional terms. The runtime interpreter (virtual machine)
may be as simple as a handful of commands to follow a linked list of
subroutines calling each one in turn.

One of the design principles of Forth is that compiled code is extremely
compact and fast, which makes it ideal for running at a very low level on
constrained hardware.

Older Forths are untyped. All data is a machine word on a stack. Arrays and
equivalent are implemented by dropping the address of the array on the
stack and then using redirection to access the array, which makes it rather
like C.

Unlike C, Forth puts the book-keeping related to function calls on a
separate stack, which simplifies the runtime significantly.

Newer Forths added a third stack for floating point values.


The two classic Forth books back in the 80s were Starting Forth and Thinking
Forth, by Leo Brodie:

http://www.forth.com/starting-forth/

http://thinking-forth.sourceforge.net/


They're a bit old, and the Starting Forth book in particular has a level of
whimsy which feels a bit odd to many people, but you can browse them to get
a feel for the language.



-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Monday, April 20, 2015 at 7:54:37 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody  wrote:
> > Prestige of Unix development environment keeps us stuck with text files when
> > the world has moved on
> 
> And what, pray, would we gain by using non-text source code? Aside
> from binding ourselves to a set of tools, which would create an even
> worse lock-in?

Threads like this one would become passé.
In html for example there's things like fluid-layout.
So also if indentation was strictly delimited by tabs
then whether you like to see your tabs as 4 spaces and I like to see them as 2
would be as relevant to our discussing shared code as the fact that I wearing
pyjamas and you are in a 3 piece suit.

The key thing to make this work is that the tab needs to be a reasonably solid
non-leaky abstraction for denoting an indent.
As soon as you allow both tabs and spaces all the interminable bikeshedding 
starts 

In many ways this is like the browser wars.
If browsers had been made like half-decent compilers then non-compliant html
wouldn't render and would get corrected on short order.
Instead browsers overreach themselves to be nice (to users) and end up being
horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen 
versions.

Likewise all the overreaching to be allow 'free-form' layout puts paid to all
attempts at richer structure comprehending tools.
As a quick example try this:
You've a 10-file python project in which you want to replace function 'f' 
by function 'longname'
How easy is it?

I am ready to bet that if you use IE-ish its easy if you use classic editors
not so.

This unfortunate choice between sophistication+lockin vs uncivilization+freedom
is unnecessary
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Mon, 20 Apr 2015 04:07 am, Dan Sommers wrote:

> Smalltalk, Forth, and LISP don't follow the program=textfile system
> (although LISP can, and does sometimes);

Correct, and the fact that they wrapped code and environment into a
completely opaque image was a major factor in their decline in popularity
for all three languages.

http://www.ianbicking.org/where-smalltalk-went-wrong.html
http://www.ianbicking.org/where-smalltalk-went-wrong-2.html


Source as text means that you can use any text based tool with little or no
effort. Using a non-text binary blob for source code means that your
options are much more limited. Look at source control software like git and
mercurial (hg): they automatically work on any language based on lines of
text code. There is no need for hg-for-java, hg-for-python, hg-for-ruby,
hg-for-javascript, hg-for-c, there is just hg. But if languages were
image-based like Smalltalk, hg would require special knowledge of the
internals of each compiler's image file format.


-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Mark Lawrence]

On 20/04/2015 03:08, Rustom Mody wrote:

Prestige of Unix development environment keeps us stuck with text files when
the world has moved on



If it ain't broke, don't fix it.

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

Mark Lawrence

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

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody  wrote:
> Prestige of Unix development environment keeps us stuck with text files when
> the world has moved on

And what, pray, would we gain by using non-text source code? Aside
from binding ourselves to a set of tools, which would create an even
worse lock-in?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Sunday, April 19, 2015 at 11:23:20 PM UTC+5:30, Steven D'Aprano wrote:
> Programmers use source code as text for the same reason that wheels are
> still round. Wheels have been round for thousands of years! Why can't we
> try something modern, like triangular wheels? Or something fractal in
> three-dimensions... maybe cauliflower shaped?

So also did people believe for a good 2000 years that acceleration due to 
gravity
is proportional to mass until Galileo climbed up the tower of Pisa and dropped
2 different weight objects
http://en.wikipedia.org/wiki/Galileo%27s_Leaning_Tower_of_Pisa_experiment

Analogies can work both ways

And before you ask something like

| What does this have to do with creating a language with configurable syntax?
| Just because C/Unix was a good idea doesn't mean every idea related to
| programming language design is also a good idea. 

let me spell it out:
Prestige of Aristotle stymies progress of physics of 2 millennia 
likewise
Prestige of Unix development environment keeps us stuck with text files when
the world has moved on
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Monday, April 20, 2015 at 2:11:13 AM UTC+5:30, Marko Rauhamaa wrote:
> Michael Torrie:
> 
> > On 04/18/2015 01:00 AM, Marko Rauhamaa wrote:
> >> It would be possible to define a canonical AST storage format. Then,
> >> your editor could "incarnate" the AST in the syntax of your choosing.
> >
> > As was just mentioned in another part of the thread, what you're
> > describing is essentially LISP.
> 
> I don't see how that is more essentially Lisp than Python.
> 
> Lisp has a noncanonical textual representation just like Python.
> 
> 
> Marko

Technically correct
Pragmatically: its like saying a meal that costs a penny, 100 EURO and 10K EURO
are all the same.
In C, access to parsing /unparsing is one of open up gcc/use lex/yacc
In python, it is use the introspective module(s)
In lisp its one call (read)/(print) -- at most; none if the REPL is used
effectively
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: do you guys help newbies??

[Mark Lawrence]

On 20/04/2015 02:53, Dave Angel wrote:

On 04/19/2015 09:37 PM, josiah.l...@stu.nebo.edu wrote:

On Wednesday, November 27, 2002 at 4:01:02 AM UTC-7, John Hunter wrote:

"malik" == malik martin  writes:


 malik>i'm having a simple problem i guess.  but i still dont
 malik> know the answer. anyone see anything wrong with this code?
 malik> i think it's the line in the while loop that starts with
 malik> "averagea = ..."  because it will execute once but once the
 malik> loop goes around one more time it gets an error. is there
 malik> it because averagea has been assigned a definate value? if
 malik> so how do i record the value but reset averagea back to 0(
 malik> i guess it would be 0)

 malik>any help would be apreciated. thanks!!

I think you forgot to post your code.   Makes it harder.

JDH




And I think you forgot to check the date of the post to which you're
responding.



Rather sad to see those three initials in that post as well 😢

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

Mark Lawrence

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

Re: do you guys help newbies??

[Dave Angel]

On 04/19/2015 09:37 PM, josiah.l...@stu.nebo.edu wrote:

On Wednesday, November 27, 2002 at 4:01:02 AM UTC-7, John Hunter wrote:

"malik" == malik martin  writes:


 malik>i'm having a simple problem i guess.  but i still dont
 malik> know the answer. anyone see anything wrong with this code?
 malik> i think it's the line in the while loop that starts with
 malik> "averagea = ..."  because it will execute once but once the
 malik> loop goes around one more time it gets an error. is there
 malik> it because averagea has been assigned a definate value? if
 malik> so how do i record the value but reset averagea back to 0(
 malik> i guess it would be 0)

 malik>any help would be apreciated. thanks!!

I think you forgot to post your code.   Makes it harder.

JDH




And I think you forgot to check the date of the post to which you're 
responding.


--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Sunday, April 19, 2015 at 11:38:45 PM UTC+5:30, Dan Sommers wrote:


> What's to revamp? My IDE is UNIX.

Precisely my point: source-file = text-file is centerstage of Unix philosophy
If you want to start by questioning that, you must question not merely the 
language (python or whatever) but the matrix in which it is embedded

> 
> Java programmers who don't dare leave their beloved pointy clicky IDE
> for a command line store their source files as plain text (and they
> cringe when I sed sed against those source files, but I digress).  The
> one project I ever did on a mainframe had a common text editor that
> supported FORTRAN, JCL, and COBOL, and stored source code in files of
> containing fixed length records of EBCDIC characters, IIRC.

And in all likelihood different from the files (not really text) created
by Cobol

> The notion
> of a "line of code," even in white-space-neutral languages, is deeply
> rooted in punch cards, and isn't going away anytime soon.
> 
> IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
> languages will continue to work that way.

Yeah...
For what I (and I guess bartC) are talking about to succeed we would need
- more structured diff/merge in git (etc)
- corresponding sed/grep etc
- editor (plugins)
- etc

http://blog.languager.org/2013/09/poorest-computer-users-are-programmers.html

So yes its more work than making a new language
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: do you guys help newbies??

[josiah.l...@stu.nebo.edu]

On Wednesday, November 27, 2002 at 4:01:02 AM UTC-7, John Hunter wrote:
> > "malik" == malik martin  writes:
> 
> malik>i'm having a simple problem i guess.  but i still dont
> malik> know the answer. anyone see anything wrong with this code?
> malik> i think it's the line in the while loop that starts with
> malik> "averagea = ..."  because it will execute once but once the
> malik> loop goes around one more time it gets an error. is there
> malik> it because averagea has been assigned a definate value? if
> malik> so how do i record the value but reset averagea back to 0(
> malik> i guess it would be 0)
> 
> malik>any help would be apreciated. thanks!!
> 
> I think you forgot to post your code.   Makes it harder.
> 
> JDH

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

Re: New to Python - block grouping (spaces)

[BartC]

On 20/04/2015 00:59, Ben Finney wrote:

BartC  writes:


I used actual languages Python and C in my example, I should have used
A and B or something.


If you had, then the topic drifts so far from being relevant to a Python
programming forum that I'd ask you to stop.

Perhaps that should have happened much sooner.


Maybe it should have. This sub-thread started by you replying to this 
parenthesised comment of mine:


"(Actually *I* would quite like to know why languages don't have
switchable syntax anyway to allow for people's personal preferences.)"

I didn't mention any language by name at all!

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Ben Finney]

BartC  writes:

> I used actual languages Python and C in my example, I should have used
> A and B or something.

If you had, then the topic drifts so far from being relevant to a Python
programming forum that I'd ask you to stop.

Perhaps that should have happened much sooner.

-- 
 \  “If we have to give up either religion or education, we should |
  `\  give up education.” —William Jennings Bryan, 1923-01 |
_o__)  |
Ben Finney

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

Re: New to Python - block grouping (spaces)

[Ron Adam]

On 04/19/2015 05:42 PM, BartC wrote:


So I'm aware of some of the things that are involved.

(BTW that project worked reasonably well, but I decided to go in a
different direction: turning "J" from a mere syntax into an actual language
of its own.)


Something you might try with your new language is to have an editor that 
can parse the source text to a tokenised "text" data file.  It should be a 
fairly direct text to text translation, so putting it into the editor 
should be doable.


Once you get that far, you can add pluggable token parsers to the editor 
that can unparse the token files to a specific user format for editing, and 
reparse it back to the standardised token file for storage.  Now the users 
can choose a customised dialect of your language.  And the compiler will 
work on a single token file type.


This will also remove the need for pretty printers and formatters as they 
will be built into the editors pluggable token parser.  Just have the 
editor tokenise and then immediately untokenise and you just checked for 
syntax errors and reformatted the program.   The highlighter could also 
work with the token parser as well.  The only catch is how to handle 
compile and run time errors.  The editor will need to read an error file 
and translate it back to the source.  I think it's doable but it will be 
tricky to get it to work well.


The reason to make the split at tokens is, it's at a stage that most of 
what is needed is already in a text editor.


The token file format becomes the bridge that spans the gap between the 
user/editor and the compiler/interpreter.


Then your compiler/interpreter is all implementation details that work on a 
single standardised token file format rather than unformatted text files.


Ron




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

Re: HELP! How to return the returned value from a threaded function

[D. Xenakis]

This worked like a charm.
http://code.activestate.com/recipes/84317-easy-threading-with-futures/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[BartC]

On 19/04/2015 13:59, Ben Finney wrote:

BartC  writes:


Why shouldn't A configure his editor to display a Python program in
C-like syntax, and B configure their editor to use Python-like tabbed
syntax?


I don't recall anyone saying that *shouldn't* be done. Feel free to
make, and maintain and support and propagate and keep pace with changes
in everything Python interacts with, a full Python stack that supports
such flexibility.


A can write code in the preferred syntax, and B can view/modify
exactly the same code in /their/ preferred syntax. What would be the
problem?


I can only invite you to embark on the project of a Python compiler
which accepts such a switchable syntax, maintain it consistently over
the lifetime of a project with significant numbers of people
collaborating using different switch settings for that syntax, and
working on the same code with different editor settings.

Once you've done that, report back to us about the problems encountered.


(The actual stored representation of the program would be in one of
those two styles, or something else entirely; Lisp-like syntax for
example. It doesn't matter because no-one would care.


No-one except the people who have to maintain and debug and continue
developing a Python that supports multiple radically-different syntaxes.
I suspect the efforts of those people is being discounted in your vision.


I used actual languages Python and C in my example, I should have used A 
and B or something.


If this was actually Python, then clearly source must be stored in 
Python syntax, to get around some of the objections that have been 
raised. Then all existing tools will work as before.


But it means an editor would need to understand Python extremely well in 
order to do the 2-way transformation I was suggesting. And while that 
would need maintaining, I don't think it's impossible (don't smart 
editors already understand a lot of the syntax? And if I was doing this, 
I would use a conventional editor, and an separate translator). But it 
would all be optional; everything would then still work as before.


However, I have played around with an actual project along these lines, 
but with some differences. Let's call actual Python source ".PY", and my 
preferred syntax ".JPY" (since those were the file extensions I used; 
"J" was the name I used to designate my syntax - syntax, not language, 
as the language must still be Python).


Here, the intention was to store source code in .JPY files, with .PY 
used as an intermediate form when I need to use an existing Python tool. 
So the translation was one-way (which suited me because I tend to do my 
own thing).


There are a few issues: I can still import .PY files created by others, 
but if it's one of mine created as .JPY, it just means it needs 
translating before running Python. Things such as eval() that have been 
mentioned, I haven't attempted. (Probably, it would be written as 
jeval() and would need to invoke the translator on the string, the 
results of which are passed to eval(). You can get around most such 
problems.)


So I'm aware of some of the things that are involved.

(BTW that project worked reasonably well, but I decided to go in a 
different direction: turning "J" from a mere syntax into an actual 
language of its own.)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Alternative to curve_fit() from scipy.optimize

[ddidussa]

Hello,

I am trying to fit a curve of the form (ln(x+a))**b to a set of points.

However, curve_fit() from scipy.optimize fails to find a consistent optimal 
solution (as I increase the number of data points, the coefficients found vary 
greatly).

I suspect this is because of the algorithm that the function uses to solve the 
problem (Levenberg-Marquardt), as it finds a local minimum and returns those 
values.

Do you know of any package that contains a function that is more adequate to 
fit logarithmic functions? Or a curve-fitting function where I can specify 
which algorithm to solve the problem?

Thanks in advance,
Danielle
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Marko Rauhamaa]

Michael Torrie :

> On 04/18/2015 01:00 AM, Marko Rauhamaa wrote:
>> It would be possible to define a canonical AST storage format. Then,
>> your editor could "incarnate" the AST in the syntax of your choosing.
>
> As was just mentioned in another part of the thread, what you're
> describing is essentially LISP.

I don't see how that is more essentially Lisp than Python.

Lisp has a noncanonical textual representation just like Python.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best search algorithm to find condition within a range

[Paul Rubin]

Steven D'Aprano  writes:
> Have you tried Factor? I'm wondering if it is worth looking at, as a
> more modern and less low-level version of Forth.

Factor is basically Lisp with Forth-based syntax, from what I can tell.
Tagged objects, garbage collection, etc.

Forth is traditionally a self-hosted low level language with a
minimalistic spirit.  It uses native machine words containing numbers or
machine pointers like assembly language does, with no typechecking of
any sort.  I'd say there is a rather big cultural and technical divide
between Forth and Factor, despite some surface similarities.

The comp.lang.forth newsgroup is actually quite lively and interesting
and I'm a semi-regular there, though I use Forth only sort of casually,
mostly for the change of perspective it brings to programming, rather
than because I see it as a good way to deliver an end result.

This article is critical of Forth and somewhat unpopular on the Forth
newsgroup but it describes Forth's flavor from the "other side":

http://yosefk.com/blog/my-history-with-forth-stack-machines.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Paul Rubin]

Steven D'Aprano  writes:
> You might be interested in the Coffeescript model>
> You'll notice that Coffeescript isn't a mere preprocessor or source code
> transformation. 

I like Purescript (purescript.org) better than Coffeescript, but either
way, I don't see Python as an attractive target for that approach.
People code in Javascript because they have to (browser apps), so if
they hate the JS language but have to use it anyway, it's reasonable to
wrap a translation layer around it.  JS is basically used as a high
level assembly language.

By contrast, most people who use Python use it because they like it.
Sure there are warts here and there, but for the most part, if someone
doesn't like Python, they can pick something else that does the same
job.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[Dave Angel]

On 04/19/2015 11:56 AM, pauld11718 wrote:

I shall provide with further details

Its about Mathematical modelling of a system. Fortran does one part and python 
does the other part (which I am suppose to provide).
For a time interval tn --> t_n+1, fortran code generates some values, for which my 
python code accepts it as an input. It integrates some data for the same time step tn 
--> tn+1 and fortran computes based on this for the next time step t_n+1 --> 
t_n+2..and this is how loop continues.

Its the fortran code calling my Python executable at all the time interval.


Then you'd better find out how it's calling your executable.  Calling it 
is very different than starting it.  The whole import x, y,z is done 
only upon initial startup of the python code.  You can then call the 
Python code as many times as you like without incurring that overhead again.


Naturally, if the guy who designed the Fortran code didn't think the 
same way, and is unavailable for further tweaking, you've got a problem.




So,
1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows?


Don't worry about how you get installed until after you figure out how 
you're going to get those calls and data back and forth between the 
Fortran code and your own.




2. As interfacing between fortran/python is via .dat file, so on every 
time-step python executable is called it shall open()/close() .dat file. This 
along with all those
from  import *'s
are unnecessary.


Have you got specs on the whole dat file thing?  How will you know it's 
time to examine the file again?  As long as you get notified through 
some other mechanism, there's no problem in both programs having an open 
handle on the shared file.


For that matter, the notification can be implicit in the file as well.

But is there a designer behind this, or is the program intending to deal 
with something else and you're just trying to sneak in the back door?





3. I dont have access to fortran code. I shall provide the python executable 
only, which will take input from .dat file and write to another .dat file. So, 
what is your suggestion regarding socket/pipe and python installation on RAM? I 
have no idea with those.



Not much point in opening a pipe if the other end isn't going to be 
opened by the Fortran code.



Isn't there a better way to handle such issues?



Sure, there are lots of ways.  But if the Fortran code is a closed book, 
you'll have to find out how it was designed, and do all the adapting at 
your end.


If it becomes open again, then you have the choice between having one of 
your languages call functions in the other (ie. single process), having 
some mechanism (like queues, or sockets) between two separately started 
processes, and having one program launch the other repeatedly.  That 
last is probably the least performant choice.


If you google "python Fortran" you'll get lots of hits.  You could start 
reading to see what your choices are.  But if the Fortran designer has 
left the room, you'll be stuck with whatever he put together.


And chances are very high that you'll need to develop, and certainly 
test, some parts of the project on the Windows machine, and particularly 
with the Windows C/Fortran compilers.



--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Mon, Apr 20, 2015 at 4:07 AM, Dan Sommers  wrote:
> IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
> languages will continue to work that way.

Linefeeds are nothing to git - it tracks the entire content of the
file. When you ask to see the diff between two versions of a file,
that's when lines start to have meaning - and if you configure in your
own difftool, you're welcome to compare files in arbitrary ways. It's
not for the sake of source control that code is in lines of text -
it's for the sake of humans.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best search algorithm to find condition within a range

[Dave Angel]

On 04/19/2015 09:02 AM, Steven D'Aprano wrote:

On Sun, 19 Apr 2015 04:08 am, Albert van der Horst wrote:


Fire up a lowlevel interpreter like Forth. (e.g. gforth)


Yay! I'm not the only one who uses or likes Forth!

Have you tried Factor? I'm wondering if it is worth looking at, as a more
modern and less low-level version of Forth.



I also like Forth (since 83), but haven't done much in the last decade.

I was newsletter editor for our local FIG for many years.

I have met and debated with Elizabeth Rather, and been a "third hand" 
for Chuck Moore when he was re-soldering wires on his prototype Forth board.


You can see my name in the X3J14 standard:
   https://www.taygeta.com/forth/dpans1.htm#x3j14.membership


I'd be interested in a "more modern" Forth, but naturally, as a member 
of band of rugged individualists, I wonder if it can possibly satisfy 
more than one of us.



http://factorcode.org/

That site is my first time I recall seeing "concatenative" as a type of 
language.  Interesting way of thinking of it.  I just call it RPN, and 
relate it to the original HP35 calculator ($400, in about 1972).


From the overview, it looks like they're at least aiming at what I 
envisioned as the next Forth I wanted to use.  Instead of putting ints 
and addresses on the stack, you put refs to objects, in the Python 
sense.  Those objects are also gc'ed.  I don't know yet whether 
everything is an object, or whether (like Java), you have boxed and 
unboxed thingies.


Sounds interesting, and well worth investigating.  thanks for pointing 
it out.


--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[CHIN Dihedral]

On Thursday, April 16, 2015 at 11:06:28 PM UTC+8, Mark Lawrence wrote:
> On 16/04/2015 15:52, Blake McBride wrote:
> 
> > So, Python may be a cute language for you to use as an individual, but it 
> > is unwieldy in a real development environment.
> >
> 
> Thanks for this, one of the funniest comments I've read here in years. 
> It's good to see that new people share the humourous side of the Python 
> programming culture.  Long may it continue.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Python is a cross-platform computer
language with dynamical types, 
functional programming featuers, oops, and generic programming featuers 
designed in the language.

Now the generic part is the main
progress in the software and IT
sectors 



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

Re: New to Python - block grouping (spaces)

[Mel Wilson]

On Mon, 20 Apr 2015 03:53:08 +1000, Steven D'Aprano wrote:

> On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote:

>> Well evidently some people did but fortunately their managers did not
>> interfere.
> 
> You are assuming they had managers. University life isn't exactly the
> same as corporate culture.

IIRC Thompson, Ritchie, et al. were working at Bell Labs.  Legend has it 
that management would not buy them a Multics, so they were forced to 
write their own using the hardware they had.

Mel.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Dan Sommers]

On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote:

> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system
> today?

Revamp?  What's to revamp?

C, C++, C#, Java, FORTRAN, Python, Perl, Ruby, POSIX shells, Javascript,
and a whole spectrum of arguably mainstream languages *still* work that
way.  Plenty of other languages that compile to Python or Java bytecode
work that way, even if the source code isn't Python or Java.  New
languages, like go, Rust, and Julia work that way.  What's to revamp?
My IDE is UNIX.

Java programmers who don't dare leave their beloved pointy clicky IDE
for a command line store their source files as plain text (and they
cringe when I sed sed against those source files, but I digress).  The
one project I ever did on a mainframe had a common text editor that
supported FORTRAN, JCL, and COBOL, and stored source code in files of
containing fixed length records of EBCDIC characters, IIRC.  The notion
of a "line of code," even in white-space-neutral languages, is deeply
rooted in punch cards, and isn't going away anytime soon.

IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
languages will continue to work that way.

Smalltalk, Forth, and LISP don't follow the program=textfile system
(although LISP can, and does sometimes); and UCSD Pascal didn't (at
least I think it didn't; the only tools I remember from those days all
ran inside UCSD Pascal and didn't expose much of the internals).

Slash rant.  Sorry.

Now that we've settled on UTF-8 as a successor to ASCII, the
program=textfile system has a long future in front of it.

Dan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote:

> On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote:
> 
> 
> 
>> I suspect you'll find the task fundamentally hard.
> 
> How hard?
> Lets see.
> Two guys wanted to write an OS.
> Seeing current languages not upto their standard they first made
> themselves a suitable language.
> Would you call their project hard ridiculous and misguided?

No, I would call it easy and sensible. University undergraduates write their
own compilers and operating systems. Admittedly only toy ones, but Thomson
and Ritchie weren't undergraduates.

What does this have to do with creating a language with configurable syntax?
Just because C/Unix was a good idea doesn't mean every idea related to
programming language design is also a good idea.


> Well evidently some people did but fortunately their managers did not
> interfere.

You are assuming they had managers. University life isn't exactly the same
as corporate culture.


> OTOH some others liked the ideas/outlook enough that they jumped on the
> bandwagon and in short order there were - a heavy duty compilation system
> -- parser generators to librarians etc - editor(s)
> - source code systems
> - text tools (grep sed)
> - shell
> 
> In short a 'Programmer's Work Bench'
> http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf
> 
> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system today?

Programmers use source code as text for the same reason that wheels are
still round. Wheels have been round for thousands of years! Why can't we
try something modern, like triangular wheels? Or something fractal in
three-dimensions... maybe cauliflower shaped?



-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:38 pm, BartC wrote:

> (I think much of the problem that most languages are intimately
> associated with their specific syntax, so that people can't see past it
> to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
> whatever the syntax is, who cares? We just want to do an assignment!)

You are making the mistake of thinking that we write code for the benefit of
the compiler or interpreter. We don't. If we did that, we'd all be using
machine code, programming in hex.

Source code exists to be read by human beings. If you want to communicate
with other human beings, you have to agree on a common language.

You might be interested in the Coffeescript model. You write Coffeescript
code, which is then translated (compiled? transpiled?) into pure
Javascript, which can then be run in the Javascript engine of your choice.
That's a language design model which is proven to work, unlike the idea of
having configurable syntax.

You'll notice that Coffeescript isn't a mere preprocessor or source code
transformation. The code is compiled into a different language, which may
not be reversible, and different compilers may generate different
(better/worse) code.

The Coffeescript:

eat food for food in ['toast', 'cheese', 'wine']


compiles to Javascript:

var food, j, len, ref;

ref = ['toast', 'cheese', 'wine'];
for (j = 0, len = ref.length; j < len; j++) {
  food = ref[j];
  eat(food);
}




-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Mel Wilson]

On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote:

> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system
> today?

Dunno.  Why not?  There's half of you right there.

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

Re: New to Python - block grouping (spaces)

[Michael Torrie]

On 04/18/2015 01:00 AM, Marko Rauhamaa wrote:
> Ben Finney :
> 
>> If you only write programs that will only ever be read by you and
>> no-one else, feel free to maintain a fork of Python (or any other
>> language) that suits your personal preferences.
> 
> It would be possible to define a canonical AST storage format. Then,
> your editor could "incarnate" the AST in the syntax of your choosing.

As was just mentioned in another part of the thread, what you're
describing is essentially LISP.

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

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote:



> I suspect you'll find the task fundamentally hard.

How hard?
Lets see.
Two guys wanted to write an OS.
Seeing current languages not upto their standard they first made themselves a
suitable language.
Would you call their project hard ridiculous and misguided?

Well evidently some people did but fortunately their managers did not interfere.

OTOH some others liked the ideas/outlook enough that they jumped on the 
bandwagon and in short order there were
- a heavy duty compilation system -- parser generators to librarians etc
- editor(s)
- source code systems
- text tools (grep sed) 
- shell

In short a 'Programmer's Work Bench'
http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf

Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
why cant we revamp this 45-year old archaic program=textfile system today?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[pauld11718]

I shall provide with further details

Its about Mathematical modelling of a system. Fortran does one part and python 
does the other part (which I am suppose to provide).
For a time interval tn --> t_n+1, fortran code generates some values, for which 
my python code accepts it as an input. It integrates some data for the same 
time step tn --> tn+1 and fortran computes based on this for the next time step 
t_n+1 --> t_n+2..and this is how loop continues.

Its the fortran code calling my Python executable at all the time interval.

So,
1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows? 

2. As interfacing between fortran/python is via .dat file, so on every 
time-step python executable is called it shall open()/close() .dat file. This 
along with all those 
from  import *'s
are unnecessary.

3. I dont have access to fortran code. I shall provide the python executable 
only, which will take input from .dat file and write to another .dat file. So, 
what is your suggestion regarding socket/pipe and python installation on RAM? I 
have no idea with those.

Isn't there a better way to handle such issues?

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

Re: Python and fortran Interface suggestion

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:48 AM, pauld11718  wrote:
> I am developing a code under Ubuntu(64bit) with python using various 
> libraries. Once done, I need to generate an executable which shall be 
> interfaced with fortran program on account of further collaboration. The 
> python executable shall be used with windows(32bit).
>
> So, I guess everytime my python executable is called by the fortran code on 
> each time step, all those
> from  import *'s
> will be executed and are time consuming (which is not at all required). 
> Moreover, creating executable for windows, using linux is that possible by 
> any means?
>
> What is a better methodology for addresing such interfacing?

Hmm. Let's divide that into several parts.

1) You need to have a Python program that interfaces with Fortran.

Does it need to call functions from a Fortran library, or is it simply
invoked by the Fortran program and that's it? If the latter, it's not
hard. But if you're concerned about startup time, you may want to
consider having your Python program keep running indefinitely, and
have some alternative means of communicating between them. For
instance, Python might create a socket or pipe, which the Fortran
program opens and writes to, and then reads a response. (If you can't
edit the Fortran code at all, it's pretty easy to write a slim stub
executable that does the socket/pipe handling.) Or alternatively,
install Python onto a RAM disk, to improve startup time that way.

2) You need to run the whole kit and caboodle on Windows. The best way
to do this is simply to write clean Python code, and then install a
Windows Python, and everything will work just fine. However, Windows
does tend to have far worse disk cache management than Linux has,
which will exacerbate your startup delays.

3) Above all, you need to know exactly how long things are taking.
Before you start trying to speed things up, first figure out where
it's actually slow. You never know, it might already be fast enough!

Check out some details, see how things go. On the face of it, I'd
guess that what you want to do will be quite doable.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best search algorithm to find condition within a range

[Gene Heskett]

On Sunday 19 April 2015 10:56:49 Marko Rauhamaa wrote:
> Steven D'Aprano :
> > Yay! I'm not the only one who uses or likes Forth!
>
> Out of interest, is Forth different from PostScript? I have done some
> small-time programming in PostScript but nothing in Forth.
>
>
> Marko

No relationship detectable Marko.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Chris Angelico]

On Sun, Apr 19, 2015 at 9:38 PM, BartC  wrote:
> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in C-like
> syntax, and B configure their editor to use Python-like tabbed syntax?

You still haven't addressed the question of the extent of "C-like
syntax" for Python. It's not simply a matter of block delimiters. With
git (and I believe similarly with hg, but I'm not sure about smaller
and/or proprietary source control systems), you can define a pair of
filters which transform a file between the actual source control
system and your checked-out version, so (for instance) you could have
source control work with four-space indents where you work with tab
indents. That one's dead easy. With a little more work, you could
probably rig something up to use keywords or symbols to delimit blocks
of code; braces would be harder, because Python uses them for dicts
and sets, so you'd need some sort of context-aware parsing.

But the biggest problem is that you wouldn't actually be changing
anything else. You'd end up with a bizarre hybrid that uses a tiny bit
of C-like syntax, but entirely Python-like syntax everywhere else. For
example, Python doesn't allow this:

if condition: for i in range(3): do_stuff()

So you'd never truly be able to take advantage of the braces. In fact,
all you'd _really_ have would be a way to key in some braces, commit
to source control, check out again, and have your indentation
auto-fixed for you... and if that's all you want, I think there are
editors which make the reindenting of code a ton easier than that!

As Dave suggests, make yourself a parser which turns *any* legal[1]
Python code into your preferred "C-like" syntax, and another which
performs a perfect reverse transformation. I suspect you'll find the
task fundamentally hard.

ChrisA

[1] Coping with broken Python code is going to be important later on,
but ignore it for now. It's a ton harder to ensure that you can do a
reversible syntactic change on something with syntax errors!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best search algorithm to find condition within a range

[Marko Rauhamaa]

Steven D'Aprano :

> Yay! I'm not the only one who uses or likes Forth!

Out of interest, is Forth different from PostScript? I have done some
small-time programming in PostScript but nothing in Forth.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Python and fortran Interface suggestion

[pauld11718]

I am developing a code under Ubuntu(64bit) with python using various libraries. 
Once done, I need to generate an executable which shall be interfaced with 
fortran program on account of further collaboration. The python executable 
shall be used with windows(32bit).

So, I guess everytime my python executable is called by the fortran code on 
each time step, all those
from  import *'s
will be executed and are time consuming (which is not at all required). 
Moreover, creating executable for windows, using linux is that possible by any 
means?

What is a better methodology for addresing such interfacing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Rustom Mody]

On Sunday, April 19, 2015 at 5:15:07 PM UTC+5:30, BartC wrote:
> On 18/04/2015 03:22, Rustom Mody wrote:
> > On Saturday, April 18, 2015 at 6:49:30 AM UTC+5:30, Dan Sommers wrote:
> >> On Fri, 17 Apr 2015 18:05:52 +0100, BartC wrote:
> >>
> >>> (Actually *I* would quite like to know why languages don't have
> >>> switchable syntax anyway to allow for people's personal preferences.)
> >>
> >> You want LISP, the programmable programming language.
> 
> I don't really want Lisp (not even with a shiny new syntax).

You do... See below

> 
> > You got it!!
> > One of the deep paradoxes in 'getting' programming is that you cant do
> > programming without some syntax; and yet syntax is irrelevant.
> 
> Yes, exactly!
> 
> When I sometimes want to code in Python, why can't I used my usual syntax?
> 
> The tabbing isn't so much of a big deal, but, for example, I normally 
> use ":=" and  "=" for Python's "=" and "==" operators, and it can be a 
> nuisance when switching between syntaxes. (At least Python picks up the 
> use of "=" inside an expression, unlike C...)

See McCarthy's interview
http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy
This is after a life of Lisp and AI -- he died a couple of years after the 
interview.
And in there he repeatedly asks for 'abstract syntax' languages -- as I see it
the same as you are asking

Of course one needs to distinguish Lisp-technology from Lisp-philosophy.
I believe you and McCarthy are asking for Lisp philosophy as I am also:
http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

JFTR: The specific connection with html is somewhat facetious
That programmers are stuck in text files 50 years after everyone else has moved 
on is more serious
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python - block grouping (spaces)

[Mark Lawrence]

On 19/04/2015 13:59, Ben Finney wrote:

BartC  writes:


Why shouldn't A configure his editor to display a Python program in
C-like syntax, and B configure their editor to use Python-like tabbed
syntax?


I don't recall anyone saying that *shouldn't* be done. Feel free to
make, and maintain and support and propagate and keep pace with changes
in everything Python interacts with, a full Python stack that supports
such flexibility.



Presumably we just add BartCPython to the list containing those like 
Python 2.8 and RickedPython.


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

Mark Lawrence

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

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:38 pm, BartC wrote:

> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
> 
> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?
> 
> A can write code in the preferred syntax, and B can view/modify exactly
> the same code in their preferred syntax. What would be the problem?
> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.

The only people who would not care are those alone in a bubble who never
share or discuss code with anyone else. Everyone else will care a great
deal.

How could A and B talk about the code to each other? A says "line 56 is
buggy, you need to replace foo{^bar} with foo@bar" and B replies "what are
you talking about? line 56 says foo.bar and foo@bar is a syntax error".




-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:44 pm, BartC wrote:

> When I sometimes want to code in Python, why can't I used my usual syntax?

When I go to China, why doesn't everyone speak English for my convenience?

I'll tell you what. When you convince the makers of C compilers to support
Python syntax as an alternative, then I'll help with making Python
compilers support C syntax.


-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Dave Angel]

On 04/19/2015 07:38 AM, BartC wrote:


Perhaps you don't understand what I'm getting at.

Suppose there were just two syntaxes: C-like and Python-like (we'll put
aside for a minute the question of what format is used to store Python
source code).

Why shouldn't A configure his editor to display a Python program in
C-like syntax, and B configure their editor to use Python-like tabbed
syntax?

A can write code in the preferred syntax, and B can view/modify exactly
the same code in /their/ preferred syntax. What would be the problem?
(The actual stored representation of the program would be in one of
those two styles, or something else entirely; Lisp-like syntax for
example. It doesn't matter because no-one would care.

(I think much of the problem that most languages are intimately
associated with their specific syntax, so that people can't see past it
to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
whatever the syntax is, who cares? We just want to do an assignment!)



If you make enough simplifying assumptions, of course it's easy and natural.

Assume that a text editor is the only way you'll be viewing the source 
code.  You and your coworkers are willing to each use a prescribed text 
editor, rather than your previous favorite one that doesn't happen to 
support the customization you're suggesting here.  You're not going to 
use a version control system, nor diff programs.  You're not going to 
post your code in messages on the internet.


You're not going to display error messages showing source code, from a 
running system.  You're not going to use the interactive debugger.


You're not going to copy code from one place to another without copying 
sufficient context to be able to reconstruct the funny syntax.


You're going to permit only one such variation, and it's just big enough 
that it's always obvious which version of the code is being examined (by 
programs or by humans) [1]


You're not going to use eval()  [good].  You're not going to examine 
source code that comes from 3rd party or the standard library.


The changes you want are all completely reversible, regardless of 
interspersed comments, and when reversed, preserve spacing and 
characters completely in the way that each user expects to see the code. 
 And they are reversible even if you only have a small fragment of the 
code.


I implemented something analogous to such a system 40 years ago.  But on 
that system, nearly all of the restrictions above applied.  There was no 
clipboard, no version control, no internet.  Programs had to fit in 64k. 
Each line stood completely on its own, so context was not a problem.  i 
wrote the text editor, much of the interactive debugger, the listing 
utility, the pretty printer, the cross reference program, etc.  So they 
were consistent.  Further, we had a captive audience -- if they didn't 
like it, they could buy the competitor's product, which had similar 
constraints.  Would I do things differently now?  You bet I would.  At 
least if I could upgrade the memory addressability to a few megs.



For the purposes you've described so far, I'd suggest just writing two 
translators, one a mirror image of the other.  Invoke them automatically 
on load and save in your personal editor  And learn to live with both 
syntaxes, because it will leak.  And if it's really not reversible, 
don't use them when you're editing somebody else's code.  And even if it 
is reversible, don't use them when you edit code you plan to post on the 
internet.


[1] So for example  a=b can not mean assignment in one version, and a 
comparison in the other.  Because then you'd need to either discover 
that it's a line by itself, or within an if expression, or ...  But you 
could arrange two disjoint sets of symbols readily enough.  In your 
version, require either := or ==, and make = just plain illegal.


PS.  I haven't examined the costs in tool development to support this. 
Just whether it's practical.  You can easily discount any one of these 
constraints, but taken as a whole, they very much limit what you can do.


--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: Best search algorithm to find condition within a range

[Steven D'Aprano]

On Sun, 19 Apr 2015 04:08 am, Albert van der Horst wrote:

> Fire up a lowlevel interpreter like Forth. (e.g. gforth)

Yay! I'm not the only one who uses or likes Forth!

Have you tried Factor? I'm wondering if it is worth looking at, as a more
modern and less low-level version of Forth.


-- 
Steven

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

Re: New to Python - block grouping (spaces)

[Ben Finney]

BartC  writes:

> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?

I don't recall anyone saying that *shouldn't* be done. Feel free to
make, and maintain and support and propagate and keep pace with changes
in everything Python interacts with, a full Python stack that supports
such flexibility.

> A can write code in the preferred syntax, and B can view/modify
> exactly the same code in /their/ preferred syntax. What would be the
> problem?

I can only invite you to embark on the project of a Python compiler
which accepts such a switchable syntax, maintain it consistently over
the lifetime of a project with significant numbers of people
collaborating using different switch settings for that syntax, and
working on the same code with different editor settings.

Once you've done that, report back to us about the problems encountered.

> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.

No-one except the people who have to maintain and debug and continue
developing a Python that supports multiple radically-different syntaxes.
I suspect the efforts of those people is being discounted in your vision.

-- 
 \   “To have the choice between proprietary software packages, is |
  `\  being able to choose your master. Freedom means not having a |
_o__)master.” —Richard M. Stallman, 2007-05-16 |
Ben Finney

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

Re: New to Python - block grouping (spaces)

[BartC]

On 18/04/2015 03:22, Rustom Mody wrote:

On Saturday, April 18, 2015 at 6:49:30 AM UTC+5:30, Dan Sommers wrote:

On Fri, 17 Apr 2015 18:05:52 +0100, BartC wrote:


(Actually *I* would quite like to know why languages don't have
switchable syntax anyway to allow for people's personal preferences.)


You want LISP, the programmable programming language.


I don't really want Lisp (not even with a shiny new syntax).


You got it!!
One of the deep paradoxes in 'getting' programming is that you cant do
programming without some syntax; and yet syntax is irrelevant.


Yes, exactly!

When I sometimes want to code in Python, why can't I used my usual syntax?

The tabbing isn't so much of a big deal, but, for example, I normally 
use ":=" and  "=" for Python's "=" and "==" operators, and it can be a 
nuisance when switching between syntaxes. (At least Python picks up the 
use of "=" inside an expression, unlike C...)


--
Bartc

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

Re: New to Python - block grouping (spaces)

[BartC]

On 18/04/2015 03:22, Ben Finney wrote:

BartC  writes:


(Actually *I* would quite like to know why languages don't have
switchable syntax anyway to allow for people's personal preferences.)


Which people's personal preferences? Are these the same people who have
such passionate disagreement about tabs versus spaces?

If you only write programs that will only ever be read by you and no-one
else, feel free to maintain a fork of Python (or any other language)
that suits your personal preferences.

Too much effort? Or maybe you sometimes want others, whose preferences
may not exactly match yours, to collaborate on programs you write? Then
I think you have your answer of why such personal perferences are not
switchable in the languages we actually use.


Perhaps you don't understand what I'm getting at.

Suppose there were just two syntaxes: C-like and Python-like (we'll put 
aside for a minute the question of what format is used to store Python 
source code).


Why shouldn't A configure his editor to display a Python program in 
C-like syntax, and B configure their editor to use Python-like tabbed 
syntax?


A can write code in the preferred syntax, and B can view/modify exactly 
the same code in /their/ preferred syntax. What would be the problem? 
(The actual stored representation of the program would be in one of 
those two styles, or something else entirely; Lisp-like syntax for 
example. It doesn't matter because no-one would care.


(I think much of the problem that most languages are intimately 
associated with their specific syntax, so that people can't see past it 
to what the code is actually saying. a=b, a:=b, b=>a, (setf a b), 
whatever the syntax is, who cares? We just want to do an assignment!)


--
Bartc







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

Re: sorting list by multiple criteria and grouping alphabetically in python

[Chris Angelico]

On Sat, Apr 18, 2015 at 5:56 PM, Ahamed Farook  wrote:
> sorted(lsNearCities, key=operator.itemgetter(1,0))

This doesn't sort the list, it constructs a new one - and then
promptly discards it. What you want is the .sort() method on the list
object. As your code is incomplete, I can't say if there are any other
issues in it, but try switching over to the sort method and seeing if
that does what you want.

All the best!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list