We Keep Coding

Why is Pygame so much slower than 2d game engines?

I am a godot user and a Python user. In pygame, in a simple game like pong, I had an average of 55-60 FPS in fullscreen. In addition, when ported to Kivy, I had an average FPS of 60-70FPS. But when I coded this in Godot, and got an average FPS of 180-200 in the viewport, while profiling! My program was extremely similar in both, and I wasn't static typing at all in Godot. Why is pygame so slow and is there anyway I can make it faster?

Godot is using OpenGL ES for drawing to the window. PyGame is based on SDL, which does not use hardware graphics primitives at all. You could also port your game to Kivy, which supports OpenGL ES too.
In terms of pushing pixels to the screen, graphics being drawn with a CPU Vs running on GPU is not a contest the CPU can ever win. That said, for a whole lot of game styles, PyGame is fast enough. There is absolutely no point updating the screen faster than the monitor is refreshing.
I would expect a basic Pong in PyGame to always run at full-FPS. On a huge high-DPI display, maybe even erasing the background is enough of a pixel-load to drop the FPS.

How can I get PyGame's fullscreen mode to scale consistently on different computers?

In short: With the same python script and the same monitor, using PyGame in fullscreen mode produces two different sized images on two different computers.
I am trying to run a PyGame script on two computers, and I need the images displayed to match each other in size on both computers. Each computer has the same monitor. Without using fullscreen, the PyGame windows (and so the images of the surfaces displayed) are the same size. When using
pygame.display.set_mode((width,height),pygame.FULLSCREEN)
The images are the same size on both computers when the ratio of (width,height) matches the aspect ratio of the native resolution of my monitor. If I use a combination that is not on that list, for instance in my case (1250, 850), the images on the screen are scaled differently for each computer. The computers are fairly similar, however they do not have the same graphics adapter.
In the PyGame documentation we can find
When requesting fullscreen display modes, sometimes an exact match for the
requested resolution cannot be made. In these situations pygame will select
the closest compatible match.
Is PyGame picking a different match for each computer?

Maybe you can use pygame.display.list_modes, this will tell you what resolutions of fullscreen are possible

To answer the title question: use a display mode resolution that is a commonly supported aspect ratio.
The difference lies in the graphics adapter. The list of supported resolutions given by pygame.display.list_modes() depends on the adapter. In particular, the next highest resolution above (1250,850) was different for each adapter, so PyGame's fullscreen used a different "closest compatible match" on each computer.

How to optimize tile rendering in pygame?

I am making a tile based game, and the map needs to be rendered every frame. Right now, each tile is 32X32, and the visible map is 28X28 tiles. The performance is dreadful. I recently made it only render the visible tiles, but this still did not improve the FPS much. Right now I'm looking for a way to speed up the rendering. I attribute the slowness to the way I am rendering ; every tile is individually blitted to the screen. What would be a more effective was of doing this?

In pygame (afaik), updating the screen is always one hell of a bottle neck. Since I could not see your code, I don't know, how you are updating the screen. Only blitting the the sprites that changed is a start, but you need to only update those parts that changed, on the screen.
Basically it is the difference between using display.flip() or using update_rects() with only the changed rects. I know, that does not help at all, when you are scrolling the map.
Take a look at this question: Why is this small (155 lines-long) Pacman game on Python running so slow?, it has a similiar topic.
One thing I tried when I had a map compiled of tiles and some sprites on it, I tried always having a precompiled image of the map for an area containing the currently displayed part and some 200 or so pixels around that, so that I could blit the prepared "ground" (still only in updated parts) without the need of blitting all those tiles contained in it. That, of course, is quite some thinking you have to put into that, espacially if you have multiple layers and parts of the map that can be above your active sprites. It is interesting to think and work that through, but I cannot tell you, how much you will gain by that.
One totally different possible solution: I began with pygame once (since I did SDL in C++ prior to that). Recently I was directed to another python gaming library: pyglet. This does not suffer from the problems of updating the whole screen as much as pygame (I think it's because of usage of OpenGL acceleration; it still works on my not at all accelerated eee-Netbook). If you are not bound to pygame in any way, it might be interesting to take a look at pyglet.

Using Pygame to make scrolling shoot-em-up

I'm starting to work on a 2D scrolling shoot-em-up game, and I was wondering if pygame is suitable. I would like to hit close to 60 fps while animating a scrolling background with hundreds of sprites (mostly bullets, of course); is this feasible with pygame? From what I've read, I'm leaning toward no, but I'd like another opinion from someone with more experience with pygame.
I'm also looking at using PyOpenGL with pygame, but I have absolutely no experience with OpenGL. Will OpenGL work better in this case than native pygame graphics, and are there any good tutorials for OpenGL/PyOpenGL/using PyOpenGL with pygame?

Pygame is as good as they get for 2D CPU graphics. All the graphics is implemented in C, (PyGame wraps SDL) so the code is nearly as fast as an equivalent C software renderer.
That said, it's still (basically) a software renderer, and there's this interesting device in every modern computer called a GPU which is designed to do that. PyOpenGL/OpenGL will take advantage of it, so yes, absolutely PyOpenGL will render faster than PyGame.
Bottom line:
PyGame is fast, but not as fast as PyOpenGL. For hundreds of onscreen sprites, that will mainly be a logic problem (Python logic is slow, even by interpreted language standards). Rewriting it in SDL would make it faster (because C/C++ is faster than Python). You could also use PyOpenGL, which I predict in this case would improve performance significantly, though not dramatically (but it's much harder to use).
Like I said, though, it will be primarily a logic issue, I think. There is something to be said for using PyOpenGL, but as they say, the greatest optimization you will ever make is when your code works for the first time.

Pygame is the best solution for 2D games in python according to me. You can save Surfaces uses its optimized Sprites animation, so I think it's the fastest solution : as for development process than for code execution.

Basic Python 2D graphics?

I'm looking for a Python 2D graphics library that can basically do the following and not necessarily anything more:
Create a window of specified width and height
Set the RGB of pixel X, Y on the back buffer.
Swap buffers
...and that's it basically. I can't find anything that doesn't come with a massive amount of complex baggage.

I recommend PyQt for this - it's a GUI library/framework but it has very good drawing capabilities. If you look at the examples coming with PyQt, focusing on the graphics & drawing samples, it's quite amazing what you can do with very few lines of code.
Oh, and it does the double-buffering you mention automatically so you don't have to worry about it.
Alternatively, you can use PyGame - a library wrapping SDL, used for game development. Naturally it has very strong 2D graphics capabilities.