0

I have thought that maybe (if this does not mean any inconvenience) I could modify Python's built-in code so I could add my custom functions, modules, classes so I don't have to import anything when I am coding. Kind of considering building my own version.

I suppose this has disadvantages, I'd like to know which ones.

qaztype
  • 73
  • 13
  • 1
    It sounds like a proper Python environment has not been established .. don't go changing the tooling, change the environment. It's much simpler and will do what you need - the only reason to modify Python's core is to *extended* the language at a core level, such as adding new syntax or modifying how the VM works .. – user2864740 Dec 26 '14 at 19:35
  • @user2864740 I do not consider it to be so. Maybe he wants to add a lot of functionalities that he could build his own version. Check my answer, please. –  Dec 26 '14 at 19:36
  • @JuanRocamonde Those should be implemented as modules - using the appropriate "C binding" if lower-level access is required. Only the core types in Python are "sealed" and I've yet to find a compelling reason to subvert that. – user2864740 Dec 26 '14 at 19:37
  • @user2864740 we do not know what he is actually trying to do. I suggest a further explanation by the OP. –  Dec 26 '14 at 19:38
  • 1
    @JuanRocamonde "..so I don't have to import anything when I am coding" - I think it is *safe to assume* (and I am certainly assuming such) that this is *not* an advanced case, but simply about an environment that can be optimized to minimize repetitive start-up behavior. – user2864740 Dec 26 '14 at 19:39
  • @user2864740 I agree with you. –  Dec 26 '14 at 19:41

2 Answers2

2

This is similar to an answer I wrote here:

Where is the PYTHONPATH defined in the first place?

That is not a good idea: you'd have to modify python's built-in code and libraries. I do not even know if they are compiled but if they weren't, even though you'd be able to modify the code (which I do not know if that is possible in the simple way we assume it) you would run into trouble:

  1. You may screw up any other part of the code by which python won't ever run and you won't ever know why
  2. Your application wouldn't be compatible with any other computer since you'd have to modify the package too.
  3. Even though you had a script modifying the package (so it is compatible) or even if you just ran it in a unique machine, you may not have enough system permissions to do so (in your case I suppose you do since I assume you are the machine's owner, but you may not)
  4. Most Python implementations do not have the raw source code available on-site. It's all compiled. So, you would need to go download the raw code and compile yourself, which is yet another problem.

I do not really recommend it, but if you still want to try, I hope someone may answer your question better than me.

I now add

Maybe if the modifications you want to add to the language are very consistent and so frequent that you can build your own version of Python that you can install anywhere and share with friends. As @user286474 pointed out there

It sounds like a proper Python environment has not been established .. don't go changing the tooling, change the environment. It's much simpler and will do what you need - the only reason to modify Python's core is to extended the language at a core level, such as adding new syntax or modifying how the VM works.-

I think he is right. Nevertheless, you may still want to modify the original content of Python to replace it with your custom stuff. I do not really recommend it. However, if you consider it appropriate, you can download the raw code of Python and compile it yourself. It is a hard but an interesting task.

Community
  • 1
  • 1
1

I don't think that avoiding the need to import modules is a good reason for building your own python version. Note that you can write a module "standard.py" containing:

import sys, math, os, ... # all the other modules you like to have handy

and then in your code you can just add one line

import * from standard

and then you can use for example

sys.argv

as if you imported sys in your script

6502
  • 112,025
  • 15
  • 165
  • 265
  • Please don't encourage this kind of thing. Explicit is better than implicit; if a module needs to access sys.argv, it should import sys. – Daniel Roseman Dec 26 '14 at 20:18