#namespace — Public Fediverse posts

https://blog.gslin.org/archives/2026/03/16/12935/amazon-s3-%e6%8e%a8%e5%87%ba-account-regional-namespaces/

Amazon S3 推出 Account Regional Namespace(s)

#account #amazon #aws #bucket #cloud #name #namespace #namespaces #regional #s3 #security #service

https://blog.gslin.org/archives/2026/03/16/12935/amazon-s3-%e6%8e%a8%e5%87%ba-account-regional-namespaces/

Amazon S3 推出 Account Regional Namespace(s)

#account #amazon #aws #bucket #cloud #name #namespace #namespaces #regional #s3 #security #service

https://blog.gslin.org/archives/2026/03/16/12935/amazon-s3-%e6%8e%a8%e5%87%ba-account-regional-namespaces/

Amazon S3 推出 Account Regional Namespace(s)

#account #amazon #aws #bucket #cloud #name #namespace #namespaces #regional #s3 #security #service

https://blog.gslin.org/archives/2026/03/16/12935/amazon-s3-%e6%8e%a8%e5%87%ba-account-regional-namespaces/

Amazon S3 推出 Account Regional Namespace(s)

#account #amazon #aws #bucket #cloud #name #namespace #namespaces #regional #s3 #security #service

https://blog.gslin.org/archives/2026/03/16/12935/amazon-s3-%e6%8e%a8%e5%87%ba-account-regional-namespaces/

Amazon S3 推出 Account Regional Namespace(s)

#account #amazon #aws #bucket #cloud #name #namespace #namespaces #regional #s3 #security #service

#namespace ext_image_copy_capture ext_ext_image_copy_capture_
#namespace ext_image_copy_capture::manager_v1 manager_v1_

#namespace ext_image_capture_source ext_ext_image_capture_source_v1

#using ext_image_copy_capture as capture
#using ext_image_capture_source as image::source

#using capture::manager_v1 as image::manager
#using capture::session_v1 as image::session
#using capture::session_v1 as image::session
#using capture::manager_v1::create_session

extern struct image::manager *manager;
extern struct image::source *source;

struct image::session *session = create_session(manager, source);

or something similar

RE: https://social.vlhl.dev/objects/e95463e7-b873-413d-8669-0ec0cd50e084

thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:

/* lib.h */
#namespace lib lib_

void lib::foo(); /* declares lib_foo as a function name */

/* app.c */
#include <lib.h>
#using lib::foo
#using lib::foo as nya
#using lib as MyApi

int main(void) {
	/* all of those would be pre-processed to lib_foo() */
	lib::foo();
	foo();
	nya();
	MyApi::foo();
}

works with macros, and identifiers, basically anywhere a #define would also work

and could be backwards compatible, e.g. if i were to use it in openrc:

/* rc.h */
#ifdef _HAS_NAMESPACE
#namespace rc rc_
#namespace RC RC_
#endif

now older c programs can still use rc_service_resolve, and newer ones can use rc::service_resolve (as well as #using directives)

including whole namespace, like #using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of all lib_ it sees since #namespace was declared, and forward-replace them

but with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are

@deedasmi
About three quarters of them wouldn't have any vowels, so good luck pronouncing them 🙂
#maths #NameSpace

@afilina This is also how some mocking libs replace functions. There's a slide about it in one of my older talks. #php #namespace
https://senseexception.github.io/mock-mock-mock-talk/#/21

[Перевод] Как мы освободили 7 ТиБ памяти

Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов , больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает. Но есть одна размерность, по которой, как мы подозреваем, мы почти на вершине: это пространства имён. Я думаю так, потому что мы постоянно сталкиваемся со странным поведением во всех процессах, которые их отслеживают. В частности, все процессы, выполняющие их listwatch, занимают на удивление много памяти и подвергают apiserver серьёзной нагрузке. Это стало одной из сложностей масштабирования, которую замечаешь, только достигая определённого порога. При увеличении оверхеда памяти эффективность снижается: каждый байт, который нам нужно использовать для управления — это байт, отнятый у пользовательских сервисов. Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов. Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.

https://habr.com/ru/articles/962642/

#пространство_имен #контейнеры #контейнеры_docker #поды #namespace

Maybe someone can use this and enhance it. #Joomla! #namespace

https://github.com/angieradtke/joomla_namespaces/blob/main/update_joomla_namespaces.php

Dzisiaj dalsza praca z podstaw #Python - tym razem patrzymy na #namespace, czyli jak widać nasze #zmienne. Dla Comarch.

@yantor3d

When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.

> Namespaces are one honking great idea -- let's do more of those!

`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.

Don't do it.

#python #namespace #namespaces #ZenOfPython #zen #import

@yantor3d

When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.

> Namespaces are one honking great idea -- let's do more of those!

`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.

Don't do it.

#python #namespace #namespaces #ZenOfPython #zen #import

@yantor3d

When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.

> Namespaces are one honking great idea -- let's do more of those!

`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.

Don't do it.

#python #namespace #namespaces #ZenOfPython #zen #import

@yantor3d

When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.

> Namespaces are one honking great idea -- let's do more of those!

`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.

Don't do it.

#python #namespace #namespaces #ZenOfPython #zen #import

@yantor3d

When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.

> Namespaces are one honking great idea -- let's do more of those!

`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.

Don't do it.

#python #namespace #namespaces #ZenOfPython #zen #import

Namespace Reuse Vulnerability Exposes AI Platforms to Remote Code Execution https://gbhackers.com/namespace-reuse-vulnerability/ #CyberSecurityNews #cybersecurity #Vulnerability #Namespace #AI

[Перевод] Как контейнеры работают в Kubernetes

SRE Spotify написал интересный deep dive о том, как Kubernetes управляет контейнерами, запуская их как обычные процессы Linux. Вместо теоретических рассказов о пространствах имён, cgroups и внутренностях ОС автор развернул под в Kubernetes-кластере и исследовал, что происходит вокруг него на уровне Linux. В оригинале для экспериментов использовался дистрибутив Kubernetes K3s, но наш инженер вдохновился историей и повторил все шаги на бесплатной версии нашей платформы — Deckhouse Kubernetes Platform Community Edition. Поэтому в статье теория из оригинала будет совмещена с нашей практикой. Будет полезно, если вы хотите лучше разобраться в фактических принципах работы K8s.

https://habr.com/ru/companies/flant/articles/913548/

#k8s #nginx #управление_контейнерами #оркестрация_контейнеров #linux #kubernetes #пространство_имен #namespace #контейнеры #контейнеризация

Ruby 3.5 Feature: Namespace on read

https://bugs.ruby-lang.org/issues/21311

#HackerNews #Ruby #3.5 #Namespace #RubyFeatures #RubyLang #SoftwareDevelopment #ProgrammingNews

Клиентский код. Пространство имен

Привет, Хабр! У меня появилась необходимость отделить проект от фреймворка. Благо кода фреймворка в проекте было не так много, но избавиться от него тоже нужно. Поэтому было принятно решение переписать функционал который он покрывал. Одной из используемых функций фреймворка было - построение пространства имен. Пространство имен, проще говоря, создано что-бы задавать область видимости кода для другого кода. Используя пространство имен можно гарантировать что клиентский код не будет зависить от названия: переменных, функций, класса, и всего чего угодно в коде, в том числе при подключении нескольких библиотек тоже можно не переживать. Клиентский код будет зависить только от результата работы кода. Удачно получилось что тема пересекается с моей статьей . Может если это будет серия статьей с пометкой Клиентский код, то мне получится лучше донести что же всетаки это за код такой.

https://habr.com/ru/articles/895798/

#Пространство_имен #архитектура #организация_проекта_в_ОС #namespace #Организация_кода #Клиентский_код

Мой первый контейнер без Docker

Технологии контейнеризации, возможно, как и у большинства из нас, плотно засели в моей голове. И казалось бы, просто пиши Dockerfile и не выпендривайся. Но всегда же хочется узнавать что‑то новое и углубляться в уже освоенные темы. По этой причине я решил разобраться в реализации контейнеров в ОС на базе ядра linux и в последствие создать свой «контейнер» через cmd.

https://habr.com/ru/articles/881428/

#docker #контейнер #контейнеризация #linux #namespace #cgroups #cgroup_v2

#Proxmox #Backup Server (#PBS) - Copier/Déplacer des sauvegardes à partir d'un espace de nom (#namespace) vers un autre espace de nom, sur un même entrepôt de données (#datastore) 🤙

#Proxmox #Backup Server (#PBS) - Copier/Déplacer des sauvegardes à partir d'un espace de nom (#namespace) vers un autre espace de nom, sur un même entrepôt de données (#datastore) 🤙

#Proxmox #Backup Server (#PBS) - Copier/Déplacer des sauvegardes à partir d'un espace de nom (#namespace) vers un autre espace de nom, sur un même entrepôt de données (#datastore) 🤙

#Proxmox #Backup Server (#PBS) - Copier/Déplacer des sauvegardes à partir d'un espace de nom (#namespace) vers un autre espace de nom, sur un même entrepôt de données (#datastore) 🤙

ADL – Avoid Debugging Later

Back in the day, being a witch was considered a grave crime. Today, we’re diving into one of C++’s lesser-known spells: ADL (Argument-Dependent Lookup). But before we explore this arcane magic, you must heed a warning—black magic comes with consequences. ADL is particularly treacherous, often leading to frustrating and hard-to-debug issues. Whenever possible, it’s wise to avoid casting this spell unless absolutely necessary.

Ingredients

Every spell needs ingredients, this time the only ingredients you need are a C++ compiler and a function that accepts at least one parameter, but there is a try catch, the parameter type has to belong to the same namespace of the function.

Casting the Spell

This spell works in shadows—you must look closely to uncover its effect.

std::cout << "Can you see me?";

Should the spell have passed you by, I’ll summon its power again for your eyes:

std::vector<int> a{1}, b{2};swap(a, b);

If the spell’s effect remains elusive, let’s summon the entire code for you to see:

#include <vector>int main() {    std::vector<int> a{1}, b{2};    swap(a, b);    return 0;}

And there it is, I didn’t use using namespace std; and yet I called std::swap function without the std:: prefix.

Dangerous Path

Before we dive into unveiling the syntax secrets, this is the place for warning signs. We all know that using namespace std; is considered bad practice—and for a good reason. When you import an entire namespace into your own without being fully aware of the functions and names you’re bringing in, collisions can occur. Such collisions might result in calling an unintended function or class, often one with a slightly different algorithm or mechanism (after all, there’s usually a reason for the identical naming).

Calling an unexpected function might unintentionally summon dependencies from distant, unforeseen corners of your code, and in doing so, awaken Undefined Behavior lurking quietly in the shadows, waiting for the right moment to strike.

This ‘spell’ exposes you to the exact same issue, even without explicitly using using namespace. There are situations where you may need to cast this spell to achieve generic or scalable code. However, even in those cases, you must ensure the area is clear. Treat these spell locations as dangerous and suspicious zones—mark them clearly, and suspect them first whenever a bug appears nearby.

Syntax Ritual: Unveiling the Dark Art of ADL

This spell was originally crafted to support the well-known foundation of C++ code:

std::cout << "Hello World";

This simple, foundational code uses ADL to access std::operator<<(std::ostream&, const char*), as the actual code is:

std::operator<<(std::cout, "Hello World"); // Without using ADLoperator<<(std::cout, "Hello World"); // Using ADL

The general idea behind this magic is that the compiler searches for a matching function in the current namespace and in the namespaces of each argument in the function call. For example, in the code above, the operator<< is located in the std namespace, and the argument std::cout also belongs to the same namespace.

However, there are many more rules regarding what the lookup would contain in each case. The exact rules of the ADL can be found on cppreference.

A slightly more complex example comes from my experience with the dlib library, which looks like this:

namespace dlib {    class dense_feature_extractor {    public:        friend void serialize(const dense_feature_extractor& item, std::ostream& out) {            out << "dense_feature_extractor::serialize\n";        }        friend void deserialize(dense_feature_extractor& item, std::istream& in) {            std::cout << "dense_feature_extractor::deserialize\n";        }    };        class matrix {};        void serialize(const matrix& m, std::ostream& out) {        out << "dlib::serialize(matrix)\n";    }        void deserialize(const matrix& m, std::istream& in) {        std::cout << "dlib::deserialize(matrix)\n";    }}

Now, it becomes interesting: without ADL, we can’t access the serialize and deserialize friend functions inside the dense_feature_extractor class, unless we modify the library to declare them outside the class or make them static functions within the class.

By casting a few ADL spells, we can craft the following function:

dlib::matrix m;dlib::dense_feature_extractor d;serialize(m, std::cout); // dlib::serialize(matrix)// same as: dlib::serialize(m, std::cout);serialize(d, std::cout);// dense_feature_extractor::serializedeserialize(m, std::cin); // dlib::deserialize(matrix)// same as: dlib::deserialize(m, std::cin);deserialize(d, std::cin); // dense_feature_extractor::deserialize

Since the calls appear identical, we can generalize them as follows:

template <typename T>void dlib_serializer(const T &val) {    serialize(val, std::cout);}template <typename T>void dlib_deserializer(T &val) {    deserialize(val, std::cin);}void func() {    dlib::matrix m;    dlib::dense_feature_extractor d;    dlib_serializer(m);    dlib_serializer(d);    dlib_deserializer(m);    dlib_deserializer(d);}

The Spell You Might Unintentionally Already Cast

This spell is subtle and elusive, and you may already be summoning it without even noticing—simply by forgetting the std:: prefix (or any other namespace’s arcane sigil). The silver lining is that now, armed with this knowledge, you’ll be able to spot its presence in any code that calls upon it.

Special Thanks

• Ellie Bogdanov for spelling assistance.
• ChatGPT for the logo and for grammar and spelling assistance.

#adl #advanced #ArgumentDependentLookup #C_ #coding #cpp #debug #dlib #include #Intermediate #magic #namespace #programming #spell #spells #usingNamespace

hmph. well? that's unexpected!

#namespace #php #psr4 #autoload

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

We have just released version 0.2.0 of the nethsm-cli #RustLang #crate. 🥳
This executable allows for easy integration with @nitrokey #NetHSM devices (and containers).

With this release we have added #namespace and #OpenPGP support! 🔑
Also, users can now rely on shell completion and man pages! 📚

https://crates.io/crates/nethsm-cli/0.2.0

Thanks to @wiktor for working out #OpenPGP support using #rPGP! 🎉

#CLI #HSM #encryption #decryption #DigitalSignature #signing #ArchLinux #Nitrokey #signstar

We have just released version 0.4.0 of the #nethsm #RustLang #crate. 🥳
This library allows for easy integration with @nitrokey #NetHSM devices (and containers).

With this release we have added #namespace and #OpenPGP support!
Additionally, large parts of the documentation have been improved.

https://crates.io/crates/nethsm/0.4.0

Thanks to @wiktor for working out #OpenPGP support using #rPGP! 🎉

#HSM #encryption #decryption #DigitalSignature #signing #RustLang #ArchLinux #Nitrokey #signstar

#namespace #joke #startrek #developer @humour @allstartrek

Управление секретами: путь от Opensource до Enterprise

Наша команда занимается развитием продуктов в сфере информационной безопасности в Лиге Цифровой Экономики. В этой статье хотим поделиться опытом создания нашего продукта — модуля управления инфраструктурными секретами ЦУП 2.0 на основе открытого программного обеспечения. В нашем случае это «ванильный» Vault версии 1.7, который был доступен по свободной лицензии MPL. Взяв его за основу в 2021 году, мы почти сразу столкнулись со следующими проблемами его использования: отсутствие горизонтального масштабирования; ограничение производительности при использовании в высоконагруженном режиме; неадаптивный мониторинг; узкие возможности управления доступом. Все эти проблемы нам пришлось решать, т. к. стояла задача развернуть наш модуль секретов в проекте, где он будет интегрирован с системами Mission Critical+. Как мы это сделали — расскажем подробнее в статье.

https://habr.com/ru/companies/digitalleague/articles/837302/

#информационная_безопасность #opensource #enterprise #тенанты #vault #namespace

@treyhunner

Put `__all__ = []` at the top of every module, to thwart anyone who tries to use Python's `from x import *` syntax. 😜

"Namespaces are one honking great idea -- let's do more of those!" is right in the Zen of Python.

#namespace #namespaces #import

Found these pages useful:

https://sanctum.geek.nz/presentations/trusted-networks-with-wireguard.pdf

https://www.wireguard.com/netns/

#linux #network #wireguard #vpn #namespace

#OpenStreetMap namespaces translated to #Ukrainian 🇺🇦 language : https://wiki.openstreetmap.org/wiki/Category:Uk:Namespaces

#Ukraine #repair #namespace

I wonder if anyone has seriously thought about adding some kind of namespacing to the C preprocessor.

for example, it would be nice if you could say

#namespace FOO
#include "foo.h"
#endnamespace

and then all the preprocessor defines from foo.h are brought into your file with names like FOO###BOOL

#c #preprocessor #cpreprocessor #cpp #wg14

I wonder if anyone has seriously thought about adding some kind of namespacing to the C preprocessor.

for example, it would be nice if you could say

#namespace FOO
#include "foo.h"
#endnamespace

and then all the preprocessor defines from foo.h are brought into your file with names like FOO###BOOL

#c #preprocessor #cpreprocessor #cpp #wg14

I wonder if anyone has seriously thought about adding some kind of namespacing to the C preprocessor.

for example, it would be nice if you could say

#namespace FOO
#include "foo.h"
#endnamespace

and then all the preprocessor defines from foo.h are brought into your file with names like FOO###BOOL

#c #preprocessor #cpreprocessor #cpp #wg14

I wonder if anyone has seriously thought about adding some kind of namespacing to the C preprocessor.

for example, it would be nice if you could say

#namespace FOO
#include "foo.h"
#endnamespace

and then all the preprocessor defines from foo.h are brought into your file with names like FOO###BOOL

#c #preprocessor #cpreprocessor #cpp #wg14

I wonder if anyone has seriously thought about adding some kind of namespacing to the C preprocessor.

for example, it would be nice if you could say

#namespace FOO
#include "foo.h"
#endnamespace

and then all the preprocessor defines from foo.h are brought into your file with names like FOO###BOOL

#c #preprocessor #cpreprocessor #cpp #wg14

@yantor3d

Thank you! This is one of my pet peeves, too. Tim had the namespaces thing right, but it seems like of all his Zen of Python items, this one is violated widely, continuously, and with negative consequences...

#namespace #import

Falls wir uns nicht mehr sehen:

Ich wünsche allen eine angenehme #Jahresendveranstaltung sowie einen reibungslosen Übergang in den neuen #Namespace!

@mrjhnsn I guess #IPFS - Gateways now see the same kind of abuse #Tor2Web saw half a decade ago.

In both cases the problem ain't #IPFS or #Tor but the fact that said #Gateway|s aka. public #Web - #Proxies get abused and combine the disadvantages of #SurfaceWeb and #HiddenWeb...

And with the #Namespace for #IPFS being really huge, there's no good way to prevent abuse except not operating such gateways at all...