On Mon, 12 Nov 2012 17:37:50 -0500, Dave Angel wrote:
> On 11/12/2012 05:07 PM, Beekeeper2020 wrote:
[...]
>> Python eventually will die once troll troll troll troll troll...
> In case anybody is tempted to respond to this troll message,
Like you did? Without trimming?
:-P
--
Steven
--
h
On 11/12/2012 05:07 PM, Beekeeper2020 wrote:
> I totally agreed about the Python syntax. Why do I need to worry about the
> syntax which wasted hours to get it to work?
> Brain dead python designer! Maybe Guido need to learn it from the Master,
> "Go to Ruby, and see how elegant the language is d
ers
on hours solving your Python Stupid Syntax ( Your dumb Global variable is
another example).
Google is too dumb to understand these issues.
--
View this message in context:
http://python.6.n6.nabble.com/f-python-tp4708177p4995649.html
Sent from the Python - python-list mailing list a
On 4/15/2012 6:59 PM, Ian Kelly wrote:
On Sun, Apr 15, 2012 at 4:49 PM, Terry Reedy wrote:
On 4/15/2012 12:16 PM, Ian Kelly wrote:
On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
wrote:
In<87aa2iz3l1@kuiper.lan.informatimago.com>, on 04/11/2012
at 05:32 PM, "Pascal J. Bourguignon"
On Sun, Apr 15, 2012 at 4:49 PM, Terry Reedy wrote:
> On 4/15/2012 12:16 PM, Ian Kelly wrote:
>>
>> On Sat, Apr 14, 2012 at 8:57 PM, Shmuel  Metz
>> Â wrote:
>>>
>>> In<87aa2iz3l1@kuiper.lan.informatimago.com>, on 04/11/2012
>>> Â at 05:32 PM, "Pascal J. Bourguignon" Â said:
>>>
You're
On 4/15/2012 12:16 PM, Ian Kelly wrote:
On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
wrote:
In<87aa2iz3l1@kuiper.lan.informatimago.com>, on 04/11/2012
at 05:32 PM, "Pascal J. Bourguignon" said:
You're confused. C doesn't have arrays. Lisp has arrays. C only has
vectors
Neither C
On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
wrote:
> In <87aa2iz3l1@kuiper.lan.informatimago.com>, on 04/11/2012
> Â at 05:32 PM, "Pascal J. Bourguignon" said:
>
>>You're confused. C doesn't have arrays. Â Lisp has arrays. C only has
>>vectors
>
> Neither C nor any other programming langua
In <87aa2iz3l1@kuiper.lan.informatimago.com>, on 04/11/2012
at 05:32 PM, "Pascal J. Bourguignon" said:
>You're confused. C doesn't have arrays. Lisp has arrays. C only has
>vectors
Neither C nor any other programming language has vectors ;-)
>That C calls its vectors "array", or its byt
"WJ" wrote:
>
>Slashes can work under windows, up to a point:
ALL Windows APIs accept forward slashes. The only place they are not
accepted is command line commands that take options which can begin with
forward slash.
>Also, most languages I use under windows allow you to use
>slashes in paths
Shmuel (Seymour J.) Metz writes:
> In <87wr5nl54w@sapphire.mobileactivedefense.com>, on 04/10/2012
>at 09:10 PM, Rainer Weikusat said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be sensibly applied to 'C strings' (which
>>are sim
Shmuel (Seymour J.) Metz writes:
> In <87wr5nl54w@sapphire.mobileactivedefense.com>, on 04/10/2012
>at 09:10 PM, Rainer Weikusat said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be sensibly applied to 'C strings' (which
>>are simi
["Followup-To:" header set to comp.lang.lisp.]
On 2012-04-11, Shmuel Metz wrote:
> In <87wr5nl54w@sapphire.mobileactivedefense.com>, on 04/10/2012
>at 09:10 PM, Rainer Weikusat said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be s
In <87wr5nl54w@sapphire.mobileactivedefense.com>, on 04/10/2012
at 09:10 PM, Rainer Weikusat said:
>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>first/rest terminology can be sensibly applied to 'C strings' (which
>are similar to linked-lists in the sense that ther
Xah Lee wrote:
>
> so recently i switched to a Windows version of python. Now, Windows
> version takes path using win backslash, instead of cygwin slash. This
> fucking broke my find/replace scripts that takes a dir level as input.
> Because i was counting slashes.
Slashes can work under windows
On 4/10/2012 4:10 PM, Rainer Weikusat wrote:
'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
first/rest terminology can be sensibly applied to 'C strings' (which
are similar to linked-lists in the sense that there's a 'special
termination value' instead of an explicit length
Shmuel (Seymour J.) Metz writes:
> In <20120409111329@kylheku.com>, on 04/09/2012
>at 06:55 PM, Kaz Kylheku said:
>
>>Null-terminated C strings do the same thing.
>
> C arrays are not LISP strings; there is no C analog to car and cdr.
'car' and 'cdr' refer to cons cells in Lisp, not to s
"Shmuel (Seymour J.)Metz" wrote in
message news:4f8410ff$2$fuzhry+tra$mr2...@news.patriot.net...
In <20120409111329@kylheku.com>, on 04/09/2012
at 06:55 PM, Kaz Kylheku said:
If we scan for a null terminator which is not there, we have a
buffer overrun.
You're only thinking of scanni
On Tue, Apr 10, 2012 at 6:52 AM, Shmuel Metz
wrote:
> In <20120409111329@kylheku.com>, on 04/09/2012
> at 06:55 PM, Kaz Kylheku said:
>
>>Null-terminated C strings do the same thing.
>
> C arrays are not LISP strings; there is no C analog to car and cdr.
The post you're criticising specif
In <87vcl81wtw@sapphire.mobileactivedefense.com>, on 04/09/2012
at 09:20 PM, Rainer Weikusat said:
>This is logically very similar to the LISP list
FSVO similar.
>This is, I think, a case where the opinions of people who have used
>C strings and the opinions of people who haven't differ
In <20120409111329@kylheku.com>, on 04/09/2012
at 06:55 PM, Kaz Kylheku said:
>Null-terminated C strings do the same thing.
C arrays are not LISP strings; there is no C analog to car and cdr.
>Code that needs to deal with null "characters" is manipulating
>binary data, not text,
That's
Rainer Weikusat writes:
> Shmuel (Seymour J.) Metz writes:
>
> [...]
>
>>>For one thing, if s is a non-empty null terminated string then,
>>>cdr(s) is also a string representing the rest of that string
>>>without the first character,
>>
>> Are you really too clueless to differentiate between C a
Shmuel (Seymour J.) Metz writes:
[...]
>>For one thing, if s is a non-empty null terminated string then,
>>cdr(s) is also a string representing the rest of that string
>>without the first character,
>
> Are you really too clueless to differentiate between C and LISP?
In LISP, a list is a set o
On 2012-04-09, Roy Smith wrote:
> In article <4f82d3e2$1$fuzhry+tra$mr2...@news.patriot.net>,
> Shmuel (Seymour J.) Metz wrote:
>
>> >Null terminated strings have simplified all kids of text
>> >manipulation, lexical scanning, and data storage/communication
>> >code resulting in immeasurable sa
On 2012-04-09, Shmuel Metz wrote:
> In <20120408114313...@kylheku.com>, on 04/08/2012
>at 07:14 PM, Kaz Kylheku said:
>
>>Null-terminated strings are infinitely better than the ridiculous
>>encapsulation of length + data.
>
> ROTF,LMAO!
>
>>For one thing, if s is a non-empty null terminated s
In article <4f82d3e2$1$fuzhry+tra$mr2...@news.patriot.net>,
Shmuel (Seymour J.) Metz wrote:
> >Null terminated strings have simplified all kids of text
> >manipulation, lexical scanning, and data storage/communication
> >code resulting in immeasurable savings over the years.
>
> Yeah, especial
In <20120408114313...@kylheku.com>, on 04/08/2012
at 07:14 PM, Kaz Kylheku said:
>Null-terminated strings are infinitely better than the ridiculous
>encapsulation of length + data.
ROTF,LMAO!
>For one thing, if s is a non-empty null terminated string then,
>cdr(s) is also a string representi
On 4/9/2012 1:52 AM, Chris Angelico wrote:
> I think this will be a real winner, and you
> should team up with Ranting Rick to produce a new operating system and
> Python with this new specification and RULE THE WORLD!
But only after going back to the cage to plan for tomorrow night.
--
CPython 3
Ok no problem. My sloppiness. After all, my implementation wasn't
portable. So, let's fix it. After a while, discovered there's the
os.sep. Ok, replace "/" to os.sep, done. Then, bang, all hell
went lose. Because, the backslash is used as escape in string, so any
regex that manipulate path got fuc
On Mon, Apr 9, 2012 at 3:45 PM, Xah Lee wrote:
> because, slash is one of the useful char, far more so than backslash.
> Users should be able to use that for file names.
>
Users should be able to use EVERY character for their file names. So
here's a solution. Your path separator is the byte 0xFF,
Xah Lee wrote:
« http://xahlee.org/comp/fuck_python.html »
David Canzi wrote
«When Microsoft created MS-DOS, they decided to use '\' as the
separator in file names. Â This was at a time when several previously
existing interactive operating systems were using '/' as the file name
separator an
On 04/08/2012 08:04 PM, David Robinow wrote:
> On Sun, Apr 8, 2012 at 6:55 PM, Dennis Lee Bieber
> wrote:
>>The main reason, as I recall, for the command line using \ for file
>> paths is that it inherited / as command OPTION prefix from CP/M; MS-DOS
>> being a 32-bit work-alike for CP/M
On Sun, Apr 8, 2012 at 6:55 PM, Dennis Lee Bieber wrote:
> The main reason, as I recall, for the command line using \ for file
> paths is that it inherited / as command OPTION prefix from CP/M; MS-DOS
> being a 32-bit work-alike for CP/M in the first generation.
I also thought it was becau
On Sun, 08 Apr 2012 04:11:20 -0700, Xah Lee wrote:
> Ok no problem. My sloppiness. After all, my implementation wasn't
> portable. So, let's fix it. After a while, discovered there's the
> os.sep. Ok, replace "/" to os.sep, done. Then, bang, all hell
> went lose. Because, the backslash is used as
"Kaz Kylheku" wrote in message
news:20120408114313...@kylheku.com...
Worse, the one byte Unix mistake being covered is, disappointingly, just a
clueless rant against null-terminated strings.
Null-terminated strings are infinitely better than the ridiculous
encapsulation of length + data.
For
On Sun, Apr 8, 2012 at 11:32 AM, Peter J. Holzer wrote:
> Poul-Henning Kamp nominated the C/Unix guys:
>
> http://queue.acm.org/detail.cfm?id=2010365
Besides what Kaz and Chris wrote, the suggestion that if they had
chosen ptr+len format then we wouldn't have buffer overflows is
erroneous. There
On Mon, Apr 9, 2012 at 5:14 AM, Kaz Kylheku wrote:
> Not only can compilers compress storage by recognizing that string literals
> are
> the suffixes of other string literals, but a lot of string manipulation code
> is
> simplified, because you can treat a pointer to interior of any string as a
On 2012-04-08, Peter J. Holzer wrote:
> On 2012-04-08 17:03, David Canzi wrote:
>> If you added up the cost of all the extra work that people have
>> done as a result of Microsoft's decision to use '\' as the file
>> name separator, it would probably be enough money to launch the
>> Burj Khalifa
("C:/users/terry/data/somefile.txt")
I just verified that you can pass arguments with slashes, such as a
path, to a Python program from the shell. Here is my tem.py:
import sys
print(sys.argv)
If I run it from its directory as current path:
F:\Python\mypy>c:\programs\python32\pyth
"David Canzi" wrote:
>Xah Lee wrote:
Please check whom you are replying to.
Do not feed the trolls, please.
jue
--
http://mail.python.org/mailman/listinfo/python-list
On 2012-04-08 17:03, David Canzi wrote:
> If you added up the cost of all the extra work that people have
> done as a result of Microsoft's decision to use '\' as the file
> name separator, it would probably be enough money to launch the
> Burj Khalifa into geosynchronous orbit.
So we have anothe
["Followup-To:" header set to comp.lang.lisp.]
On 2012-04-08, David Canzi wrote:
> Xah Lee wrote:
>>hi guys,
>>
>>sorry am feeling a bit prolifit lately.
>>
>>today's show, is: 'Fuck Python'
>>http://xahlee.org/comp/fuck_python.html
>>
>>
>>Fuck Python
>> By X
Xah Lee wrote:
>hi guys,
>
>sorry am feeling a bit prolifit lately.
>
>today's show, is: 'Fuck Python'
>http://xahlee.org/comp/fuck_python.html
>
>
>Fuck Python
> By Xah Lee, 2012-04-08
>
>fuck Python.
>
>just fucking spend 2 hours and still going.
>
>here's th
On 04/08/12 09:11, HoneyMonster wrote:
Well, I certainly shall not be reading - or even seeing - any more of his
drivel.
Yes you will. There is always someone willing to include his entire
messages for a one line reply.
It's always September somewhere.
--
D'Arcy J.M. Cain | Democra
On Sun, 08 Apr 2012 11:34:56 +, Steven D'Aprano wrote:
> When the only tool you know how to use is a hammer, everything looks
> like a nail. Instead of using regexes ("now you have two problems"), use
> the right tool: to count path components, split the path, then count the
> number of path c
On 08/04/2012 12:11, Xah Lee wrote:
Hi Xah,
You clearly didn't want help on this subject, as you really now how to
do it anyway. But having read your posts over the years, I'd like to
give you an observation on your persona, free of charge! :-)
You are actually a talented writer, some may fi
On Sun, 08 Apr 2012 11:34:56 +, Steven D'Aprano wrote:
> I have read Xah Lee's post so that you don't have to.
Well, I certainly shall not be reading - or even seeing - any more of his
drivel.
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 8, 4:34 am, Steven D'Aprano wrote:
> On Sun, 08 Apr 2012 04:11:20 -0700, Xah Lee wrote:
>
> [...]
>
> I have read Xah Lee's post so that you don't have to.
>
> Shorter Xah Lee:
>
> "I don't know Python very well, and rather than admit I made
> some pretty lousy design choices in my
Congratulations. You just tried to treat Python as though it were a
hammer and your task as though it were a nail. And you bashed your
thumb while doing it. You also hurt yourself on Windows and blamed it
on Python. I'm afraid I'm fresh out of sympathy, won't get a new
shipment till tomorrow.
Chri
On Sun, 08 Apr 2012 04:11:20 -0700, Xah Lee wrote:
[...]
I have read Xah Lee's post so that you don't have to.
Shorter Xah Lee:
"I don't know Python very well, and rather than admit I made
some pretty lousy design choices in my code, I blame Python.
And then I cross-post about it,
hi guys,
sorry am feeling a bit prolifit lately.
today's show, is: 〈Fuck Python〉
http://xahlee.org/comp/fuck_python.html
Fuck Python
By Xah Lee, 2012-04-08
fuck Python.
just fucking spend 2 hours and still going.
here's the short story.
so recently i swi
50 matches
Mail list logo