Muito obrigado a Brian Granger, Fernando Pérez e Robert Kern pelas contribuições para este artigo!
Para quem está começando e também para cientistas de dados mais experientes, o Jupyter Notebook é uma das ferramentas mais populares: o ambiente interativo é ideal para ensinar, aprender, compartilhar seu trabalho com colegas e ainda garante reprodutibilidade. Só que, enquanto você explora o notebook, é comum esbarrar no IPython.
Em alguns casos, os dois parecem sinônimos — e dá para concordar que isso confunde quando você quer se aprofundar: os magics são do Jupyter ou do IPython? Salvar e carregar notebooks é recurso do IPython ou do Jupyter?
As perguntas não param por aí.
O post de hoje quer destacar de forma mais explícita algumas diferenças centrais entre os dois, começando pelas origens para explicar como se relacionam e cobrindo recursos específicos que pertencem a um ou a outro — para ficar mais fácil distinguir!
Vale também conferir o guia definitivo do Jupyter Notebook da DataCamp com dicas, boas práticas, exemplos e muito mais.
As origens do IPython / Jupyter
Para entender bem o que é o Jupyter Notebook e como ele difere do IPython, vale voltar um pouco e ver como os dois se encaixam na história — e no futuro — dos notebooks computacionais.
O começo dos notebooks computacionais: MATLAB, Mathematica e Maple
Em meados dos anos 1980, o MATLAB foi lançado pela The MathWorks, fundada por Jack Little, Steve Bangert e Cleve Moler.
Indo para o fim da década, 1987 para ser exato: Theodore Gray começou a trabalhar no front-end de notebooks do Mathematica e, um ano depois, saiu a versão pública. A interface gráfica permitia criar e editar documentos de notebook com código formatado, texto e vários recursos como matemática tipografada, gráficos, componentes de GUI, tabelas e sons. Havia funções padrão de editor de texto, como correção ortográfica multilíngue em tempo real. Você podia exibir os documentos em modo apresentação.
Ao olhar a estrutura desses notebooks, dá para notar de cara a hierarquia de células que permitia organizar e seccionar documentos — algo que hoje também existe nos notebooks Jupyter.
Também no fim dos anos 1980, em 1989, o Maple apresentou sua primeira GUI no estilo notebook, incluída na versão 4.3 para Macintosh. Versões para X11 e Windows vieram em 1990. Esses primeiros notebooks inspiraram e lançaram as bases para o que mais tarde seria chamado de “notebooks de data science”.
A ascensão dos notebooks de data science
Muitos notebooks computacionais vieram depois de Maple e Mathematica. Aqui, vamos focar nos que ajudaram a impulsionar os notebooks de data science — alguns deles seguem populares entre iniciantes e profissionais experientes.
Sage Notebook
O Sage Notebook, como sistema baseado em navegador, saiu pela primeira vez em meados dos anos 2000 e, em 2007, ganhou uma versão mais poderosa, com contas de usuário e a possibilidade de tornar documentos públicos. A interface lembrava o Google Docs, já que o layout do Sage foi inspirado no Google Notebooks.
Os criadores do Sage eram usuários assíduos dos notebooks do Mathematica e das planilhas do Maple. Outros fatores que pesaram no desenvolvimento do Sage foram: primeiro, a proximidade com a equipe do IPython, até porque a versão em terminal do Sage usava IPython. Segundo, “uma tentativa fracassada” de dois estudantes de criar uma GUI para IPython. Terceiro, a ascensão dos aplicativos web “AJAX” (acrônimo de “Asynchronous JavaScript And XML”), que evitavam recarregar a página a cada ação.
Isso vale, por exemplo, ao enviar um formulário: sem AJAX, você seria redirecionado para outra página com as respostas do servidor ao clicar em enviar. Com AJAX, o JavaScript faz a requisição, recebe o resultado e atualiza a tela. Nada de recarregar ou redirecionar.
Outros apps AJAX conhecidos: Gmail, Google Maps, Facebook, Twitter… Quase tudo hoje é AJAX.
IPython e Jupyter Notebook
No fim de 2001, cerca de vinte anos depois de Guido van Rossum começar a trabalhar no Python no instituto CWI, na Holanda, Fernando Pérez iniciou o desenvolvimento do IPython. O projeto foi fortemente influenciado pelos notebooks do Mathematica e pelas planilhas do Maple, assim como o Sage e tantos outros.
Em 2005, houve a primeira tentativa de construir um sistema de notebook com Wx, um toolkit para GUIs multiplataforma. Dois alunos do Google Summer of Code trabalharam no protótipo sob orientação de Robert Kern e Fernando Pérez. Depois, Robert seguiu refinando a base do IPython para facilitar a criação de um front-end wxPython para o shell do IPython. Esses ajustes ajudaram a viabilizar um sistema de notebook mais limpo, e parte deles foi integrada ao IPython quando o esforço finalmente ganhou tração.
O segundo protótipo do notebook do IPython surgiu no verão de 2006, feito por Min Ragan-Kelley e orientado por Brian Granger. Era web e tinha backend em banco SQL, mas o trabalho foi descontinuado pela complexidade tecnológica da época.
O terceiro protótipo apareceu em outubro de 2010, feito por terceiros em alguns dias de hack. Finalmente, na primavera-verão de 2011, Brian Granger passou a trabalhar em tempo integral no protótipo web, baseado no trabalho de 2010, quando criou a arquitetura de kernel e a especificação de mensagens do IPython com Fernando Pérez e o PyZMQ com Min Ragan Kelley.
PyZMQ é a biblioteca que fornece bindings Python para ZeroMQ; ela era necessária para os recursos de computação paralela do IPython, o console qt e o notebook.
PyZMQ e websockets foram as tecnologias-chave que viabilizaram o notebook. No outono do mesmo ano, outros contribuidores (como Matthias Bussonnier, Min e Fernando) passaram a colaborar. Em 21 de dezembro de 2011, foi lançada a primeira versão do IPython Notebook (0.12).
Nos anos seguintes, a equipe recebeu prêmios, como o Advancement of Free Software para Fernando Pérez em 23 de março de 2013 e o Jolt Productivity Award, além de financiamento da Alfred P. Sloan Foundation, entre outros.
Por fim, em 2014, nasceu o Project Jupyter como um spin-off do IPython.
O último release do IPython antes da separação incluía shell interativo, servidor de notebook, console Qt etc., tudo em um único repositório. O projeto cresceu, com componentes cada vez mais distintos que, por acaso, ainda estavam no mesmo guarda-chuva.
Mas o tamanho não foi o único motivo para o Project Jupyter: de 2011 a 2014, o notebook do IPython passou a funcionar com outras linguagens. Primeiro Julia, depois R. Falar em “IPython notebook” (sugerindo que era só Python) enquanto ele rodava kernels de Julia e R confundia as pessoas.
Por que manter “IPython” no nome se havia outras linguagens?
“Jupyter” foi inspirado nas principais linguagens abertas para ciência (Julia, Python e R). Embora pareça um acrônimo, nunca significou excluir outras linguagens. Além disso, representava melhor o projeto em desenvolvimento e homenageava suas raízes científicas.
Após o início do Project Jupyter, as partes independentes de linguagem do IPython — como o formato do notebook, o protocolo de mensagens, o console Qt, o app web do notebook etc. — foram migradas para o projeto Jupyter. A organização principal no GitHub está aqui.
Na comunidade Jupyter e IPython, isso ficou conhecido como “The Big Split”.
Hoje, o IPython tem dois papéis: ser o backend Python do Jupyter Notebook (o kernel) e um shell interativo de Python. E tem mais: no ecossistema IPython, você também encontra um framework de computação paralela. Falamos disso mais adiante!
Assim como o IPython, o Project Jupyter é um guarda-chuva para vários projetos: além do Notebook, há um Console e um console Qt; e subprojetos como o JupyterHub (para implantação de notebooks), o nbgrader (educação) etc. Veja uma visão geral da arquitetura aqui.
É justamente essa evolução que explica a confusão de muitos pythonistas sobre IPython e Jupyter: como um nasceu do outro (e há pouco tempo), ainda há quem confunda os nomes. E o fator complicador é a sobreposição: há muitos recursos do IPython e do Jupyter Notebook que se parecem e às vezes são difíceis de distinguir. Como separar os dois fica mais claro nas próximas seções. Para mais detalhes da história do IPython, veja os relatos de Fernando Pérez e William Stein.
Notebooks em R
R Markdown e Jupyter Notebook compartilham a proposta de um fluxo reprodutível, tecendo código, saída e texto em um único documento, com suporte a widgets interativos e exportação para múltiplos formatos.
Mas também diferem: o primeiro foca execução em lote reprodutível, representação em texto puro, controle de versão, saída para produção e oferece o mesmo editor e ferramentas que você usa com scripts R. O segundo prioriza saída inline junto do código, cache de resultados entre sessões, compartilhamento de código e saída em um único arquivo. Notebooks enfatizam execução interativa. Em vez de texto puro, usam uma representação estruturada, como JSON.
É aí que entra o notebook do RStudio: ele combina as vantagens do R Markdown com o que os notebooks computacionais têm de melhor.
Para aprender a trabalhar com notebooks em R e entender as diferenças entre Jupyter e R Markdown em compartilhamento, gestão de projetos, versionamento e mais, veja o post Jupyter e R: notebooks com R da DataCamp.
Outros notebooks de data science
Claro, há muitos outros notebooks para explorar em data science. Nos últimos anos, surgiram várias alternativas: Beaker Notebook, Apache Zeppelin, Spark Notebook, DataBricks Cloud etc.; e também ferramentas como o IDE Rodeo ou o nteract, que tornam análises interativas e reprodutíveis. Um ponto legal: o nteract difere das demais ferramentas citadas por aproveitar a arquitetura do Jupyter (protocolos e formatos).
O futuro dos notebooks
Ao que tudo indica, notebooks vieram para ficar. Recentemente, a próxima geração do Jupyter Notebook foi apresentada: o JupyterLab. Além do suporte a Notebooks, ele inclui gerenciador de arquivos, editor de texto, terminal, monitor de processos Jupyter, gerenciador de clusters IPython e um pager para exibir ajuda.
Você pode pensar que nada disso é novo, já que o Jupyter Notebook também oferece esses recursos. A diferença é que o JupyterLab permite usar esses blocos de computação interativa de formas inéditas.
Leia mais aqui.
O conjunto rico de ferramentas do Jupyter Notebook evoluiu organicamente, guiado pelas necessidades de usuários e desenvolvedores. O JupyterLab traz uma arquitetura de nova geração para suportar tudo isso, com uma UI flexível e responsiva e um layout controlado pelo usuário que integra as ferramentas.
IPython ou Jupyter?
A evolução do projeto e o consequente “Big Split” são a base para entender as diferenças reais entre os dois. Mas, por serem intrinsecamente conectados, às vezes surge a dúvida sobre o que pertence a cada um.
A seguir, vamos passar por recursos que fazem parte do ecossistema IPython ou do Project Jupyter.
Agora é com você: identifique a resposta certa e saiba mais sobre cada recurso!
Kernels?
Embora kernels apareçam com destaque hoje no aplicativo Jupyter Notebook, a primeira ferramenta a usar um kernel completo e protocolo foi o console Qt, anterior ao Notebook. Hoje, os kernels são explorados de forma flexível pelo Notebook, tanto historicamente quanto arquiteturalmente, e são um recurso do Jupyter, não do Notebook em si. Ou seja, kernels vão além de um recurso: são uma abstração central da arquitetura Jupyter e são usados por ferramentas fora do notebook, como o console de texto, o console Qt, o Thebe da O’Reilly, o Kernel Gateway, o editor Hydrogen do nteract. No JupyterLab, kernels podem ser conectados a tudo: de um notebook a um console web ou até a um arquivo de texto.
Um kernel é um programa que executa e inspeciona o código do usuário: ele provê computação e comunicação com os front-ends, como os notebooks. O aplicativo Jupyter Notebook tem três kernels principais: IPython, IRkernel e IJulia.
Como o nome “Jupyter” foi inspirado em Julia, Python e R, isso não surpreende. O kernel IPython é mantido pelo time do Jupyter, como resultado da evolução do projeto.
Mas você também pode rodar muitas outras linguagens no Jupyter Notebook: Scala, JavaScript, Haskell, Ruby e mais. Esses são kernels mantidos pela comunidade.
Implantação de notebooks?
Implantar notebooks é algo que você normalmente encontra — ou busca — ao trabalhar com Jupyter. Há vários pacotes para ajudar nessa tarefa e que fazem parte do ecossistema Jupyter.
Alguns deles:
docker-stacksé útil quando você precisa de pilhas de apps Jupyter e kernels como contêineres Docker.ipywidgetsfornece widgets HTML e JavaScript interativos (sliders, checkboxes, caixas de texto, gráficos etc.) para a arquitetura Jupyter, combinando controles de front-end com um kernel Jupyter.jupyter-drivepermite ao IPython usar o Google Drive para gerenciamento de arquivos.jupyter-sphinx-themeadiciona um tema Jupyter ao Sphinx do seu notebook. Facilita criar documentação inteligente e bonita.kernel_gatewayé um servidor web que oferece mecanismos para iniciar e se comunicar com kernels Jupyter. Veja aqui alguns casos de uso.nbviewerpara compartilhar seus notebooks. Confira a galeria aqui.tmpnbpara criar servidores temporários de Jupyter Notebook com Docker. Experimente aqui.traitletsé um framework que permite a classes Python terem atributos com checagem de tipo, valores padrão calculados dinamicamente e callbacks “on change”. Também serve para configuração, carregando valores de arquivos ou argumentos de linha de comando. O traitlets alimenta o sistema de configuração do IPython e do Jupyter e a API declarativa dos widgets interativos do IPython.
Uso do shell do sistema?
É possível adaptar o IPython para uso como shell do sistema com o “escape” de shell: linhas que começam com ! são passadas diretamente ao shell. Por exemplo, !ls executa o ls no diretório atual. Você pode atribuir o resultado de um comando do sistema a uma variável Python com myfiles=!ls. Se quiser imprimir explicitamente o resultado do ls como uma lista de strings, sem atribuir a uma variável, use dois pontos de exclamação (!!ls) ou o comando mágico %sx sem atribuição.
# Assign the result to `ls`
ls = !ls
# Explicit `ls`
!!ls
# Or with magics
%sx
# Assign magics result
ls = %sxNote que comandos com !! não podem ser atribuídos a variáveis, mas o resultado de um magic (desde que retorne valor) pode ser atribuído.
O IPython também permite expandir valores de variáveis Python em chamadas de sistema: basta envolver variáveis ou expressões entre chaves ({}). Em um comando com ! ou !!, qualquer variável Python prefixada com $ é expandida. No bloco abaixo, você dá um echo no atributo argv da variável sys. Note que você também pode usar as sintaxes $/$$ para passar variáveis Python a partir da saída do sistema e usá-las depois em scripts.
Para passar um $ literal ao shell, use $$. Você vai precisar do $ literal para acessar variáveis de ambiente como $PATH:
# Import and initialize
import math
x = 4
# System call with variable
!echo {math.factorial(x)}
# Expand a variable
!echo $sys.argv
# Use $$ for a literal $
!echo "A system variable: $$HOME"Leia mais aqui.
Além do IPython, há kernels com sintaxe especial para executar linhas como comandos de shell! Esses não são exatamente “magics” no sentido estrito, pois podem implementar com qualquer nome e de forma diferente (mais ou menos rica) do que os magics do IPython.
Também existem aliases que você pode definir para comandos de sistema. São basicamente atalhos para comandos bash. Um alias é uma tupla: (“showTheDirectory”, “ls”). Rode %alias? para saber mais!
Dica: use %rehashx para carregar todo o seu $PATH como aliases do IPython.
Magics?
Se você já passou pelo guia definitivo do Jupyter Notebook da DataCamp ou já trabalhou com Jupyter, deve conhecer os “magic commands”. Os magics geralmente têm um elemento de sintaxe inválido na linguagem subjacente seguido de uma palavra que indica um comando. Por baixo dos panos, funções magic são funções Python.
O kernel IPython usa o símbolo % porque não é um operador unário válido em Python. Linhas que começam com %% sinalizam uma “cell magic”: recebem como argumentos não só o restante da linha, mas todas as linhas abaixo, no bloco atual. Cell magics podem modificar arbitrariamente a entrada recebida — que nem precisa ser Python válido — e recebem o bloco inteiro como uma única string.
Magics são específicos de cada kernel e foram criados para deixar seu trabalho no Jupyter Notebook muito mais interativo. A disponibilidade depende dos desenvolvedores e varia de kernel para kernel. Ou seja: magics são um recurso de kernel.
Usando o backend Python do Jupyter Notebook, o IPython (o kernel), você pode aproveitar truques que aceleram, simplificam e tornam seu desenvolvimento mais interativo. A lista abaixo não é exaustiva. Veja a listagem completa de magics.
Plotagem
Um grande recurso do kernel IPython é exibir gráficos gerados pelas células. Ele funciona de forma integrada com o matplotlib para isso. Use o magic %matplotlib.
Por padrão, o gráfico abre em uma janela separada. Você também pode especificar um backend, como inline ou qt, para exibir os gráficos embutidos ou via outro backend GUI. Leia mais aqui.
Navegação no sistema de arquivos
Os magics do kernel também permitem navegar no seu sistema de arquivos. Use %cd e %bookmark para trocar de diretório ou favoritar pastas que você acessa com frequência.
Acesso ao debugger
Você pode usar magics para chamar o debugger do Python com %pdb sempre que houver uma exceção não tratada. Ele guia você pelo trecho que gerou a exceção, ajudando a achar o bug rapidamente.
Também dá para usar %run com a opção -d para rodar scripts sob controle do debugger, configurando breakpoints iniciais automaticamente. Por fim, o %debug facilita ainda mais o acesso ao debugger.
Extensões do IPython
Use o magic %load_ext para carregar uma extensão IPython pelo nome do módulo. Extensões são módulos Python que alteram o comportamento do shell: podem registrar magics, definir variáveis e, em geral, modificar o namespace do usuário para oferecer novos recursos nas células de código. Exemplos:
- Use
%load_ext oct2py.ipythonpara chamar arquivos M e funções Octave a partir do Python, - Use
%load_ext rpy2.ipythonpara usar uma interface com R embutido em um processo Python, - Use
%load_ext Cythonpara compilar Python em C, - Use
sympy.init_printing()para exibir objetos Sympy Basic com formatação bonita automaticamente, e - Para usar Fortran na sua sessão interativa, carregue
%load_ext fortranmagic.
… E tem muito mais! Você pode criar e registrar suas próprias extensões IPython no PyPI — há várias extensões e magics criados por usuários. Um exemplo é ipython_unittest. Veja também o índice de extensões.
Outra extensão para ficar de olho é a sparkmagic, um conjunto de ferramentas para trabalhar interativamente com clusters Spark remotos via Livy (um servidor REST do Spark) em notebooks Jupyter. A biblioteca sparkmagic fornece o magic %%spark para rodar código facilmente em um cluster Spark remoto a partir de um notebook IPython comum.
# Load in sparkmagic
%load_ext sparkmagic.magics
# Set the endpoint
%manage_spark
# Ask for help
%spark?Veja mais exemplos de uso desses magics com Spark aqui.
Além do %load_ext, o IPython tem outros dois magics para gerenciar extensões no Jupyter Notebook: %reload_ext e %unload_ext para recarregar e descarregar extensões.
Kernels diferentes, outros magics
Em outras linguagens, o elemento de sintaxe dos magics pode ter significado. O kernel de R, IRKernel, não tem sistema de magics. Para executar comandos bash, por exemplo, você usa funções R como system() para chamar o SO. Exemplo: system("head -5 *.csv", intern=TRUE). Incluindo o argumento intern, você captura a saída como vetor de caracteres em R. Para exibir markdown, use display_markdown(), passando o código como string. Da mesma forma, o kernel de Julia, IJulia, também não usa “magics”. Em vez disso, outras sintaxes mais naturais em Julia — que funcionam fora das células do IJulia e muitas vezes são mais poderosas — cumprem o papel. Quando você digita um magic do IPython em uma célula IJulia, os desenvolvedores providenciaram uma ajuda explicando como fazer algo equivalente em Julia, quando possível.
Por exemplo, o análogo do %load do IPython no IJulia é IJulia.load().
Por outro lado, há kernels como o de Scala, IScala, que suportam magics de forma parecida com o IPython. Mas o conjunto é diferente, acompanhando as especificidades de Scala e da JVM. Magics começam com % seguidos de um identificador e, opcionalmente, entradas. Alguns destaques:
# Type Information
%type 1
# Library Management
%libraryDependencies
%updateComo citado, a biblioteca sparkmagic também fornece kernels de Scala e Python que se conectam automaticamente a um cluster Spark remoto, rodam código e consultas SQL, gerenciam o servidor Livy e a configuração de jobs Spark e geram visualizações — tudo isso sem precisar escrever código!
Por exemplo, dá para executar consultas SparkSQL com %%sql ou acessar informações e logs da aplicação Spark via %%info.
Se você está usando outro kernel e quer saber se há magics, vale saber que alguns kernels se baseiam no projeto metakernel e, em muitos casos, usam os mesmos magics do kernel IPython. A lista de magics do metakernel está aqui. O metakernel é um template de kernel Jupyter/IPython que já inclui funções magic essenciais.
Alguns exemplos:
- Kernel MATLAB
matlab_kernel, - Kernel Octave
octave_kernel, - Kernel Java9
java9_kernel, - Kernel Wolfram
wolfram_kernel, - Kernel SAS. … E muitos outros!
Isso significa que, por exemplo, usando o kernel MATLAB, você terá estes magics disponíveis:
Available line magics:
%cd %connect_info %download %edit %get %help %html %install %install_magic %javascript %kernel %kx %latex %load %ls %lsmagic %magic %parallel %plot %pmap %px %python %reload_magics %restart %run %set %shell %spell
Available cell magics:
%%debug %%file %%help %%html %%javascript %%kx %%latex %%processing %%px %%python %%shell %%show %%spellComparando com os magics padrão do kernel IPython, vários são iguais:
Available line magics:
%alias %alias_magic %autocall %automagic %autosave %bookmark %cat %cd %clear %colors %config %connect_info %cp %debug %dhist %dirs %doctest_mode %ed %edit %env %gui %hist %history %killbgscripts %ldir %less %lf %lk %ll %load %load_ext %loadpy %logoff %logon %logstart %logstate %logstop %ls %lsmagic %lx %macro %magic %man %matplotlib %mkdir %more %mv %notebook %page %pastebin %pdb %pdef %pdoc %pfile %pinfo %pinfo2 %popd %pprint %precision %profile %prun %psearch %psource %pushd %pwd %pycat %pylab %qtconsole %quickref %recall %rehashx %reload_ext %rep %rerun %reset %reset_selective %rm %rmdir %run %save %sc %set_env %store %sx %system %tb %time %timeit %unalias %unload_ext %who %who_ls %whos %xdel %xmode
Available cell magics:
%%! %%HTML %%SVG %%bash %%capture %%debug %%file %%html %%javascript %%js %%latex %%perl %%prun %%pypy %%python %%python2 %%python3 %%ruby %%script %%sh %%svg %%sx %%system %%time %%timeit %%writefileNo fim das contas, uma pergunta ajuda a distinguir quais magics são específicos do IPython e quais podem ser usados em outros kernels: este recurso é específico do Python ou é algo geral da linguagem com que você está trabalhando?
Por exemplo, %pdb (o debugger do Python) ou %matplotlib são específicos do Python e não fazem sentido no kernel de JavaScript. Já mudar de diretório com %cd é bem geral e deveria funcionar em qualquer linguagem, por ser um comando comum. Ainda assim, você precisa verificar se o seu kernel implementa magics.
Conversão e formatação de notebooks?
Converter e formatar notebooks são tarefas do ecossistema Jupyter. Duas ferramentas típicas são nbconvert e nbformat.
Com a primeira, você converte notebooks para vários formatos para apresentar informações de forma familiar, publicar pesquisas, embutir notebooks em artigos, colaborar e compartilhar conteúdo.
Já a segunda contém o formato do Jupyter Notebook e é a chave para entender que arquivos de notebook são documentos JSON simples que incluem: metadados (como info do kernel/linguagem), a versão do formato (maior e menor) e as células onde ficam texto, código etc.
Salvar e carregar notebooks?
Salvar e carregar notebooks é um recurso do aplicativo Jupyter Notebook. Você pode carregar arquivos .ipynb criados por outras pessoas baixando e abrindo o arquivo no Jupyter. Especificamente, crie um novo notebook e depois abra o arquivo clicando na aba “File”, em “Open”, e selecionando o notebook baixado.
No sentido inverso, você salva seus notebooks clicando na mesma aba “File” e escolhendo “Download as” para baixar o arquivo, ou pode salvar e criar um checkpoint. Isso ajuda a fazer um controle de versão básico e reverter para uma versão anterior do notebook. Claro, suas alterações são salvas automaticamente a cada poucos minutos, então nem sempre é necessário fazer isso manualmente.
Você também pode optar por não salvar mudanças no notebook original fazendo uma cópia e salvando tudo nela!
Atalhos de teclado e multicursor?
Selecionar múltiplas células, alternar a saída, inserir novas células etc. — tudo isso tem atalhos de teclado no Jupyter Notebook. A lista completa fica no menu superior: vá em “Help” e selecione “Keyboard Shortcuts”.
O suporte a múltiplos cursores também é um recurso do Jupyter Notebook!
Rede de computação paralela?
A rede de computação paralela fazia parte do projeto IPython, mas desde a versão 4.0 virou um pacote independente chamado ipyparallel. Ele é basicamente uma coleção de scripts de CLI para controlar clusters no Jupyter.
Mesmo tendo se separado, continua sendo um componente poderoso e, muitas vezes, subestimado do ecossistema IPython; poderoso porque, em vez de rodar um único kernel Python, você pode iniciar vários kernels distribuídos em múltiplas máquinas.
Casos típicos de uso do ipyparallel incluem rodar modelos muitas vezes para estimar a distribuição das saídas ou como variam com parâmetros de entrada. Quando as execuções são independentes, você ganha tempo distribuindo o processamento em vários computadores de um cluster. Pense em treino distribuído de modelos ou simulações.
Terminal?
Este é um recurso do ecossistema Jupyter: há o Jupyter Console e um aplicativo de terminal Jupyter. Porém, desde o início, IPython nomeava o terminal interativo original para Python. Ele oferece um REPL aprimorado, especialmente voltado à computação científica. Esse era o padrão antes de 2011, quando o Notebook trouxe uma interface web moderna e poderosa para Python.
Depois, existia o console do IPython, que iniciava dois processos: o shell de terminal do IPython e o perfil padrão (kernel), que por padrão era Python. O console IPython agora está descontinuado; para iniciá-lo, use o Jupyter Console, um front-end baseado em terminal para kernels Jupyter. Seu código deriva do terminal IPython de processo único. O Jupyter Console entrega a experiência interativa do IPython no terminal, mas podendo se conectar a qualquer kernel Jupyter — não só ao IPython. Assim, você testa qualquer kernel instalado direto no terminal, sem abrir um Notebook completo. O Console permite interação em modo texto com kernels como IJulia e IRKernel.
Por fim, o Jupyter Notebook também tem um aplicativo de Terminal: um shell bash simples que roda no navegador. Você o encontra ao iniciar o app e escolher um novo terminal no menu suspenso.
Qt Console?
O console Qt já foi parte do IPython, mas hoje está no projeto Jupyter. É um app leve que lembra um terminal, mas traz melhorias possíveis apenas em GUI, como figuras inline, edição multilinha com destaque de sintaxe, dicas gráficas e muito mais. O console Qt pode usar qualquer kernel Jupyter.
Conclusão
O post de hoje complementou o guia definitivo da DataCamp, cobrindo em mais detalhes a história dos notebooks computacionais e os principais recursos dos projetos IPython e Jupyter — para entender melhor a evolução e a diferença entre os dois. A ideia é mostrar que, sem a perspectiva histórica, a distinção pode ser difícil. Em alguns casos, há uma zona cinzenta, um “meio-termo”, que não se classifica facilmente.
