propose to fix the bug by not writing things back that way, instead
writing back whenever a key in the proxy is set. The discussion is about
subtler differences between the proposals.
—Guido
On Mon, Aug 23, 2021 at 22:19 Steven D'Aprano wrote:
> On Sat, Aug 21, 2021 at 05:46:52PM -0700, G
org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MK7N36L3XCXVY5R4DIIYIDU2W7EGJKZ3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/
On Thu, Aug 26, 2021 at 1:29 AM Nick Coghlan wrote:
> On Mon, 23 Aug 2021 at 13:07, Guido van Rossum wrote:
> > But... I also care about backwards compatibility, and I have a crazy
> idea for making PyEval_GetLocals() work in a useful manner without
> compromising the behavior
at would be the use case for that? I
guess to start over with a computation. But there are better ways to do
that. So let's not worry too much about preventing the user from shooting
themselves in the foot -- surely at the global level, "globals().clear()"
will do weird shit too. :-)
e object is advantageous. The cost
of the extra indirection is irrelevant, this is always going to be a slow
interface meant for occasional use in a debugger.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-
ast locals proxy
> implementation, as that could cause weird interactions if a trace hook is
> enabled during the initial start up of the interpreter and tries to trace
> the proxy implementation code.
>
Of course. But it would still be interesting to have pseudo-code in your
PEP showin
(context)
> Guido van Rossum schrieb am 13.08.21 um 19:24:
> > In 3.11 we're changing a lot of details about code objects. Part of this
> is
> > the "Faster CPython" work, part of it is other things (e.g. PEP 657 --
> Fine
> > Grained Error Locations in
s compatibility for these two
functions.
That means:
- Get rid of PyCode_NewWithPosArgs altogether
- PyCode_New becomes unstable (and gets a new posinlyargcount argument)
On Wed, Sep 1, 2021 at 11:52 AM Guido van Rossum wrote:
> (context)
>
>> Guido van Rossum schrieb am 13.08.21 u
rg/message/TDLCJHNQSPNE7UXEJ33PV2VNQOPUFUT7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-wo
is defined, skip calling __iter__ in iter()".
>
> The optimisation that bypasses the __[a]iter__ method call feels more
> legitimate in the actual for loop syntax, it just feels odd to me if the
> builtin isn't forcing the call.
>
> Cheers,
> Nick.
>
>>
&g
Quick reaction: This feels like a bait and switch to me. Also, there are
many advantages to using a standard format like zip (many formats are
really zip with some conventions). Finally, the bytecode format you are
using is “marshal”, and is fully portable — as is zip.
On Thu, Sep 2, 2021 at 21:44
On Fri, Sep 3, 2021 at 4:12 PM Victor Stinner wrote:
> On Thu, Sep 2, 2021 at 11:15 PM Guido van Rossum wrote:
> > FWIW I've applied for an exception from the two-release deprecation
> policy from the SC:
> > https://github.com/python/steering-council/issues/75
>
>
On Tue, Sep 7, 2021 at 10:00 AM Stefan Behnel wrote:
> Guido van Rossum schrieb am 07.09.21 um 00:44:
> > In addition, I just heard from the SC that they've approved the
> exception.
> > So we will remove these two APIs from 3.11 without deprecation.
>
> Erm, ha
role in laying its
foundation, as it allows for the expression of both
dimensioability as well as basic shape manipulation .
All in all, I'm very interested in where both PEP 646 and future PEPs will take
us and look forward to further developments.
Regards,
Ba
dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3W7TDX5KNVQVGT5CUHBK33M7VNTP25DZ/
> Code of Conduct: http://python.org/psf/codeofconduct
s people register things
that don't follow the letter of the protocol, just to get things going.
(This is common for complex protocols like Mapping, where some function you
have no control over insists on a Mapping but only calls one or two common
methods.
Duck typing is alive and kicking!
-
On Tue, Sep 14, 2021 at 4:33 PM Brandt Bucher
wrote:
> Guido van Rossum wrote:
> > On Tue, Sep 14, 2021 at 3:49 PM Brandt Bucher brandtbuc...@gmail.com
> > wrote:
> > > I think it's also worth noting that a missing "`__iter__` that returns
> > > self&qu
On Tue, Sep 14, 2021 at 9:03 PM Steven D'Aprano wrote:
> On Tue, Sep 14, 2021 at 12:33:32PM -0700, Guido van Rossum wrote:
> > My view of this is:
> >
> > A. It's not an iterator if it doesn't define `__next__`.
> >
> > B. It is strongly
t that only has __next__,
> apart from "broken" :-(
>
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'
On Tue, Sep 14, 2021 at 11:44 PM Steven D'Aprano
wrote:
> On Tue, Sep 14, 2021 at 09:38:38PM -0700, Guido van Rossum wrote:
>
> > > I don't know what I would call an object that only has __next__,
> > > apart from "broken" :-(
> > >
> &
-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/KEURSMCLUVI7VPKM6M2VUV4JIW6FP66Z/
> Code of Conduct: http
def __iter__(self):
return A()
Now this works:
for x in S(): ...
However this doesn't:
for x in iter(S()): ...
In Steven's view, A does not deserve to work in the former case: Because A
is a "broken" iterator, he seems to want it rejected by the iter() call
that is
> https://mail.python.org/archives/list/python-dev@python.org/message/TWSJKE4KKSW7YD3OCHKGKJC52VUG6FY5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/
On Mon, Sep 20, 2021 at 1:07 PM Patrick Reader <_...@pxeger.com> wrote:
> > The current restrictions will also confuse some users (e.g. those used
> to bash, and IIRC JS, where the rules are similar as what Pablo is
> proposing).
> > --
> > --Guido van Rossum (python
print(f"{source.removesuffix(".py")}.c: $(srcdir)/{source}")
^
SyntaxError: f-string: unmatched '('
```
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/0
s before")
print(f"{source.removesuffix(".py")}.c: $(srcdir)/{source}")
print("\t$(COMMAND)")
So these two tools, at least, seem to be doing all right (maybe because
they both come from the JavaScript culture, where ne
on just
because it's in an f-string.
I presume it was trickier at the time because we were coming from
"{xxx}".format(...), where the parser doesn't know that the string is a
format string.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun
In this case I am inclined not to backport.
In general we should look at existing usage before making changes.
Somebody’s code might break — but does it matter? That depends on a lot of
factors. E.g. if parsing an error message has become a common way to get
useful info out of the error that is no
is `./configure --enable-optimizations`, which doesn't
mention PGO -- IIUC it turns on PGO and LTO, if they're available.
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 P
What I have heard repeatedly, from people who are paid to know, is that
most users don’t care about the latest features, and would rather stick to
a release until it becomes unsupported. (Extreme example: Python 2.)
Numpy isn’t random, it’s at the bottom of the food chain for a large
ecosystem or
We’ll, typically you don’t explicitly mention ExceptionGroup — it’s implied
by the ‘except*’ syntax. Introducing match semantics probably wouldn’t open
up new functionality, you can already write ‘except (E1, E2):’.
On Sun, Oct 3, 2021 at 09:00 Thomas Grainger wrote:
> What about `except case Ex
iding any feedback on the use of 'except
*'. So I think it's a bit late to be bikeshedding the syntax. This thread
was meant to solicit feedback on how to *format* it: does the space go
before or after the '*'.
--
--Guido van Rossum (python.org/~guido)
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.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun
The question was about which style to *recommend* (a la PEP-8).
On Mon, Oct 4, 2021 at 8:03 AM Jonathan Goble wrote:
> On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum wrote:
>
>> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble wrote:
>>
>>> Therefore my vote is fo
some + expression group as e: …
Argh. This would be very easy to overlook. As the senior author of PEP 654
I am going to go with "except*". Since it was shown that "except group" has
ambiguous edge cases the proposals have gotten worse, which to me is a good
sign that we
To be clear, Sam’s basic approach is a bit slower for single-threaded code,
and he admits that. But to sweeten the pot he has also applied a bunch of
unrelated speedups that make it faster in general, so that overall it’s
always a win. But presumably we could upstream the latter easily,
separately
u can't write "def f x:
return x+1" and you can't write "f 42". Allowing the omission of the
parentheses here would be inconsistent (even if some other languages allow
it).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him
hat's basically Question 2 - whether to just replace Callable in
> the initial PEP (option 1) or to specify a more complete syntax from the
> beginning (option 2).
>
> 5. Serhiy Storchaka
>
> > How could you replace Callable[..., int] and Callable[Concatenate[str,
> P],
e that it must
return something introspectable is the same.) Union objects have an
`__args__` attribute that gives the underlying types, and a
`__parameters__` attribute giving any type variables.
Note that the implementation of this introspectable type should ultimately
be in C.
--
--Guido van Ross
ense of
> the house" for what Python4 means at this point :)
>
> --David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://m
AM, Brett Cannon wrote:
>
>
>
> On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum wrote:
>>
>> Generally speaking, deferring something to Python 4 means "never".
>
>
> Does that mean your aversion to double digit version numbers (i.e. 3.10) is
>
Or at least just a use
case that's poorly covered?
TBH, your choice of words is ambiguous -- are you interested in
overhauling the facilities for testing *of* the standard library (i.e.
the 'test' package), or the testing facilities *provided by* the
standard library (i.e. the unittest
#x27;, x is ''
> (True, False)
Code that relies on this is incorrect (the language doesn't guarantee
interning) but nevertheless given the intention of the implementation,
that behavior of encode() is also a bug.
--
--Guido van Rossum (python.org/~guido)
On Wed, Mar 6, 2013 at 2:20 AM, Terry Reedy wrote:
> Clicking this link
> http://www.microsoft.com/en-us/download/details.aspx?id=14597
> on this Developer Guide page
> http://docs.python.org/devguide/setup.html#windows
> now returns a
> "We are sorry, the page you requested cannot be found."
> pa
On Wed, Mar 6, 2013 at 3:32 PM, Terry Reedy wrote:
> On 3/6/2013 12:29 PM, Steve Dower wrote:
>>
>> From: Case Van Horsen
>
>
>>> The "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1"
>>> is still available for download. It includes
ng code that does:
>
> from timeit import *
>
> May break. The above may not be the recommended best practice in Python, but
> it's perfectly valid and widely used.
>
> Eli
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mai
ConvArg { arg_name = path_converter,
>arg_type = int (*converter)(PyObject *, void *)
>arg_use_ptr = false },
> MainArg { arg_name = path,
>arg_type = path_t,
>
of brackets for indexing and a
> dictionary lookup. However it is too late to discuss this idea.
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscri
rough as the Python default and the annotation would be left blank.
Right. In fact, I think the decision of what (if anything) should be
put in the annotation should be up to the converter class. It can be a
specific method on the converter object.
--
--Guido van Rossum (python.org/~guido)
___
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
the same way? It has the same issue of
popping up, rarely, when you least expect it, and messing with your code.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
x27;s Python core.
> Getting things committed in Python is not easy, and even if we get a sudden
> influx of good patches (which I doubt) these will take time to review and
> get committed. In an outside project there's much less friction.
>
> IDLE would be a great first foray into t
owever we should switch to bundling the separate project's output
rather than bundling the increasingly broken version in the stdlib. What
other distributors do is outside our control, but we ought to recommend
them to do the same.
--
--Guido van Rossum (python.org/~guido)
__
On Wed, Mar 20, 2013 at 12:38 PM, Barry Warsaw wrote:
> On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
>
> >Agreed that the "sync into stdlib" think should not happen, or should at
> >best be a temporary measure until we can remove idle from the source
> >
be used as comments.
>
> --
> ~Ethan~
>
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo
underlying base class to remove the special treatment.
--
--Guido van Rossum (python.org/~guido
___
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
expect
> that Foo(x) will return a Foo object, not a Bar object. Why should int
> be any different? What have I missed here?
>
A class can define a __new__ method that returns a different object. E.g.
(python 3):
>>> class C:
... def __new__(cls): return 42
...
>>> C()
in a package whose __init__.py imports them
in the desired order.)
I don't really see what we could change to avoid breaking code in any
particular case -- the burden is up to the library to do it right. I don't
see a reason to forbid any of this either.
--
--Guido van Rossum (python.org/
On Thu, Apr 4, 2013 at 8: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 expe
Redirecting to python-ideas.
On Thu, Apr 4, 2013 at 9:26 AM, Richard Oudkerk wrote:
> On 04/04/2013 4:17pm, Guido van Rossum wrote:
>>
>> I don't really see what we could change to avoid breaking code in any
>> particular case -- the burden is up to the library to do
#x27;t want to compromise on the
latter. I do think it would be fine if "from a import b" returned the
attribute 'b' of module 'a' if it exists, and otherwise look for
module 'a.b' in sys.modules.
On Thu, Apr 4, 2013 at 1:28 PM, PJ Eby wrote:
> On Thu, Apr
n C using an unsafe cast, and the code that
checks for allowable subclasses of int actually ensures such a cast
will work. But it still feels wrong; __int__ should be expected to do
the work.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing lis
+1 on Brett and PJE just doing this.
On Thu, Apr 4, 2013 at 3:38 PM, Brett Cannon wrote:
>
>
>
> On Thu, Apr 4, 2013 at 5:00 PM, PJ Eby wrote:
>>
>> On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote:
>> > I do think it would be fine if "from a import
om/p/psutil/
> https://code.google.com/p/pysendfile/
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/py
ven Cython) are feeling down on Python 3
because they do not have enough volunteers to help with the port (even
though at least for IronPython and Jython, the new str/bytes model is
much more suitable than the old), they should apply to the PSF for
funding. I believe PyPy is already in the pro
re of them may reply-all to this message with more details.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/p
On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou wrote:
> On Thu, 11 Apr 2013 14:11:21 -0700
> Guido van Rossum wrote:
>> Hey Antoine,
>>
>> Some of my Dropbox colleagues just drew my attention to the occurrence
>> of case folding in pathlib.py. Basically, cas
On Thu, Apr 11, 2013 at 4:09 PM, Cameron Simpson wrote:
> On 11Apr2013 14:11, Guido van Rossum wrote:
> | Some of my Dropbox colleagues just drew my attention to the occurrence
> | of case folding in pathlib.py. Basically, case folding as an approach
> | to comparing pathnames is fa
. But that's not the case here, is
it? It's not a bug in the class, it's a bug in the call site. So I
agree it ought to be TypeError.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum wrote:
> To me, NotImplementedError means that a subclass didn't implement
> something it should have implemented. But that's not the case here, is
> it? It's not a bug in the class, it's a bug in the call site
024 IIRC). But short names pretty much require
consulting the filesystem, so we can probably ignore them.
I guess the bottom line is that, no matter how hard pathlib tries,
apps cannot always rely on the predictions about filename validity or
equivalence made by pathlib -- we'll have to
On Fri, Apr 12, 2013 at 12:26 PM, Barry Warsaw wrote:
> On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:
>
>>I do wonder about this passage in the PEP:
>>
>>> Let's say you wanted to encode an enumeration value in a database. You
>>> might want to
types: object() < object()
>
> Now, you could *further* require that the type of enum values be
> sortablebut that point you really have no excuse for not allowing
> enum values to be compared :)
>
> --David
> _______
> Python-Dev mailing list
> Python-Dev@python.org
&g
On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw wrote:
> On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:
>
>>So, pragmatically, if e and f are values of the same enum class,
>>couldn't e f (where is any comparison operator) defer to
>>e.value f.value ? Or is t
Well, even better. :-)
On Fri, Apr 12, 2013 at 5:13 PM, Glenn Linderman wrote:
> 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
ms that I get in Python 3 from
> non-enums. That is, if enums X.a and X.b happen to both be ints, or both
> strings, then comparisons should succeed, but if they are different types, I
> should get a TypeError.
>
> The above applies to related enums. If they are unrelated (
int subclass that does
better and use that -- IntEnum is just one example of how you can
override the value type of Enum. (And yes, I am now +1 on documenting
this mechanism.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python
So clearly the ree expectation is that they compare equal (if the values
are).
On Apr 13, 2013 11:24 AM, "Scott Dial"
wrote:
> On 4/12/2013 10:51 PM, Steven D'Aprano wrote:
> > And two examples from asm-generic/errno.h:
> >
> > #define EWOULDBLOCK EAGAIN /* Operation would block */
> > #defi
er what |
> `\mnemonic means, you've got a problem.” —Larry Wall |
> _o__) |
> Ben Finney
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/p
;
>-Nikolaus
>
> --
> »Time flies like an arrow, fruit flies like a Banana.«
>
> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http:/
gh this list are priceless.
> ___
> 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/guido%40python.org
gt;> 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
>
rg
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http:
we *will* get bug
> reports/enhancement requests to fix it, on a regular basis. We can choose
> to live with that, but we should admit that it will will happen :)
I'm convinced. I also think that 2/3 compatibility is not as important
as getting it right for the foreseeable future.
--
--Guido van Rossum (sent from Android phone)
On Apr 22, 2013 6:09 PM, "R. David Murray" wrote:
>
> On Tue, 23 Apr 2013 11:16:20 +1200, Greg Ewing <
greg.ew...@canterbury.ac.nz> wrote:
> > Victor Stinner wrote:
> > > The last proposition is to add transform
rs to all of these, and your rhetoric is not
appreciated. The special status is for the translation between bytes
and Unicode characters (code points). There are many contexts where a
byte stream is labeled (either separately or in-line) as being encoded
using some specific encoding.
--
--Guido va
that the builtin help() function always displays the class's
> __doc__, even when called on an instance which has its own __doc__.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
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 Tue, Apr 23, 2013 at 8:31 AM, R. David Murray wrote:
> On Tue, 23 Apr 2013 08:11:06 -0700, Guido van Rossum wrote:
>> I gotta say, I'm with Antoine here. It's pretty natural (also coming
>> from other languages) to assume that the class used to define the
>> enu
odec interfaces, without
> enforcing type restrictions. The codec defines the supported
> input and output types.
As an implementation mechanism I see nothing wrong with this. I hope
the codecs module lets you introspect the input and output types of a
codec given by
ott
>
> --
> Scott Dial
> sc...@scottdial.com
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/pyt
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
>>> encode()/decode() functions in the codecs module:
&g
agic, and the only
consequences we can reason about are those that are documented as
consequences of using this particular kind of magic. I'm not sure that
we can implement a hack to prevent MyEnum.a.b from being an alias for
MyEnum.b, but even if we cannot prevent that, I don't think we need t
mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
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
FWIW,
If we're going ahead with the plan to make Colors.red an instance of
Colors, maybe the class names used in examples should be singular,
i.e. isinstance(Color.red, Color)?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing
27;t know what's going on, but it feels like we had this same
discussion a week ago, and I still disagree. Disregarding, the C[i]
notation, I feel quite strongly that in the following example:
class Color(Enum):
red = 1
white = 2
blue = 3
orange = 4
the values Color
On Thu, Apr 25, 2013 at 3:02 PM, Barry Warsaw wrote:
> On Apr 25, 2013, at 02:54 PM, Guido van Rossum wrote:
>
>>I don't know what's going on,
>
> Mostly that this is my first opportunity to chime in on the subject.
>
>>but it feels like we had this sa
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
>>object as Col
#x27;t likely to be useful in
this context.
> 3. Inspired by namedtuple, move the current Enum constructor
> functionality to an Enum._make() API (implemented either as a class
> method in Enum or as an ordinary method on the metaclass)
--
--Guido van Rossum (python.org/~guido)
___
values are ints and strings, and even the latter could be
considered a luxury when compared to other languages' enums.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
On Fri, Apr 26, 2013 at 10:33 AM, Glenn Linderman wrote:
> 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
On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky wrote:
> On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum wrote:
>> > On 4/25/2013 9:19 PM, Guido van Rossum wrote:
>> I think you've lost track of the Zen of Python.
>
> I feel that this thread has lost track of it l
1601 - 1700 of 6462 matches
Mail list logo
