Максим Припадчев

1. До 18ти лет, скорее всего, никуда не возьмут.
2. В вашем возрасте обучение максимально быстрое и эффективное.

Отсюда план:
1. Учитесь, читайте книги, набивайте руку на пет-проектах. Читать и учиться придется на протяжении всей карьеры (спойлер, т.к. пенсии у вас не будет - всей жизни).
2. Заканчивайте 11й класс.
3. Постарайтесь поступить в ВУЗ (опционально).
4. После первой сессии начинайте искать работу. К этому времени у вас должно скопиться небольшое портфолио проектов и опыт достаточный для трудоустройства на младшие позиции.
5. Спокойно доучивайтесь в ВУЗ-е (опционально), паралельно работая.

Ну так почитай основы.
Во-первых, используй r-строки, чтобы не натыкаться на проблемы с символом \.
Во-вторых, изучи зарезервированные символы регулярных выражений, а именно: ( ) [ ] ^ $ . ? * +. Если тебе нужен этот символ как просто символ, его надо экранировать! Т.е. если тебе нужно совпадение с символом ?, надо писать \?.
В-третьих, для поиска символа из указанного набора используются квадратные скобки, т.е. [abc] совпадёт с одним символом из указанных: a, b или c. Для задания диапазона можно сделать так: [a-z]. Это зачастую короче.
В-четвёртых, для поиска символа НЕ из указанного набора используется такой синтаксис: [^abc]
В-пятых, есть заранее заданные наборы. Например, \w описывает словесные символы (буквы, цифры и подчёркивание), \d описывает цифры, и т.д. Аналогично, \W и \D описывают всё кроме словесных символов и цифр, соотв.
Тогда у тебя будет два варианта
Если подчёркивание - не проблема:

re.sub(r'\W', '', 'test:_:test', re.I)  # даст test_test

Если подчёркивание тоже нужно убрать:

re.sub(r'[\W_]', '', 'test:_:test', re.I)  # даст testtest

Есть ещё один способ загружать неформатные файлы, похожие на json.
Дело в том, что любой json файл представляет собой валидный yaml-файл.
Но yaml гораздо боле гибкий формат, который "проглатывает" и ключи без кавычек, и трейлинговые запятые.
Можно много спорить по поводу безопасности и корректности использования yaml для парсинга невалидных json, но иногда просто нет выхода и нужно обрабатывать огромное количество таких уже имеющихся файлов.

import yaml
with open('test.json', encoding='utf-8') as f:
    data = yaml.load(f, yaml.CSafeLoader)

Уважаемый mayton2019 дал в общем-то почти исчерпывающий ответ. Но раз вы задали этот вопрос "из возникшего интереса", то есть шанс, что и другим ответы данной темы будут интересы, потому попробую еще чуть-чуть дополнить упомянутый ответ.

Возможно многие и не слышали, но тем не менее существуют т.н. In-memory database (по-русски это, кажется, называется "Резидентная база данных", но я не уверен). Применяются такие системы как правило в высоконагруженных приложениях - в системах провайдеров телекоммуникационных услуг, когда-то читал - что в системах он-лайн биржевой торговли и пр. Там где данных очень много и доступ к ним нужен очень быстро. И главное - владелец таких данных оччччеееень богатенький, что-бы позволить себе приобрести оборудование с объемом оперативной памяти сопоставимым с объемом внешней памяти для "обычных" серверов баз данных. И вот тогда, для таких задач все данные СУБД, включая все индексы и другой служебно-вспомогательной информации, загоняются в оперативную память, обеспечивая и нужную скорость доступа и удобство доступа, которое обычно присуще СУБД.
Главнейшая проблема, которую решают разработчики таких систем - как обеспечить целостности базы данных при внезапной перезагрузке систем. Это влияет на производительность In-memory database, заставляя тратить часть вычислительных ресурсов на синхронизацию данных в ОП и резервных копий на внешней памяти.
Список таких систем можно, кстати, найти даже в Википедии:
https://en.wikipedia.org/wiki/List_of_in-memory_da...

Если же "спуститься" с небес на землю и учесть финансовые возможности "нормального" пользователя, то например, в языке программирования Python есть такой модуль - Pandas. По сути он дает удобство доступа к данным, почти такое-же (а может и еще большее) как SQL, сохраняя таблицы в ОП. А скорость обработки - сопоставимую с реализацией на "голых" массивах, а для сложных поисковых запросов - и еще большую. Естественно, что объем таблиц (DataFrame в терминологии Pandas) не может быть слишком большим. И не смотря на то, что есть прямой шлюз для перехода от DataFrame к SQL-структурам СУБД и обратно, скорость работы "в памяти" на много выше, чем скорость работы с теми-же данными, выгруженными в БД. Поэтом программист может комбинировать работу DataFrame для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.

При поиске тегов вам нужно указывать пространство имен:

import requests
from xml.etree import ElementTree

response = requests.get(
    'https://s3-ap-northeast-1.amazonaws.com/data.binance.vision?delimiter=/&prefix=data/spot/monthly/klines/BTCUSDT/1h/')
print(response)
archive_tree = ElementTree.fromstring(response.content)
namespace = archive_tree.tag.split('}')[0].strip('{')
for files in archive_tree.iter(f'{{{namespace}}}Key'):
    print(files.text)

Output:

<Response [200]>
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-08.zip
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-08.zip.CHECKSUM
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-09.zip
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-09.zip.CHECKSUM
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-10.zip
data/spot/monthly/klines/BTCUSDT/1h/BTCUSDT-1h-2017-10.zip.CHECKSUM
...

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Возьмем к примеру сущность "пользователь". Придумаем ему несколько свойств, методов и событий.
Свойства: имя, возраст, адрес, баланс.
Методы: установить имя, прочитать имя, установить адрес, прочитать адрес...
События: имя изменилось, баланс изменился, аватарка изменилась, пользователь заказал пиццу, или что там у вас за бизнес-логика.

Вы можете придумать свои события, которые подходят под ваши процессы.

SELECT user_id, join_date EXTRACT(DAY FROM date) as day FROM users VALUES (?, ?)

SELECT запросы c условием пишутся не так.

Встроенной функции нет. И похоже, что речь идёт не столько о разных шрифтах, а сколько о гомоглифах - символах юникода из разных алфавитов, которые выглядят похоже. Например, как русское и латинское "о". Это нетривиальная задача, но пакет confusable_homoglyphs (ставится через pip) может помочь. В частности, функция is_confusable().

from confusable_homoglyphs.confusables import is_confusable


wtf = 'YOᑌ ᑎᗩᗰE 42'

is_good = []
result = []
for c in wtf:
    data = is_confusable(c, preferred_aliases=[], greedy=True)
    if data:
        data = data[0]
        alias = data['alias']
        if alias in ('LATIN', 'COMMON'):
            data = False
    if data:
        is_good.append('!')
        print(data)
        result.append(data['homoglyphs'][0]['c'])
    else:
        is_good.append(' ')
        result.append(c)
    print()
print(''.join(result))
print(''.join(is_good))

Работает неидеально, но настройки модуля лежат в JSON - можно кое-что поправить. Или создать issue на гитхабе проекта.

Конечно, можно извратиться, отрендерить строку и прогнать по ней OCR, но это такая себе идея.

Ну например можно использовать API тинькофф инвестиций:
1. Это бесплатно
2. В качестве источника данных - не только лишь мосбиржа.

В качестве транспорта используется gRPC - php его поддерживает.
Какой-то чел даже написал библиотеку для работы с инвестициями через php
Вот: https://github.com/metaseller/tinkoff-invest-api-v2-php
Если эта библиотека по каким-то причинам не подошла - можно сгенерировать код самостоятельно, из protobuf-файлов:
https://github.com/Tinkoff/investAPI/
Документация к самому API:
https://tinkoff.github.io/investAPI/

Вот инструкция по работе с gRPC из php:
https://grpc.io/docs/languages/php/quickstart/

А какое-бы значение атрибута вы бы хотели получить, обращаясь к классу, а не к объекту??

А вообще-то, например, вот так:

import numpy as np
arr=np.empty(10)
for item in dir(arr):
    print(item, getattr(arr,item))

Ну, или что-бы хоть немного просеять тот шлак, который от такого весьма странного действия вы получите, можно сделать вот так:

interesting_methods = [method for method in dir(arr) if method.startswith('__') is False]   
for item in interesting_methods:
    print(item, getattr(arr,item))

Тоже, конечно, не понятно, что вы с этой информацией делать то собираетесь, но в выдаче, если порыться, можно найти осмысленную информацию, которую вы как бы проверяете.