Re: Help with Streaming and Chunk Processing for Large JSON Data (60 GB) from Kenna API
2qdxy4rzwzuui...@potatochowder.com writes:
[...]
> In Common Lisp, you can write integers as #nnR[digits], where nn is the
> decimal representation of the base (possibly without a leading zero),
> the # and the R are literal characters, and the digits are written in
> the intended base. So the input #16f is read as the integer 65535.
Typo: You meant #16R, not #16f.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Bug in 3.12.5
Martin Nilsson writes:
> The attached program doesn’t work in 3.12.5, but in 3.9 it worked.
Attachments don't show up either on the mailing list or the newsgroup.
Try again with the program inline in your post (if it's not too long).
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Process.start
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> marc nicole wrote or quoted:
>>Thanks for the reply, Here's the code I tested for the debug:
>>print("executed")
>>but neither "Hello World" or "Executed" are displayed in the console which
>
> It shouldn't spit out "Executed" 'cause there's a lowercase
> "e" in the mix. Talk about sweating the small stuff!
>
> That 'if __name__ == "__main__"' jazz? It's barking up the wrong
> tree here, just muddying the waters. I'd 86 that clause for now.
>
> In your start() function call, you're rockin' "do_something()",
> but the actual function's defined as "do_Something()" with a
> capital "S". Python's all about that case sensitivity.
>
> Dropping that "exit(0)" bomb right after firing up the process?
> That's like bailing on a gnarly wave before you even catch it.
> It might pull the plug on the main process before the kid process
> has a chance to strut its stuff.
>
> Those "ghello" and "fhello" functions? They're just chillin'
> there, not pulling their weight!
[...]
Stefan, you've recently started using a lot of slang in your posts.
I suggest that this is counterproductive. For me, it makes your
posts more difficult to read. I can imagine that it would be even
more difficult for readers whose first language is not English.
You also indent your own new text, which is exactly the opposite of
common Usenet conventions. (You've been doing this for a long time.)
Please consider prioritizing your readers' convenience over whatever
benefit you derive from your unconventional posting style.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: ListAdmin: Is list/archive working correctly?
Ethan Furman writes:
> On 8/30/24 15:28, dn via Python-list wrote:
>> The OP was @Gilmeh Serda (from an invalid email address). That appears in
>> the email thread
>>
>> @Stefan Ram has had two contributions quoted, but no such original-message
>> has appeared in the thread.
>
> I can't speak about the archives, but I can say that Stefan's posts
> are discarded automatically since they are opposed to their words
> showing up on the list.
I'm posting this on the comp.lang.python Usenet newsgroup.
Stefan Ram's posts to comp.lang.python include several header lines,
including "X-No-Archive: Yes". I presume the software that copies
comp.lang.python posts to python-list pays attention to some of those
header lines. (I personally think it's silly to impose this kind of
restriction. The Usenet group and the mailing list are both public.)
Lawrence D'Oliveiro adds the string "(Posting On Python-List
Prohibited)" to the subject on his articles, for reasons he has
declined to discuss. I don't know whether the software recognizes
that.
Can someone who manages the list software discuss the exact
rules? I suggest that those rules should be documented on
<https://mail.python.org/mailman/listinfo/python-list>.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: new here
Lawrence D'Oliveiro writes:
> On 23 Aug 2024 03:43:15 GMT, rbowman wrote:
>> I am confused by the cross-over to Python-list. I only read/post to
>> comp.lang.python. Is that echoed to Python-list or vice versa?
>
> This has been happening, without asking our permission, for years.
The comp.lang.python newsgroup and the Python-list mailing list
are bidirectionally gatewayed. Both are public. Why is that a
problem for you? Whose permission do you think is needed?
https://mail.python.org/mailman/listinfo/python-list
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: bring back nntp library to python3
"test" writes:
> why is the nntp library deprecated in recent python versions? they
> clearly lost touch
nntplib is not vanishing into thin air. It's just not going to be part
of a default Python installation. (It's not there in Python 3.13.0rc1.)
In my opinion the use of the word "deprecated" is misleading.
$ python3
Python 3.12.4 (main, Jun 27 2024, 13:53:59) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import nntplib
:1: DeprecationWarning: 'nntplib' is deprecated and slated for removal
in Python 3.13
>>>
$
<https://pypi.org/project/nntplib/>
The rationale for removing nntplib and other modules from the default
installation is explained in PEP 0594 <https://peps.python.org/pep-0594/>.
"""
Back in the early days of Python, the interpreter came with a large
set of useful modules. This was often referred to as “batteries
included” philosophy and was one of the cornerstones to Python’s success
story. Users didn’t have to figure out how to download and install
separate packages in order to write a simple web server or parse email.
Times have changed. With the introduction of PyPI (née Cheeseshop),
setuptools, and later pip, it became simple and straightforward to
download and install packages. Nowadays Python has a rich and vibrant
ecosystem of third-party packages. It’s pretty much standard to either
install packages from PyPI or use one of the many Python or Linux
distributions.
[...]
The nntplib module implements the client side of the Network News
Transfer Protocol (nntp). News groups used to be a dominant platform for
online discussions. Over the last two decades, news has been slowly but
steadily replaced with mailing lists and web-based discussion
platforms. Twisted is also planning to deprecate NNTP support and pynntp
hasn’t seen any activity since 2014. This is a good indicator that the
public interest in NNTP support is declining.
The nntplib tests have been the cause of additional work in the recent
past. Python only contains the client side of NNTP, so the tests connect
to external news servers. The servers are sometimes unavailable, too
slow, or do not work correctly over IPv6. The situation causes flaky
test runs on buildbots.
"""
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: ModuleNotFoundError: No module named 'Paramiko'
Thomas Passin writes:
> On 4/8/2024 2:01 PM, Dietmar Schwertberger via Python-list wrote:
>> To be sure, you can always go the the directory of the Python
>> interpreter and open a cmd window there.
>> (By entering 'cmd' into the explorer address bar.)
>> Then enter 'python.exe -mpip install paramiko'.
>> This way you can be sure that you're not running a pip.exe that
>> belongs to another Python interpreter.
>
> This is not quite right. The best name of the Python executable may or
> may not be "python.exe". The command line needs a space after the
> "-m":
No, the option and its argument can be bundled. "-mpip" is equivalent
to "-m pip". (The space might make it clearer for human readers.)
[...]
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Invalid literal for int() with base 10?
Keith Thompson writes:
> "Kevin M. Wilson" writes:
>> Ok, I'm not finding any info. on the int() for converting a str to an
>> int (that specifies a base parameter)?!
>
> https://docs.python.org/3/library/functions.html#int
[...]
Or `print(int.__doc__)` at a Python ">>>" prompt, or `pydoc int`
(or `pydoc3 int`) at a shell prompt. The latter may or may not be
available.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Invalid literal for int() with base 10?
"Kevin M. Wilson" writes:
> Ok, I'm not finding any info. on the int() for converting a str to an
> int (that specifies a base parameter)?!
https://docs.python.org/3/library/functions.html#int
> The picture is of the code I've written...
I don't see a picture. The mailing list probably does not accept
attachments. (You don't need a picture anyway.)
> And the base 10 paradigm involved??
The int() constructor takes a base parameter whose default value is 10.
If you specify base=0, it will accept binary, octal, and hexadecimal
numbers in addition to decimal. All this is explained in the link I
gave you.
> years = int('y') # store for calculationValueError: invalid
> literal for int() with base 10: 'y'What is meant by "invalid literal"?
'42' is a valid literal for int(). 'y' is not.
What value did you expect int('y') to give you?
Perhaps you have a variable named 'y' containing a string? If so, you
might want something like int(y) or int(f{'y'}), but int('y') passes the
literal string 'y', which has nothing to do with a variable of that
name.
> I'm trying to convert srt to int,
Do you mean "str to int"?
> and I didn't know I needed to specify the base.
You don't. If you don't specify the base, it defaults to 10.
> Plus I haven't read anything that I need to specify
> the base for the int(). Attached is the code, showing the code and
> the execution of said code.
Any attachment was removed.
> "When you pass through the waters, I will
> be with you: and when you pass through the rivers, they will not sweep
> over you. When you walk through the fire, you will not be burned: the
> flames will not set you ablaze." Isaiah 43:2
You can add a signature to all your messages if you like, but it will be
very helpful if you introduce it with a line consisting of "-- ", as
I've done here.
It would also be very helpful if you introduce line breaks into your
message, particularly before and after any included code. The
formatting made your message difficult to read.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What to use instead of nntplib?
Grant Edwards writes:
> On 2023-05-21, Retrograde wrote:
>> Who ever came up with "Removing dead batteries" as a slogan, when
>> some of those batteries still work perfectly well, needs to rethink
>> it. Go ahead and remove code that no longer works, OK. But removing
>> unpopular modules? That undercuts the entire philosophy of the
>> platform, in my opinion.
>
> And one of the metrics of "popularity" seems to be "activity"
> (e.g. changes committed). For things that have been around for 20+
> years and have all the features they need and all of the bugs fixed
> (and are now very stable) that lack of "activity" is interpreted as
> "unpopular" regardless of how many people are using the module.
My understanding is that nntplib isn't being erased from reality,
it's merely being removed from the set of modules that are provided
by default.
I presume that once it's removed from the core, it will still be
possible to install it via pip or some other mechanism.
You can disable the deprecation warning:
import warnings
warnings.filterwarnings("ignore", category=DeprecationWarning)
import nntplib
If my understanding is correct, why is this such a big problem?
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What do these '=?utf-8?' sequences mean in python?
Chris Green writes:
> Chris Green wrote:
>> I'm having a real hard time trying to do anything to a string (?)
>> returned by mailbox.MaildirMessage.get().
>>
> What a twit I am :-)
>
> Strings are immutable, I have to do:-
>
> newstring = oldstring.replace("_", " ")
>
> Job done!
Not necessarily.
The subject in the original article was:
=?utf-8?Q?aka_Marne_=C3=A0_la_Sa=C3=B4ne_(Waterways_Continental_Europe)?=
That's some kind of MIME encoding. Just replacing underscores by spaces
won't necessarily give you anything meaningful. (What if there are
actual underscores in the original subject line?)
You should probably apply some kind of MIME-specific decoding. (I don't
have a specific suggestion for how to do that.)
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hide my query about covariance matrix syntax from google
Chris Angelico writes:
> On Fri, 14 Apr 2023 at 03:11, Meghna Karkera wrote:
>>
>> Respected Sir
>>
>> I kindly request you to hide my query about covariance matrix syntax from
>> google which was emailed to you a few years back as it appears on google
>> page.
>>
>> Hoping that you do the needful.
>
> These posts are public. While it's possible to ask for something to be
> removed from the official python-list archive, that won't remove it
> from Google Groups or any other third-party archive.
>
> Also, there's nothing we can do here to remove your post; you'll have
> to contact the list admins.
>
> And just in case it's of interest to you:
> https://en.wikipedia.org/wiki/Streisand_effect
It's also mirrored to Usenet (comp.lang.python). There's basically no
way to delete articles from Usenet. (The protocol includes a command to
cancel an article, but servers ignore it due to past abuse.)
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: =- and -= snag
"Morten W. Petersen" writes:
> I was working in Python today, and sat there scratching my head as the
> numbers for calculations didn't add up. It went into negative numbers,
> when that shouldn't have been possible.
>
> Turns out I had a very small typo, I had =- instead of -=.
>
> Isn't it unpythonic to be able to make a mistake like that?
Very early versions of C (around 1975 or so, before K&R1 was
published) actually used "op=" for compound assignment operators, so
`x =- 2` would subtract 2 from x. It was changed to "=op" (`x -= 2`)
precisely to avoid this ambiguity that programmers kept running
into (people were less generous with whitespace back then).
As late as the late 1990s, I used a compiler (VAXC) that still
recognized the old-style compound assignment operators, though I
think it warned about them.
I thought "Pythonic" was more about how you write code than about the
design of the language. But designing a language syntax so typos are
likely to be syntax errors rather than valid code with different
semantics is an interesting challenge.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz
Greg Ewing writes:
> On 2/03/23 10:59 am, gene heskett wrote:
>> Human skin always has the same color
>
> Um... no?
You took that out of context. The assertion was that "Human skin
always has the same color" and "the difference is not the color,
but the brightness". I offer no opinion on whether that's accurate.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: hello can I be in your group?
September Skeen writes:
> I was wondering if I could be in your group
This is an unmoderated Usenet newsgroup. It doesn't have members, just
people who post to it. If you want to discuss Python, just post. (Take
a look around first to get an idea how how thinks work.)
If you see a response from "Manosh Manosh", I recommend ignoring it.
He appears to be a spammer.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What should go to stdout/stderr and why Python logging write everything to stderr?
MRAB writes:
[...]
> The purpose of stderr is to display status messages, logging and error
> messages, even user prompts, and not mess up the program's actual
> output. This is important on a *nix system where you might be piping
> the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some
system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is Microsoft Windows secretly downloading childporn to your computer ?!
Juha Nieminen writes: > In comp.lang.c++ Steve Hayes wrote: >> You download things FROM a computer, you upload them TO a computer. > > It's a matter of perspective. If a hacker breaks into your computer and > starts a download from somewhere else into your computer, isn't the hacker > "downloading" things to your computer? My understanding of the word "downloading" has always been STOP FEEDING THE TROLL! -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Microsoft Windows secretly downloading childporn to your computer ?!
Steve Hayes writes: > On Tue, 1 Dec 2015 03:19:39 +0100, "Skybuck Flying" > wrote: >>The question is: >> >>Is Microsoft [snip] > > You download things FROM a computer, you upload them TO a computer. > > Since you don't even know that much about computers, anything else you > say is obviously not worth readin. Nor is it worth replying to. *Please* don't feed the troll. (Followups set.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- https://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes: > In article <8hl2ucfdv...@mid.individual.net>, > Gregory Ewing wrote: >> Tim Bradshaw wrote: >> > In general any function >> > which raises its argument to more than one power ... doesn't make >> > much sense if its argument has units. >> >> That's not true. Consider the distance travelled by a >> falling object: y(t) = y0 + v0*t + 0.5*a*t**2. Here t has >> dimensions of time, and it's being raised to different >> powers in different terms. It works because the >> coefficents have dimensions too, and all the terms end up >> having the same dimensions. > > This reminds me of back when I was a kid and my dad was trying to teach > me basic physics. He kept saying that the acceleration of gravity was > 9.8 meters per second squared and I just couldn't wrap my brain around > what it meant to square a second. > > Now that I think about it, I still can't. :-) Fuel economy can be measured in reciprocal acres (or reciprocal hectares if you prefer). miles/gallon or km/liter is distance / distance**3 --> distance**-2. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
"BartC" writes: > "RG" wrote in message > news:rnospamon-20651e.17410012102...@news.albasani.net... [...] >> Likewise, all of the following are the same number written in different >> notations: >> >> pi/2 >> pi/2 radians >> 90 degrees >> 100 gradians >> 1/4 circle >> 0.25 circle >> 25% of a circle >> 25% of 2pi >> >> See? > > But what exactly *is* this number? Is it 0.25, 1.57 or 90? It's approximately 1.57. > I can also write 12 inches, 1 foot, 1/3 yards, 1/5280 miles, 304.8 mm and so > on. They are all the same number, roughly 1/13100 of the polar > circumference of the Earth. They aren't bare numbers, they're lengths (actually the same length). > This does depend on the actual size of an arbitrary circle, but that seems > little different from the choice of 0.25, 1.57 or 90 for your quarter > circle. The radian is defined as a ratio of lengths. That ratio is the same regardless of the size of the circle. The choice of 1/(2*pi) of the circumference isn't arbitrary at all; there are sound mathematical reasons for it. Mathematicians could have chosen to set the full circumference to 1, for example, but then a lot of computations would contain additional multiplications and/or divisions by 2*pi. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
p...@informatimago.com (Pascal J. Bourguignon) writes: > Seebs writes: >> On 2010-10-01, Pascal J. Bourguignon wrote: >>> Seebs writes: >>>> On 2010-10-01, Pascal J. Bourguignon wrote: >>>>> compiler passes wrong type wrong resultfails at run-time >>>>> (the programmer (with exception >>>>> spends hoursexplaining this is >>>>> finding the the wrong type) >>>>> problem) >>> >>>> I have no clue what exact scenario you're talking about here. I've never >>>> seen a bug that could plausibly be described as "compiler passes wrong >>>> type" which wasn't picked up quickly by running with more warnings enabled. >> >>> This is the scenario discussed in this thread, a long is passed to >>> maximum without a compiler warning. >> >> The compiler didn't pass the wrong type, the user did. > > And the compiler passed it on without saying anything. Because the user didn't use the option (-Wconversion) that would have caused the compiler to warn about it. [...] -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
> In article ,
> Seebs wrote:
>
>> On 2010-09-30, RG wrote:
>> > That gives (what I would consider to be) false positives, e.g.:
>>
>> > [...@mighty:~]$ cat foo.c
>>
>> > void foo(long x) {}
>>
>> > int main() { foo(1); }
>> > [...@mighty:~]$ gcc -Wconversion foo.c
>> > foo.c: In function ???main???:
>> > foo.c:4: warning: passing argument 1 of ???foo??? with different width due
>> > to prototype
>>
>> But it's *not* a false positive. The compiler is not claiming that the
>> conversion couldn't be done -- it's just telling you that there is a
>> change of type going on.
>
> Again, you can't have it both ways. Either a warning is a "compiler
> error" according to the claim at issue (see below) or it is not. If it
> is, then this is a false positive. If it is not, then my previous
> example refutes the claim.
[...]
In this case, the conversion (from int to long) cannot fail (barring
undefined behavior elsewhere in the program), because long is
guaranteed to be able to hold any value within the range of int.
It would be reasonable, at least as an option, to warn only about
conversions that can fail, or only about conversions that can lose
information, perhaps distinguishing between implicit conversions
and explicit conversions (casts).
Even the warning about foo(1) is not entirely unreasonable; some
programmers might prefer to write foo(1L) rather than foo(1),
to make it clear that the argument being passed is of type long
rather than int.
I don't know whether gcc provides this level of control over which
conversions it warns about, but again, that's a gcc issue, not a
C issue.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
TheFlyingDutchman writes: > On Sep 30, 10:37 pm, RG wrote: >> In article <87tyl63cag@mail.geddis.org>, >> Don Geddis wrote: >> > Keith Thompson wrote on Thu, 30 Sep 2010: >> > > RG writes: >> > >> You're missing a lot of context. I'm not trying to criticize C, just to >> > >> refute a false claim that was made about it. >> > > Can you cite the article that made this false claim, and exactly what >> > > the false claim was? >> >> >http://groups.google.com/group/comp.lang.lisp/msg/431925448da59481 >> >> > Message-ID: >> > <0497e39d-6bd1-429d-a86f-f4c89babe...@u31g2000pru.googlegroups.com> >> > From: TheFlyingDutchman >> > Newsgroups: comp.lang.lisp >> >> > [...] >> > in C I can have a function maximum(int a, int b) that will always >> > work. Never blow up, and never give an invalid answer. If someone >> > tries to call it incorrectly it is a compile error. >> > [...] That was slightly overstated. In fact, you can have such a function that will always work when called correctly, *unless* something else has caused the program's behavior to be undefined, in which case all bets are off. [...] > Thanks from me as well, Don. I was worried that people would start to > believe that the original statement was what you said it was: > > "I'm not even saying it's a flaw in the language. All I'm saying is > that > the original claim -- that any error in a C program will be caught by > the compiler -- is false, and more specifically, that it can be > demonstrated to be false without appeal to unknown run-time input." Yes, that would have been an absurd claim if anyone had actually made it. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Seebs writes: > On 2010-10-01, TheFlyingDutchman wrote: >>> > ? ? ? ? in C I can have a function maximum(int a, int b) that will always >>> > ? ? ? ? work. Never blow up, and never give an invalid answer. If someone >>> > ? ? ? ? tries to call it incorrectly it is a compile error. > >>> I would agree that the third sentence is arguably wrong, simply >>> because there's no such thing (outside #error) of a mandate to stop >>> compiling. ?However, my understanding was that the dispute was over >>> the second sentence, and that's certainly correct. > >> Why do you consider the term "compile error" a "mandate to stop >> compiling"? > > Because that's what people normally mean -- compilation failed. At least for C, I'd say it refers to a syntax error or constraint violation, i.e., something that requires a diagnostic. [...] -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes: [...] > You're missing a lot of context. I'm not trying to criticize C, just to > refute a false claim that was made about it. Can you cite the article that made this false claim, and exactly what the false claim was? -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Seebs writes:
> On 2010-09-30, Keith Thompson wrote:
>> Seebs writes:
>>> On 2010-09-30, Paul Rubin wrote:
>>>> int maximum(int a, int b);
>
>>>> int foo() {
>>>> int (*barf)() = maximum;
>>>> return barf(3);
>>>> }
>
>> That first line declare barf as an object of type "pointer to
>> function returning int", or more precisely, "pointer to function with
>> an unspecified but fixed number and type of parameters returning int"
>> (i.e., an old-style non-prototype declaration, still legal but
>> deprecated in both C90 and C99). It then initializes it to point
>> to the "maximum" function. I *think* the types are sufficiently
>> "compatible" (not necessarily using that word the same way the
>> standard does) for the initialization to be valid and well defined.
>> I might check the standard later.
>
> Hmm. You have a point. It's clearly a conversion from one type
> to another.
If I'm reading 6.7.5.3p15 correctly, the types
int (*)()
and
int (*)(int, int)
are compatible, so the declaration and initialization of barf is
perfectly legal, and a call
bar(3, 4)
would also be legal and would return 4.
I actually didn't notice on my initial reading that the call is passing
the wrong number of arguments. Since the type of barf doesn't specify
the number or types of the arguments, no diagnostic is required, but
the behavior is undefined.
>> IMHO it's better to use prototypes consistently than to figure out the
>> rules for interactions between prototyped vs. non-prototyped function
>> declarations.
>
> Yes. It's clearly undefined behavior to call a function through a
> pointer to a different type, or to call a function with the wrong number
> of arguments. I am pretty sure at least one compiler catches this.
The former is not a problem here; the type of barf is compatible with
the type of a pointer to maximum. The latter is the problem, and a
sufficiently clever compiler can warn about it.
Note that you could do something silly like this:
int one_param(int a);
int two_params(int a, int b);
int (*barf)();
if (some_condition) {
barf = one_param;
}
else {
barf = two_params;
}
if (some_other_condition) {
barf(1);
}
else {
barf(2, 3);
}
No constraint violations, and no undefined behavior as long as
some_condition and some_other_condition have the same value.
The best a compiler can do (unless it knows about the conditions)
is warn you that something *might* go wrong.
For programmers, the solution is simple: *Don't do that!*.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes: > In article , > Seebs wrote: > >> On 2010-09-30, Lie Ryan wrote: >> > On 09/30/10 16:09, TheFlyingDutchman wrote: >> >> Dynamic typed languages like Python fail in this case on "Never blows >> >> up". >> >> > How do you define "Never blows up"? >> >> I would say "blow up" would be "raise an exception". >> >> > Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow >> > up, and of the worst kind since it passes silently. >> >> So run your compiler with a decent set of warning levels, and watch as >> you are magically warned that you're passing an object of the wrong type. > > My code compiles with no warnings under gcc -Wall. Conclusion: "-Wall" is not "a decent set of warning levels" in this context, in spite of the name. (If you want to complain that the name "-Wall" is misleading, I won't disagree, but it's a gcc issue, not a C issue.) With "-Wconversion", I get: c.c: In function 'main': c.c:7: warning: passing argument 1 of 'maximum' with different width due to prototype [...] >> On any given system, one or the other is true: >> >> 1. The constant 8589934592 is of type int, and the function will >> "work" -- will give that result. >> 2. The constant is not of type int, and the compiler will warn you about >> this if you ask. > > It would be nice if this were true, but my example clearly demonstrates > that it is not. And if your response is to say that I should have used > lint, then my response to that will be that because of the halting > problem, for any static analyzer that you present, I can construct a > program that either contains an error that either your analyzer will not > catch, or for which it will generate a false positive. It just so > happens that constructing such examples for standard C is very easy. And yet you have not managed to do it. It seems to me that the line between errors that a sufficiently clever compiler could or should warn you about, and errors that compilers cannot reasonably be expected to detect, is a very fuzzy one. A fairly clear example of the latter is: const double pi = 2.71828182845904523526; To a human reader, it's obviously either a mistake or deliberate obfuscation, but I'm not sure I'd *want* my compiler to warn me about it just because I named the object "pi" rather than "e". (And if I called it "x", even an intelligent human wouldn't know that it's wrong.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
> In article ,
> Keith Thompson wrote:
>> RG writes:
>> [...]
>> > You can't have it both ways. Either I am calling it incorrectly, in
>> > which case I should get a compiler error, or I am calling it correctly,
>> > and I should get the right answer. That I got neither does in fact
>> > falsify the claim. The only way out of this is to say that
>> > maximum(8589934592, 1) returning 1 is in fact "correct", in which case
>> > we'll just have to agree to disagree.
>>
>> You are calling maximum() incorrectly, but you are doing so in a way
>> that the compiler is not required to diagnose.
>
> Yes. I know. That was my whole point. There are ways to call a
> function incorrectly (more broadly, there are errors in code) that a C
> compiler is not required to diagnose.
Of course.
>> If you want to say that the fact that the compiler is not required
>> to diagnose the error is a flaw in the C language, I won't
>> argue with you.
>
> I'm not even saying it's a flaw in the language. All I'm saying is that
> the original claim -- that any error in a C program will be caught by
> the compiler -- is false, and more specifically, that it can be
> demonstrated to be false without appeal to unknown run-time input.
Did someone *really* claim that "any error in a C program will
be caught by the compiler"? If so, I must have missed that.
It's certainly not true; code that compiles cleanly can be riddled
with errors. That's true in any language, but more so in C than
in some others.
> As an aside, this particular error *could* be caught (and in fact would
> be caught by other tools like lint), but there are errors that can not
> be caught by any static analysis, and that therefore one should not be
> lulled into a false sense of security by the fact that your code is
> written in a statically typed language and compiled without errors or
> warnings. That's all.
I don't believe anyone has said otherwise.
>> If I write:
>>
>> const double pi = 22.0/7.0;
>> printf("pi = %f\n", pi);
>>
>> then I suppose I'm calling printf() incorrectly, but I wouldn't
>> expect my compiler to warn me about it.
>>
>> If you're arguing that
>>
>> int maximum(int a, int b) { return a > b ? a : b; }
>>
>> is flawed because it's too easy to call it incorrectly, you're
>> effectively arguing that it's not possible to write correct
>> code in C at all.
>
> I would say that it is very, very hard to write correct code in C for
> any non-vacuous definition of "correct". That is the reason that core
> dumps and buffer overflows are so ubiquitous. I prefer Lisp or Python,
> where core dumps and buffer overflows are virtually nonexistent. One
> does get the occasional run-time error that might have been caught at
> compile time, but I much prefer that to a core dump or a security hole.
I would say that it can certainly be difficult to write correct
code in C, but I don't believe it's nearly as hard as you think
it is. It requires more discipline than some other languages,
and it can require some detailed knowledge of the language itself,
particularly what it defines and what it doesn't. And it's not
always worth the effort if another language can do the job as well
or better.
> One might hypothesize that the best of both worlds would be a dynamic
> language with a static analyzer layered on top. Such a thing does not
> exist. It makes an instructive exercise to try to figure out why. (For
> the record, I don't know the answer, but I've learned a lot through the
> process of pondering this conundrum.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Seebs writes:
> On 2010-09-30, Paul Rubin wrote:
>> int maximum(int a, int b);
>>
>> int foo() {
>> int (*barf)() = maximum;
>> return barf(3);
>> }
>
>> This compiles fine for me. Where is the cast?
>
> On the first line of code inside foo().
Look again; there's no cast in foo().
That first line declare barf as an object of type "pointer to
function returning int", or more precisely, "pointer to function with
an unspecified but fixed number and type of parameters returning int"
(i.e., an old-style non-prototype declaration, still legal but
deprecated in both C90 and C99). It then initializes it to point
to the "maximum" function. I *think* the types are sufficiently
"compatible" (not necessarily using that word the same way the
standard does) for the initialization to be valid and well defined.
I might check the standard later.
It would have been better to use a prototype (for those of you
in groups other than comp.lang.c, that's a function declaration that
specifies the types of any parameters):
int (*barf)(int, int) = maximum;
IMHO it's better to use prototypes consistently than to figure out the
rules for interactions between prototyped vs. non-prototyped function
declarations.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
[...]
> You can't have it both ways. Either I am calling it incorrectly, in
> which case I should get a compiler error, or I am calling it correctly,
> and I should get the right answer. That I got neither does in fact
> falsify the claim. The only way out of this is to say that
> maximum(8589934592, 1) returning 1 is in fact "correct", in which case
> we'll just have to agree to disagree.
You are calling maximum() incorrectly, but you are doing so in a way
that the compiler is not required to diagnose.
If you want to say that the fact that the compiler is not required
to diagnose the error is a flaw in the C language, I won't
argue with you. It's just not a flaw in the maximum() function.
If I write:
const double pi = 22.0/7.0;
printf("pi = %f\n", pi);
then I suppose I'm calling printf() incorrectly, but I wouldn't
expect my compiler to warn me about it.
If you're arguing that
int maximum(int a, int b) { return a > b ? a : b; }
is flawed because it's too easy to call it incorrectly, you're
effectively arguing that it's not possible to write correct
code in C at all.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
> In article ,
> Keith Thompson wrote:
[...]
>> Even here, maximum() did exactly what was asked of it.
>
> Of course. Computers always do only exactly what you ask of them. On
> this view there is, by definition, no such thing as a bug, only
> specifications that don't correspond to one's intentions.
> Unfortunately, correspondence to intentions is the thing that actually
> matters when writing code.
Of course there's such a thing as a bug.
This version of maximum:
int maximum(int a, int b) {
return a > b ? a : a;
}
has a bug. This version:
int maximum(int a, int b) {
return a > b ? a : b;
}
I would argue, does not. The fact that it might be included in a
buggy program does not mean that it is itself buggy.
[...]
> I'm not saying one should not use compile-time tools, only that one
> should not rely on them. "Compiling without errors" is not -- and
> cannot ever be -- be a synonym for "bug-free."
Agreed. (Though C does make it notoriously easy to sneak buggy code
past the compiler.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
[...]
> That the problem is "elsewhere in the program" ought to be small
> comfort.
I don't claim that it's comforting, merely that it's true.
> But very well, try this instead:
>
> [...@mighty:~]$ cat foo.c
> #include
>
> int maximum(int a, int b) { return a > b ? a : b; }
>
> int main() {
> long x = 8589934592;
> printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> return 0;
> }
> [...@mighty:~]$ gcc -Wall foo.c
> [...@mighty:~]$ ./a.out
> Max of 8589934592 and 1 is 1
That exhibits a very similar problem.
8589934592 is 2**33.
Given the output you got, I presume your system has 32-bit int and
64-bit long. The call maximum(x, 1) implicitly converts the long
value 8589934592 to int. The result is implementation-defined,
but typically 0. So maximum() is called with arguments of 0 and 1,
as you could see by adding a printf call to maximum().
Even here, maximum() did exactly what was asked of it.
I'll grant you that having a conversion from a larger type to a smaller
type quietly discard high-order bits is unfriendly. But it matches the
behavior of most CPUs.
Here's another example:
#include
int maximum(int a, int b) { return a > b ? a : b; }
int main(void) {
double x = 1.8;
printf("Max of %f and 1 is %d\n", x, maximum(x, 1));
return 0;
}
Output:
Max of 1.80 and 1 is 1
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
> In article ,
> Keith Thompson wrote:
>
>> RG writes:
>> > In article
>> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
>> > Squeamizh wrote:
>> >> On Sep 29, 3:02 pm, RG wrote:
>> [...]
>> >> > This is a red herring. You don't have to invoke run-time input to
>> >> > demonstrate bugs in a statically typed language that are not caught by
>> >> > the compiler. For example:
>> >> >
>> >> > [...@mighty:~]$ cat foo.c
>> >> > #include
>> >> >
>> >> > int maximum(int a, int b) {
>> >> > return (a > b ? a : b);
>> >> >
>> >> > }
>> >> >
>> >> > int foo(int x) { return 9223372036854775807+x; }
>> >> >
>> >> > int main () {
>> >> > printf("%d\n", maximum(foo(1), 1));
>> >> > return 0;}
>> >> >
>> >> > [...@mighty:~]$ gcc -Wall foo.c
>> >> > [...@mighty:~]$ ./a.out
>> >> > 1
>> >> >
>> >> > Even simple arithmetic is Turing-complete, so catching all type-related
>> >> > errors at compile time would entail solving the halting problem.
>> >> >
>> >> > rg
>> >>
>> >> In short, static typing doesn't solve all conceivable problems.
>> >
>> > More specifically, the claim made above:
>> >
>> >> in C I can have a function maximum(int a, int b) that will always
>> >> work. Never blow up, and never give an invalid answer.
>> >
>> > is false. And it is not necessary to invoke the vagaries of run-time
>> > input to demonstrate that it is false.
>>
>> But the above maximum() function does exactly that. The program's
>> behavior happens to be undefined or implementation-defined for reasons
>> unrelated to the maximum() function.
>>
>> Depending on the range of type int on the given system, either the
>> behavior of the addition in foo() is undefined (because it overflows),
>> or the implicit conversion of the result to int either yields an
>> implementation-defined result or (in C99) raises an
>> implementation-defined signal; the latter can lead to undefined
>> behavior.
>>
>> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
>> the addition yields the value 0, but the C language doesn't require that
>> particular result. You then call maximum with arguments 0 and 1, and
>> it quite correctly returns 1.
>
> This all hinges on what you consider to be "a function maximum(int a,
> int b) that ... always work[s] ... [and] never give[s] an invalid
> answer."
int maximum(int a, int b) { return a > b ? a : b; }
> But if you don't consider an incorrect answer (according to
> the rules of arithmetic) to be an invalid answer then the claim becomes
> vacuous. You could simply ignore the arguments and return 0, and that
> would meet the criteria.
I don't believe it's possible in any language to write a maximum()
function that returns a correct result *when given incorrect argument
values*.
The program (assuming a typical implementation) calls maximum() with
arguments 0 and 1. maximum() returns 1. It works. The problem
is elsewhere in the program.
(And on a hypothetical system with INT_MAX >= 9223372036854775808,
the program's entire behavior is well defined and mathematically
correct. C requires INT_MAX >= 32767; it can be as large as the
implementation chooses. In practice, the largest value I've ever
seen for INT_MAX is 9223372036854775807.)
> If you try to refine this claim so that it is both correct and
> non-vacuous you will find that static typing does not do nearly as much
> for you as most of its adherents think it does.
Speaking only for myself, I've never claimed that static typing solves
all conceivable problems. My point is only about this specific example
of a maximum() function.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes:
> In article
> <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> Squeamizh wrote:
>> On Sep 29, 3:02 pm, RG wrote:
[...]
>> > This is a red herring. You don't have to invoke run-time input to
>> > demonstrate bugs in a statically typed language that are not caught by
>> > the compiler. For example:
>> >
>> > [...@mighty:~]$ cat foo.c
>> > #include
>> >
>> > int maximum(int a, int b) {
>> > return (a > b ? a : b);
>> >
>> > }
>> >
>> > int foo(int x) { return 9223372036854775807+x; }
>> >
>> > int main () {
>> > printf("%d\n", maximum(foo(1), 1));
>> > return 0;}
>> >
>> > [...@mighty:~]$ gcc -Wall foo.c
>> > [...@mighty:~]$ ./a.out
>> > 1
>> >
>> > Even simple arithmetic is Turing-complete, so catching all type-related
>> > errors at compile time would entail solving the halting problem.
>> >
>> > rg
>>
>> In short, static typing doesn't solve all conceivable problems.
>
> More specifically, the claim made above:
>
>> in C I can have a function maximum(int a, int b) that will always
>> work. Never blow up, and never give an invalid answer.
>
> is false. And it is not necessary to invoke the vagaries of run-time
> input to demonstrate that it is false.
But the above maximum() function does exactly that. The program's
behavior happens to be undefined or implementation-defined for reasons
unrelated to the maximum() function.
Depending on the range of type int on the given system, either the
behavior of the addition in foo() is undefined (because it overflows),
or the implicit conversion of the result to int either yields an
implementation-defined result or (in C99) raises an
implementation-defined signal; the latter can lead to undefined
behavior.
Since 9223372036854775807 is 2**63-1, what *typically* happens is that
the addition yields the value 0, but the C language doesn't require that
particular result. You then call maximum with arguments 0 and 1, and
it quite correctly returns 1.
>> We are all aware that there is no perfect software development process
>> or tool set. I'm interested in minimizing the number of problems I
>> run into during development, and the number of bugs that are in the
>> finished product. My opinion is that static typed languages are
>> better at this for large projects, for the reasons I stated in my
>> previous post.
>
> More power to you. What are you doing here on cll then?
This thread is cross-posted to several newsgroups, including
comp.lang.c.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Erik Max Francis writes: > Keith Thompson wrote: >> Erik Max Francis writes: >> [...] >>> >>> print c # floating point accuracy aside >>> 299792458.0 m/s >> >> Actually, the speed of light is exactly 299792458.0 m/s by >> definition. (The meter and the second are defined in terms of the >> same wavelength of light; this was changed relatively recently.) > > I know. Hence why I wrote the comment "floating point accuracy aside" > when printing it. Ok. I took the comment to be an indication that the figure was subject to floating point accuracy concerns; in fact you meant just the opposite. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Erik Max Francis writes: [...] > >>> print c # floating point accuracy aside > 299792458.0 m/s Actually, the speed of light is exactly 299792458.0 m/s by definition. (The meter and the second are defined in terms of the same wavelength of light; this was changed relatively recently.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
George Neuner writes: > On 28 Sep 2010 12:42:40 GMT, Albert van der Horst > wrote: >>I would say the dimensional checking is underrated. It must be >>complemented with a hard and fast rule about only using standard >>(SI) units internally. >> >>Oil output internal : m^3/sec >>Oil output printed: kbarrels/day > > "barrel" is not an SI unit. He didn't say it was. Internal calculations are done in SI units (in this case, m^3/sec); on output, the internal units can be converted to whatever is convenient. > And when speaking about oil there isn't > even a simple conversion. > > 42 US gallons ? 34.9723 imp gal ? 158.9873 L > > [In case those marks don't render, they are meant to be the > double-tilda sign meaning "approximately equal".] There are multiple different kinds of "barrels", but "barrels of oil" are (consistently, as far as I know) defined as 42 US liquid gallons. A US liquid gallon is, by definition, 231 cubic inches; an inch is, by definition, 0.0254 meter. So a barrel of oil is *exactly* 0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792 kbarrels/day. (Please feel free to check my math.) That's admittedly a lot of digits, but there's no need for approximations (unless they're imposed by the numeric representation you're using). -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
Standish P writes: > On Aug 18, 5:38 pm, Keith Thompson wrote: [...] >> Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory, >> or comp.lang.python. Please trim the Newsgroups line. > > provide a rigorous proof that people are more interested in the > nauseating nude pictures that you post of your mother in the > newsgroups than in the subject of forth implementation. [snip] *plonk* -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
Standish P writes: > On Aug 18, 12:30 pm, Elizabeth D Rather wrote: [...] >> Mostly it had a "snowball's chance" because it was never picked up by >> the CS gurus who, AFAIK, never really took a serious look at it. > > Its quite possible that the criticism is unfair, but dont you think > that in part some responsibility must be borne by your organization in > not doing a good job of education ? [snip] > Show me on what page does it explain how Forth implements dynamic > binding or lexical binding and takes care of the scope of definition > of the "nouns" ? [...] Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory, or comp.lang.python. Please trim the Newsgroups line. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: GNU Emacs Developement Inefficiency (commentary)
Emmy Noether writes: [98 lines deleted] The parent article was posted to comp.emacs and comp.lang.lisp. Why did you cross-post your followup to comp.lang.c, comp.lang.python, and comp.lang.scheme? -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: Implementation suggestions for creating a Hierarchical circuit database
nick writes: > I am writing a personal software that will read circuit design/ > netlist. I will be using the MCNC benchmarks that contain different > types of designs in SPICE netlist format. [snip] You cross-posted this question to comp.theory, comp.lang.c++, comp.lang.c, comp.lang.python, and sci.math. Since you don't mention anything about any implementation language, I don't see how your question is relevant to any of the comp.lang.* groups. If you have questions about a particular language, feel free to post to comp.lang.whatever. (I won't bother to redirect followups, since that affects only followups to *this* article, but please consider trimming the newsgroups line.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: SPAM
"Steven Lord" writes: [snip] > If you feel the need to respond to a spam like this, please snip out any > URLs or email addresses used by the spammers -- otherwise all you're doing > is giving the spammer more advertising. Better yet, if you feel the need to respond to a spam, step away from the keyboard until the feeling passes. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: structs
"Gary Herron" writes: > Python *is* object-oriented I disagree. Care to provide proof of that statement? -- http://mail.python.org/mailman/listinfo/python-list
Re: structs
"Scott David Daniels" writes: > To avoid using epsilon, do something like: > if 1 + abs(x) != 1: An OK effort, but you're wrong. That's not how to do it at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursive function won't compile
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: >> #include >> #include >> >> def RecursiveFact(n): >> if(n>1): >> return n*RecursiveFact(n-1) >> else: >> return 1 >> >> fact = RecursiveFact(31) >> print fact >> >> fact = "End of program" >> print fact >> >> >> ..but yet it still gives the right answer. How is this possible? > > Given that you obviously don't use python, but some weird cross-breed > beteween python and C - who are we to judge the semantics of that > chimera? What do you mean? Aren't these: #include perfectly valid comments in Python? Followups redirected. -- Keith Thompson (The_Other_Keith) <[EMAIL PROTECTED]> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: Important Research Project
"E.D.G." <[EMAIL PROTECTED]> writes: > "CBFalconer" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> "E.D.G." wrote: > >> Where is Perl described in the C standard? This seems rather OT. > > It has been my experience that a person who is an expert with one computer > language can usually do reasonably well when working with other languages. > I am trying to find some people who can assist with getting a Perl program > running. It would probably be easier for expert programmers in any language > to help with this type of work compared with people such as myself who are > not experts in any programming language. CBFalconer's point is that this newsgroup (comp.lang.c, where he and I are both reading this) is for discussion of the C programming language. If you want to discuss something other than C, please find another forum. Massive cross-posts like this are rarely appropriate. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- http://mail.python.org/mailman/listinfo/python-list
Re: The Nature of the “Unix Philosophy”
"Xah Lee" <[EMAIL PROTECTED]> writes: > The Nature of the “Unix Philosophy” > > Xah Lee, 2006-05 ___ /| /| | | ||__|| | Please do | / O O\__ NOT | / \ feed the| / \ \ trolls | / _\ \ __| /|\\ \ || / | | | |\/ || / \|_|_|/ \__|| / / \|| || / | | /|| --| | | |// | --| * _| |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // |/ * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c (If you *must* post followups, please drop comp.lang.c from the Newsgroups: header -- which doesn't imply that this is topical in any of the other newsgroups to which it's posted.) Xah: please consider creating your own newsgroup under alt.*. You can post your long essays there and (if you absolutely insist on doing so) post pointers to them elsewhere. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: symbolic links, aliases, cls clear
[EMAIL PROTECTED] (Floyd L. Davidson) writes: > [EMAIL PROTECTED] wrote: >>If I may recommend an alternative, >> >>print "\033[H\033[J" >> >>the ansi sequence to clear the screen. > > Or so you would hope (however, that is *not* what you have listed!). > > Unfortunately, it is poor practice to hard code such sequences. > Instead the proper sequence should be obtained from the > appropriate database (TERMINFO or TERMCAP), and the easy way to > do that is, > >tput clear (Or "clear".) On the other hand, I think it's been at least a decade since I've used a terminal or emulator that's not VT100-compatible (i.e., accepts ANSI control sequences). Of course, I'll run into one the day after I start writing code that depends on that assumption. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: symbolic links, aliases, cls clear
"mp" <[EMAIL PROTECTED]> writes: > i have a python program which attempts to call 'cls' but fails: > > sh: line 1: cls: command not found > > i tried creating an alias from cls to clear in .profile, .cshrc, and > /etc/profile, but none of these options seem to work. > > my conclusion is that a python program that is executing does not use > the shell (because it does not recognize shell aliases). is this > correct? Yes. > should i use a symbolic link? if so, where should i place it? You could, but I don't think it's the best solution. > what is the difference between aliases and symbolic links? Aliases exist only in a shell. Symbolic links exist in the file system. > if i execute a command like 'clear' to clear the screen, where does the > shell look to find the command 'clear'? Generally it searches $PATH for an executable file called "clear". I don't know Python very well (note the cross-post), but if it provides a way to detect which operating system you're running on, you could execute "cls" if you're on Windows, or "clear" if you're on a Unix-like system. Or there might be some Python library with a clear-screen function. Are you sure you want to clear the screen? If I run your program and it clears my screen for me, it could be erasing significant information. If you want complete control over the screen, you should probably use something like curses or ncurses (there may be a Python interface to it). -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: IT Industry Predicament
"Xah Lee" <[EMAIL PROTECTED]> writes: [the usual] ___ /| /| | | ||__|| | Please do | / O O\__ NOT | / \ feed the| / \ \ trolls | / _\ \ __| /|\\ \ || / | | | |\/ || / \|_|_|/ \__|| / / \|| || / | | /|| --| | | |// | --| * _| |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // |/ * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____ -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: Examples of Quality Technical Writing
"javuchi" <[EMAIL PROTECTED]> writes: > Why do you have such a need of being hating everything and everybody > and expressing it so offen? > Can you live without hate? > Can you let others live without your hates? Xah Lee is a well-known troll. Replying to him is a waste of time. Please just ignore him. (A killfile is an effective way to do so.) -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python doc problem example: gzip module (reprise)
Rick Wotnaz <[EMAIL PROTECTED]> writes: [snip] > I've managed to avoid reading Xah Lee's diatribes for the most > part. Since you included the *WHOLE THING* in your post, I had an > "opportunity" to see what he had to say, and for once I agree with > some of it. That's fine, but if you're going to post a followup, could you please limit it to comp.lang.python? There's no hope of getting Xah Lee to stop posting his rants to irrelevant newsgroups (that's what killfiles are for), but I doubt that many readers of comp.lang.perl.misc really want to read about Python documentation -- if they do, they can always read comp.lang.python. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: a Haskell a Day
"Xah Lee" <[EMAIL PROTECTED]> writes: [snip] ___ /| /| | | ||__|| | Please do | / O O\__ NOT | / \ feed the| / \ \ trolls | / _\ \ __| /|\\ \ || / | | | |\/ || / \|_|_|/ \__|| / / \|| || / | | /|| --| | | |// | --| * _| |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // |/ * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____ -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft Hatred FAQ
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Hm... What does this have to do with Perl? > > Why did you post this in comp.lang.perl.misc? He posted this in comp.lang.python, comp.lang.perl.misc, comp.unix.programmer, comp.lang.java.programmer, *and* comp.os.linux.misc because he's a troll. I wish I could say that he'll go away if we ignore him. I can say, however, that ignoring him will minimize his impact. In the past, his rants have led to long rambling arguments across multiple newsgroups, none of them relevant to any point that might be made -- which is probably exactly what he wants. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
Roedy Green <[EMAIL PROTECTED]> writes: [...] > Especially with spam, there are no perfect solutions, but at least we > could do many times better than what we are living with and put the > spammers out of business. A partial solution to spam, or at least to pollution of Usenet newsgroups, would be to STOP POSTING THIS STUFF TO NEWSGROUPS WHERE IT'S NOT RELEVANT. There are several newsgroups that deal with e-mail abuse. This discussion isn't being posted to any of them. Please stop. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Perl's documentation come of age
"Xah Lee" <[EMAIL PROTECTED]> writes: [ the usual ] +---+ .:\:\:/:/:. | PLEASE DO NOT |:.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +---+ / \ | |@@@ / /|,|\ \ | |@@@ /_// /^\ \\_\ @x@@x@| | |/ WW( ( ) )WW \/| |\| __\,,\ /,,/__ \||/ | | | jgs (__Y__) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ====== -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
"jan V" <[EMAIL PROTECTED]> writes: >> +---+ .:\:\:/:/:. >> | PLEASE DO NOT |:.:\:\:/:/:.: >> | FEED THE TROLLS | :=.' - - '.=: >> | | '=(\ 9 9 /)=' >> | Thank you, | ( (_) ) >> | Management | /`-vvv-'\ >> +---+ / \ >> | |@@@ / /|,|\ \ >> | |@@@ /_// /^\ \\_\ >>@x@@x@| | |/ WW( ( ) )WW >>\/| |\| __\,,\ /,,/__ >> \||/ | | | jgs (__Y__) >> /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > Please don't use ASCII art... not everyone uses a fixed-width font for his > newsreader... > (your picture looks all mangled here) If "PLEASE DO NOT" and "FEED THE TROLLS" are legible, even if they aren't aligned as intended, the message has gotten through. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
"Xah Lee" <[EMAIL PROTECTED]> writes: [the usual] +---+ .:\:\:/:/:. | PLEASE DO NOT |:.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +---+ / \ | |@@@ / /|,|\ \ | |@@@ /_// /^\ \\_\ @x@@x@| | |/ WW( ( ) )WW \/| |\| __\,,\ /,,/__ \||/ | | | jgs (__Y__) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ====== -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry ... and Xah Lee (I mean Jerry) Springer
Alex <[EMAIL PROTECTED]> writes: > Xah Lee wrote: [SSSNNNIIIPPP!!!] > I've extracted the preceding castigating snippets from Mr. Lee's > Jargon "thesis". [SSSNNNIIIPPP!!!] *Please stop posting followups to this off-topic nonsense. Just ignore it. Responding to spam is spam; responding to a troll gives him exactly what he wants and annoys the heck out of the rest of us. +---+ .:\:\:/:/:. | PLEASE DO NOT |:.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +---+ / \ | |@@@ / /|,|\ \ | |@@@ /_// /^\ \\_\ @x@@x@| | |/ WW( ( ) )WW \/| |\| __\,,\ /,,/__ \||/ | | | jgs (__Y__) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ====== Followups redirected appropriately. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
Roedy Green <[EMAIL PROTECTED]> writes: > On 11 Aug 2005 18:23:42 -0700, "Xah Lee" <[EMAIL PROTECTED]> wrote or > quoted : [ the usual nonsense ] > > Jargon [...] [snip] Take a look at the Newsgroups: line. Then look for other articles Xah Lee has posted, and see if you can make sense of any of them. If you must post a followup, at least limit the newsgroups to those where it might be topical. +---+ .:\:\:/:/:. | PLEASE DO NOT |:.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +---+ / \ | |@@@ / /|,|\ \ | |@@@ /_// /^\ \\_\ @x@@x@| | |/ WW( ( ) )WW \/| |\| __\,,\ /,,/__ \||/ | | | jgs (__Y__) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ====== -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expresiveness in a Computer Language?
"Xah Lee" <[EMAIL PROTECTED]> writes: > What is Expresiveness in a Computer Language > > 20050207, Xah Lee. +---+ .:\:\:/:/:. | PLEASE DO NOT |:.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +---+ / \ | |@@@ / /|,|\ \ | |@@@ /_// /^\ \\_\ @x@@x@| | |/ WW( ( ) )WW \/| |\| __\,,\ /,,/__ \||/ | | | jgs (__Y__) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ====== -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Language documentation ( was Re: Computing Industry shams)
alex goldman <[EMAIL PROTECTED]> writes: > Lawrence Kirby wrote: [snip] >> My response talks about relevance, not ambiguity. > > Well, your response was irrelevant. This entire discussion is irrelevant to most, if not all, of the newsgroups to which it's being posted. comp.lang.c, where I'm reading this, is for discussion of the C programming language; I see nothing about C. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python docs [was: function with a state]
Please stop cross-posting this stuff! -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's OOP's jargons and complexities?
jacob navia <[EMAIL PROTECTED]> writes: > Good post. > > First article that demistifies this OO centered approach > in quite a long time. I have no idea whether it was "good" or not, but it was blatantly off-topic in at least comp.lang.c, and probably all the other newsgroups to which it was cross-posted. Jacob, please don't encourage this kind of newsgroup abuse. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's OOP's jargons and complexities?
"Xah Lee" <[EMAIL PROTECTED]> writes: [snip] If you must post a followup to this, please drop comp.lang.c from the newsgroups header. I can't speak for the other newsgroups, but it's definitely off-topic here in comp.lang.c. Thank you. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to write a tutorial
"Xah Lee" <[EMAIL PROTECTED]> writes: [snip] > Following is a tutorial on Python's classes. [snip] Please stop posting this to comp.lang.c. I'm sure the folks in most of the other newsgroup aren't interested either -- or if they are, they can find it in comp.lang.python. Followups redirected. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- http://mail.python.org/mailman/listinfo/python-list
