and the fact that Ezio is managing the project elsewhere, I think rejection
is appropriate. However if we do that I think the PEP should at least be
updated with references to Ezio’s project, with some verbiage added as to why
these changes are being made.
What do you think, Mariatta?
-Bar
Miro, what tests (outside of Python itself) do you think may break, and do you
have a way to check that?
-Barry
On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:
> On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
> >
> > Barry and I are working on a patch to add depre
That sounds great, thanks Mariatta.
-Barry
> On Jun 23, 2021, at 12:36, Mariatta wrote:
>
> My understanding is that Ezio is/will be working on updating PEP 588.
> Last I heard from Ezio is that he would be co-author of PEP 588 and he would
> be updating it/rewrite it to b
es due to these
DeprecationWarnings. I defer to the RM but Pablo already approved it. :D
https://github.com/python/cpython/pull/26882
adds import time DeprecationWarnings to asyncore, asynchat, and smtpd.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in
Tracebacks) has been unanimously accepted for Python 3.11 by the Python
Steering Council.
Congratulations Pablo, Batuhan, and Ammar!
Cheers,
-Barry (on behalf of the Steering Council)
signature.asc
Description
On Jun 29, 2021, at 08:27, Mark Shannon wrote:
>
> I was expected the announcement of a BDFL delegate for PEP 657, as the author
> is a steering council member.
PEP Delegates are not required, even when the PEP author is an SC member.
-Barry
signature.asc
Description: Message si
to the Python 3.9 behavior, and that a PEP be written for Python 3.11.
Cheers,
-Barry (on behalf of the Steering Council)
> On Jun 28, 2021, at 00:56, Ethan Furman wrote:
>
> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str()
> in 3.10 and another in
As specifically to the flaws in our workflow and the backlog, this is exactly
what the Developer-in-Residence program was designed to address:
https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-developer-in.html
Stay tuned!
-Barry
> On Jun 29, 2021, at 09:56, Joannah Nanjekye wr
On Jul 29, 2021, at 05:55, Steve Dower wrote:
>
> Maybe we should have a "Type" other than Standards Track for PEPs that are
> documenting implementation designs, rather than requirements for
> standardisation?
Wouldn’t Informational fill that need?
-Barry
sig
exists only for the symmetry described in the PEP is
just a little extra complexity for little value.
Let us know what you think about making these changes. We aren’t making
acceptance contingent on these changes, but we do think they make the PEP and
the new APIs better.
-Barry (on behalf of the
Thanks Nick. Ethan, what do you think?
-Barry
> On Jul 29, 2021, at 16:28, Nick Coghlan wrote:
>
>
>
> On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
>
t; some_var = bytearray(bchr(65))
> vs
> some_var = bytearray.from_int(65)
Can you provide some rationale for why you prefer bchr() over .fromint()?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
m not a fan of smushedwords but .fromint()
seemed better than .fromord().
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.or
es.
When the SC was considering all these PEPs for 3.10, we felt like we needed
clarity on the direction and purpose of type annotations before we could make
decisions we’d have to live with essentially forever.
Cheers,
-Barry
signature.asc
Description: Message
rmine what’s right for them, their
teams, or their projects.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pytho
t this would be an acceptable resolution for most
folks. Ethan, can you reconsider?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-
> On 8 Sep 2021, at 06:39, Steven D'Aprano wrote:
>
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
>
>> I think Nick is on board with bytes.fromint() and no bchr(), and my
>> sense of the sentiment here is that this would be an acceptable
On Sep 9, 2021, at 08:53, Christopher Barker wrote:
>
> I fully admit serious bikeshedding here, but:
I think you meant “byte-shedding” :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- pyth
(length=1, byteorder=sys.byteorder, *, signed=False)
Then I ought to be able to just do
>>> (65).to_bytes()
b’A’
and if I try to convert an integer value greater than 255, I get the same
OverflowError?
Seems good enough to me.
-Barry
> On Sep 9, 2021, at 08:53, Christopher B
On Sep 9, 2021, at 10:56, Ethan Furman wrote:
>
> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>
> > While I think int.to_bytes() is pretty obscure (I knew about it, forgot
> > about it, and learned
> > about it again!) I’m not so sure it’s any less obscure than a
Adding default arguments to int.to_bytes() is both useful on its own merits and
kind of too easy *not* to do, so...
https://bugs.python.org/issue45155
https://github.com/python/cpython/pull/28265
-Barry
> On Sep 9, 2021, at 12:12, Barry Warsaw wrote:
>
> Signed PGP part
> On Sep
-be-the-default-value-for-int-to-bytes-byteorder/10616
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
ghlighting can extend deep into the
file.
speaking-for-all-3-of-the-remaining-emacs-users-ly y’rs,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
that
same mechanism?
Will `make test` and/or CI run Python with both options? How will we make sure
that frozen modules (or not) don’t break Python?
Option #3 seems like the most reasonable one to me, with the ability to turn it
on when running from the source tree.
-Barry
> On Sep 27, 2021,
We could of course bike shed on the syntax forever. The PSC did vote to accept
the PEP but we left room for changes while during the 3.11 cycle.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-de
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
That might be exceptable.
-Barry
> On Oct 6, 2021, at 08:59, Brandt Bucher wrote:
>
> Łukasz Langa wrote:
>> Joking aside, since we allow any expression after 'except' 'group' then this
>> is indeed ambiguous. In theory!
>
> Another option
own that "except group" has
> ambiguous edge cases the proposals have gotten worse, which to me is a good
> sign that we need to stop.
With async it goes *before* def, for, with.
Can you put the group before the except in the same style?
try:
stuff...
group except :
han
the kind of analysis the PSC needs in order to weigh the cost and
benefits of making such changes to Python.
TL;RA - One Syntax to Rule Them All
Cheers,
-Barry
> On Oct 7, 2021, at 09:41, S Pradeep Kumar wrote:
>
> Hello all,
>
> Typing-sig has been discussing user-friendly synt
constraint?
Hi Sergei. I don’t mean anything more than just that there should be a single
syntax for all of Python. I was just trying to describe “the bits of Python
that aren’t type annotations”.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
if there are any other security issues that must be
applied to 2.6, please let me know.
Cheers,
-Barry
[1] Guido's time machine works in both directions and prevents a 2.6.10 from
ever happening.
signature.asc
Description: PGP signature
___
P
On Feb 21, 2013, at 10:38 AM, Nick Coghlan wrote:
>- make it possible to enable safer behaviour globally in at least 2.7
>and 3.3 (and perhaps in 2.6 and 3.2 security releases as well)
I want to be fairly conservative with 2.6.9.
-Barry
___
Pyth
I really want to EOL 2.6 in October as per schedule, and I really
don't want a 2.6.10. So if we get the API changes wrong in 2.6.9 there won't
be much of an opportunity to correct it. Also, in 2.6, hash randomization is
opt-in so the default didn't change.
Cheers,
- -Barry
gt;> Colors = make('Colors', 'red green blue'.split())
>>> int(Colors.green)
2
>>> 7 + int(Colors.green)
9
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
);
Py_RETURN_NONE;
}
>>> from _intcompat import *
>>> printint(7)
and the value is: 7
>>> from flufl.enum import make
>>> Colors = make('Colors', 'red green blue'.split())
>>> printint(Colors.green)
and the value is: 2
Full
about the value).
2) When you do, wrapping the item in int() doesn't seem too bad to me.
>>> from flufl.enum import make
>>> Colors = make('Colors', 'red green blue'.split())
>>> int(Colors.blue)
3
Cheers,
-Barry
On Feb 26, 2013, at 01:22 AM, Nick Coghlan wrote:
>I don't think we need true constants - labelled values should suffice
>for easier to debug magic numbers.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
bute to return the value.
Thus if you want the int value, it would be easy enough to say
``Colors.green.int`` or ``Animals.bee.int``
https://bugs.launchpad.net/flufl.enum/+bug/1132859
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Feb 25, 2013, at 05:40 PM, brett.cannon wrote:
>http://hg.python.org/peps/rev/7aa92fb33436
>changeset: 4776:7aa92fb33436
>user:Brett Cannon
>date:Mon Feb 25 11:39:56 2013 -0500
>summary:
> Add PEP 445: The Argument Clinic DSL
I beat you with P
e much more complicated and not conducive
to dict usage.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
sed enum.
Maybe. I don't think a stdlib solution has to meet *all* needs. I think
named values plus int-interoperable enums will solve almost all use cases.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
but I have
a bug to track the feature request:
https://bugs.launchpad.net/flufl.enum/+bug/1132976
Heck, that might even allow you to implement int-derived enum values if you
really wanted them .
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@pyth
btues).
At first glance, this turns out to be pretty easy in flufl.enum.
https://code.launchpad.net/~barry/flufl.enum/lp1132976/+merge/150472
I'm not sure it's a good idea or whether it meets a real need, and you could
bikeshed on the name of the magic attribute, but I think this s
a feature matrix would be a better way to
go than something that assumes a particular Python implementation has a
particular feature set (which may change in the future).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
g packages, what critical
projects are still missing, etc.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e == 'nt'> right?)
Yeah, but that all old code ;)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e for pretty printers, GUI displays and the like
>depend on some common API.
And One True Way of invoking and/or discovering how to invoke, a package's
test suite.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
en lucky if there's a README.test and it's still accurate.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
way to declare test dependencies (a good thing), it seems
to have no way to declare how to actually run the tests.
Cheers,
-Barry
[1] Start of thread:
http://comments.gmane.org/gmane.linux.debian.devel.python/8572
[2] https://github.com/nose-devs/nose/issues/634
__
On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>setuptools feature. PEP 426 has an extension mechanism that could do
>the job.
Shouldn't "testing" be a first order feature?
On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote:
>On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw wrote:
>> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>>
>>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>>>setuptools
On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>The big thing is automated tools, not developers.
Exactly.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
ow how important tests are, so I think our tools should
reflect that and make it easy for those tests to be expressed. As a selfish
side-effect, I want to reduce the amount of guesswork I need to perform in
order to know how to run a package's test when I `$vcs clone` their
repository. ;
l script to
>run tests is interesting, but orthogonal to the thing Barry was asking
>for.
Right, two different things.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
at's just too much to hope for right now.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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. IIRC Georg and
>Barr
On Mar 17, 2013, at 09:16 PM, Glenn Linderman wrote:
>try:
>newSimpleXMLAPI()
>newapi = True
>except Exception:
>newapi = False
try:
True
except NameError:
True = 1
False = 0
-Barry
signature.asc
Description
On Mar 18, 2013, at 09:45 PM, Larry Hastings wrote:
>4. Store a string that looks like the Python declaration of the signature,
>and parse it (Nick's suggestion). For foo above, this would be
>"(arg,b=3,*,kwonly='a')". Len
v seems like the right way to manage IDLE.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hink IDLE should be a separate project entirely, but I
guess there's push back against that too.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:
>I didn't hear any at the sprint here.
JFDI! :)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
e best way to indicate that a PEP has
been updated post-Final status.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
;status quo.
The release managers should have a say in the matter, since it does cause some
amount of pain there.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
parating
the stdlib into a separate repo, for the benefit of alternative
implementations. Agreed that there are many other issues to resolve in that
latter discussion.
But I think Eli is right that we should be thinking about how to develop code
in separate repos and still ship a combined rele
g
>proper relative imports? After all, relative imports and packages go hand in
>hand.
I personally dislike PEP 328 relative imports, since they seem fragile, but
that's a different discussion.
-Barry
___
Python-Dev mailing list
Python-Dev@py
plicit conversion to the base
>type, so deprecation of subtypes makes sense as a way forward. We should
>check the other type coercion methods, too.)
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
d break, so I see no reason to
change the status quo here.
>>> class anint(int):
... def __index__(self):
... return myint(self)
...
>>> from operator import index
>>> type(index(anint(7)))
Aside: It seems a bit odd to me that bin/hex
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
>On 04/04/13 01:16, Barry Warsaw wrote:
>> the other built-in types-as-functions, so int() calls __int__() which must
>> return a concrete integer.
>Why must it? I think that's the claim which must be justified
On Apr 03, 2013, at 01:46 PM, Barry Warsaw wrote:
>It's a consistency-of-implementation issue. Where built-in types are
>callable, they return concrete instances of themselves. This is true for
>e.g. list, tuple, dict, bytes, str, and should also be true of int.
Well, I guess i
iated in 3.4. (Example, I was against re-adding the u-prefix, but I
was wrong!)
Thankfully, after October, I won't have to worry about 2.6 any more.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
ut there is thankfully a
great replacement that's Python 3 compatible).
I talked to someone at Pycon who was still using Python 1.5, which is probably
older than some of the people on this list ;).
-Barry
___
Python-Dev mailing list
Python-Dev@python
e like today's COBOL programmers (which
is good for future employment prospects :), but there's more Python 3 code out
there waiting to be written than there is existing Python 2 code today. :)
Don't worry about what you *can't* port!
- -Barry
-BEGIN PGP SIGNATURE-
V
set, or as
distinct keys in the same dictionary::
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
import Enum
>>> Colors = Enum('Colors', 'red green blue')
>>> Colors.black = Colors.blue
>>> Colors.black
>>> Colors.black is Colors.blue
True
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
this issue would not arise, but I have recently worked on
>an application that had *exactly* the above sort of enumeration used
>internally, when it would have been totally appropriate to use Enum rather
>than IntEnum. The ap has several places where an ordered comparison
>against th
ally undefined for Enums but
defined for IntEnums.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I like much of this PEP, but the exception type for this case seems
>odd to me. Wouldn't a TypeError be more appropriate here?
>
>Somewhat like this:
>
>>>> 'a' - 'b'
>Traceback (most recent call last):
> File "", line 1, in
>TypeEr
ide comparison methods if desired :)
Hey, no peeking! :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
>You get that automatically if you return NotImplemented from the
>comparison methods. I don't think you should be explicitly raising
>NotImplemented.
Oh, that's much better. Thanks, I'll update the implementation
435, but
flufl.enum will have to raise the TypeError explicitly for consistency.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Apr 12, 2013, at 08:36 AM, Ethan Furman wrote:
>Huh??
Refresh the page :).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-
ome cases to
>hide the value itself, which is often not important.
Yes, although we aren't documenting it so we don't get locked into the API.
If you look at the flufl.enum implementation, you'll see this is how we
implement IntEnums.
-Barry
___
e metaclass-based API used to create IntEnum be documented,
>so strongly motivated people can write their own crazy variants?
I think you recommended against that in python-ideas :).
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it the bill for those who want
ordered comparisons, and it's also easy to subclass EnumValues to specialize
the behavior (in fact, this is how IntEnums are implemented).
So if you really want ordered-comparisons-with-untyped-enum-values, you can
have them. :)
-Barry
enum for Python 2
compatibility, and deprecations.
Eli, what do you think about documenting the extension API?
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
you make me cry?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
se enum type's iteration
and repr. It's not crucial functionality whereas I still don't want the base
enum values to support ordered comparisons.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
disallow this
than to make it work. E.g.
if shape.color is Colors.red:
# works
if shape.color == Colors.red:
# throws an exception
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
On Apr 18, 2013, at 07:34 PM, Antoine Pitrou wrote:
>Normally you should break a buildbot as a celebration :)
Or do a release and go on vacation.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
;>> B = Enum('B', 'c b a')
>>> B
>>> for item in B: print(item)
...
B.a
B.b
B.c
>>> from flufl.enum import IntEnum
>>> C = IntEnum('C', 'c b a')
>>> C
>>> for item in C: print(item)
...
C.c
C.b
C.
sed.
There are several reasons:
* It's been that way since day 1 of the package
* Zero is special in a way; it's the only false integer value
* This is very easy to override
* If you're using the auto-numbering convenience API, then you don't care
about the values anyway
create.
>>> class StrEnum(Enum):
... __value_factory__ = StrEnumValue
Now, when you define your enumerations, the values will be ``str`` subclasses.
::
>>> class Noises(StrEnum):
... dog = 'bark'
... cat = 'meow'
ideas discussion. It was thought that this would allow for typos in
the set of enumeration items to creep in.
I don't see how you can reconcile these issues to allow for duplicate values.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http
incompatibility
either, and attribute name order is just fine.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
#x27;t care about the exact contents of __repr__ as long as it's
predictable. You don't really care about item iteration order either as long
as it's defined. Sorting by attribute name fulfills both use cases *and* it's
simple. Zen 3 FTW.
-Barry
___
Use this in new code.
>> bee = 2
>> ant = 3
>> # Backwards compatibility aliases
>> Insect.wsap = Insect.wasp
>
>Hmmm, I must have missed this.
>
>That satisfies my use-cases. Objection withdrawn.
Yay!
-Barry
_
gt;Saturday = 6
>Sunday = 7
Sorry, that's still not a complete use case. I don't see why you'd depend on
iteration order over Days for any particular functionality. Besides, if you
did, I think it would be better to derive Days from IntEnum and then iteration
order i
{
'__doc__': 'A specialized enumeration with values that are also integers.',
'__value_factory__': IntEnumValue,
})
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@pyth
to easily do
bytes->bytes or str->str transformations as easily as was possible in Python
2. I've not thought about it much, but placing those types of transformations
on a different set of functions (methods or builtins) seems like the right
direction. IOW, don't mess with en
501 - 600 of 2826 matches
Mail list logo
