Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 11/20/2018 10:33 PM, Nathaniel Smith wrote: On Tue, Nov 20, 2018 at 6:05 PM Glenn Linderman wrote: On 11/20/2018 2:17 PM, Victor Stinner wrote: IMHO performance and hiding implementation details are exclusive. You should either use the C API with impl. details for best performances, or use

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On 11/29/2018 2:10 PM, Andrew Svetlov wrote: Neither http.client nor http.server doesn't support compression (gzip/compress/deflate) at all. I doubt if we want to add this feature: for client better to use requests or, well, aiohttp. The same for servers: almost any production ready web server f

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On 1/30/2019 2:32 PM, Raymond Hettinger wrote: Now that regular dicts are ordered and compact, it makes more sense for the _asdict() method to create a regular dict (as it did in its early days) rather than an OrderedDict. ... Option 4) Just make the change directly in 3.8, s/OrderedDict/dic

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On 1/30/2019 8:45 PM, Raymond Hettinger wrote: On Jan 30, 2019, at 3:41 PM, Glenn Linderman wrote: Would it be practical to add deprecated methods to regular dict for the OrderedDict reordering methods that raise with an error suggesting "To use this method, convert dict to OrderedDict.

Re: [Python-Dev] Summary of Python tracker Issues

On 2/28/2019 2:18 PM, Jonathan Goble wrote: On Thu, Feb 28, 2019, 5:11 PM Terry Reedy > wrote: On 2/28/2019 8:07 AM, Jonathan Goble wrote: > On Thu, Feb 28, 2019, 8:02 AM INADA Naoki mailto:songofaca...@gmail.com> >

Re: [Python-Dev] Summary of Python tracker Issues

On 2/28/2019 2:52 PM, Terry Reedy wrote: On 2/28/2019 5:38 PM, Glenn Linderman wrote: On 2/28/2019 2:18 PM, Jonathan Goble wrote: On Thu, Feb 28, 2019, 5:11 PM Terry Reedy <mailto:tjre...@udel.edu>> wrote:     On 2/28/2019 8:07 AM, Jonathan Goble wrote:     > On Thu, Feb 28, 2

Re: [Python-Dev] (Licensing question) backport of shutil.copyfile() functionality

On 3/11/2019 4:35 PM, Giampaolo Rodola' wrote: Hello, some time ago I contributed a couple of patches to speedup shutil.copy*() functions: https://bugs.python.org/issue33671 https://bugs.python.org/issue33695 I would like to backport both functionalities so that they can be used on Python 2.7

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

On 4/20/2019 2:08 PM, Inada Naoki wrote: "import typing" is slow too. 2019年4月21日(日) 1:43 Ilya Kamenshchikov >: alright, so would an import under TYPE_CHECKING guard be an option? like: from typingimport TYPE_CHECKING if TYPE_CHECKING:

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 4/22/2019 4:03 PM, Inada Naoki wrote: On Tue, Apr 23, 2019 at 2:18 AM Chris Barker via Python-Dev wrote: On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon wrote: This doesn't strike me as needing an optimization through a dedicated method. maybe a new dict mapping type -- "shared_dict" -- i

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 4/22/2019 5:19 PM, Steven D'Aprano wrote: Oh, you mean just like regular dicts with shared keys already do:-) https://www.python.org/dev/peps/pep-0412/ Perhaps I've missed something in this discussion, but isn't this a matter of just making the existing shared-keys functionality explicitly u

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 4/22/2019 7:27 PM, Steve Dower wrote: On 22Apr2019 1921, Steve Dower wrote: On 22Apr2019 1822, Glenn Linderman wrote: Inada is now proposing a way to allow the coder to suggest a group of dictionaries that might benefit from the same gains, by preclassifying non-__dict__ slot dictionaries

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 4/22/2019 7:27 PM, Steve Dower wrote: On 22Apr2019 1921, Steve Dower wrote: On 22Apr2019 1822, Glenn Linderman wrote: Inada is now proposing a way to allow the coder to suggest a group of dictionaries that might benefit from the same gains, by preclassifying non-__dict__ slot dictionaries

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 4/22/2019 10:59 PM, Steve Dower wrote: On 22Apr2019 2119, Glenn Linderman wrote: While Inada's suggested DictBuilder interface was immediately obvious, I don't get how either copy or update would achieve the goal. Perhaps you could explain? Particularly, what would be the tr

Re: [Python-Dev] Easier debugging with f-strings

On 5/6/2019 5:39 PM, Eric V. Smith wrote: Last fall Larry Hastings made a suggestion for adding a way to make so-called "print-based debugging" easier with f-strings. Basically the approach is that f-strings would be able to produce the text of the expression and the value of that expression, w

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/20/2019 2:20 PM, Christian Heimes wrote: On 20/05/2019 23.12, Andrew Svetlov wrote: socketserver.py is also questionable I briefly though about the module, but didn't consider it for removal. The http.server, xmlrpc.server, and logging configuration server are implemented on top of the s

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

ttery is a disservice to novice users, because they might try to use it for something real. On Tue, May 21, 2019 at 9:39 AM Glenn Linderman <mailto:v%2bpyt...@g.nevcal.com>> wrote: On 5/20/2019 2:20 PM, Christian Heimes wrote: On 20/05/2019 23.12, Andrew Svetlov wrote: sock

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/21/2019 11:15 AM, Christian Heimes wrote: On 21/05/2019 18.29, Glenn Linderman wrote: On 5/20/2019 2:20 PM, Christian Heimes wrote: On 20/05/2019 23.12, Andrew Svetlov wrote: socketserver.py is also questionable I briefly though about the module, but didn't consider it for removal

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/21/2019 2:00 PM, Nathaniel Smith wrote: On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote: After maintaining my own version of http.server to fix or workaround some of its deficiencies for some years, I discovered bottle.py. It has far more capability, is far better documented, and

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

Between this discussion and Steve Dower's recently referenced blog post at https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/from which I quote below: It’s been widely known for many years that Windows is the only mainstream operating system that does not include

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/22/2019 4:09 AM, Christian Heimes wrote: On 22/05/2019 01.11, Glenn Linderman wrote: On 5/21/2019 2:00 PM, Nathaniel Smith wrote: On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote: After maintaining my own version of http.server to fix or workaround some of its deficiencies for

Re: [Python-Dev] PEP 594: update 1

On 5/24/2019 9:09 PM, Random832 wrote: On Thu, May 23, 2019, at 15:27, Steve Holden wrote: Besides which, it would be lovely to have a major release that didn't involve any pain at all for the majority of users! Our erstwhile BDFL always eschewed two-digit version identifiers- due to the possib

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On 5/27/2019 7:28 PM, Steven D'Aprano wrote: On the other hand, locals() currently returns a dict everywhere. It might be surprising for it to start returning a proxy object inside functions instead of a dict. I thought the proxy object sounded more useful... how different is it in use from a di

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On 6/27/2019 3:09 PM, Brett Cannon wrote: My guess is that without Guido to just ask this will have to go to a PEP as it changes a built-in. How does adding two new methods change a built-in? Now if an extra parameter were added to modify lstrip, rstrip, and strip to make them do something di

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On 6/28/2019 10:10 AM, MRAB wrote: On 2019-06-28 03:40, Glenn Linderman wrote: On 6/27/2019 3:09 PM, Brett Cannon wrote: My guess is that without Guido to just ask this will have to go to a PEP as it changes a built-in. How does adding two new methods change a built-in? Now if an extra

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On 7/1/2019 8:28 PM, Terry Reedy wrote: On 7/1/2019 1:57 PM, Chris Barker via Python-Dev wrote: This was quite extensively discussed on python-ideas recently: https://mail.python.org/archives/list/python-id...@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On 7/2/2019 12:56 PM, Terry Reedy wrote: On 7/2/2019 12:16 AM, Glenn Linderman wrote: On 7/1/2019 8:28 PM, Terry Reedy wrote: I did not read much of the thread, but the proposal is to wrap a near-trivial expression (2 operations) or replace a current method call with a method call than is

[Python-Dev] Re: What to do about invalid escape sequences

On 8/6/2019 5:57 PM, Gregory P. Smith wrote: People distribute code via pypi.  if we reject uploads of packages with these problems and link to fixers (modernize can be taught what to do), we prevent them from spreading further.  A few years after doing that, we can revisit how much pain and fo

[Python-Dev] Re: What to do about invalid escape sequences

On 8/7/2019 6:13 PM, raymond.hettin...@gmail.com wrote: This isn't about me. As a heavy user of the 3.8 beta, I'm just the canary in the coal mine. Are you, with an understanding of the issue, submitting bug reports on the issues you find, thus helping to alleviate the problem, and educate th

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/2020 1:42 PM, Guido van Rossum wrote: But we feel that `case x, x` can easily be misunderstood as "a tuple of two equal values" So what _is_ the syntax for "a tuple of two equal values" ? case x, ?x:  # comes to mind (not that it is in the PEP :)) __

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 11/13/2020 1:48 PM, Joao S. O. Bueno wrote: On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett > wrote: I *hope* this was a typo!  If     case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote: Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means exa

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On 11/21/2020 9:47 AM, David Mertz wrote: So in my mind, if I had the choice, it is a decision between a sigil and a word to indicate "no, really use this name as a value!" I like a word better, but none of the current keywords really make sense, so it would need to be a new word. I suggested "

[Python-Dev] Re: __init_subclass__ and metaclasses

On 12/29/2020 10:00 PM, Guido van Rossum wrote: I need to think about this more. Both techniques could coexist. Technically the class *is* created at the point `__init_subclass__` is called. What the metaclass does after that point is embellishment. Most metaclasses will have sufficient con

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

On 2/25/2021 9:40 PM, Nathaniel Smith wrote: On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote: So is "fail-fast if you forget to handle an ExceptionGroup" really a feature? (Do we call this out in the PEP?) We may believe that "except Exception" is an abuse, but it is too common to dism

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

On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote: On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing mailto:greg.ew...@canterbury.ac.nz>> wrote: On 4/03/21 5:37 am, Paul Moore wrote: > frameworks and libraries typically have to interact with other users' > code, and there the c

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

On 3/4/2021 1:41 AM, Irit Katriel wrote: On Thu, Mar 4, 2021 at 1:38 AM Glenn Linderman <mailto:v%2bpyt...@g.nevcal.com>> wrote: On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote: That's an interesting idea. Do you mean that one exception gets handled and t

[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

On 4/19/2021 12:44 PM, Guido van Rossum wrote: We had a similar thing at Dropbox, where `# coding: pyxl` would enable a preprocessor that allowed HTML embedded in the Python code. It translated this to function calls and string literals. There were however several drawbacks: - Installing the

[Python-Dev] Re: name for new Enum decorator

On 5/28/2021 12:08 AM, Michał Górny wrote: On Thu, 2021-05-27 at 20:24 -0700, Ethan Furman wrote: Greetings! The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements into a decorator instead, and I'm having a hard time thinking up a

[Python-Dev] Re: name for new Enum decorator

On 5/29/2021 6:33 PM, Nick Coghlan wrote: On Sat, 29 May 2021, 7:27 am Ethan Furman, > wrote: On 5/28/21 12:43 AM, Petr Viktorin wrote:  > On 28. 05. 21 5:24, Ethan Furman wrote:  >>      class FlagWithMasks(IntFlag):  >>          DEFAULT = 0x0  >>

[Python-Dev] Re: name for new Enum decorator

On 5/31/2021 1:37 PM, Luciano Ramalho wrote: On Fri, May 28, 2021 at 7:00 PM Joao S. O. Bueno wrote: "check_all_bits_defined" or something along it. Best suggestion so far. Similar: "ensure_all_bits_named" I am all for brainstorming, as we've been doing for a few days. Maybe we need to brain

[Python-Dev] Re: name for new Enum decorator

On 6/2/2021 7:59 PM, Ethan Furman wrote: On 5/27/21 8:24 PM, Ethan Furman wrote: > So, like the enum.unique decorator that can be used when duplicate names should be an error, > I'm adding a new decorator to verify that a Flag has no missing aliased values that can be > used when the programme

[Python-Dev] Re: Proposal: declare "unstable APIs"

On 6/3/2021 3:34 PM, Guido van Rossum wrote: On Thu, Jun 3, 2021 at 3:17 PM Tim Delaney mailto:timothy.c.dela...@gmail.com>> wrote: Perhaps "living API" analogous to "living document". Much more positive connotations ... Perhaps, but that's pretty much coining a new term, which we wou

[Python-Dev] Re: Roundup to GitHub Issues migration

On 6/21/2021 2:31 PM, Christopher Barker wrote: By contrast, requiring a github account for reporting bugs also makes python an unwelcoming place for non-developers in general. Github is a developers' social network, "mere" users are much less likely to want to be part of it.

[Python-Dev] Re: Roundup to GitHub Issues migration

On 6/22/2021 12:52 PM, Brett Cannon wrote: On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman <mailto:v%2bpyt...@g.nevcal.com>> wrote: On 6/21/2021 2:31 PM, Christopher Barker wrote: By contrast, requiring a github account for reporting bugs also makes

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

On 10/3/2021 10: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. Seems like a good reason to promote   "except

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec fordistribution metadata 2.0

On 2/19/2013 11:06 AM, Daniel Holth wrote: This feature does something to remedy the setuptools chicken/egg problem. We have eliminated the egg ;-) This is the most artfully crafted comment I've seen on topic on this list for some months! Thanks! ___

Re: [Python-Dev] Status of XML fixes

On 3/17/2013 8:48 PM, Barry Warsaw wrote: On Mar 17, 2013, at 05:37 PM, Christian Heimes wrote: Any attempt to fix the XML issues *will* change the behavior of the library and result into an incompatibility with older releases. Benjamin doesn't want to change the behavior of our XML libraries.

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 5:15 PM, Terry Reedy wrote: Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines) People keep claiming that Windows CMD has a limited output buffer. It is configurable, at least to lines, which is where I have mine set. That is far too much t

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 4/1/2013 5:47 PM, Daniel Holth wrote: users expect .py to be opened with a text editor. This user expects .py to be executed as an executable script, and thinks that is the default after an installation of Python on Windows. Windows has a separate option, Edit, to use to edit things. Bu

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

On 4/12/2013 3:59 PM, Guido van Rossum wrote: class Insect(Enum): wasp = 1 bee = 1 ant = 2 We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is not Insect.bee. can't define two names in the same enum to have the same value, per the PEP. ___

Re: [Python-Dev] Deciding against the CLA

On 4/15/2013 12:15 AM, Ben Finney wrote: Steven D'Aprano writes: On 13/04/13 20:30, Ben Finney wrote: "Stephen J. Turnbull" writes: A failure to sign the CLA is already a decision not to contribute to the distribution As someone who cannot in good faith sign the CLA, that characterisation

Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module

On 4/15/2013 4:21 PM, Larry Hastings wrote: On 04/15/2013 09:31 AM, Eli Bendersky wrote: Would it make sense to think about adding this in the scope of the argument clinic work, or is it too unrelated? This seems like a commonly needed thing for large parts of the stdlib (where the C accelerat

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

On 4/24/2013 1:22 AM, M.-A. Lemburg wrote: On 23.04.2013 19:24, Guido van Rossum wrote: On Tue, Apr 23, 2013 at 9:04 AM, M.-A. Lemburg wrote: On 23.04.2013 17:47, Guido van Rossum wrote: On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg wrote: Just as reminder: we have the general purpose enco

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

On 4/25/2013 3:37 PM, Guido van Rossum wrote: On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw wrote: >On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote: >>I suppose you were going to propose to use isinstance() overloading, >>but I honestly think that Color.red.__class__ should be the same >>

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

On 4/25/2013 3:23 PM, Barry Warsaw wrote: My point is, "days of the week" has a natural ordering, so why wouldn't you use IntEnum for that? Problem solved. While the ordering is natural, some implementations start from 0, some start from 1, and on the naming side, some start from Sunday, and

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

On 4/25/2013 4:53 PM, Ethan Furman wrote: On 04/25/2013 04:26 PM, Glenn Linderman wrote: My question is, once an enumeration is defined, is there a way, short of element-by-element assignment, to import the individual enumeration instances into the current namespace, so that I can say &quo

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

On 4/25/2013 7:25 PM, Ethan Furman wrote: On 04/25/2013 07:09 PM, Glenn Linderman wrote: On 4/25/2013 4:53 PM, Ethan Furman wrote: On 04/25/2013 04:26 PM, Glenn Linderman wrote: My question is, once an enumeration is defined, is there a way, short of element-by-element assignment, to import

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

On 4/25/2013 7:49 PM, Nick Coghlan wrote: On Fri, Apr 26, 2013 at 12:38 PM, Guido van Rossum wrote: If the above syntax won't work, that isinstance() outcome isn't really important. :-( Can't we do some kind of callable check? There may be some weird decorators that won't work, but they aren't

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

On 4/25/2013 8:22 PM, Greg wrote: On 26/04/2013 3:12 p.m., Glenn Linderman wrote: On 4/25/2013 7:49 PM, Nick Coghlan wrote: You couldn't create an enum of callables, but that would be a seriously weird thing to do anyway But aren't all classes callable? An enum of classe

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

On 4/25/2013 9:19 PM, Guido van Rossum wrote: On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman wrote: an enumeration of objects whose class defines __call__ would not be so weird. Seriously? You'd complexificate the basic usage in order to cater for such an esoteric use case? The *only

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

On 4/26/2013 6:22 PM, Greg Ewing wrote: 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 coul

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

On 4/28/2013 4:37 PM, Steven D'Aprano wrote: I have also suggested that that the enum package provide a decorator which can be used to explicitly flag values to *not* be turned into enum values. See here: http://mail.python.org/pipermail/python-dev/2013-April/125641.html Even if the Enum class

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

On 4/28/2013 9:09 PM, 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'), and bool('False') doesn't return False anyway, so let's not do that.) Glad you made this pronouncement in this wa

Re: [Python-Dev] Enumeration items: `type(EnumClass.item) is EnumClass` ?

On 4/29/2013 10:01 AM, Guido van Rossum wrote: On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman wrote: On 04/29/2013 08:39 AM, Guido van Rossum wrote: Indeed, the "type(Color.red) is Color" claim was meant for the situation where red is defined directly in Color, and I used type() instead of isin

Re: [Python-Dev] PEP-435 reference implementation

On 4/30/2013 1:12 PM, Ethan Furman wrote: Greetings, Eli asked me to put the reference implementation here for review. It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and test_ref435.py Thanks for the code reference. Tests ran fine here on Python 3.3 If I alter test_r

Re: [Python-Dev] PEP-435 reference implementation

On 4/30/2013 4:49 PM, Ethan Furman wrote: On 04/30/2013 03:34 PM, Ethan Furman wrote: On 04/30/2013 03:24 PM, Glenn Linderman wrote: On 4/30/2013 1:12 PM, Ethan Furman wrote: Greetings, Eli asked me to put the reference implementation here for review. It is available at https

Re: [Python-Dev] PEP-435 reference implementation

On 4/30/2013 9:19 PM, Ethan Furman wrote: Latest code available at https://bitbucket.org/stoneleaf/aenum. --> class Color(Enum): ... red = 1 ... green = 2 ... blue = 3 Enum items are virtual attributes looked by EnumType's __getattr__. The win here is that --> Color.red.green.bl

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

On 4/30/2013 11:08 PM, Barry Warsaw wrote: On Apr 28, 2013, at 07:46 PM, Ethan Furman wrote: and similarly, Enum behavior /should be/ (in my opinion ;) Season.AUTUMN is Season('AUTUMN') is Season(3) I think you'll have a problem with this. flufl.enum did this, but it has an inherent conflict

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 5/3/2013 6:41 PM, Steven D'Aprano wrote: Many official Microsoft file extensions are four or more letters, e.g. docx. I don't see any value in making long-lasting decisions on file extensions based on (transient?) bugs that aren't our responsibility. +1

[Python-Dev] PEP 435 - ref impl disc 2

So I have a class based on Nick's Named Values, that has been extended to propagate names into expressions, so that if you have named values 'x' and 'y', when you x + y, the result is a named value whose name is '(x + y)'. Seems pretty awkward to integrate this with Enum. Maybe I'm missing

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/4/2013 11:31 PM, Glenn Linderman wrote: So I have a class based on Nick's Named Values, that has been extended to propagate names into expressions, so that if you have named values 'x' and 'y', when you x + y, the result is a named value whose name is '(x

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/4/2013 11:46 PM, Glenn Linderman wrote: Somehow, the overloading is not finding the __add__ operator in the NamedInt class, when the NamedInt's are wrapped in enumerations. And I guess I figured it out... NamedInt needs to test issubclass( type( self ), NamedInt ) rather

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/5/2013 12:10 AM, Glenn Linderman wrote: On 5/4/2013 11:46 PM, Glenn Linderman wrote: Somehow, the overloading is not finding the __add__ operator in the NamedInt class, when the NamedInt's are wrapped in enumerations. And I guess I figured it out... NamedInt needs to test issub

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/5/2013 12:21 AM, Ethan Furman wrote: On 05/04/2013 11:31 PM, Glenn Linderman wrote: x = NamedInt('the-x', 1 ) y = NamedInt('the-y', 2 ) # demonstrate that NamedInt propagates the names into an expression syntax print( repr( x ), repr( y ), repr( x+y )) fro

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/5/2013 6:07 AM, Ethan Furman wrote: class NEI( NamedInt, Enum ): x = NamedInt('the-x', 1 ) y = NamedInt('the-y', 2 ) @property def __name__(self): return self.value.__name__ This cured it, thank you. But I really still don't understand why the numbers showed up as

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/5/2013 7:14 PM, Nick Coghlan wrote: I think there comes a point where "subclass the metaclass" is the right answer to "how do I do X with this type?". I believe making two different kinds of value labelling mechanisms play nice is such a case :) Could be. Could be that sufficient operator

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/5/2013 9:51 PM, Nick Coghlan wrote: On Mon, May 6, 2013 at 12:46 PM, Glenn Linderman wrote: Sadly, once the Enums are defined, there is to be no way to subclass them to add functionality, like producing a NamedInt result from operations on them. That rule is enforced by the metaclass, so

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/6/2013 6:26 PM, Ethan Furman wrote: On 05/05/2013 01:01 AM, Glenn Linderman wrote: The bigger problem is that the arithmetic on enumeration items, which seems like it should be inherited from NamedInt (and seems to be, because the third value from each print is a NamedInt), doesn't

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

On 5/6/2013 7:58 PM, Tim Delaney wrote: On 7 May 2013 12:29, Ethan Furman > wrote: On 05/05/2013 02:55 PM, Tim Delaney wrote: So long as I can get one of the requirements documented to implement an auto-number syntax I'll be happy enough with

Re: [Python-Dev] PEP 435 - ref impl disc 2

So, thanks everyone for helping me understand the metaclass issues, and helping fix my code and the reference implementation, so that I got a working workaround for enumerations. Twiddling some more newly using hg and bitbucket... learned a lot today... at

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/10/2013 11:02 PM, Ethan Furman wrote: On 05/10/2013 10:15 PM, Glenn Linderman wrote: But the last few lines of demo1 demonstrate that NIE doesn't like, somehow, remember that its values, deep down under the covers, are really int. And doesn't even like them when they are wr

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/11/2013 12:11 AM, Glenn Linderman wrote: * I'm playing with adding another keyword parameter to Enum, but it is presently giving me an error about unknown keyword parameter passed to __prepare__ even though I added **kwds to the list of its parameters. I'll learn something by

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/11/2013 12:11 AM, Glenn Linderman wrote: Oh, newest code posted. That'll give me some practice pulling from your repository into mine :) Well, I had to bring your changes to my local repository, and then push them up to my bitbucket repo... not sure if there is a way to merge

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/13/2013 7:36 PM, Ethan Furman wrote: On 05/10/2013 10:15 PM, Glenn Linderman wrote: So it is quite possible to marry the two, as Ethan helped me figure out using an earlier NamedInt class: class NIE( IntET, Enum ): x = ('NIE.x', 1) y = ('NIE.y', 2) z

[Python-Dev] PEP 435 doesn't help with bitfields [Was: Re: PEP 435 - ref impl disc 2]

On 5/13/2013 7:36 PM, Ethan Furman wrote: 2) Is something like demo2 interesting to anyone but me? Of course, I think it would be great for reporting flag values using names rather than a number representing combined bit fields. No idea. ;) There's been some talk of Enum-ing constants in th

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On 5/19/2013 9:08 PM, Ethan Furman wrote: On 05/19/2013 05:24 PM, Nick Coghlan wrote: This is the point I was trying to make: once you use IntEnum (as you would in any case where you need bitwise operators), Enum gets out of the way for everything other than __str__, __repr__, and one other slo

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/14/2013 7:16 AM, Ethan Furman wrote: Thank you for being persistent. You are correct, the value should be an IntET (at least, with a custom __new__ ;). You know, when you look at something you wrote the night before, and have no idea what you were trying to say, you know you were tired.

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/20/2013 11:44 PM, Glenn Linderman wrote: On 5/14/2013 7:16 AM, Ethan Furman wrote: Thank you for being persistent. You are correct, the value should be an IntET (at least, with a custom __new__ ;). You know, when you look at something you wrote the night before, and have no idea what

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 5/22/2013 3:33 PM, Łukasz Langa wrote: 2. does not have a standard way for methods to be added to existing generic functions (i.e., some are added using registration functions, others require defining ``__special__`` methods, possibly by monkeypatching). I assume you are talking

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 5/22/2013 5:55 PM, Guido van Rossum wrote: On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman wrote: Yet about half of the operator overloads would be incomplete if there were not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the second parameter is as key to the dispatch as

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 5/23/2013 12:14 AM, Antoine Pitrou wrote: On Thu, 23 May 2013 02:33:57 -0400 Devin Jeanpierre wrote: >On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou wrote: > >On Thu, 23 May 2013 12:12:26 +1000 > >Nick Coghlan wrote: > >>The binary operators can be more accurately said to use a complica

Re: [Python-Dev] PEP 409 and the stdlib

On 5/28/2013 6:02 AM, Serhiy Storchaka wrote: 20.05.13 18:46, Antoine Pitrou написав(ла): I think it is a legitimate case where to silence the original exception. However, the binascii.Error would be more informative if it said *which* non-base32 digit was encountered. Please open a new issue

Re: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL

On 7/12/2013 8:50 AM, Guido van Rossum wrote: You underestimate the reach of XP. For older or underpowered hardware outside the developed world it is still the de facto choice. And it definitely is the best version of Windows ever. None of the Win98 crap and none of the Vista junk. Telling

Re: [Python-Dev] The Return Of Argument Clinic

On 8/5/2013 1:48 AM, Larry Hastings wrote: The impl should know whether or not it failed. So it's the interface we're defining that forces it to throw away that information. If we provided a way for it to return that information, we could shave off some cycles. The problem is, how do we do th

Re: [Python-Dev] format, int, and IntEnum

On 8/14/2013 9:27 PM, Nick Coghlan wrote: I think Eric is overinterpreting the spec, there. While that particular sentence requires that the empty format string will be equivalent to a plain str() operation for builtin types, it is only a recommendation for other types. For enums, I believe t

Re: [Python-Dev] Completing the email6 API changes.

On 9/1/2013 3:10 PM, R. David Murray wrote: This doesn't work, though, because you could (although you usually won't) have more than one 'text/html' part in a single multipart. I was traveling and your original message is still unread in my queue of "things to look at later" :( I haven't caug

Re: [Python-Dev] Completing the email6 API changes.

On 9/1/2013 8:03 PM, Stephen J. Turnbull wrote: This is getting off-topic IMO; we should probably take this thread to email-sig. Probably, but you didn't :) Glenn Linderman writes: > I recall being surprised when first seeing messages generated by > Apple Mail softwar

Re: [Python-Dev] Completing the email6 API changes.

On 9/2/2013 2:40 PM, R. David Murray wrote: I'm still not understanding how the text/plain part*refers* to the related parts. I don't think the text/plain part can refer to the related parts, but, like you, am willing to be educated if there is a way; but while the text/html may be able to if

Re: [Python-Dev] Offtopic: OpenID Providers

On 9/5/2013 1:30 PM, Tres Seaver wrote: +1 for supporting Persona as an alternative to OpenID on all *.python.org servers. Is there a Python implementation of Persona I can install on my web server? ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] Offtopic: OpenID Providers

On 9/6/2013 10:22 AM, Dan Callahan wrote: On 9/5/13 12:31 PM, Jesus Cea wrote: I have big hopes for Mozilla Persona, looking forward Python infrastructure support :). Hi, I'm the project lead on Persona signin, and I spoke at PyCon earlier this year regarding why and how Mozilla is building P

<    1   2   3   4   5   6   7   >