Using gzip.GzipFile:

import gzip

with gzip.open('input.gz','rt') as f:
    for line in f:
        print('got line', line)

Note: gzip.open(filename, mode) is an alias for gzip.GzipFile(filename, mode). I prefer the former, as it looks similar to with open(...) as f: used for opening uncompressed files.

You can use zcat to stream the uncompressed contents into grep or whatever filter you want, without incurring space overhead. E.g.

zcat bigfile.gz | grep PATTERN_I_NEED > much_smaller_sample

Also, if it's just grep you're streaming to, you can use zgrep e.g.

zgrep PATTERN_I_NEED bigfile.gz > much_smaller_sample

but zgrep doesn't support 100% of the features of grep on some systems.

You can't, because Gzip is not an archive format.

That's a bit of a crap explanation on its own, so let me break this down a bit more than I did in the comment...

Its just compression

Being "just a compression system" means that Gzip operates on input bytes (usually from a file) and outputs compressed bytes. You cannot know whether or not the bytes inside represent multiple files or just a single file -- it is just a stream of bytes that has been compressed. That is why you can accept gzipped data over a network, for example. Its bytes_in -> bytes_out.

What's a manifest?

A manifest is a header within an archive that acts as a table of contents for the archive. Note that now I am using the term "archive" and not "compressed stream of bytes". An archive implies that it is a collection of files or segments that are referred to by a manifest -- a compressed stream of bytes is just a stream of bytes.

What's inside a Gzip, anyway?

A somewhat simplified description of a .gz file's contents is:

1. A header with a special number to indicate its a gzip, a version and a timestamp (10 bytes)
2. Optional headers; usually including the original filename (if the compression target was a file)
3. The body -- some compressed payload
4. A CRC-32 checksum at the end (8 bytes)

That's it. No manifest.

Archive formats, on the other hand, will have a manifest inside. That's where the tar library would come in. Tar is just a way to shove a bunch of bits together into a single file, and places a manifest at the front that lets you know the names of the original files and what sizes they were before being concatenated into the archive. Hence, .tar.gz being so common.

There are utilities that allow you to decompress parts of a gzipped file at a time, or decompress it only in memory to then let you examine a manifest or whatever that may be inside. But the details of any manifest are specific to the archive format contained inside.

Note that this is different from a zip archive. Zip is an archive format, and as such contains a manifest. Gzip is a compression library, like bzip2 and friends.

I was able to answer my question with the help of the comments. (Thanks!) My code now extracts .tex files from multiple .gz files that are inside a single .tar file, without unzipping/saving each .gz file to the computer.

def extractFile(filename):
    tar = tarfile.open(filename)
    for subfile in tar.getmembers():
        # Open subfile only if .gz
        if subfile.name.endswith('.gz'):
            try: 
                gz = tar.extractfile(subfile)
                gz = tarfile.open(fileobj=gz)
                # Extract file from .gz into 'latex' subfolder only if .tex
                for subsubfile in gz.getmembers():
                    if subsubfile.name.endswith('.tex'):
                        gz.extract(subsubfile, path='latex')
            except tarfile.ReadError:
                # Add subfile name to error log
                with open('error_log.txt', 'a') as log:
                    log.write(subfile.name + '\n')

Piping zcat’s output to head -n 1 will decompress a small amount of data, guaranteed to be enough to show the first line, but typically no more than a few buffer-fulls (96 KiB in my experiments):

zcat logfile.gz | head -n 1

Once head has finished reading one line, it closes its input, which closes the pipe, and zcat stops after receiving a SIGPIPE (which happens when it next tries to write into the closed pipe). You can see this by running

(zcat logfile.gz; echo $? >&2) | head -n 1

This will show that zcat exits with code 141, which indicates it stopped because of a SIGPIPE (13 + 128).

You can add more post-processing, e.g. with AWK, to only extract the date:

zcat logfile.gz | awk '{ print $1; exit }'

(On macOS you might need to use gzcat rather than zcat to handle gzipped files.)

Pass mode='rt' (text mode) to the gzip.open call.

From the documentation (linked above):

The mode argument can be any of 'r', 'rb', 'a', 'ab', 'w', 'wb', 'x' or 'xb' for binary mode, or 'rt', 'at', 'wt', or 'xt' for text mode. The default is 'rb'.

MemoryError suggests that the file is too big for your runtime to process.

IIGC train.gz may be a training model and it may be that you must deal with this model as a single chunk. If so, your best solution is to find a bigger (more memory) machine.

If at all possible (and strongly preferred), you should stream the uncompressed file through your program so that you may constrain the buffer|in-memory window onto it thereby limiting the possibility that you'll run out of memory.