[Python-Dev] Re: macOS issues with 3.8.7rc1

On 10/12/20 10:28 am, Guido van Rossum wrote: In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem Another problem, for me at least, is that OS updates often seem

[Python-Dev] Re: Story behind vars() vs .__dict__

On 22/12/20 12:36 am, Paul Sokolovsky wrote: Expected clarification on ".__dict__ breaking object encapsulation": Encapsulation is not something that Python has ever been big on. There are plenty of places where implementation details are exposed, and we don't regard that as a problem. -- Greg

[Python-Dev] Re: Enhancement request for PyUnicode proxies

Rather than a full-blown buffer-protocol-like thing, could we get by with something simpler? How about just having a flag in the unicode object indicating that it doesn't own the memory that it points to? -- Greg ___ Python-Dev mailing list -- python-de

[Python-Dev] Re: Story behind vars() vs .__dict__

On 9/01/21 9:12 am, Chris Barker wrote: (though I notice that if you create __slots__ in pure Python, its names show up in dict anyway -- so clearly I'm confused...) Descriptors for the slots get added to the *class* dict. But that's not the dict that vars() looks at. -- Greg _

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 12/01/21 6:21 am, Larry Hastings wrote: Unbound code objects ...The "annotation code object" is then stored *unbound* as the internal value of ``__co_annotations__``; it is then bound on demand when the user asks for ``__annotations__``. This seems like premature optim

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 6:22 am, Larry Hastings wrote: * The language will set __annotations__ to a dict if the object has   annotations, or None if it has no annotations. That sounds inconvenient -- it means that any code referencing __annotations__ has to guard against the possibility of it being None

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 12/01/21 10:16 am, Larry Hastings wrote: This is addressed in PEP 563, when it rejected the idea of using "function local state when defining annotations": This would be prohibitively expensive for highly annotated code as the frames would keep all their objects alive. That includes

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 12/01/21 10:41 am, Larry Hastings wrote: So: if you're using annotations for something besides "type hints", Didn't Guido decree that using annotations for anything other than type hints is no longer supported? -- Greg ___ Python-Dev mailing list

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 12/01/21 11:32 am, Łukasz Langa wrote: EdgeDB uses stringified annotations exclusively which minimizes runtime memory usage of annotations because those strings are pretty much all ASCII and many can be interned. 946 -> s_schema.Schema 362 -> str 298 -> sd.CommandContext Seems to me the

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 2:46 pm, Larry Hastings wrote: Using an 64-byte empty dict per object with no defined annotations seems so wasteful.  And anything short of an empty dict, you'd have to guard against. If __annotations__ were to return a read-only mapping object instead of a dict, the same empty o

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 2:21 pm, Larry Hastings wrote: Slots intelligently support inheritance, too. Are you sure about that? My experiments suggest that it has the same problem as __annotations__: Python 3.8.2 (default, Mar 23 2020, 11:36:18) [Clang 8.1.0 (clang-802.0.42)] on darwin Type "help", "copyrig

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 12/01/21 2:56 pm, Larry Hastings wrote: In PEP 649 I think every reference of "binding" is talking about binding a code object to a globals dict to produce a function object.   The process of binding a function to an object instance to make a method is conceptually very similar, but distin

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 13/01/21 6:54 am, Larry Hastings wrote: Note that this only works in the current version of the PEP / prototype, where annotations are strictly evaluated in module scope.  If we start supporting closures, those need "cell" objects, which IIUC can't be marshalled. The cells belong to the en

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 13/01/21 5:47 am, Larry Hastings wrote: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at runtime--bytecode, lnotab, names, consts, etc. Would that tuple be significa

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 13/01/21 3:31 pm, Larry Hastings wrote: Let's say we put those behind a from __future__ import.  Now we're gonna write library code that examines annotations. A user passes in a class and asks us to examine its annotations.  The old semantics might be active on it, or the new ones.  How d

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 5:29 am, Steven D'Aprano wrote: No, I don't think it is possible to enforce lack of side-effects. Not without rebuilding the language from the ground up with a clear, definitive and enforcable distinction between pure and impure functions. (I think Haskell does something like that.

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 6:17 am, Paul Sokolovsky wrote: For example, print() would be considered "pure", as its purpose is to provide program output, not arbitrarily change program state That definition of purity wouldn't really help with optimisations, though, because optimising away a print() call would

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 1:13 pm, Paul Sokolovsky wrote: But nobody talked about optimizing away generic "pure"-annotated functions (which would differ from "mathematical" definition of purity), only about optimizing "pure" *dunder* methods The same thing applies. If we decide that print() is pure, then a _

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 3:32 pm, Terry Reedy wrote: I say 'yes', because the purpose of logging is to document what happens, and if nothing happens, there is nothing to document.  Wrapping a .__bool__ in a logging decorator might be part of testing it. Or it might be something else. It would be fine to *

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide the details. It wouldn't be the same as

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 16/01/21 9:38 am, Guido van Rossum wrote: On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings > wrote: class OuterCls:     class InnerCls:         def method(a:OuterCls.InnerCls=None): pass We've turned the local reference into a global re

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 16/01/21 2:09 pm, Guido van Rossum wrote: Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But consider this: ``` class Outer:     foo = 1     class Inner:     print(foo) That's true. So maybe the user should have to be explicit in cases like this: class Outer:

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 17/01/21 12:31 pm, Larry Hastings wrote: Consider the best practice for getting class annotations, example here from Lib/dataclasses.py: cls_annotations = cls.__dict__.get('__annotations__', {}) Isn't that going to get broken anyway? It won't trigger the calling of __co_annotations_

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 19/01/21 1:13 pm, Inada Naoki wrote: I don't want to import modules used only in type hints. I don't want to import even "typing". How about having a pseudo-module called __typing__ that is ignored by the compiler: from __typing__ import ... would be compiled to a no-op, but recognised by

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote: TypeError: object.__new__(B) is not safe, use B.__new__() It's not safe because object.__new__ doesn't know about any C-level initialisation that A or B need. At the C level, there is always a *single* inheritance hierarchy. The right th

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 3/02/21 12:07 am, Phil Thompson wrote: On 01/02/2021 23:50, Greg Ewing wrote: At the C level, there is always a *single* inheritance hierarchy. Why? Because a C struct can only extend one other C struct. I want my C-implemented class's __new__ to support cooperative multi-inheri

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 3/02/21 4:52 am, Phil Thompson wrote: Thanks - that's fairly definitive, although I don't really understand why __new__ has this particular requirement. The job of tp_new is to initialise the C struct. To do this, it first has to initialise the fields of the struct it inherits from, then in

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 3/02/21 11:05 am, Martin Teichmann wrote:     class MyClass(B, Mixin):           "whatever" this leads to an MRO of MyClass -> B -> Mixin -> A -> object. If you do the tp_new stuff correctly at the C level, you can still create such a class. The only limitation is that if Mixin has a __n

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 3/02/21 10:35 pm, Phil Thompson wrote: On 02/02/2021 23:08, Greg Ewing wrote: you have no idea what kind of C struct it expects to get. I had assumed that some other magic in typeobject.c (eg. conflicting meta-classes) would have raised an exception before getting to this stage if there

[Python-Dev] Re: What's up with assignment expression and tuples?

On 5/02/21 8:51 pm, Paul Sokolovsky wrote: a = 0 while a < 5: a += 1 becomes: a0 = 0 while (a1 := phi(a0, a2)) < 5: a2 = a1 + 1 SSA seems to be something intended for compilers to use as an intermediate representation, not something to actually write code in. So I'm puzzle

[Python-Dev] Re: Concerns about PEP 634

On 7/02/21 9:58 am, Steve Holden wrote: My suggestion that it be introduced via __future__ due to its contentious nature met immediate resistance. __future__ is for things that are changing in incompatible ways. This is an entirely new feature that doesn't conflict with anything existing, so it

[Python-Dev] Re: Python standardization

On 13/02/21 9:03 am, Paul Bryan wrote: What if PSF were to undertake codifying a language specification? We have the Language Reference and Library Reference. Do they not count as specifications? -- Greg ___ Python-Dev mailing list -- python-dev@pyth

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On 14/02/21 8:48 am, Eric Traut wrote: def is_str_list(val: Constrains[List[object]:List[str]) -> bool: ... Maybe something like this? def is_str_list(val: List[str] if True else List[object]) -> bool: ... -- Greg ___ Python-Dev mailing li

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

While I don't particularly mind if we get ExceptionGroup, giving it special magical semantics, and especially new syntax, seems like bringing a massively overpowered weapon to bear on something that will only be used rarely. Handling multiple exceptions from an ExceptionGroup could be done using

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 4/03/21 5:37 am, Paul Moore wrote: frameworks and libraries typically have to interact with other users' code, and there the contract has changed from "do what you like in your code and I'll cope" to "do what you like in your code as long as you don't let an exception group escape, and I'll co

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

While we're talking about compelling use cases, does anyone have an actual, concrete use case for the proposed "except *" feature that's strong enough to justify new syntax? I'm fine with having ExceptionGroup as a built-in type. I'm not fine with adding new syntax that will apparently be used on

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On 7/04/21 5:22 am, Brandt Bucher wrote: we might consider updating those templates if the term "Reference Implementation" implies a higher standard than "we've put in the work to make this happen, and you can try it out here" Maybe "prototype implementation" would be better? I think I've use

[Python-Dev] Re: Boundaries between numbers and identifiers

On 14/04/21 8:54 am, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka >  >>> [0x1for x in (1,2)] I would totally make that a SyntaxError, and backwards compatibility be damned. Indeed. Python is not Fotran! -- Greg __

[Python-Dev] Re: In what tense should the changelog be written?

On Fri, Apr 30, 2021 at 02:22 Steven D'Aprano > wrote: Without a subject of the sentence, that's not present tense, it is the imperative mood.     "Fix buffalo.spam ..." is a command or suggestion. While it could be read that way, I don't think th

[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

On Wed, May 26, 2021 at 8:55 AM Ammar Askar > wrote: most recently if your topic mentioned libera.chat, the new freenode owners will take it over, ban anyone from chatting in it and change the topic My goodness. Let's hope the new owners eventually learn

[Python-Dev] Re: Dropping out of this list

On 19/08/21 7:23 pm, Antoine Pitrou wrote: The whole thing is ridiculous enough to read like a Monty Python skit by now, but the trout-slapping ending is still missing. Just have the police come in and arrest everyone, that usually works. -- Greg ___

[Python-Dev] Re: Making code object APIs unstable

On 2/09/21 4:46 am, Victor Stinner wrote: If creating a fake frame is a common use case, we can maybe write a public C API for that. For example, I saw parser injecting frames to show the file name and line number of the parsed file in the traceback. The way I would like to see this addressed i

[Python-Dev] Re: Making code object APIs unstable

On 2/09/21 7:46 pm, Antoine Pitrou wrote: Tracebacks are linked in a single direction, to go the other direction you need to walk the frames attached to the traceback. So a (fake or not) frame object is still desirable, IMHO. Could we at least remove the necessity for a fake code object? --

[Python-Dev] Re: PEP 654 except* formatting

On 4/10/21 6:23 pm, Guido van Rossum wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote: Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError. You can't do that with our current lexer+parser. I don't think it woul

[Python-Dev] Re: PEP 654 except* formatting

On 6/10/21 7:15 am, sascha.schlemmer--- via Python-Dev wrote: except (*E1, *E2) as error: ... Then we would have to decide whether to allow except (E1, *E2) as error: ... and if so, what it would mean. -- Greg ___ Python-Dev mailing list -- pyt

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Carl Meyer wrote: An XML parser that follows the XML standard is never safe to expose to untrusted input. Does the XML standard really mandate that a conforming parser must blindly download any DTD URL given to it from the real live internet? Somehow I doubt that. -- Greg _

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Ethan Furman wrote: I must admit I find it mildly amusing (but a lot frustrating) that we are talk about /enumerations/ not needing to be based on ints. Checking out Merrian-Webster gives this: Definition of ENUMERATE 1 : to ascertain the number of : count 2 : to specify one after another : l

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Barry Warsaw wrote: >>> Colors = make('Colors', 'red green blue'.split()) >>> Animals = make('Animals', 'ant bee cat'.split()) >>> Colors.green == Animals.bee The currently suggested solution to that seems to be to make comparison non-transitive, so that Colors.green == 1 and Animal

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Terry Reedy wrote: (The non-reflexivity of NAN is a different issue, but NANs are intentionally insane.) Yes, the non-transitivity in that case only applies to one very special value. We're talking about making comparison non-transitive for *all* values of the types involved, which is a whole

Re: [Python-Dev] cffi in stdlib

Antoine Pitrou wrote: Or we'll go straight to 5. (or switch to date-based numbering :-)) We could go the Apple route and start naming them after species of snake. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailma

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Ethan Furman wrote: In the first three examples the data in quotes is the doc string; in examples 4 and 5 the RHS is the actual value assigned. What if you want to assign both values and docstrings? -- Greg ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Stephen J. Turnbull wrote: Worse for me, most of the applications I have, I'd like the enumerator identifiers to be both string-valued and int-valued: the int used to index into Python sequences, and the string used in formatting SQL. Is the string value required the same as the name used in Py

Re: [Python-Dev] cffi in stdlib

Antoine Pitrou wrote: We have to find sufficiently silly species of snakes, though. Glancing through http://en.wikipedia.org/wiki/List_of_snakes, we have: Wart snakes Java wart snakes Pipe snakes Stiletto snakes Rubber boas Dog-faced water snakes Shovel-nosed snakes Hook-nosed snakes Leaf-nose

Re: [Python-Dev] can't assign to function call

Hrvoje Niksic wrote: I am not the best person to answer because I go on to argue that this syntax is not needed in Python at all (anything it can do can be implemented with __setitem__ at no loss of clarity). I would even argue that the proxy solution is even *better* for that particular use c

Re: [Python-Dev] relative import circular problem

Kristján Valur Jónsson wrote: However, relative imports can _only_ be performed using the "from X import Y syntax" This seems like a legitimate complaint on its own, regardless of the circular import issue. The principle of least surprise suggests that relative imports should be possible using

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Barry Warsaw wrote: On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote: class Insect(Enum): wasp = wsap = 1 bee = 2 ant = 3 What's the justification for this restriction? I have looked in the PEP, and didn't see one. If you allowed this, there would be no way to look up an enumera

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Victor Stinner wrote: The last proposition is to add transform() and untransform() methods to bytes and str types. ... If I remember correctly, the missing point is how to define which types are supported by a codec Also, for any given codec, which direction is "transform" and which is "untrans

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Steven D'Aprano wrote: - If it is no burden to have to import a module and call an external function for some transformations, why have encode and decode methods at all? Now that all text strings are unicode, the unicode codecs are in a sense special, in that you can't do any string I/O at all

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Stephen J. Turnbull wrote: By RFC specification, BASE64 is a *textual* representation of arbitrary binary data. (Cf. URIs.) The natural interpretation of .encode('base64') in that context would be as a bytes-to-text encoder. However, ... In practice, we invariably use an ASCII octet stream to

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

R. David Murray wrote: The first False looks correct to me, I would not expect an enum value to be an instance of the class that holds it as an attribute. The second certainly looks odd, but what does it even mean to have an instance of an Enum class? This attitude baffles me. In most other la

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

R. David Murray wrote: If 'a' is now an instance of MyEnum, then I would expect that: MyEnum.a.b would be valid That is indeed a quirk, but it's not unprecedented. Exactly the same thing happens in Java. This compiles and runs: enum Foo { a, b } public class Main { publi

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw wrote: I just can't get over the weirdness of a class having attributes which are actual instances of itself. I wonder how many programmers will even notice that this characteristic exists. Exactly the same weirdness occurs in Java, but I had neve

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 26/04/13 11:53, Ethan Furman wrote: --> from Color import * # doesn't work in a function, though :( Yeah, that would be nice. ;) A bit dangerous, though -- what if another module does the same thing, but its Color is different? It needs to put foo.Color in sys.modules, where foo is the nam

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 26/04/13 13:03, MRAB wrote: But there _is_ an ordering problem, in that the days wrap around. Do we want a CircularEnum, then? Ordering would be defined only up to the starting value, which you would be required to specify when doing anything where it mattered. class Day(CircularEnum):

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Steven D'Aprano wrote: I don't think iscallable will work, since that descriptors like staticmethod and classmethod aren't callable. Nor are properties. Hmmm, maybe we should look for a __get__ method as well? Enums of descriptors would seem to fall into the seriously-weird category as well. O

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Piotr Duda wrote: There is at least one more problem, enum inheritance, given: class Colors(Enum): red = 1 green = 2 blue = 3 class MoreColors(Color): cyan = 4 magenta = 5 yellow = 6 what type is MoreColors.red? Given the implementation we're considering, it would probably be Col

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Guido van Rossum wrote: If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, Another way we could tell the difference is if the def state

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Eli Bendersky wrote: There's a conceptual difference between a value of an enumeration and a collection of such values. Not if you think of an enum as a type and a type as defining a set of values. From that point of view, the enum itself is already a collection of values, and introducing anot

Re: [Python-Dev] class name spaces inside an outer function

PJ Eby wrote: On Sat, Apr 27, 2013 at 2:27 PM, Ethan Furman wrote: I filed bug http://bugs.python.org/issue17853 last night. About the only workaround I can see is to put "Season = Season" at the top of a class that uses this inside a function definition, This whole business can be avoide

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Guido van Rossum wrote: And __init__/__new__ probably shouldn't be overridden. Why shouldn't __init__ be overridden? It's the obvious way to support Java-style enum-items-with-attributes. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Ethan Furman wrote: Overriding __init__ is a PITA because __init__ is also called when you do Planet(3) # get EARTH and __init__ was expecting a gravitational constant and radius (or something like that). A couple ways around that: 1) have the metaclass store the args somewhere special

Re: [Python-Dev] class name spaces inside an outer function

Guido van Rossum wrote: On Saturday, April 27, 2013, Greg Ewing wrote: class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) def __init__(self, mass, radius): self.mass = mass

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Steven D'Aprano wrote: On 29/04/13 10:29, Ethan Furman wrote: - bool(1)# True - int('11') # 11 - str(var) # whatever var had in it, now as a str I think that's a red herring, because you're comparing the use of the object constructor with look-up by name. How does what bool

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Cameron Simpson wrote: I'd go a bit further here: I'd take this final sentence as being -0 on preventing adding more enumerals(?), whereas I'm a solid -1 on preventing it. By all means not actively support it, but very against doing things that make it hard for a subclass to support it. I had a

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Guido van Rossum wrote: (2a. We could also allow Color('red') is Color.red, but that could be confusing, and we can already do that with getattr(Color, 'red'), That doesn't quite give you the same thing. Presumably Color('__str__') would be expected to raise a ValueError, for example. -- Greg

Re: [Python-Dev] Enumeration item arguments?

Eli Bendersky wrote: Besides, did we not agree that the only acceptable *members* for enums are going to be descriptors? No, that only applies to names assigned in the class body. Here, mass and radius are being set a different way, so there is no restriction on them. -- Greg _

Re: [Python-Dev] Enumeration items: mixed types?

Ethan Furman wrote: I suppose the other option is to have `.value` be whatever was assigned (1, 'really big country', and (8273.199, 517) ), I thought that was the intention all along, and that we'd given up on the idea of auto-assigning integer values (because it would require either new synta

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Barry Warsaw wrote: Why isn't getattr() for lookup by name good enough? Because it will find things that are not enum items, e.g. '__str__'. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Enum: subclassing?

On 02/05/13 13:47, Steven D'Aprano wrote: The most obvious use-case for subclassing enums is to extend them: class Directions(Enum): north = 1 east = 2 west = 3 south = 4 class Directions3D(Directions): up = 5 down = 6 It doesn't necessarily follow that subclassing is the right mechanism for

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Guido van Rossum wrote: you should do some other check, e.g. "if x in Color:". So you don't think it's important to have an easy way to take user input that's supposed to be a Color name and either return a Color or raise a ValueError? -- Greg ___ Py

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Eli Bendersky wrote: TypeError: Cannot subclass enumerations This message might be better phrased as "cannot extend enumerations", since we're still allowing subclassing prior to defining members. -- Greg ___ Python-Dev mailing list Python-Dev@pytho

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Barry Warsaw wrote: I still don't get it why this is an issue though, or at least why this is different than any other getattr on any other class, It's not a problem that getattr() has this behaviour. What I'm questioning is the idea that getattr() should be the only provided way of doing a nam

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Guido van Rossum wrote: I haven't seen code in the style that Greg proposes in decades, What style are you talking about here? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Eli Bendersky wrote: I'm just curious what it is about enums that sets everyone on a "let's make things safer" path. Python is about duck typing, it's absolutely "unsafe" in the static typing sense, in the most fundamental ways imaginable. This isn't about catching bugs in the program, it's a

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Guido van Rossum wrote: Code that wants to validate a string the user typed as input. Web forms just don't work that way. Maybe "validation" was a misleading term to use. To be more precise, I'm talking about taking input to the program (it needn't come directly from a user, it could be read fr

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Nick Coghlan wrote: 1. The current PEP, offering only "getattr(MyEnum, name)". > 2. We restore __getitem__ on EnumMetaclass *solely* for member lookup by name 3. Use keyword arguments to distinguish two different ways of calling the enum class: MyEnum(value = 1) --> lookup by value MyE

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

Ethan Furman wrote: --> class Color(Enum): ... red, green, blue ... --> class MoreColor(Color): ... red, orange, yellow ... --> type(MoreColor.red) is MoreColor False This argument no longer applies, since we're not allowing enums to be extended. class Color(Enum): red = e()

Re: [Python-Dev] Mysterious Python pyc file corruption problems

Guido van Rossum wrote: This reminds me of the following bug, which can happen when two processes are both writing the .pyc file and a third is reading it. ... I think all the errors are actually explainable from this scenario. The second writer will still carry on to write a valid .pyc file,

Re: [Python-Dev] Ordering keyword dicts

Joao S. O. Bueno wrote: Actually, when I was thinking on the subject I came to the same idea, of having some functions marked differently so they would use a different call mechanism - but them I wondered around having a different opcode for the ordered-dict calls. Would that be feasible? No,

Re: [Python-Dev] What if we didn't have repr?

Łukasz Langa wrote: 1. Make __str__() a protocol for arbitrary string conversion. 2. Move the current __repr__() contracts, both firm and informal to a new, extensible version of pprint. -1. The purposes of repr() and pprint() are quite different. Please let's not make any sweeping changes ab

Re: [Python-Dev] eval and triple quoted strings

Guido van Rossum wrote: Not a bug. The same is done for file input -- CRLF is changed to LF before tokenizing. I'm not convinced it's reasonable behaviour to re-scan the string as though it's being read from a file. It's a Python string, so it's already been through whatever line-ending transfo

Re: [Python-Dev] eval and triple quoted strings

Guido van Rossum wrote: No. Executing a file containing those exact characters produces a string containing only '\n' and exec/eval is meant to behave the same way. The string may not have originated from a file, so the universal newlines behavior of the io module is irrelevant here -- the parser

Re: [Python-Dev] Python 3 as a Default in Linux Distros

Chris Angelico wrote: print "Hello, world!" SyntaxError: invalid syntax Is it safe to presume that it's more likely a syntax error will come from an interpreter version mismatch than a code bug? Maybe look at sys.args[0], and if it ends in "python" with no version number, add something to the

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

Antoine Pitrou wrote: - it is held alive through builtins: the site module patches builtins with additional objects, which themselves keep references to the site module's globals, The module probably *should* stay alive in that case, since it's still accessible via those patched builtins.

Re: [Python-Dev] to rename or not...

Ronald Oussoren wrote: * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for binary data by default * Keep and deprecate "readPlist", "writePlist" and the their string equivalents, those still use Data objects +1, makes sense to me. -- Greg _

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Ryan wrote: Nonblocking sounds too Internet-related. How about...flow? AsyncParser? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pyth

Re: [Python-Dev] Enum Eccentricities

Ethan Furman wrote: Also, if we change Enum so that members do act more like class attributes, then things like Color.red.blue.green.blue will result in Color.blue, I thought we already decided it was worth making that not happen? -- Greg ___ Python

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Guido van Rossum wrote: Somehow "unraisable" sounds too technical, It's not even really accurate. It's been raised, it just can't be propagated any further. But "unpropagatable exception" would be a bit of a mouthful. -- Greg ___ Python-Dev mailing

Re: [Python-Dev] Enum Eccentricities

Steven D'Aprano wrote: It might not be a rule, but it's certainly the norm. I reckon that class attributes that aren't accessible from the instance are significantly more surprising than Color.red.blue. There are really two different kinds of things that we refer to as "class attributes". One

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Antoine Pitrou wrote: Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). How about something like "Uncaught exception in __del__ method ignored"? It explains fairly clearly what has happened, and also in

<    1   2   3   4   5   6   7   8   9   10   >