On 05/14/2013 02:35 PM, Guido van Rossum wrote:
For example you could file low-priority bugs for both issues in the
hope that someone else figures it out.
Got it figured out.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
On 05/16/2013 09:38 AM, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 16, 2013, at 06:22 PM, Christian Heimes wrote:
Are you able to reproduce the issue? Perhaps you could use inotify to
track down file activity. It shouldn't affect timing much and you can
track if
On 05/19/2013 05:24 PM, Nick Coghlan wrote:
This is the point I was trying to make: once you use IntEnum (as you
would in any case where you need bitwise operators), Enum gets out of
the way for everything other than __str__, __repr__, and one other
slot (that escapes me for the moment...).
__
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single exception
traceback, instead of the new:
During handling of the above exception, another exception
On 05/20/2013 06:47 AM, Nick Coghlan wrote:
On 20 May 2013 23:38, Ethan Furman wrote:
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single exception
On 05/20/2013 07:50 AM, R. David Murray wrote:
On Mon, 20 May 2013 07:12:07 -0700, 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
On 05/20/2013 11:14 AM, Mark Janssen wrote:
I have pondered it many times, although usually in the form "Why do we
need both str and repr?"
Here's an idea: considering python objects are "stateful". Make a
general, state-query operator: "?". Then the distinction is clear.
--> ?"This is a s
On 05/20/2013 11:32 AM, Terry Jan Reedy wrote:
On 5/20/2013 11:39 AM, Steven D'Aprano wrote:
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
On 05/21/2013 04:23 AM, Nick Coghlan wrote:
On Tue, May 21, 2013 at 5:17 PM, Hrvoje Niksic wrote:
On 05/20/2013 05:15 PM, Ethan Furman wrote:
1) Do nothing and be happy I use 'raise ... from None' in my own
libraries
2) Change the wording of 'During handling of the
On 05/23/2013 04:36 AM, "Martin v. Löwis" wrote:
Am 21.05.13 18:03, schrieb Ethan Furman:
And, of course, we only make these changes when we're already modifying
the module for some other reason.
In the specific case, the KeyError has indeed useful information that
the Typ
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
On 23 maj 2013, at 16:49, Guido van Rossum wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
"The dispatch type is currently specified as a decorator argument. The
implementation could a
User API
To define a generic function, decorate it with the ``@singledispatch``
decorator. Note that the dispatch happens on the type of the first
argument, create your function accordingly:
.. code-block:: pycon
>>> from functools import singledispatch
>>> @singledispatch
...
On 05/23/2013 11:13 AM, Éric Araujo wrote:
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
>>> @fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print("St
On 05/23/2013 01:10 PM, Łukasz Langa wrote:
On 23 maj 2013, at 20:59, PJ Eby wrote:
As to the ability to do multiple types registration, you could support
it only in type annotations, e.g.:
@func.register
def doit(foo: [int, float]):
...
Initially I thought so, too. But it s
On 05/23/2013 02:02 PM, Ronan Lamy wrote:
2013/5/23 Łukasz Langa mailto:luk...@langa.pl>>
On 23 maj 2013, at 20:13, Éric Araujo mailto:mer...@netwok.org>> wrote:
> Question: what happens if two functions (say in two different modules)
> are registered for the same type?
Last on
On 06/02/2013 10:20 PM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate list
and include it in core, and switch over
the API's so that they verify HTTPS by default.
+1
Also, +1 on using system certs when available.
--
~Ethan~
__
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a "slightly outdated" CA store is that it can be a
security risk.
Tracking the Mozilla store isn't difficult. New additions can be ignored for
currently released Pythons so we'd ju
On 06/03/2013 10:55 AM, Donald Stufft wrote:
On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a "slightly outdated" CA store is that it can be a
security risk.
Tr
On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
I worry with the current situation people will just use TLS connections without realizing
it's not being verified and thinking they are "safe".
Yet there's quite a visible warning in the docs
Congratulations, Łukasz!
--
~Ethan~
___
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
I just used the build system on the 3.4.0 docs, and some of the library modules (haven't checked the others) have the
TOC showing up at the bottom of the page instead of the top.
Am I doing something wrong?
--
~Ethan~
___
Python-Dev mailing list
Pytho
Is there a doctest mailing list? I couldn't find it.
I'm try to use doctest to verify my docs (imagine that!) but I'm having trouble with the one that uses pickle (imagine
that!).
Any advice on how to make it work?
Here's the excerpt:
===
On 06/07/2013 09:54 AM, Olemis Lang wrote:
On 6/7/13, Ethan Furman wrote:
Is there a doctest mailing list? I couldn't find it.
JFTR, Testing-in-Python (TiP) ML should be the right target for
general purpose questions about testing, considering docs even for
unittest and doctest
On 06/07/2013 10:50 AM, Mark Janssen wrote:
>>> from pickle import dumps, loads
>>> Fruit.tomato is loads(dumps(Fruit.tomato))
True
Why are you using is here instead of ==?
I'm using `is` because I'm verifying that the instance returned by `pickle.loads` is the exact same objec
On 06/07/2013 10:54 AM, Mark Janssen wrote:
On Fri, Jun 7, 2013 at 10:50 AM, Mark Janssen wrote:
>>> from pickle import dumps, loads
>>> Fruit.tomato is loads(dumps(Fruit.tomato))
True
Why are you using is here instead of ==? You're making a circular
loop using "is"
I should
On 06/07/2013 11:45 PM, Steven D'Aprano wrote:
On 08/06/13 15:18, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Enumerations can be pickled and unpickled::
>
> >>> from enum import Enum
> >>> class Fruit(Enum):
> ...
On 06/08/2013 01:07 AM, Serhiy Storchaka wrote:
08.06.13 10:03, Ethan Furman написав(ла):
Indeed, and it is already in several different ways. But it would be
nice to have a pickle example in the docs that worked with doctest.
I ended up doing what Barry did:
>>> from test.
On 06/08/2013 03:09 AM, Serhiy Storchaka wrote:
08.06.13 11:47, Ethan Furman написав(ла):
In this case it is better to exclude a code example from doctests or
add auxiliary code (i.e. as Steven suggested) to pass the doctest.
Are you saying there is something wrong about what I have in place
On 06/08/2013 09:21 PM, Nick Coghlan wrote:
Using the test suite in the enum docstrings initially is fine. In the
future, once we migrate a module like socket to using enum.IntEnum
instead of bare integers, it would be appropriate to change the enum
docs to reference that rather than the test su
I just wanted to take a minute and say THANK YOU to everyone involved in
getting Python 3 to where it is today.
It is so much easier to use, especially metaclasses (nearly pulled my hair out
trying to get Enum working on Py2!).
Also a big thank you to the doctest folks as it was invaluable in
So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in
the 2.x series.
I would like to put this on PyPI, but the `enum` name is already taken.
Would it be inappropriate to call it `stdlib.enum`?
--
~Ethan~
___
Python-Dev mail
On 06/15/2013 01:53 PM, Antoine Pitrou wrote:
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman wrote:
So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in
the 2.x series.
I would like to put this on PyPI, but the `enum` name is already taken.
Would it be
On 06/15/2013 06:50 PM, Donald Stufft wrote:
I claimed backport.enum, but you're welcome to the name. I was going to try and
backport this PEP under that name anyways.
Thank you for the offer, but I think I'll go with GPS's idea of calling it
enum34.
--
~Ethan~
_
On 06/15/2013 10:52 PM, Ben Finney wrote:
Donald Stufft writes:
On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:
Is there anything I can do to keep the ‘enum’ package online for
continuity but make it clear, to automated tools, that this is
end-of-life and obsoleted by another package?
Right
On 06/17/2013 09:05 PM, Eli Bendersky wrote:
On Fri, Jun 14, 2013 at 6:47 AM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
14.06.13 11:46, Antoine Pitrou написав(ла):
On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
raymond.hettinger mailto:python-check...@python.org>> w
On 06/20/2013 01:18 PM, Amaury Forgeot d'Arc wrote:
2013/6/20 Serhiy Storchaka wrote:
Now with enumerations in the stdlib the stat module constants are candidates
for flag enumerations. How easy will be
implement it on C?
Aha. Should an internal C module fetch the value of the constants, and
On 06/20/2013 01:27 PM, Guido van Rossum wrote:
On Thu, Jun 20, 2013 at 1:18 PM, Amaury Forgeot d'Arc wrote:
2013/6/20 Serhiy Storchaka wrote:
Now with enumerations in the stdlib the stat module constants are
candidates for flag enumerations. How easy will be implement it on C?
Aha. Should a
On 06/26/2013 07:08 PM, Skip Montanaro wrote:
I'd like to urge stdlib contributors and core devs to
heed it -- or explain why you can't.
Where I can, I do, however I often find it difficult to come up with a
one-liner, especially one that mentions the parameters to functions.
If the one-line ru
On 06/27/2013 08:18 AM, Eric Snow wrote:
On Thu, Jun 27, 2013 at 2:48 AM, Nick Coghlan wrote:
I think the main concern I would have is whether other implementations
are happy they can provide a suitable ordered dictionary for class
namespace execution.
It's also worth considering what would ha
On 06/28/2013 01:07 PM, Jim J. Jewett wrote:
(On June 19, 2013) Barry Warsaw wrote about porting mailman from
flufl.enum to the stdlib.enum:
Switching from call syntax to getitem syntax for looking up an
enum member by name, e.g.
-delivery_mode = DeliveryMode(data['delivery_mode'
On 07/11/2013 04:58 PM, Christian Heimes wrote:
how do you feel about dropping Windows XP support for Python 3.4? It
would enable us to use some features that are only available on Windows
Vista and newer, for example http://bugs.python.org/issue6926 and
http://bugs.python.org/issue1763 .
PEP 1
While working on issue #18508 I stumbled across this:
Traceback (most recent call last):
...
File "/usr/local/lib/python3.4/enum.py", line 417, in __new__
if value in cls._value2member_map:
TypeError: unhashable type: 'list'
I'll wrap it in a try-except block, but I must admit I was surpri
http://bugs.python.org/issue18510
Commenting further:
some_key in dict
is conceptually the same as
some_key in dict.keys()
which /would/ return False for an unhashable key -- at least it did in 2.x; for
3.x you have to say
some_key in list(dict.keys())
which seems like a step b
On 07/20/2013 03:21 AM, Ronald Oussoren wrote:
On 20 Jul, 2013, at 1:47, Ethan Furman wrote:
While working on issue #18508 I stumbled across this:
Traceback (most recent call last):
...
File "/usr/local/lib/python3.4/enum.py", line 417, in __new__
if value in cls._value2
Thanks for the insights, everyone.
--
~Ethan~
___
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
Excerpt from http://meta.stackoverflow.com/q/190442/176681:
Janrain no longer actively supports MyOpenID, and announced on Twitter that
their users should proceed with caution.
This decision was made by Janrain, [snip]
I know the Python bug tracker allows MyOpenID logins; if that is your only
A question came up on stackoverflow asking about the Planet example and the need to have the constant G defined in the
method instead of at the class level:
http://stackoverflow.com/q/17911188/208880
Since methods and descriptors are immune to enumeration my proposed solution created a Constant
On 08/07/2013 01:54 AM, Alexander Belopolsky wrote:
That's not how the history looks on the tracker. Robin submitted ~50 patches before
I suggested that "we should start
with the "xx" modules." Then he did submit patches to the example modules, but
have never responded to my reviews.
Dumb
On 08/13/2013 04:51 PM, Steven D'Aprano wrote:
I have raise a tracker item and PEP for adding a statistics module to the
standard library:
http://bugs.python.org/issue18606
http://www.python.org/dev/peps/pep-0450/
The bug-tracker doesn't think you've submitted a CLA yet. If you haven't
yo
On 08/13/2013 04:51 PM, Steven D'Aprano wrote:
My question is, is it acceptable to post the code and tests to
the tracker as-is, and ask for a pronouncement on the PEP first,
and then fix the test breakage later?
Certainly.
--
~Ethan~
___
Python-De
From http://bugs.python.org/issue18738:
Ethan Furman commented:
--> class Test(enum.IntEnum):
... one = 1
... two = 2
...
--> '{}'.format(Test.one)
'Test.one'
--> '{:d}'.format(Test.one)
'1'
--> '{:}'.format(Test.one)
'T
On 08/15/2013 05:40 AM, Brett Cannon wrote:
What we should probably do is have unittest turn deprecations on by default
when running your tests but leave them
silent otherwise. I still think keeping them silent for the benefit of
end-users is a good thing as long as we make it
easier for devel
Given that the !r and !s format codes can be used to get the repr and str of an IntEnum, would it be acceptable to have
IntEnum's __format__ simply pass through to int's __format__? And likewise with all mix-in classes?
--
~Ethan~
___
Python-Dev maili
On 08/15/2013 10:44 AM, Eric V. Smith wrote:
On 08/15/2013 11:21 AM, Ethan Furman wrote:
Given that the !r and !s format codes can be used to get the repr and
str of an IntEnum, would it be acceptable to have IntEnum's __format__
simply pass through to int's __format__? And likewis
On 08/14/2013 09:27 PM, Nick Coghlan wrote:
For enums, I believe they should be formatted like their
base types (so !s and !r will show the enum name, anything without
coercion will show the value) .
I agree. While one of the big reasons for an Enum type was the pretty
str and repr, I don't s
On 08/20/2013 11:15 PM, Ethan Furman wrote:
On 08/14/2013 09:27 PM, Nick Coghlan wrote:
For enums, I believe they should be formatted like their
base types (so !s and !r will show the enum name, anything without
coercion will show the value) .
I agree. While one of the big reasons for an
On 08/30/2013 06:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
Sometimes it is. And sometimes it's user-input related, or waiting on a local-pipeline related. But in all cases it
means, return whatever is ready, don't block if nothing is ready.
--
~Ethan~
Am I the only one experiencing this?
262 tests OK.
93 tests failed:
test___all__ test_abc test_array test_ast test_asynchat
test_asyncore test_bisect test_buffer test_bufio test_bytes
test_codeccallbacks test_codecs test_colorsys test_compileall
test_configparser test_contextlib t
Part of the fix for issue #18693 is to fix inspect to look in the metaclass for class attributes
(http://bugs.python.org/issue18929).
In inspect.py in function get_mro() we can either add the metaclass
unconditionally, or only if it is not 'type'.
If we add unconditionally, then help() adds t
On 09/01/2013 06:02 PM, Eli Bendersky wrote:
os seems to import io in some functions; can this be done always? If yes, we
can just define the constants once and
os.SEEK_* will alias io.SEEK_*? The other way (io taking from os) is also a
possibility (maybe the preferred one because
io already r
I recently committed a fix for unicodeobject.c so that the %d, %i, and %u format specifiers always output values
(otherwise, in subclasses, the str() was used instead).
Should this be fixed in 3.3 as well?
What guidelines determine when a bug is fixed in previous versions?
--
~Ethan~
_
On 09/06/2013 07:47 AM, Armin Rigo wrote:
Are you suggesting that inspect.getmro(A) would return (A, object,
type)? That seems very wrong to me.
Currently, `inspect.getmro(A)` returns `(A, object)`.
Considering that Python actually will look in A's metaclass to find a class attribute, I thin
On 09/06/2013 08:44 AM, R. David Murray wrote:
On Fri, 06 Sep 2013 08:14:09 -0700, Ethan Furman wrote:
On 09/06/2013 07:47 AM, Armin Rigo wrote:
Are you suggesting that inspect.getmro(A) would return (A, object,
type)? That seems very wrong to me.
Currently, `inspect.getmro(A)` returns
On 09/06/2013 09:37 AM, R. David Murray wrote:
On Fri, 06 Sep 2013 08:59:02 -0700, Ethan Furman wrote:
For the short term I can restrict the change to inspect.classify_class_attrs().
Sounds like the best course.
There is one other function in inspect that calls getmro():
def getmembers
On 09/06/2013 07:51 AM, Ethan Furman wrote:
What guidelines determine when a bug is fixed in previous versions?
On 09/06/2013 08:29 AM, Brian Curtin wrote:
If it's a bug in that version and the version is accepting bug fixes,
i.e., not in security mode, go for it. This includes crossin
I've run across two different ways to think about this:
1) the type of the first argument
2) where the method/attribute lives
Since attributes don't take a first argument they default to 2: an instance attribute lives in the instance, a class
attribute lives in the class, and a metaclass
On 09/08/2013 06:52 AM, Ryan wrote:
...what's a PEP dictator?
The person tasked with deciding on the fate of an individual PEP.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
And something I forgot to ask: is anyone willing to be the BDFL-Delegate for
PEP 447?
*Bump*.
It would be nice if this could make into 3.4.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On 09/09/2013 08:43 AM, Mark Shannon wrote:
I would like time to investigate this further, but at the moment I think it
will either make attribute lookup poorly
defined or slow.
Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed poi
On 09/10/2013 06:09 AM, Hrvoje Niksic wrote:
On 09/10/2013 02:24 PM, Paul Moore wrote:
td['FOO'] = 42
td['foo'] = 32
list(td.keys())
['FOO'] or ['foo']? Both answers are justifiable.
Note that the same question can be reasonably asked for dict itself:
d = {}
d[1.0] = 'foo'
d[1] = 'bar'
d
On 09/10/2013 07:54 AM, Antoine Pitrou wrote:
Le Tue, 10 Sep 2013 15:09:56 +0200,
Hrvoje Niksic a écrit :
On 09/10/2013 02:24 PM, Paul Moore wrote:
td['FOO'] = 42
td['foo'] = 32
list(td.keys())
['FOO'] or ['foo']? Both answers are justifiable.
Note that the same question can be reasonably
On 09/10/2013 01:36 PM, Lukas Lueg wrote:
Should'nt the key'ing behaviour be controlled by the type of the key instead of
the type of the container?
That would be up to the key function.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On 09/10/2013 03:12 PM, MRAB wrote:
On 10/09/2013 22:46, Antoine Pitrou wrote:
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
> "Joao S. O. Bueno" wrote:
>> On 10 September 2013 16:08, Paul M
On 09/10/2013 05:26 PM, Eric V. Smith wrote:
On 9/10/2013 6:18 PM, Ethan Furman wrote:
On 09/10/2013 03:12 PM, MRAB wrote:
On 10/09/2013 22:46, Antoine Pitrou wrote:
On Tue, 10 Sep 2013 18:44:20 -0300
"Joao S. O. Bueno" wrote:
On 10 September 2013 18:06, Antoine Pitrou wrote:
http://docs.python.org/3/library/functions.html#dir:
Note: Because dir() is supplied primarily as a convenience for
use at an interactive prompt [...]
I suspect this comment is out of date, as there are two functions in the inspect module that rely on dir(), which also
means that help indir
On 09/11/2013 05:47 AM, Nick Coghlan wrote:
On 11 September 2013 21:57, R. David Murray wrote:
Except it is wider than that: the transform function can be anything,
not just case folding.
I suggested surjectiondict or ontodict, but Antoine didn't like those :)
(I had to look up the terms...it'
On 09/11/2013 02:38 AM, Serhiy Storchaka wrote:
There is a question about specifying the transform function.
There are three ways to do this:
1. Positional argument of the constructor.
d = TransformDict(str.casefold, Foo=5)
This method follows the precedent of defaultdict:
--> from collecti
On 09/11/2013 06:58 AM, Victor Stinner wrote:
2013/9/11 Steven D'Aprano :
But the proposal is not for a case-insensitive dict. It is more general
than that, with case-insensitivity just one specific use-case for such
a transformative dict. Arguably the most natural, or at least obvious,
such tra
On 09/11/2013 06:58 AM, Victor Stinner wrote:
The os.environ mapping uses a subclass of MutableMapping which
accepts 4 functions: encoder/decoder for the key and encoder/decoder
for the value. Such type is even more generic. transformdict cannot
replace os._Environ.
True, it's more generic --
On 09/11/2013 08:49 AM, Victor Stinner wrote:
2013/9/11 Ethan Furman :
He isn't keeping the key unchanged (notice no white space in MAPPING), he's
merely providing a function that will automatically strip the whitespace
from key lookups.
transformdict keeps the key unchanged, see
On 09/11/2013 08:48 AM, Antoine Pitrou wrote:
Le Wed, 11 Sep 2013 07:48:56 -0700,
Ethan Furman a écrit :
Personally, I wouldn't mind having all four; for one thing, the name
'transformdict' would then be entirely appropriate. ;)
The key decoder function is quite useless sin
On 09/11/2013 10:49 AM, Antoine Pitrou wrote:
What I dislike is the idea of doing additional work because some
barriers are imposed ;-). PEP or PyPI are on a similar scale here. At
least a PEP would help record the various discussion details, so I'd
favour that over the PyPI path.
I would thin
On 09/11/2013 02:39 PM, Tim Delaney wrote:
On 12 September 2013 02:03, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
On 09/11/2013 08:49 AM, Victor Stinner wrote:
2013/9/11 Ethan Furman mailto:et...@stoneleaf.us>>:
He isn't keeping the key unchanged
On 09/11/2013 02:39 PM, Tim Delaney wrote:
I would think that retrieving the keys from the dict would return the
transformed keys (I'd
call them canonical keys).
The more I think about this the more I agree. A canonicaldict with a key function that simply stored the transformed
key and it's
On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
Yeah, so this is totally silly. What you're basically saying is "we
don't need TransformDict since people can re-implement it themselves".
No, what I'm saying is that the "case-preserving" aspect of transformdict is silly. The main point of transf
On 09/12/2013 08:40 AM, Antoine Pitrou wrote:
Le Thu, 12 Sep 2013 08:05:44 -0700,
Ethan Furman a écrit :
On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
Yeah, so this is totally silly. What you're basically saying is "we
don't need TransformDict since people can re-implemen
+1 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 09/13/2013 02:45 PM, Antoine Pitrou wrote:
Serhiy Storchaka wrote:
I think that's important. As OrderectDict has additional methods besides
the MutableMapping API, so TransformDict should provide useful
specialized methods.
Ok, I have a better (IMO) proposal:
>>> d = TransformDict(st
On 09/13/2013 05:49 PM, Steven D'Aprano wrote:
+1 on __transform__ method on dicts.
What would __transform__ do? Just canonicalize the key, or also save the original key? How much front-end work will
each user have to do to actually use this new magic method to good effect?
Personally, if
On 09/13/2013 06:25 PM, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonical key? My gut feeling is that I'm
likely to have code like this:
d = TransformDict(...)
for key in data:
On 09/13/2013 08:33 PM, Steven D'Aprano wrote:
Likewise, the point of transformdict is to avoid needing to care
about the transformation function 99% of the time.
No one's arguing against that point. It's the 1% of the time that being able to get the canonical name back is a Good
Thing, and
On 09/13/2013 08:18 PM, Steven D'Aprano wrote:
You're missing that I'm not iterating over the entire dict, just some
subset ("data") that I got from elsewhere.
Ah, okay. Between you and Antoine I am convinced that .getitem() is a good thing. So have that and .transform_key and
we're golden!
On 09/13/2013 09:53 PM, Joao S. O. Bueno wrote:
On 13 September 2013 22:40, Ethan Furman wrote:
On 09/13/2013 06:25 PM, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
Is it more common to want both the canonical key and value at the same
time, or to just want the canonica
On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman wrote:
I mean - given no function to retrieve the canonical key,
one would have to resort to:
my_key = data.__transform__(given_key)
for key, value in data.items():
if data.__transform__(key
On 09/14/2013 10:41 AM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 09:43:13 -0700 Ethan Furman wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
I had originally thought transform_key
On 09/14/2013 05:32 PM, Serhiy Storchaka wrote:
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not tran
I see PEP 428 is both targeted at 3.4 and still in draft status.
What remains to be done to ask for pronouncement?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
Three questions:
Would the new __initclass__ function be usable with actual full-blown
metaclasses?
The PEP says this:
If present on the created object, this new hook will be called by the class
creation machinery after the __class__ reference has been initialised.
Given that statement,
On 09/17/2013 02:21 PM, Guido van Rossum wrote:
Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on
the issue on the code.
Congratulations, Stephen!
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On 09/18/2013 01:26 AM, Antoine Pitrou wrote:
Le Tue, 17 Sep 2013 14:40:21 -0700,
Ethan Furman a écrit :
On 09/17/2013 02:21 PM, Guido van Rossum wrote:
Congrats, I've accepted the PEP. Nice work! Please work with the
reviewers on the issue on the code.
Congratulations, Stephen!
Or S
1001 - 1100 of 1590 matches
Mail list logo
