On Sat, Nov 28, 2015 at 12:24 AM, Laura Creighton wrote:
> I think it's just another instance of Just-In-Time Manufacturing
> https://en.wikipedia.org/wiki/Just-in-time_manufacturing
>
> "As soon as you need a object, we'll have one ready". :)
Just-In-Time Quantum Manufacturing: "As soon as you n
In a message of Fri, 27 Nov 2015 23:57:29 +1100, "Steven D'Aprano" writes:
>On Fri, 27 Nov 2015 01:56 pm, MRAB wrote:
>
>> On 2015-11-27 02:44, Steven D'Aprano wrote:
>
>>> The PyPy implementation has to take special actions to preserve the ID
>>> across object recreations. That is what I mean by "
On Fri, 27 Nov 2015 01:56 pm, MRAB wrote:
> On 2015-11-27 02:44, Steven D'Aprano wrote:
>> The PyPy implementation has to take special actions to preserve the ID
>> across object recreations. That is what I mean by "faked".
>>
> You could argue that it _does_ continue to exist, it just changes it
BartC :
> I think [functions] are more first class in Lisp than they are in most
> other languages including Python.
Functions in Python and Lisp have the same status.
I would say that Python is one of the many modern Lisp derivatives. What
Python still lacks is:
* A way to augment the languag
On 27/11/2015 01:09, Steven D'Aprano wrote:
On Thu, 26 Nov 2015 12:23 pm, BartC wrote:
[First-class functions]
The names are declared, but the names are rarely bound to anything else.
Functions are just called the same boring way they are in C.
/They might as well be static definitions/.
Su
Steven D'Aprano writes:
> On Fri, 27 Nov 2015 12:40 pm, Ben Finney wrote:
>
> > It's still not been expressed what “fake” refers to here. Or, rather,
> > what “real” thing was being expected, and how these don't qualify.
>
> They are faked in the sense that in this implementation, the object
> li
Steven D'Aprano writes:
> On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
>
>
>> (Conversely, I see that unlike CPython, all PyPy's numbers have
>> unchanging ids, even after exiting PyPy and restarting, so it seems that
>> PyPy's numerical ids are "faked".)
>>
>> [PyPy 2.6.1 with GCC 4.9.2]
On Fri, Nov 27, 2015 at 1:56 PM, MRAB wrote:
> You could argue that it _does_ continue to exist, it just changes its
> form...
PyPy: The Quantum Mechanics of Python programming. If you aren't
actually looking at something right at this instant, it might exist in
a different form... or not exist a
On 2015-11-27 02:44, Steven D'Aprano wrote:
On Fri, 27 Nov 2015 12:40 pm, Ben Finney wrote:
Steven D'Aprano writes:
On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
> (Conversely, I see that unlike CPython, all PyPy's numbers have
> unchanging ids, even after exiting PyPy and restarting,
On Fri, 27 Nov 2015 12:40 pm, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
>>
>>
>> > (Conversely, I see that unlike CPython, all PyPy's numbers have
>> > unchanging ids, even after exiting PyPy and restarting, so it seems
>> > that PyPy's n
On 27/11/2015 01:46, Steven D'Aprano wrote:
On Thu, 26 Nov 2015 12:52 pm, Ned Batchelder wrote:
For someone who claims to be interested in language design, you're
remarkably dismissive of pretty much the entire industry. I don't think
it's worth the effort to try to change your mind.
In fair
On Thu, 26 Nov 2015 12:52 pm, Ned Batchelder wrote:
> For someone who claims to be interested in language design, you're
> remarkably dismissive of pretty much the entire industry. I don't think
> it's worth the effort to try to change your mind.
In fairness to BartC, I don't think that's malici
On Thu, 26 Nov 2015 10:23 pm, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Nov 26, 2015 at 9:54 PM, Marko Rauhamaa wrote:
>>>
>>>>>> hash([])
>>>Traceback (most recent call last):
>>> File "", line 1, in
>>>TypeError: unhashable type: 'list'
>>>
>>> Annoying.
>>
>> Yes
Steven D'Aprano writes:
> On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
>
>
> > (Conversely, I see that unlike CPython, all PyPy's numbers have
> > unchanging ids, even after exiting PyPy and restarting, so it seems
> > that PyPy's numerical ids are "faked".)
>
> I'm pretty sure that they ar
On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
> (Conversely, I see that unlike CPython, all PyPy's numbers have
> unchanging ids, even after exiting PyPy and restarting, so it seems that
> PyPy's numerical ids are "faked".)
>
> [PyPy 2.6.1 with GCC 4.9.2] on linux2
> id(1+2j)
> 67990011
On Thu, 26 Nov 2015 07:27 pm, Marko Rauhamaa wrote:
> What I'm saying is that Python does not prevent mutable keys but tries
> to do that with lists and tuples.
>
> I think Python should stop trying.
>
> I have wanted to use lists as keys, and there should be no reason to
> allow mutable tuples.
On 2015-11-27 00:15, Random832 wrote:
Chris Angelico writes:
Windows: I'm not sure, and frankly, I don't trust it. A quick test
showed a couple of failures:
It might be case insensitive only for ASCII.
Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for case
comparison. it doesn't
On Thu, 26 Nov 2015 12:23 pm, BartC wrote:
> On 26/11/2015 00:31, Steven D'Aprano wrote:
>> In 2015, it's hard to think of any non-obsolete, non-toy language which
>> doesn't treat functions as first-class values, including creating them on
>> the fly. Fortran and C perhaps.
>
> It's funny then
On Fri, Nov 27, 2015 at 11:15 AM, Random832 wrote:
> Chris Angelico writes:
>> Windows: I'm not sure, and frankly, I don't trust it. A quick test
>> showed a couple of failures:
>>
>> It might be case insensitive only for ASCII.
>
> Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for ca
Chris Angelico writes:
> Windows: I'm not sure, and frankly, I don't trust it. A quick test
> showed a couple of failures:
>
> It might be case insensitive only for ASCII.
Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for case
comparison. it doesn't handle those cases, but it does ha
On Fri, Nov 27, 2015 at 9:27 AM, BartC wrote:
> On 26/11/2015 13:15, Chris Angelico wrote:
>>
>> On Thu, Nov 26, 2015 at 11:53 PM, BartC wrote:
>
>
>>> http://pastebin.com/JrVTher6
>
>
>> #14 and #15: Are you assuming that a character is a byte and that
>> diacritical-free English is the only lan
On 26/11/2015 13:15, Chris Angelico wrote:
On Thu, Nov 26, 2015 at 11:53 PM, BartC wrote:
http://pastebin.com/JrVTher6
#14 and #15: Are you assuming that a character is a byte and that
diacritical-free English is the only language in the world?
I don't think that need be the assumption.
BartC wrote:
I simply stated that Python's approach was novel. Steven D'Aprano then
responded by belittling my view, and effectively trashing every language
I've ever used.
He pointed out that many other dynamic languages construct
functions on the fly the same way that Python does, going
all
Gregory Ewing :
> Marko Rauhamaa wrote:
>> What I'm saying is that Python does not prevent mutable keys but
>> tries to do that with lists and tuples.
>>
>> I think Python should stop trying.
>
> Do you volunteer to answer all the posts from beginners complaining
> that "the dict type is broken" b
Marko Rauhamaa wrote:
What I'm saying is that Python does not prevent mutable keys but tries
to do that with lists and tuples.
I think Python should stop trying.
Do you volunteer to answer all the posts from beginners
complaining that "the dict type is broken" because they
used a list as a key
On 2015-11-26 12:53, BartC wrote:
On 26/11/2015 01:52, Ned Batchelder wrote:
On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
On 26/11/2015 00:31, Steven D'Aprano wrote:
It really, truly isn't. Your viewpoint is clouded by too much immersion in
crippled languages. *Old and o
On 2015-11-26 14:40, BartC wrote:
On 26/11/2015 13:15, Chris Angelico wrote:
On Thu, Nov 26, 2015 at 11:53 PM, BartC wrote:
FWIW here is that list of features that are different between Python and my
language, or that work a different way, or that I think could be a useful
addition. (Although
On 26/11/2015 13:15, Chris Angelico wrote:
On Thu, Nov 26, 2015 at 11:53 PM, BartC wrote:
FWIW here is that list of features that are different between Python and my
language, or that work a different way, or that I think could be a useful
addition. (Although Python's internal workings make man
On Thu, Nov 26, 2015 at 11:53 PM, BartC wrote:
> FWIW here is that list of features that are different between Python and my
> language, or that work a different way, or that I think could be a useful
> addition. (Although Python's internal workings make many impractical.)
>
> http://pastebin.com/
On 26/11/2015 01:52, Ned Batchelder wrote:
On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
On 26/11/2015 00:31, Steven D'Aprano wrote:
It really, truly isn't. Your viewpoint is clouded by too much immersion in
crippled languages. *Old and obsolete versions* of crippled langu
Chris Angelico :
> On Thu, Nov 26, 2015 at 10:23 PM, Marko Rauhamaa wrote:
>> It's not letting me in the case of list.
>
> Actually it is. Your mistake is trying to use a list as a dict key.
> You have a solution available: use a tuple.
Yes, or wrap the list in a class.
Marko
--
https://mail.
On Thu, Nov 26, 2015 at 10:24 PM, Ben Finney wrote:
> Dave Farrance writes:
>
>> Marko Rauhamaa wrote:
>>
>> >Dave Farrance :
>> >
>> >> (Conversely, I see that unlike CPython, all PyPy's numbers have
>> >> unchanging ids, even after exiting PyPy and restarting, so it seems
>> >> that PyPy's num
Ben Finney wrote:
>Dave Farrance writes:
>
>> Marko Rauhamaa wrote:
>>
>> >Dave Farrance :
>> >
>> >> (Conversely, I see that unlike CPython, all PyPy's numbers have
>> >> unchanging ids, even after exiting PyPy and restarting, so it seems
>> >> that PyPy's numerical ids are "faked".)
>> >
>> >
On Thu, Nov 26, 2015 at 10:23 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Nov 26, 2015 at 9:54 PM, Marko Rauhamaa wrote:
>>>
>>>>>> hash([])
>>>Traceback (most recent call last):
>>> File "", line 1, in
>>>TypeError: unhashable type: 'list'
>>>
>>> Annoying.
>>
>>
Dave Farrance :
> Marko Rauhamaa wrote:
>>What's a faked id?
>
> You can figure out what I'm getting at -- i.e. I presume that the ids
> are not pointers to stored numbers in memory (as with CPython) but are
> a translation of the numerical variable's value.
CPython is within its rights to fake
On Thu, Nov 26, 2015 at 10:12 PM, Dave Farrance wrote:
> Marko Rauhamaa wrote:
>
>>Dave Farrance :
>>
>>> (Conversely, I see that unlike CPython, all PyPy's numbers have
>>> unchanging ids, even after exiting PyPy and restarting, so it seems
>>> that PyPy's numerical ids are "faked".)
>>
>>What's
Chris Angelico :
> On Thu, Nov 26, 2015 at 9:54 PM, Marko Rauhamaa wrote:
>>
>>>>> hash([])
>>Traceback (most recent call last):
>> File "", line 1, in
>>TypeError: unhashable type: 'list'
>>
>> Annoying.
>
> Yes, it's really annoying that you get an immediate exception instead
Dave Farrance writes:
> Marko Rauhamaa wrote:
>
> >Dave Farrance :
> >
> >> (Conversely, I see that unlike CPython, all PyPy's numbers have
> >> unchanging ids, even after exiting PyPy and restarting, so it seems
> >> that PyPy's numerical ids are "faked".)
> >
> >What's a faked id?
>
> You can
On 26/11/2015 06:52, Marko Rauhamaa wrote:
Steven D'Aprano :
Making tuples mutable would break their use as dictionary keys, which is a
*critical* use.
No, it wouldn't. Any object that provides __hash__() and __eq__() can be
used as a key.
Almost, see https://wiki.python.org/moin/Dictionar
Marko Rauhamaa wrote:
>Dave Farrance :
>
>> (Conversely, I see that unlike CPython, all PyPy's numbers have
>> unchanging ids, even after exiting PyPy and restarting, so it seems
>> that PyPy's numerical ids are "faked".)
>
>What's a faked id?
You can figure out what I'm getting at -- i.e. I pre
On Wed, 25 Nov 2015 14:51:23 +0100, Antoon Pardon wrote:
> Am I missing something?
The issue is with lambdas rather than with list comprehensions per se.
Python's lambdas capture free variables by reference, not value.
> x = 3
> f = lambda y: x + y
> f(0)
3
On Thu, Nov 26, 2015 at 9:54 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Nov 26, 2015 at 7:27 PM, Marko Rauhamaa wrote:
>>> I have wanted to use lists as keys, and there should be no reason to
>>> allow mutable tuples. It should be enough to say that the behavior of
>>> a dictionary
Dave Farrance :
> (Conversely, I see that unlike CPython, all PyPy's numbers have
> unchanging ids, even after exiting PyPy and restarting, so it seems
> that PyPy's numerical ids are "faked".)
What's a faked id?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico :
> On Thu, Nov 26, 2015 at 7:27 PM, Marko Rauhamaa wrote:
>> I have wanted to use lists as keys, and there should be no reason to
>> allow mutable tuples. It should be enough to say that the behavior of
>> a dictionary is undefined if a key should mutate on the fly.
>
> Python def
Alan Bawden wrote:
>Chris Angelico writes:
> ...
>> Python 2.7.8 (2.4.0+dfsg-3, Dec 20 2014, 13:30:46)
>> [PyPy 2.4.0 with GCC 4.9.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> tuple([]) is tuple([])
>> False
>
>I said I wouldn't be suprised if it
Op 26-11-15 om 09:27 schreef Marko Rauhamaa:
> Chris Angelico :
>
>> On Thu, Nov 26, 2015 at 5:52 PM, Marko Rauhamaa wrote:
>>> Nothing prevents using mutable objects as keys in Python.
>> Sure, you _can_. But if the key's hash changes between dict insertion
>> and retrieval, all manner of invaria
On Thu, Nov 26, 2015 at 7:27 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Nov 26, 2015 at 5:52 PM, Marko Rauhamaa wrote:
>>> Nothing prevents using mutable objects as keys in Python.
>>
>> Sure, you _can_. But if the key's hash changes between dict insertion
>> and retrieval, all man
Op 26-11-15 om 02:52 schreef Ned Batchelder:
> I almost started to explain about how yes, Python is often written in
> conservative static ways. I was going to mention that a little dynamic
> nature goes a long way, and is never far from the surface in even the
> simplest Python programs.
>
> But I
Chris Angelico :
> On Thu, Nov 26, 2015 at 5:52 PM, Marko Rauhamaa wrote:
>> Nothing prevents using mutable objects as keys in Python.
>
> Sure, you _can_. But if the key's hash changes between dict insertion
> and retrieval, all manner of invariants will break, and likewise if
> two equal object
Op 25-11-15 om 23:38 schreef Ian Kelly:
> On Wed, Nov 25, 2015 at 2:05 PM, Antoon Pardon
> wrote:
>> Op 25-11-15 om 21:39 schreef Ian Kelly:
>>
>>> I believe that sentence from the docs is using "some" to mean "not
>>> all", whereas you are apparently using it to mean "any".
>>>
>>> frozenset([1,2
On Thu, Nov 26, 2015 at 5:52 PM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Making tuples mutable would break their use as dictionary keys, which is a
>> *critical* use.
>
> No, it wouldn't. Any object that provides __hash__() and __eq__() can be
> used as a key.
>
> Nothing prevents using mut
Steven D'Aprano :
> Making tuples mutable would break their use as dictionary keys, which is a
> *critical* use.
No, it wouldn't. Any object that provides __hash__() and __eq__() can be
used as a key.
Nothing prevents using mutable objects as keys in Python.
Egon Spengler: There's something
On 11/25/2015 12:32 AM, Chris Angelico wrote:
On Wed, Nov 25, 2015 at 7:14 PM, Antoon Pardon
wrote:
[snip]
"Oh come on. It's basic arithmetic. You should be able to add 7 and
7... the result's 14!"
"But it's so confusing. Why can't it be 16? It'd be more convenient
for me if it were 16."
N
BartC :
> Clearly a huge amount of programming can be done without having to deal
> with first-class functions (or constructing functions at run-time; that
> sounds fun). (Or without using OOP, another thing I can't stand.)
Even the lowliest code monkeys deal with on-the-fly functions and OOP
nowa
On 26/11/2015 05:08, Ben Finney wrote:
Ned Batchelder writes:
For someone who claims to be interested in language design, you're
remarkably dismissive of pretty much the entire industry. I don't
think it's worth the effort to try to change your mind.
+1.
BartC, when you want to join us in d
Ned Batchelder writes:
> For someone who claims to be interested in language design, you're
> remarkably dismissive of pretty much the entire industry. I don't
> think it's worth the effort to try to change your mind.
+1.
BartC, when you want to join us in discussions on good faith – that is,
h
Ian Kelly writes:
> On Wed, Nov 25, 2015 at 5:52 PM, Random832 wrote:
> > On 2015-11-25, Ben Finney wrote:
> >> That is, the ‘2’ in ‘cartesian_point = (2, 3)’ means something
> >> different than in ‘cartesian_point = (3, 2)’.
> >>
> >> Whereas the ‘2’ in ‘test_scores = [2, 3]’ means exactly the
Chris Angelico writes:
> On Thu, Nov 26, 2015 at 1:08 PM, Alan Bawden wrote:
>> (Note that nothing in the documentation I can find actually _guarantees_
>> that a Python implementation will only have one unique empty tuple, but
>> I wouldn't be suprised if the following is nonetheless true in al
On Wed, Nov 25, 2015 at 5:52 PM, Random832 wrote:
> On 2015-11-25, Ben Finney wrote:
>> That is, the ‘2’ in ‘cartesian_point = (2, 3)’ means something different
>> than in ‘cartesian_point = (3, 2)’.
>>
>> Whereas the ‘2’ in ‘test_scores = [2, 3]’ means exactly the same as in
>> ‘test_scores = [3
On Thu, Nov 26, 2015 at 1:46 PM, Ian Kelly wrote:
> On Wed, Nov 25, 2015 at 7:25 PM, Chris Angelico wrote:
>> On Thu, Nov 26, 2015 at 1:08 PM, Alan Bawden wrote:
>>> (Note that nothing in the documentation I can find actually _guarantees_
>>> that a Python implementation will only have one uniqu
On Wed, Nov 25, 2015 at 7:25 PM, Chris Angelico wrote:
> On Thu, Nov 26, 2015 at 1:08 PM, Alan Bawden wrote:
>> (Note that nothing in the documentation I can find actually _guarantees_
>> that a Python implementation will only have one unique empty tuple, but
>> I wouldn't be suprised if the foll
On Thu, Nov 26, 2015 at 1:08 PM, Alan Bawden wrote:
> (Note that nothing in the documentation I can find actually _guarantees_
> that a Python implementation will only have one unique empty tuple, but
> I wouldn't be suprised if the following is nonetheless true in all
> current implementations:
>
Steven D'Aprano writes:
> In fact, it's easy to find cases even now where the compiler is
> insufficiently smart to recognise all the possible optimizations available.
> There's no tuple simpler than the empty tuple, but Python 3.3 at least
> fails to optimize that case:
>
> py> dis(compile("()",
On Thu, 26 Nov 2015 12:20 am, BartC wrote:
> On 25/11/2015 10:52, Steven D'Aprano wrote:
>> On Wed, 25 Nov 2015 07:14 pm, Antoon Pardon wrote:
>
>>> What exactly is your point?
>>
>> That there is a simple analogy between the distinction between code
>> inside/outside a for-loop, and code inside/
On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
> On 26/11/2015 00:31, Steven D'Aprano wrote:
> > On Thu, 26 Nov 2015 09:41 am, BartC wrote:
> >
> >> Maybe you're too familiar with it. But the idea of executing the
> >> function and other definitions in a file, instead of they jus
On 26/11/2015 00:31, Steven D'Aprano wrote:
On Thu, 26 Nov 2015 09:41 am, BartC wrote:
Maybe you're too familiar with it. But the idea of executing the
function and other definitions in a file, instead of they just being
there, is novel.
It really, truly isn't. Your viewpoint is clouded by t
On Thu, 26 Nov 2015 01:34 am, BartC wrote:
> On 25/11/2015 13:53, Marko Rauhamaa wrote:
>> BartC :
>>
>>> Using tuples in the same way that other languages implement records is
>>> going to be difficult if you can't change the values of the fields!
>>
>> Guido could decide tomorrow that tuples are
On 2015-11-25, Ben Finney wrote:
> That is, the ‘2’ in ‘cartesian_point = (2, 3)’ means something different
> than in ‘cartesian_point = (3, 2)’.
>
> Whereas the ‘2’ in ‘test_scores = [2, 3]’ means exactly the same as in
> ‘test_scores = [3, 2]’.
>
> If each position in the sequence gives the valu
On Thu, 26 Nov 2015 09:41 am, BartC wrote:
> Maybe you're too familiar with it. But the idea of executing the
> function and other definitions in a file, instead of they just being
> there, is novel.
It really, truly isn't. Your viewpoint is clouded by too much immersion in
crippled languages. *
On Thu, 26 Nov 2015 05:27 am, Antoon Pardon wrote:
> Op 25-11-15 om 18:40 schreef Steven D'Aprano:
>> On Wed, 25 Nov 2015 08:56 pm, Antoon Pardon wrote:
>>
>>> Since (x, y, z) is not a fixed value, it is not a literal.
>>
>> Right. And therefore, (x, y, z) syntax is not syntax for a literal. Hen
On 25/11/2015 22:16, Marko Rauhamaa wrote:
BartC :
I'm interested in language design because that's what I've done on and
off for over 30 years. And I'm discussing some design decisions in
Python.
That *is* a fun ambition, useful or not.
(At the moment, it's mostly fun. But in the past I ac
On Wed, Nov 25, 2015 at 2:05 PM, Antoon Pardon
wrote:
> Op 25-11-15 om 21:39 schreef Ian Kelly:
>> On Wed, Nov 25, 2015 at 11:27 AM, Antoon Pardon
>> wrote:
>>> I don't know what you are talking about. The first thing I have argued
>>> is that () is a literal. Then I have expaned that to that som
BartC :
> I'm interested in language design because that's what I've done on and
> off for over 30 years. And I'm discussing some design decisions in
> Python.
That *is* a fun ambition, useful or not.
However, while I'm very choosy and critical when it comes to my
programming tools, I'm extremel
On Thu, Nov 26, 2015 at 8:05 AM, Antoon Pardon
wrote:
> Op 25-11-15 om 21:39 schreef Ian Kelly:
>> On Wed, Nov 25, 2015 at 11:27 AM, Antoon Pardon
>> wrote:
>>> I don't know what you are talking about. The first thing I have argued
>>> is that () is a literal. Then I have expaned that to that som
On 25/11/2015 20:50, Mark Lawrence wrote:
On 25/11/2015 17:18, BartC wrote:
Can you please let us know what you're taking, what it costs and where
we can get it, as we would also like to live in cloud cuckoo land,
provided that The Price Is Right™.
And I would really like to know what your p
Op 25-11-15 om 21:39 schreef Ian Kelly:
> On Wed, Nov 25, 2015 at 11:27 AM, Antoon Pardon
> wrote:
>> I don't know what you are talking about. The first thing I have argued
>> is that () is a literal. Then I have expaned that to that something
>> like (3, 5, 8) is a literal. I never argued that tu
Ben Finney :
> Perhaps it would be easier if you point out that ‘x’ doesn't mean
> multiply either, and they've *already* been substituting that symbol
> instead of the correct ‘×’ for multiply.
In my childhood, we always used '·' for the multiplication sign until
senior high school, when the vec
On 25/11/2015 17:18, BartC wrote:
On 25/11/2015 15:13, Ned Batchelder wrote:
On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
Accept that some things /are/ a source of confusion. When, in writing
documentation, I find something hard to explain something, then I try
and make it
On Wed, Nov 25, 2015 at 11:27 AM, Antoon Pardon
wrote:
> I don't know what you are talking about. The first thing I have argued
> is that () is a literal. Then I have expaned that to that something
> like (3, 5, 8) is a literal. I never argued that tuple expressions
> in general are literals. And
Laura Creighton writes:
> The great sticking point for the children I am teaching is '*' means
> multiplication. […] that one can swap out a particular convention 'x
> means multiply' and swap in another one '* means multiply' while
> leaving the underlying truth unchanged.
Perhaps it would be e
Chris Angelico writes:
> This is a distinction I generally make. Putting it another way: a list
> has the same meaning regardless of how many items are on it (for
> instance, a shopping list is still a shopping list whether it has five
> or fifty items on it), where a tuple is a package where eac
On 11/25/2015 5:20 AM, BartC wrote:
it seems to be more lucrative to write thicker user manuals, and provide
longer training courses, than to make software simpler.
If that were true, certainly by now the sufficiently thick manual would
provide crystal clear explanations. :)
I-don't-think-
On 11/25/2015 4:25 AM, Antoon Pardon wrote:
I think there are reasons to find the above behaviour bizarre. I personnaly
don't find it bizarre, but that is because I'm familiar with what is going
on.
Which I suspect is necessary.
>but if someone expects the compilor to take a snapshot of L and
On 25/11/2015 18:03, Ian Kelly wrote:
On Wed, Nov 25, 2015 at 10:18 AM, BartC wrote:
We have no way of evaluating their power or simplicity,
since they are not available to us.
I'll see if I can rustle up a comparison so that Python users can see what
they're missing!
Unless you're going to
Marko Rauhamaa writes:
> Jussi Piitulainen writes:
>
>> You know, people have developed further ways to talk about these
>> things precisely because substitution semantics is inadequate for
>> what they wanted to talk about.
>
> "Assignment" is what everybody uses and understands.
You can tell tha
Op 25-11-15 om 18:40 schreef Steven D'Aprano:
> On Wed, 25 Nov 2015 08:56 pm, Antoon Pardon wrote:
>
>> Since (x, y, z) is not a fixed value, it is not a literal.
>
> Right. And therefore, (x, y, z) syntax is not syntax for a literal. Hence
> why the Python docs call it a tuple display instead of
On Wed, Nov 25, 2015 at 10:18 AM, BartC wrote:
>> We have no way of evaluating their power or simplicity,
>> since they are not available to us.
>
> I'll see if I can rustle up a comparison so that Python users can see what
> they're missing!
Unless you're going to make the actual languages avail
On Wed, 25 Nov 2015 08:56 pm, Antoon Pardon wrote:
> Since (x, y, z) is not a fixed value, it is not a literal.
Right. And therefore, (x, y, z) syntax is not syntax for a literal. Hence
why the Python docs call it a tuple display instead of a tuple literal --
no matter what x, y, z are. Even if t
On 25/11/2015 15:13, Ned Batchelder wrote:
On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
Accept that some things /are/ a source of confusion. When, in writing
documentation, I find something hard to explain something, then I try
and make it simpler in the program. But not eno
Jussi Piitulainen :
> Marko Rauhamaa writes:
>> As far as the words "variable" and "binding" go, they are present in
>> lambda calculus (1929 and on):
>
> So it's more than ten years earlier than I thought. Old enough,
> anyway. Strictly speaking, that a Wikipedia article uses the words
> "variabl
On Thu, Nov 26, 2015 at 2:13 AM, Ned Batchelder wrote:
> I agree with you: there are things about Python that surprise people.
> That's because it's a programming language, and very very little about
> programming languages is obvious. The best we can hope for is "familiar,"
> and even then, fami
>and even then, familiar to who? High school algebra students will at
>first be baffled by "x = x + 1", an equation which is clearly
>unsatisfiable.
Some languages are "better" in that specific case in my opinion (mind te
double quotes :-)
- Ada and Pascal use := instead of = which is simpler t
In a message of Wed, 25 Nov 2015 07:13:41 -0800, Ned Batchelder writes:
>That's because it's a programming language, and very very little about
>programming languages is obvious. The best we can hope for is "familiar,"
>and even then, familiar to who? High school algebra students will at
>first b
On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
> Accept that some things /are/ a source of confusion. When, in writing
> documentation, I find something hard to explain something, then I try
> and make it simpler in the program. But not enough of that goes on: it
> seems to be
Marko Rauhamaa writes:
> Jussi Piitulainen writes:
>
>> In point d, McCarthy refers to variables as variables; I'm sure this
>> would go back to Church and 1940's at least, so I expect they used
>> this word already back then. But the ability to store new content to
>> the data structure that asso
On 25/11/2015 13:53, Marko Rauhamaa wrote:
BartC :
Using tuples in the same way that other languages implement records is
going to be difficult if you can't change the values of the fields!
Guido could decide tomorrow that tuples are mutable.
(Could that be done without breaking existing co
Op 25-11-15 om 14:24 schreef Chris Angelico:
> On Wed, Nov 25, 2015 at 11:25 PM, Antoon Pardon
> wrote:
>>> But there's a big difference between those who guess wrong from a position
>>> of ignorance, and then make an honest attempt to understand the behaviour
>>> and why it actually does make sen
Chris Angelico :
> On Wed, Nov 25, 2015 at 11:48 PM, Marko Rauhamaa wrote:
>> I think "binding" is too fancy a word to be used with conventional
>> programming languages like Python. If your programming language has
>> an assignment statement, "binding" is even nonsensical. Consider:
>>
>>def
BartC :
> Using tuples in the same way that other languages implement records is
> going to be difficult if you can't change the values of the fields!
Guido could decide tomorrow that tuples are mutable. The decision is
more or less arbitrary, and has to do with dictionary keys, I bet (not a
part
Op 20-11-15 om 08:49 schreef dieter:
> In addition, the last few days have had two discussions in this list
> demonstrating the conceptial difficulties of late binding -- one of them:
>
> Why does "[lambda x: i * x for i in range(4)]" gives
> a list of essentially the same functions?
C
1 - 100 of 285 matches
Mail list logo
