[issue46571] Strange `@typing.no_type_check` behavior for class variables

Jelle Zijlstra added the comment: Thanks for the fix Nikita! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Jelle Zijlstra added the comment: New changeset 395029b0bd343648b4da8044c7509672ea768775 by Nikita Sobolev in branch 'main': bpo-46571: improve `typing.no_type_check` to skip foreign objects (GH-31042) https://github.com/python/cpython/commit/395029b0bd343648b4da8044c7509672ea768775

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29224 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31042 ___ Python tracker ___

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: Okay, somebody can submit a PR! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Jelle Zijlstra added the comment: I think we could do it by looking at __qualname__. -- ___ Python tracker ___ ___

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: I agree that Jelle's proposal (Nikita's #2) looks best *if* we can implement it. How do we ensure that class A: ... @no_type_check class B: AA = A class C: ... ... suppresses annotations in B and C but not in A? --

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Jelle Zijlstra added the comment: 1. Less change in behavior 2. From the purpose of the decorator, it makes sense for it to apply to nested classes as well as methods, even if the docs don't say so explicitly. -- ___ Python tracker

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Nikita Sobolev added the comment: Ken Jin, Jelle, can you please share your ideas why `(2)` is better than `(1)`? -- ___ Python tracker ___

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Alex Waygood added the comment: I fully withdraw my suggestion of deprecating the decorator; it's evidently used more than I realised. I don't have any strong opinion on whether (1) or (2) would be a better solution. -- ___ Python tracker

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Ken Jin added the comment: I agree with Jelle, let's go with (2). It feels strange to have a decorator modify types that it doesn't own. -- ___ Python tracker ___

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Nikita Sobolev added the comment: ## 1. What is documented? The docs makes this even more weird! > @typing.no_type_check > Decorator to indicate that annotations are not type hints. > This works as class or function decorator. With a class, it applies > recursively to all methods defined in

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: @no_type_check (introduced by PEP 484) is intended for static checkers, to signal to them that they shouldn't check the given function or class. I don't think PEP 484 specifies its runtime effect -- arguably get_type_hints() could just ignore it. Or raise

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Jelle Zijlstra added the comment: Let's not jump into deprecating it. I think (2) makes the most sense. If we can get that working reliably (using __qualname__ I assume), it would be my preference; otherwise we should do (1). This problem can also affect function objects, right? `class B:

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Alex Waygood added the comment: ...Option 3). Deprecate @no_type_check? Maybe we should gather some stats on how many people are using @no_type_check? My feeling is that it's never achieved widespread adoption, so maybe it's just not that useful a thing to have in the stdlib. Anyway, the

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Change by Nikita Sobolev : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46571] Strange `@typing.no_type_check` behavior for class variables

: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: Strange `@typing.no_type_check` behavior for class variables versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46

[issue43257] get_type_hints evaluates class variables before type hints

Ken Jin added the comment: Rejecting this since annotations are expressions that have side effects (so anti-patterns are discouraged). If you *really* want this, I suspect str: "str"="asdf" or using `from __future__ import annotations` will work. -- resolution: -> not a bug stage:

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: You're welcome. Thank you for pushing the issue! :-) -- ___ Python tracker ___ ___

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Miro Hrončok added the comment: Thank you, Ethan. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43162] Enum regression: AttributeError when accessing class variables on instances

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

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: New changeset 44e580f448016b86807465a186d03d9074e2b589 by Ethan Furman in branch 'master': bpo-43162: [Enum] update docs, renable doc tests (GH-24487) https://github.com/python/cpython/commit/44e580f448016b86807465a186d03d9074e2b589 --

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: DeprecationWarning will be active in 3.10 and 3.11 with removal in 3.12. -- ___ Python tracker ___

[issue43257] get_type_hints evaluates class variables before type hints

Guido van Rossum added the comment: Oops, I realized it's not really a compiler bug. When the compiler sees class C: str: str = "abc" if effectively rearranges that to class C: str = "abc" __annotations__["str"] = str (where __annotations__ is initialized to {} at the start of

[issue43257] get_type_hints evaluates class variables before type hints

Guido van Rossum added the comment: Sure looks like a compiler bug! Can you investigate whether this occurs in earlier Python versions? Maybe bisect if it doesn’t? -- ___ Python tracker

[issue43257] get_type_hints evaluates class variables before type hints

Ken Jin added the comment: Hmm I noticed this occurs in Python 3.9 but not 3.10. If you insert ``from __future__ import annotations`` at the start of your code, it stops erroring. Anyways, I don't think this is dataclass specific, the following code using a plain class also errors: ```

[issue43257] get_type_hints evaluates class variables before type hints

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

[issue43257] get_type_hints evaluates class variables before type hints

s().datetime ... datetime.datetime(2021, 2, 18, 12, 47, 56, 608261) -- messages: 387266 nosy: xirdneh priority: normal severity: normal status: open title: get_type_hints evaluates class variables before type hints

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Miro Hrončok added the comment: "Wait for the warning to appear in at least two major Python versions. It's fine to wait more than two releases." https://www.python.org/dev/peps/pep-0387/#basic-policy-for-backwards-compatibility So indeed, if you add the warning in 3.10, the behavior can be

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Change by Ethan Furman : -- pull_requests: +23277 pull_request: https://github.com/python/cpython/pull/24487 ___ Python tracker ___

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: Dylan, it's not the `from_str()` method, but the `__str__` method that is the problem. Instead of def __str__(self): if self is self.EXITCODE: return 'exitcode' it should be def __str__(self): cls = self.__class__

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: New changeset d65b9033d6d092552775f6f5e41e7647100f9f2c by Ethan Furman in branch 'master': bpo-43162: [Enum] deprecate enum member.member access (GH-24486) https://github.com/python/cpython/commit/d65b9033d6d092552775f6f5e41e7647100f9f2c --

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Miro Hrončok added the comment: Ethan, should the depreciation exist for 2 releases prior to removal? Dylan, even in that case, I guess the proper way to access the other members is supposed to be type(self).FOO or ClassName.FOO, not self.FOO. --

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Dylan Baker added the comment: Author of said meson code here. I use this pattern when the enum names and values are implementation details, but the string values are user visible. In this case the enum itself is used internally to represent what kind of test we're doing, but we're

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Change by Ethan Furman : -- keywords: +patch pull_requests: +23276 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/24486 ___ Python tracker

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Miro Hrončok added the comment: Thanks. In the meantime, I've opened https://github.com/mesonbuild/meson/issues/8318 -- ___ Python tracker ___

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Ethan Furman added the comment: The code for that `__str__` seems very inefficient -- why doesn't it just do: return self.name ? - The issue is not being able to access class attributes, the issue is whether one enum member should be seen as an attribute of another:

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Miro Hrončok added the comment: Git bisect: c314e60388282d9829762fb6c30b12e2807caa19 is the first new commit commit c314e60388282d9829762fb6c30b12e2807caa19 Author: Ethan Furman Date: Tue Jan 12 23:47:57 2021 -0800 bpo-42901: [Enum] move member creation to `__set_name__` (GH-24196)

[issue43162] Enum regression: AttributeError when accessing class variables on instances

ecated in Python 3.9 and 3.8. -- components: Library (Lib) messages: 386626 nosy: hroncok priority: normal severity: normal status: open title: Enum regression: AttributeError when accessing class variables on instances type: behavior versions: Python 3.10 ___

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Terry J. Reedy added the comment: New changeset 488aabafe2f1c5db05a6c1a7a8b49d7b89b1f36b by Terry Jan Reedy (Miss Islington (bot)) in branch '3.7': bpo-36096: IDLE: Refactor class variables in colorizer (GH-12002) (GH-12075) https://github.com/python/cpython/commit

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Change by miss-islington : -- pull_requests: +12094 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Change by miss-islington : -- pull_requests: +12089 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Cheryl Sabella added the comment: New changeset ed1deb0719f0ac1b08a374e30ad26a701d4d51a2 by Cheryl Sabella in branch 'master': bpo-36096: IDLE: Refactor class variables in colorizer (GH-12002) https://github.com/python/cpython/commit/ed1deb0719f0ac1b08a374e30ad26a701d4d51a2

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

Change by Cheryl Sabella : -- keywords: +patch pull_requests: +12033 stage: -> patch review ___ Python tracker ___ ___

[issue36096] IDLE: Refactor class variables to instance variables in colorizer

New submission from Cheryl Sabella : >From Terry's comment on PR11472 for issue 35689: > I don't like the use of class variables to initialize volatile instance state > variables. I think it confuses the code a bit. Better, I think, to put them > in an `init_state` method

[issue36012] Investigate slow writes to class variables

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

[issue36012] Investigate slow writes to class variables

Raymond Hettinger added the comment: New changeset d8b9e1fc2e45d2bc3f4a9737c375f2adb8a8c7de by Raymond Hettinger (Stefan Behnel) in branch 'master': bpo-36012: Avoid linear slot search for non-dunder methods (GH-11907)

[issue36012] Investigate slow writes to class variables

Raymond Hettinger added the comment: Thanks Neil. The tooling does indeed look nice. I added your PyUnicode_InternInPlace() suggestion to the PR. At this point, the PR looks ready-to-go unless any of you think we've missed some low-hanging fruit. --

[issue36012] Investigate slow writes to class variables

Neil Schemenauer added the comment: BTW, 'perf report [...]' has a really neat annotated assembly view. Scroll to the function you are interested in and press 'a'. Press 't' to toggle the time units (left side numbers). I'm attaching a screenshot of the disassembly of the lookdict

[issue36012] Investigate slow writes to class variables

Neil Schemenauer added the comment: Some profiling using 'perf'. This is for cpython 63fa1cfece4912110ce3a0ff11fb3ade3ff5e756. children self [...] + 97.27% 0.00% run_mod (inlined) + 88.53% 6.33% PyObject_SetAttr + 79.34% 6.80% type_setattro + 43.92%43.92%

[issue36012] Investigate slow writes to class variables

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36012] Investigate slow writes to class variables

Raymond Hettinger added the comment: Wow, I didn't expect to get an immediate win this of this magnitude :-) -- ___ Python tracker ___

[issue36012] Investigate slow writes to class variables

Pablo Galindo Salgado added the comment: This are the timings that I am measuring with PR 11907: Variable and attribute read access: 5.7 ns read_local 5.9 ns read_nonlocal 16.2 ns read_global 24.5 ns read_builtin 20.9 ns read_classvar_from_class

[issue36012] Investigate slow writes to class variables

Stefan Behnel added the comment: It turns out that "update_slot()" is always called, even when we are not updating a slot name (which is always a special dunder-name). The linear search for names in "update_slots()" is a huge waste of time here, and short-circuiting out of it when the name

[issue36012] Investigate slow writes to class variables

Change by Stefan Behnel : -- keywords: +patch pull_requests: +11932 stage: -> patch review ___ Python tracker ___ ___

[issue36012] Investigate slow writes to class variables

Raymond Hettinger added the comment: > can you include your python 2.7 runs? for me it looks similar It will give similar results unless you switch to old-style classes (edit out the inheritance from object). class A: pass A.x = 1 --- $

[issue36012] Investigate slow writes to class variables

Yasser Alshalaan added the comment: can you include your python 2.7 runs? for me it looks similar -- nosy: +Yasser Alshalaan ___ Python tracker ___

[issue36012] Investigate slow writes to class variables

Pablo Galindo Salgado added the comment: It seems 50% of the overhead (50ns) is due to two reasons: - 30-40% is due to the call to update_slot(type, name) after the item is set in the class dictionary. - 70-60% is due to all the extra work from _PyObject_GenericSetAttrWithDict until it

[issue36012] Investigate slow writes to class variables

New submission from Raymond Hettinger : Benchmark show what writes to class variables are anomalously slow. class A(object): pass A.x = 1 # This write is 3 to 5 times slower than other writes. FWIW, the same operation for old-style classes in Python 2.7 was several times

[issue33796] dataclasses.replace broken with class variables

Eric V. Smith added the comment: Ah, you're right. I did misunderstand. Thanks for correcting me. PR soon. -- nosy: +ned.deily priority: normal -> release blocker ___ Python tracker

[issue33796] dataclasses.replace broken with class variables

Sigurd Ljødal added the comment: I think you misunderstood the issue here. I'm not trying to replace the class variable itself, I'm changing another field on a class that has a class variable. The problem is that the replace method includes the class variable in the change dict when copying

[issue33796] dataclasses.replace broken with class variables

Eric V. Smith added the comment: Thanks for the report. This is the same error you get when using any non-field: >>> @dataclass ... class C: ... i: int ... >>> c = C(4) >>> replace(c, i=3) C(i=3) >>> replace(c, j=3) Traceback (most recent call last): File "", line 1, in File

[issue33796] dataclasses.replace broken with class variables

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

[issue33796] dataclasses.replace broken with class variables

New submission from Sigurd Ljødal : The dataclasses.replace function does not work for classes that have class variables. See the console output below for an example. $ python Python 3.7.0b5+ (heads/3.7:3c417610ad, Jun 7 2018, 16:21:29) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "

[issue30577] Multidimensional comprehensions cannot access class variables except in the first for

Changes by Zachary Ware : -- stage: -> resolved status: open -> closed superseder: -> Comprehensions in a class definition mostly cannot access class variable ___ Python tracker

[issue30577] Multidimensional comprehensions cannot access class variables except in the first for

Fengyang Wang added the comment: It looks like this is a duplicate of http://bugs.python.org/issue11796 Sorry for the noise. -- resolution: -> duplicate ___ Python tracker

[issue30577] Multidimensional comprehensions cannot access class variables except in the first for

Fengyang Wang added the comment: By the way, in Python 2.7 at least, this was working. -- ___ Python tracker ___

[issue30577] Multidimensional comprehensions cannot access class variables except in the first for

t class Y: r = [1, 2, 3] z = [(i, j) for j in r for i in [4, 5]] does not fail. (Version 3.5.2 on Windows) -- components: Interpreter Core messages: 295220 nosy: fengyang.wang priority: normal severity: normal status: open title: Multidimensional comprehensions cannot access class

DRY and class variables

My classes correspond to sql tables. In these classes I want to have several class variables that refer to data that are common to all instances. The assignment statements for the class variables are the same in all classes, except that of these instructions needs the name of the class itself

Re: DRY and class variables

On 08/09/11 11:55, egbert wrote: My classes correspond to sql tables. In these classes I want to have several class variables that refer to data that are common to all instances. The assignment statements for the class variables are the same in all classes, except that of these instructions

Re: DRY and class variables

On Thu, Sep 8, 2011 at 3:55 AM, egbert egber...@xs4all.nl wrote: My classes correspond to sql tables. In these classes I want to have several class variables that refer to data that are common to all instances. The assignment statements for the class variables are the same in all classes

Re: DRY and class variables

On Thu, Sep 08, 2011 at 12:22:33PM +0200, Thomas Jollans wrote: You should be able to do this with a metaclass (almost certainly overkill), or with a class decorator (Python 2.6+): def with_metadata (cls): cls.m = Metadata (cls.__name__) cls.m.do_something () return cls

Re: use class factory to set required class variables?

On Wed, 26 Jan 2011 13:37:20 -0800, Alan wrote: I have a class ``A`` that is intentionally incomplete: it has methods that refer to class variables that do not exist. For the record, in Python it is usual to refer to attributes rather than class variables and instance variables. In Python

Re: use class factory to set required class variables?

Alan wrote: I have a class ``A`` that is intentionally incomplete: it has methods that refer to class variables that do not exist. The class ``A`` has several complicated methods, a number of which reference the missing class variables. Obviously, I do not directly use ``A``. I have a class

Re: use class factory to set required class variables?

On Jan 27, 2011, at 4:03 AM, Steven D'Aprano wrote: On Wed, 26 Jan 2011 13:37:20 -0800, Alan wrote: I have a class ``A`` that is intentionally incomplete: it has methods that refer to class variables that do not exist. For the record, in Python it is usual to refer to attributes rather

use class factory to set required class variables?

I have a class ``A`` that is intentionally incomplete: it has methods that refer to class variables that do not exist. The class ``A`` has several complicated methods, a number of which reference the missing class variables. Obviously, I do not directly use ``A``. I have a class factory ``f

Re: use class factory to set required class variables?

On Jan 26, 4:37 pm, Alan alan.is...@gmail.com wrote: I have a class factory ``f``` that subclasses ``A`` *only* in order to define the class variables. I suppose it would be clearer to say that `f` *returns* subclasses of `A`. Hopefully that was clear ... Alan Isaac -- http://mail.python.org

Re: scope of generators, class variables, resulting in global na

break? 2. What are the advantages of making the scope of class variables different? Maybe is it just a historical trait? See the discussion in the PEP for introducing nested scopes in the first place: http://www.python.org/dev/peps/pep-0227/ Thanks. That is really useful. I just read

Re: scope of generators, class variables, resulting in global na

. What would this suggestion break? 2. What are the advantages of making the scope of class variables different? Maybe is it just a historical trait? Cheers, Leo. -- http://mail.python.org/mailman/listinfo/python-list

Re: scope of generators, class variables, resulting in global na

On Feb 27, 2010, at 6:57 PM, dontspamleo wrote: http://bioscreencastwiki.com/Python_Variable_scope_gymnastics Broken link: Site settings could not be loaded We were unable to locate the API to request site settings. Please see below for debugging information. HTTP Response Status Code:

Re: scope of generators, class variables, resulting in global na

of making the scope of class variables different? Maybe is it just a historical trait? See the discussion in the PEP for introducing nested scopes in the first place: http://www.python.org/dev/peps/pep-0227/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: scope of generators, class variables, resulting in global na

Hi Arnaud et al, Here is the link to the bug report from which the discussion in PEP 289 was extracted: http://bugs.python.org/issue872326 It looks like they were fixing a bunch of bugs and that this discussion was one of the many in that thread. Here is another post which points to the core

Re: scope of generators, class variables, resulting in global na

dontspamleo dontsendleos...@gmail.com writes: Hi Arnaud et al, Here is the link to the bug report from which the discussion in PEP 289 was extracted: http://bugs.python.org/issue872326 It looks like they were fixing a bunch of bugs and that this discussion was one of the many in that

scope of generators, class variables, resulting in global na

Hello, Can someone help me understand what is wrong with this example? class T: A = range(2) B = range(4) s = sum(i*j for i in A for j in B) It produces the exception: type 'exceptions.NameError': global name 'j' is not defined The exception above is especially confusing since the

Re: scope of generators, class variables, resulting in global na

* Nomen Nescio: Hello, Can someone help me understand what is wrong with this example? class T: A = range(2) B = range(4) s = sum(i*j for i in A for j in B) It produces the exception: type 'exceptions.NameError': global name 'j' is not defined Which Python implementation are you

Re: scope of generators, class variables, resulting in global na

On Feb 24, 5:52 am, Nomen Nescio nob...@dizum.com wrote: Hello, Can someone help me understand what is wrong with this example? class T:   A = range(2)   B = range(4)   s = sum(i*j for i in A for j in B) It produces the exception: type 'exceptions.NameError': global name 'j' is not

Re: scope of generators, class variables, resulting in global na

On Feb 24, 12:21 pm, Alf P. Steinbach al...@start.no wrote: * Nomen Nescio: Hello, Can someone help me understand what is wrong with this example? class T:   A = range(2)   B = range(4)   s = sum(i*j for i in A for j in B) It produces the exception: type

Re: scope of generators, class variables, resulting in global na

Nomen Nescio wrote: Hello, Can someone help me understand what is wrong with this example? class T: A = range(2) B = range(4) s = sum(i*j for i in A for j in B) It produces the exception: type 'exceptions.NameError': global name 'j' is not defined It's due to scoping rules for

Re: scope of generators, class variables, resulting in global na

Hi Folks, Thanks everyone for the great contributions! I understand this better now. The distinction between a shorthand for a function definition and a shorthand for a loop iteration is crucial. Also: thanks for pointing out the even the list comprehension doesn't work in py3. That was

Re: scope of generators, class variables, resulting in global na

dontspamleo dontsendleos...@gmail.com writes: @Arnaud: I tried to find your earlier post -- googled Arnaud lambda -- but couldn't. I remembered after posting that I sent this to python-ideas. Here is the first message in the thread:

Re: Union of class variables

On Feb 16, 6:16 pm, Joan Miller pelok...@gmail.com wrote: Is possible to get a third class with the class variables of another two classes? class A:     foo = 1 class B:     bar = 2 Through multiple inheritance? class C(A, B): ... pass ... C.foo 1

Re: Union of class variables [Solved]

On 16 feb, 08:40, alex23 wuwe...@gmail.com wrote: On Feb 16, 6:16 pm, Joan Miller pelok...@gmail.com wrote: Is possible to get a third class with the class variables of another two classes? class A:     foo = 1 class B:     bar = 2 Through multiple

Re: Union of class variables

Joan Miller pelok...@gmail.com writes: Is possible to get a third class with the class variables of another two classes? Multiple inheritance is allowed in Python: class Baz(Foo, Bar): pass However, it leads to complications that you likely don't want, e.g. URL:http

Re: Class variables static by default?

class variables. It takes a real effort of will to remind myself that they're probably not talking about something like this: for theclass in (int, float, Decimal, Fraction): do_something_with(theclass) Right. I figured you don't have much of a background in other OO languages but actually

Re: Class variables static by default?

; four of them in the Language Reference, section Class definitions, where the OP's issue is discussed: Programmer’s note: Variables defined in the class definition are class variables; they are shared by all instances. To create instance variables, they can be set in a method with self.name

Re: Class variables static by default?

actually do get a mental double-take every time I read about class variables. It takes a real effort of will to remind myself that they're probably not talking about something like this: for theclass in (int, float, Decimal, Fraction): do_something_with(theclass) I found that his posts

Re: Class variables static by default?

On Sat, 19 Dec 2009 20:28:07 -0800, Chris Rebert wrote: Surely, since string variables are strings, and float variables are floats, and bool variables are bools, and module variables are modules, a class variable will be a class and an instance variable will be an instance? As they say,

Re: Class variables static by default?

definition are class variables; they are shared by all instances. To create instance variables, they can be set in a method with self.name = value. Both class and instance variables are accessible through the notation “self.name“, and an instance variable hides a class variable with the same name

Class variables static by default?

Given the following script, I'd expect p1.items to just contain [foo] and p2.items to contain [bar] but they both contain [foo, bar]. Why is this? Are object variables not specific to their instance? --- #!/usr/bin/env python class Parser: items = [] def

Re: Class variables static by default?

On Sat, 19 Dec 2009 19:10:13 -0500, KarlRixon karlri...@gmail.com wrote: Given the following script, I'd expect p1.items to just contain [foo] and p2.items to contain [bar] but they both contain [foo, bar]. Why is this? Are object variables not specific to their instance?

  1   2   3   >