Greetings,
A Great Py Course:
https://dabeaz-course.github.io/practical-python/
David Beazley is a celebrated python dev, previously he was a lecturer in
compiler theory.
His practical py course is:
"A no-nonsense treatment of Python that has been actively taught to more
than 400 in-p
On 04May2020 17:17, ozst...@gmail.com wrote:
On Tuesday, 5 May 2020 01:35:42 UTC+10, David Raymond wrote:
Not necessarily the cause of your problem, but if you're going to compare dates
it should be as objects, or as text as year-month-day. Here you're comparing
dates as text in day-month-ye
On Tuesday, 5 May 2020 01:35:42 UTC+10, David Raymond wrote:
> Not necessarily the cause of your problem, but if you're going to compare
> dates it should be as objects, or as text as year-month-day. Here you're
> comparing dates as text in day-month-year format. So January first comes
> b
Many thanks for your help. It is really appreciated. I see both your points and
maybe this is where my problems lays.
If for example it starts (and it does) at 9.30am then the print is..
streaming It is supposed to wait for the 40 minutes, stop then print
this.. Waiting for the next str
Not necessarily the cause of your problem, but if you're going to compare dates
it should be as objects, or as text as year-month-day. Here you're comparing
dates as text in day-month-year format. So January first comes before May
4th 2020
"01-01-" < "04-05-2020"
...
04-05-2020 09:30:
Hi,
A nooby here and I could do with some help in finding out what, if anything, is
wrong with the script
Is there anything in this script that could cause the stream to stop before the
allocated time?
For example the time.txt file which gives the times to the script, shows the
time to start
link as follow:
https://www.udemy.com/complete-package-of-python-course-mastery-in-python-course/?couponCode=PYTHONFORUM
--
https://mail.python.org/mailman/listinfo/python-list
On 8/11/17 6:37 AM, Python wrote:
> Marko Rauhamaa wrote:
>> Python :
>>
>>> Marko Rauhamaa wrote:
>>> I didn't disagree with any of these statements about __hash__, but only
>>> your statement about id and __eq__:
>>>
id() is actually an ideal return value of __hash__(). The only
criter
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
I didn't disagree with any of these statements about __hash__, but only
your statement about id and __eq__:
id() is actually an ideal return value of __hash__(). The only
criterion is that the returned number should be different if the
__e
Marko Rauhamaa wrote:
Of course, some algorithms can (and, we have learned, do) prefer some
bits over others, but that's inside the implementation black box. I
would think every bit should carry an approximately equal weight.
Ideally that would be true, but you need to consider the perfor
Steve D'Aprano wrote:
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
which I think agrees with my comment: using the id() itself would put too many
objects in the same b
Python wrote:
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id()
nan is a clear, simple, undeniable counterexample to that claim.
It's a cou
e the unique bits are in the hash
value?
0x1000
0x2000
0x3000
0x4000
should be no worse as __hash__() values than
0x1000
0x2000
0x3000
0x4000
or
1
2
3
4
Of course, some algorithms can (and, we have l
On Fri, Aug 11, 2017 at 7:17 AM, Marko Rauhamaa wrote:
> That's interesting, but suggests there's something weird (~ suboptimal)
> going on with CPython's scrambling algorithm. Also, your performance
> test might yield completely different results on other Python
> implementations.
>
> Apart from
Chris Angelico :
> I'm aware of this. Doesn't change the fact that the *INITIAL INDEX* is
> based on exactly what I said.
>
> Yaknow?
What you're saying is that CPython heavily prefers the low-order bits to
be unique performance-wise. I don't know why that particular heuristic
bias was chosen.
Peter Otten <__pete...@web.de>:
> Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Let's see:
>
> $ cat hashperf.py
> class A(object):
> __slots__ = ["_hash"]
>
> def __hash__(self):
> return self._hash
>
> def no_magic():
> a = A()
> a._hash = id(a)
On Fri, Aug 11, 2017 at 6:56 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>>> I see no point in CPython's rotation magic.
>>
>> Have you ever implemented a hashtable? The most common way to pick a
>> bucket for an object is to use modulo
Chris Angelico :
> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Have you ever implemented a hashtable? The most common way to pick a
> bucket for an object is to use modulo on the number of buckets.
Like I said earlier, CPython takes t
Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my comment: using the id() itsel
On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my
Peter Otten <__pete...@web.de>:
> Steve D'Aprano wrote:
>> The C code says:
>>
>>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees with my comment: using the id() itself would put
>> too many objects in
Steve D'Aprano wrote:
> The C code says:
>
>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too
> many objects in the same bucket (i.e. too many collision
Python :
> Marko Rauhamaa wrote:
> I didn't disagree with any of these statements about __hash__, but only
> your statement about id and __eq__:
>
>> id() is actually an ideal return value of __hash__(). The only
>> criterion is that the returned number should be different if the
>> __eq__() is Fa
On Fri, Aug 11, 2017 at 2:41 AM, Steve D'Aprano
wrote:
> On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
>
>> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
>> wrote:
>>
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive
On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
> wrote:
>
>> The C code says:
>>
>>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (
Python :
> Marko Rauhamaa wrote:
>> Python :
>>
>>> Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
>>>
>>> $ python
>>> Python
On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
wrote:
> The C code says:
>
>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too many
> objec
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
> Steven D'Aprano wrote:
>
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Pytho
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[G
Python :
> Marko Rauhamaa wrote:
>> id() is actually an ideal return value of __hash__(). The only criterion
>> is that the returned number should be different if the __eq__() is
>> False. That is definitely true for id().
>
> $ python
> Python 2.7.13 (default, Jan 19 2017, 14:48:08)
> [GCC 6.3.0
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type
Peter Otten <__pete...@web.de>:
> Steven D'Aprano wrote:
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Python (kinda) did this by
Steven D'Aprano wrote:
> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>
>> Good point! A very good __hash__() implementation is:
>>
>> def __hash__(self):
>> return id(self)
>>
>> In fact, I didn't know Python (kinda) did this by default already. I
>> can't find that in
On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
> Good point! A very good __hash__() implementation is:
>
> def __hash__(self):
> return id(self)
>
> In fact, I didn't know Python (kinda) did this by default already. I
> can't find that information in the definition of obje
Chris Angelico :
> On Wed, Aug 9, 2017 at 11:46 PM, Marko Rauhamaa wrote:
>> Really, the most obvious use case for hashed objects is their membership
>> in a set. For example:
>>
>> invitees = set(self.bff)
>> invitees |= self.classmates()
>> invitees |= self.relatives()
>
> Okay. So
On Wed, 9 Aug 2017 11:46 pm, Marko Rauhamaa wrote:
> Typically, an object's equality is simply the "is" relation.
"Typically"? I don't think so. Are you sure you've programmed in Python before?
*wink*
py> [1, 2] is [1, 2]
False
The most commonly used objects don't define equality as identity, e
On Wed, Aug 9, 2017 at 11:46 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
>>> Chris Angelico :
>>>
Which means that its value won't change. That's what I said. Two
things will be equal regardless of that metadata.
>>>
>>> In re
Chris Angelico :
> On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> Which means that its value won't change. That's what I said. Two
>>> things will be equal regardless of that metadata.
>>
>> In relational-database terms, your "value" is the primary key and
>> yo
On 8/9/2017 9:25 AM, Marko Rauhamaa wrote:
> r...@zedat.fu-berlin.de (Stefan Ram):
>
>> Steve D'Aprano writes:
>>> There's a word for frozen list: "tuple".
>> Yes, but one should not forget that a tuple
>> can contain mutable entries (such as lists).
> Not when used as keys:
>
> >>> hash
r...@zedat.fu-berlin.de (Stefan Ram):
> Steve D'Aprano writes:
>>There's a word for frozen list: "tuple".
>
> Yes, but one should not forget that a tuple
> can contain mutable entries (such as lists).
Not when used as keys:
>>> hash(([], []))
Traceback (most recent call last):
On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Which means that its value won't change. That's what I said. Two
>> things will be equal regardless of that metadata.
>
> In relational-database terms, your "value" is the primary key and your
> "metadata" is the rest o
On Wed, 9 Aug 2017 08:38 pm, Marko Rauhamaa wrote:
> sometimes you really would like an immutable
> (or rather, no-longer-mutable) list to act as a key.
There's a word for frozen list: "tuple".
:-)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, thi
On Wed, 9 Aug 2017 02:19 pm, Dennis Lee Bieber wrote:
> On Tue, 8 Aug 2017 15:38:42 + (UTC), Grant Edwards
> declaimed the following:
>
>>On 2017-08-08, Peter Heitzer wrote:
[...]
>>> The differences between blanks and tabs :-)
>>
>>You've misspelled "Tabs are evil and should never be used"
On Wed, 9 Aug 2017 07:51 pm, Marko Rauhamaa wrote:
> Dennis Lee Bieber :
>
>> Then there is the facet that tuples (being unmutable) can be used as
>> keys into a dictionary...
>
> Mutable objects can be used as keys into a dictionary.
Indeed.
And people can also put their hand into a fire in o
On Wed, Aug 9, 2017 at 8:00 AM, Marko Rauhamaa wrote:
> Yeah, when there's a will, there's a way.
My Dad used to say "Where there's a will, there's relatives."
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico :
> On Wed, Aug 9, 2017 at 8:38 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
Mutable objects can be used as keys into a dictionary.
>>>
>>> Only when the objects' mutability does not affect their values.
>>
>> Up t
On Wed, Aug 9, 2017 at 8:38 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
>>> Mutable objects can be used as keys into a dictionary.
>>
>> Only when the objects' mutability does not affect their values.
>
> Up to equality. The objects can
On Tue, 08 Aug 2017 14:19:53 +, Stefan Ram wrote:
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave in other
> languages, that means, the course starts roughly with these topics:
>
> - number and string literals - types of
Chris Angelico :
> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
>> Mutable objects can be used as keys into a dictionary.
>
> Only when the objects' mutability does not affect their values.
Up to equality. The objects can carry all kinds of mutable payload as
long as __hash__() and __eq
On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
> Dennis Lee Bieber :
>
>> Then there is the facet that tuples (being unmutable) can be used as
>> keys into a dictionary...
>
> Mutable objects can be used as keys into a dictionary.
Only when the objects' mutability does not affect the
Dennis Lee Bieber :
> Then there is the facet that tuples (being unmutable) can be used as
> keys into a dictionary...
Mutable objects can be used as keys into a dictionary.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Dennis Lee Bieber :
> Tabs are logical entities indicating structure and should always be
> used!
I wrote an entire database program using only tabs.
http://dilbert.com/strip/1992-09-08>
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Aug 8, 2017 10:20 AM, "Stefan Ram" wrote:
>
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave
> in other languages, that means, the course starts roughly
> with these topics:
>
> - number and string liter
On 2017-08-08, Peter Heitzer wrote:
> Stefan Ram wrote:
>> I am planning a Python course.
> [different topics]
>> Are there any other very simple things that
>> I have missed and that should be covered very
>> early in a Python course?
>
> The
On Tue, Aug 8, 2017 at 7:19 AM, Stefan Ram wrote:
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave
> in other languages, that means, the course starts roughly
> with these topics:
>
> - number and string literals
> - ty
On Wed, Aug 9, 2017 at 1:02 AM, Stefan Ram wrote:
> Chris Angelico writes:
>>Why a new Python course?
>
> It is not a course in the sense of a written text
> (which I would call "course notes").
>
> It is a course in the sense of an event, where I will me
Stefan Ram wrote:
> I am planning a Python course.
[different topics]
> Are there any other very simple things that
> I have missed and that should be covered very
> early in a Python course?
The differences between blanks and tabs :-)
--
Dipl.-Inform(FH) Peter Heitzer
On Wed, Aug 9, 2017 at 12:19 AM, Stefan Ram wrote:
> I am planning a Python course.
>
Before answering any other questions, answer this one:
Why a new Python course? How is it different from what already exists?
The answer to that will govern just about everything else. The
specific
Hi all,
Is there on line course in Python? I am looking for a level between beginner
and intermediate. I would appreciate if you could suggest me?
Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
Hi fellow Pythonistas,
Let me show you my project - an introductory Python online course:
https://snakify.org/ . Our key features are 100+ exercises with deep
mathematical approach and a neat website to solve them online using a
step-by-step debugger. We already have thousands of happy users
Hi,
I've taught a python course with some positive results to high school students
with zero experience in programming. Now I am making these course materials
(slides in English and lecture videos in Cantonese) freely available as a
contribution back to the community
On Monday, July 11, 2016 at 11:03:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Monday 11 July 2016 13:07, Rustom Mody wrote:
>
> > Python is good for black-box – us the ‘batteries included’ without worrying
> > too much how they are made
> > Scheme, assembly language, Turing machines etc are at the
in 762282 20160711 063300 Steven D'Aprano
wrote:
>On Monday 11 July 2016 13:07, Rustom Mody wrote:
>
>> Python is good for black-box â us the âbatteries includedâ without
>> worrying
>> too much how they are made
>> Scheme, assembly language, Turing machines etc are at the other end of the
On Monday 11 July 2016 13:07, Rustom Mody wrote:
> Python is good for black-box – us the ‘batteries included’ without worrying
> too much how they are made
> Scheme, assembly language, Turing machines etc are at the other end of the
> spectrum
I would put it the other way.
Python is excellent fo
On 07/09/2016 04:21 PM, Chris Angelico wrote:
Yes, I hear a lot about Udacity. Has anyone taken any of the pay-for
classes? Are the instructors helpful, skilled, etc? Did it seem like
good value for money?
Yes. Yes, yes. Yes. :)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python
On Sunday, July 10, 2016 at 10:36:39 PM UTC+5:30, Ethan Furman wrote:
> On 07/10/2016 12:18 AM, Bob Martin wrote:
> > in 762247 20160709 223746 Malik Rumi wrote:
>
> >> I want one of those "knuckle down and learn" classes. But even more than
> >> th=
> >> at, I want a class with a real teacher wh
On 07/10/2016 12:18 AM, Bob Martin wrote:
in 762247 20160709 223746 Malik Rumi wrote:
I want one of those "knuckle down and learn" classes. But even more than th=
at, I want a class with a real teacher who is available to answer questions=
and explain things. I've done a lot of books and onlin
in 762247 20160709 223746 Malik Rumi wrote:
>I want one of those "knuckle down and learn" classes. But even more than th=
>at, I want a class with a real teacher who is available to answer questions=
>and explain things. I've done a lot of books and online video, but there's=
>usually no help. If
way too fragmented
>>> for me. Where can I find classes like that - online - paid or free?
>>> Thanks.
>>
>>
>> Yes, they definitely exist. I work with a company called Thinkful
>> (www.thinkful.com) which does what you're talking about - you get a
>>
hey definitely exist. I work with a company called Thinkful
(www.thinkful.com) which does what you're talking about - you get a
personal mentor with whom you meet regularly, plus access to a number
of experts. It's a paid course. There are other such courses around,
too, but I don't per
(www.thinkful.com) which does what you're talking about - you get a
personal mentor with whom you meet regularly, plus access to a number
of experts. It's a paid course. There are other such courses around,
too, but I don't personally know their effectiveness.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
I want one of those "knuckle down and learn" classes. But even more than that,
I want a class with a real teacher who is available to answer questions and
explain things. I've done a lot of books and online video, but there's usually
no help. If I search around long enough, I can often find an a
On Thursday, July 7, 2016 at 8:38:15 AM UTC+5:30, Michael Torrie wrote:
> On 07/06/2016 06:50 PM, Lawrence D’Oliveiro wrote:
> >> I want to be easy and not bored so i can learn python.
> >
> > There is no Royal Road, nothing is going to be handed to you on a plate.
>
> Seconded. If he gets bored
On 07/06/2016 06:50 PM, Lawrence D’Oliveiro wrote:
>> I want to be easy and not bored so i can learn python.
>
> There is no Royal Road, nothing is going to be handed to you on a plate.
Seconded. If he gets bored easily, he will not be very successful at
learning Python or any other programming
On Thursday, July 7, 2016 at 7:28:38 AM UTC+12, nickpe...@gmail.com wrote:
> i am totaly beginner and i want to learn python.
Write code.
> I want to be easy and not bored so i can learn python.
There is no Royal Road, nothing is going to be handed to you on a plate.
--
https://mail.python.org
There are a ton of great resources on
https://wiki.python.org/moin/BeginnersGuide . The resource I generally
recommend to people first is "Learn Python The Hard Way" @
http://learnpythonthehardway.org/ . The course is $29.95 and worth every
penny but if you can't afford it the auth
On Thu, Jul 7, 2016 at 5:28 AM, wrote:
> i am totaly beginner and i want to learn python.
> I have see that there is many course in codeacademy, udemy, treehouse etc but
> i not know who is the best.
> Can you please give me some advice?
> I want to be easy and not bored so i c
Hello,
i am totaly beginner and i want to learn python.
I have see that there is many course in codeacademy, udemy, treehouse etc but i
not know who is the best.
Can you please give me some advice?
I want to be easy and not bored so i can learn python.
Thank you and sorry for my bad english
Python programmers,
Any Python and/or Django courses/materials to recommend?
I may be teaching a Python/Django class soon. My client may be
willing to jumpstart by buying existing course materials (lecture
slides, notes, homeworks, labs, reference links, any other materials
I have created Python with Oracle Database Course, and offer 50% discount till
10-5-2016.
Any one interested in course just click on below link.
https://www.udemy.com/using-python-with-oracle-db/?
Then write coupon Code=PYTHON_ORACLE_50%25
--
https://mail.python.org/mailman/listinfo/python
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
On Wednesday, May 13, 2015 at 8:14:39 PM UTC+5:30, zipher wrote:
> On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> > On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> > > Why can't a language be designed with a *practical and concrete* need in
> > > min
> > No, Common LISP does, but as the website says Common LISP is a
> > "multi-paradigm" langauge. It's trying to be everything to everybody,
> > just like Python tried to do in the other direction, making "everything an
> > object". Python was trying to be too pure, while LISP was trying to be
>
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
On Thu, 14 May 2015 04:07 am, 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
> hasn't answered or understood.
>
>> On Wed, May 13, 2015 at 8:44 AM,
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
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
> hasn't answered or understood.
>
>> On Wed, May 13, 2015 at 8:44
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
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 hasn't
answered or understood.
> On Wed, May 13, 2015 at 8:44 AM, zipher wrote:
> > On Tuesday, May 12, 2015 at 10:35:29
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
I don't know why I'm replying to this...
On Wed, May 13, 2015 at 8:44 AM, zipher wrote:
> On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
>> How history U-turns!!
>> Lisp actually got every major/fundamental thing wrong
>> - variables scopes were dynamic by mistake
>> - lambdas
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
On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> > Why can't a language be designed with a *practical and concrete* need in
> > mind? As far as I know, only one language designed from theoretical first
>
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
On Wednesday, May 13, 2015 at 11:47:19 AM UTC+5:30, Chris Angelico wrote:
> On Wed, May 13, 2015 at 3:56 PM, Rustom Mody wrote:
> >> Yep. I'd also use clear function/procedure names to make it more
> >> visible, and probably tie this in with loops to show how you can print
> >> more than one thing
1 - 100 of 230 matches
Mail list logo
