Ethan Furman added the comment:
Note: still need to update docs.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28082>
___
___
Ethan Furman added the comment:
Still need to update docs.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28083>
___
___
Pyth
Ethan Furman added the comment:
I don't have enough socket experience to know which constants should go into
what groups and what those groups should be called. So far my involvement has
been to switch other's patches to use Enum._convert instead of
"globals().update(Enum.__memb
Ethan Furman added the comment:
The patch was initially from Serhiy as part of issue23591. So it's safe to say
at least one person requested it, and a core dev at that.
I will happily make it two people: as an occasional user of re having the
constants be named makes it much easier for me
New submission from Ethan Furman:
Split from issue23591.
Add IntFlag constants for consistency with IntEnum constants.
--
files: issue-socket.stoneleaf.01.patch
keywords: patch
messages: 275851
nosy: ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: commit review
New submission from Ethan Furman:
Split from issue23591.
--
files: issue-re.stoneleaf.02.patch
keywords: patch
messages: 275848
nosy: ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: commit review
status: open
title: re: convert re flags to (much friendlier
Ethan Furman added the comment:
Many thanks to everyone for their input and help.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Ethan Furman added the comment:
>> Which means it has methods such as __getitem__, __setitem__, etc.,
>> which means those methods can implement whatever is needed to give
>> the namespace the desired semantics (within Python syntax).
> Ah, _that_'s what you had in mi
Changes by Ethan Furman <et...@stoneleaf.us>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Ethan Furman added the comment:
Empty strings are empty strings, not None.
An better way for your code example would be:
def ...():
if url:
else:
raise URLError(...URL cannot be empty...)
--
nosy: +ethan.furman
resolution: -> not a bug
stage: -> re
Ethan Furman added the comment:
Not having a __definition_order__ could be a disadvantage for classes making
use of __getattr__ for virtual attributes, such as Enum and proxy classes.
With __definition_order__, and __dir__, Enum could present a coherent view;
without it it's a big jumbled
Ethan Furman added the comment:
What affect will this have with hash randomization?
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Ethan Furman <et...@stoneleaf.us>:
--
title: x fromat of % operator broken in Python 3.5.2 -> x format of % operator
broken in Python 3.5.2
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Ethan Furman:
With the landing of ordered class namespaces the build order for Enum needs to
be redone to at least keep the user-specified pieces' relative order intact:
>>> from enum import Enum
>>> class Color(Enum):
... red = 1
... blue = 2
... g
Ethan Furman added the comment:
Is this going to be added back? Should I add __definition_order__ to Enum?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24254>
___
_
Ethan Furman added the comment:
Evidently the correct form is:
super(SSLContext, SSLContext).options.__set__(self, value)
Not sure that's any better. :(
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
See issue14965.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28025>
___
___
Python-bugs-list
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14965>
___
_
Ethan Furman added the comment:
A little more research shows this is a problem with inheriting descriptors.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
Huh. Well, for property this works:
@property
def options(self):
return Options(_SSLContext.options.__get__(self))
@options.setter
def options(self, value):
_SSLContext.options.__set__(self, Options.OP_ALL)
Sure is ugly, though
Ethan Furman added the comment:
Can you give me a code sample?
Also, wouldn't
<Options.ALL|NO_SSLv3|NO_SSLv2|NO_COMPRESSION: 2197947391>
be more readable? And keep the "OP_" names as aliases.
--
___
Python tracker <rep...@bug
Ethan Furman added the comment:
Just so we're clear: I'm going to go with "auto()" and (mostly) use Python's
standard routines (with only a little bit of metaclass magic).
Vedran opined:
> Since you like examples, what do you say about
I love examples! Examples are like pi
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28025>
___
_
Ethan Furman added the comment:
Vedran commented:
> This is something fundamental: it is breaking the promise that class body
> is a suite of commands, where Python statements (such as assignment) have
> their usual semantics.
I find it curious that you're okay with
>>>
Ethan Furman added the comment:
> For me, it is an issue. But you probably already know that.
>(http://bugs.python.org/issue26988#msg273125) (That's "the other thread".)
Ah, thanks. I had forgotten about that one.
For what it's worth, I largely agree with you there.
>
Ethan Furman added the comment:
Any problems with:
class Color(Enum): # or Color(Flag)
red = _auto_
green = _auto_
blue = _auto_
In other words:
- is the missing parenthesis an issue?
- are linters/checkers/IDEs going to have (or report) problems
Ethan Furman added the comment:
I like it! (Although I have no idea which other thread you are talking about.)
And yes, it needs the leading and trailing underscore so as not to clash with
member names.
--
___
Python tracker <
Ethan Furman added the comment:
I would like to add a function that can be used when creating a Flag (and Enum,
but that's less important) that will generate the next value.
This is important because in Flag the values are an important internal detail,
but are largely irrelevant to the user
Ethan Furman added the comment:
Thanks for the patch, John and Emanuel!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27877>
___
__
Ethan Furman added the comment:
New changeset 871bdb06c1cf by Ethan Furman in branch 'default':
add recipes for pseudo-valueless enums
https://hg.python.org/cpython/rev/871bdb06c1cf
--
___
Python tracker <rep...@bugs.python.org>
Ethan Furman added the comment:
> IS = Enum("IS", "a, b")
functools is meant to work with types, but the enum member "IS.a" is not a type
-- however, the enum "IS" is a type.
Use "foo.register(IS)&q
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27984>
___
_
Ethan Furman added the comment:
> I am quite aware about what's the intended use, but you can't just
> assume people will know about it.
Fair enough.
> In my view, you must do one of two things:
>
> 1) (at least in documentation, and preferably in the code by raising
> E
Ethan Furman added the comment:
As a side note, I suspect there would be much less confusion with Flag if we
had an AutoEnum.
C'est la vie.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
> All my questions pertain to Flags.
Ah, okay.
> You said what to me seem like two contradictory things:
>
>> Not having 2 named has different consequences for Flag vs IntFlag
>> (although *neither is an error*): Flag: no combination of fl
Ethan Furman added the comment:
> 1) IntFlags is not simply the meet of int and Flags (like IntEnum is the
> meet of int and Enum,
> https://docs.python.org/3.5/library/enum.html#others)?
> It seems a very different class.
No, I think it is. The differences between Enum
Ethan Furman added the comment:
> Yes, you're correct here, but what about output? Do all relevant bits have
> to be named separately?
No.
> And will the output always talk about separate
> bits?
No.
> We have talked about this.
Indeed. Here's my previous reply. ;)
&
Ethan Furman added the comment:
Two things to note:
- there is no need to change the stdlib to use anything besides the default
constructor -- it's not going away, and it already works (my apologies if
I misunderstood)
- PEP 467 has not yet been accepted (unless I missed that?)
However
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27923>
___
_
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26051>
___
_
Ethan Furman added the comment:
Since we're using re as the sample, here's where re.I is defined:
Lib/re.py:
-
I = IGNORECASE = sre_compile.SRE_FLAG_IGNORECASE # ignore case
As already mentioned, re.I results in 2, and a re.compile object is not usable
as a re flag.
> Also, I supp
Ethan Furman added the comment:
Raymond, thanks for your support.
I am happy to have a flags variant. The advice to wait and let Enum mature
instead of adding the Flag variant at the beginning was sound, and we have a
better product to show for it now.
The four base Enum-type classes
Ethan Furman added the comment:
Patch includes tests, but not docs.
>From a previous comment:
---
> As it stands, Weird(7) would be <Weird.A|BC: 7>, and if A was not
> defined an error would be raised.
Actually, it would be <Weird.BC|A: 7> since BC ha
Ethan Furman added the comment:
Thanks!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26981>
___
___
Python-bugs-list
Changes by Ethan Furman <et...@stoneleaf.us>:
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Ethan Furman added the comment:
Issue 26988 reverted. Need to add shim here.
--
resolution: fixed ->
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Ethan Furman added the comment:
Serhiy, is this a quick fix you can get in?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: -ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27607>
___
_
Ethan Furman added the comment:
We'll keep the stdlib version simple.
--
resolution: -> rejected
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Ethan Furman <et...@stoneleaf.us>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Ethan Furman added the comment:
No magic, but a whole heap of extra boiler-plate. :(
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
Vedran, you have some very interesting points. However, if you really want to
champion this you'll need to take it to Python Ideas.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
Thank you, Raymond, David, Barry, John, etc. for your feedback.
While I really like AutoEnum I can see that that much magic doesn't need to
exist in the stdlib.
Unfortunately, the alternatives aren't very pretty, so I'll leave the
AutoNumberEnum as a recipe
Ethan Furman added the comment:
Raymond, I appreciate your review and your poll. I am open to removing
AutoEnum, but would like to give it a couple more weeks of review. (I'll post
on py-dev.)
The only point you made that I will firmly refute is the "unexpected breakage":
you ran
Ethan Furman added the comment:
The repr is better -- which patch did you test?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
added missing '#'
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26988>
___
___
Python-bugs-list
Ethan Furman added the comment:
The values used in Flags are an implementation detail. The expected, and
supported, use is naming the flags:
class Color(Flags):
Red, Green, Blue
even custom names can be set using this method:
>>> class Color(enum.Flags):
... red, gr
Ethan Furman added the comment:
'.0' does not have a name unless the user defines it; similarly, '.-1' does not
have a name unless the user defines it.
For Flags, negative numbers are supported in order to specify which flags are
desired, but the final representation will be zero or positive
Ethan Furman added the comment:
The zero value is special in that it represents a flag with nothing set.
Excluding it has its own problems, but if you have an argument for that
behavior I'm listening.
Any other non-Flag value is not allowed, and will raise an error (IntFlags
won't share
Ethan Furman added the comment:
Serhiy's patch is only for IntFlags, and my patch hasn't yet fully incorporated
his (many thanks for decompose!)
For IntFlags I do not expect to have very many instances alive at once,
especially since not-bitwise operators will lose the IntFlag class
Ethan Furman added the comment:
Currently, the patch has the main values pre-created (so identity works as
expected), and combinations are created on the fly (like normal class
instances) -- in which case identity cannot be relied upon.
Once I have the basic work done, I'll go back and add
Ethan Furman added the comment:
IntFlags will be in before feature freeze.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
The idea behind Flags is that they are easily combined enums. The advantage
they have over IntFlags is they do not interact with integers, and they cannot
have non-existing values used. By keeping the same API as IntFlags we only
have two APIs instead
Ethan Furman added the comment:
Flags -> int-backed, but not ints; useful for pure Python flags
IntFlags -> ints (like IntEnum); useful for interfacing with other systems
Are there better names?
--
title: Add IntFlags -> Add Flags and
Changes by Ethan Furman <et...@stoneleaf.us>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Ethan Furman added the comment:
Done in issue26988.
--
resolution: -> fixed
status: open -> closed
superseder: -> Add AutoNumberedEnum to stdlib
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Ethan Furman added the comment:
I'm not trying to rub salt in the wound, but it's a good idea (for all of us)
to test our programs with "-W always" to see if any thing pops up:
$ python3.4 -W always -c "'%x' % 3.14"
sys:1: DeprecationWarning: automatic int conversions
Ethan Furman added the comment:
Okay, I think I'm done making changes unless any more mistakes are found.
Thanks everyone for the pushing, prodding, and feedback!
--
Added file: http://bugs.python.org/file43986/issue26988.stoneleaf.05.patch
Ethan Furman added the comment:
Fixed the typos (thanks!), removed the self-reference, and went with "similar
names and purposes".
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Ethan Furman added the comment:
Did a little rewording and trimming (and formatting). Tried to keep the ideas
while not being so verbose.
--
Added file: http://bugs.python.org/file43977/issue27242.stoneleaf.01.patch
___
Python tracker <
Ethan Furman added the comment:
The 80-column thing isn't fixed yet, but I redid the patch:
- removed AutoNameEnum since there was some question of casing, etc
- redid the methodology of auto-generating values:
instead of adding it all to the prepared namespace or the metaclass, I
now
Ethan Furman added the comment:
Oh, forgot to mention I also tried testing as just 'main.py' from inside the
test directory (that's what accounted for one of the two error messages).
--
___
Python tracker <rep...@bugs.python.org>
Ethan Furman added the comment:
Sylvia, if you have any control over the name of your zip files, please use
something shorter. ;)
The files inside are a 'main.py' and a 'module.py' -- notice there is no
'__main__.py'. So it can't be executed as 'python3 -m blahblah'.
I tried renaming
Ethan Furman added the comment:
That was the last nudge I needed.
Thanks, everyone.
--
assignee: -> ethan.furman
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.py
Ethan Furman added the comment:
Oh, and yes, I'll fix the whole 80-column thing. ;)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
Okay, here's an updated patch with the doc changes.
Once the main patch is committed I'm going to reorganize the docs a bit, but
that's later.
--
assignee: -> ethan.furman
Added file: http://bugs.python.org/file43743/issue26988.stoneleaf.02.pa
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27524>
___
_
Ethan Furman added the comment:
> I think such omissions are hard to predict and you won't know where is
> the omission until you encounter it. So if you don't know, how do you
> know what to put in the tests?
True.
> And if it is encountered and fixed, such errors should not
Ethan Furman added the comment:
> I ... reorganize the existing tests a little.
Please don't.
Moving tests around makes it harder for reviewers to see what
actually changed.
Rewriting tests to do the same thing as before also takes more
work from reviewers as we have to verify the new c
Ethan Furman added the comment:
This change was done in issue25548.
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ethan Furman added the comment:
Here's the code. I'll do the doc changes next.
--
keywords: +patch
Added file: http://bugs.python.org/file43694/issue26988.stoneleaf.01.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Ethan Furman added the comment:
If you are constructing your own base Enum type, which would you rather do?
class BaseZeroEnum(Enum):
"initial integer is 0"
_start_ = 0
...
or
class BaseZeroEnum(Enum, start=0):
"initial integer is 0"
...
? Oh, an
Ethan Furman added the comment:
That brings up a really good point -- this feature requires the __prepare__
method of the metaclass, so it won't work in Python 2 any way.
So, yeah, bug-fix-mostly mode for enum34. :)
--
___
Python tracker <
Ethan Furman added the comment:
Yeah, I think the public interface will just be the AutoEnum and AutoNameEnum
style.
---
> Will these features go into enum34?
Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum.
In terms of capability, aenum is the most advan
Ethan Furman added the comment:
I don't think I'll have this in before the next alpha (today? tomorrow?) but
I'll get it merged in the next couple weeks (need to do some integration work
with the other Enum enhancements).
--
___
Python tracker <
Ethan Furman added the comment:
I like AutoEnum.
Another auto-related thought: one of the more common Enum questions on
StackOverflow is how to automatically have the value be the stringified version
of the name:
class Huh(Enum):
this
that
those
Huh.this.name == Huh.this.value
# True
Ethan Furman added the comment:
I need names. `aenum` already has an `AutoNumberEnum` (the one from the docs,
no magic) so I hate to use the same name for the stdlib version with different
behavior.
So I either need a different name for the stdlib version, or a different name
for the aenum
Ethan Furman added the comment:
The problem with testing the type of object a name refers to outside the class
is it then becomes more difficult to make that an Enum member:
class AddressType(Enum):
pobox
mailbox # third-party po box
property
Having to assign a value to `property
Ethan Furman added the comment:
A standard feature of Enum is that either space separated strings or a list of
strings is accepted any where either is.
_sunder_ names are the ones reserved for Enum use (such as _value_, _name_, and
soon _order_ (for py2/py3 compatible code
Ethan Furman added the comment:
There is one wrinkle with auto-numbering. Consider the following code:
class Color(AutoNumberEnum):
red
green
blue
@property
def cap_name(self):
return self.name.upper()
What happens with `property`?
- `property` is looked up in the class
Ethan Furman added the comment:
Reviewing...
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23591>
___
___
Python-bugs-list
Ethan Furman added the comment:
Brett, no worries. My time has been extremely limited.
I'll get the other locations in the stdlib fixed sometime in the next two
months if no one beats me to it.
--
___
Python tracker <rep...@bugs.python.org>
Ethan Furman added the comment:
Just look briefly through your patches, and they look pretty good. I'll take a
more in-depth look in the next couple weeks. (Feel free to ping again if you
don't see any activity from me, and thanks for your patience
Ethan Furman added the comment:
os.fspath() will be changed to ensure the output of calling obj.__fspath__() is
a str or bytes object.
So the final behavior of calling os.fspath() will be to return a str or bytes
or to raise an exception.
I'll update the code for this change, as well
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25958>
___
_
Changes by Ethan Furman <et...@stoneleaf.us>:
--
nosy: +ethan.furman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27242>
___
_
Ethan Furman added the comment:
os.path is actually two different modules: posixpath.py and ntpath.py
posixpath.py is being tracked in issue26027
ntpath.py is being tracked in issue27184
--
___
Python tracker <rep...@bugs.python.org>
Ethan Furman added the comment:
Currently, os.fspath will raise an exception if the thing passed in is not
str/bytes/PathLike, and that error message will proclaim that str or bytes or
PathLike is required; however, this is not true in cases such as Path (which
doesn't allow bytes
Ethan Furman added the comment:
Jelle: We still need os.open if you would like to work on that. :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
701 - 800 of 1854 matches
Mail list logo
