Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #84819 > unrolled thread
| Started by | 1989lzhh <1989lzhh@gmail.com> |
|---|---|
| First post | 2015-01-29 21:39 +0800 |
| Last post | 2015-01-30 20:35 -0700 |
| Articles | 5 on this page of 65 — 16 participants |
Back to article view | Back to comp.lang.python
[OT] fortran lib which provide python like data type 1989lzhh <1989lzhh@gmail.com> - 2015-01-29 21:39 +0800
Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-01-29 14:39 -0800
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-29 17:40 -0800
Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-30 08:32 +0100
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 08:27 -0800
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 10:08 -0700
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 09:31 -0800
RAII vs gc (was fortran lib which provide python like data type) Rustom Mody <rustompmody@gmail.com> - 2015-01-30 10:02 -0800
Re: RAII vs gc (was fortran lib which provide python like data type) Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 21:28 +0000
Re: RAII vs gc (was fortran lib which provide python like data type) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 14:00 +1100
Re: RAII vs gc (was fortran lib which provide python like data type) Chris Angelico <rosuav@gmail.com> - 2015-02-01 14:21 +1100
Re: RAII vs gc (was fortran lib which provide python like data type) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-31 19:27 -0800
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 11:15 -0700
Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-30 10:23 -0800
Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-31 09:27 +0100
Re: [OT] fortran lib which provide python like data type Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-31 11:51 +1300
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:49 +1100
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 14:22 +0200
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 07:50 -0800
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 19:43 +0200
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 18:30 -0800
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:38 +0200
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:49 +1100
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 20:57 +0200
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 12:59 +1100
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 13:05 +1100
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:51 +0200
Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:04 +1100
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 18:01 +1100
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:52 +0200
Re: [OT] fortran lib which provide python like data type Paul Rudin <paul.nospam@rudin.co.uk> - 2015-02-02 12:56 +0000
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 15:27 +0200
Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:08 +0000
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-02-02 08:21 -0800
Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:52 +0000
Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 04:25 +1100
Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 18:34 +0000
Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 10:15 +1100
Re: [OT] fortran lib which provide python like data type Matthew Barnett <auxlang@mrabarnett.plus.com> - 2015-02-02 02:35 +0000
Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:45 +1100
Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:12 -0500
Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:14 -0500
Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 15:47 +1100
Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:06 +0000
Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-31 17:59 +0000
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 13:27 +1100
Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-31 22:26 -0800
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:58 +0200
Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-02-01 09:14 +0100
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 21:12 +0200
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 17:50 -0700
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 09:39 +0200
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 09:25 -0700
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 19:57 +0200
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 11:23 -0700
Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 20:54 +0200
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-02-02 05:30 -0800
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:50 +1100
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:49 -0700
Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 22:04 +1100
Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 08:18 -0800
Re: [OT] fortran lib which provide python like data type Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 23:12 +0000
Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:35 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2015-01-30 20:49 -0700 |
| Message-ID | <mailman.18329.1422676162.18130.python-list@python.org> |
| In reply to | #84926 |
On 01/30/2015 04:50 PM, Steven D'Aprano wrote: > Oh great. So if the average application creates a hundred thousand pointers > of the course of a session, you'll only have a thousand or so seg faults > and leaks. > > Well, that certainly explains this: > > https://access.redhat.com/articles/1332213 I fail to see the connection. GLibc is a low-level library written in C, not C++. By its nature requires a lot of pointer use, and is prone to having errors. But not that many, seeing as *all* Linux software depends on it and uses at least part of it *all* the time. Pretty remarkable if you ask me. Wonder how they do it. Perhaps they try to follow "basic rules." > Manual low-level pointer manipulation is an anti-pattern. What you glibly > describe as programmers following "basic rules" has proven to be beyond the > ability of the programming community as a whole. I don't see how you would write system code without this "anti-pattern" as you describe. Python is a great language for everything else, but I certainly wouldn't call it a system language. Couldn't write a kernel in it without providing it with some sort of unsafe memory access (pointers!). Or even write a Python interpreter (Yes there's PyPy, but with a jit it's still working with pointers). What I call glibly "basic rules" are in fact shown to more or less work out, as Glibc proves. Pointer use does lead to potential vulnerabilities. And they must be corrected as they are found. Still not sure what your point is. Is there a reason to use C or C++ for many of us? Nope. I'm not arguing that we should find them of use. It's easy for us to sit on Python and look with contempt at C or C++, but they really do have their place (C more than C++ IMO). This is so far off the original topic that it probably is construed that I am arguing for C++ vs Python or something. But I am not. I'm quite content with Python. There are a host of languages I find interesting including D, Google Go, Vala, FreeBASIC, Mozilla Rust, etc. But Python fits my needs so well, I can't be bothered to invest much time in these other languages.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-31 22:04 +1100 |
| Message-ID | <54ccb6a2$0$12985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84934 |
Michael Torrie wrote: > On 01/30/2015 04:50 PM, Steven D'Aprano wrote: >> Oh great. So if the average application creates a hundred thousand >> pointers of the course of a session, you'll only have a thousand or so >> seg faults and leaks. >> >> Well, that certainly explains this: >> >> https://access.redhat.com/articles/1332213 > > I fail to see the connection. The connection is that you made a comment about eliminating "99%" of segfaults, as if that was something to be proud of. It's not. Like 99% uptime (which means you are down for over three and a half days per year), it's not very impressive. All it takes is *one* mishandled pointer, and you can have a seg fault, leak, buffer overflow, security exploit, or other serious bug. Which leads to vulnerabilities like Ghost. Yesterday, as I wrote that message, my web browser crashed *eight times* in a matter of half an hour. There are thousands of serious security vulnerabilities due to mishandled pointers. Anyone who thinks that Linux is "secure" is deluding themselves. It's only secure in comparison to nightmares like Windows. The fact is, the security of computer systems is best described as "with care and attention to detail, we can make it merely awful". And the manual use of pointers in low-level languages like C is a huge factor in that. > GLibc is a low-level library written in C, > not C++. By its nature requires a lot of pointer use, and is prone to > having errors. But not that many, seeing as *all* Linux software > depends on it and uses at least part of it *all* the time. Pretty > remarkable if you ask me. Wonder how they do it. Perhaps they try to > follow "basic rules." Exactly. And as Ghost demonstrates, that is *not good enough*. >> Manual low-level pointer manipulation is an anti-pattern. What you glibly >> describe as programmers following "basic rules" has proven to be beyond >> the ability of the programming community as a whole. > > I don't see how you would write system code without this "anti-pattern" > as you describe. Python is a great language for everything else, but I > certainly wouldn't call it a system language. I didn't actually mention Python. > Couldn't write a kernel > in it without providing it with some sort of unsafe memory access > (pointers!). Or even write a Python interpreter (Yes there's PyPy, but > with a jit it's still working with pointers). Systems languages now are, in a sense, in the same position that programming was back in the days before the invention of Fortran. The programmer, writing in a low-level assembly, was responsible for pushing items onto the stack, jumping to a sub-routine, popping the arguments off, then jumping back to the return address. Before Fortran, there were a number of proto-languages that aimed to make that safer, but Fortran was the first language where the compiler itself could completely handle all the book-keeping needed to use functions easily and safely. The problem is not *pointers*, but "manual low-level pointer manipulation", as I said. We programmers are expected to work out how much memory we need before allocating a pointer, remember to check whether it is nil or not before dereferencing it, don't forget to release the memory when you're done, oh you just wrote past the end of the buffer and now the Russian mob owns your computer... Where are the systems languages that will do to pointer access what Fortran did to the stack? They do exist: Rust claims to be a blazing fast systems language that is memory-safe and eliminates dangling pointers and buffer overflows at compile time. Assuming this is true, that means that the Rust compiler could generate code that is just as fast and efficient as C but without all the unsafe memory accesses of C. http://doc.rust-lang.org/nightly/intro.html#ownership I've never used Rust. I don't know whether it is ready for kernel development, or whether it lives up to its claims. Rust itself is not the point: there are other approaches to memory-safety, some of them are suitable for application development and some are suitable for systems languages. C is now four decades old. It took a single decade to go from hand-writing machine code in binary to Fortran, and here we are sixty years later still having buffer overflows. The fact that C is still one of the top three *application development languages* is a shameful indictment on the conservatism, resistance to change, intellectual laziness and hubris of the programming community as a whole. I won't go so far as to say that C must die. But it must become a niche language, used for the tiny (and growing ever more tiny as time goes on) segment of code that modern, memory-safe languages *provably* cannot handle. > What I call glibly "basic rules" are in fact shown to more or less work > out, as Glibc proves. Pointer use does lead to potential > vulnerabilities. And they must be corrected as they are found. Still > not sure what your point is. No. They must be prevented from existing in the first place. We know that the NSA and other hostile government organisations are engaged in a concerted effort to weaponise software bugs. Criminal organisations mass deploy malware at random against hundreds of millions of machines at a time. Other groups write "advanced persistent threats", effectively custom malware targeted specifically at a single person or organisation. All these things have something in common: they rely on bugs in the targeted software. Eliminate insecure and buggy software, and you eliminate these threats. (Buffer overflows are not the only source of exploitable bugs. Today, they're not even the number one such source. But they are number two.) > Is there a reason to use C or C++ for many of us? Nope. I'm not > arguing that we should find them of use. It's easy for us to sit on > Python and look with contempt at C or C++, but they really do have their > place (C more than C++ IMO). This is so far off the original topic that > it probably is construed that I am arguing for C++ vs Python or > something. But I am not. I'm quite content with Python. There are a > host of languages I find interesting including D, Google Go, Vala, > FreeBASIC, Mozilla Rust, etc. But Python fits my needs so well, I can't > be bothered to invest much time in these other languages. I cannot disagree with that. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-01-31 08:18 -0800 |
| Message-ID | <3f60b63d-d4f3-474b-9290-0d87948a7af2@googlegroups.com> |
| In reply to | #84950 |
On Saturday, January 31, 2015 at 4:34:14 PM UTC+5:30, Steven D'Aprano wrote: > > Yesterday, as I wrote that message, my web browser crashed *eight times* in > a matter of half an hour. There are thousands of serious security > vulnerabilities due to mishandled pointers. Anyone who thinks that Linux > is "secure" is deluding themselves. It's only secure in comparison to > nightmares like Windows. The fact is, the security of computer systems is > best described as "with care and attention to detail, we can make it merely > awful". Beware that may be closer to ghost than you may think http://blog.trendmicro.com/trendlabs-security-intelligence/analyzing-cve-2015-0311-flash-zero-day-vulnerability/
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2015-01-30 23:12 +0000 |
| Message-ID | <mailman.18324.1422659559.18130.python-list@python.org> |
| In reply to | #84899 |
Michael Torrie <torriem@gmail.com> wrote: > Yes I can tell you haven't used C++. Compared to C, I've always found > memory management in C++ to be quite a lot easier. The main reason is > that C++ guarantees objects will be destroyed when going out of scope. > So when designing a class, you put any allocation routines in the > constructor, and put deallocation routines in the destructor. And it > just works. This is something I miss in other languages, even Python. Python has context managers for that.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2015-01-30 20:35 -0700 |
| Message-ID | <mailman.18328.1422675320.18130.python-list@python.org> |
| In reply to | #84899 |
On 01/30/2015 04:12 PM, Sturla Molden wrote: > Michael Torrie <torriem@gmail.com> wrote: > >> Yes I can tell you haven't used C++. Compared to C, I've always found >> memory management in C++ to be quite a lot easier. The main reason is >> that C++ guarantees objects will be destroyed when going out of scope. >> So when designing a class, you put any allocation routines in the >> constructor, and put deallocation routines in the destructor. And it >> just works. This is something I miss in other languages, even Python. > > Python has context managers for that. Right I had forgotten about that. That's a good solution for dynamic, GC languages.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.python
csiph-web