Re: New to Python - block grouping (spaces)
In article , Rustom Mody wrote: >On Monday, April 20, 2015 at 4:00:16 PM UTC+5:30, Steven D'Aprano wrote: >> On Monday 20 April 2015 12:43, Rustom Mody wrote: >> >> > You've a 10-file python project in which you want to replace function 'f' >> > by function 'longname' >> > How easy is it? >> >> About a thousand times easier than the corresponding situation: >> >> You have ten PDF files in which you want to replace the word "f" with the >> word "longname". >> > >To paraphrase Pauli's "This is not even wrong" >this is not even a strawman On the contrary it is the last word in this discussion. At least the last word I need or will read. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Saturday, April 25, 2015 at 12:57:34 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > Some rambly ruminations on switchable (aka firstclass) syntax > > http://blog.languager.org/2015/04/poverty-universality-structure-0.html > > I'll ruminate in response: Thanks for a connoisseur review First time hearing of kernel. Following some link from there came to this Hudak-news: http://www.caringbridge.org/visit/hudak/journal/view/id/5538f5cea589b4216c04438a [Hudak is a scheme-doyen - Yale-scheme: T dialect - and later Haskell] Enough OT now that I should stop -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
Rustom Mody : > Some rambly ruminations on switchable (aka firstclass) syntax > http://blog.languager.org/2015/04/poverty-universality-structure-0.html I'll ruminate in response: * The awesomeness of lisp is in lambda calculus and not in macros. * Lisp syntax is actually not quite first-class: Guile: scheme@(guile-user)> let While compiling expression: ERROR: Syntax error: unknown location: let: bad let in form let Elisp: if Debugger entered--Lisp error: (void-variable if) eval(if nil) eval-last-sexp-1(t) eval-last-sexp(t) eval-print-last-sexp() call-interactively(eval-print-last-sexp nil nil) * Syntax is first-class in Kernel http://web.cs.wpi.edu/~jshutt/kernel.html>. Too bad Kernel chose a naming scheme (NPI) that makes it incompatible with scheme. * Beginning schemers are infatuated with defining new syntax (macros). What results is unreadable code. * The age-old lisp idea of application-specific languages is perfectly all right, though. And most to the point: * Even with its syntax machinery, the lisp parser will reject Python and C source code. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Friday, April 17, 2015 at 10:36:13 PM UTC+5:30, BartC wrote: > (Actually *I* would quite like to know why languages don't have > switchable syntax anyway to allow for people's personal preferences.) Some rambly ruminations on switchable (aka firstclass) syntax http://blog.languager.org/2015/04/poverty-universality-structure-0.html -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/24/2015 01:31 AM, 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. >> > > First paragraph from > http://www.talkpythontome.com/episodes/show/4/enterprise-python-and-large-scale-projects > > > Mahmoud is lead developer of the Python Infrastructure team at > eBay/PayPal and he has some amazing facts and studies to discuss about > the truths and myths using Python for real projects. We discuss how eBay > is using Python internally for many large-scale uses. Then we move on to > discuss the 10 myths of enterprise Python, such as Python is not > compiled, Python is weakly-typed, Python does not scale, and more. Thanks for posting this. Very interesting. Unfortunately the original poster is long gone and will never benefit from this. Too bad. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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. First paragraph from http://www.talkpythontome.com/episodes/show/4/enterprise-python-and-large-scale-projects Mahmoud is lead developer of the Python Infrastructure team at eBay/PayPal and he has some amazing facts and studies to discuss about the truths and myths using Python for real projects. We discuss how eBay is using Python internally for many large-scale uses. Then we move on to discuss the 10 myths of enterprise Python, such as Python is not compiled, Python is weakly-typed, Python does not scale, and more. -- 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)
On 22/04/2015 12:37, Rustom Mody wrote: On Wednesday, April 22, 2015 at 9:35:34 AM UTC+5:30, llanitedave wrote: On Tuesday, April 21, 2015 at 8:12:07 PM UTC-7, Rustom Mody wrote: On Wednesday, April 22, 2015 at 3:05:57 AM UTC+5:30, llanitedave wrote: On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: If only Galileo had had you as lawyer... Well, I'd asked Giordano Bruno for a positive recommendation. For some inexplicable reason, he declined. Maybe got too steamed-up pursuing high philosophy?? I think it had something to do with multiple inheritance. Anyway, back in those days using indentation rather than braces was definitely considered heresy. Along with braces, I hear the PEC¹ is preparing other instruments of pleasure like the rack for you and me for persisting in profanities in these divine precincts. - ¹Python Ecumenical Council If the PEC were going to use any weapon of torture it would be the Comfy Chair, unless somebody borrowed the time machine and destroyed it before it could be put to use. -- 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)
On Wednesday, April 22, 2015 at 9:35:34 AM UTC+5:30, llanitedave wrote: > On Tuesday, April 21, 2015 at 8:12:07 PM UTC-7, Rustom Mody wrote: > > On Wednesday, April 22, 2015 at 3:05:57 AM UTC+5:30, llanitedave wrote: > > > On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: > > > > If only Galileo had had you as lawyer... > > > > > > Well, I'd asked Giordano Bruno for a positive recommendation. For some > > > inexplicable reason, he declined. > > > > Maybe got too steamed-up pursuing high philosophy?? > > I think it had something to do with multiple inheritance. Anyway, back in > those days using indentation rather than braces was definitely considered > heresy. Along with braces, I hear the PEC¹ is preparing other instruments of pleasure like the rack for you and me for persisting in profanities in these divine precincts. - ¹Python Ecumenical Council -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Tuesday, April 21, 2015 at 8:12:07 PM UTC-7, Rustom Mody wrote: > On Wednesday, April 22, 2015 at 3:05:57 AM UTC+5:30, llanitedave wrote: > > On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: > > > If only Galileo had had you as lawyer... > > > > Well, I'd asked Giordano Bruno for a positive recommendation. For some > > inexplicable reason, he declined. > > Maybe got too steamed-up pursuing high philosophy?? I think it had something to do with multiple inheritance. Anyway, back in those days using indentation rather than braces was definitely considered heresy. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Wednesday, April 22, 2015 at 3:05:57 AM UTC+5:30, llanitedave wrote: > On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: > > If only Galileo had had you as lawyer... > > Well, I'd asked Giordano Bruno for a positive recommendation. For some > inexplicable reason, he declined. Maybe got too steamed-up pursuing high philosophy?? -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: > On Tuesday, April 21, 2015 at 9:01:08 PM UTC+5:30, llanitedave wrote: > > On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > > > > > > > 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 > > > > Difference is, Aristotle was flat-out, objectively wrong. > > > > Unix with text files, not so much. > > If only Galileo had had you as lawyer... Well, I'd asked Giordano Bruno for a positive recommendation. For some inexplicable reason, he declined. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Tuesday, April 21, 2015 at 9:01:08 PM UTC+5:30, llanitedave wrote: > On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > > > > 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 > > Difference is, Aristotle was flat-out, objectively wrong. > > Unix with text files, not so much. If only Galileo had had you as lawyer... -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > 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 Difference is, Aristotle was flat-out, objectively wrong. Unix with text files, not so much. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Monday, April 20, 2015 at 9:14:23 AM UTC+5:30, Chris Angelico wrote: > I definitely don't see how a non-text source code format would improve > on it. Feel like elaborating? You are putting emphasis on the 'non'. This puts you into an oscillatory system between tautology and contradiction: How can something which is NOT be something? -- contradiction It is something else -- tautology If you dont put the emphasis on the not but on 'structured text' it may be more meaningful; eg html html is not 'not-text' -- you can edit it in a text editor alright. However if you edit it in a html-editor -- mozilla composer, seamonkey, or any of zillion web versions -- you get (at least) two views -- text vs structured In the text (ironically also called html) view it behaves like a half-assed text-editor In the structured view it renders the html structure (somewhat) So a table does not show as etc but actually as cells. This prevents trivial counting/off-by-one errors. After the gross-layout is taken care of you can switch to text mode and add fancy html attributes if needed. Likewise having ready access to the AST of a program would be neat So for example when I used to do a lot of lisp, my editor was set up so that - cursor arrows behaved like normal cursor arrows - keypad arrows moved up/down/along S-exp ie they were tree movements -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 20/04/2015 11:30, Steven D'Aprano wrote:
On Monday 20 April 2015 12:43, Rustom Mody wrote:
You've a 10-file python project in which you want to replace function 'f'
by function 'longname'
How easy is it?
About a thousand times easier than the corresponding situation:
You have ten PDF files in which you want to replace the word "f" with the
word "longname".
Why would the PDF example be particularly difficult? (I assume they can
simply be processed individually.)
Some tool would be used to edit the textual contents of the files, and,
in the absence of any more specific instructions (there being embedded
code examples for instance, or some literal uses of "f", or it's verse
that still needs to rhyme), then you just replace each whole-word "f"
with "longname".
(It might well be 1000 times harder if the PDFs contained full-featured
Postscript where all the "f"s are generated at runtime, or their glyphs
are formed with highly elaborate graphics.)
You have identified a weakness in the current Python ecosystem. Our
automated refactoring tools are currently quite weak and primitive.
I'm sure everyone is already aware of the difficulties with doing this
with Python code, but apart from comments and strings, there are
examples such as this:
if cond:
def f():
print ("This is F")
else:
f=3.142
x=f
In this last line, it's not possible to tell whether f refers to the
function, or the number. (I assume the requirement is to change calls to
f(), or any references to the name, to longname(), as well as the defs.)
Even harder is:
eval(s)
where the string s may also contain references to f.
There is also code that may be commented out temporarily that you want
to change, and other comments that you don't want to change. Etc.
With some languages the task is simpler, as what is or isn't a valid
reference to "f" can be determined by examining the source code.
(Although C gives Python a run for its money by being able to use its
macro system to make certain code impossible to analyse from the static
sources.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Monday, April 20, 2015 at 4:00:16 PM UTC+5:30, Steven D'Aprano wrote: > On Monday 20 April 2015 12:43, Rustom Mody wrote: > > > You've a 10-file python project in which you want to replace function 'f' > > by function 'longname' > > How easy is it? > > About a thousand times easier than the corresponding situation: > > You have ten PDF files in which you want to replace the word "f" with the > word "longname". > To paraphrase Pauli's "This is not even wrong" this is not even a strawman If you want a realistic example its something like castXML or its more well-known predecessor gccXML https://github.com/CastXML/CastXML/blob/master/doc/manual/castxml.1.rst [With some hesitation because I dont like XML but anyway in the abstract thats my point] > > You have identified a weakness in the current Python ecosystem. Our > automated refactoring tools are currently quite weak and primitive. I'm only > aware of one, Bicycle Repair Man, which as far as I know is no longer under > active development. Well there is rope if thats what you want. > But I think the reason for that is not because Python is > text based. Java is also text based and it has powerful refactoring tools. > In Python's case: > > - Python projects tend to be smaller and less enterprisey than Java > projects; > > - Python syntax is easier to read (less cruft) and therefore manual > refactoring is simpler, compared to Java. All this is true but a bit far afield from what I am saying: These examples are about how to keep going with these silos as they are I am talking of how the silos can be less impenetrable -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Monday 20 April 2015 12:43, Rustom Mody wrote: > You've a 10-file python project in which you want to replace function 'f' > by function 'longname' > How easy is it? About a thousand times easier than the corresponding situation: You have ten PDF files in which you want to replace the word "f" with the word "longname". You have identified a weakness in the current Python ecosystem. Our automated refactoring tools are currently quite weak and primitive. I'm only aware of one, Bicycle Repair Man, which as far as I know is no longer under active development. But I think the reason for that is not because Python is text based. Java is also text based and it has powerful refactoring tools. In Python's case: - Python projects tend to be smaller and less enterprisey than Java projects; - Python syntax is easier to read (less cruft) and therefore manual refactoring is simpler, compared to Java. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Monday 20 April 2015 18:38, Gregory Ewing wrote: > Steven D'Aprano wrote: >> Wheels have been round for thousands of years! Why can't we >> try something modern, like triangular wheels? > > http://en.wikipedia.org/wiki/Reuleaux_triangle > > http://blog.geomblog.org/2004/04/square-wheels.html I *knew* some smart-arse would mention those :-) There's always one... it's usually me, but there's always one... :-) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
I work in research and mainly use Fortran and Python. I haven't had any problem with the python indentation. I like it, I find it simple and easy. Well, sometimes I may forget to close an IF block with an ENDIF, in Fortran, so used I am on ending a block just decreasing the indentation, not a big problem actually (always spotted by the compiler). -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
Steven D'Aprano wrote: Wheels have been round for thousands of years! Why can't we try something modern, like triangular wheels? http://en.wikipedia.org/wiki/Reuleaux_triangle http://blog.geomblog.org/2004/04/square-wheels.html -- Greg -- 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: >> 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: New to Python - block grouping (spaces)
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)
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)
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)
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)
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: New to Python - block grouping (spaces)
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)
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)
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)
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)
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)
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: New to Python - block grouping (spaces)
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: New to Python - block grouping (spaces)
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)
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)
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: New to Python - block grouping (spaces)
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
Re: New to Python - block grouping (spaces)
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: New to Python - block grouping (spaces)
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: New to Python - block grouping (spaces)
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: New to Python - block grouping (spaces)
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)
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)
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)
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)
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)
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)
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)
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: New to Python - block grouping (spaces)
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: New to Python - block grouping (spaces)
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)
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)
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)
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)
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: New to Python - block grouping (spaces)
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)
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)
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: New to Python - block grouping (spaces)
Rustom Mody : >> It would be possible to define a canonical AST storage format. Then, >> your editor could "incarnate" the AST in the syntax of your choosing. >> >> [...] > > Things like comments are a headache -- they have to be shoved into the > AST rather artificially I don't think comments would be so bad assuming you don't write comments like this: result = principal * (1 + interest_rate / 100) # expressed as percentage ^ I know, I know -- that's a lot to assume. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Saturday, April 18, 2015 at 12:30:49 PM UTC+5:30, 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. > > A Python source file is an AST storage format, only it's not canonical. > IOW, more than one Python source file can produce identical AST's. That > isn't a problem for the specialized editors but it can be a problem for > text editors, source code control etc. Things like comments are a headache -- they have to be shoved into the AST rather artificially -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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. A Python source file is an AST storage format, only it's not canonical. IOW, more than one Python source file can produce identical AST's. That isn't a problem for the specialized editors but it can be a problem for text editors, source code control etc. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
Michael Torrie : > There was a version of Python (compatible at a bytecode level) that did > implement braces for blocks. It was called pythonb, but it is now > defunct, understandably for lack of interest. http://www.perl.com/pub/2001/04/01/parrot.htm> LW: Sure. I'd probably write the program something like this: while(@line = Sys::Stdin->readline()): continue_next if $line[0] =eq= "#": print @line; } Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/17/2015 07:22 PM, 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. I always find discussions like these rather amusing. From a practical standpoint, no matter now passionately someone feels about this sort of thing, it is ultimately totally irrelevant. The language (whatever language or subject it is) is already defined. You either use it as it exists or go on to something else. EOD! (End-of-discussion). The exception, of course, is if you are actively involved in the defining and creating something new. But otherwise, take it or leave it. Naturally you are permitted to have your own opinions, whether passionate or otherwise, but it's not worth arguing about. -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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. 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. I dont believe one can ever get that without some experience of Lisp -- Minsky's Turing award lecture is an elaboration of this: http://web.media.mit.edu/~minsky/papers/TuringLecture/TuringLecture.html -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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. -- \ “It is the integrity of each individual human that is in final | `\examination. On personal integrity hangs humanity's fate.” | _o__) —Richard Buckminster Fuller, _Critical Path_, 1981 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/17/2015 11:05 AM, BartC wrote: > He wanted to know if there was a simple syntax wrapper for it. That > seems reasonable enough. > > (Actually *I* would quite like to know why languages don't have > switchable syntax anyway to allow for people's personal preferences.) There was a version of Python (compatible at a bytecode level) that did implement braces for blocks. It was called pythonb, but it is now defunct, understandably for lack of interest. It was just a modification to the parser is all. So it's completely doable. In fact one could probably do it with a preprocessor of some kind. But there's little utility in it. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Sat, Apr 18, 2015 at 3:05 AM, BartC wrote: > (Actually *I* would quite like to know why languages don't have switchable > syntax anyway to allow for people's personal preferences.) Why do it? What's the advantage of calling two different syntaxes one language? Simpler to just call them two separate languages - maybe two languages that share some sort of runtime, but two languages. For instance, Java bytecode doesn't have to be created from Java source code, but we don't consider NetRexx to be a "switchable syntax" for Java. It's a completely separate language that compiles to a .class file. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
sohcahto...@gmail.com: > Can someone still write ugly code in Python? No doubt about it. But at > least code blocks will be easily deciphered. That's how I was originally convinced about Python: a coworker with a terrible C++ "handwriting" produced neat, legible code in Python. I'm still slightly annoyed by some downsides in the indentation style, but the practical benefits more than compensate. Also, the semicolon rules of JavaScript and Go are horrible compared with the simple line continuation rules of Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Friday, April 17, 2015 at 10:06:13 AM UTC-7, BartC wrote:
> On 17/04/2015 17:28, Grant Edwards wrote:
> > On 2015-04-17, Michael Torrie wrote:
>
> >> However, it may be that people recognized that you likely had made up
> >> your mind already, and posted accordingly.
> >
> > I think most of us just assumed he was just trolling and were playing
> > along for the fun of it.
>
> What was troll-like about it? The OP made it clear he didn't like the
> way Python made use of tabs, but he didn't want an argument about it or
> to be persuaded to change his mind or change anyone else's.
>
> He wanted to know if there was a simple syntax wrapper for it. That
> seems reasonable enough.
>
> (Actually *I* would quite like to know why languages don't have
> switchable syntax anyway to allow for people's personal preferences.)
>
> --
> Bartc
Allowing a switchable syntax only makes the fight even worse. If you made
braces in Python an option to use instead of whitespace block delimiting, then
there'd be a ton of infighting among Python developers over which to use. Just
look at C/C++ developers fighting over where the opening brace goes.
By having the language itself forcing a specific style, it requires everyone
using it to either shut up and get over it, or just don't use the language.
Personally, I like the Python style. It forces people to write code that is at
least somewhat good to look at. Not like monstrosities like this that I see
from newbie (hell, even professional) C/C++ programmers:
if (something > something_else)
{
result = do_something();
if (!result){
printf("Error!\n")
return 0;
}
do_other_stuff();
}
Can someone still write ugly code in Python? No doubt about it. But at least
code blocks will be easily deciphered.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Friday, April 17, 2015 at 10:36:13 PM UTC+5:30, BartC wrote: > (Actually *I* would quite like to know why languages don't have > switchable syntax anyway to allow for people's personal preferences.) Mess in programming syntax is because of html: http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 17/04/2015 17:28, Grant Edwards wrote: On 2015-04-17, Michael Torrie wrote: However, it may be that people recognized that you likely had made up your mind already, and posted accordingly. I think most of us just assumed he was just trolling and were playing along for the fun of it. What was troll-like about it? The OP made it clear he didn't like the way Python made use of tabs, but he didn't want an argument about it or to be persuaded to change his mind or change anyone else's. He wanted to know if there was a simple syntax wrapper for it. That seems reasonable enough. (Actually *I* would quite like to know why languages don't have switchable syntax anyway to allow for people's personal preferences.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 2015-04-17, Michael Torrie wrote: > On 04/16/2015 08:52 AM, Blake McBride wrote: >> Thanks for all the responses. I especially like the Pike pointer. >> To be clear: > [troll bait elided] > While it appears that you had already made up your mind about the > matter long before posting, and perhaps was just looking for > vindication, I feel that some of the snide replies you got were just > not tremendously professional. There are people who post to Usenet professionally? And I've been doing it all these years _for_free_? And, it's not like there's some sort of Olympics for which I needed to maintain my amateur standing. > However, it may be that people recognized that you likely had made up > your mind already, and posted accordingly. I think most of us just assumed he was just trolling and were playing along for the fun of it. -- Grant Edwards grant.b.edwardsYow! As President I have at to go vacuum my coin gmail.comcollection! -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 08:52 AM, Blake McBride wrote: > Thanks for all the responses. I especially like the Pike pointer. > To be clear: > > 1. I don't think languages should depend on invisible elements to > determine logic. > > 2. Having been an employer, it is difficult to force programmers to > use any particular editor or style. Different editors handle tabs > and spaces differently. This is all a bloody nightmare with Python. > > 3. Languages that use braces (or the like) can be run through a > program beautifier to correct the indentation. You are just screwed > in Python. So, Python may be a cute language for you to use as an > individual, but it is unwieldy in a real development environment. > > 4. Language beautifiers used on bracey languages removes all > arguments in favor of an off-side language. While it appears that you had already made up your mind about the matter long before posting, and perhaps was just looking for vindication, I feel that some of the snide replies you got were just not tremendously professional. However, it may be that people recognized that you likely had made up your mind already, and posted accordingly. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
Op 16-04-15 om 19:10 schreef Steven D'Aprano: > On Thu, 16 Apr 2015 08:51 pm, BartC wrote: > >> On 16/04/2015 06:49, Steven D'Aprano wrote: >>> On Thursday 16 April 2015 14:07, Blake McBride wrote: Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code? If so, where can I find it? >>> No more bugs from accidentally forgetting to use optional braces! >> You get bugs instead from mistakenly using the wrong indentation or >> losing the correct indentation (accidentally pressing the wrong key for >> example). > That's nothing! Python gives you absolutely no protection from accidentally > typing: > > > x += 1 > > when you actually wanted: > >y -= 2 I find this a bit disingenuous. Each time assignment as an expression comes up, so that it would be possible to have an assignment in a if or while condition, few of the regulars seem to have a problem with the argument that the current choice protects against a particular kind of bug. The fact that braces protect against a kind of bug you care less about, is just your preference. That doesn't mean a different preference is somehow worthy of ridicule. Mistakes of all kinds happen and I see no reason to ridicule someone for wishing protect against one kind of mistake, while yourself having the protection you like. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 01:41 PM, Steven D'Aprano wrote:
>2. Having been an employer, it is difficult to force programmers to use
>any particular editor or style. Different editors handle tabs and spaces
>differently. This is all a bloody nightmare with Python.
Do you really expect us to believe for a microsecond that the choice
between "4 spaces" or "tab" is worse than the C brace wars?
You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.
The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.
Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)
I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.
block = {statement_1; statement_2; ...}
The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time.
But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 16/04/2015 18:10, Steven D'Aprano wrote:
On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
On 16/04/2015 06:49, Steven D'Aprano wrote:
On Thursday 16 April 2015 14:07, Blake McBride wrote:
Is there a utility that will allow me to write Python-like code that
includes some block delimiter that I can see, that converts the code
into
runnable Python code? If so, where can I find it?
No more bugs from accidentally forgetting to use optional braces!
You get bugs instead from mistakenly using the wrong indentation or
losing the correct indentation (accidentally pressing the wrong key for
example).
That's nothing! Python gives you absolutely no protection from accidentally
typing:
x += 1
when you actually wanted:
y -= 2
As I'm sure you will agree, it is an easy mistake to make.
I meant hitting Backspace or Delete.
But also, sometimes you post code to Usenet and you find leading tabs
have been stripped out. With Python code, that's problematical.
I'm not impressed by arguments "braces protect you from accidentally hitting
tab too many times (or too few)". Um, okay. Don't people read their own
code? How do you not notice that you've indented it wrongly?
Take:
if cond:
stmt1
stmt2
stmt3
and:
if cond:
stmt1
stmt2
stmt3
which one is correct? Is there a tab too many, or one too few? Or two
too many? Now, much as I dislike C-style braces, at least it is a little
more resilient:
if (cond) {
stmt1;
stmt2;
stmt3;
}
or:
if (cond) {
stmt1;
stmt2;
}
stmt3;
One 'if' clearly has three statements, and the other has two, and you
are confident enough to fix the tabbing errors without consequences.
while braces without indentation are horribly opaque:
code code code code code code code { code } code code code { code
code code { code code code } code { code { code { code code code
{ code code } code code { code code } } } } code } code
It seems to work well enough with expressions:
x = (a * (b+c) * d) / e
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 16.04.15 08:49, Steven D'Aprano wrote: I'm not aware of any pre-processor tools for Python that will syntactically check that added braces match the indentation. Such a tool would be unPythonic: if they match, the braces are redundant and are not needed, and if they do not match, then the compiler (or preprocessor) should not guess whether the indentation is right or the braces are right. But if you enforce the rule that braces must match indentation, then the braces are redundant! If you find such a preprocessor, or write your own, feel free to use it. But you won't get any respect from experienced Python programmers: we use Python in part to get away from braces, we're not chomping at the bit to put them back in. https://hg.python.org/cpython/raw-file/default/Tools/scripts/pindent.py -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Thu, 16 Apr 2015 10:59:44 -0700, Rustom Mody wrote: > On Thursday, April 16, 2015 at 9:37:57 AM UTC+5:30, Blake McBride wrote: >> Greetings, >> >> I am new to Python. I am sorry for beating what is probably a dead >> horse but I checked the net and couldn't find the answer to my >> question. > > Kudos for making dead horses fly [33 posts in 13 hours and going strong] Catapult and a dream, man. Catapult and a dream. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 11:08 AM, alister wrote: On Thu, 16 Apr 2015 08:01:45 -0700, Blake McBride wrote: As a side note, I bought a few books on Python from Amazon for use on my Kindle. At least one of the books has the formatting for the Kindle messed up rendering the meaning of the program useless. Case in point. Blake A poor quality book You can write bad books for any language I do sympathise as this is something you cannot easily tell before purchase (although there as so many good guides available on line I don't think there is much benefit in buying a book) Some publishers are worse about this than others. Packt (www.packtpub.com) has some decent material, but absolutely incompetent when it comes to formatting python code in a Kindle .mobi file. I don't think I've ever seen *any* errata published for any of their books. I long since decided that anything I see from Packt that I want to read... I might find it on Amazon, but I go to Packt's site and purchase the PDF. They have a harder time screwing that up, apparently. O'Reilly, on the other hand, gets it right. Period. -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Thu, 16 Apr 2015 08:01:45 -0700, Blake McBride wrote: > As a side note, I bought a few books on Python from Amazon for use on my > Kindle. At least one of the books has the formatting for the Kindle > messed up rendering the meaning of the program useless. > > Case in point. > > Blake A poor quality book You can write bad books for any language I do sympathise as this is something you cannot easily tell before purchase (although there as so many good guides available on line I don't think there is much benefit in buying a book) -- Talking much about oneself can also be a means to conceal oneself. -- Friedrich Nietzsche -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On Thu, 16 Apr 2015 16:09:13 +0200, Antoon Pardon wrote: > On 04/16/2015 03:18 PM, alister wrote: > > >>> As is argueing against a real position instead of making something up. >>> Nobody is argueing for arbitrary indentation. >> May I suggest that you give it a try for a month, perhaps re-writing a >> small program you already have in a pythonic style (don't simply write >> c in python) & see if your opinion changes. >> >> if not then other suggestions that python is not a language of choice >> for you may be appropriate. >> >> be warned you may find it creates (or increases ) an extreme dislike >> for C & other languages that require braces & semicolons, it did for me >> (especially the semi-colon!) > > I think you are mistaking me for someone else. I have been using python > since before 2000. I went from not liking the forced indentation to not > being bothered with it to not liking it again. > > I also think that one doesn't need to discard a language just because > one doesn't like this particular feature. One can think the other > characteristics of the language are positive enough one can live with > this small annoyance. This suggestion was aimed at the Original poster. -- Your mode of life will be changed for the better because of new developments. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On Thu, 16 Apr 2015 14:44:15 +0100, BartC wrote: > On 16/04/2015 14:18, alister wrote: >> On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote: > >>> Nobody is argueing for arbitrary indentation. >> >> May I suggest that you give it a try for a month, perhaps re-writing a >> small program you already have in a pythonic style (don't simply write >> c in python) & see if your opinion changes. > > You mean try writing pure Python for a month? Yes, you can get used to > anything. But that doesn't take away from the issues that some people > have with its indentation. In my case, that would be the following > (apart from the extra fragility of the code which you can't argue with): code fragility? google "goto fail", this could not have happened with python. he try it suggestion was not to get you get used to it but to give you enough experience to show that your perceived problems are actually no existent FUD > > * I need some closure, some indication of where the end of a block is. > Otherwise how do I know I'm looking at the last statement, or whether > there is more on the next page or further down the screen? oh please if you are not going to look at the code you cant tell in a brace delimited language either & if you do open your eyes to scan the code it is easier to see in python because the indentation is 100% trustworthy where as with C you have to be careful that a brace has not been inserted somewhere unexpected. > > Even when I can see what follows the block, I can only infer that this > is the end of the block because I eventually hit some other arbitrary > construct with less indentation, not something specifically signalling > the end of /that/ block. it is not arbitrary the un-indent is the signal > > (This would come up when using copy&paste for example. If I've > accidentally left out the last line of a block, I won't know about it > until the code later doesn't work.) > * I modify code a lot, adding and removing extra nested blocks all the > time. My editor can't indent or un-indent blocks without a lot of manual > typing. get a decent editor designed fro programming > With block-delimited schemes, this isn't an issue, as temporary > lack of correct indentation isn't crucial. > > (However, given a choice of only brace-delimited blocks, and Python > style, I'd go for the latter! I have a longer list of complaints for > C-style braces.) so you are already 90% of the way there & just need to grasp the fact that the braces are redundant if you (sensibly) stick to a rigid formatting style -- Kiss your keyboard goodbye! -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Thursday, April 16, 2015 at 9:37:57 AM UTC+5:30, Blake McBride wrote: > Greetings, > > I am new to Python. I am sorry for beating what is probably a dead horse but > I checked the net and couldn't find the answer to my question. Kudos for making dead horses fly [33 posts in 13 hours and going strong] -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 2015-04-17 03:10, Steven D'Aprano wrote: > And there there was the time I edited some code written by my boss. > I intended to write a comment: > > # FIXME: this function is a little slow and should be optimized. > > but I hit the wrong key a couple of times and wrote: > > # This is a steaming pile of guano written by a drooling > # moron who shouldn't be allowed near a computer. It needs > # to be deleted with prejudice, and the hard drive and all > # backup tapes set on fire just to be sure. > > As I'm sure you will agree, it is an easy mistake to make. Phew, glad I'm not the only one to do that. Fortunately, I had one of those code-reformatters the OP talks about, and it fixed the mistake for me. :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On 16/04/2015 14:44, BartC wrote: * I modify code a lot, adding and removing extra nested blocks all the time. My editor can't indent or un-indent blocks without a lot of manual typing. With block-delimited schemes, this isn't an issue, as temporary lack of correct indentation isn't crucial. The year is 2015, not 1520. Get an editor that can indent and dedent code, there's tens if not hundreds of the things, IDLE included. -- 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)
On Fri, 17 Apr 2015 12:52 am, Blake McBride wrote: > Thanks for all the responses. I especially like the Pike pointer. To be > clear: > > 1. I don't think languages should depend on invisible elements to > determine logic. Icompletelyagreethatinvisibleelementsareterribleandalllanguagesshouldeliminatethemcompletely.Anythingelsewillharmreadabilityandmakesitmuchhardertofollowthelogic. > 2. Having been an employer, it is difficult to force programmers to use > any particular editor or style. Different editors handle tabs and spaces > differently. This is all a bloody nightmare with Python. Do you really expect us to believe for a microsecond that the choice between "4 spaces" or "tab" is worse than the C brace wars? If you, as an employer, cannot get your programmers to follow your in-house style requirements, then what instructions can you get them to follow? Do they even bother to show up? Other than on "lunch is on the boss" day? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
-- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
> On 16/04/2015 06:49, Steven D'Aprano wrote:
>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>
>>> Is there a utility that will allow me to write Python-like code that
>>> includes some block delimiter that I can see, that converts the code
>>> into
>>> runnable Python code? If so, where can I find it?
>
>> No more bugs from accidentally forgetting to use optional braces!
>
> You get bugs instead from mistakenly using the wrong indentation or
> losing the correct indentation (accidentally pressing the wrong key for
> example).
That's nothing! Python gives you absolutely no protection from accidentally
typing:
x += 1
when you actually wanted:
y -= 2
And there there was the time I edited some code written by my boss. I
intended to write a comment:
# FIXME: this function is a little slow and should be optimized.
but I hit the wrong key a couple of times and wrote:
# This is a steaming pile of guano written by a drooling
# moron who shouldn't be allowed near a computer. It needs
# to be deleted with prejudice, and the hard drive and all
# backup tapes set on fire just to be sure.
As I'm sure you will agree, it is an easy mistake to make.
I'm not impressed by arguments "braces protect you from accidentally hitting
tab too many times (or too few)". Um, okay. Don't people read their own
code? How do you not notice that you've indented it wrongly?
To my mind, the argument from "hitting tab too many times" is like tying a
double-bed mattress to your head in case an eagle flying overhead drops a
tortoise on your head.
The great thing about Off-side rule languages like Python is that the
structure of code is easy to see:
code code code code code code code
code
code code code
code code code
code code code
code
code
code
code code code
code code
code code
code code
code
code
while braces without indentation are horribly opaque:
code code code code code code code { code } code code code { code
code code { code code code } code { code { code { code code code
{ code code } code code { code code } } } } code } code
It's true that if a tool mangles your source code and deletes all your
indentation, you cannot mechanically fix the problem without understanding
the intent of the source code. But if a tool mangles your source code by
deleting words starting with "w", the same applies. Don't use broken tools.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 2015-04-16, Blake McBride wrote: > Thanks for all the responses. I especially like the Pike pointer. > To be clear: > > 1. I don't think languages should depend on invisible elements to > determine logic. I had the same attitude when I first tried Python 15 years ago. But, Python was the only free language implimentation I could find for Windows that had all the features to allow me to easily write a program to suck e-mail messages out of Outlook via DCOM and shove them over to an SMTP server. After a few days of use, I was a firm believer in semantically significant indentation (and have been ever since). > 2. Having been an employer, it is difficult to force programmers to > use any particular editor or style. Different editors handle tabs > and spaces differently. This is all a bloody nightmare with Python. It's an even _worse_ problem for C, PHP, Javascript, et al. At least Python requires some semblance of order and method. Those other languages allow complete anarchy, and any time developer A has to read/edit code from devloper B, it wastes all sorts of time. > 3. Languages that use braces (or the like) can be run through a > program beautifier to correct the indentation. With Python, there's no need. The indenation is _already_ correct. > You are just screwed in Python. So, Python may be a cute > language for you to use as an individual, but it is unwieldy in a > real development environment. Ah. That explains why Google uses it so much. > 4. Language beautifiers used on bracey languages removes all > arguments in favor of an off-side language. As trolls go, I don't think this rates much above a C-. -- Grant Edwards grant.b.edwardsYow! VICARIOUSLY experience at some reason to LIVE!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride wrote: > 2. Having been an employer, it is difficult to force programmers to use any > particular editor or style. Different editors handle tabs and spaces > differently. This is all a bloody nightmare with Python. > > 3. Languages that use braces (or the like) can be run through a program > beautifier to correct the indentation. You are just screwed in Python. So, > Python may be a cute language for you to use as an individual, but it is > unwieldy in a real development environment. > If you're prepared to run a beautifier on your employees' code, you should have no problem requiring that they adopt a syntactically-legal style. You're already throwing away any option of indentation not matching the physical structure of the code, so why not simply have the indentation define the physical structure? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 2015-04-16, Blake McBride wrote: > 2. Having been an employer, it is difficult to force programmers to > use any particular editor or style. Different editors handle tabs > and spaces differently. This is all a bloody nightmare with Python. > > 3. Languages that use braces (or the like) can be run through a > program beautifier to correct the indentation. You are just screwed > in Python. So, Python may be a cute language for you to use as an > individual, but it is unwieldy in a real development environment. Yes, you are quite right - no employers have ever used Python, nor has anybody ever used Python in a "real development environment". The issues you raise are novel and have not been thought about before. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 07:52 AM, Blake McBride wrote: Thanks for all the responses. I especially like the Pike pointer. To be clear: 1. I don't think languages should depend on invisible elements to determine logic. 2. Having been an employer, it is difficult to force programmers to use any particular editor or style. Different editors handle tabs and spaces differently. This is all a bloody nightmare with Python. 3. Languages that use braces (or the like) can be run through a program beautifier to correct the indentation. You are just screwed in Python. So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment. 4. Language beautifiers used on bracey languages removes all arguments in favor of an off-side language. Blake McBride While I certainly don't have your background or depth of experience... do you really think that over the last 20 odd years that Python has been around that #2 and #3 have not been hammered out? Honestly, this is starting to smell more and more like a troll... -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
As a side note, I bought a few books on Python from Amazon for use on my Kindle. At least one of the books has the formatting for the Kindle messed up rendering the meaning of the program useless. Case in point. Blake -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
Thanks for all the responses. I especially like the Pike pointer. To be clear: 1. I don't think languages should depend on invisible elements to determine logic. 2. Having been an employer, it is difficult to force programmers to use any particular editor or style. Different editors handle tabs and spaces differently. This is all a bloody nightmare with Python. 3. Languages that use braces (or the like) can be run through a program beautifier to correct the indentation. You are just screwed in Python. So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment. 4. Language beautifiers used on bracey languages removes all arguments in favor of an off-side language. Blake McBride -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On 04/16/2015 03:18 PM, alister wrote: > >> As is argueing against a real position instead of making something up. >> Nobody is argueing for arbitrary indentation. > May I suggest that you give it a try for a month, perhaps re-writing a > small program you already have in a pythonic style (don't simply write c > in python) & see if your opinion changes. > > if not then other suggestions that python is not a language of choice for > you may be appropriate. > > be warned you may find it creates (or increases ) an extreme dislike for > C & other languages that require braces & semicolons, it did for me > (especially the semi-colon!) I think you are mistaking me for someone else. I have been using python since before 2000. I went from not liking the forced indentation to not being bothered with it to not liking it again. I also think that one doesn't need to discard a language just because one doesn't like this particular feature. One can think the other characteristics of the language are positive enough one can live with this small annoyance. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
> On Apr 16, 2015, at 2:11 AM, Paul Rubin wrote: > > Steven D'Aprano writes: >> I'm aware that Coffeescript provides a brace-free wrapper around Javascript; >> I'm not aware of any wrapper that *adds* braces to a language without them. > > You're not old enough to remember Ratfor ;-) > -- > https://mail.python.org/mailman/listinfo/python-list HO Boy - Rational FORTRAN! Right up there with WatFOR (Waterloo FORTRAN for you youngsters). It was interpreted FORTRAN. Used teaching new programmers back in the day because it kept them from crashing the system. Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 03:41 PM, Chris Angelico wrote: > The case of a loop structure with its condition in the middle is one > that few languages support, so the physical structure has to be > something like: > > goto middle > while not condition: > more code > label middle > some code > > or > > while True: > some code > if condition: break > more code > > or maybe > > some code > while not condition: > more code > some code > > But I'm not sure how you could represent this more appropriately, > regardless of your indentation. Unindenting an "if" in the middle of a > loop doesn't instantly scream "this is the loop header". Using a goto > to jump half way into a loop is a really REALLY bad idea in most > programs (and it's illegal in lots of languages anyway). Repeating the > setup code is fine if it's a single line, but not else. > I'm not going to argue the merrits of various indentations styles. I just wanted to protest the notion, that because one indents one's programs in languages that don't require indentations, one can't have a quarrel with how python forces you to indent. A choice was made and although I would have preferred otherwise, I can live with it. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On Thu, Apr 16, 2015 at 11:18 PM, alister wrote: > be warned you may find it creates (or increases ) an extreme dislike for > C & other languages that require braces & semicolons, it did for me > (especially the semi-colon!) I'd just like to add to this that the lack of semicolon in Python works well because, and *only* because, Python has a lot of other rules that also are newline-sensitive. ECMAScript code sometimes runs foul of the "oops I left off a semicolon and my program did something weird" problem, which Python code almost never will. (Partly that's because Python prefers to raise SyntaxError in ambiguous cases, whereas ECMAScript tends to assign meaning to them one way or another.) If you're writing ECMAScript code, you probably want to keep all the semis, but in Python, they don't help you at all. And yet they're both classed as optional. Does that seem right to you? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)yhoni
On 16/04/2015 14:18, alister wrote: On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote: Nobody is argueing for arbitrary indentation. May I suggest that you give it a try for a month, perhaps re-writing a small program you already have in a pythonic style (don't simply write c in python) & see if your opinion changes. You mean try writing pure Python for a month? Yes, you can get used to anything. But that doesn't take away from the issues that some people have with its indentation. In my case, that would be the following (apart from the extra fragility of the code which you can't argue with): * I need some closure, some indication of where the end of a block is. Otherwise how do I know I'm looking at the last statement, or whether there is more on the next page or further down the screen? Even when I can see what follows the block, I can only infer that this is the end of the block because I eventually hit some other arbitrary construct with less indentation, not something specifically signalling the end of /that/ block. (This would come up when using copy&paste for example. If I've accidentally left out the last line of a block, I won't know about it until the code later doesn't work.) * I modify code a lot, adding and removing extra nested blocks all the time. My editor can't indent or un-indent blocks without a lot of manual typing. With block-delimited schemes, this isn't an issue, as temporary lack of correct indentation isn't crucial. (However, given a choice of only brace-delimited blocks, and Python style, I'd go for the latter! I have a longer list of complaints for C-style braces.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
