On Friday, February 21, 2014 12:26:00 AM UTC+8, Marko Rauhamaa wrote:
> Chris Angelico :
>
>
>
> > 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 v
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?
--
Chris Angelico :
> On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa 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 like a symbol or a function
On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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 can do is create a thing
Chris Angelico :
> 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 = pos->next)
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
On Fri, Feb 21, 2014 at 6:21 PM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> 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! Rea
Steven D'Aprano :
> 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 write yourself -- or wrote a
On Fri, Feb 21, 2014 at 5:59 PM, Steven D'Aprano
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 allows that. Most people wo
On Fri, Feb 21, 2014 at 5:51 PM, Steven D'Aprano
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
>> existing Python code.
>
> I would lo
On Thu, 20 Feb 2014 12:22:29 +0200, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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 wonderful da
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 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.
On Thu, 20 Feb 2014 14:09:19 +0200, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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'
On Fri, Feb 21, 2014 at 3:26 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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
>> themse
Chris Angelico :
> 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. You either ru
On Fri, Feb 21, 2014 at 2:14 AM, Marko Rauhamaa wrote:
> * you won't be finding old Python versions on newer operating system
>distributions,
>
> * even http://www.python.org/downloads/> isn't all that extensive
>and
>
> * the program may import modules that were written in different Py
Chris Angelico :
> 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 system calls,
On Thu, Feb 20, 2014 at 11:46 PM, Marko Rauhamaa 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.
>
>> There's no p
Chris Angelico :
> On Thu, Feb 20, 2014 at 11:09 PM, Marko Rauhamaa 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 want to state the Python di
On Thu, Feb 20, 2014 at 11:09 PM, Marko Rauhamaa 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 the assumpti
Chris Angelico :
> 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 keyword.
That c
On Thu, Feb 20, 2014 at 10:28 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa wrote:
>>> py35.unless x > 7:
>>> return
>>
>> What about return? Are you allowed to namespace that? And 'from' and
>> 'import' and '*'?
>
> Old keywords are gua
On Thu, Feb 20, 2014 at 10:28 PM, Marko Rauhamaa wrote:
> A coworker pointed out that the gist of the PEP has already been
> implemented by https://pypi.python.org/pypi/fuckit>.
I love how that's categorized "Topic :: Software Development ::
Quality Assurance". It certainly assures _something_ ab
Chris Angelico :
> On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa 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. Introducing new
keywords runs tha
On Thu, Feb 20, 2014 at 9:22 PM, Marko Rauhamaa 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 :
> 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 code
One advant
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 297164
28 matches
Mail list logo
