Steven D'Aprano wrote:
With a length hint, we could strengthen that promise:
if __length_hint__ returns a negative number, list, tuple and set will
fail immediately with MemoryError
which I think is a good safety feature for some things which cannot
possibly succeed, but risk DOSing your
Stephen J. Turnbull wrote:
The point is that I don't really see the value in returning a precise
estimate that cannot be relied on to be accurate. OK, Python is a
consenting adults language, but returning an integer here seems like
invitation to abuse.
Since __length_hint__ already exists
Victor Stinner wrote:
== Other Python VM and compilers ==
As far as I know, these are all still active, although possibly experimental:
Pynie (Python for the Parrot VM)
WPython (16-bit word-codes instead of byte-codes)
HotPy (high-performance
Victor Stinner wrote:
Hi,
Python 3.3 introduced os.supports_dir_fd to check if some os functions
do accept a file descriptor instead of a path. The problem is that
os.supports_dir_fd is a list of functions, not a list of function
names. If os functions are monkey patched, you cannot test
On 14/08/12 06:46, Guido van Rossum wrote:
On Mon, Aug 13, 2012 at 1:05 PM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
On Mon, Aug 13, 2012 at 12:06 PM, Brett Cannonbr...@python.org wrote:
I see nothing about ast possibly being CPython only. Should there be?
Time to ask the other
On 21/08/12 23:04, Victor Stinner wrote:
I don't like the timeit module for micro benchmarks, it is really
unstable (default settings are not written for micro benchmarks).
[...]
I wrote my own benchmark tool, based on timeit, to have more stable
results on micro benchmarks:
On 01/09/12 23:44, Victor Stinner wrote:
Hi,
I changed many functions of the curses module in Python 3.3 to improve
its Unicode support:
[...]
Thank you.
For example, if the Python curses module is not linked to libncursesw,
get_wch() is not available and addch(é) raises an OverflowError
On 19/09/12 18:51, Ido Yohanan wrote:
Hi,
I am working with PYTHON 1.5 and want to control versions of every pyo
file.
Python 1.5? Are you serious?
Python 1.5 is now at least 8 versions obsolete, and hasn't been updated
since approximately 1995.
Is there any way I can assign a file
On 20/09/12 22:59, Mark Dickinson wrote:
On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlanncogh...@gmail.com wrote:
+1 for using the unqualified argument in these error messages to
mean positional or keyword argument (inspect.Parameter spells it out
as POSITIONAL_OR_KEYWORD, but the full phrase is
On 21/09/12 00:49, Antoine Pitrou wrote:
On Thu, 20 Sep 2012 10:12:04 -0400
Benjamin Petersonbenja...@python.org wrote:
2012/9/20 Mark Dickinsondicki...@gmail.com:
Thoughts?
I tried to define the error messages in terms of the callee's
signature. I call the formals that are not variadic,
On 21/09/12 01:53, Oscar Benjamin wrote:
Mark Dickinson wrote:
def f(x): pass
...
f()
Traceback (most recent call last):
File stdin, line 1, inmodule
TypeError: f() missing 1 required positional argument: 'x'
I would say that the only problem with this terminology is that it would be
On 21/09/12 05:45, Ethan Furman wrote:
I don't expect error messages to give a complete catalog of every
problem with a specific function call. If f() reports that required
argument 'a' is missing, that does not imply that no other required
arguments are also missing. I think it is perfectly
On 30/09/12 10:43, Jan Kaliszewski wrote:
Hello,
In http://docs.python.org/release/3.2.3/reference/expressions.html#in we
read: [...] This can create the illusion of non-transitivity between
supported cross-type comparisons and unsupported comparisons. For example,
Decimal(2) == 2 and 2 ==
On Sun, Sep 30, 2012 at 07:12:47PM -0400, Brett Cannon wrote:
python3 perf.py -T --basedir ../benchmarks -f -b py3k
../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3
### call_method ###
Min: 0.491433 - 0.414841: 1.18x faster
Avg: 0.493640 - 0.416564: 1.19x faster
On 03/10/12 18:54, Serhiy Storchaka wrote:
For locals vars() returns... hmm, partially modifiable dict:
def f():
... x = 42
... print(vars())
... vars()['x'] = 43
... vars()['y'] = 44
... print(x, vars())
...
f()
{'x': 42}
42 {'y': 44, 'x': 42}
Should behavior of vars() be corrected for
On 05/10/12 22:58, Nick Coghlan wrote about locals():
As for *why* changes don't get written back, it's because the compiler
is allowed to assume it knows about every variable name that exists in
the local scope (by design), and that doesn't fit with writable
locals() for functions.
And to be
On 19/10/12 12:03, Victor Stinner wrote:
Hi,
I would like to know if there a reason for not using the hash of
(bytes or unicode) strings when comparing two objects and the hash of
the two objects was already been computed. Using the hash would speed
up comparaison of long strings when the two
On 20/10/12 01:13, Nick Coghlan wrote:
On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cunianto.c...@gmail.com wrote:
Is that the real intended behavior?
Given the way complex numbers interact with floats generally,
returning a complex number with no imaginary component as a floating
point value
On 21/10/12 06:28, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2012 07:35 PM, Greg Ewing wrote:
Antonio Cuni wrote:
Traceback (most recent call last): File stdin, line 1, in
module TypeError: __complex__ should return a complex object
i.e., the complex
On 21/10/12 19:47, Serhiy Storchaka wrote:
On 21.10.12 09:05, Greg Ewing wrote:
The equivalent solution here would be to add a new operator
for complex exponentiation that coerces its operands to
complex, and restrict the existing one to floats only.
In case of division a new operator (//)
On 21/10/12 21:11, Antoine Pitrou wrote:
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelicoros...@gmail.com wrote:
On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Apranost...@pearwood.info wrote:
Python 2.x legitimately distinguished between floats and complex, e.g.:
py (-100.0)**0.5
Traceback
On Mon, Oct 22, 2012 at 02:25:45PM +1100, Chris Angelico wrote:
There really aren't that many situations where a program will be
completely oblivious of complex/imaginary numbers and be able to
encounter them... are there?
Fortunately the math module does not promote float to complex:
py
On 26/10/12 02:57, Mark Lawrence complained that he can't subclass memoryviews:
I'm guessing that I've missed something that's blatantly obvious to
everybody except myself. I can't find a rationale anywhere as to why
I can't subclass memoryviews for my code, so I can't work around
what I
On 01/11/12 06:57, anatoly techtonik wrote:
[...]
UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment
As you may see there is inconsistency between handling of line 6 -
if len(DEBUG): and line 8 - if len(FONT_NAMES):. This is very magical
and hard to troubleshoot.
I
On 08/11/12 08:39, Ned Batchelder wrote:
Just to be clear: the reference guide says that the behavior *SHOULD BE* (but
is not yet) this:
Python 3.3.0
{print(a):print(b)}
a
b
{None: None}
That was the behaviour of Python 2.4:
py def pr(x):
... print x
...
py {pr(1): pr(2), pr(3):
On 14/11/12 21:00, Chris Withers wrote:
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers ch...@simplistix.co.uk wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other
words: you can run dict() _five
On 15/11/12 05:54, Mark Adam wrote:
Merging of two dicts is done with dict.update. How do you do it on
initialization? This doesn't make sense.
Frequently.
my_prefs = dict(default_prefs, setting=True, another_setting=False)
Notice that I'm not merging one dict into another, but merging
On 06/12/12 03:08, Chris Withers wrote:
I'd like to change the docs for poll() to say:
Check if child process has terminated.
If it has, the returncode attribute will be set and that value will be returned.
If it has not, None will be returned and the returncode attribute will remain
None.
On 09/12/12 08:14, MRAB wrote:
If package A says that it conflicts with package B, it may or may not
be symmetrical, because it's possible that package B has been updated
since the author of package A discovered the conflict, so it's
important that the user is told which package is complaining
On 09/12/12 12:32, Chris Angelico wrote:
On Sun, Dec 9, 2012 at 12:15 PM, Steven D'Apranost...@pearwood.info wrote:
Assuming that two software packages Spam and Ham install into directories
Spam and Ham, how can merely having them installed side-by-side lead to a
conflict?
I can see how
On 10/12/12 20:40, Armin Rigo wrote:
As a side note, your suggestion also enables order-preserving
dictionaries: iter() would automatically yield items in the order they
were inserted, as long as there was no deletion. People will
immediately start relying on this feature... and be confused
On 29/12/12 05:02, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsawba...@python.org wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
The
On 29/12/12 15:40, Lennart Regebro wrote:
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Apranost...@pearwood.infowrote:
The PEP says:
* New function :``timezone(name=None, db_path=None)``
This function takes a name string that must be a string specifying a
valid zoneinfo timezone, ie
On 30/12/12 07:16, Lennart Regebro wrote:
If no database is found an ``UnknownTimeZoneError`` or subclass
thereof
will
be raised with a message explaining that no zoneinfo database can be
found,
but that you can install one with the ``tzdata-update`` package.
Why should we
On 28/01/13 23:52, Antoine Pitrou wrote:
Le Mon, 28 Jan 2013 22:31:29 +1000,
Nick Coghlanncogh...@gmail.com a écrit :
6. Under New collections
Why both lists and sets?
Because pytz did it. But yes, you are right, an ordered set is a
better solution. Baseing it on OrderedDict seems like a
On 12/02/13 10:56, Jan Kaliszewski wrote:
Wouldn't __initclass__ be readable enough? IMHO it could spare users
trouble with remembering special case.
+1
I approve of the colour of this bikeshed. __init_class__ has too many
underscores.
--
Steven
On 12/02/13 18:05, Chris Withers wrote:
Hi all,
So, dicts in Python 3 return something different from their keys and values
methods:
dict(x=1, y=2).keys()
dict_keys(['y', 'x'])
type(dict(x=1, y=2).keys())
class 'dict_keys'
I have vague memories of these things being referred to as
On 13/02/13 19:52, Larry Hastings wrote:
I've always hated the .join(array) idiom for fast string concatenation
--it's ugly and it flies in the face of TOOWTDI. I think everyone should
use x = a + b + c + d for string concatenation, and we should just make
that fast.
.join(array) is much
On 13/02/13 20:09, Chris Withers wrote:
On 12/02/2013 21:03, Maciej Fijalkowski wrote:
We recently encountered a performance issue in stdlib for pypy. It
turned out that someone commited a performance fix that uses += for
strings instead of .join() that was there before.
That's...
On 13/02/13 22:46, Xavier Morel wrote:
On 2013-02-13, at 12:37 , Steven D'Aprano wrote:
# even less obvious than sum
map(operator.add, array)
That one does not work, it'll try to call the binary `add` with each
item of the array when the map iterator is reified, erroring out
On 13/02/13 10:53, Christian Tismer wrote:
Hi friends,
_efficient string concatenation_ has been a topic in 2004.
Armin Rigo proposed a patch with the name of the subject,
more precisely:
/[Patches] [ python-Patches-980695 ] efficient string concatenation//
//on sourceforge.net, on
On 14/02/13 01:18, Chris Withers wrote:
On 13/02/2013 11:53, Steven D'Aprano wrote:
I fixed a performance bug in httplib some years ago by doing the exact
opposite; += - ''.join(). In that case, it changed downloading a file
from 20 minutes to 3 seconds. That was likely on Python 2.5.
I
On 14/02/13 01:44, Nick Coghlan wrote:
Deliberately *relying* on the += hack to avoid quadratic runtime is
just plain wrong, and our documentation already says so.
+1
I'm not sure that there's any evidence that people in general are *relying* on
the += hack. More likely they write the first
On 16/02/13 16:41, Stefan Behnel wrote:
PyPy is indeed a work in progress in this area, but that doesn't
necessarily preclude it from being included.
That may be a matter of POV, but as long as PyPy fails to integrate (and
you just called that not a main focus), I find it hard to defend its
On 20/02/13 11:54, Fred Drake wrote:
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufftdonald.stu...@gmail.com wrote:
Let's not add anything to the stdlib till it has real world usage. Doing
otherwise is putting the cart before the horse.
I'd posit that anything successful will no longer need to
On 21/02/13 10:22, Antoine Pitrou wrote:
On Wed, 20 Feb 2013 18:21:22 -0500
Donald Stufftdonald.stu...@gmail.com wrote:
On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A
single 1 kB XML document can kill
On 28/02/13 07:20, anatoly techtonik wrote:
* as an exercise - try to build a scroller for a running Python script
* it is impossible for Python 2 and probably for Python 3 as well
What do you mean by a scroller?
[...]
and why PSF doesn't comply the 4. Redistribution clause
On 28/02/13 23:26, Stefan Krah wrote:
Jesse Noller jnol...@gmail.com wrote:
We have one: p...@python.org
That's not exactly a public mailing-list.
Nope. But it's also where lawyers flock and these issues can rapidly be
resolved.
If the list isn't publicly archived, the same questions
On 05/03/13 09:08, Brett Cannon wrote:
Depends on your paranoia. If you're worried about accidentally lifting IP
merely by reading someone's source code, then you wouldn't want to touch
code without the CLA signed.
Now I'm not that paranoid, but I'm still not about to commit someone's code
now
On 02/03/13 02:43, Demian Brecht wrote:
Cross-posting from python-ideas due to no response there. Perhaps it's
due to a general lack of usage/caring for cookiejar, but figured
/someone/'s got to have an opinion about my proposal ;)
Apparently not :-(
TL;DR: CookieJar FileCookieJar
On 19/03/13 00:50, Neal Becker wrote:
def F(x):
return x
x = 2
F(x) = 3
F(x) = 3
SyntaxError: can't assign to function call
Do we really need this restriction? There do exist other languages without it.
What meaning would you give to F(x) = 3, and why?
--
Steven
On 19/03/13 02:01, Hrvoje Niksic wrote:
On 03/18/2013 03:23 PM, Chris Angelico wrote:
The languages that permit you to assign to a function call all have
some notion of a reference type.
Assigning to function calls is orthogonal to reference types. For example,
Python manages assignment to
On 21/03/13 11:15, Terry Reedy wrote:
getting back to CP versus IDLE...
From IDLE:
print('\x80')
print('\xc8')
È
Impressed? You should be. Open Start menu / Python33 / Python (command line)
and both of those result (modulo the specific character) in
UnicodeEncodeError: 'charmap'
On 03/04/13 23:47, Hrvoje Niksic wrote:
On 04/03/2013 01:17 PM, Nick Coghlan wrote:
I like Nick's answer to that: int *should* always return something of
exact type int. Otherwise you're always left wondering whether you
have to do int(int(x)), or perhaps even int(int(int(x))), to
On 04/04/13 01:16, Barry Warsaw wrote:
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's intimately tied
to int(),
On 04/04/13 03:36, Guido van Rossum wrote:
Consider a subclass of int() that overrides __repr__() and __str__() to
print something fancy (maybe it defaults to hex; maybe it's an enum :-). I
want to be able to say repr(int(x)) and get the standard decimal
representation. Same with strings. If
On 04/04/13 09:07, Cameron Simpson wrote:
On 03Apr2013 14:47, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
| On 04/03/2013 01:17 PM, Nick Coghlan wrote:
| Why would one want to be absolutely sure of getting an int?
So that arithmetic can be relied upon? If a subclass can override
the add methods
On 05/04/13 01:23, Oscar Benjamin wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached to the resulting object.
When I call int(), I'm expecting an int. That includes
On 07/04/13 17:44, mar...@v.loewis.de wrote:
Martin, you guys are shooting yourself in a foot. Almost noone uses
python 3 in production, even at pycon, which is the more progressive
crowd. There is a giant group of people using python that are not as
vocal. While I bet some are using Python 3,
On 07/04/13 17:52, Maciej Fijalkowski wrote:
If they never migrate on the premises of python 3 being a better
language what does it say about python 3?
Very little. People stick with languages for all sorts of reasons,
including:
- It's what I know
- I don't like change
- That's what the
On 08/04/13 07:41, Barry Warsaw wrote:
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 ;).
Awesome! :-)
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
On 13/04/13 08:58, Christian Tismer wrote:
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
[...]
Where would I add such a complaint, usually?
Or should I simply fix it?
It's a wiki. You can fix it yourself, next
On 13/04/13 05:33, Barry Warsaw wrote:
On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
I, too, would strongly prefer to see ordering within an enum. I use
home-made enums heavily in my code and find ordering comparisons useful
there.
This was all hashed out in gory detail on
On 13/04/13 10:13, Glenn Linderman wrote:
can't define two names in the same enum to have the same value, per the PEP.
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
On 13/04/13 20:30, Ben Finney wrote:
Stephen J. Turnbull step...@xemacs.org writes:
Mark Lawrence writes:
People already use the bug tracker as an excuse not to contribute,
wouldn't this requirement make the situation worse?
A failure to sign the CLA is already a decision not to
On 21/04/13 05:42, Barry Warsaw wrote:
On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
wasp = 1 # Preferred
On 21/04/13 15:33, Nick Coghlan wrote:
The PEP is fine, as it already allows duplicate names without encouraging them:
class Insect(Enum):
wasp = 1 # Preferred. Use this in new code.
bee = 2
ant = 3
# Backwards compatibility aliases
Insect.wsap =
On 23/04/13 09:16, Greg Ewing wrote:
Victor Stinner wrote:
The last proposition is to add transform() and untransform() methods
to bytes and str types. ... If I remember
correctly, the missing point is how to define which types are
supported by a codec
Also, for any given codec, which
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more,
or less, strange than str('spam') or int(1) or list([]). Why
would you do that?
But as soon as you think of it in general terms:
On 26/04/13 18:00, Greg Ewing wrote:
However, there's a worse problem with defining enum
inheritance that way. The subtype relation for extensible
enums works the opposite way to that of classes.
To see this, imagine a function expecting something
of type Colors. It knows what to do with red,
On 27/04/13 12:51, Ethan Furman wrote:
On 04/26/2013 07:29 PM, Glenn Linderman wrote:
[...]
class Color( Enum ):
Enum.__enumerationItems__(
red=1,
green=2,
blue=3,
)
# other methods and assignments
Or, if we go with the metaclass
On 29/04/13 06:02, Guido van Rossum wrote:
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
Definite Issues:
- should enum items be of the type of the Enum class? (i.e. type(SPRING)
is Seasons)
IMO Yes.
+1
- should an enum item be
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why
On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:
Two examples:
- the first few integers (up to 256 now, I think) are pre-created by the
interpreter; when you do `int('7')` you are not getting a brand-new, never
before used, integer 7 object, you're getting a cached
On Sun, Apr 28, 2013 at 11:50:16PM -0700, Ethan Furman wrote:
In other words, currently:
class Color(Enum):
red = 1
green = 2
blue = 3
class MoreColor(Color):
cyan = 4
magenta = 5
yellow = 6
black = 7
MoreColor.red is Color.red #
On 30/04/13 02:42, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky eli...@gmail.com wrote:
I don't feel strongly about allowing ()-lookup in addition to []-lookup, but
in this paragraph the issue of multiple definitions has sneaked in :-)
flufl.enum disallows this:
class
On 30/04/13 03:01, Guido van Rossum wrote:
Oh dear, this is actually a mess. I don't want MoreColor.red and
Color.red to be distinct objects, but then the isinstance() checks
will become confusing. If we don't override isinstance(), we'll get
not isinstance(Color.red, MoreColor)
On 30/04/13 04:29, Guido van Rossum wrote:
You are too verbose. I have already said what I needed to say.
Sorry about that, sometimes I do go on and on. Let me be more terse.
When it comes to enums, I believe that violating Liskov is a feature, not a bug.
Also, I understand that both Scala
On 30/04/13 05:02, MRAB wrote:
Why is that backwards? MoreColor is a subclass of Color, so instances
of MoreColor are instances of Color, but instances of Color are not
instances of MoreColor. That's normal behaviour for subclasses. (All
cats are mammals, but not all mammals are cats.)
Let's
On Mon, Apr 29, 2013 at 03:50:22PM -0700, Ethan Furman wrote:
This just doesn't make sense to me:
-- class Stuff(Enum):
... blue = 1
... china = 'really big country'
... random = (8273.199, 517)
-- Stuff.blue.name == 'blue'
-- Stuff.blue.value == 1
-- Stuff.china.name ==
On Tue, Apr 30, 2013 at 10:15:58AM +0100, Paul Moore wrote:
Before I raise a bug for this, can someone confirm if I've simply missed
something? I don't see any way, either in the docs or in the helpstrings
from the codecs, of listing the codecs that have been registered.
FWIW, I picked this
On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote:
Latest code available at https://bitbucket.org/stoneleaf/aenum.
-- class Color(Enum):
... red = 1
... green = 2
... blue = 3
Ethan, you seem to be writing a completely new PEP in opposition to
Barry's PEP 435. But
On 02/05/13 01:09, Ethan Furman wrote:
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
Apparently I have to log in before I can even see the repo.
Not going to happen.
--
Steven
___
Python-Dev mailing list
On 02/05/13 08:54, Nick Coghlan wrote:
If enums had an as_dict method that returned an ordered dictionary, you
could do:
class MoreColors(Enum):
locals().update(Colors.as_dict())
Surely that is an implementation-specific piece of code? Writing to locals()
is not guaranteed to work, and
On 02/05/13 06:45, Antoine Pitrou wrote:
I was talking in the context where subclassing is allowed. I don't
think there's a use-case for subclassing of non-empty enums. On the
other hand, empty enums should probably allow subclassing (they are
abstract base enums, in a way).
If you google for
On 02/05/13 02:43, Guido van Rossum wrote:
Here's how I would implement extending an enum if subclassing were
not allowed:
class Color(Enum):
red = 1
white = 2
blue = 3
class ExtraColor(Enum):
orange = 4
yellow = 5
green = 6
flag_colors = set(Color) | set(ExtraColor)
Now I
On 03/05/13 11:29, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and I'd like to make the current
CPython behaviour part of the language/library
On 03/05/13 18:42, Antoine Pitrou wrote:
Le Fri, 3 May 2013 09:14:22 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
I would suggest moving the field names into the class header for a
class based convenience API:
class Animal(Enum, members='cat dog'): pass
This looks good to me (assuming
On 03/05/13 20:37, Paul Moore wrote:
On 2 April 2013 01:47, Daniel Holth dho...@gmail.com wrote:
This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP Applications”
and “Windowed Python ZIP Applications”, and providing some
On 04/05/13 15:13, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
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?
+0
Many
On 05/05/13 20:05, Antoine Pitrou wrote:
I still would like to see Nick's class-based API preferred over the
functional API:
class Season(Enum, members='spring summer autumn'):
pass
-1
As already mentioned, this is no substitute for the functional API as it is a
statement, not
On 06/05/13 03:07, Charles-François Natali wrote:
I'm chiming in late, but am I the only one who's really bothered by the syntax?
class Color(Enum):
red = 1
green = 2
blue = 3
I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases,
On 07/05/13 23:34, Eli Bendersky wrote:
One of the contended issues with PEP 435 on which Guido pronounced was the
functional API, that allows created enumerations dynamically in a manner
similar to namedtuple:
Color = Enum('Color', 'red blue green')
The biggest complaint reported against
On 08/05/13 21:31, Alok Nayak wrote:
I asked this question here,
http://stackoverflow.com/questions/16435233/this-python-string-literals-documentation-couldnt-explain-me-single-quote-pres,
. I was advised to ask here
They were wrong. It is not relevant here, since it is not a question about
On 14/05/13 16:51, Gregory P. Smith wrote:
[...]
This sounds like a feature request for doctest. doctest could be educated
about enums and automatically compare to the integer value for such cases.
Please no. Enums are not special enough to break the rules.
Good: Doctests look at the
On 20/05/13 09:27, Gregory P. Smith wrote:
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:
Bad: doctests.
I'm hoping that core developers don't get caught-up in the doctests are
bad
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation. That said, it should be
recognized that some testing is
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also contains
this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s), 8):
quanta = s[i: i + 8]
acc = 0
try:
On 20/05/13 23:38, Antoine Pitrou wrote:
On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano st...@pearwood.info wrote:
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
We should continue to encourage users
On 24/05/13 00:24, Ethan Furman wrote:
Here's the code that existed at one point:
for c in s:
val = _b32rev.get(c)
if val is None:
raise TypeError('Non-base32 digit found')
Even though there is no KeyError to convert in this incarnation, providing the
501 - 600 of 1505 matches
Mail list logo
