Why does Python never add itself to the Windows path?

Discussion in 'Python' started by Ben Sizer, Dec 25, 2006.

  1. Ben Sizer

    Ben Sizer Guest

    I've installed several different versions of Python across several
    different versions of MS Windows, and not a single time was the Python
    directory or the Scripts subdirectory added to the PATH environment
    variable. Every time, I've had to go through and add this by hand, to
    have something resembling a usable Python installation. No such
    problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    Kubuntu. So why is the Windows install half-crippled by default? I just
    rediscovered this today when trying to run one of the Turbogears
    scripts, but this has puzzled me for years now.

    --
    Ben Sizer
    Ben Sizer, Dec 25, 2006
    #1
    1. Advertising

  2. Ben Sizer

    vbgunz Guest

    Ben Sizer wrote:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable. Every time, I've had to go through and add this by hand, to
    > have something resembling a usable Python installation. No such
    > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > Kubuntu. So why is the Windows install half-crippled by default? I just
    > rediscovered this today when trying to run one of the Turbogears
    > scripts, but this has puzzled me for years now.
    >
    > --
    > Ben Sizer


    excellent question
    vbgunz, Dec 25, 2006
    #2
    1. Advertising

  3. Ben Sizer

    Guest

    I don't seem to have any problem running python programs regardless of
    where they are. My platform is windows xp and I have run both 2.4 and
    2.5 more details about what version of windows you are running might be
    helpfull

    https://sourceforge.net/project/showfiles.php?group_id=156455&package_id=174569

    vbgunz wrote:
    > Ben Sizer wrote:
    > > I've installed several different versions of Python across several
    > > different versions of MS Windows, and not a single time was the Python
    > > directory or the Scripts subdirectory added to the PATH environment
    > > variable. Every time, I've had to go through and add this by hand, to
    > > have something resembling a usable Python installation. No such
    > > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > > Kubuntu. So why is the Windows install half-crippled by default? I just
    > > rediscovered this today when trying to run one of the Turbogears
    > > scripts, but this has puzzled me for years now.
    > >
    > > --
    > > Ben Sizer

    >
    > excellent question
    , Dec 25, 2006
    #3
  4. Ben Sizer

    MC Guest

    Hi!

    +1

    --
    @-salutations

    Michel Claveau
    MC, Dec 25, 2006
    #4
  5. Ben Sizer

    Ross Ridge Guest

    Ben Sizer wrote:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable.


    Personally, I hate Windows applications that add themselves to the
    PATH. So much crap gets put in there that I don't even use the default
    system PATH and just set my own explicitly.

    > Every time, I've had to go through and add this by hand, to
    > have something resembling a usable Python installation.


    If you're installing multiple versions of Python on one machine you're
    going to have to do this anyways to ensure the version of Python you
    want first in the path actually is first.

    > No such problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > Kubuntu.


    Linux distributions normally install themselves somewhere that's
    normally in the path already. I suppose you can do the same thing on
    Windows if you want, just choose to install Python into directory
    that's already in your path. Though installing to something like
    C:\WINDOWS\SYSTEM32 is probably not a good idea.

    Ross Ridge
    Ross Ridge, Dec 25, 2006
    #5
  6. Ben Sizer

    Ben Sizer Guest

    wrote:

    > I don't seem to have any problem running python programs regardless of
    > where they are. My platform is windows xp and I have run both 2.4 and
    > 2.5 more details about what version of windows you are running might be
    > helpfull


    I don't think the Windows version is relevant. I did point out that
    this happens across different incarnations of Windows (98SE and XP the
    2 I have on hand to test), and that the problem wasn't specifically
    about "running python programs". Basically if you go to a command
    prompt and type "python", it won't do anything on a plain Python
    install on Windows. Try it on Linux, and probably Mac too, and it'll do
    something useful.

    Similarly, if you install a Python package that adds to the scripts
    directory, you can typically expect to run those scripts from the
    command line without having to use the full path - not on Windows.

    --
    Ben Sizer
    Ben Sizer, Dec 25, 2006
    #6
  7. Ben Sizer

    Ben Sizer Guest

    Ross Ridge wrote:
    > Ben Sizer wrote:
    > > I've installed several different versions of Python across several
    > > different versions of MS Windows, and not a single time was the Python
    > > directory or the Scripts subdirectory added to the PATH environment
    > > variable.

    >
    > Personally, I hate Windows applications that add themselves to the
    > PATH. So much crap gets put in there that I don't even use the default
    > system PATH and just set my own explicitly.


    Personally I hate programs that ask to be installed to the root folder
    of my hard drive, but Python suggests that as a default too. ;)

    In an ideal world, Python should operate pretty much the same across
    all platforms. Unfortunately, as it stands, you need to have different
    instructions for running things on Windows. eg. The standard "python
    setup.py install" invocation isn't going to do a damn thing unless
    you've fixed up the path beforehand. The same goes for "python
    ez_setup.py", another common favourite. The scripts directory is
    important too: TurboGears installs a "tg-admin" script which you're
    supposed to run from your project's directory: which on Windows means
    you need to type something like "c:\python24\scripts\tg-admin" each
    time. Half of the people who develop on Mac and Linux don't realise or
    acknowledge this. and so the instructions for using their packages
    don't work for the average person new to Python who probably just ran
    the Windows installer program and thought that would suffice.

    > Linux distributions normally install themselves somewhere that's
    > normally in the path already. I suppose you can do the same thing on
    > Windows if you want, just choose to install Python into directory
    > that's already in your path. Though installing to something like
    > C:\WINDOWS\SYSTEM32 is probably not a good idea.


    The Windows way is typically to install things in Program Files and
    then point things there as necessary. Installing it the Linux way would
    just cause a different set of problems. Adding it to the PATH variable
    is not going to cause problems for the vast majority of people, and
    it's far easier to edit up the PATH to remove an entry you don't want,
    than to move an installed program from one place to another.

    --
    Ben Sizer
    Ben Sizer, Dec 25, 2006
    #7
  8. Ben Sizer

    WaterWalk Guest

    Ben Sizer wrote:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable. Every time, I've had to go through and add this by hand, to
    > have something resembling a usable Python installation. No such
    > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > Kubuntu. So why is the Windows install half-crippled by default? I just
    > rediscovered this today when trying to run one of the Turbogears
    > scripts, but this has puzzled me for years now.
    >


    Well, after Python is installed on a Windows platform, files with
    extention ".py" or ".pyw" are automatically associated with python or
    pythonw. If a python script is double-clicked or input something like
    "sth.py" in the "cmd" box, the python interpreter is automatically
    called. I don't see any proplem or inconvenience with this.
    WaterWalk, Dec 26, 2006
    #8
  9. Ben Sizer

    Dustan Guest

    WaterWalk wrote:
    > Ben Sizer wrote:
    > > I've installed several different versions of Python across several
    > > different versions of MS Windows, and not a single time was the Python
    > > directory or the Scripts subdirectory added to the PATH environment
    > > variable. Every time, I've had to go through and add this by hand, to
    > > have something resembling a usable Python installation. No such
    > > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > > Kubuntu. So why is the Windows install half-crippled by default? I just
    > > rediscovered this today when trying to run one of the Turbogears
    > > scripts, but this has puzzled me for years now.
    > >

    >
    > Well, after Python is installed on a Windows platform, files with
    > extention ".py" or ".pyw" are automatically associated with python or
    > pythonw. If a python script is double-clicked or input something like
    > "sth.py" in the "cmd" box, the python interpreter is automatically
    > called. I don't see any proplem or inconvenience with this.


    In the command line, entering "python" does not run the python
    interpreter (unless you modify the settings yourself).
    Dustan, Dec 26, 2006
    #9
  10. Ben Sizer

    robert Guest

    Ben Sizer wrote:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable. Every time, I've had to go through and add this by hand, to
    > have something resembling a usable Python installation. No such
    > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > Kubuntu. So why is the Windows install half-crippled by default? I just
    > rediscovered this today when trying to run one of the Turbogears
    > scripts, but this has puzzled me for years now.
    >


    That would put together a great mix-up if app installations add to the PATH. Think of multiple installations etc.
    ( Note: this is also _NOT_ done on *nix - just a sym link is possibly put into /usr/local/bin or so )

    To have something similar on Win I have a C:\bin folder where I put all my small .exe's / installations and all the start vectors (.exe, .bat's....).

    The python.exe on Win is very small and just loads the pythonXX.dll. It also finds the right default DLL due to the version engraved in python.exe.
    Thus I just copy the small python.exe from my favorite/default Python installation (2.3) into my C:\bin.
    Thats probably next to what you obviously want - a "default link".
    The Test&Fun-Pythons ( ... 2.2 2.4 2.5 2.6 ) - I have them renamed as e.g. python25.exe also in C:\bin . I make similar links on *nix also.

    Perhaps in the future the Python Windows installer should create such pythonXX.exe "links" and maybe even a default python.exe (upon Checkbox in Installer!) into the Windows\system32 ?


    Robert
    robert, Dec 26, 2006
    #10
  11. Ben Sizer

    Guest

    Ross Ridge wrote:
    > Ben Sizer wrote:
    > > I've installed several different versions of Python across several
    > > different versions of MS Windows, and not a single time was the Python
    > > directory or the Scripts subdirectory added to the PATH environment
    > > variable.

    >
    > Personally, I hate Windows applications that add themselves to the
    > PATH. So much crap gets put in there that I don't even use the default
    > system PATH and just set my own explicitly.


    Agreed. A good Windows application minimizes its footprint, only
    adding registry keys, environment variables, system tray icons,
    services, shell extensions, etc, etc, when absolutely necessary.
    Python is such an application.

    But on the other hand, I use Python on the Windows command line all the
    time. Having to manually set PATH for each machine I use Python on is
    a minor annoyance.

    One solution would be an optional feature on the MSI to prepend the
    install directory to PATH. In fact, this is what ActivePython does.
    Any reason why the official Python distribution shouldn't?

    --Ben Cartwright
    , Dec 26, 2006
    #11
  12. Ben Sizer schrieb:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable. Every time, I've had to go through and add this by hand, to
    > have something resembling a usable Python installation. No such
    > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > Kubuntu. So why is the Windows install half-crippled by default?


    For several reasons:
    1. Python can be used just fine without being on PATH. Python
    scripts run fine both when double-clicked and when invoked in
    the command line, and if you want to use an interactive
    interpreter, you can find it readily on the Start menu.
    2. Many windows users (including myself) dislike setup routines that
    manipulate PATH. I believe that the PATH environment variable
    is "owned" by the user; if Python is to be found in PATH, it
    should rather be installed to a directory that is known to live
    on PATH (or where CreateProcess searches, anyway, such
    as system32). So if the installer had such a feature, it should
    be optional, and it should default to "off".
    3. Most importantly: it is difficult to implement, and nobody has
    contributed code to make it work.

    Regards,
    Martin
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Dec 30, 2006
    #12
  13. Ben Sizer wrote:

    >I've installed several different versions of Python across several
    >different versions of MS Windows, and not a single time was the Python
    >directory or the Scripts subdirectory added to the PATH environment
    >variable. Every time, I've had to go through and add this by hand, to
    >have something resembling a usable Python installation. No such
    >problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    >Kubuntu. So why is the Windows install half-crippled by default? I just
    >rediscovered this today when trying to run one of the Turbogears
    >scripts, but this has puzzled me for years now.
    >


    +1

    It is a pain for me because it is something I need to remember to do
    maybe once a year or less.

    It seems best practice with Windows is to throw away the machine every 2
    years - so much crap gets automatically installed in places and ways not
    solicited I'd think only cybermonks get away clean. That the Python
    install is a good citizen in this regard is noble, but does it really
    make a difference in regard to the overall Windows installation? And is
    that difference worth the recurring pain of not having Python on the
    path automatically?

    There must be hundreds of programs on the PATH of the machine I type on,
    its ugly. And lets not even talk about the Registry. Time to throw
    away the machine. That's what I get for being a cheap slut for any
    interesting program.


    Windows will never be UNIX, invest in penicillin.
    Eric Pederson, Dec 30, 2006
    #13
  14. Ben Sizer

    Ben Sizer Guest

    Martin v. Löwis wrote:

    > Ben Sizer schrieb:
    > > I've installed several different versions of Python across several
    > > different versions of MS Windows, and not a single time was the Python
    > > directory or the Scripts subdirectory added to the PATH environment
    > > variable. Every time, I've had to go through and add this by hand, to
    > > have something resembling a usable Python installation. No such
    > > problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
    > > Kubuntu. So why is the Windows install half-crippled by default?

    >
    > For several reasons:
    > 1. Python can be used just fine without being on PATH. Python
    > scripts run fine both when double-clicked and when invoked in
    > the command line, and if you want to use an interactive
    > interpreter, you can find it readily on the Start menu.


    Yet many scripts and applications require parameters, or to be executed
    from a certain directory. For example, setup.py. Or the various
    turbogears scripts. Or easy_install.

    > 2. Many windows users (including myself) dislike setup routines that
    > manipulate PATH.


    My opinion is that this is not as big a problem as some may feel that
    it is. Unlike Unix systems, the PATH variable is rarely used. Most
    applications are launched via the Start Menu, which uses absolute
    paths, or via file associations, also done via absolute paths. The
    chance of a naming collision only really arises when you start using
    the command line, which most people don't do.

    However, among those who will use the command line, are some people new
    to Python, who will come across instructions like this:

    <http://docs.python.org/inst/standard-install.html>

    "As described in section 1.2, building and installing a module
    distribution using the Distutils is usually one simple command:

    python setup.py install

    On Unix, you'd run this command from a shell prompt; on Windows, you
    have to open a command prompt window (``DOS box'') and do it there; "

    Pretty much none of the instructions in that part of the docs will work
    without you altering your path beforehand. Python's cross-platform
    nature means people rightly expect the same instructions to work on
    Linux and Windows from a standard installation. Right now, they don't.

    > if Python is to be found in PATH, it
    > should rather be installed to a directory that is known to live
    > on PATH (or where CreateProcess searches, anyway, such
    > as system32). So if the installer had such a feature, it should
    > be optional, and it should default to "off".


    It's a lot more anti-social to install to system32 than to modify the
    PATH variable. How easy is it to temporarily undo an installation to a
    system directory like that? What if you still want Python in your path
    but with less precedence than some other user directory?

    > 3. Most importantly: it is difficult to implement, and nobody has
    > contributed code to make it work.


    There appears to be a freely-available binary at this address that may
    suffice:
    http://legroom.net/modules.php?op=modload&name=Open_Source&file=index&page=software&app=modpath

    --
    Ben Sizer
    Ben Sizer, Dec 31, 2006
    #14
  15. Ben Sizer

    vbgunz Guest

    Ben Sizer wrote:
    > I've installed several different versions of Python across several
    > different versions of MS Windows, and not a single time was the Python
    > directory or the Scripts subdirectory added to the PATH environment
    > variable.


    I don't understand what all the fuss is about. Add a single page to the
    installer and on it, have 3 radio buttons. The choices could be "add to
    path (recommended)", "add to path with version", "do not add to path
    (not recommended)". On a brand new installation or if the user is
    upgrading, "add to path (recommended)" should automatically be
    selected. If the user is downgrading, "add to path with version" could
    be the default selection? If a user truly does not want the Python
    installation to touch the path, they'll know to select "do not add to
    path (not recommended)" and it's the end of the story, everyone is
    happy... It doesn't even have to be like this *but* why not help add
    the install to the path?

    I haven't used Windows in quite a while but I've done several
    installations across some of the family boxes and some inside some
    virtual machines and every time I tried launching python through a
    console I temporarily got stunned with an error. I just forget and wish
    the install could at least remind me. No problem, I know how to add the
    path so no biggie at all. Some if not most python documentation assumes
    Python is on the path... Anyhow, I don't get why it doesn't apply by
    default in some way on Windows even if at the least it could be a
    simple reminder or tip to do so.
    vbgunz, Dec 31, 2006
    #15
  16. Ben Sizer

    Tom Plunket Guest

    vbgunz wrote:

    > I don't understand what all the fuss is about. Add a single page to the
    > installer and on it, have 3 radio buttons.


    I don't understand what the fuss is about, and would not give that
    recommendation based on my not understanding it!

    I have never ever needed or wanted to launch the python interactive
    interpreter from a command-line. IPython is what I want to use when I'm
    going interactive, and running scripts from the command-line works just
    fine with Windows's file associations.

    > Some if not most python documentation assumes Python is on the path...


    Really? I must live in different places in the docs, but I can't recall
    encountering any such documentation.

    > Anyhow, I don't get why it doesn't apply by default in some way on
    > Windows even if at the least it could be a simple reminder or tip to do
    > so.


    Users who want it in their paths are certainly capable of putting it
    there. I am in the camp that detests apps that automatically install
    tons of crap everywhere without prompts. Certainly, though, the
    suggestion that one pane in the installer offer to put it in the path
    would leave the default as it is today ("don't edit PATH"), though,
    right? Doesn't make a whole lot of sense to add a new option and
    default it to something completely different from the old behavior, does
    it?


    -tom!

    --
    Tom Plunket, Jan 1, 2007
    #16
  17. Ben Sizer

    robert Guest

    Ben Sizer wrote:
    > Martin v. Löwis wrote:
    >
    >> 2. Many windows users (including myself) dislike setup routines that
    >> manipulate PATH.

    >
    > My opinion is that this is not as big a problem as some may feel that
    > it is. Unlike Unix systems, the PATH variable is rarely used. Most


    It is a big problem.

    It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions.
    This would create funny PATH variables - almost a "psychic behavior with history".

    I'd vote heavily against manipulating the PATH.

    Example: Just recently I had a lot of magical version problems with Borland stuff installers which by default and without question or noticeable checkboxes add naively (and multiple folders) to the PATH. And there were not just version mix-up problems - even things with same names of the C++ and the Pascal compilers and even stuff from old 16bit compilers wanted to deal with each other...

    "Default Links" - generally speaking - are by far better than PATHs regarding application level stuff.


    >> if Python is to be found in PATH, it
    >> should rather be installed to a directory that is known to live
    >> on PATH (or where CreateProcess searches, anyway, such
    >> as system32). So if the installer had such a feature, it should
    >> be optional, and it should default to "off".

    >
    > It's a lot more anti-social to install to system32 than to modify the
    > PATH variable. How easy is it to temporarily undo an installation to a
    > system directory like that? What if you still want Python in your path
    > but with less precedence than some other user directory?


    Uninstallation would be same as for the pythonXX.dll.

    A python(XX).exe next to the DLL would just be a natural consequence - the DLL already defined the policy. python.exe is nothing else than a DLL loader.

    Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so...

    If one really wants multi user separate installations that clean, it is all necessary to create oneself something like ....\<user>\bin <user>\system32. Yet not different from Linux: a ~\bin on the PATH would be custom with most *unix default layouts also.
    Dealing with less and more precedence / PATH order is about the same issue : you have by far crossed the line from where you have to set yourself the PATH consciously.
    And multiple Python installers automatically establishing the right precedence on the PATH !? - with re.sub() :)

    Putting a pythonXX.exe next to pythonXX.dll into system32 should be a non-q and a kind of default comfort for multi-python users.
    Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most "compatible" to *nix.


    Robert
    robert, Jan 1, 2007
    #17
  18. Ben Sizer

    Ben Sizer Guest

    robert wrote:
    > Ben Sizer wrote:
    > > My opinion is that this is not as big a problem as some may feel that
    > > it is. Unlike Unix systems, the PATH variable is rarely used.

    >
    > It is a big problem.
    >
    > It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions.


    So you think most Python users have more than one version of Python
    installed? I disagree - but even if it is true, how come this isn't a
    big problem on Unix? Can you name a single distribution that doesn't
    install Python to the path?

    > This would create funny PATH variables - almost a "psychic behavior with history".


    It is quite trivial to see if Python is already on the path, and act
    differently based on that.

    > Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so...


    So... that's another reason why there's rarely a problem in setting
    that PATH variable.

    > Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most "compatible" to *nix.


    No, it doesn't : the /scripts directory is also important for many
    Python packages and that isn't addressed by shifting python.exe into
    system32.

    --
    Ben Sizer
    Ben Sizer, Jan 2, 2007
    #18
  19. Ben Sizer

    Ben Sizer Guest

    Tom Plunket wrote:
    > vbgunz wrote:


    > > Some if not most python documentation assumes Python is on the path...

    >
    > Really? I must live in different places in the docs, but I can't recall
    > encountering any such documentation.


    I have posted a few examples above: "Installing Python Modules"
    (http://python.org/doc/2.2.3/inst/inst.html) is a key example. 3rd
    party packages often expect you to type "python setup.py install".
    Setuptools/easyinstall will give you an 'easy_install' script, but then
    notes that you have to manually fix up the PATH yourself.

    > Users who want it in their paths are certainly capable of putting it
    > there.


    By that logic, users who want Python are probably capable of unzipping
    the archive and putting it somewhere semi-suitable. So why provide an
    installer?

    If you're going to provide an installer, it should do the whole job,
    and get Python in a state that is reasonably consistent across all
    platforms, where practical. Adding to the PATH variable isn't
    impractical.

    > I am in the camp that detests apps that automatically install
    > tons of crap everywhere without prompts.


    Why use hyperbole here? Is 13 or 14 bytes optionally added to a single
    environment variable "tons of crap"? And did anybody insist that the
    installer would have no prompts?

    > Certainly, though, the
    > suggestion that one pane in the installer offer to put it in the path
    > would leave the default as it is today ("don't edit PATH"), though,
    > right? Doesn't make a whole lot of sense to add a new option and
    > default it to something completely different from the old behavior, does
    > it?


    I have no problem with something being configurable, but I do have a
    problem with Windows users being forced to jump through unnecessary
    hoops that Unix and MacOS users don't have to endure. And I think the
    default should be to edit the PATH and allow you to explicitly disallow
    this: changing from the current behaviour is the right thing to do
    because the current behaviour is wrong, in terms of cross-platform
    compatibility and usability.

    --
    Ben Sizer
    Ben Sizer, Jan 2, 2007
    #19
  20. Ben Sizer

    Fuzzyman Guest

    Ben Sizer wrote:
    [snip..]
    > I have no problem with something being configurable, but I do have a
    > problem with Windows users being forced to jump through unnecessary
    > hoops that Unix and MacOS users don't have to endure. And I think the
    > default should be to edit the PATH and allow you to explicitly disallow
    > this: changing from the current behaviour is the right thing to do
    > because the current behaviour is wrong, in terms of cross-platform
    > compatibility and usability.
    >


    I strongly agree with these sentiments.

    Fuzzyman
    http://www.voidspace.org.uk/python/articles.shtml

    > --
    > Ben Sizer
    Fuzzyman, Jan 2, 2007
    #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. Soren Kuula
    Replies:
    1
    Views:
    439
    Henry S. Thompson
    Dec 1, 2005
  2. Kevin
    Replies:
    4
    Views:
    411
    Irrwahn Grausewitz
    Oct 17, 2003
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    861
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,761
    Smokey Grindel
    Dec 2, 2006
  5. Tzury Bar Yochay
    Replies:
    5
    Views:
    767
    Steven D'Aprano
    Oct 23, 2008
Loading...

Share This Page