f python?

Discussion in 'Perl Misc' started by Xah Lee, Apr 8, 2012.

  1. Xah Lee

    Xah Lee Guest

    hi guys,

    sorry am feeling a bit prolifit lately.

    today's show, is: 〈Fuck Python〉
    http://xahlee.org/comp/fuck_python.html

    ------------------------------------
    **** Python
    By Xah Lee, 2012-04-08

    **** 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, **** python doc incomprehensible
    scattered comp-sci-r-us BNF shit. Then, **** python for “os.path†and
    “os†modules then string object and string functions inconsistent
    ball. And **** Guido who wants to **** 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 ****.
    Meanwhile, the “os.walk†went into incomprehensible OOP object and
    iterators ****.

    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~"

    # print "reading:", file_path
    input_file = open(file_path, "rb")
    file_content = unicode(input_file.read(), "utf-8")
    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")
    output_file.read() # we do this way instead of “os.rename†to
    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."
     
    Xah Lee, Apr 8, 2012
    #1
    1. Advertising

  2. 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
     
    Martin P. Hellwig, Apr 8, 2012
    #2
    1. Advertising

  3. Xah Lee

    David Canzi Guest

    Xah Lee <> wrote:
    >hi guys,
    >
    >sorry am feeling a bit prolifit lately.
    >
    >today's show, is: '**** Python'
    >http://xahlee.org/comp/fuck_python.html
    >
    >------------------------------------
    >**** Python
    > By Xah Lee, 2012-04-08
    >
    >**** 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 **** 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
     
    David Canzi, Apr 8, 2012
    #3
  4. Xah Lee

    Kaz Kylheku Guest

    ["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: '**** Python'
    >>http://xahlee.org/comp/fuck_python.html
    >>
    >>------------------------------------
    >>**** Python
    >> By Xah Lee, 2012-04-08
    >>
    >>**** 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 **** Python, are you sure you're shooting at the
    > right target?


    I would have to say, probably yes.
     
    Kaz Kylheku, Apr 8, 2012
    #4
  5. 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 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.
    | | | |
    __/ | http://www.hjp.at/ | -- Bill Code on
     
    Peter J. Holzer, Apr 8, 2012
    #5
  6. "David Canzi" <> wrote:
    >Xah Lee <> wrote:


    Please check whom you are replying to.

    Do not feed the trolls, please.

    jue
     
    Jürgen Exner, Apr 8, 2012
    #6
  7. Xah Lee

    Kaz Kylheku Guest

    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 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.
     
    Kaz Kylheku, Apr 8, 2012
    #7
  8. Xah Lee

    Nobody Guest

    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).
     
    Nobody, Apr 9, 2012
    #8
  9. Xah Lee

    Xah Lee Guest

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

    >
    > I agree.  **** 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 **** unix. The entirety of unix, unix geek, unixers, unix
    fuckheads. **** 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
     
    Xah Lee, Apr 9, 2012
    #9
  10. Xah Lee

    Roy Smith Guest

    In article <4f82d3e2$1$fuzhry+tra$>,
    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, especially code that needs to deal with lengths and nulls. It's
    > great for buffer overruns too.


    I once worked on a C++ project that used a string class which kept a
    length count, but also allocated one extra byte and stuck a null at the
    end of every string.
     
    Roy Smith, Apr 9, 2012
    #10
  11. Xah Lee

    Kaz Kylheku Guest

    On 2012-04-09, Shmuel Metz <> wrote:
    > In <>, 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 representing the rest of that string
    >>without the first character,

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


    In Lisp we can burn a list literal like '(a b c) into ROM, and compute (b c)
    without allocating any memory.

    Null-terminated C strings do the same thing.

    In some Lisp systems, in fact, "CDR coding" was used to save space when
    allocating a list all at once. This created something very similar to
    a C string: a vector-like object of all the CARs, with a terminating
    convention marking the end.

    It's logically very similar.

    I need not repeat the elegant recursion example for walking a C string.

    That example is not possible with the length + data representation.
    (Not without breaking the encapsulation and passing the length as a separate
    recursion parameter to a recursive routine that works with the raw data part of
    the string.)

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


    To get the length of a string, you call a function, in either representation,
    so it is not any more complicated from a coding point of view. The function is,
    of course, more expensive if the string is null terminated, but you can code
    with awareness of this and not call length wastefully.

    If all else was equal (so that the expense of the length operation were
    the /only/ issue) then of course the length + data would be better.

    However, all else is not equal.

    One thing that is darn useful, for instance, is that
    p + strlen(p) still points to a string which is length zero, and this
    sort of thing is widely exploited in text processing code. e.g.

    size_t digit_prefix_len = strspn(input_string, "0123456789");
    const char *after_digits = input-string + digit_prefix_len;

    if (*after_digits == 0) {
    /* string consists only of digits: nothing after digits */
    } else {
    /* process part after digits */
    }

    It's nice that after_digits is a bona-fide string just like input_string,
    without any memory allocation being required.

    We can lexically analyze a string without ever asking it what its length is,
    and as we march down the string, the remaining suffix of that string is always
    a string so we can treat it as one, recurse on it, whatever.

    Code that needs to deal with null "characters" is manipulating binary data, not
    text, and should use a suitable data structure for that.

    > It's great for buffer overruns too.


    If we scan for a null terminator which is not there, we have a buffer overrun.

    If a length field in front of string data is incorrect, we also have a buffer
    overrrun.

    A pattern quickly emerges here: invalid, corrupt data produced by buggy code
    leads to incorrect results, and behavior that is not well-defined!
     
    Kaz Kylheku, Apr 9, 2012
    #11
  12. Xah Lee

    Kaz Kylheku Guest

    On 2012-04-09, Roy Smith <> wrote:
    > In article <4f82d3e2$1$fuzhry+tra$>,
    > 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, especially code that needs to deal with lengths and nulls. It's
    >> great for buffer overruns too.

    >
    > I once worked on a C++ project that used a string class which kept a
    > length count, but also allocated one extra byte and stuck a null at the
    > end of every string.


    Me too! I worked on numerous C++ projects with such a string template
    class.

    It was usually called

    std::basic_string

    and came from this header called:

    #include <string>

    which also instantiated it into two flavors under two nicknames:
    std::basic_string<char> being introduced as std::string, and
    std::basic_string<wchar_t> as std::wstring.

    This class had a c_str() function which retrieved a null-terminated
    string and so most implementations just stored the data that way, but
    some of the versions of that class cached the length of the string
    to avoid doing a strlen or wcslen operation on the data.
     
    Kaz Kylheku, Apr 9, 2012
    #12
  13. 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 of conses (pairs) whose car (first element of
    the pair) contains a value and whose cdr (second element of the pair)
    links to the next cons that's part of the list. The end of a list is
    marked by a cdr whose value is nil. A so-called 'C string' is a
    sequentially allocated sequence of memory locations which contain the
    characters making up the string and the end of it is marked by a
    memory location holding the value 0. This is logically very similar
    to the LISP list and it shouldn't be to difficult to understand that
    'cdr(s) is also a string representing the rest of the string' means
    'given that s points to a non-empty C string, s + 1 points to a
    possibly empty C string which is identical with s with the first
    character removed'.

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


    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 greatly. A nice
    German proverb applicable to situations like that would be 'Was der
    Bauer nicht kennt das frisst er nicht' ...
     
    Rainer Weikusat, Apr 9, 2012
    #13
  14. 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 and LISP?

    >
    > In LISP, a list is a set of conses (pairs) whose car (first element of
    > the pair) contains a value and whose cdr (second element of the pair)
    > links to the next cons that's part of the list. The end of a list is
    > marked by a cdr whose value is nil.


    Addition: This can also be implemented very neatly in Perl by using
    two element array references as 'cons cells', toy example

    -----------
    sub car
    {
    return $_[0][0];
    }

    sub cdr
    {
    return $_[0][1];
    }

    sub list
    {
    @_ && [shift, &list];
    }

    $l = list(0 .. 100);
    while ($l) {
    print(car($l), ' ');
    $l = cdr($l);
    }
    print("\n");
    -----------

    and for algorithms which are well-suited for linked lists, this can
    even outperform (when suitably implemented) an equivalent algorithm
    using arrays.
     
    Rainer Weikusat, Apr 9, 2012
    #14
  15. Xah Lee

    BartC Guest

    "Shmuel (Seymour J.)Metz" <> wrote in
    message news:4f8410ff$2$fuzhry+tra$...
    > In <>, 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 scanning an existing string; think of
    > constructing a string. The null only indicates the current length, not
    > the amount allocated.
    >
    >>If a length field in front of string data is incorrect, we also have
    >>a buffer overrrun.

    >
    > The languages that I'm aware of that use a string length field also
    > use a length field for the allocated storage. More precisely, they
    > require that attempts to store beyond the allocated length be
    > detected.


    I would have thought trying to *read* beyond the current length would be an
    error.

    Writing beyond the current length, and perhaps beyond the current allocation
    might be OK if the string is allowed grow, otherwise that's also an error.

    In any case, there is no real need for an allocated length to be passed
    around with the string, if you are only going to be reading it, or only
    modifying the existing characters. And depending on the memory management
    arrangements, such a length need not be stored at all.

    --
    Bartc
     
    BartC, Apr 10, 2012
    #15
  16. Shmuel (Seymour J.) Metz <> writes:
    > In <>, 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 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) was already
    explained elsewhere.
     
    Rainer Weikusat, Apr 10, 2012
    #16
  17. Xah Lee

    WJ Guest

    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, up to a point:

    C:\>cd info/source

    C:\info\source>


    Also, most languages I use under windows allow you to use
    slashes in paths:

    C:\>ruby -e "puts IO.read( 'c:/info/frag' )"
    275439
    109999
    102972
    109999
    102972
    110000
    102972
    109999

    101085
    108111
     
    WJ, Apr 11, 2012
    #17
  18. Xah Lee

    Kaz Kylheku Guest

    ["Followup-To:" header set to comp.lang.lisp.]
    On 2012-04-11, Shmuel Metz <> wrote:
    > In <>, 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 there's a 'special
    >>termination value' instead of an explicit length)

    >
    > A syringe is similar to a sturgeon in the sense that they both start
    > with S. LISP doesn't have arrays, and C doesn't allow you to insert
    > into the middle of an array.


    Lisp, however, has arrays. (Not to mention hash tables, structures, and
    classes). Where have you been since 1960-something?

    (let ((array #(1 2 3 4)))
    (aref array 3)) ;; -> 4, O(1) access
     
    Kaz Kylheku, Apr 11, 2012
    #18
  19. Shmuel (Seymour J.) Metz <> writes:
    > In <>, 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 there's a 'special
    >>termination value' instead of an explicit length)

    >
    > A syringe is similar to a sturgeon in the sense that they both start
    > with S.


    And the original definition of 'idiot' is 'a guy who cannot learn
    because he is too cocksure to already know everything'. Not that this
    would matter in the given context ...

    > LISP doesn't have arrays,


    Lisp has arrays.

    > and C doesn't allow you to insert
    > into the middle of an array.


    Well, of course it does: You just have to move the content of all
    memory cells 'after' the new insert 'one up'. But unless I'm very much
    mistaken, the topic was "first and rest" (car and cdr), as the terms
    could be used with a C string and not "whatever Shmuel happens to
    believe to know" ...
     
    Rainer Weikusat, Apr 11, 2012
    #19
  20. Shmuel (Seymour J.) Metz <> writes:

    > In <>, 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 there's a 'special
    >>termination value' instead of an explicit length)

    >
    > A syringe is similar to a sturgeon in the sense that they both start
    > with S. LISP doesn't have arrays, and C doesn't allow you to insert
    > into the middle of an array.


    You're confused. C doesn't have arrays. Lisp has arrays.
    C only has vectors (Lisp has vectors too).

    That C calls its vectors "array", or its bytes "char" doesn't change the
    fact that C has no array and no character.


    cl-user> (make-array '(3 4 5) :initial-element 42)
    #3A(((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42))
    ((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42))
    ((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42)))

    cl-user> (make-array 10 :initial-element 42)
    #(42 42 42 42 42 42 42 42 42 42)



    --
    __Pascal Bourguignon__ http://www.informatimago.com/
    A bad day in () is better than a good day in {}.
     
    Pascal J. Bourguignon, Apr 11, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    763
  2. Paul Moore
    Replies:
    0
    Views:
    639
    Paul Moore
    Mar 1, 2008
  3. Martin v. Löwis
    Replies:
    0
    Views:
    681
    Martin v. Löwis
    Mar 1, 2008
  4. Senthil Kumaran
    Replies:
    0
    Views:
    594
    Senthil Kumaran
    Jan 17, 2011
  5. R. David Murray
    Replies:
    0
    Views:
    783
    R. David Murray
    Jan 17, 2011
Loading...

Share This Page