Steven D'Aprano writes:
> > Give us a non-MS example, please.
> I'm afraid I don't understand your question.
There were two problems mentioned. Paul worries about 4-letter
extensions under PowerShell. You mentioned conflicts in Linux file
managers. In both cases, a bug on Windows in detecti
On 4 May 2013 07:48, Nick Coghlan wrote:
> We don't need examples of arbitrary data file extentions, we need
> examples of 4 letter extensions that are known to work correctly when
> placed on PATHEXT, including when called from PowerShell. In the
> absence of confirmation that 4-letter extension
On 4 May 2013 07:42, "Nick Coghlan" wrote:
> 2. We restore __getitem__ on EnumMetaclass *solely* for member lookup
> by name (the "getmember" functionality above). This would leave
> __call__ used for the reverse lookup (value to member and hence name)
> and __getitem__ for the forward lookup (nam
Hi Matej,
On Thu, Mar 7, 2013 at 11:08 AM, Matej Cepl wrote:
> if c is not ' ' and c is not ' ':
> if c != ' ' and c != ' ':
Sorry for the delay in answering, but I just noticed what is wrong in
this "fix": it compares c with the same single-character ' ' twice,
whereas the
On Sat, 04 May 2013 11:41:27 +1000
Steven D'Aprano wrote:
>
> > Rather than risk obscure bugs, I would suggest restricting the extensions
> > to 3 characters. For the “Windowed Python ZIP Applications” case, could we
> > use .pzw as the extension instead of .pyzw?
>
> I've had Linux systems whic
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
> > Am 04.05.2013 01:22, schrieb Antoine Pitrou:
> >> On Sat, 04 May 2013 11:15:17 +1200
> >> Greg Ewing wrote:
> >>> Eli Bendersky wrote:
> >>> > I'm just curious what it is about enums t
On 05/04/2013 04:33 AM, Antoine Pitrou wrote:
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing wrote:
Eli Bendersky wrote:
I'm just curious w
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
>> Am 04.05.2013 01:22, schrieb Antoine Pitrou:
>>> On Sat, 04 May 2013 11:15:17 +1200
>>> Greg Ewing wrote:
Eli Bendersky wrote:
> I'm just curious what it is about enums that sets everyone on
Paul Moore gmail.com> writes:
> This will mean that scripts written with #!/usr/bin/env python will
> behave the same on Unix and Windows in the presence of activated
> virtualenvs.
Overall I think it's the right result. There's one other compatibility
clarification: at the moment, as allowed by
On Sat, 04 May 2013 06:37:23 -0700
Ethan Furman wrote:
>
> +1. An enum is basically a bidirectional mapping between some raw
> values and some "nice" instances, so it deserves a well-defined lookup
> operation in each direction.
> >>
> >> As I see it, there are 3 possible ways
Just to stop the bikeshedding, let's do #2. Put back __getitem__
solely for lookup by name. Keep __call__ (really __new__) for lookup
by value or "pass-through" for members.
--Guido
On Fri, May 3, 2013 at 11:42 PM, Nick Coghlan wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
>> Am
On 4 May 2013 15:20, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
> > This will mean that scripts written with #!/usr/bin/env python will
> > behave the same on Unix and Windows in the presence of activated
> > virtualenvs.
>
> Overall I think it's the right result. There's one other com
Paul Moore gmail.com> writes:
> PS Vinay - from this post, I assume you're already looking at this
> code? I was considering trying to put together a patch, but I don't want to
> duplicate effort if you're working on it.
I've taken a quick look at it, but I probably won't be able to make any
cha
FYI, I'm aware this broke some buildbots and will have a look today to
figure out why.
On Sat, May 4, 2013 at 1:57 PM, brett.cannon wrote:
> http://hg.python.org/cpython/rev/e39a8f8ceb9f
> changeset: 83607:e39a8f8ceb9f
> user:Brett Cannon
> date:Sat May 04 13:56:58 2013 -0400
>
Hello pydev,
PEP 435 is ready for final review. A lot of the feedback from the last few
weeks of discussions has been incorporated. Naturally, not everything could
go in because some minor (mostly preference-based) issues did not reach a
consensus. We do feel, however, that the end result is bette
Great job guys.
Victor
Le 5 mai 2013 00:06, "Eli Bendersky" a écrit :
> Hello pydev,
>
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated. Naturally, not everything could
> go in because some minor (mostly preference-based) i
On 05/04/2013 07:01 AM, Eric V. Smith wrote:
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
I'm now -1 on my own as_dict() suggestion, due to the general name
clash problem for arbitrary enums.
To avoid the name collision, namedtuple calls this _asdict().
Although I recall Raymond told me he should
Typo line 171:
One thing I'd like to be clear in the PEP about is whether enum_type and
_EnumDict._enum_names should be documented, or whether they're considered
implementation details.
I'd like to make a subclass of Enum that accepts ... for auto-valued enums
but that requires subclassing the m
Hm. Trailing underscores look *really* weird to me.
On Sat, May 4, 2013 at 3:41 PM, Larry Hastings wrote:
> On 05/04/2013 07:01 AM, Eric V. Smith wrote:
>
> On 5/4/2013 2:42 AM, Nick Coghlan wrote:
>
> I'm now -1 on my own as_dict() suggestion, due to the general name
> clash problem for arbitrar
On Sat, May 4, 2013 at 4:27 PM, Tim Delaney wrote:
> Typo line 171:
>
>
Fixed, thanks.
> One thing I'd like to be clear in the PEP about is whether enum_type and
> _EnumDict._enum_names should be documented, or whether they're considered
> implementation details.
>
>
No, they should not. Not o
On 5 May 2013 10:49, Eli Bendersky wrote:
>
> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
> wrote:
>
>> Typo line 171:
>>
>>
> Fixed, thanks.
>
>
>
>> One thing I'd like to be clear in the PEP about is whether enum_type and
>> _EnumDict._enum_names should be documented, or whether they're consi
It appears there's no obvious link from bugs.python.org to the contributor
agreement - you need to go via the unintuitive link Foundation ->
Contribution Forms (and from what I've read, you're prompted when you add a
patch to the tracker).
I'd suggest that if the "Contributor Form Received" field
On 5 May 2013 11:22, Tim Delaney wrote:
> On 5 May 2013 10:49, Eli Bendersky wrote:
>
>>
>> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
>> wrote:
>>
>>> Typo line 171:
>>>
>>>
>> Fixed, thanks.
>>
>>
>>
>>> One thing I'd like to be clear in the PEP about is whether enum_type and
>>> _EnumDict.
On 5 May 2013 13:11, Tim Delaney wrote:
> @@ -142,6 +152,7 @@
> if obj_type in (object, Enum):
> enum_item = object.__new__(enum_class)
> else:
> +value = obj_type.__new__(obj_type, value)
> enum_item
On 05/04/2013 08:11 PM, Tim Delaney wrote:
I've been able to achieve the auto-numbering without relying on the internal
implementation at all (with a
limitation), with a single change to enum_type.__new__. My previous patch was
slightly wrong - fix below as well. All
existing tests pass. BTW
On 5 May 2013 13:32, Ethan Furman wrote:
> On 05/04/2013 08:11 PM, Tim Delaney wrote:
>
>>
>> I've been able to achieve the auto-numbering without relying on the
>> internal implementation at all (with a
>> limitation), with a single change to enum_type.__new__. My previous patch
>> was slightl
On Sat, May 4, 2013 at 8:22 PM, Tim Delaney wrote:
> On 5 May 2013 13:11, Tim Delaney wrote:
>
>> @@ -142,6 +152,7 @@
>> if obj_type in (object, Enum):
>> enum_item = object.__new__(enum_class)
>> else:
>> +value = obj_typ
Split off from the PEP 435 - requesting pronouncement thread.
Think I've come up with a system that works for my auto-numbering case
without knowing the internals of enum_type. Patch passes all existing test
cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new
Hi,
On Sun, May 5, 2013 at 4:23 AM, Tim Delaney wrote:
> It appears there's no obvious link from bugs.python.org to the contributor
> agreement - you need to go via the unintuitive link Foundation ->
> Contribution Forms (and from what I've read, you're prompted when you add a
> patch to the trac
On 05/04/2013 10:59 PM, Ethan Furman wrote:
On 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
[snip]
2. Instead of d
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
On 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new class and uses
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 + y)'.
Seems pretty awkward t
33 matches
Mail list logo
