On 27/03/2016 22:55, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:
On 27/03/2016 18:19, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
There would be a list of expression terms that can also form independent
statements.
On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:
> On 27/03/2016 18:19, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
>
> >> There would be a list of expression terms that can also form independent
> >> statements. Not knowing Python, the list wo
On 27 Mar 2016 23:11, "Ben Bacarisse" wrote:
>
> Steven D'Aprano writes:
>
> > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> >
> >> Steven D'Aprano writes:
> >>> For example, would you consider that this isolated C code is
> >>> "meaningless"?
> >>> int i = n + 1;
> >>
> >> It's meaningful a
On 27/03/2016 18:19, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
There would be a list of expression terms that can also form independent
statements. Not knowing Python, the list would comprise function calls
(ie. the function call is top node in the AST
Steven D'Aprano writes:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
>> Steven D'Aprano writes:
>>> For example, would you consider that this isolated C code is
>>> "meaningless"?
>>> int i = n + 1;
>>
>> It's meaningful as long as n is in a certain range of values so there's
>> no overf
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
> On 27/03/2016 16:48, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> >> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
>
> >> Well, that could be done in Python (not so usefully because you can't
On 27/03/2016 16:48, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
On 27/03/2016 14:47, Dennis Lee Bieber wrote:
Well, that could be done in Python (not so usefully because you can't
take account of such info until a call is attempted), but that's not
what
On 3/27/2016 11:48 AM, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
whether fn has an explicit return or not, and not allowing:
fn # and other kinds of expression
unless some keyword is used.
Python *could* have made it an error to have a u
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
> > On Sun, 27 Mar 2016 12:31:26 +0100, BartC declaimed the
> > following:
> >
> >> On 27/03/2016 07:34, Paul Rubin wrote:
> >>> BartC writes:
> But my suggestion was to have requi
On 27/03/2016 14:47, Dennis Lee Bieber wrote:
On Sun, 27 Mar 2016 12:31:26 +0100, BartC declaimed the
following:
On 27/03/2016 07:34, Paul Rubin wrote:
BartC writes:
But my suggestion was to have required a keyword in front of
such expressions.
Should there be a keyword in front of a l
On 27/03/2016 07:34, Paul Rubin wrote:
BartC writes:
But my suggestion was to have required a keyword in front of
such expressions.
Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?
They both look like function calls. Function calls are *v
On 27 Mar 2016 10:56, "Steven D'Aprano" wrote:
>
>
> My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
> function:
>
> void foo(int n) {
> int i = n + 1;
> bar(i);
> }
>
> There's a possible overflow of a signed int in there. This is undefined
> behaviour. Now, you migh
On Sunday, March 27, 2016 at 1:10:51 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
> > No it's not meaningless if it "might" overflow, it's meaningless if it
> > -does- overflow,
>
> No! That's exactly wrong!
>
> Paul, thank you for inadvertently provin
On Sun, 27 Mar 2016 01:30 am, Chris Angelico wrote:
> On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
>> I'm surprised that both C and Python allow statements that apparently do
>> nothing. In both, an example is:
>>
>> x
>>
>> on a line by itself. This expression is evaluated, but then any resul
On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> For example, would you consider that this isolated C code is
>> "meaningless"?
>> int i = n + 1;
>
> It's meaningful as long as n is in a certain range of values so there's
> no overflow.
>
>> But according to the stan
On Sat, 26 Mar 2016 08:23 am, Chris Angelico wrote:
> On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano
> wrote:
>> Undefined behaviour does not mean "implementation specific behaviour".
>> Nor does it mean "something sensible will happen but we don't promise
>> what it will be". It means "the co
On Sunday, March 27, 2016 at 12:05:01 PM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > eg haskell (ghc) is written in ghc
> > Where did the first bootstrap start from?
>
> The very earliest Haskell implementation was written in Lisp.
Ummm So you found a little chink in my argument -- Ok :
Rustom Mody writes:
> eg haskell (ghc) is written in ghc
> Where did the first bootstrap start from?
The very earliest Haskell implementation was written in Lisp.
--
https://mail.python.org/mailman/listinfo/python-list
BartC writes:
> But my suggestion was to have required a keyword in front of
> such expressions.
Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?
The compiler can't tell which of those expressions has a side effect.
The first might be buggy cod
Steven D'Aprano writes:
> For example, would you consider that this isolated C code is
> "meaningless"?
> int i = n + 1;
It's meaningful as long as n is in a certain range of values so there's
no overflow.
> But according to the standard, it's "meaningless", since it might
> overflow, and signed
On Sunday, March 27, 2016 at 10:32:34 AM UTC+5:30, Rustom Mody wrote:
> I had an impression of seeing some discussion on this and resolved not
> to incorporate.
Meaning: I think I remember something about a resolution -- after some debate
-- not to OO-ify the C/Unix errno system
--
https://mail.p
On Sunday, March 27, 2016 at 2:15:22 AM UTC+5:30, Terry Reedy wrote:
> On 3/26/2016 1:43 PM, Rustom Mody wrote:
>
> > There is this nice piece of OO called the exception hierarchy:
>
> > https://docs.python.org/2/library/exceptions.html#exception-hierarchy
>
> https://docs.python.org/3/library/
On Sun, Mar 27, 2016 at 1:44 PM, Steven D'Aprano wrote:
> If [anyone] takes over the world and bans C, insisting that it be
> replaced with a new language of his own design called "T", the
> *implementation* of CPython would have to change, but the *interface*, the
> language itself, won't have to
On Sun, 27 Mar 2016 04:43 am, Rustom Mody wrote:
> On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>>
>> > For one thing its good to remember that we wouldn't be here without
>> > python Python wouldn't be what it is w
On Sun, Mar 27, 2016 at 4:43 AM, Rustom Mody wrote:
> On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>>
>> > For one thing its good to remember that we wouldn't be here without python
>> > Python wouldn't be what it is
On 3/26/2016 1:43 PM, Rustom Mody wrote:
There is this nice piece of OO called the exception hierarchy:
> https://docs.python.org/2/library/exceptions.html#exception-hierarchy
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
BaseException ⊇ Exception ⊇ EnvironmentError
On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>
> > For one thing its good to remember that we wouldn't be here without python
> > Python wouldn't be what it is without CPython
>
> There is nothing about Python that r
On 26/03/2016 14:30, Chris Angelico wrote:
On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
I'm surprised that both C and Python allow statements that apparently do
nothing. In both, an example is:
x
on a line by itself. This expression is evaluated, but then any result
discarded. If there wa
On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
> I'm surprised that both C and Python allow statements that apparently do
> nothing. In both, an example is:
>
> x
>
> on a line by itself. This expression is evaluated, but then any result
> discarded. If there was a genuine use for this (for examp
On 26/03/2016 13:22, Chris Angelico wrote:
On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano wrote:
In plain English, if the programmer had an intention for the code, and it
was valid C syntax, it's not hard to conclude that the code has some
meaning. Even if that meaning isn't quite what the p
On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano wrote:
> In plain English, if the programmer had an intention for the code, and it
> was valid C syntax, it's not hard to conclude that the code has some
> meaning. Even if that meaning isn't quite what the programmer expected.
> Compilers are well
On Sat, 26 Mar 2016 01:59 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Culturally, C compiler writers have a preference for using undefined
>> behaviour to allow optimizations, even if it means changing the semantics
>> of your code.
>
> If your code has UB then by definition it has no sem
On Sat, Mar 26, 2016 at 9:39 PM, Steven D'Aprano wrote:
> It is an accident of history that Python's first and major implementation
> happens to be written in C. (Although its use as a glue language, allowing
> people to safely use libraries written in C, probably played a role in
> ensuring Pytho
On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
> For one thing its good to remember that we wouldn't be here without python
> Python wouldn't be what it is without CPython
There is nothing about Python that relies on the C standard being as it is.
There are Python implementations that are not w
Steven D'Aprano :
> On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
>> Yes, although the same could be true for Python as well.
>
> Is this a philosophical question? Yes, it *could* be true, in some
> alternate universe, but it isn't actually true.
>
> Python does not have undefined behaviour
On Friday, March 25, 2016 at 9:20:23 PM UTC+5:30, Steven D'Aprano wrote:
>
> Undefined behaviour in C is a minefield waiting to blow your program's legs
> off, because the designers of the language made the explicit choice that
> they wanted the language to be as fast and efficient as possible, ev
Steven D'Aprano writes:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code.
If your code has UB then by definition it has no semantics to change.
Code with UB has no meaning.
--
https:
On Fri, Mar 25, 2016, at 22:46, Steven D'Aprano wrote:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code. The C compiler is allowed to ignore your code, move it
> around
> so that things
On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Undefined behaviour in C is a minefield waiting to blow your program's
>> legs off, because the designers of the language made the explicit
>> choice that they wanted the language to be as fast and efficient as
>> possib
On Sat, 26 Mar 2016 09:08 am, BartC wrote:
> On 25/03/2016 16:22, Steven D'Aprano wrote:
>> On Fri, 25 Mar 2016 10:06 pm, BartC wrote:
>
> (OK, I'll risk the wrath of Mark Lawrence et al by daring to post my
> opinions.)
Please ignore Mark Lawrence when he is acting as an obnoxious troll, as he
On 25/03/2016 16:22, Steven D'Aprano wrote:
On Fri, 25 Mar 2016 10:06 pm, BartC wrote:
(OK, I'll risk the wrath of Mark Lawrence et al by daring to post my
opinions.)
But it is an optimisation that /could/ be done by the byte-code compiler
I would also expect that Victor Stinner's FAT Py
On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano wrote:
> On Fri, 25 Mar 2016 06:54 am, BartC wrote:
>
>>> In the case of C, the line is limited to working with some specific type
>>> (say, an int32). Even there, if the addition might overflow, the
>>> behaviour is undefined and the compiler can d
On 25/03/2016 02:49, Michael Torrie wrote:
I've been trying to follow things on this thread, and I understand a bit
about Pythonic ideomatic style and I know what Python is really good at
and some of what it's not so good at, but it seems like one of Bart's
original contentions was that given a
Steven D'Aprano :
> Undefined behaviour in C is a minefield waiting to blow your program's
> legs off, because the designers of the language made the explicit
> choice that they wanted the language to be as fast and efficient as
> possible, even at the cost of safe, reproducible behaviour.
Yes, a
On Fri, 25 Mar 2016 10:06 pm, BartC wrote:
> On 25/03/2016 01:02, Dennis Lee Bieber wrote:
>> On Thu, 24 Mar 2016 19:54:54 +, BartC declaimed the
>> following:
>>
>>
>>>
>>> (I use a dedicated repeat-N-times loop that needs no explicit loop
>>> variable,
>
>> Well, that sure wouldn't support
On Fri, 25 Mar 2016 06:54 am, BartC wrote:
>> In the case of C, the line is limited to working with some specific type
>> (say, an int32). Even there, if the addition might overflow, the
>> behaviour is undefined and the compiler can do anything it wants
>> (including time travel,
>
> I'm pretty
On 25/03/2016 01:02, Dennis Lee Bieber wrote:
On Thu, 24 Mar 2016 19:54:54 +, BartC declaimed the
following:
(I use a dedicated repeat-N-times loop that needs no explicit loop
variable,
Well, that sure wouldn't support a Python for-loop...
If I may, I'll reply to this point
On 03/24/2016 04:18 PM, Mark Lawrence wrote:
> On 24/03/2016 19:54, BartC wrote:
>> On 24/03/2016 18:10, Steven D'Aprano wrote:
>>> On Fri, 25 Mar 2016 12:01 am, BartC wrote:
>>
>>>
>>> Then those numbers are pointless.
>>
>> Yes, they would need some adjustment to do this stuff properly.
>
> Plea
On Thursday, March 24, 2016 at 2:03:58 PM UTC-4, BartC wrote:
> On 24/03/2016 17:13, Ned Batchelder wrote:
> > On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:
> >> On 24/03/2016 15:30, Ned Batchelder wrote:
> >>> On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
On 12/03/2016 01:16, BartC wrote:
Please go and play with this.
https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you ca
On 24/03/2016 14:37, Rustom Mody wrote:
On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote:
BartC :
And forgetting Python for a minute and concentrating only on its
byte-code as a language in its own right, how would you go about the
job of streamlining it?
Really, you
On 24/03/2016 19:54, BartC wrote:
On 24/03/2016 18:10, Steven D'Aprano wrote:
On Fri, 25 Mar 2016 12:01 am, BartC wrote:
Then those numbers are pointless.
Yes, they would need some adjustment to do this stuff properly.
Please give up before you get sued by the families of the people who
On 24/03/2016 18:10, Steven D'Aprano wrote:
On Fri, 25 Mar 2016 12:01 am, BartC wrote:
Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
but this is not executing code indirectly as most of the rest have
On 03/21/2016 06:43 AM, BartC wrote:
> On 21/03/2016 12:08, Ned Batchelder wrote:
>> On Sunday, March 20, 2016 at 9:15:32 PM UTC-4, BartC wrote:
>>>
>>> A tokeniser along those lines in Python, with most of the bits filled
>>> in, is here:
>>>
>>> http://pastebin.com/dtM8WnFZ
>>>
>>
>> Bart, we get
On 2016-03-24, Steven D'Aprano wrote:
> On Fri, 25 Mar 2016 02:03 am, Jon Ribbens wrote:
>> On 2016-03-24, BartC wrote:
>>> On 24/03/2016 14:08, Jon Ribbens wrote:
if you thought you needed to do that then most likely what you
should actually be doing is re-writing your code so you no l
On Thu, 24 Mar 2016 14:28:32 +, BartC wrote:
> On 24/03/2016 14:01, Chris Angelico wrote:
>
>> I don't, until it's pointed out. At that point, someone who respects
>> the language will at least pay *some* heed to the changed
>> recommendations; what we're seeing here is that he continues to u
On Thu, 24 Mar 2016 14:04:53 +, BartC wrote:
> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>>
>>
>>> This is how you're currently evaluating Python. Instead of starting
>>> with the most simple and obvious code
>>
>> One problem is that wh
On Fri, 25 Mar 2016 12:01 am, BartC wrote:
> But there are all sorts of micro-micro-benchmarks that can concentrate
> on a single byte-code. For example, how long does it take to call an
> empty function with no parameters? Just putting such a call into a
> simple loop can be effective:
>
> Python
On 24/03/2016 17:13, Ned Batchelder wrote:
On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:
On 24/03/2016 15:30, Ned Batchelder wrote:
On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
You know what is missing from this conversation?
For one of Bart's criti
On Fri, 25 Mar 2016 02:03 am, Jon Ribbens wrote:
> On 2016-03-24, BartC wrote:
>> On 24/03/2016 14:08, Jon Ribbens wrote:
>>> if you thought you needed to do that then most likely what you
>>> should actually be doing is re-writing your code so you no longer
>>> need to. However, you could do:
>>
On Fri, 25 Mar 2016 01:16 am, BartC wrote:
> Or is the Pythonic way, when you want to change some elements of a list
> to just build a new one that incorporates those changes?
If you are only changing a few elements, or one at a time in some random
order, then just change the element. Lists have
On Fri, 25 Mar 2016 01:04 am, BartC wrote:
> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>>
>>
>>> This is how you're currently evaluating Python. Instead of starting
>>> with the most simple and obvious code
>>
>> One problem is that what cou
On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:
> On 24/03/2016 15:30, Ned Batchelder wrote:
> > On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
> >> You know what is missing from this conversation?
> >>
> >> For one of Bart's critics to actually show faster c
On 24/03/2016 15:30, Ned Batchelder wrote:
On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
You know what is missing from this conversation?
For one of Bart's critics to actually show faster code.
There's plenty of people telling him off for writing unpythonic and slow
c
On Thu, Mar 24, 2016, at 11:18, BartC wrote:
> On 24/03/2016 15:03, Jon Ribbens wrote:
> > No it isn't, it's replacing the elements in-place,
>
> Replace them with what, if not an entirely new list built from
> '[0]*len(L)'?
Well, the *contents* of such a list, obviously. But the original list's
On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
> You know what is missing from this conversation?
>
> For one of Bart's critics to actually show faster code.
>
> There's plenty of people telling him off for writing unpythonic and slow
> code, but I haven't seen anyone act
On 2016-03-24, BartC wrote:
> On 24/03/2016 14:08, Jon Ribbens wrote:
>> if you thought you needed to do that then most likely what you
>> should actually be doing is re-writing your code so you no longer
>> need to. However, you could do:
>>
>>L[:] = [0] * len(L)
>
> OK, but that's just build
On 2016-03-24, BartC wrote:
> On 24/03/2016 15:03, Jon Ribbens wrote:
>> On 2016-03-24, BartC wrote:
>>> On 24/03/2016 14:08, Jon Ribbens wrote:
if you thought you needed to do that then most likely what you
should actually be doing is re-writing your code so you no longer
need to.
On 24/03/2016 15:03, Jon Ribbens wrote:
On 2016-03-24, BartC wrote:
On 24/03/2016 14:08, Jon Ribbens wrote:
if you thought you needed to do that then most likely what you
should actually be doing is re-writing your code so you no longer
need to. However, you could do:
L[:] = [0] * len(L)
On Thu, Mar 24, 2016, at 10:49, BartC wrote:
> On 24/03/2016 14:34, Jussi Piitulainen wrote:
> > You understand correctly, but it may be more natural in practice to
> > write it this way:
> >
> > for k, item in enumerate(them):
> > them[k] = f(item)
> >
> > I _think_ I might write i
On 24/03/2016 14:34, Jussi Piitulainen wrote:
BartC writes:
On 24/03/2016 14:08, Jon Ribbens wrote:
On 2016-03-24, BartC wrote:
I'd presumably have to do:
for i in range(len(L)):
L[i]=0
That's kind've a weird thing to want to do;
The thing I'm trying to demonstrate is changing a
On 24/03/2016 14:22, Matt Wheeler wrote:
The point is that one can just do `mylist.clear()`
Only in 3.3 and up. In Python 2.x you have to do it the old fashioned,
long winded way.
mylist[:] = []
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for o
On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote:
> BartC :
>
> > And forgetting Python for a minute and concentrating only on its
> > byte-code as a language in its own right, how would you go about the
> > job of streamlining it?
> Really, your optimization efforts shoul
On 24/03/2016 14:01, Chris Angelico wrote:
I don't, until it's pointed out. At that point, someone who respects
the language will at least pay *some* heed to the changed
recommendations; what we're seeing here is that he continues to use C
idioms and then complain that Python is slow. I don't ex
BartC writes:
> On 24/03/2016 14:08, Jon Ribbens wrote:
>> On 2016-03-24, BartC wrote:
>>> I'd presumably have to do:
>>>
>>>for i in range(len(L)):
>>> L[i]=0
>>
>> That's kind've a weird thing to want to do;
>
> The thing I'm trying to demonstrate is changing an element of a list
> that
BartC :
> And forgetting Python for a minute and concentrating only on its
> byte-code as a language in its own right, how would you go about the
> job of streamlining it?
CPython's bytecode is not crucial for CPython's execution speed. The
bytecode is mainly a method of improving the performance
On 24 March 2016 at 14:04, BartC wrote:
>On 24/03/2016 13:50, Steven D'Aprano wrote:
>> for i in range(len(mylist)-1, -1, 0):
>> del mylist[i]
>
> That's wouldn't be I'd call clearing a list, more like destroying it
> completely!
Look more closely. The semantics of using the del keyword with
On 24/03/2016 14:08, Jon Ribbens wrote:
On 2016-03-24, BartC wrote:
On 24/03/2016 13:50, Steven D'Aprano wrote:
Likewise clearing a list:
for i in range(len(mylist)-1, -1, 0):
del mylist[i]
That's wouldn't be I'd call clearing a list, more like destroying it
completely!
How would you
On 2016-03-24, BartC wrote:
> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> Likewise clearing a list:
>>
>> for i in range(len(mylist)-1, -1, 0):
>> del mylist[i]
>
> That's wouldn't be I'd call clearing a list, more like destroying it
> completely!
>
> How would you actually clear a list b
On 24/03/2016 13:50, Steven D'Aprano wrote:
On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
This is how you're currently evaluating Python. Instead of starting
with the most simple and obvious code
One problem is that what counts as "simple and obvious" depends on what you
are used to. C
On Fri, Mar 25, 2016 at 12:50 AM, Steven D'Aprano wrote:
> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>
>
>> This is how you're currently evaluating Python. Instead of starting
>> with the most simple and obvious code
>
> One problem is that what counts as "simple and obvious" depends on
On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
> This is how you're currently evaluating Python. Instead of starting
> with the most simple and obvious code
One problem is that what counts as "simple and obvious" depends on what you
are used to. Coming from a background of Pascal, iteratin
On 24/03/2016 03:24, Chris Angelico wrote:
On Thu, Mar 24, 2016 at 12:41 AM, BartC wrote:
To extend this analogy better, executing byte-code to directly perform a
task itself might be equivalent to travelling on foot, while everyone is
suggesting taking the bus, tube or taxi.
It's easy to se
On Thursday, March 24, 2016 at 8:54:49 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Mar 24, 2016 at 12:41 AM, BartC wrote:
> > To extend this analogy better, executing byte-code to directly perform a
> > task itself might be equivalent to travelling on foot, while everyone is
> > suggesting taking
On Thu, Mar 24, 2016 at 12:41 AM, BartC wrote:
> To extend this analogy better, executing byte-code to directly perform a
> task itself might be equivalent to travelling on foot, while everyone is
> suggesting taking the bus, tube or taxi.
>
> But when you are on foot, it might be worth looking at
On 23/03/2016 10:48, Chris Angelico wrote:
On Wed, Mar 23, 2016 at 9:34 PM, BartC wrote:
Someone could be interested in cars, mechanics and performance without
wanting to know the most Pythonic way to get from Kings Cross to Heathrow.
But if I complain that the trek across four blocks of Lo
On 23/03/2016 23:55, Steven D'Aprano wrote:
On Thu, 24 Mar 2016 03:24 am, Random832 wrote:
On Wed, Mar 23, 2016, at 12:08, Mark Lawrence wrote:
And doing it 'Pythonically' can lead to suggestions such as the
following the other day:
c, psource = psource[0], psource[1:]
(where psource is a
On Thu, Mar 24, 2016 at 11:12 AM, Random832 wrote:
> I guess the question is, what do you _actually_ need the tail string
> for? If you're using it in a loop, to pop further characters from (the
> scenario that would cause it to be copying the string over lots of
> times), wouldn't it make more se
On Wed, Mar 23, 2016, at 19:55, Steven D'Aprano wrote:
> while psource:
> c, psource = psource[0], psource[1:]
> lxsymbol = disptable[min(ord(c), 256)](c, psource)
>
>
> But one positive: this conclusively proves that "Pythonic" is in the eye
> of
> the beh
On Thu, 24 Mar 2016 03:24 am, Random832 wrote:
> On Wed, Mar 23, 2016, at 12:08, Mark Lawrence wrote:
>> > And doing it 'Pythonically' can lead to suggestions such as the
>> > following the other day:
>> >
>> > c, psource = psource[0], psource[1:]
>> >
>> > (where psource is a very long string),
On 23/03/2016 16:24, Random832 wrote:
On Wed, Mar 23, 2016, at 12:08, Mark Lawrence wrote:
And doing it 'Pythonically' can lead to suggestions such as the
following the other day:
c, psource = psource[0], psource[1:]
(where psource is a very long string), which even I could tell, from
kno
On Wed, Mar 23, 2016, at 12:08, Mark Lawrence wrote:
> > And doing it 'Pythonically' can lead to suggestions such as the
> > following the other day:
> >
> > c, psource = psource[0], psource[1:]
> >
> > (where psource is a very long string), which even I could tell, from
> > knowing what goes o
On 23/03/2016 06:09, Ben Finney wrote:
Steven D'Aprano writes:
On Mon, 21 Mar 2016 06:47 pm, Ben Finney wrote:
Bart can show good faith by *learning* idiomatic Python, with the
humility of a beginner. And also by refraining from rhetoric about
how bad Python's performance is, until he gains
On 23/03/2016 10:34, BartC wrote:
On 23/03/2016 06:09, Ben Finney wrote:
The problem is that Bart simultaneously is a beginner at Python, and
expresses astonishment that everyone shrugs when Bart's
dreadfully-written code performs so badly.
My interests differ from most people here writing Py
On Wednesday, March 23, 2016 at 6:35:12 AM UTC-4, BartC wrote:
> On 23/03/2016 06:09, Ben Finney wrote:
>
> > The problem is that Bart simultaneously is a beginner at Python, and
> > expresses astonishment that everyone shrugs when Bart's
> > dreadfully-written code performs so badly.
>
> My inte
On Wed, Mar 23, 2016 at 9:57 PM, Tim Golden wrote:
> On 23/03/2016 10:48, Chris Angelico wrote:
>> On Wed, Mar 23, 2016 at 9:34 PM, BartC wrote:
>>> Someone could be interested in cars, mechanics and performance without
>>> wanting to know the most Pythonic way to get from Kings Cross to Heathrow
On 23/03/2016 10:48, Chris Angelico wrote:
> On Wed, Mar 23, 2016 at 9:34 PM, BartC wrote:
>> Someone could be interested in cars, mechanics and performance without
>> wanting to know the most Pythonic way to get from Kings Cross to Heathrow.
>
> But if I complain that the trek across four blocks
On Wed, Mar 23, 2016 at 9:34 PM, BartC wrote:
> ... which even I could tell, from knowing what goes on behind the scenes,
> wasn't going to work well ...
> ...
>> Good faith is contradicted by asserting knowledge of Python, complaining
>> about how some deliberately non-idiomatic Python code is pe
On 23/03/2016 06:09, Ben Finney wrote:
The problem is that Bart simultaneously is a beginner at Python, and
expresses astonishment that everyone shrugs when Bart's
dreadfully-written code performs so badly.
My interests differ from most people here writing Python.
For example, I'm interested
On Wed, Mar 23, 2016 at 5:07 PM, Steven D'Aprano
wrote:
> Fortunately, not all such "bugs" are of equal severity. In this case, there
> are two failure modes. Consider a *false positive* bug: we think the file
> exists when it actually doesn't.
>
> if os.path.exists(filename):
> os.unlink(file
1 - 100 of 274 matches
Mail list logo
