Re: Slices time complexity

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

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 01:33:37 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:21 AM, wrote: > > However I do 'drive' as I've been programming for decades. And I can have > > an opinion about a model of car that I don't normally drive. An opinion > > which you

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 01:22:02 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:11 AM, wrote: > > (128MB or 128KB? In the 1980s we were all running in 64KB to 640KB of > > memory. 128MB might be what a well-endowed mainframe might have had!) > > Yes, and we

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 10:50:20 UTC+1, alister wrote: > Actually the more you make these claims the more I think you are > suffering from NIH (Not Invented Here) syndrome. That's not surprising. I started out developing hardware such as microprocessor boards and video displays. My

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano wrote: > On Monday 01 August 2016 18:05, bart4...@gmail.com wrote: > > > You think that my nearly 30 years' experience of designing interpreted > > languages and writing fast bytecode interpreters doesn't make my opinions > > have any more

Re: Why not allow empty code blocks?

On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: > That said, I wish he'd stop posting his arguments here on this list as > he clearly doesn't use Python for anything, and hasn't used Python for > any real amount of coding. He has no vested interest in Python so why > should his

Re: Why not allow empty code blocks?

On Sunday, 31 July 2016 16:31:56 UTC+1, Steven D'Aprano wrote: > On Sun, 31 Jul 2016 08:18 pm, BartC wrote: > The whole point of an optimizing compiler is that you don't have to detect > patterns yourself. The compiler does it. There's a whole science to writing > optimizing compilers these

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 00:50:09 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 9:43 AM, wrote: > > On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: > > > >> That said, I wish he'd stop posting his arguments here on this list as > >> he clearly doesn't use

Re: Python and the need for speed

On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote: > > > high level languages like Python should make it difficult, if not > > impossible, to write sub- > > optimal code (at least in the blatantly obvious cases). > >

Re: Python and the need for speed

On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: > bartc writes: > > > These are straightforward language enhancements. > > FYI, the question is not how to optimize the code but how to prevent the > programmer from writing stupid code in the first place. Someone > suggested

Re: Python and the need for speed

On Wednesday, 12 April 2017 10:57:10 UTC+1, bart...@gmail.com wrote: > On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > > for i in range(10): > > answer += 1 > > So... how exactly does the compiler prohibit stupid code? > And this lookup happens for every loop

Re: Python and the need for speed

On Wednesday, 12 April 2017 16:04:53 UTC+1, Brecht Machiels wrote: > On 2017-04-12 14:46:45 +, Michael Torrie said: > It would be great if you could run the benchmark I mention in my first > link and share the results. Highly appreciated! Were you ever able to isolate what it was that's

Re: Python and the need for speed

On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen wrote: > bart4...@gmail.com writes: > > > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: > >> bartc writes: > >> > > > >> > These are straightforward language enhancements. > >> > >> FYI, the question is not

Re: Python and the need for speed

On Thursday, 13 April 2017 00:09:35 UTC+1, Gregory Ewing wrote: > bart4...@gmail.com wrote: > > > But the language can also play a part in not allowing certain things to be > > expressed naturally. So the for-loop in the example has to have a > > control-variable even if it's not referenced. >

Re: syntax difference

Features? Important ones? Go back 40 years and see how important they were then. Most of them,nobody had heard of, and would not be meaningful. Now do the same with my list - most are programming features that could be understood and appreciated even then. Finally, imagine going forward 40

Re: syntax difference

Do you think that a feature like swap(x,y) literally only works on two simple variables? X and y represent any two lvalue expressions. For example, a[I] and a[I+1]. Python will evaluate each twice. My version sets up two references then exchanges what they point to with one bytecode. --

Re: syntax difference

I think you're getting a programming language mixed up with a bunch of random libraries. If you want to do any actual coding rather than scripting, such as implementing some of that stuff, then this is where those basic language features that are missing from core Python become useful. What

Re: syntax difference

Some of that can be done. It may not need specific support. But my intention is to have an ordinary language for everyday coding not one that can only be understood by CS professors. Mine is unusual in that I can drop features I rarely use, which means that everything in it gets good use.

Re: syntax difference

You're right. While pointers can be made to fit, it would be an awkward fit into Python and could introduce overheads even when not used. My use of them is frequently when straddling boundaries between languages (a pointer in one environment points to the data of another), or when working just

Re: syntax difference

The actual interpreter code is irrelevant. Switch would be a feature of the language being interpreted, not of the interpreter. If the task is to match an expression X against a variety of values, then expressing that as a switch means the interpreter /could/ use a jump table (of labels within

Re: syntax difference

(Sorry no idea how to do quoting on this mobile app I have to use.) Those examples of using network features are merely examples of function calls. This is what I'm talking about with basic language features. Pointers are merely an extra level of indirection; they can be made to fit. A few

Re: syntax difference

If you're genuinely interested in how pointers might work I'll try and write that up when I get back to a real machine, and will do it in the form of a link. Since people are clearly unhappy with discussing features that ought to be in Python in a Python forum. --

Re: syntax difference

It isn't about my language versus Python. It is about the surprising number of simple features that are missing and that people are claiming don't matter, despite the considerable efforts made to provide them via add-ons. But I'm glad you stepped because making these posts via a smartphone AND

Re: syntax difference

Alister: == which can be implemented in python by putting function calls as members of a list or dictionary switch=[case1,case2,case3] switch[a]() == This is the approach you might use when you don't have a proper switch. It could be done in C that way. Problems: the code for the

Re: Feeding the trolls

What a friendly, welcoming and open-minded group this is! It costs me some genuine effort to make what I believe are relevant and interesting technical posts, and people are discussing not just how to avoid seeing them, but how to screen anyone who wants to reply. Yes my posts are more 'meta'

Re: Feeding the trolls

Steven D'Aprano wrote: == If you were more interested in appreciating Python for what it is, instead of turning everything into a pissing contest where your personal, private language does it better, your experience might be different. And who knows, you might even learn a thing or two.

Re: syntax difference

Yeah, people keep bringing that up when they run out of arguments. So, every programmer must always use the most advanced, most esoteric features possible at every opportunity? Coding should only be for the elite? There is a place for various levels of programming language. I'm saying that

Re: syntax difference

Pointers are perhaps a more technical feature. Switch and case, the latter a more general version of switch, are universal. Repeat n times is universal. While it is trivial to implement with other constructs, it as an annoyance and distraction that is easily fixed. Now you will probably say it