On Thursday, 21 May 2015 18:16:33 UTC+1, Steven D'Aprano wrote:
> On Thu, 21 May 2015 11:34 pm, bartc wrote:
> > On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano wrote:
> > Using what is really pass-by-reference for everything is fine,
>
> I'm really sure it isn't fine. You could use p
On Thu, 21 May 2015 11:34 pm, bartc wrote:
> On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano wrote:
>> On Wednesday 20 May 2015 19:56, Bartc wrote:
>
>> What you *shouldn't* do is implement your own argument convention,
>
> (That's exactly what I did for my static language compiler whi
On 2015-05-21 14:34, bartc wrote:
On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano wrote:
On Wednesday 20 May 2015 19:56, Bartc wrote:
What you *shouldn't* do is implement your own argument convention,
(That's exactly what I did for my static language compiler which
generates x64 c
On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano wrote:
> On Wednesday 20 May 2015 19:56, Bartc wrote:
> What you *shouldn't* do is implement your own argument convention,
(That's exactly what I did for my static language compiler which
generates x64 code. The Win64 calling convention wa
On Thu, May 21, 2015 at 5:35 PM, Steven D'Aprano
wrote:
>> You don't need huge. On any algorithm where slices are being used you
>> will have to account for the linear complexity. You seem to be
>> dismissive of this fact, but it can have tremendous performance
>> implications, since it can turn a
On Thursday 21 May 2015 05:51, Mario Figueiredo wrote:
> On Wed, 20 May 2015 03:07:03 +1000, Steven D'Aprano
> wrote:
[...]
>>But, really... if you're serious about dealing with huge arrays of data,
>>you want something like numpy, not Python lists.
>
> You don't need huge. On any algorithm wher
Steven D'Aprano :
> On Wednesday 20 May 2015 19:56, Bartc wrote:
>> But simple data such as small integers and floats are passed by
>> value. Bigger data is 'sort of' passed by reference, but not full
>> reference (the details are a bit messy, but if an object consists of
>> two parts (A,B), then
On Wednesday 20 May 2015 19:56, Bartc wrote:
> "Steven D'Aprano" wrote in message
> news:555c225b$0$2769$c3e8da3$76491...@news.astraweb.com...
>
>> The mental gymnastics they go through to force the round peg of pass-by-
>> sharing object semantics into the false dichotomy "pass-by-value versus
On Wed, 20 May 2015 06:54 pm, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>
>> Code snippet 1:
>>
>> x = [[1,2],[1,2]]
>>
>> creates a list bound to the name "x", containing a list containing ints 1
>> and 2, and a second independent list also containing ints 1 and 2.
>
> Using the word
Terry Reedy wrote:
A club
roster contains identifiers that refer to and identify the members.
Exactly: the roster "refers to" the members, rather
than "containing" them. Or equivalently, it contains
references to the members.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Am 19.05.15 um 15:44 schrieb Steven D'Aprano:
Variables are not first class values in C. (I assume you meant *values*
rather than "objects", on account of C not being an OOP language.) There is
no way, for example, to set x to *the variable y* in either C or Python. If
you could, that would imply
On Wed, 20 May 2015 21:47:46 +0100, Mark Lawrence
wrote:
>Please provide the figures to back up this claim. Nothing personal but
>we've had problems with the RUE (amongst others) making nonsensical
>claims, please don't take us down that path, thank you.
Alright. My apologies. This answer of
On 20/05/2015 20:51, Mario Figueiredo wrote:
On Wed, 20 May 2015 03:07:03 +1000, Steven D'Aprano
wrote:
Yes, a slice can be expensive, if you have (say) a ten billion element list,
and take a slice list[1:].
Since nothing seems to surprise you and you seem so adamant on calling
anyone being
On Thu, May 21, 2015 at 5:51 AM, Mario Figueiredo wrote:
> But no one is arguing for that. Instead, it was said that it would be
> interesting if Python offered views.
It's pretty easy, actually. (Slightly more complicated once you handle
more details like negative indexing and strides other than
On Wed, May 20, 2015 at 1:51 PM, Mario Figueiredo wrote:
> On Wed, 20 May 2015 03:07:03 +1000, Steven D'Aprano
> wrote:
>
>>Yes, a slice can be expensive, if you have (say) a ten billion element list,
>>and take a slice list[1:].
>
> Since nothing seems to surprise you and you seem so adamant on
On Wed, 20 May 2015 03:07:03 +1000, Steven D'Aprano
wrote:
>Yes, a slice can be expensive, if you have (say) a ten billion element list,
>and take a slice list[1:].
Since nothing seems to surprise you and you seem so adamant on calling
anyone being surprised by it, maybe I will surprise you if y
On 5/20/2015 4:54 AM, Gregory Ewing wrote:
At this point the student thinks, "Um... what? How
can an object contain another object *twice*?"
If he's still thinking in physical terms, this
sentence is nonsensical.
It gets even worse with:
x = [1, 2]
x[1] = x
Now you have to say that the list c
On 20 May 2015 at 10:56, Bartc wrote:
>
> However, I was so impressed with how (C)Python does things (working
> exclusively with pointers, doing assignments by simply copying pointers, and
> using reference counting to manage memory), that I'm experimenting with
> letting my language work the same
"Steven D'Aprano" wrote in message
news:555c225b$0$2769$c3e8da3$76491...@news.astraweb.com...
> The mental gymnastics they go through to force the round peg of pass-by-
> sharing object semantics into the false dichotomy "pass-by-value versus
> pass-by-reference" is just crazy.
>
> One consequenc
Steven D'Aprano wrote:
Code snippet 1:
x = [[1,2],[1,2]]
creates a list bound to the name "x", containing a list containing ints 1
and 2, and a second independent list also containing ints 1 and 2.
Using the word "contains" here is misleading, because
it conjures a mental picture of phy
Rustom Mody :
> On Wednesday, May 20, 2015 at 12:16:49 PM UTC+5:30, Marko Rauhamaa wrote:
>> Rustom Mody :
>>
>> > In short any language that is implemented on von Neumann hw will
>> > need to address memory.
>>
>> I don't think von Neumann hardware plays a role here. I think the
>> data model i
On Wednesday 20 May 2015 16:23, Rustom Mody wrote:
> I dont like teaching this. viz that in python
> x = [[1,2],[1,2]]
> is equal to y defined as
> z = [1,2]
> y = [z,z]
> And although they are equal as in '==' they are not equal as in behavior,
> memory usage etc, a fact that can only be elucidat
On Wednesday, May 20, 2015 at 12:16:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > In short any language that is implemented on von Neumann hw will need
> > to address memory.
>
> I don't think von Neumann hardware plays a role here. I think the data
> model is inherent in Python/Jav
Rustom Mody :
> In short any language that is implemented on von Neumann hw will need
> to address memory.
I don't think von Neumann hardware plays a role here. I think the data
model is inherent in Python/Java/Lisp regardless of the underlying
formalism (which could be SKI combinatory calculus o
On Wednesday, May 20, 2015 at 11:27:56 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 20 May 2015 14:30, Rustom Mody wrote:
>
> > And what about Java?
> > http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
> semantics
>
> Congratulations, you have found yet another example
Steven D'Aprano :
> Rustom, if you are serious about this approach, then the implication
> is that if I execute "x = 23" in Python, and I ask you what the value
> of x is, you should answer something like "146588120" (that's the
> implementation dependent "value", i.e. the address of the int 23).
On Wednesday 20 May 2015 15:33, Steven D'Aprano wrote:
> Someone sufficiently killed with an abacus
Er, *skilled*.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday 20 May 2015 14:30, Rustom Mody wrote:
> And what about Java?
> http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
semantics
Congratulations, you have found yet another example of the Java community's
collective delusion and insistence on misusing terms for the ma
On Wednesday 20 May 2015 14:30, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> There is a little magic elf hiding inside the computer, and when you
>> type an expression like '2 + 3', little tiny hammers bang it out in
>> Morse Code on the elf's head; in response, the elf calculates the
>> answer
On 20/05/2015 05:30, Rustom Mody wrote:
On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:
Ben Finney :
Right. So the box with an arrow coming out of it is a good metaphor for
pointers -- *in languages that have pointers*, which Python does not.
A box with an arrow comin
Steven D'Aprano :
> There is a little magic elf hiding inside the computer, and when you
> type an expression like '2 + 3', little tiny hammers bang it out in
> Morse Code on the elf's head; in response, the elf calculates the
> answer on his teeny tiny abacus and passes it back to the interpreter
On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
>
> > Right. So the box with an arrow coming out of it is a good metaphor for
> > pointers -- *in languages that have pointers*, which Python does not.
> >
> > A box with an arrow coming out of it is a poor met
Ben Finney :
> Right. So the box with an arrow coming out of it is a good metaphor for
> pointers — *in languages that have pointers*, which Python does not.
>
> A box with an arrow coming out of it is a poor metaphor for Python's
> references, since a Python reference doesn't contain anything acc
On Wednesday, May 20, 2015 at 7:56:43 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
>
> > Steven D'Aprano wrote:
> >> Chris, that is one of the best explanations for why "references equals
> >> pointers" is *not* a good explanation for Python's behaviour.
On Wed, May 20, 2015 at 12:26 PM, Steven D'Aprano
wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> Chris, that is one of the best explanations for why "references equals
>>> pointers" is *not* a good explanation for Python's behaviour.
>>
>> Many people h
On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> Chris, that is one of the best explanations for why "references equals
>> pointers" is *not* a good explanation for Python's behaviour.
>
> Many people here seem to have lost sight of the
> fact that the word "pointer"
On Tue, 19 May 2015 09:00 pm, Gregory Ewing wrote:
> Chris Angelico wrote:
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
>> 2) In fact, dereferenci
On Wed, 20 May 2015 04:19 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>>> You're slaying straw men.
>>
>> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>>
>> You made a claim that was not defensible, and I tore t
Gregory Ewing writes:
> If I draw two boxes on a blackboard with an arrow between them, I
> think it's perfectly reasonable to call that arrow a pointer.
Right. So the box with an arrow coming out of it is a good metaphor for
pointers — *in languages that have pointers*, which Python does not.
Steven D'Aprano wrote:
Chris, that is one of the best explanations for why "references equals
pointers" is *not* a good explanation for Python's behaviour.
Many people here seem to have lost sight of the
fact that the word "pointer" existed in the English
language long before C, and even long b
On 19.05.15 18:15, Ian Kelly wrote:
On May 19, 2015 4:16 AM, "Serhiy Storchaka" mailto:storch...@gmail.com>> wrote:
>
> On 19.05.15 12:45, Steven D'Aprano wrote:
>>
>> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>>>
>>> From the above link it seems slices work in linear time on a
Steven D'Aprano :
> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>> You're slaying straw men.
>
> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>
> You made a claim that was not defensible, and I tore that claim to shreds.
> Have the good grace to admit that your e
On Wed, May 20, 2015 at 3:46 AM, Steven D'Aprano
wrote:
> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>
>> Steven D'Aprano :
>>
>>> To be useful, explanations ought to give the user *predictive power*
>>> -- if I calculate 32767 + 1, what will Python do?
>>>
>>> Explanation #1 predicts tha
On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> To be useful, explanations ought to give the user *predictive power*
>> -- if I calculate 32767 + 1, what will Python do?
>>
>> Explanation #1 predicts that Python will return 32768.
>> Explanation #2 makes no prediction
On Wed, May 20, 2015 at 3:07 AM, Steven D'Aprano
wrote:
> True confession time: I've been using Python for over 15 years. For at least
> 12 of those years, I've found myself feeling guilty every time I write a
> loop like "for x in seq[1:]" to skip the first element, because I'm worried
> about co
On Wed, 20 May 2015 12:52 am, Bartc wrote:
> "Steven D'Aprano" wrote in message
> news:555b0621$0$2753$c3e8da3$76491...@news.astraweb.com...
[...]
>> I'm sure that lots of things surprise people who assume that every
>> language's performance characteristics are identical.
>>
>> Python is not Lis
Steven D'Aprano :
> To be useful, explanations ought to give the user *predictive power*
> -- if I calculate 32767 + 1, what will Python do?
>
> Explanation #1 predicts that Python will return 32768.
> Explanation #2 makes no prediction at all.
Any semantic ruleset that correctly predicts the beh
On May 19, 2015 4:16 AM, "Serhiy Storchaka" wrote:
>
> On 19.05.15 12:45, Steven D'Aprano wrote:
>>
>> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>>>
>>> From the above link it seems slices work in linear time on all cases.
>>
>>
>> I wouldn't trust that is always the case, e.g. deleti
On 19 May 2015 at 09:50, Chris Angelico wrote:
> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa wrote:
>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
>
> Sorta
"Steven D'Aprano" wrote in message
news:555b0621$0$2753$c3e8da3$76491...@news.astraweb.com...
> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>> And this really has a big impact on certain operations. For instance,
>> the code below may surprise some people when they realize it doesn't
>>
On Tue, 19 May 2015 07:35 pm, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
>> to explain Python's object references, the differences will start to
>> be problematic:
>>
>> 1) Pointer arithmetic simply doesn't exist in Python.
On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano
wrote:
> On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:
>
>> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa wrote:
>>> For example, you could explain Python's object references as pointers
>>> (memory addresses) if you considered that helpfu
On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:
> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa wrote:
>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
>
>
On Tuesday, May 19, 2015 at 5:16:29 PM UTC+5:30, Rustom Mody wrote:
> On Tuesday, May 19, 2015 at 12:42:50 PM UTC+5:30, Marko Rauhamaa wrote:
> > I sympathize. Can you get Python without getting a language like C
> > first? Can a baby be born without an umbilical cord? Can you skip Newton
> > and g
On Tuesday, May 19, 2015 at 12:42:50 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > However conceptually/pedagogically making a fundamenal distinction of
> > timeless | time
> > value | object
> > immutable | mutable
> > expression | statement
> > function | procedure
> >
> > is key to g
On Tuesday 19 May 2015 18:39, Marko Rauhamaa wrote:
> What I'm saying is that it doesn't matter what semantic description you
> give Python constructs as long as the observed behavior is correct.
You really think that it doesn't matter which of the following two
explanations I give for this beha
On Tuesday, May 19, 2015 at 1:49:31 PM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 19 May 2015 15:33, Rustom Mody wrote:
>
> > However conceptually/pedagogically making a fundamenal distinction of
> > timeless | time
> > value | object
> > immutable | mutable
> > expression | statement
> > funct
On 19 May 2015 at 11:15, Serhiy Storchaka wrote:
> On 19.05.15 12:45, Steven D'Aprano wrote:
>>
>> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>>>
>>> From the above link it seems slices work in linear time on all cases.
>>
>>
>> I wouldn't trust that is always the case, e.g. deleting a
Chris Angelico wrote:
1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
not just pointers to their first elements, and subscripting is most
definitely NOT "add to pointer and dereference".
2) In fact, dereferencing as a whole isn't really a 'thing' either. At
best, it happens
On 19.05.15 12:45, Steven D'Aprano wrote:
On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
From the above link it seems slices work in linear time on all cases.
I wouldn't trust that is always the case, e.g. deleting a contiguous slice
from the end of a list could be O(1).
It always ha
On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
> I'd like to understand what I'm being told about slices in
> https://wiki.python.org/moin/TimeComplexity
>
> Particularly, what's a 'del slice' and a 'set slice' and whether this
> information pertains to both CPython 2.7 and 3.4.
Get a sl
Chris Angelico :
> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
> to explain Python's object references, the differences will start to
> be problematic:
>
> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
> not just pointers to their first elements,
On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa wrote:
> For example, you could explain Python's object references as pointers
> (memory addresses) if you considered that helpful. (That's how Lisp
> textbooks often explain cons cells.)
Sorta-kinda-maybe, but if a C programmer's idea of pointers i
Steven D'Aprano :
>> What matters is the effect of a program. If two metaphysical
>> formulations of language semantics produce the same outcome, neither
>> is objectively better than the other.
>
> By outcome, do you mean the program's output?
Yes, the program's output, but also the interactions
On Tuesday 19 May 2015 15:33, Rustom Mody wrote:
> However conceptually/pedagogically making a fundamenal distinction of
> timeless | time
> value | object
> immutable | mutable
> expression | statement
> function | procedure
>
> is key to getting programming [and is something that Pascal got bet
On Tuesday 19 May 2015 17:12, Marko Rauhamaa wrote:
> Can you get Python without getting a language like C first?
Yes.
There are a few senses in which C is very important to Python. Python was
designed to be a glue language for interoperability with C libraries, so
that's a very important sen
Rustom Mody :
> However conceptually/pedagogically making a fundamenal distinction of
> timeless | time
> value | object
> immutable | mutable
> expression | statement
> function | procedure
>
> is key to getting programming [and is something that Pascal got better
> than most of its successors].
On Tuesday, May 19, 2015 at 10:44:10 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 19 May 2015 12:20, Rustom Mody wrote:
>
> > I must say I am impressed by C#/.Net for making the value/object
> > distinction first-class all the way from language to VM.
>
> I'm not sure what you mean by that.
On Tuesday 19 May 2015 12:20, Rustom Mody wrote:
> I must say I am impressed by C#/.Net for making the value/object
> distinction first-class all the way from language to VM.
I'm not sure what you mean by that. Are you referring to something similar
to Java's distinction between native/unboxed t
On Tuesday, May 19, 2015 at 1:20:55 AM UTC+5:30, Ian wrote:
> It may be possible that lists in CPython could be made to share their
> internal arrays with other lists on a copy-on-write basis, which could
> allow slicing to be O(1) as long as neither list is modified while the
> array is being shar
On 5/18/2015 5:04 PM, Mario Figueiredo wrote:
Other languages implement slices. I'm currently being faced with a Go
snippet that mirrors the exact code above and it does run in linear
time.
Is there any reason why Python 3.4 implementation of slices cannot be
a near constant operation?
The
On 18/05/2015 22:04, Mario Figueiredo wrote:
On Mon, 18 May 2015 13:49:45 -0600, Ian Kelly
wrote:
Other languages implement slices. I'm currently being faced with a Go
snippet that mirrors the exact code above and it does run in linear
time.
Is there any reason why Python 3.4 implementation o
On Mon, 18 May 2015 13:49:45 -0600, Ian Kelly
wrote:
>> Other languages implement slices. I'm currently being faced with a Go
>> snippet that mirrors the exact code above and it does run in linear
>> time.
>>
>> Is there any reason why Python 3.4 implementation of slices cannot be
>> a near const
On May 18, 2015 9:56 PM, "Fabien" wrote:
>
> On 05/18/2015 09:49 PM, Ian Kelly wrote:
>>
>> It may be possible that lists in CPython could be made to share their
>> internal arrays with other lists on a copy-on-write basis, which could
>> allow slicing to be O(1) as long as neither list is modifie
On Tue, May 19, 2015 at 5:49 AM, Mario Figueiredo wrote:
> On Tue, 19 May 2015 05:36:44 +1000, Chris Angelico
> wrote:
>
>>What's the point of optimizing slicing to allow you to use a poor
>>algorithm, instead of fixing your algorithm?
>>
>
> Chris, thank you for your input. But the code isn't re
On 05/18/2015 09:49 PM, Ian Kelly wrote:
It may be possible that lists in CPython could be made to share their
internal arrays with other lists on a copy-on-write basis, which could
allow slicing to be O(1) as long as neither list is modified while the
array is being shared. I expect this would b
On Mon, May 18, 2015 at 1:23 PM, Mario Figueiredo wrote:
> I'd like to understand what I'm being told about slices in
> https://wiki.python.org/moin/TimeComplexity
>
> Particularly, what's a 'del slice' and a 'set slice' and whether this
> information pertains to both CPython 2.7 and 3.4.
"Del Sl
On May 18, 2015 9:26 PM, "Mario Figueiredo" wrote:
>
> I'd like to understand what I'm being told about slices in
> https://wiki.python.org/moin/TimeComplexity
>
> Particularly, what's a 'del slice' and a 'set slice' and whether this
> information pertains to both CPython 2.7 and 3.4.
>
> From the
On Tue, 19 May 2015 05:36:44 +1000, Chris Angelico
wrote:
>What's the point of optimizing slicing to allow you to use a poor
>algorithm, instead of fixing your algorithm?
>
Chris, thank you for your input. But the code isn't really the
question, is it?
It's just an example. It was being used ea
On Tue, May 19, 2015 at 5:23 AM, Mario Figueiredo wrote:
> From the above link it seems slices work in linear time on all cases.
> And this really has a big impact on certain operations. For instance,
> the code below may surprise some people when they realize it doesn't
> run in linear time on 3.
I'd like to understand what I'm being told about slices in
https://wiki.python.org/moin/TimeComplexity
Particularly, what's a 'del slice' and a 'set slice' and whether this
information pertains to both CPython 2.7 and 3.4.
>From the above link it seems slices work in linear time on all cases.
And
81 matches
Mail list logo
