On Fri, Feb 21, 2014 at 6:21 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Thu, 20 Feb 2014 12:22:29 +0200, Marko Rauhamaa wrote:
I'm looking forward to the day when every application can add its own
keywords as is customary in Lisp.
And
On Fri, 21 Feb 2014 09:21:56 +0200, Marko Rauhamaa wrote:
I don't hear Lispers or C programmers complaining.
Lisp is not a popular language. Despite being more powerful, more
efficient, and a lot older, I expect that there are far fewer people who
know Lisp (let alone use it regularly) than
Chris Angelico ros...@gmail.com:
How does C let you create new keywords?
With #define. Nowhere near as elegant (flexible, hygienic) as in Lisp,
but used to create new syntax:
include/linux/list.h:
#define list_for_each(pos, head) \
for (pos = (head)-next; pos != (head); pos =
On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
How does C let you create new keywords?
With #define. Nowhere near as elegant (flexible, hygienic) as in Lisp,
but used to create new syntax:
That can't create new syntax, though. All it
Chris Angelico ros...@gmail.com:
On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa ma...@pacujo.net wrote:
With #define. Nowhere near as elegant (flexible, hygienic) as in
Lisp, but used to create new syntax:
That can't create new syntax, though. All it can do is create a thing
that looks
On 02/21/2014 04:03 AM, Marko Rauhamaa wrote:
With the addition of macros, Python would become a (remote) Lisp
dialect. Defining macros would become more complicated because of
Python's more complex supersyntax.
Have you tried MacroPy? If not, you should. If so, what were its failings?
--
On Friday, February 21, 2014 12:26:00 AM UTC+8, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
Also, what happens if two modules (one of which might be your script)
written for different versions both import some third module? Should
they get different versions, based on
In working on a proposal that might result in the creation of a new
keyword, I needed to ascertain what names were used extensively in
existing Python code. Out of random curiosity, I asked my script what
names were the most commonly used. The script responded with 21854
names and a total of
Chris Angelico ros...@gmail.com:
In working on a proposal that might result in the creation of a new
keyword,
I'm looking forward to the day when every application can add its own
keywords as is customary in Lisp.
I needed to ascertain what names were used extensively in existing
Python
On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa ma...@pacujo.net wrote:
from py35 import *
That way, you could choose between:
unless x 7:
return
and:
py35.unless x 7:
return
in case you have already made use of the name unless in your program.
What about return?
Chris Angelico ros...@gmail.com:
On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa ma...@pacujo.net wrote:
py35.unless x 7:
return
What about return? Are you allowed to namespace that? And 'from' and
'import' and '*'?
Old keywords are guaranteed not to clash with programs.
On Thu, Feb 20, 2014 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
A coworker pointed out that the gist of the PEP has already been
implemented by URL: https://pypi.python.org/pypi/fuckit.
I love how that's categorized Topic :: Software Development ::
Quality Assurance. It certainly
On Thu, Feb 20, 2014 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa ma...@pacujo.net wrote:
py35.unless x 7:
return
What about return? Are you allowed to namespace that? And 'from' and
'import'
Chris Angelico ros...@gmail.com:
Python has a facility like this. It doesn't namespace the keywords,
but it does let you choose whether to have them or not. In Python 2.5,
you could type from __future__ import with_statement to turn 'with'
into a keyword. After Python 2.6, it's always a
On Thu, Feb 20, 2014 at 11:09 PM, Marko Rauhamaa ma...@pacujo.net wrote:
How about blocking the introduction of new keywords for ever except if
you specify:
from __py35__ import syntax
Eventually, every Python module would likely begin with a statement like
that, and it would document
Chris Angelico ros...@gmail.com:
On Thu, Feb 20, 2014 at 11:09 PM, Marko Rauhamaa ma...@pacujo.net wrote:
from __py35__ import syntax
It's more self-documenting with the __future__ directive, because it
says *what* syntax you're importing from the future.
As a developer, I will probably
On Thu, Feb 20, 2014 at 11:46 PM, Marko Rauhamaa ma...@pacujo.net wrote:
And at some point, the new keywords must just become standard.
That's an explicit program of destroying backwards-compatibility: a war
on legacy code. That may be the Python way, but it's not a necessary
strategy.
Chris Angelico ros...@gmail.com:
If the interpreter were to include every dialect of old Python, then
it would have a lot more than two branches. They would, in fact,
increase exponentially with every Python version.
It shouldn't be *that bad*; the linux kernel is grappling with the glut
of
On Fri, Feb 21, 2014 at 2:14 AM, Marko Rauhamaa ma...@pacujo.net wrote:
* you won't be finding old Python versions on newer operating system
distributions,
* even URL: http://www.python.org/downloads/ isn't all that extensive
and
* the program may import modules that were written
Chris Angelico ros...@gmail.com:
Also, what happens if two modules (one of which might be your script)
written for different versions both import some third module? Should
they get different versions, based on what version tags they use
themselves? Compatibility can't be changed that easily.
On Fri, Feb 21, 2014 at 3:26 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Also, what happens if two modules (one of which might be your script)
written for different versions both import some third module? Should
they get different versions, based on what
On Thu, 20 Feb 2014 14:09:19 +0200, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
Python has a facility like this. It doesn't namespace the keywords, but
it does let you choose whether to have them or not. In Python 2.5, you
could type from __future__ import with_statement to turn
On Thu, 20 Feb 2014 14:46:35 +0200, Marko Rauhamaa wrote:
I would imagine there would be dozens of branches in the interpreter
if the latest interpreter were to support all past Python dialects (as
it should, IMO).
Well thank goodness you're not in charge of Python's future development.
That
On Thu, 20 Feb 2014 20:39:10 +1100, Chris Angelico wrote:
In working on a proposal that might result in the creation of a new
keyword, I needed to ascertain what names were used extensively in
existing Python code.
I would love to steal^W see your script for doing this :-)
--
Steven
--
On Thu, 20 Feb 2014 12:22:29 +0200, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
In working on a proposal that might result in the creation of a new
keyword,
I'm looking forward to the day when every application can add its own
keywords as is customary in Lisp.
And what a
On Fri, Feb 21, 2014 at 5:51 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 20 Feb 2014 20:39:10 +1100, Chris Angelico wrote:
In working on a proposal that might result in the creation of a new
keyword, I needed to ascertain what names were used extensively in
On Fri, Feb 21, 2014 at 5:59 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Then I can write code like:
for for in in:
while while:
if if:
raise raise
which will go a long way to ensuring that my code is an hostile and
unreadable as possible.
REXX
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Thu, 20 Feb 2014 12:22:29 +0200, Marko Rauhamaa wrote:
I'm looking forward to the day when every application can add its own
keywords as is customary in Lisp.
And what a wonderful day that will be! Reading any piece of code you
didn't
28 matches
Mail list logo
