;A class representing a view of an object; similar to
>>> numpy.ndarray.view"""
>>> pass
>>>
>>> class Object:
>>> class View(View):
>>> """A view class costumized for objects of type Object"&
uot;A class representing a view of an object; similar to
>> numpy.ndarray.view"""
>> pass
>>
>> class Object:
>> class View(View):
>> """A view class costumized for objects of type Object"""
>>
``
> class View:
> """A class representing a view of an object; similar to
> numpy.ndarray.view"""
> pass
>
> class Object:
> class View(View):
> """A view class costumized for objects of type Object"&qu
The proposed semantics would be the same as self.__privs__[__class__,
"foo"]; yes I can say the problem is ugliness. The following is an example
where name mangling can be problematic (of course there are workarounds,
yet if double-underscores are meant to represent class-specific members,
the foll
On Mon, Aug 30, 2021 at 5:49 AM Mehrzad Saremi wrote:
>
> No, a class ("the class that I'm lexically inside") cannot be accessed from
> outside of the class. This is why I'm planning to offer it as a core
> feature because only the parser would know. There's apparently no elegant
> solution if you
ot;"
> > pass
> >
> > class Object:
> > class View(View):
> > """A view class costumized for objects of type Object"""
> > pass
> > ```
> >
> > Again, in this example, class `Object.Vie
w):
> """A view class costumized for objects of type Object"""
> pass
> ```
>
> Again, in this example, class `Object.View` can't take double-underscore
> names without conflicting with `View`'s.
>
> My idea is to int
an object; similar to
numpy.ndarray.view"""
pass
class Object:
class View(View):
"""A view class costumized for objects of type Object"""
pass
```
Again, in this example, class `Object.View` can't take double-underscore
names
On Thu, 19 Mar 2020 at 16:46, Peter J. Holzer wrote:
> This is similar to algebraic expressions: Have you ever tried to read a
> mathematical paper from before the time the current notation (which we
> Long, convoluted
> sentences instead of what can now be written as a short formula.
...yes, and
On 2020-03-19 15:17, Musbur wrote:
Hello,
either it's me or everybody else who's missing the point. I understand
the OP's proposal like this:
dict[set] == {k: dict[k] for k in set}
list[iterable] == [list[i] for i in iterable]
Am I right?
"Iterable" is too broad because it includes tuples an
On 19/03/2020 14:47, Peter J. Holzer wrote:
On 2020-03-19 14:24:35 +, Rhodri James wrote:
On 19/03/2020 13:00, Peter J. Holzer wrote:
It's more compact, especially, if "d" isn't a one-character variable,
but an expression:
fname, lname = db[people].employee.object.get(pk=1234)[['firs
On Fri, Mar 20, 2020 at 2:46 AM Peter J. Holzer wrote:
> > A good language has a small core and extensibility via
> > libraries.
>
> This would actually be a feature of the (standard) library.
I think the line kinda blurs here. This would be a feature of a core
data type, and in CPython, it would
For dictionaries it'd even be more useful:
d = {
'first_name': 'Frances',
'last_name': 'Allen',
'email': 'fal...@ibm.com'
}
fname, lname = d[['first_name', 'last_name']]
Why not do this?
import operator
first_last = operator.itemgetter("first_name", "last_name"
On Fri, Mar 20, 2020 at 2:37 AM Terry Reedy wrote:
>
> On 3/18/2020 10:28 PM, Santiago Basulto wrote:
>
> > For dictionaries it'd even be more useful:
> > d = {
> > 'first_name': 'Frances',
> > 'last_name': 'Allen',
> > 'email': 'fal...@ibm.com'
> > }
> >
On 2020-03-19 08:05:18 -0700, Dan Stromberg wrote:
> On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote:
> > On 2020-03-19 14:24:35 +, Rhodri James wrote:
> > > On 19/03/2020 13:00, Peter J. Holzer wrote:
> > > > It's more compact, especially, if "d" isn't a one-character variable,
> > > >
On 03/19/2020 02:09 AM, Terry Reedy wrote:
On 3/18/2020 10:28 PM, Santiago Basulto wrote:
For dictionaries it'd even be more useful:
d = {
'first_name': 'Frances',
'last_name': 'Allen',
'email': 'fal...@ibm.com'
}
fname, lname = d[['first_name', 'last_n
On 3/18/2020 10:28 PM, Santiago Basulto wrote:
For dictionaries it'd even be more useful:
d = {
'first_name': 'Frances',
'last_name': 'Allen',
'email': 'fal...@ibm.com'
}
fname, lname = d[['first_name', 'last_name']]
Insert ordered dicts make this sort
Hello,
either it's me or everybody else who's missing the point. I understand
the OP's proposal like this:
dict[set] == {k: dict[k] for k in set}
list[iterable] == [list[i] for i in iterable]
Am I right?
--
https://mail.python.org/mailman/listinfo/python-list
Santiago Basulto writes:
> Hello community. I have an idea to share with the list to see what you all
> think about it.
>
> I happen to use both Python for Data Science (with our regular friends
> NumPy and Pandas) as well as for scripting and backend development. Every
> t
On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote:
> On 2020-03-19 14:24:35 +, Rhodri James wrote:
> > On 19/03/2020 13:00, Peter J. Holzer wrote:
> > > It's more compact, especially, if "d" isn't a one-character variable,
> > > but an expression:
> > >
> > > fname, lname =
> db[peop
On 2020-03-19 14:24:35 +, Rhodri James wrote:
> On 19/03/2020 13:00, Peter J. Holzer wrote:
> > It's more compact, especially, if "d" isn't a one-character variable,
> > but an expression:
> >
> > fname, lname = db[people].employee.object.get(pk=1234)[['first_name',
> > 'last_name']]
> >
On 19/03/2020 13:00, Peter J. Holzer wrote:
On 2020-03-19 18:22:34 +1300, DL Neil via Python-list wrote:
On 19/03/20 3:28 PM, Santiago Basulto wrote:
myself missing A LOT features from NumPy, like fancy indexing or
boolean arrays.
So, has it ever been considered to bake into Python's builtin li
On 2020-03-19 18:22:34 +1300, DL Neil via Python-list wrote:
> On 19/03/20 3:28 PM, Santiago Basulto wrote:
> > myself missing A LOT features from NumPy, like fancy indexing or
> > boolean arrays.
> > So, has it ever been considered to bake into Python's builtin list and
> > dictionary types functi
On 19/03/20 3:28 PM, Santiago Basulto wrote:
...> myself missing A LOT features from NumPy, like fancy indexing or
boolean
arrays.
So, has it ever been considered to bake into Python's builtin list and
dictionary types functionality inspired by NumPy? I think multi indexing
alone would be huge a
Hello community. I have an idea to share with the list to see what you all
think about it.
I happen to use both Python for Data Science (with our regular friends
NumPy and Pandas) as well as for scripting and backend development. Every
time I'm working in server-side Python (not the PyData
On Fri, Sep 20, 2019 at 5:16 AM Cecil Westerhof wrote:
>
> Paul Rubin writes:
>
> > Python 3.7.3 (default, Apr 3 2019, 05:39:12)
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> a = range(10)
> > >>> b = reversed(a)
> > >>> sum(a) == sum(b)
>
Paul Rubin writes:
> Python 3.7.3 (default, Apr 3 2019, 05:39:12)
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a = range(10)
> >>> b = reversed(a)
> >>> sum(a) == sum(b)
> True
> >>> sum(b) == sum(a)
> False
Why does this happen?
On Mon, Sep 16, 2019 at 1:56 PM Skip Montanaro wrote:
> Mails for someone here who goes by the handle "ast" with a fake
> address of n...@gmail.com keep landing in my Gmail spam folder. I
> suspect the same is true for all people subscribed to python-list who
> use Gmail. Gmail (correctly, I think
(I would have sent this off-list, but for obvious reasons I couldn't.)
Mails for someone here who goes by the handle "ast" with a fake
address of n...@gmail.com keep landing in my Gmail spam folder. I
suspect the same is true for all people subscribed to python-list who
use Gmail. Gmail (correctly
nguage just for fun.
>
> Clojure looks pretty solid but its syntax is different than Python's.
>
> Since Lisp's make it so easy to modify the language, what about the idea
> of developing a few macros to make a modified Clojure dialect that
> more closely matched Py
On 9/15/19 9:10 AM, Christian Seberino wrote:
> Say if I may ask a tangential question...I've always wondered whether it
> would be not too hard to compile Python source code to a Lisp like source
> code? How hard would it be to say compile Python source to Clojure source?
I'm sure a compiler c
Take a look at this, Christian:
https://github.com/lihaoyi/macropy
Best,
Luciano
On Sun, Sep 15, 2019 at 12:17 PM Christian Seberino wrote:
>
>
> > I had to read this twice. It confused the hell out of me.
>
> Lol. Certainly didn't mean to be confusing! Hy bring Lisp to Python. I was
> mor
> Python vs Clojure's syntax difference is superficial compared to their
> other differences, like the Clojure's immutable data structures and
> having to deal with the JVM.
Well there's ClojureScript to run this hypothetical Pythonic Lisp in the
browser.
> I also don't think it's really practic
> I had to read this twice. It confused the hell out of me.
Lol. Certainly didn't mean to be confusing! Hy bring Lisp to Python. I was
more interested in making a Lisp that had trivial similarities to Python like
using some of the same keywords.
A related interested of mine is converting P
On 9/14/19 8:19 PM, Louis Valence wrote:
> I had to read this twice. It confused the hell out of me. Anyhow, I
> suppose you should take a look at
>
> https://github.com/hylang/hy
Yup that's probably exactly the opposite of what the OP was asking
about. Neat, though.
--
https://mail.pytho
Christian Seberino writes:
> Python is my goto main language. However, sometimes I'm tempted to
> play with a Lisp like language just for fun.
>
> Clojure looks pretty solid but its syntax is different than Python's.
>
> Since Lisp's make it so easy to modify
Python is my goto main language. However, sometimes I'm tempted to
play with a Lisp like language just for fun.
Clojure looks pretty solid but its syntax is different than Python's.
Since Lisp's make it so easy to modify the language, what about the idea
of developing a few m
Hi all,
I've been thoroughly reading various discussions, such as [1], [2] and
related ones regarding PEP 425, PEP 491 and PEP 513. I also happen to
use musl sometimes, so as discussed here [3] I thought it would be a
good idea to submit a new PEP regarding musl compatibility.
It's no
x27;ve been thoroughly reading various discussions, such as [1], [2] and
> related ones regarding PEP 425, PEP 491 and PEP 513. I also happen to
> use musl sometimes, so as discussed here [3] I thought it would be a
> good idea to submit a new PEP regarding musl compatibility.
>
>
Hello there,
I am the developer of pylint-pycharm and mypy-pycharm, two plugins
providing both real-time and on-demand scanning of Python files with
PyLint/Mypy from within PyCharm/IDEA.
The real-time code inspection works automatically the same way like the
PyCharm's build-in PEP8 check
I try to run selenium with firefox on RasberyPi3 ARM7 , any idea if it possible?
what should I do?
I don't mind to change to another driver
--
https://mail.python.org/mailman/listinfo/python-list
W dniu piątek, 2 grudnia 2016 21:51:08 UTC+1 użytkownik codew...@gmail.com
napisał:
> Something like this: https://marketplace.django-cms.org/en/ ?
Hey, that's nice solution, good to know that there is site like this :D Thanks
--
https://mail.python.org/mailman/listinfo/python-list
What are
> your opinions on this idea? Maybe there is other, better way to build it?
Something like this: https://marketplace.django-cms.org/en/ ?
--
https://mail.python.org/mailman/listinfo/python-list
Hello, what do you think about building a marketplace website on connection of
python+django? End effect-side should look and work similar to these:
https://zoptamo.com/uk/s-abs-c-uk, https://www.ownerdirect.com/ . What are your
opinions on this idea? Maybe there is other, better way to build
Hi all,
although it doesn't fit the bill 100%, I sometimes use this extremely simple
function as a decorator:
def new(call):
return call()
For example:
@new
class MySingleton:
x = 2
y = 2
def sum(self, x, y):
return x + y
@new
def my_obj():
x = 2
y = 2
de
Steven D'Aprano wrote:
There's only so far I can go without support from the compiler.
It turns out one can go surprisingly far. Here's something I
cooked up that seems to meet almost all the requirements.
The only shortcoming I can think of is that a nestedmodule
inside another nestedmodule wo
On Tuesday 05 July 2016 13:47, Chris Angelico wrote:
> On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote:
>>> If you push your code into a separate .py file, you can reference the
>>> original module by importing it. Is that also the normal way to use
>>> "outer" functions etc from inside a n
On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote:
>> If you push your code into a separate .py file, you can reference the
>> original module by importing it. Is that also the normal way to use
>> "outer" functions etc from inside a namespace?
>
> Good question!
>
> With the current implement
On Tue, 5 Jul 2016 12:58 pm, Chris Angelico wrote:
> On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano
> wrote:
>> *** IF *** you are willing to push the code out into its own separate .py
>> file, you can use a module and write your code in a more natural form:
>>
>>
>> # module example.py
>> var
On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano wrote:
> *** IF *** you are willing to push the code out into its own separate .py
> file, you can use a module and write your code in a more natural form:
>
>
> # module example.py
> var = 999
>
> def spam(arg):
> return eggs(arg) + var
>
> def
oundly told that this was crazy talk, that the whole point of classes
was that they must be instantiated to use them, that code like the second
example would be confusing and very possibly bring about the fall of
Western Civilisation. The idea that this might be a legitimate alternative
to the sin
On Tuesday, July 5, 2016 at 10:10:04 AM UTC+12, I wrote:
>
> On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote:
>
> > Functions within the namespace can't call other functions within the
> > same namespace using unqualified names. This was a stated requirement.
>
> Doesn’t my @n
On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote:
> Functions within the namespace can't call other functions within the
> same namespace using unqualified names. This was a stated requirement.
Doesn’t my @namespace decorator provide that?
--
https://mail.python.org/mailman/li
On 07/04/2016 01:37 PM, Chris Angelico wrote:
On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote:
On 07/01/2016 04:13 PM, Steven D'Aprano wrote:
But classes are not like the others: they must be instantiated before they
can be used, and they are more than just a mere namespace grouping related
entitie
On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote:
> On 07/01/2016 04:13 PM, Steven D'Aprano wrote:
>>
>> But classes are not like the others: they must be instantiated before they
>> can be used, and they are more than just a mere namespace grouping related
>> entities. Classes support inheritance. Class
On 07/01/2016 04:13 PM, Steven D'Aprano wrote:
But classes are not like the others: they must be instantiated before they
can be used, and they are more than just a mere namespace grouping related
entities. Classes support inheritance. Classes should be used for "is-a"
relationships, not "has-a"
On 07/03/2016 03:02 PM, Kevin Conway wrote:
>At some point earlier Ethan Furman declared:
It's not a language change.
Perhaps. My argument is that anything that introduces a new class-like
construct and set of lexical scoping rules is a language change. For
example, if this change went into 2.
On 04/07/2016 00:21, Lawrence D’Oliveiro wrote:
On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote:
If the problem with using classes to satisfy the namespace need is
that it's unwieldy to use dot qualified paths then isn't that quite similar
to saying namespaces are unwieldy?
P
On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote:
> If the problem with using classes to satisfy the namespace need is
> that it's unwieldy to use dot qualified paths then isn't that quite similar
> to saying namespaces are unwieldy?
Python has a simple solution to that:
a =
spaces are unwieldy? Leveraging classes as a nested module
creates a de-facto internal namespace of "cls" for self reference and I'm
unsure of why that is unwanted but "module.namespace.blah" is wanted.
I suppose my issue is not so much that namespace objects are a bad idea a
On 07/02/2016 08:44 PM, Steven D'Aprano wrote:
Try getting this behaviour from within a class:
class Food(metaclass=Namespace):
# (1) no special decorators required
def spam(n):
return ' '.join(['spam']*n)
# (2) can call functions from inside the namespace
breakf
On Sun, 3 Jul 2016 01:34 am, Kevin Conway wrote:
> staticmethod isn't technically required to use a method through the class
> (or subclasses), it simply provides the appropriate magic to allow it to
> be called through instances.
>
> For example, the following code covers all described use cases
On Sat, 2 Jul 2016 11:50 am, Kevin Conway wrote:
> I believe the namespace object you are referring to is exactly a class.
Yes, a namespace is exactly like a class, minus inheritance, instantiation,
the implied "is-a" relationship, and the whole Java "utility class"
anti-pattern.
In other words,
On 07/02/2016 08:34 AM, Kevin Conway wrote:
For the proponents of namespace, what is deficient in the above example
that necessitates a language change?
Adding a new widget is not changing the language.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
> staticmethod isn't technically required to use a method through the class
(or subclasses), it simply provides the appropriate magic to allow it to be
called through instances.
For example, the following code covers all described use cases of the
proposed namespace. Methods are invoked without cr
On Fri, Jul 1, 2016, at 21:50, Kevin Conway wrote:
> I believe the namespace object you are referring to is exactly a
> class. IIRC, classes came about as a "module in a module".
No, because classes have instances. And conceptually they seem like they
*should* have instances. Just using the term "
On Saturday, July 2, 2016 at 1:50:56 PM UTC+12, Kevin Conway wrote:
> Regardless, all use cases you've listed are already satisfied by use of the
> static and class method decorators.
Except for the need to decorate every such function inside the class. How about:
import types
def namesp
On Friday, July 1, 2016 at 8:19:36 PM UTC+5:30, BartC wrote:
> On 01/07/2016 15:13, Steven D'Aprano wrote:
>
> > Sometimes we have a group of related functions and variables that belong
> > together, but are not sufficiently unrelated to the rest of the module that
> > we want to split them out in
> Did you mean for this to go to -Ideas?
> >>
> >> Not yet. I wanted some initial feedback to see if anyone else liked the
> >> idea before taking it to Bikeshedding Central :-)
> >>
> >> Besides, I expect Python-Ideas will say it needs to be a packa
On Sat, 2 Jul 2016 05:29 am, Ethan Furman wrote:
> On 07/01/2016 10:10 AM, Steven D'Aprano wrote:
>> On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote:
>
>>> Did you mean for this to go to -Ideas?
>>
>> Not yet. I wanted some initial feedback to see if anyon
On 07/01/2016 10:10 AM, Steven D'Aprano wrote:
On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote:
Did you mean for this to go to -Ideas?
Not yet. I wanted some initial feedback to see if anyone else liked the idea
before taking it to Bikeshedding Central :-)
Besides, I expect Python-
On Sat, 2 Jul 2016 12:49 am, BartC wrote:
> On 01/07/2016 15:13, Steven D'Aprano wrote:
>
>> Sometimes we have a group of related functions and variables that belong
>> together, but are not sufficiently unrelated to the rest of the module
>> that we want to split them out into another file.
>
>
On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote:
> On 07/01/2016 07:13 AM, Steven D'Aprano wrote:
>
> I like the idea, but I have a couple questions about the design choices.
Thanks!
> Comments below.
[...]
>> Despite the "class" statement (a limitat
On Sat, Jul 2, 2016 at 12:49 AM, BartC wrote:
> Why not just extend the capabilities of a class? I actually thought this
> would work until I tried it and it didn't:
>
> class C():
> def fn():
> print ("Hi!")
>
> C.fn()
>
> The error message suggests Python knows what's going on. So wh
On 07/01/2016 07:13 AM, Steven D'Aprano wrote:
I like the idea, but I have a couple questions about the design choices.
Comments below.
The Zen of Python says:
Namespaces are one honking great idea -- let's do more of those!
Proposal
=
Add a new "names
On 01/07/2016 15:13, Steven D'Aprano wrote:
Sometimes we have a group of related functions and variables that belong
together, but are not sufficiently unrelated to the rest of the module that
we want to split them out into another file.
Here's a proof of concept. I use a class with a custom
On Fri, Jul 1, 2016, at 10:13, Steven D'Aprano wrote:
> The biggest limitation is that I have to abuse the class statement to do
> this. In an ideal world, there would be syntactic support and a keyword:
>
> namespace Example:
> x = 0
> y = []
> def test(n): ...
>
> al
The Zen of Python says:
Namespaces are one honking great idea -- let's do more of those!
Proposal
=
Add a new "namespace" object to Python.
Rationale
==
Sometimes we have a group of related functions and variables that belong
together, but are not suffici
On Thursday, May 26, 2016 at 8:56:44 AM UTC+12, jimz...@gmail.com wrote:
> I think in-process DB is quite popular in less serious development, e.g.
> SQLite.
“less serious”!? It’s the world’s most popular DBMS! There’s likely a copy in
your pocket or purse right now.
--
https://mail.python.org/
On Wednesday, 25 May 2016 19:15:38 UTC+1, Ian wrote:
> On Wed, May 25, 2016 at 10:52 AM, wrote:
> > Link: https://github.com/JimChengLin/AsyncDB
> >
> > I always wonder why people do not make an async DB, when they are crazy
> > with async web framework. Hard disks are faster than the Internet,
On Wed, May 25, 2016 at 10:52 AM, wrote:
> Link: https://github.com/JimChengLin/AsyncDB
>
> I always wonder why people do not make an async DB, when they are crazy with
> async web framework. Hard disks are faster than the Internet, but still
> pretty slow compared to CPU/RAM.
In-process dbm-s
Link: https://github.com/JimChengLin/AsyncDB
I always wonder why people do not make an async DB, when they are crazy with
async web framework. Hard disks are faster than the Internet, but still pretty
slow compared to CPU/RAM.
Due to my limited English skill, I may be not able to explain how it
On Friday, May 15, 2015 at 10:36:45 PM UTC-5, Rustom Mody wrote:
> On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote:
> > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> > > On 14/05/2015 02:40, Steven D'Aprano wrote:
> > > > On Thu, 14 May 2015 04:07 am, zipher
On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote:
> On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> > On 14/05/2015 02:40, Steven D'Aprano wrote:
> > > On Thu, 14 May 2015 04:07 am, zipher wrote:
> > >
> > >>
> > >> No, you haven't understood, padawan. Lambda *
On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> On 14/05/2015 02:40, Steven D'Aprano wrote:
> > On Thu, 14 May 2015 04:07 am, zipher wrote:
> >
> >>
> >> No, you haven't understood, padawan. Lambda *is* the function, not it's
> >> definition. Perhaps you will understand wha
gt; I think you're confused. LISP doesn't have variables. It's a lambda
> calculus with an entirely different model computation than other programming
> languages which use variables all the time. To the extent that it DOES have
> variables, it's to accomida
actually the
> same thing, they're certainly not opposites. That is a fact which genuinely
> is profound.
My God, you and Lawrence have gone off the deep end. What you're telling me is
that you've never programmed something on digital hardware. That, fucking C,
you&#x
On 14/05/2015 02:40, Steven D'Aprano wrote:
On Thu, 14 May 2015 04:07 am, zipher wrote:
No, you haven't understood, padawan. Lambda *is* the function, not it's
definition. Perhaps you will understand what I mean by that, perhaps you
won't. It's subtle.
Subtle like a kick to the head.
Mar
with water.
>> The opposite of "iterative programming" would then be a style where
>> the program can't ever repeat anything. That would be a very limited
>> language and would *not* be equivalent to a Turing machine.
>
>
> The "opposite"
On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote:
> On Wed, May 13, 2015 at 12:07 PM, zipher wrote:
> > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote:
> >> I don't know why I'm replying to this...
> >
> > Because you're trying to get an answer to a question that even Academia
On 13/05/2015 22:38, Ian Kelly wrote:
On Wed, May 13, 2015 at 12:07 PM, zipher wrote:
Yes, and LISP is neither. Although LISP is a functional style, that is only by
appearance. It's completely different from Haskell, which I would describe as
a true functional language. The difference is
except that it has an entirely different relationship to data, one
> orthogonal to iterative computation.
Iteration is a type of recursion. Specifically, it's the type of
recursion that doesn't require keeping a stack of values from each
higher-up repetition in the evaluation. Also
Ian Kelly :
> LISP is also the reason why we're cursed with the terrible name
> "lambda" for anonymous functions rather than something more mnemonic
> (like "function").
The only terrible aspect of "lambda" is how difficult it is to type.
BTW, Common Lisp actually has an operator called "functio
t that's too difficult to explain on this thread.
> The opposite of "iterative programming" would then be a style where
> the program can't ever repeat anything. That would be a very limited
> language and would *not* be equivalent to a Turing machine.
The "op
On 2015-05-12, Marko Rauhamaa wrote:
> zipher :
>
>> That is why you have very high-level languages that allow you to
>> rapidly prototype ideas, test them, and then, depending all the other
>> constraints, move them to lower-level language implementations.
>
> Finally an argument to tackle. That
procedural
styles alike.
The opposite of "iterative programming" would then be a style where
the program can't ever repeat anything. That would be a very limited
language and would *not* be equivalent to a Turing machine.
> And the idea of lambdas were already encoded by the use of
On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote:
> On Tue, May 12, 2015 at 9:11 PM, zipher wrote:
> > I know. That's because most people have fallen off the path
> > (http://c2.com/cgi/wiki?OneTruePath).
>
> You wrote that, didn't you? I recognize that combination of delusional
> narci
an other programming languages
which use variables all the time. To the extent that it DOES have variables,
it's to accomidate those coming over from iterative programming.
And the idea of lambdas were already encoded by the use of special expressions,
set-off by parenthesis. So they
Steven D'Aprano wrote:
"I want to do numerical calculations" lead to Fortran.
"I want to control telescopes" lead to Forth.
I don't think those things led to their respective languages
in the same way. The notation that mathematicians use for
numerical calculations had a clear influence on th
On Wednesday, May 13, 2015 at 9:17:48 AM UTC+5:30, Ian wrote:
> On Tue, May 12, 2015 at 9:11 PM, zipher wrote:
> > I know. That's because most people have fallen off the path
> > (http://c2.com/cgi/wiki?OneTruePath).
>
> You wrote that, didn't you? I recognize that combination of delusional
> n
1 - 100 of 1094 matches
Mail list logo
