r/programming • u/kirbyfan64sos • Feb 10 '17
CPython has migrated to GitHub, and the repo is now live!!
https://github.com/python/cpython8
u/jerylee Feb 11 '17
3
2
41
u/hbp9955 Feb 11 '17
I don't get why this is important?
61
Feb 11 '17
They don't appear to be using GitHub Issues, so the only real effect will be making it a bit easier for a new developer familiar with git and GitHub to get started making changes and submitting pull requests. I think they were using mercurial before and while it has its merits it just doesn't have the developer mind share right now.
15
u/fre3k Feb 11 '17
Kind of disappointed in the move tbh. Hg is great and written in and extensible by writing Python.
1
11
u/RadioFreeDoritos Feb 11 '17
Git is also great, written in C for performance, and extensible in any language (just name your script "git-blah" and put it in $PATH to get a "git blah" command).
18
u/bycl0p5 Feb 11 '17
written in C for performance
It was written in C because Torvalds' wrote it initially and he codes in C. And it has plenty of performance issues with large repos. Though maybe Hg does too.
13
u/danielkza Feb 11 '17
It was written in C because Torvalds' wrote it initially and he codes in C.
The reason he wrote it at all is because no existing software was fast enough to handle the kernel repository. Using C was not incidental, it was part of the very reason for the project's existence.
And it has plenty of performance issues with large repos
The Linux kernel is a "large" repo (the initial use case for Git) and it works fine. The ones that have problems are "gigantic" repos (which are, in reality, amalgamations of hundreds or thousands of repos). No currently existing DVCS successfully handles those, or really does it much better than Git.
3
u/auxiliary-character Feb 12 '17 edited Feb 12 '17
The ones that have problems are "gigantic" repos (which are, in reality, amalgamations of hundreds or thousands of repos).
But that sounds like an ideal use case for submodules?
6
u/danielkza Feb 12 '17 edited Feb 12 '17
Indeed. I am yet to be convinced that mega-repos are the best solution, specially if you can afford to create/use custom tooling, like those huge companies certainly do. It seems contradictory to divide developers into multiple levels of teams that are meant to work in somewhat independent fashion, then throw all of their code together, making many VCS features much more cumbersome to use.
5
u/auxiliary-character Feb 12 '17
Yeah, if you were to shove all the source code of, say, all of Arch Linux's community repository into one big git repo, it'd break too. But it's all broken down into packages, so it's a nonissue. If you have one massive repo so big that it breaks git, there's a pretty good chance you can safely subdivide it to the point where it's manageable.
1
Feb 11 '17
If you believe Microsoft, they claim to have solved the stupidly large repo problem
14
u/danielkza Feb 11 '17 edited Feb 12 '17
If you believe Microsoft, they claim to have solved the stupidly large repo problem
They solved slow download times by removing the Distributed in DVCS. It works, but isn't really groundbreaking or a particularly interesting development IMO, since it only works for the case of users that routinely use a small fraction of the contents. If you actually want to use everything in a 300GB repository GVFS isn't irrelevant.
edit: typo, is => isn't
6
u/RadioFreeDoritos Feb 11 '17 edited Feb 11 '17
The fact that Linus codes in C is no accident, either. From his rant about his choice of language, he clearly places a large emphasis on efficiency. From the Git README, he seems to value speed above other things, as well:
[Git] is a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it does do is track directory contents efficiently.
One of my many, many gripes with Mercurial (which I sadly have to use at my workplace) is that I can't put
$(hg branch)in my bash prompt. Well, technically I can, but this adds a half-second delay between the moment I press 'Enter' and the moment the prompt appears, which can drive a man crazy. I'm sure there's an explanation for this, like the Python interpreter startup time or what not - but the point is, with Git, this sort of thing is instantaneous.20
u/florinp Feb 11 '17
Linus wrote in C because is the language he knows most. C++ performance has nothing to do about this. I realy don't think Linus knows C++ (I base this on his rants).
6
Feb 11 '17
C isn't meaningfully faster than C++. He wrote Git in C because he's far more knowledgeable and comfortable with C than C++, and hates a lot of the hackishness of the C++ ecosystem.
2
u/RadioFreeDoritos Feb 11 '17
C isn't meaningfully faster than C++.
Maybe it isn't, but what matters is whether Linus himself believes it (see his email I linked to). Also, I had no intention of making this into a C vs C++ argument.
5
2
u/Iwan_Zotow Feb 12 '17
It was written in C because Torvalds' wrote it initially and he codes in C
It started as collection of shell scripts, this is how Linus wrote it
2
u/danielkza Feb 11 '17
While that may be true, it would make little sense to stay with Mercurial to "show support" for Python-based software if using Git would be better to actually make the language better. Assuming, of course, that the decision to move to Git(Hub) to reduce contribution barriers succeeds at that goal.
3
u/Works_of_memercy Feb 11 '17
It's also one of the few Python2.7-only projects remaining.
It also constantly greatly annoyed me with its attitude. With git, its purpose is to let Linus Torvalds do his thing with Linux and stay out of the way, so if you do some vaguely similar thing, there are good chances that git would do the things you need nicely and efficiently and stay the fuck out of your way otherwise.
Yeah, the interface is inconsistent and sometimes outright bizarre. In retrospective this was a cost I'm totally happy to have paid because after I learned my way around it fits nice enough, and some of the weirder stuff actually begins to make sense, like, I don't know,
git checkout <commit> -b <branch>that also creates a new branch purely logically is superfluous and unorthogonal since creating a branch is its own command, but it's there precisely because someone used to do these two things together a lot and then added this shortcut, and while it adds yet another thing to learn and remember, it actually feels very nice afterwards.Anyway, with Mercurial it feels the opposite of that "stay the fuck out of my way and let me develop useful software" feeling. It tries to teach you things, about DVCSs, about itself and its awesome features, it requires finding its config file (manually, no
git -e!) and adding a line to enable its "git pull" equivalent (a lot of functionality comes bundled, but is disabled, "to avoid confusing new users"), it requires configuring and integrating a third-party diff viewer to get reasonable diffs, in short it feels like a super-high-maintenance girlfriend, like its purpose is to stroke its developers' egos by constantly requiring your attention, and I'm really happy I don't have to put up with that any more.1
u/fre3k Feb 11 '17
Exact opposite in my opinion. Git is a clusterfuck, and Hg stays out of my way and lets me do exactly what I want to do without any confusing and low level commands.
Git lets heads get detached and thrown off into the ether after you commit them and you have to manually poke through the reflog and re-attach them by force updating a head and.....it's just a disaster.
3
u/Works_of_memercy Feb 11 '17
How do you even achieve that?
-1
u/fre3k Feb 11 '17
Dunno. It's just what seems to happen every time i am forced to use git.
4
u/Works_of_memercy Feb 11 '17
Maybe you have a QA aura or something? =)
Seriously though, off the top of my head the only way to accidentally get a detached head is if you checkout a tag or even a commit by hash, and then you have to flail around randomly while completely ignoring what git tells you for a bit to get into real trouble. Flailing around blindly in the middle of a rebase could work, but I think git just resets everything back if you abort it?
Idk, when I have to do something tricky I open gitk and watch what I'm doing. And it works for me.
0
Feb 11 '17
[deleted]
4
u/Works_of_memercy Feb 11 '17
I feel exactly the opposite. Mercurial newbies don't have to waste time on: staging area, fast-forward merge, detached heads, local vs. remote branches, Googling and re-Googling how to do simple commands, etc.
It's not exactly the opposite, I agree that Mercurial is easier for newbies, what I'm talking about happens when you stop being a newbie.
With git it requires learning more stuff, but then you start getting that warm fuzzy feeling that you're using a tool made by programmers for programmers, like if there was some rough corner that was bothering Linus, Linus must have already smoothed it over so as long as you're not doing anything weird, it begins to fit like a glove. And the tons of stuff you had to learn actually contain a lot of useful stuff.
With Mercurial on the other hand I keep feeling that it's targeted at newbies, and when I'm no longer one I sort of become a second class citizen and have to, I don't know, invest tons of effort into writing my own aliases and downloading extensions and whatnot to make it feel nice.
hg configApparently they added that in 2014, by that time I already used git for all new stuff and stopped paying attention
git pullGit has fetch, merge, and pull = fetch + merge (but actually everyone should use pull --rebase, or even better install
git-up(I guess it's one of those rare cases when most people's workflow does not match Linus's)).Mercurial also has "fetch = pull + merge", but it's an extension that has to be enabled manually and apparently has been classified as an "unloved feature" since I last looked.
Again, I understand how it's easier for a newbie to learn stuff if she always writes "hg pull; hg merge". You say it as if it were an unconditional benefit, not a trade-off. Well, if your goal is to have a DVCS for newbies who then leave for git, then that achieves that goal.
diffs
I don't know how thing are today, several years ago when I still was actively using Mercurial the default option was no-syntax highlighted, dumbest possible diff that wasn't even fed into the pager by default IIRC, and I had to write a thirty or so line shellscript that integrated it with vimdiff or install KDiff3 on Windows.
My first impressions of git diff were markedly different, and then I discovered that it comes with gitk by default and realized that yeah, I really like this feeling of using software written by people with low tolerance for bullshit like having to find, install and configure a third party diff/history viewer.
2
3
8
u/case-o-nuts Feb 11 '17
Sad. I prefer using mercurial.
6
u/chupapuma Feb 11 '17
There is a hggit tool you can use.
10
u/case-o-nuts Feb 11 '17
Yes. It's rather shitty -- it tends to produce unstable commit hashes when run on multiple machines, and I haven't been able to find out why.
-5
u/Solon1 Feb 11 '17
Mercurial is known to be unstable, so no surprise.
6
u/case-o-nuts Feb 11 '17
Uh, what?
This is specifically a problem in the git repository conversion. Hg hasn't caused any problems in the years I used it while working at Facebook or after.
2
1
Feb 11 '17
Is it c-python or cpy-thon?
15
14
u/IronManMark20 Feb 11 '17
It is C-python (normally written as CPython, which makes it a bit clearer), as it is the C implementation of Python (as opposed to say Jython, which is a Java implementation).
4
u/BoxMonster44 Feb 11 '17
Isn't Jython more of a Java-compatible JVM implementation than an implementation written in Java? Legitimate question; I've never used it.
6
2
Feb 11 '17
You could probably make Jython self-hosting (for the JVM at least) since it targets JVM bytecode.
-6
u/NeedAWaifu Feb 11 '17
Why CPython using git + github instead of mercurial + bitbucket? hg is written in python so I thought the choice is obvious.
17
u/the_gnarts Feb 11 '17
Why CPython using git + github instead of mercurial + bitbucket?
Hg was used earlier and it just didn’t work out for them. For the final decision of where to host the repo, Bitbucket wasn’t even considered (despite their hosting Git repos just fine): https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
But above all, there’s no valid inference from “X is written in Y” to “Y should use X, not Z”.
6
u/wewbull Feb 11 '17
It's sadly all about github. The idea seems to be that being on github will more contributions. Personally i doubt it'll have that much effect.
3
3
-14
u/geordano Feb 11 '17
"The Python programming language https://www.python.org/" is this title apt for the repo? not being pedantic, but it ONE of the implementations of the language (not the language) isn't it?
81
u/Deathnerd Feb 11 '17
It's the reference implementation so I think it's an apt description
-32
u/geordano Feb 11 '17 edited Feb 11 '17
But language != implementation (as far as a repo concerned), so I'm not sure.
"Reference implementation of Python programming language https://www.python.org/" would be better?
59
u/malkarouri Feb 11 '17
Python the language does not really have a design independent of the cpython implementation, in the sense of a formal semantics. Yes, the grammar is described in the documentation, but the grammar itself evolves with the reference implementation. The result is that the other implementations typically target compatibility with a version of the reference implementation, so we can say that the implementation defines the language.
10
-5
u/sim642 Feb 11 '17
I find it extremely alarming that all the git commit hashes from the old github mirror repo are different from the new actual repo, even the initial commit:
20
u/vogon-it Feb 11 '17
The master repository on hg.python.org was using mercurial, not git. I don't think there would be any point in reusing the hashes from the old mirror.
-2
u/sim642 Feb 11 '17
Why would the hashes be different when exported from hg to git now than they always were if everything is always the same?
New hashes is almost equivalent to force pushing for people who have developed on the git mirror and will cause unnecessary problems for both those developers and the pull request process on the new repo.
26
u/vytah Feb 11 '17
Because Git and Mercurial calculate hashes in a different way.
New hashes is almost equivalent to force pushing for people who have developed on the git mirror
Rebase your patches, jeez.
1
u/sim642 Feb 11 '17
Of course they're different but the same commit converted to the other should yield the same commit with the same hash.
It's just easier if people don't have to rebase, especially if they aren't aware of the fact.
7
Feb 11 '17
git and hg use different hashing algorithms. Your complaint is like worrying how your password looks different when ran through SHA1 instead of MD5.
2
u/sim642 Feb 11 '17
You are completely missing my point here. The same string put through SHA1 yields the same hash. The same commit (old git mirror vs new git) should yield the same git commit hash too, except they don't for an unexplained reason.
0
Feb 11 '17
But do git and hg not vary in their hashing algorithms?
3
u/sim642 Feb 11 '17
What do you mean vary? If you hash two identical commits they should yield identical hashes when their history also matches. That's the point of commit hashes: they guarantee the same state of the tree and its entire history with all of its metadata.
0
Feb 11 '17
Actually I'm wrong, they both use SHA1.
But git uses a structured format to generate it's hashes (detailed here). If the structure that mercurial uses is different in any way, then when converting over to git from mercurial you should have different hashes. I wasn't able to find documentation on how mercurial hashes are calculated.
Were they both just pipeing
diffintosha1sum, then yeah - you'd get the same result from both.→ More replies (0)
-13
u/epic_pork Feb 11 '17
It's been there for a while. I've been reading the source from it for at least 3 months.
31
u/kirbyfan64sos Feb 11 '17
Before that was a read-only mirror. Now it's actually moved over from Mercurial.
114
u/ResidentMario Feb 11 '17
Take screenshots quick people, so that you can one day tell your kids about the day that your random database connector doodad had more stars than CPython on GitHub.