| |
 Search this list this category for: (Advanced)

Mailing List Archive: Python: Python

# f python?

 1 2  View All Index | Next | Previous | Print Thread | View Threaded

xahlee at gmail

Apr 8, 2012, 4:11 AM

Post #1 of 50 (1336 views)
 f python?
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 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.

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 fucked majorly. So, now you need to
find a quoting mechanism. Then, fuck python doc incomprehensible
scattered comp-sci-r-us BNF shit. Then, fuck python for “os.path” and
“os” modules then string object and string functions inconsistent
ball. And FUCK Guido who wants to fuck change python for his idiotic
OOP concept of “elegance” so that some of these are deprecated.

So after several exploration of “repr()”, “format()”, “‹str›.count()”,
“os.path.normpath()”, “re.split()”, “len(re.search().group())” etc,
after a long time, let's use “re.escape()”. 2 hours has passed. Also,
discovered that “os.path.walk” is now deprecated, and one is supposed
to use the sparkling “os.walk”. In the process of refreshing my
python, the “os.path.walk” semantics is really one fucked up fuck.
Meanwhile, the “os.walk” went into incomprehensible OOP object and
iterators fuck.

now, it's close to 3 hours. This fix is supposed to be done in 10 min.
I'd have done it in elisp in just 10 minutes if not for my
waywardness.

This is Before

def process_file(dummy, current_dir, file_list):
current_dir_level = len(re.split("/", current_dir)) -
len(re.split("/", input_dir))
cur_file_level = current_dir_level+1
if min_level <= cur_file_level <= max_level:
for a_file in file_list:
if re.search(r"\.html$", a_file, re.U) and os.path.isfile(current_dir + "/" + a_file): replace_string_in_file(current_dir + "/" + a_file) This is After def process_file(dummy, current_dir, file_list): current_dir = os.path.normpath(current_dir) cur_dir_level = re.sub( "^" + re.escape(input_dir), "", current_dir).count( os.sep) cur_file_level = cur_dir_level + 1 if min_level <= cur_file_level <= max_level: for a_file in file_list: if re.search(r"\.html$", a_file, re.U) and
os.path.isfile(current_dir + re.escape(os.sep) + a_file):
replace_string_in_file(current_dir + os.sep + a_file)
# print "%d %s" % (cur_file_level, (current_dir + os.sep +
a_file))

Complete File

# -*- coding: utf-8 -*-
# Python

# find & replace strings in a dir

import os, sys, shutil, re

# if this this is not empty, then only these files will be processed
my_files = []

input_dir = "c:/Users/h3/web/xahlee_org/lojban/hrefgram2/"
input_dir = "/cygdrive/c/Users/h3/web/zz"
input_dir = "c:/Users/h3/web/xahlee_org/"

min_level = 2; # files and dirs inside input_dir are level 1.
max_level = 2; # inclusive

print_no_change = False

find_replace_list = [

(
u"""<iframe style="width:100%;border:none" src="http://xahlee.org/
footer.html"></iframe>""",
u"""<iframe style="width:100%;border:none" src="../footer.html"></
iframe>""",
),

]

def replace_string_in_file(file_path):
"Replaces all findStr by repStr in file file_path"
temp_fname = file_path + "~lc~"
backup_fname = file_path + "~bk~"

input_file = open(file_path, "rb")
input_file.close()

num_replaced = 0
for a_pair in find_replace_list:
num_replaced += file_content.count(a_pair[0])
output_text = file_content.replace(a_pair[0], a_pair[1])
file_content = output_text

if num_replaced > 0:
print "◆ ", num_replaced, " ", file_path.replace("\\", "/")
shutil.copy2(file_path, backup_fname)
output_file = open(file_path, "r+b")
preserve file creation date
output_file.seek(0)
output_file.write(output_text.encode("utf-8"))
output_file.truncate()
output_file.close()
else:
if print_no_change == True:
print "no change:", file_path

# os.remove(file_path)
# os.rename(temp_fname, file_path)

def process_file(dummy, current_dir, file_list):
current_dir = os.path.normpath(current_dir)
cur_dir_level = re.sub( "^" + re.escape(input_dir), "",
current_dir).count( os.sep)
cur_file_level = cur_dir_level + 1
if min_level <= cur_file_level <= max_level:
for a_file in file_list:
if re.search(r"\.html\$", a_file, re.U) and
os.path.isfile(current_dir + re.escape(os.sep) + a_file):
replace_string_in_file(current_dir + os.sep + a_file)
# print "%d %s" % (cur_file_level, (current_dir + os.sep +
a_file))

input_dir = os.path.normpath(input_dir)

if (len(my_files) != 0):
for my_file in my_files:
replace_string_in_file(os.path.normpath(my_file) )
else:
os.path.walk(input_dir, process_file, "dummy")

print "Done."

--
http://mail.python.org/mailman/listinfo/python-list

steve+comp.lang.python at pearwood

Apr 8, 2012, 4:34 AM

Post #2 of 50 (1288 views)
 Re: f python? [In reply to]
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, because I'm the most important
person in the Universe."

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 components directly.

import os
components = os.path.split(some_path)
print len(components)

No matter what separator the OS users, os.path.split will do the right
thing. There's no need to mess about escaping separators so you can
hammer it with the regex module, when Python comes with the perfectly
functional socket-wrench you actually need.

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 8, 2012, 4:37 AM

Post #3 of 50 (1288 views)
 Re: f python? [In reply to]
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.

Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list

xahlee at gmail

Apr 8, 2012, 5:04 AM

Post #4 of 50 (1286 views)
 Re: f python? [In reply to]
On Apr 8, 4:34am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> 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 code, I blame Python.
> And then I cross-post about it, because I'm the most important
> person in the Universe."
>
> 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 components directly.
>
> import os
> components = os.path.split(some_path)
> print len(components)
>
> No matter what separator the OS users, os.path.split will do the right
> thing. There's no need to mess about escaping separators so you can
> hammer it with the regex module, when Python comes with the perfectly
> functional socket-wrench you actually need.

Lol. i think you tried to make fun of me too fast.

O, was it you who made fun of my python tutorial before? i was busy,
i'll have to get back on that down the road.

Xah
--
http://mail.python.org/mailman/listinfo/python-list

martin.hellwig at gmail

Apr 8, 2012, 6:10 AM

Post #5 of 50 (1286 views)
 Re: f python? [In reply to]
On 08/04/2012 12:11, Xah Lee wrote:
<cut all>
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 find your occasional
profanity offensive but at least it highlights your frustration.
You are undoubtedly and proven a good mathematian and more important
than that self taught. You have a natural feel for design (otherwise you
would not clash with others view of programming).
You know a mixture of programming languages.

Whether you like it or not, you are in the perfect position to create a
new programming language and design a new programming paradigm.
Unhindered from all the legacy crap, that keep people like me behind (I
actually like BNF for example).

It is likely I am wrong, but if that is your destiny there is no point
fighting it.

Cheers and good luck,

Martin
--
http://mail.python.org/mailman/listinfo/python-list

someone at someplace

Apr 8, 2012, 6:11 AM

Post #6 of 50 (1288 views)
 Re: f python? [In reply to]
On Sun, 08 Apr 2012 11:34:56 +0000, 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

steve+comp.lang.python at pearwood

Apr 8, 2012, 6:29 AM

Post #7 of 50 (1286 views)
 Re: f python? [In reply to]
On Sun, 08 Apr 2012 11:34:56 +0000, 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 components directly.
>
> import os
> components = os.path.split(some_path)
> print len(components)

Which is completely wrong. How embarrassing. Serves me right for not
testing my code before sending.

Nevertheless it is easy enough to write a split path function, or even to
use it in place:

def splitpath(path):
return os.path.normpath(path).split(os.path.sep)

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

darcy at druid

Apr 8, 2012, 7:56 AM

Post #8 of 50 (1288 views)
 Re: f python? [In reply to]
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 <darcy [at] druid> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
IM: darcy [at] Vex
--
http://mail.python.org/mailman/listinfo/python-list

dmcanzi at uwaterloo

Apr 8, 2012, 10:03 AM

Post #9 of 50 (1285 views)
 Re: f python? [In reply to]
Xah Lee <xahlee [at] gmail> 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 the short story.
>
>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.
>
>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 fucked majorly.

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 and at least one was using '\'
as an escape character. As a result of Microsoft's decision
to use '\' as the separator, people have had to do extra work
to adapt programs written for Windows to run in non-Windows
environments, and vice versa. People have had to do extra work
to write software that is portable between these environments.
People have done extra work while creating tools to make writing
portable software easier. And people have to do extra work when
they use these tools, because using them is still harder than
writing portable code for operating systems that all used '/'
as their separator would have been.

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, when you say fuck Python, are you sure you're shooting at the
right target?

--
David Canzi | TIMTOWWTDI (tim-toe-woe-dee): There Is More Than One
| Wrong Way To Do It
--
http://mail.python.org/mailman/listinfo/python-list

kaz at kylheku

Apr 8, 2012, 10:25 AM

Post #10 of 50 (1285 views)
 Re: f python? [In reply to]
On 2012-04-08, David Canzi <dmcanzi [at] uwaterloo> wrote:
> Xah Lee <xahlee [at] gmail> 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 the short story.
>>
>>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.
>>
>>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 fucked majorly.
>
> When Microsoft created MS-DOS, they decided to use '\' as
> the separator in file names.

This is false. The MS-DOS (dare I say it) "kernel" accepts both forward and
backslashes as separators.

The application-level choice was once configurable through a variable
in COMMAND.COM. Then they hard-coded it to backslash.

However, Microsoft operating systems continued to (and until this day)
recognize slash as a path separator.

Only, there are broken userland programs on Windows which don't know this.

> So, when you say fuck Python, are you sure you're shooting at the
> right target?

I would have to say, probably yes.
--
http://mail.python.org/mailman/listinfo/python-list

hjp-usenet2 at hjp

Apr 8, 2012, 10:32 AM

Post #11 of 50 (1284 views)
 Re: f python? [In reply to]
On 2012-04-08 17:03, David Canzi <dmcanzi [at] uwaterloo> 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 another contender for the Most Expensive One-byte Mistake?

Poul-Henning Kamp nominated the C/Unix guys:

http://queue.acm.org/detail.cfm?id=2010365

hp

--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp [at] hjp |
__/ | http://www.hjp.at/ | -- Bill Code on asrg [at] irtf
--
http://mail.python.org/mailman/listinfo/python-list

jurgenex at hotmail

Apr 8, 2012, 10:49 AM

Post #12 of 50 (1286 views)
 Re: f python? [In reply to]
"David Canzi" <dmcanzi [at] uwaterloo> wrote:
>Xah Lee <xahlee [at] gmail> wrote:

Do not feed the trolls, please.

jue
--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Apr 8, 2012, 10:59 AM

Post #13 of 50 (1286 views)
 Re: f python? [In reply to]
On 4/8/2012 7:11 AM, 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.

Python passes strings to Windows functions as the user requests. In
spite of the fact that command.com and cmd.exe (command prompt window)
require backslashes for paths that they proccess, the internal Windows
functions all (as far as I know) accept slashes in paths. Slashes are
used for options only at the shell level. So within a Python program,
one can use slashes on Windows too, just as you are used to.

open("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\python.exe tem.py /a/b
['tem.py', '/a/b']

If the current directory were not the directory containing the script,
then one would have to use backslashes for the path to the script and
would see backslashes in sys.argv[0]. If I execute tem.py in IDLE, the
output is

['F:\\Python\\mypy\\tem.py']

because IDLE 'starts in' the python.exe directory and Windows functions
produce paths with '\' even though they accept them with '/'.

Try aiming your ire at the right target. The title of this post should
have been Fuck Microsoft for the billion (at least) in time, effort, and
annoyance they inflicted on the world by being intentionally different
from and conflicting with unix on shell syntax.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

kaz at kylheku

Apr 8, 2012, 12:14 PM

Post #14 of 50 (1288 views)
 Re: f python? [In reply to]
On 2012-04-08, Peter J. Holzer <hjp-usenet2 [at] hjp> wrote:
> On 2012-04-08 17:03, David Canzi <dmcanzi [at] uwaterloo> 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 another contender for the Most Expensive One-byte Mistake?

The one byte mistake in DOS and Windows is recognizing two characters as path
separators. All code that correctly handles paths is complicated by having to
look for a set of characters instead of just scanning for a byte.

> http://queue.acm.org/detail.cfm?id=2010365

DOS backslashes are already mentioned in that page, but alas it perpetuates the
clueless myth that DOS and windows do not recognize any other path separator.

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 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,
where cdr(s) is conveniently defined as s + 1.

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
string.

Because they are recursively defined, you can do elegant tail recursion on null
terminated strings:

const char *rec_strchr(const char *in, int ch)
{
if (*in == 0)
return 0;
else if (*in == ch)
return in;
else
return rec_strchr(in + 1, ch);
}

length + data also raises the question: what type is the length field? One
byte? Two bytes? Four? And then you have issues of byte order. Null terminated
C strings can be written straight to a binary file or network socket and be
instantly understood on the other end.

Null terminated strings have simplified all kids of text manipulation, lexical
scanning, and data storage/communication code resulting in immeasurable
savings over the years.
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 8, 2012, 12:27 PM

Post #15 of 50 (1284 views)
 Re: f python? [In reply to]
On Mon, Apr 9, 2012 at 5:14 AM, Kaz Kylheku <kaz [at] 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
> string.

I'm not sure about the value of tail recursion in C, but this is
definitely a majorly useful feature, as is the related technique of
parsing by dropping null bytes into the string (see for instance the
strtok function, which need not do any memory movement; I wrote a CSV
parser that works the same way). Often I use both techniques
simultaneously, for instance in parsing this sort of string:

"A:100 B:200 C:300"

First, tokenize on the spaces by looking for a space, retaining a
pointer, and putting in a NUL:
char *next=strchr(str,' '); if (!next) break; *next++=0;
Then read a character, and increment the pointer through that string
as you parse.

Try doing THAT in a high level language without any memory copying.
And "without any memory copying" may not be important with this
trivial example, but suppose you've just read in a huge CSV file to
parse - maybe 16MB in the normal case, with no actual limit other than
virtual memory. (And yes, I read the whole thing in at once, because
it comes from a Postgres database and reading it in pieces would put
more load on the central database server.)

Don't get me wrong, I wouldn't want to do _everything_ in C; but I
also wouldn't want to do everything in length-preceded strings. The
nearest equivalent that would be able to use the shared buffer is a
length-external string like BASIC uses (or used, back when I used to
write BASIC code and 8086 assembly to interface with it) - a string
"object" consists of a length and a pointer. But that has issues with
freeing up memory, if you're using parts of a string.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

ian.g.kelly at gmail

Apr 8, 2012, 3:32 PM

Post #16 of 50 (1284 views)
 Re: f python? [In reply to]
On Sun, Apr 8, 2012 at 11:32 AM, Peter J. Holzer <hjp-usenet2 [at] hjp> 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's a difference between a string and a string buffer,
and the metadata records the length of the string, not the size of the
buffer, and so the gets function in that parallel universe would be
just as broken as the one in ours.
--
http://mail.python.org/mailman/listinfo/python-list

bc at freeuk

Apr 8, 2012, 3:46 PM

Post #17 of 50 (1284 views)
 Re: f python? [In reply to]
"Kaz Kylheku" <kaz [at] kylheku> wrote in message
news:20120408114313.85 [at] kylheku

> 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 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,
> where cdr(s) is conveniently defined as s + 1.

If strings are represented as (ptr,length), then a cdr(s) would have to
return (ptr+1,length-1), or (nil,0) if s was one character. No big deal.

(Note I saw your post in comp.lang.python; I don't about any implications of
that for Lisp.)

And if, instead, you want to represent all but the last character of the
string, then it's just (ptr,length-1). (Some checking is needed around empty
strings, but similar checks are needed around s+1.)

In addition, if you want to represent the middle of a string, then it's also
very easy: (ptr+a,b).

> 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
> string.

Yes, the string "bart" also contains "art", "rt" and "t". But with counted
strintgs, it can also contain "bar", "ba", "b", etc....

There are a few advantages to counted strings too...

> length + data also raises the question: what type is the length field? One
> byte? Two bytes? Four?

Depends on the architecture. But 4+4 for 32-bits, and 8+8 bytes for 64-bits,
I would guess, for general flex strings of any length.

There are other ways of encoding a length.

(For example I use one short string type of maximum M characters, but the
current length N is encoded into the string, without needing any extra count
byte (by fiddling about with the last couple of bytes). If you're trying to
store a short string in an 8-byte field in a struct, then this will let you
use all 8 bytes; a zero-terminated one, only 7.)

> And then you have issues of byte order.

Which also affects every single value of more than one byte.

> Null terminated
> C strings can be written straight to a binary file or network socket and
> be
> instantly understood on the other end.

But they can't contains nulls!

> Null terminated strings have simplified all kids of text manipulation,
> lexical
> scanning, and data storage/communication code resulting in immeasurable
> savings over the years.

They both have their uses.

--
Bartc

--
http://mail.python.org/mailman/listinfo/python-list

nobody at nowhere

Apr 8, 2012, 4:43 PM

Post #18 of 50 (1284 views)
 Re: f python? [In reply to]
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 escape in string, so any
> regex that manipulate path got fucked majorly. So, now you need to
> find a quoting mechanism.

if os.altsep is not None:
sep_re = '[%s%s]' % (os.sep, os.altsep)
else:
sep_re = '[%s]' % os.sep

But really, you should be ranting about regexps rather than Python.
They're convenient if you know exactly what you want to match, but a
nuisance if you need to generate the expression based upon data which is
only available at run-time (and re.escape() only solves one very specific
problem).

--
http://mail.python.org/mailman/listinfo/python-list

drobinow at gmail

Apr 8, 2012, 5:04 PM

Post #19 of 50 (1286 views)
 Re: f python? [In reply to]
On Sun, Apr 8, 2012 at 6:55 PM, Dennis Lee Bieber <wlfraed [at] ix> 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 because Bill Gates used a PDP-11 in high school
and DEC used the / as command OPTION
I found out later that Gates purchased DOS rather than wrote it, so
this story may be erroneous. Nevertheless, at the time, DEC was way
bigger than AT&T (in computers) and the choice really wasn't
surprising.
--
http://mail.python.org/mailman/listinfo/python-list

d at davea

Apr 8, 2012, 5:25 PM

Post #20 of 50 (1284 views)
 Re: f python? [In reply to]
On 04/08/2012 08:04 PM, David Robinow wrote:
> On Sun, Apr 8, 2012 at 6:55 PM, Dennis Lee Bieber <wlfraed [at] ix> 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 because Bill Gates used a PDP-11 in high school
> and DEC used the / as command OPTION
> I found out later that Gates purchased DOS rather than wrote it, so
> this story may be erroneous. Nevertheless, at the time, DEC was way
> bigger than AT&T (in computers) and the choice really wasn't
> surprising.

CP/M was indeed the inspiration for QDOS (Quick and Dirty OS), and it
shows in lots of ways, right down to the layout of the PSP at the
beginning of program's memory images. There was a separate group within
Microsoft doing Xenix ( ~ Unix), and the two did not cooperate.

But just as important, just as it was "clear" that PC programs would
never need more than 640k, it was also clear that disks would never get
bigger than a few meg. Subdirectories were not part of the original
picture, and were not supported till MSDOS 2.0

--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

xahlee at gmail

Apr 8, 2012, 10:45 PM

Post #21 of 50 (1283 views)
 Re: f python? [In reply to]
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 and at least one was using '\' as an escape character.  As a
result of Microsoft's decision to use '\' as the separator, people
have had to do extra work to adapt programs written for Windows to run
in non-Windows environments, and vice versa.  People have had to do
extra work to write software that is portable between these
environments. People have done extra work while creating tools to
make writing portable software easier.  And people have to do extra
work when they use these tools, because using them is still harder
than writing portable code for operating systems that all used '/' as
their separator would have been.»

namekuseijin wrote:

> yes, absolutely.  But you got 2 inaccuracies there:  1) Microsoft didn't create DOS; 2) fucking DOS was written in C, and guess what, it uses \ as escape character.  Fucking microsoft.
>
> > So, when you say fuck Python, are you sure you're shooting at the
> > right target?
>
> I agree.  Fuck winDOS and fucking microsoft.

No. The choice to use backslash than slash is actually a good one.

because, slash is one of the useful char, far more so than backslash.
Users should be able to use that for file names.

i don't know the detailed history of path separator, but if i were to
blame, it's fuck unix. The entirety of unix, unix geek, unixers, unix

〈On Unix Filename Characters Problem〉
http://xahlee.org/UnixResource_dir/writ/unix_filename_chars.html

〈On Unix File System's Case Sensitivity〉
http://xahlee.org/UnixResource_dir/_/fileCaseSens.html

〈UNIX Tar Problem: File Length Truncation, Unicode Name Support〉
http://xahlee.org/comp/unix_tar_problem.html

〈What Characters Are Not Allowed in File Names?〉
http://xahlee.org/mswin/allowed_chars_in_file_names.html

〈Unicode Support in File Names: Windows, Mac, Emacs, Unison, Rsync,
USB, Zip〉
http://xahlee.org/mswin/unicode_support_file_names.html

〈The Nature of the Unix Philosophy〉
http://xahlee.org/UnixResource_dir/writ/unix_phil.html

Xah
--
http://mail.python.org/mailman/listinfo/python-list

alex.mizrahi at gmail

Apr 8, 2012, 11:51 PM

Post #22 of 50 (1283 views)
 Re: f python? [In reply to]
>> 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 fucked majorly. So, now you need to
>> find a quoting mechanism.
>
> if os.altsep is not None:
> sep_re = '[%s%s]' % (os.sep, os.altsep)
> else:
> sep_re = '[%s]' % os.sep
>
> But really, you should be ranting about regexps rather than Python.
> They're convenient if you know exactly what you want to match, but a
> nuisance if you need to generate the expression based upon data which is
> only available at run-time (and re.escape() only solves one very specific
> problem).

It isn't a problem of regular expressions, but a problem of syntax for
specification of regular expressions (i.e. them being specified as a
string).

Common Lisp regex library cl-ppcre allows to specify regex via a parse
tree. E.g. "(foo[/\\]bar)" becomes

(:REGISTER (:SEQUENCE "foo" (:CHAR-CLASS #\/ #\\) "bar"))

This is more verbose, but totally unambiguous and requires no escaping.

So this definitely is a problem of Python's regex library, and a problem
of lack of support for nice parse tree representation in code.

cl-ppcre supports both textual perl-compatible regex specification and
parse tree. I would start with a simple string specification, then when
shit hits fan I can call cl-ppcre::parse-string to get those parse trees
and replaces forward slash with back slash. Moreover, I can
automatically convert regexes:

(defun scan-auto/ (regex target-string)
(let ((fixed-parse-tree (subst '(:char-class #\/ #\\) '(:char-class #\/)
(cl-ppcre::parse-string regex)
:test 'equal)))
(cl-ppcre:scan-to-strings fixed-parse-tree target-string)))

CL-USER> (scan-auto/ "foo[/]bar" "foo\\bar")
"foo\\bar"
#()
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 8, 2012, 11:52 PM

Post #23 of 50 (1283 views)
 Re: f python? [In reply to]
On Mon, Apr 9, 2012 at 3:45 PM, Xah Lee <xahlee [at] gmail> 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, and your file
names are UTF-8 encoded. 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!

Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list

bahamutzero8825 at gmail

Apr 9, 2012, 12:22 AM

Post #24 of 50 (1285 views)
 Re: f python? [In reply to]
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.2.2 | Windows NT 6.1.7601.17640
--
http://mail.python.org/mailman/listinfo/python-list

spamtrap at library

Apr 9, 2012, 5:19 AM

Post #25 of 50 (1283 views)
 Re: f python? [In reply to]
In <20120408114313.85 [at] kylheku>, on 04/08/2012
at 07:14 PM, Kaz Kylheku <kaz [at] 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 representing the rest of that string
>without the first character,

Are you really too clueless to differentiate between C and LISP?

>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, especially code that needs to deal with lengths and nulls. It's
great for buffer overruns too.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not