Re: xml.etree and namespaces -- why?

f XML should be understood > identically: > > http://www.inkscape.org/namespaces/inkscape;> > > > and: > > http://www.inkscape.org/namespaces/inkscape;> > > > So you can see why e.get('inkscape:label') cannot possibly work, and why > e.g

Re: xml.etree and namespaces -- why?

I have no idea why, I used to remove namespaces, following the advice from stackoverflow: https://stackoverflow.com/questions/4255277/lxml-etree-xmlparser-remove-unwanted-namespace _ns_removal_xslt_transform = etree.XSLT(etree.fromstring('''     xmlns:xsl="http://www.w3.org/1999/XSL/Tran

Re: xml.etree and namespaces -- why?

On 2022-10-19, Robert Latest wrote: > If the XML input has namespaces, tags and attributes with prefixes > in the form prefix:sometag get expanded to {uri}sometag where the > prefix is replaced by the full URI. > > Which means that given an Element e, I cannot dire

Re: xml.etree and namespaces -- why?

self-contained Python example that illustrates my problem. I'm struggling to understand xml.etree's handling of namespaces. I'm trying to parse an Inkscape document which uses several namespaces. From etree's documentation: If the XML input has namespaces, tags and attributes with prefixes

xml.etree and namespaces -- why?

Hi all, For the impatient: Below the longish text is a fully self-contained Python example that illustrates my problem. I'm struggling to understand xml.etree's handling of namespaces. I'm trying to parse an Inkscape document which uses several namespaces. From etree's documentation

[issue45675] pkgutil.get_data() doesn't add subpackages to namespaces when importing

331 nosy: godlygeek, pablogsal priority: normal severity: normal status: open title: pkgutil.get_data() doesn't add subpackages to namespaces when importing type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Stefan Behnel added the comment: The obvious work-around is to not use a default namespace. The result is just a visual difference, not a semantic one. If someone wants to continue with the existing PR, I'll try to free some time to review any improvements. -- versions: +Python

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Daan Luttik added the comment: Is there any workaround for this? this bug still seems to be present in python 3.9.6. -- nosy: +dtluttik versions: +Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

Change by Batuhan Taskaya : -- type: security -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

Change by Ali mazloum : -- type: -> security ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

Change by Batuhan Taskaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

Batuhan Taskaya added the comment: New changeset a045991f60b51636a784623dda7ad84b5b2c6b73 by Batuhan Taskaya in branch 'main': bpo-42355: symtable.get_namespace() now checks whether there are multiple or any namespaces found (GH-23278) https://github.com/python/cpython/commit

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Change by Carl Schaefer : -- nosy: +carlschaefer ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18182] xml.dom.createElement() does not take implicit namespaces into account

Change by Irit Katriel : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +22172 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23278 ___ Python tracker ___

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

n File "/usr/local/lib/python3.10/symtable.py", line 312, in get_namespace raise ValueError("name is bound to multiple namespaces") ValueError: name is bound to multiple namespaces >>> table.lookup("A").get_namespaces() () -- assignee: BTaskaya com

[issue35617] unittest discover does not work with implicit namespaces

Change by Inada Naoki : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> unittest discovery doesn't detect namespace packages when given no parameters ___ Python tracker

Re: Friday Finking: Imports, Namespaces, Poisoning, Readability

AFAIKT the "three" are readability, naming conflicts and source location. On 05/06/2020 01:15, DL Neil via Python-list wrote: - how do you like to balance these three (and any other criteria)? Readability is king. Or queen, if you prefer. Anything that damages readability drops

Re: Friday Finking: Imports, Namespaces, Poisoning, Readability

On 2020-06-05 12:15, DL Neil via Python-list wrote: > Finking/discussion: > > - how do you like to balance these three (and any other criteria)? For most of what I do, I only ever have one such module so I'm not trying keep multiple short-names in my head concurrently. For me, it's usually

Friday Finking: Imports, Namespaces, Poisoning, Readability

How do you prefer to balance all of the above when import-ing? Python offers a number of options for importing modules, eg import module, ... from importable import object, ... most of which can be augmented with the "as preferred_name" syntax. (ignoring the much-reviled "*" (import

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Márton Marczell added the comment: Can he please get a review of the pull request? -- nosy: +marczellm ___ Python tracker ___ ___

[issue40104] ElementTree does not find elements in a default namespace with namespaces

Myron Walker added the comment: Looks like this is fixed in the latest source code. -- stage: -> resolved status: open -> closed ___ Python tracker ___

[issue40104] ElementTree does not find elements in a default namespace with namespaces

New submission from Myron Walker : When you have an xml document like the one with a default namespace below. When you try to lookup nodes in the document they are not found. ``` docTree.find("specVersion") None ``` If you add a namespaces map with the '' key and the default names

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

STINNER Victor added the comment: New changeset ace018ca47c03ca699603341b12781b5329d2eaa by Victor Stinner in branch 'master': bpo-40050: Rephrase NEWS entry (GH-19148) https://github.com/python/cpython/commit/ace018ca47c03ca699603341b12781b5329d2eaa --

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

Change by STINNER Victor : -- pull_requests: +18509 pull_request: https://github.com/python/cpython/pull/19148 ___ Python tracker ___

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

STINNER Victor added the comment: Since this reference leak is fixed, I reapplied Hai Shi's change for _weakref in bpo-1635741: New changeset 93460d097f50db0870161a63911d61ce3c5f4583 by Victor Stinner in branch 'master': bpo-1635741: Port _weakref extension module to multiphase

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

STINNER Victor added the comment: I close the issue. I pushed commit 83d46e0622d2efdf5f3bf8bf8904d0dcb55fc322 which should not be controversial. In short, the fix is to remove two unused imports :-D The fix doesn't remove module.__spec__ nor avoid usage of _weakref, it only fix this issue

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

he sys module. * Maybe module.__spec__ should leak less importlib internals: explicitly clear namespaces? Use static methods? I'm not sure how to do that. Are you saying change everything on __spec__ objects to be static methods? That won't work because the whole point of __spec__ objects is t

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

STINNER Victor added the comment: New changeset 83d46e0622d2efdf5f3bf8bf8904d0dcb55fc322 by Victor Stinner in branch 'master': bpo-40050: Fix importlib._bootstrap_external (GH-19135) https://github.com/python/cpython/commit/83d46e0622d2efdf5f3bf8bf8904d0dcb55fc322 --

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

Change by STINNER Victor : -- pull_requests: +18496 pull_request: https://github.com/python/cpython/pull/19135 ___ Python tracker ___

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

STINNER Victor added the comment: > Before _weakref is converted to multiphase initialization: > (...) > => same module That's because modules which don't use the multiphase initialization are cached in _PyImport_FixupExtensionObject(): see msg364914 for details. Next calls to

[issue40050] importlib: module.__spec__ leaks importlib namespaces (test_importlib leaked xxx references)

tlib should before save/restore the the "Python state" rather than modifying modules * Maybe module.__spec__ should leak less importlib internals: explicitly clear namespaces? Use static methods? I'm not sure how to do that. * Remove module.__spec__? ... that would mean rejecting PEP 4

[issue35617] unittest discover does not work with implicit namespaces

Change by Phil Connell : -- nosy: +pconnell ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Maarten ter Huurne added the comment: Can I please get a review of the pull request? -- ___ Python tracker ___ ___

[issue18182] xml.dom.createElement() does not take implicit namespaces into account

karl added the comment: The current specification as of today documents https://dom.spec.whatwg.org/#dom-document-createelementns If you run this in the browser console, var nsdoc = 'http://foo.bar/zoo'; var xmldoc = document.implementation.createDocument(nsdoc, 'Zoo', null); var cpd =

[issue35617] unittest discover does not work with implicit namespaces

Change by Roger Gammans : -- nosy: +rgammans ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13378] ET: add custom namespaces to serialization methods

STINNER Victor added the comment: This issue is 8 years old and has already 3 patches attached, it is not newcomer friendly: I remove the "easy" keyword. -- keywords: -easy nosy: +vstinner ___ Python tracker

Re: Namespaces: memory vs 'pollution'

On 07/22/2019 08:12 PM, DL Neil wrote: On 22/07/19 9:40 PM, Thomas Jollans wrote: Just FYI, in the scientific Python community certain short abbreviations are the norm. Many modules have a ‘standard’ abbreviation that most people use, minimizing confusion. import numpy as np import

Re: Namespaces: memory vs 'pollution'

On 07/22/2019 07:27 PM, DL Neil wrote: NameError conveys nothing to the user. PythonVersionError is more communicative - and speaks volumes to 'us'. The mainline code is something like: p = PythonEnvironment() try:     p.compatibility( ...spec... )    # eg must be Py3 not 2.n  

Re: Namespaces: memory vs 'pollution'

On 23/07/2019 04.27, DL Neil wrote: > On 23/07/19 11:00 AM, Ethan Furman wrote: >> On 07/20/2019 05:02 PM, DL Neil wrote: >> >>> Upon closer inspection, I realised it didn't just fail; it failed >>> badly! Some silly, little, boy had imported the PythonEnvironment >>> class but failed to ALSO

Re: Namespaces: memory vs 'pollution'

On 23/07/2019 03:27, DL Neil wrote: On 23/07/19 11:00 AM, Ethan Furman wrote: On 07/20/2019 05:02 PM, DL Neil wrote: Upon closer inspection, I realised it didn't just fail; it failed badly! Some silly, little, boy had imported the PythonEnvironment class but failed to ALSO import

Re: Namespaces: memory vs 'pollution'

On 22/07/19 9:40 PM, Thomas Jollans wrote: On 22/07/2019 07.06, DL Neil wrote: Current thoughts: import environment_module as em - so, even more of an abbreviation than suggested!? - I rarely need to write a long list of import statements, so there won't be many. - not normally using

Re: Namespaces: memory vs 'pollution'

On 23/07/19 11:00 AM, Ethan Furman wrote: On 07/20/2019 05:02 PM, DL Neil wrote: Upon closer inspection, I realised it didn't just fail; it failed badly! Some silly, little, boy had imported the PythonEnvironment class but failed to ALSO import PythonVersionError. So, the reported error was

Re: Namespaces: memory vs 'pollution'

On 22/07/2019 07.06, DL Neil wrote: > > Current thoughts: > > import environment_module as em > > - so, even more of an abbreviation than suggested!? > - I rarely need to write a long list of import statements, so there > won't be many. > - not normally using such abbreviations in my code,

Re: Namespaces: memory vs 'pollution'

On 07/20/2019 05:02 PM, DL Neil wrote: Upon closer inspection, I realised it didn't just fail; it failed badly! Some silly, little, boy had imported the PythonEnvironment class but failed to ALSO import PythonVersionError. So, the reported error was not the expected exception! I don't

Re: Namespaces: memory vs 'pollution'

On 22/07/19 5:30 AM, Roel Schroeven wrote: DL Neil schreef op 21/07/2019 om 2:02: How do you remember to from-import- 'everything' that is needed? ... > Upon closer inspection, I realised it didn't just fail; it failed badly! Some silly, little, boy had imported the PythonEnvironment class

Re: Namespaces: memory vs 'pollution'

DL Neil schreef op 21/07/2019 om 2:02: How do you remember to from-import- 'everything' that is needed? ... > Upon closer inspection, I realised it didn't just fail; it failed badly! Some silly, little, boy had imported the PythonEnvironment class but failed to ALSO import PythonVersionError.

Re: Namespaces: memory vs 'pollution'

On 2019-07-21 12:02:27 +1200, DL Neil wrote: > What do you do to (respecting purism) ensure 'everything' (necessary) is > imported (and nothing more), preferably without relying upon (faulty, in my > case) human-memory or reading through volumes of code/documentation? I write tests (not as

Namespaces: memory vs 'pollution'

How do you remember to from-import- 'everything' that is needed? I have a 'utility module' which contains a bunch of classes which examine/check/log aspects of the execution environment. One of which is PythonEnvironment, another relates to the HostSystem (as examples). They are

[issue35617] unittest discover does not work with implicit namespaces

Terry J. Reedy added the comment: If this is truly a duplicate, this should be closed and the issue number in the pr title changed to 23882. Any reviewer should look at both proposed fixes, as they are not the same. The other patch has what looks like the beginning of a test. --

[issue35617] unittest discover does not work with implicit namespaces

Emmanuel Arias added the comment: Hi! IMO its a good propose. You will have to modify some tests. -- nosy: +eamanu versions: +Python 3.8 ___ Python tracker ___

[issue35617] unittest discover does not work with implicit namespaces

Simon Fagerholm added the comment: Martin: Yeah, they same to be same! Can't believe I didn't find it -- ___ Python tracker ___

[issue35617] unittest discover does not work with implicit namespaces

Martin Panter added the comment: Is this related to Issue 23882? That one is about making discovery work when “__init__.py” files are removed. -- nosy: +martin.panter ___ Python tracker

[issue35617] unittest discover does not work with implicit namespaces

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35617] unittest discover does not work with implicit namespaces

Simon Fagerholm added the comment: Issue originally from SO: https://stackoverflow.com/questions/46976256/recursive-unittest-discovery-with-python3-and-without-init-py-files -- ___ Python tracker

[issue35617] unittest discover does not work with implicit namespaces

Change by Roundup Robot : -- keywords: +patch, patch, patch pull_requests: +10691, 10692, 10693 stage: -> patch review ___ Python tracker ___

[issue35617] unittest discover does not work with implicit namespaces

Change by Roundup Robot : -- keywords: +patch pull_requests: +10691 stage: -> patch review ___ Python tracker ___ ___

[issue35617] unittest discover does not work with implicit namespaces

Change by Roundup Robot : -- keywords: +patch, patch, patch, patch pull_requests: +10691, 10692, 10693, 10694 stage: -> patch review ___ Python tracker ___

[issue35617] unittest discover does not work with implicit namespaces

Change by Roundup Robot : -- keywords: +patch, patch pull_requests: +10691, 10692 stage: -> patch review ___ Python tracker ___

[issue35617] unittest discover does not work with implicit namespaces

_thing1.py -- components: Library (Lib) messages: 332748 nosy: Simon Fagerholm priority: normal severity: normal status: open title: unittest discover does not work with implicit namespaces type: behavior versions: Python 3.7 ___ Python tracker <https://bu

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Maarten ter Huurne added the comment: I think I have a good solution now, see the pull request for details. It does touch a lot of code, but I split all the changes into small consistent units, so it should be easier to verify whether they are correct. --

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Change by Maarten ter Huurne : -- pull_requests: +10286 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Maarten ter Huurne added the comment: I was working on what I thought would be an elegant solution to this problem: for non-qualified attributes, add the element's namespace before accessing the cache and strip the namespace prefix after accessing the cache if it's equal to the element's

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Change by Роман Донченко : -- nosy: +SpecLad ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Rafael Ascensao added the comment: what's the status on this? -- nosy: +Rafael Ascensao ___ Python tracker ___

Re: How do native namespaces work?

Thomas Nyberg wrote: > Hello, > > I'm trying to understand native namespaces. I'm currently using python > 3.5 as packaged in debian 9. I've been following the instructions here: > > https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-p

Re: How do native namespaces work?

On 10/05/2017 04:07 PM, Peter Otten wrote: > Are you sure you are using the correct interpreter? When I activate a > virtual environment it changes the prompt like so: Sorry I just cut out the extra cruft from my prompt for clarity. (In hindsight, I should probably have left the `(venv)` prompt

Re: How do native namespaces work?

Thomas Nyberg wrote: > Hello, > > I'm trying to understand native namespaces. I'm currently using python > 3.5 as packaged in debian 9. I've been following the instructions here: > > https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-p

How do native namespaces work?

Hello, I'm trying to understand native namespaces. I'm currently using python 3.5 as packaged in debian 9. I've been following the instructions here: https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-packages Those instructions link to the following

Re: Namespaces are one honking great idea

Hi all, although it doesn't fit the bill 100%, I sometimes use this extremely simple function as a decorator: def new(call): return call() For example: @new class MySingleton: x = 2 y = 2 def sum(self, x, y): return x + y @new def my_obj(): x = 2 y = 2

A nestedmodule decorator (Re: Namespaces are one honking great idea)

Steven D'Aprano wrote: There's only so far I can go without support from the compiler. It turns out one can go surprisingly far. Here's something I cooked up that seems to meet almost all the requirements. The only shortcoming I can think of is that a nestedmodule inside another nestedmodule

Re: Namespaces are one honking great idea

t;just unindent and move to a new > file if you want to break it out" equivalency, but it does make sense > - it's a *nested* namespace, which modules (even in a package) are > not. So you have the outer namespace acting pretty much the way > builtins do. (Do nested namespaces work?) I ha

Re: Namespaces are one honking great idea

ch modules (even in a package) are not. So you have the outer namespace acting pretty much the way builtins do. (Do nested namespaces work?) ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

On Tue, 5 Jul 2016 12:58 pm, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano > wrote: >> *** IF *** you are willing to push the code out into its own separate .py >> file, you can use a module and write your code in a more natural form: >> >> >> #

Re: Namespaces are one honking great idea

On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano wrote: > *** IF *** you are willing to push the code out into its own separate .py > file, you can use a module and write your code in a more natural form: > > > # module example.py > var = 999 > > def spam(arg): > return

Re: Namespaces are one honking great idea

inheritance. Classes should be used for >> "is-a" relationships, not "has-a" relationships. Although classes (and >> instances) are namespaces, they provide fundamentally different kind of >> behaviour than modules and packages. > > A namespace would

Re: Namespaces are one honking great idea

On Tuesday, July 5, 2016 at 10:10:04 AM UTC+12, I wrote: > > On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > > > Functions within the namespace can't call other functions within the > > same namespace using unqualified names. This was a stated requirement. > > Doesn’t my

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > Functions within the namespace can't call other functions within the > same namespace using unqualified names. This was a stated requirement. Doesn’t my @namespace decorator provide that? --

Re: Namespaces are one honking great idea

espace grouping related entities. Classes support inheritance. Classes should be used for "is-a" relationships, not "has-a" relationships. Although classes (and instances) are namespaces, they provide fundamentally different kind of behaviour than modules and packages. A name

Re: Namespaces are one honking great idea

elated >> entities. Classes support inheritance. Classes should be used for "is-a" >> relationships, not "has-a" relationships. Although classes (and instances) >> are namespaces, they provide fundamentally different kind of behaviour >> than >> modu

Re: Namespaces are one honking great idea

, not "has-a" relationships. Although classes (and instances) are namespaces, they provide fundamentally different kind of behaviour than modules and packages. A namespace would not hurt but I really don't get why you don't consider classes a valid and rather helpful namespace. 1/

Re: Namespaces are one honking great idea

On 07/03/2016 03:02 PM, Kevin Conway wrote: >At some point earlier Ethan Furman declared: It's not a language change. Perhaps. My argument is that anything that introduces a new class-like construct and set of lexical scoping rules is a language change. For example, if this change went into

Re: Namespaces are one honking great idea

On 04/07/2016 00:21, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: If the problem with using classes to satisfy the namespace need is that it's unwieldy to use dot qualified paths then isn't that quite similar to saying namespaces are unwieldy

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: > If the problem with using classes to satisfy the namespace need is > that it's unwieldy to use dot qualified paths then isn't that quite similar > to saying namespaces are unwieldy? Python has a simple

Re: Namespaces are one honking great idea

refer to each > other by their dotted names. My response to this may come off as a bit glib, but it isn't intended that way. If the problem with using classes to satisfy the namespace need is that it's unwieldy to use dot qualified paths then isn't that quite similar to saying namespaces are unwi

Re: Namespaces are one honking great idea

On 07/02/2016 08:44 PM, Steven D'Aprano wrote: Try getting this behaviour from within a class: class Food(metaclass=Namespace): # (1) no special decorators required def spam(n): return ' '.join(['spam']*n) # (2) can call functions from inside the namespace

Re: Namespaces are one honking great idea

On Sun, 3 Jul 2016 01:34 am, Kevin Conway wrote: > staticmethod isn't technically required to use a method through the class > (or subclasses), it simply provides the appropriate magic to allow it to > be called through instances. > > For example, the following code covers all described use

Re: Namespaces are one honking great idea

attern. In other words, exactly not like a class *wink* Classes and modules are both namespaces: "an abstract container or environment created to hold a logical grouping of unique identifiers or symbols (i.e. names)", to quote Wikipedia: https://en.wikipedia.org/wiki/Namespa

Re: Namespaces are one honking great idea

On 07/02/2016 08:34 AM, Kevin Conway wrote: For the proponents of namespace, what is deficient in the above example that necessitates a language change? Adding a new widget is not changing the language. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

> staticmethod isn't technically required to use a method through the class (or subclasses), it simply provides the appropriate magic to allow it to be called through instances. For example, the following code covers all described use cases of the proposed namespace. Methods are invoked without

Re: Namespaces are one honking great idea

On Fri, Jul 1, 2016, at 21:50, Kevin Conway wrote: > I believe the namespace object you are referring to is exactly a > class. IIRC, classes came about as a "module in a module". No, because classes have instances. And conceptually they seem like they *should* have instances. Just using the term

Re: Namespaces are one honking great idea

On Saturday, July 2, 2016 at 1:50:56 PM UTC+12, Kevin Conway wrote: > Regardless, all use cases you've listed are already satisfied by use of the > static and class method decorators. Except for the need to decorate every such function inside the class. How about: import types def

Re: Namespaces are one honking great idea

On Friday, July 1, 2016 at 8:19:36 PM UTC+5:30, BartC wrote: > On 01/07/2016 15:13, Steven D'Aprano wrote: > > > Sometimes we have a group of related functions and variables that belong > > together, but are not sufficiently unrelated to the rest of the module that > > we want to split them out

Re: Namespaces are one honking great idea

I believe the namespace object you are referring to is exactly a class. IIRC, classes came about as a "module in a module". Regardless, all use cases you've listed are already satisfied by use of the static and class method decorators. Methods decorated with these do not require an instance

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 05:29 am, Ethan Furman wrote: > On 07/01/2016 10:10 AM, Steven D'Aprano wrote: >> On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: > >>> Did you mean for this to go to -Ideas? >> >> Not yet. I wanted some initial feedback to see if anyone else liked the >> idea before taking

Re: Namespaces are one honking great idea

On 07/01/2016 10:10 AM, Steven D'Aprano wrote: On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: Did you mean for this to go to -Ideas? Not yet. I wanted some initial feedback to see if anyone else liked the idea before taking it to Bikeshedding Central :-) Besides, I expect Python-Ideas

Re: Namespaces are one honking great idea

But if you use a metaclass (usually, but not necessarily a subclass of `type`) you can customize the creation of the new class, or even return a completely different object altogether. That's what I'm doing. Why am I returning a module instead of a class? Because (1) conceptually a namespace (i

Re: Namespaces are one honking great idea

f Python's lack of dedicated >> syntax for namespaces), the Example namespace behaves like (in fact, >> *is*) a module embedded inside a module. > > So the idea is to have several "mini-modules" inside a single file? That would certainly be possible. > Can a mini-modu

  1   2   3   4   5   6   7   >