[Python-Dev] "Provisional" considered harmful? [was: PEP 455: TransformDict]
As will become evident, I disagree with Steven at almost every point. However, I think his point about users not reading documentation is well-taken. Due to hyperlinking, users are very likely to skip past module docstrings. I suggest two (perhaps informal) additions to the documentation policy in PEP 411: (1) Provisional packages should be explicitly described as such in release announcements. I think this is done already, cf. "Improvements in email" in the Release announcement and What's New for Python 3.3.0.[1] However the policy should be explicit and the word "provisional" should be emphasized and linked to PEP 411. (2) Individual APIs in those packages should be documented as provisional. Steven D'Aprano writes: > - Since people cannot rely on provisional features still being available > in the future, if they care the slightest about forward compatibility, > they dare not use them. You exaggerate to the extent that you harm your argument. People make tradeoffs. Some will choose the extreme you describe here, others will take more risk. Your real argument is that the benefits are small because you expect that provisional stdlib packages will not get much if any additional use over PyPI packages. Can't know without trying ... thus, the PEP. Similar considerations apply to your other arguments. > None of these arguments are documented in the PEP, let alone refuted. They're not real arguments, as stated. If you rephrase them as actual arguments, they turn out to merely be the "half-empty" phrasing of the "half-full" arguments used in favor. Can't know without trying. > I don't think that "provisional" helps end users at all. If anything, it > hurts them -- it means more uncertainty and doubt. True, it *increases* the uncertainty *inside* the stdlib. On the flip side, it decreases uncertainty *overall* by announcing that the core developers *want* this feature in stdlib *now*, and probably the API won't change *at all*, and very probably the API won't change "much". > But for provisional packages, that promise doesn't apply, and > although PEP 411 says that packages won't be gratuitously removed, > I have to assume that any provisional package in version 3.x could > be gone without notice or warning in 3.x+1. It's unlikely it will be "gone", it will end up on PyPI. > I don't see how that helps me. Since you evidently demand absolute certainty, you're right, it doesn't help you with respect to any given provisional package. I'm more flexible, and I greatly value having the core developers evaluate the modules on PyPI (or the modules that have only seen the flourescent lights of Google Labs up to now) for me, and putting their Good Codesmithing Stamp of Approval on some of them more quickly. And if in fact the policy works in the sense that more code gets into the stdlib (non-provisionally) faster than without the PEP, in the long run *you* benefit even with if you adopt a policy of using only non-provisional APIs. > The PEP has a lengthy section that claims to be about how it will > help end users. It actually isn't -- it is about how inclusion in > the standard library helps end users. Right. And this PEP is about how to get good code into the stdlib faster. It's a means to that intermediate end, and transitively a means to the real end of helping end users. > Not surprisingly, there's nothing about why reserving the right to > rip out a package without warning is good for end uers, since it > isn't. What it really comes down to is you're saying you fear you will frequently disagree with the judgment of python-dev with regard to the options provided by "provisional". You want them bound by hard and fast rules. That's fine; everybody has their own requirements. Nevertheless, it's logically possible that as long as you pay attention to "provisional" markings this PEP will be a win for you. I agree with the PEP proponents that "logically possible" can be strengthened to "probably true", but of course YMMV. Footnotes: [1] http://www.python.org/download/releases/3.3.0/ http://docs.python.org/3.3/whatsnew/3.3.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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) == my_key:
> >
>
> Which is exactly why I, and others, would like to have the transform function
> easily available. Besides being able to
> use it to get a canonical key, one could use it to get the function itself.
> Yay, introspection!
Well, no, you misunderstand :) The transform function takes an
original key (perhaps "canonical") and returns the transformed key, it
can't do the reverse which is what getitem() does. i.e.:
>>> d = TransformDict(str.lower)
>>> d['Foo'] = 5
>>> d._transform_func('Foo')
'foo'
>>> d.getitem('foo')
[('Foo', 5)]
What getitem() does is make the surjection bijective by restricting its
input domain to the set of stored keys.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings wrote:
> On 09/14/2013 03:40 AM, Antoine Pitrou wrote:
> > Hello,
> >
> > Following the python-dev discussion, I've written a PEP to recap the
> > proposal and the various arguments. It's inlined below, and it will
> > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
>
> Whenever I read a discussion about the dict, I always wonder whether the
> same thing applies to a set. Have you considered the utility of a
> TransformSet? Or is it YAGNI?
Well, a TransformSet is like a normal dict, you just need to call the
transformation function yourself when inserting the keys.
i.e.:
d = TransformSet(str.lower)
d.add('Foo')
is the same conceptually as:
d = {}
d['Foo'.lower()] = 'Foo'
d['foo'] # gets the original key
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 14 September 2013 12:44, Steven D'Aprano wrote: > On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote: > >> Personally, if there's a bunch of push-back against just adding >> TransformDict directly, why don't we make it provisional? I thought that >> was what provisional was for (meaning: we're going to add it, PyPI is not >> really appropriate, there may be some API changes). > > Not according to PEP 411. It implies that only modules/packages can be > provisional, not individual functions, and states that "most packages" > are expected to be provisional. So either PEP 411 doesn't apply to > TransformDict at all, or it applies by default. The PEP doesn't say. > > http://www.python.org/dev/peps/pep-0411/ > > > Everything below the line is about PEP 411, not TransformDict. If you > don't care about PEP 411, you can stop reading now. > > > == > > > Personally, I think it's a poor PEP. It doesn't document opposition to > the idea, and if I recall the discussion at the time correctly, there > was plenty of opposition. > > - Since people cannot rely on provisional features still being available > in the future, if they care the slightest about forward compatibility, > they dare not use them. Correct, that's exactly what they should do. > - If people do use them, and we care about backwards compatibility, we > dare not remove provisional packages without going through the same > deprecation process as for ordinary packages. > - It relies on people reading the documentation and noticing that a > package is marked "provisional". Like that's going to happen. > > None of these arguments are documented in the PEP, let alone refuted. > Even if the decision to approve the PEP ends up being vindicated, I > think it was poor form for the PEP to ignore arguments against. > > I don't think that "provisional" helps end users at all. If anything, it > hurts them -- it means more uncertainty and doubt. Packages may languish > in provisional status indefinitely. Speaking as an end user, I used to > know that once a feature hit the std lib, it was stable and wouldn't be > removed without going through a lengthy period of deprecation (except > under truly remarkable circumstances). But for provisional packages, > that promise doesn't apply, and although PEP 411 says that packages > won't be gratuitously removed, I have to assume that any provisional > package in version 3.x could be gone without notice or warning in 3.x+1. > I don't see how that helps me. It just means that for some indefinite > period, there's a package in the std lib doing exactly what I want that > I dare not use in production software because there are no stability > guarantees. Correct, it doesn't help you until it graduates from provisional status. Less risk averse users may choose to use it sooner (since any removed modules would almost certainly find a home on PyPI in fairly short order) > The PEP has a lengthy section that claims to be about how it will help > end users. It actually isn't -- it is about how inclusion in the > standard library helps end users. Not surprisingly, there's nothing > about why reserving the right to rip out a package without warning is > good for end uers, since it isn't. "We expect that most of the API of most provisional packages will be unchanged at graduation. Withdrawals are expected to be rare." Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 14 September 2013 12:44, Steven D'Aprano wrote: > On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote: > >> Personally, if there's a bunch of push-back against just adding >> TransformDict directly, why don't we make it provisional? I thought that >> was what provisional was for (meaning: we're going to add it, PyPI is not >> really appropriate, there may be some API changes). > > Not according to PEP 411. It implies that only modules/packages can be > provisional, not individual functions, and states that "most packages" > are expected to be provisional. So either PEP 411 doesn't apply to > TransformDict at all, or it applies by default. The PEP doesn't say. > > http://www.python.org/dev/peps/pep-0411/ > > > Everything below the line is about PEP 411, not TransformDict. If you > don't care about PEP 411, you can stop reading now. > > > == > > > Personally, I think it's a poor PEP. It doesn't document opposition to > the idea, and if I recall the discussion at the time correctly, there > was plenty of opposition. Oops, meant to reply to this part, too. PEP 411 is an Informational PEP, not a standards track PEP. It's there to describe the policy, not to make the case for *having* the policy. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 14/09/2013 05:47, Ethan Furman wrote:
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! :)
+1
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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) == my_key: Which is exactly why I, and others, would like to have the transform function easily available. Besides being able to use it to get a canonical key, one could use it to get the function itself. Yay, introspection! Well, no, you misunderstand :) The transform function takes an original key (perhaps "canonical") and returns the transformed key, it can't do the reverse which is what getitem() does. i.e.: Argh, of course you are right. Still, I think it would be useful to expose the transform function. Any good reason not to? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sat, 14 Sep 2013 09:43:13 -0700 Ethan Furman wrote: > 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) == my_key: > >>> > >> > >> Which is exactly why I, and others, would like to have the transform > >> function easily available. Besides being able to > >> use it to get a canonical key, one could use it to get the function > >> itself. Yay, introspection! > > > > Well, no, you misunderstand :) The transform function takes an > > original key (perhaps "canonical") and returns the transformed key, it > > can't do the reverse which is what getitem() does. i.e.: > > Argh, of course you are right. > > 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? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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, but transform_func is also good, and possibly less confusing. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
14.09.13 20:41, Antoine Pitrou написав(ла): 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? There is one reason -- serialization. For example pickle saves the transform function as an argument for TransformDict constructor. Repr exposes the transform function too (in evaluable representation). Other serializers need the transform function too. My implementations expose it as public property (transform), your -- as private attribute (_transform). Or perhaps I misunderstood you? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sat, 14 Sep 2013 22:07:50 +0300 Serhiy Storchaka wrote: > 14.09.13 20:41, Antoine Pitrou написав(ла): > > 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? > > There is one reason -- serialization. For example pickle saves the > transform function as an argument for TransformDict constructor. Repr > exposes the transform function too (in evaluable representation). Other > serializers need the transform function too. My implementations expose > it as public property (transform), your -- as private attribute > (_transform). > > Or perhaps I misunderstood you? "No good reason" not to expose it. It was a double negation, sorry ;-) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #18937: Add an assertLogs() context manager to unittest.TestCase to
On 9/14/2013 1:45 PM, antoine.pitrou wrote:
http://hg.python.org/cpython/rev/4f5815747f58
changeset: 85701:4f5815747f58
user:Antoine Pitrou
date:Sat Sep 14 19:45:47 2013 +0200
summary:
Issue #18937: Add an assertLogs() context manager to unittest.TestCase to
ensure that a block of code emits a message using the logging module.
files:
Doc/library/unittest.rst | 41 +++
Lib/unittest/case.py | 109 +++-
Lib/unittest/test/test_case.py | 96 ++
Misc/NEWS |2 +
4 files changed, 242 insertions(+), 6 deletions(-)
diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
--- a/Doc/library/unittest.rst
+++ b/Doc/library/unittest.rst
@@ -1031,6 +1031,47 @@
.. versionchanged:: 3.3
Added the *msg* keyword argument when used as a context manager.
assertWarnsRegex
+ .. method:: assertLogs(logger=None, level=None)
+
+ A context manager to test that at least one message is logged on
+ the *logger* or one of its children, with at least the given
+ *level*.
+
+ If given, *logger* should be a :class:`logging.Logger` object or a
+ :class:`str` giving the name of a logger. The default is the root
+ logger, which will catch all messages.
+
+ If given, *level* should be either a numeric logging level or
+ its string equivalent (for example either ``"ERROR"`` or
+ :attr:`logging.ERROR`). The default is :attr:`logging.INFO`.
+
+ The test passes if at least one message emitted inside the ``with``
+ block matches the *logger* and *level* conditions, otherwise it fails.
+
+ The object returned by the context manager is a recording helper
+ which keeps tracks of the matching log messages. It has two
+ attributes:
+
+ .. attribute:: records
+
+ A list of :class:`logging.LogRecord` objects of the matching
+ log messages.
+
+ .. attribute:: output
+
+ A list of :class:`str` objects with the formatted output of
+ matching messages.
+
+ Example::
+
+ with self.assertLogs('foo', level='INFO') as cm:
+logging.getLogger('foo').info('first message')
+logging.getLogger('foo.bar').error('second message')
+ self.assertEqual(cm.output, ['INFO:foo:first message',
+ 'ERROR:foo.bar:second message'])
+
+ .. versionadded:: 3.4
+
There are also other methods used to perform more specific checks, such as:
The new method should be added to the table of raises/warns methods that
starts this group. The table intro sentence
"It is also possible to check that exceptions and warnings are raised
using the following methods:"
should be modified to something like
"It is also possible to check the production of exception, warning, and
log messages using the following methods:"
Terry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote: > Following the python-dev discussion, I've written a PEP to recap the > proposal and the various arguments. It's inlined below, and it will > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. > Thanks, Antoine! Raymond Hettinger has volunteered to be the PEP dictator (is that the word we use?) for this PEP. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiler for the Mac OS X version of Python 3.4
I was exercising the alpha two release of 3.4 and noticed that it is still being built under GCC 4.2.1. Is there any reason we have to use an old compiler? I would like to see it built under the latest version of Clang (like the other tools on the Mac) or under GCC 4.8.1. I've better using the latter for many months. It works great and produces *much* better code (in terms of readability for those of us who look at assembly output and in terms of speed (approx 20-25% better for cpu bound code)). I'm wondering whether is some issue that forces us to use GCC 4.2.1 or whether that is just an artifact of continuing to do what we've always been doing. Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
In article <[email protected]>, Raymond Hettinger wrote: > I was exercising the alpha two release of 3.4 and noticed that > it is still being built under GCC 4.2.1. > > Is there any reason we have to use an old compiler? Yes, kinda. It's because the 64-bit/32-bit installer we supply is designed to run on multiple versions of OS X: 10.6 (Snow Leopard), 10.7, 10.8, and the upcoming 10.9. The safest way to ensure that the bits produced (executables, shared libs, and .so bundles) are linked with compatible versions of system shared libraries and frameworks is to build on the lowest supported system, 10.6, or - carefully - with a 10.6 SDK on a newer system. The standard compiler in the Apple Developer Tools for 10.6 is gcc 4.2. Clang was very immature at that point. The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past. > I would like to see it built under the latest version of Clang > (like the other tools on the Mac) or under GCC 4.8.1. > I've better using the latter for many months. It works great > and produces *much* better code (in terms of readability > for those of us who look at assembly output and in terms > of speed (approx 20-25% better for cpu bound code)). > > I'm wondering whether is some issue that forces us to use > GCC 4.2.1 or whether that is just an artifact of continuing > to do what we've always been doing. I'd like to move to Apple's latest clang, as well. (Apple is dropping gcc totally from the next release of Xcode.) There are a couple of approaches that may work and still reliably support multiple versions of OS X. Investigating this is on my list of things to do prior to the next alpha. I've opened a bug tracker issue for this (Issue19019). -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sat, 14 Sep 2013 12:31:36 -0700 Guido van Rossum wrote: > On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote: > > > Following the python-dev discussion, I've written a PEP to recap the > > proposal and the various arguments. It's inlined below, and it will > > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. > > > > Thanks, Antoine! > > Raymond Hettinger has volunteered to be the PEP dictator (is that the word > we use?) for this PEP. The discussion has settled down for the most part, and there is a consensus amongst participants on the desireability of the feature and its characteristics. The implementation is straightforward pure Python (Serhiy's C proposal should probably be a separate enhancement request on the tracker). I think the proposal will soon be ready for a pronouncement - unless other concrete questions and suggestions are recorded. Thanks Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
On Sep 14, 2013, at 1:32 PM, Ned Deily wrote: > The > most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have > a mature clang but do not provide a 10.6 SDK. Even with using an SDK, > it's still possible to end up inadvertently linking with the wrong > versions of system libraries. We have been burned by that in the past. I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5). Otherwise, were trapped in an old world and using the same reasoning as companies that still mandate Internet Explorer 6; forgoing the benefits of newer browsers just to make sure a few pieces of legacy code can be supported. > > I'd like to move to Apple's latest clang, as well. (Apple is dropping > gcc totally from the next release of Xcode.) That is an excellent reason for us to move as well. Otherwise, we risk getting out of sync with the rest of the ecosystem. > I've opened a bug tracker issue for this (Issue19019). Thank you. One thing that can be done is to take advantage of the 3.4 alphas and betas to experiment with having both a legacy version and fresh build with better tools. That would let us find out early whether the worries and fears are real and will manifest themselves in practice. I've been building under GCC 4.8.1 for months and have encountered no problems at all with the popular third-party modules or with linking to existing SO files. Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
14.09.13 20:41, Antoine Pitrou написав(ла): No good reason. What's the name? transform_func? transform_func looks... truncated. Why not transform_function or trans_func? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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 transform_function or trans_func? The stdlib commonly uses "func" rather than "function". For example "functools", where partial has an attribute named "func". I suppose it's like "int" vs. "integer". Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sat, Sep 14, 2013 at 2:55 PM, 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 transform_function or > trans_func? transform_λ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 14/09/13 23:31, Eli Bendersky wrote: On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka mailto:[email protected]>> wrote: 14.09.13 20:41, Antoine Pitrou написав(ла): No good reason. What's the name? transform_func? transform_func looks... truncated. Why not transform_function or trans_func? transform_λ Shouldn't that be transform_ƛ? (PEP 3117) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
+1. A 10.6-only build makes sense. If you aren't having problems with GCC 4.8, then Clang shouldn't give any trouble. Honestly, I still think Clang should be a compiler option in Windows distutils... Raymond Hettinger wrote: > >On Sep 14, 2013, at 1:32 PM, Ned Deily wrote: >> The >> most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, >have >> a mature clang but do not provide a 10.6 SDK. Even with using an >SDK, >> it's still possible to end up inadvertently linking with the wrong >> versions of system libraries. We have been burned by that in the >past. > >I think we should offer a separate Mac build just for 10.6 >(much like we do for the 32-bit PPC option for 10.5). > >Otherwise, were trapped in an old world and using the same >reasoning as companies that still mandate Internet Explorer 6; >forgoing the benefits of newer browsers just to make sure >a few pieces of legacy code can be supported. > >> >> I'd like to move to Apple's latest clang, as well. (Apple is >dropping >> gcc totally from the next release of Xcode.) > >That is an excellent reason for us to move as well. >Otherwise, we risk getting out of sync with the rest of the ecosystem. > >> I've opened a bug tracker issue for this (Issue19019). > >Thank you. > >One thing that can be done is to take advantage of the 3.4 alphas >and betas to experiment with having both a legacy version and >fresh build with better tools. That would let us find out early >whether >the worries and fears are real and will manifest themselves in >practice. > >I've been building under GCC 4.8.1 for months and have encountered >no problems at all with the popular third-party modules or with linking >to existing SO files. > > >Raymond >___ >Python-Dev mailing list >[email protected] >https://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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 transform_function or trans_func? The stdlib commonly uses "func" rather than "function". For example "functools", where partial has an attribute named "func". I suppose it's like "int" vs. "integer". The same functools has decorating_function() with the user_function argument. Also find_function, search_function, create_function, isfunction, isgeneratorfunction, from_function, has_function, copy_function, pickle_function, register_function, emit_function, and print_function. This is not counting tests, IDLE and private names. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
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 transform_function or trans_func? The stdlib commonly uses "func" rather than "function". For example "functools", where partial has an attribute named "func". I suppose it's like "int" vs. "integer". The same functools has decorating_function() with the user_function argument. Also find_function, search_function, create_function, isfunction, isgeneratorfunction, from_function, has_function, copy_function, pickle_function, register_function, emit_function, and print_function. This is not counting tests, IDLE and private names. The name of the parameter in __init__ is 'transform'. We could just call it that. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 09/14/2013 07:30 PM, Antoine Pitrou wrote: On Sat, 14 Sep 2013 14:33:56 +0900 Larry Hastings wrote: Whenever I read a discussion about the dict, I always wonder whether the same thing applies to a set. Have you considered the utility of a TransformSet? Or is it YAGNI? Well, a TransformSet is like a normal dict, you just need to call the transformation function yourself when inserting the keys. s/normal dict/normal set/ But, then, a TransformDict is like a normal dict, you just need to call the transformation function yourself when inserting the keys. Yet a TransformDict is a useful enough concept that it is being proposed for addition; I was wondering if a TransformSet would be useful, too. But I suppose we should take baby steps here. //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
