On 4/13/21 3:01 PM, Jelle Zijlstra wrote:
Thanks for this PEP! Most of these proposals would make for useful improvements to the language. I have a few pieces of
feedback below.
El mar, 13 abr 2021 a las 14:14, Ethan Furman escribió:
This PEP has been deferred until Python 3.9 at the
On 4/13/21 6:20 PM, Inada Naoki wrote:
Then, does anyone oppose this change?
Having staticmethod, etc., be callable would make my code much easier in at
least two different projects.
Please make this change.
--
~Ethan~
___
Python-Dev mailing list
On 4/16/21 10:27 AM, redrad...@gmail.com wrote:
Chris Angelico wrote:
On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote:
The benefits:
You will link with high quality libstdc++ with lots of reusable containers without
writing your own "buggy" one.
C++ is much much more maintainable th
On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
or read some articles ... otherwise I will need to spend too many time
providing evidences to you and after all you will probably will reject anyway
(because lots of people is
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but currently doesn't. When running Inada Noki's benchmark,
there are a total of nine possible annotations code objects. Except, each function generated by the benchmark has a
unique name, and
urllib.urlencode currently uses `str()` on its non-bytes objects before encoding the result. This causes a
compatibility break when integer module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no longer returns
the integer representation; however, `format()` does still return the
On 4/20/21 8:46 AM, Guido van Rossum wrote:
I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this
now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?
When Enum was design
On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RED
>> to be '1&#
On 4/20/21 2:11 PM, MRAB wrote:
> On 2021-04-20 20:42, Ethan Furman wrote:
>> The deprecation period will give that user, and others like them, time to
add their own Enum base classes with the
>> `__format__` method they desire.
>
> Couldn't the format accept '
An excerpt from bpo-31369: re.RegexFlag and `__all__`
GvR:
> One thing I discovered when developing this example: there doesn't seem to be
a flag to
> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though
it works
> fine at runtime).
Which raises the question: Do
On 4/29/21 10:52 AM, Antoine Pitrou wrote:
> On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
>> On 2021-04-29 18:19, Ethan Furman wrote:
>>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
>>>
>>> GvR:
>>>
>>>> One thing
On 4/29/21 10:35 AM, Jonathan Goble wrote:
> On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>> Which raises the question: Do we want to have a standard name for stdlib
Flags when no flags are set?
>
> If you want a flag to represent no flags set, it takes one line to wri
On 4/29/21 7:57 PM, Larry Hastings wrote:
> When one writes one's "blurb" for the changelog, in what tense should it be?
Present tense. :)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le..
I have two pull requests against my cpython fork from a dependabot -- what is
that, and should I merge them?
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python
On 5/6/21 7:14 AM, Jelle Zijlstra wrote:
> Maybe others have different workflows, but I don't see much of a need
> for keeping your fork's main branch up to date.
I will occasionally do a `git push origin main` just to shut up the messages about being behind/ahead; other than that,
I have no id
On 5/8/21 1:31 PM, Pablo Galindo Salgado wrote:
>> We can't piggy back on -OO as the only way to disable this, it needs to
>> have an option of its own. -OO is unusable as code that relies on "doc"
>> strings as application data such as http://www.dabeaz.com/ply/ply.html
>> exists.
>
> -OO is the
On 5/9/21 3:00 AM, M.-A. Lemburg wrote:
> BTW: For better readability, I'd also not output the lines
> for every stack level in the traceback, but just the last one,
> since it's usually clear where the call to the next stack
> level happens in the upper ones.
Usually, sure -- but in the un
On 5/13/21 2:15 AM, Irit Katriel via Python-Dev wrote:
>
> >>> help(traceback.print_exception)
> Help on function print_exception in module traceback:
>
> print_exception(exc, /, value=,
tb= at 0x02825DF09650>, limit=None, file=None,
chain=True)
On
On 5/17/2021 6:13 AM, Mark Shannon wrote:
> Where i1, i2 are integers and s1 is a string.
> i1 + i2 + s1
>
Wouldn't the carets just be under the i2 + s1 portion?
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
On 5/20/21 11:00 AM, Paul Moore wrote:
> But it nevertheless feels like a bit of an abuse - the original point
> of ellipsis was for indexing, and in particular complex slices like
> a[1:20:2, ..., 3:5]. That usage is common in numpy, as I understand
> it,
Interesting -- do you know what ... mea
On 5/20/21 10:47 AM, David Mertz wrote:
> On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote:
>> I think it's worth preserving the idiom of comparing sentinels using
>> `is`, as we do for `None` and other existing sentinel values. It's
>> relatively easy to do, such as by using a single-value Enum o
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 name.
What is the behavior? Well, a name in a flag type can be either canonical (it represents on
On 5/28/21 12:43 AM, Petr Viktorin wrote:
> On 28. 05. 21 5:24, Ethan Furman wrote:
>> class FlagWithMasks(IntFlag):
>> DEFAULT = 0x0
>>
>> FIRST_MASK = 0xF
>> FIRST_ROUND = 0x0
>> FIRST_CEIL = 0x1
>>
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 programmer thinks it's approp
On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
> On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>> In Math / CompSci there is a definition that almost exactly matches this:
Exact Cover -
>> https://en.wikipedia.org/wiki/Exact_cover
>>
>> The difference is that, IIRC, solving the problem i
TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
`int.__str__`
IntEnum and IntFlag are becoming more common in the stdlib. They currently
show up in
* http
* re
* signal
* ssl
* socket
to name just a few.
3.10 already has some changes to the str() and repr() of enums i
I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() in 3.10 and another in 3.11 is less than
ideal, so this new thread is to collect comments about Enum and it's str() and repr() and whether the changes take
effect in 3.10, 3.11, or both.
TL;DR -- sorry, there isn't on
On 6/28/21 6:54 AM, Nick Coghlan wrote:
> * Enum repr() changing back to the historical behaviour, unless you opt in to
the
> new behaviour with the global enum decorator: definite +1 here
Question for Nick: this behavior is currently in place for stdlib enumerations, and has been since beta
On 6/29/21 9:50 AM, Barry Warsaw wrote:
> the Steering Council strongly suggests that for Python 3.10, the changes in
Enum’s
> str and repr be reverted back to the Python 3.9 behavior, and that a PEP be
written
> for Python 3.11.
I was unable to revert just the str and repr changes in the time
On 7/9/21 2:25 PM, Tim Peters wrote:
> `secrets` is just a wrapper around `random.SystemRandom`, so the
> presence or absence of `secrets` doesn't matter.
>
> As to SystemRandom, all answers depend on the quality of the platform
> os.urandom(), which Python has no control over. See my answer here
On 7/11/21 4:00 PM, Miro Hrončok wrote:
> On 07. 07. 21 3:58, Ethan Furman wrote:
>> I was unable to revert just the str and repr changes in the time available
as many of them were
>> integral to fixes and improvements made to Flag. As a result the enum in
3.10 will be the
PEP: 663
Title: Improving and Standardizing Enum str(), repr(), and format() behaviors
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-dev@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post
On 7/22/21 1:01 AM, Petr Viktorin wrote:
> On 21. 07. 21 14:18, Nick Coghlan wrote:
>>
>> typedef enum {
>> PyLocals_UNDEFINED = -1;
>> PyLocals_DIRECT_REFERENCE = 0,
>> PyLocals_SHALLOW_COPY = 1
>> } PyLocals_Kind;
>>
>> PyLocals_Kind PyLocals_GetKind(void);
>
On 7/29/21 3:46 PM, Barry Warsaw wrote:
> We’re generally very favorable for adding to Python 3.11 the features and
APIs described
> in the PEP. We have some requests for changes that we’d like you to consider.
>
> * The Python-Version in the PEP needs to target Python 3.11 of course.
Done.
>
On 8/3/21 1:19 PM, Barry Warsaw wrote:
> Can you provide some rationale for why you prefer bchr() over .fromint()?
- `bchr` directly corresponds with `chr`
- `str` has no `fromint`
- `bytearray(bchr(int))` is roughly the same as `bytearray.fromint(int)`, but
`bchr(int)` for a bytes object is
Greetings, all!
After petitioning the Steering Council I have been added as a moderator for the Python Dev mailing list. I was already
the moderator of four other Python lists.
My goal as a moderator is to have our forums be civil and within the CoC. I do rely heavily on users to let me know
After reviewing the "Problems with dict subclassing performance" thread, I am suspending Marco Sulla from Python-Dev for
a period of three months. His behavior became blatantly inappropriate, and rather than apologize he continued taunting
those that were trying to help him.
Marco took excepti
On 9/7/21 10:39 PM, 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
>> resolution for most folks. Ethan, can you recon
On 9/8/21 1:21 PM, Christopher Barker wrote:
> NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the
> name. Equating a byte with a character is a legacy of C ( and Python 2” — in
Python 3, they
> are completely distinct concepts.
No, they aren't. If you
On 9/9/21 3:49 AM, Steven D'Aprano wrote:
> We're Python programmers. To Python programmers, the int 20 is not a
> space character.
That's because int 32 is the space character. ;-)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To u
On 9/9/21 1:55 AM, Nick Coghlan wrote:
> `bytes.fromint` is still the inverse of `ord` for bytes objects, even
> without the `bchr` builtin alias. The spelling of the trio is just
> `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact
> the method throws an exception for integers
On 9/9/21 8:53 AM, Christopher Barker wrote:
> On 9/9/21 7:25 AM, Ethan Furman wrote:
>> I'm starting to think the name should be `bytes.bchr` -- it avoids any
confusion with the `int.to_bytes` and
>> `int.from_bytes` methods,
>
> are they so different? :-)
Yes, they
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 proposed
bytes.fromint().
>
> So why don’t we just relax int.to_bytes()’s signature to include n
On 9/9/21 12:12 PM, Barry Warsaw wrote:
> 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
-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-dev@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post-History: 20-Jul-2021 10-Sep-2021
Resolution:
Abstract
Now that we have a few years experience with Enum
On 9/9/21 12:04 PM, Terry Reedy wrote:
> Except that .to_bytes already exists, and arguably should have had such
defaults from the
> beginning, making any new function to do the same thing superfluous.
New functions aren't always about new functionality; sometimes they are about
increased usab
On 9/13/21 9:03 AM, Steve Dower wrote:
> You *are* allowed to put some (brief) details in the abstract. No need to
avoid spoilers ;)
>
> As it stands, "it is time" on its own is a really bad reason to change
anything. So you're
> preemptively making it sound like the PEP has no solid backing.
On 9/13/21 9:55 AM, Jelle Zijlstra wrote:
> This table doesn't render properly in
https://www.python.org/dev/peps/pep-0663/#specification.
> - There are some extra blank lines
> - Many cells are blank
> - There are two "user mixed" rows and it's not clear how those relate to the mention of
"thr
Guido:
> It's still an iterator, since it duck-types in most cases where an iterator
> is required (notably "for", which is the primary use case for the iteration
> protocols -- it's in the first sentence of PEP 234's abstract).
D'Aprano:
> I don't think it duck-types as an iterator. Here's an ex
On 9/24/21 6:51 AM, Eric V. Smith wrote:
> This is clearly an improvement. My question is: is it okay to backport this
to 3.9 and 3.10? I
> think we have a rule that it's okay to change the exception text, but I'm not
sure how that
> applies to micro releases (3.9.x, 3.10.1).
"better" != "bug
On 9/27/21 10:50 AM, Guido van Rossum wrote:
> So my *actual* proposal (call it #2') is to use a separate compile-time flag,
which is set by `./configure
> --enable-optimizations` regardless of whether PGO/LTO are possible, and which
on Windows can be set by
> `PCbuild\build.bat --pgo` (we coul
On 10/5/21 6:32 PM, MRAB wrote:
> On 2021-10-06 02:12, Barry Warsaw 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.
>>
> +1
+1
--
eli.bendersky wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums are
+not integers!
class WeekDays(Enum):
SUNDAY = enum(doc='last day of the weekend')
MONDAY = enum(doc='back to work!')
TUESDAY = enum(doc='ho hum day')
WEDNESDAY =
On 02/23/2013 08:27 AM, Eli Bendersky wrote:
Any suggestions for places in the stdlib where enums could come useful will be
most welcome
codecs.EncodedFile:
errors = 'strict' | 'ignore' | 'xmlcharrefreplace' | 'replace'
socket:
AF_INET, AF_UNIX -- socket domains (first argument to soc
On 02/23/2013 09:46 AM, Nick Coghlan wrote:
Many other existing libraries would be in the same boat - backwards
compatibility would be an insurmountable barrier to using enums, but
they *could* use named values.
I like the idea of named values, but to be clear about enums: if they are
int-bas
On 02/23/2013 09:15 AM, Eli Bendersky wrote:
Hmm, constants such as os.SEEK_* which serve as *inputs* to stdlib rather
than outputs can actually be a good
candidate for enum without worrying about backwards compatibility.
The reason I make the *input* vs. *output* distinction, is that for std
On 02/24/2013 05:40 PM, Barry Warsaw wrote:
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are +not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
This is mostly a red-h
On 02/24/2013 08:14 PM, Barry Warsaw wrote:
On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:
I would still like the int subclass, though, as it would be an aid to me on
the Python side.
I think you'll know what I'm going to say. :)
Yup, saw that coming. ;)
1) Usually, you
On 02/25/2013 06:45 AM, Eli Bendersky wrote:
2) When you do, wrapping the item in int() doesn't seem too bad to me.
If it was just once or twice, sure, but I use them as names for ints, which
means I use them as ints, which means I
would have a boat load of int() calls.
Pers
I've stated my reasons for why enums should be int based, and some of the
problems with having them not be int-based.
Besides "we just don't need them int-based in these use-cases" what are the reasons for the strong desire to have them
be valueless?
--
~Ethan~
___
On 02/25/2013 08:44 AM, Skip Montanaro wrote:
Besides "we just don't need them int-based in these use-cases" what are the
reasons for the strong desire to have them be valueless?
Not sure about other people, but piggybacking off C semantics, while
convenient, reflects the limitations of the C i
On 02/25/2013 08:37 AM, Barry Warsaw wrote:
On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
And if, in those places, the enums were based on ints (or strings), would it
hurt you? Because in the places where I, as well as many others, use enums
we *need* the int portion; and having to wrap
On 02/25/2013 10:05 AM, Barry Warsaw wrote:
On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:
>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colo
On 02/25/2013 10:49 AM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky wrote:
"DOG" > "CAT" invokes lexicographical comparison between two strings, a
well-defined and sensical operations. It simply means that in a sorted list
of strings, "CAT" will come before "DOG". Th
Antoine, question for you:
Do you think enums from different groupings should compare equal?
If no, how would you propose to handle the following:
8<
--> import yaenum
--> class Color(yaenum.Enum):
... black
...
On 02/25/2013 09:35 AM, Ethan Furman wrote:
But this I don't, and in both mine, Ted's, and Alex's versions [. . .]
My sincerest apologies to Tim Delaney (aka 'Ted') for messing up his name.
--
~Ethan~
___
Python-De
On 02/25/2013 03:22 PM, Greg Ewing wrote:
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
On 02/25/2013 07:46 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Again:
Repeating yourself doesn't help make the case. It does, however,
encourage me to reply.
Good! For a while I felt like I was talking to myself! ;)
> Definition of ENUMERATE
> 1 : to
On 02/26/2013 07:01 AM, Terry Reedy wrote:
On 2/25/2013 6:53 PM, Greg Ewing wrote:
The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animals.bee == 1 but Colors.green != Animals.bee.
And then hope that this does not create a qua
On 02/26/2013 01:29 AM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Stephen J. Turnbull wrote:
Note that in both counting and listing the object of the
operation is not an element. It is a set, and set membership is
the most important aspect of the elements for that purpose.
No, it
On 02/26/2013 11:17 AM, Antoine Pitrou wrote:
On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman wrote:
I'm beginning to see why enums as a class has not yet been added to Python. We
don't want to complicate the language
with too many choices, yet there is no One Obvious Enum to fi
On 02/26/2013 12:52 PM, Tim Delaney wrote:
On 27 February 2013 01:50, Terry Reedy mailto:tjre...@udel.edu>> wrote:
We should NOT knowingly re-introduce the same problem again! If color and
animal are isolated from each other, they
should each be isolated from everything, including int.
FWIW t
On 02/26/2013 03:26 PM, Greg Ewing wrote:
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?
Let the bike shedding begin, eh? ;)
It could be
On 03/25/2013 02:16 PM, Victor Stinner wrote:
Hi,
I just realized that the Python peephole optimizer removes useless
instructions like numbers and strings between other instructions,
without raising an error nor emiting an error. Example:
$ python -Wd -c 'print "Hello"; "World"'
Hello
As part
On 04/03/2013 08:14 AM, Nick Coghlan wrote:
On 4 Apr 2013 00:18, "Barry Warsaw" mailto:ba...@python.org>> wrote:
__index__() is a bit trickier because it is not tied directly to type
conversion. In this case, int subclasses could be valid, and as Hrvoje later
points out, returning int-subclas
On 04/03/2013 10:46 AM, Barry Warsaw wrote:
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
On 04/03/2013 12:21 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/03/2013 01:50 PM, Ethan Furman wrote:
On 04/03/2013 10:46 AM, Barry Warsaw wrote:
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other bui
On 04/04/2013 08:01 AM, Chris Angelico wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be one? Sure, I could override __new__ t
On 04/12/2013 07:51 AM, Barry Warsaw wrote:
On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:
I think either the iteration order should be undefined (like a set
or dict), or the comparison operations should work. I'd prefer
the latter, because of the use case I outlined.
Order (both itera
On 04/12/2013 08:02 AM, Barry Warsaw wrote:
On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
Ordered comparisons between enumeration values are *not* supported. Enums
are
not integers (but see `IntEnum`_ below)::
>>> Colors.red
On 04/12/2013 08:37 AM, Barry Warsaw wrote:
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 darn, this doesn't work for Python 2.7. You
On 04/12/2013 12:37 PM, � wrote:
On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen wrote:
Using intEnum is certainly doable, but that opens up the door to
comparing values from different Enums, which is not something I'd want
to allow.
I agree. Comparing values from different Enums could cause
On 04/12/2013 02:06 PM, Eli Bendersky wrote:
On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote:
>>> import enum
>>> class Foo(enum.Enum):
...aa = 1
...bb = 2
...cc = 'hi'
>>> Foo
Traceback (most recent call last):
File "", line 1, in
Fil
On 04/12/2013 03:58 PM, Christian Tismer wrote:
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
and when reading a little bit, I found the entry on multiline strings.
This entry?
Defining multiline strings
strin
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__ syntax has been repurposed for the convenience API:
--> Animals = Enum('Animals', 'ant bee cat dog')
--> Animals
--> Animals.ant
--> Animals.ant.value
1
The aforementioned deprecated syntax refers to __call__ with a single arguments
On 04/25/2013 09:34 AM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__ syntax has been repurposed for the convenience API:
--> Animals = Enum
On 04/25/2013 12:02 PM, Tres Seaver wrote:
On 04/25/2013 12:39 PM, Ethan Furman wrote:
Animals is a class. Giving Animals a parameter (such as 1 or 'ant')
should return the instance that matches.
Animals is *not* a class -- it just uses the class syntax as a convenient
way to set up
On 04/25/2013 11:44 AM, Barry Warsaw wrote:
On Apr 23, 2013, at 03:44 PM, Antoine Pitrou wrote:
I'm having a problem with the proposed implementation. I haven't found
any mention of it, so apologies if this has already been discussed:
from flufl.enum import *
class C(Enum):
... a = 1
... b
On 04/25/2013 02:17 PM, Barry Warsaw wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
Ignore the single argument call syntax for Enums please. As Eli pointed
out, you have getitem syntax for this and the single argument call syntax
is deprecated. It will be removed in a future
On 04/25/2013 02:25 PM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw mailto:ba...@python.org>> wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
For me, the getitem syntax on a class seems odd and the call syntax is
TOOWTDI.
Not if you think of it as a
On 04/25/2013 03:07 PM, Barry Warsaw wrote:
On Apr 25, 2013, at 02:30 PM, Ethan Furman wrote:
--> class Animal(Enum):
... ant = 1
... bee = 2
... fly = 3
--> Animal(2) # should return Animal.bee
--> Animal('ant') # should return Animal.ant
It seems to
On 04/25/2013 03:11 PM, Barry Warsaw wrote:
On Apr 21, 2013, at 09:12 PM, R. David Murray wrote:
Regardless of the specific values involved, it is pretty much guaranteed
that if anything other than definition order is used we *will* get bug
reports/enhancement requests to fix it, on a regular b
On 04/25/2013 03:46 PM, R. David Murray wrote:
On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman wrote:
On 04/25/2013 02:25 PM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw mailto:ba...@python.org>> wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
For m
On 04/25/2013 03:23 PM, Barry Warsaw wrote:
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw wrote:
On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
Iteration order matters a lot if you don't want people complaining about
enums being broken:
We just fixed NoneType() to return None instead of raising an exception.
Another use-case for calling NoneType is working with ORMs:
result = []
for field in row:
type = get_type(field) # returns int, bool, str, NoneType, ...
result.append(type(field))
if field is None, the resu
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 "red"
instead of "Color.red" ? I
understand the be
On 04/25/2013 05:27 PM, Steven D'Aprano wrote:
On 26/04/13 09:56, MRAB wrote:
On the other hand:
type(value)(value) == value
would return True for the built-in types (will certain exceptions, such
as when value is float("NaN")).
Not an exception, that works fine in 3.3:
value = float(
On 04/25/2013 06:03 PM, MRAB wrote:
On 26/04/2013 00:59, Glenn Linderman wrote:
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 star
On 04/25/2013 06:23 PM, Greg Ewing wrote:
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
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 the
individual enumeration instances into
801 - 900 of 1590 matches
Mail list logo
