Re: [Python-Dev] Deprecating the formatter module

On 13/08/13 23:36, Brett Cannon wrote: On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka wrote: 12.08.13 22:22, Brett Cannon написав(ла): I have created http://bugs.python.org/**issue18716to deprecate the formatter module for removal in Python 3.6 unless

[Python-Dev] PEP 450 adding statistics module

Hi all, I have raised 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/ There has been considerable discussion on python-ideas, which is now reflected by the PEP. I've signed the Contribut

Re: [Python-Dev] Deprecating the formatter module

On 15/08/13 01:08, Brett Cannon wrote: On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano wrote: On 13/08/13 23:36, Brett Cannon wrote: On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka wrote: 12.08.13 22:22, Brett Cannon написав(ла): I have created http://bugs.pytho

Re: [Python-Dev] PEP 450 adding statistics module

On 15/08/13 11:49, Terry Reedy wrote: On 8/14/2013 9:25 PM, Steven D'Aprano wrote: The tests aren't yet integrated with the test runner but are runnable manually. What do you mean? With the changes I gave you, they run fine as part of the test suite. I'm sorry Terry, at th

Re: [Python-Dev] PEP 450 adding statistics module

On 15/08/13 21:42, Mark Dickinson wrote: The PEP and code look generally good to me. I think the API for median and its variants deserves some wider discussion: the reference implementation has a callable 'median', and variant callables 'median.low', 'median.high', 'median.grouped'. The pattern

Re: [Python-Dev] PEP 450 adding statistics module

On 16/08/13 04:10, Eric V. Smith wrote: I agree with Mark: the proposed median, median.low, etc., doesn't feel right. Is there any example of doing this in the stdlib? The most obvious case is datetime: we have datetime(), and datetime.now(), datetime.today(), and datetime.strftime(). The onl

Re: [Python-Dev] PEP 450 adding statistics module

On 16/08/13 04:24, R. David Murray wrote: I too prefer the median_low naming rather than median.low. I'm not sure I can articulate why, but certainly the fact that that latter isn't used anywhere else in the stdlib that I can think of is probably a lot of it:) And the reason it's not used in t

Re: [Python-Dev] PEP 450 adding statistics module

On 16/08/13 17:47, Oscar Benjamin wrote: I can't think of a situation where 1 or 2 modes are acceptable but 3 is not. The only forms I can imagine using are mode(data) to get the unique mode if it exists and mode(data, max_modes=None) to get the set of all modes. Hmmm, I think you are right. Th

[Python-Dev] Tracker meta-issue

Is this the right place to request somebody look at an issue in the meta-tracker? http://psf.upfronthosting.co.za/roundup/meta/issue517 Replying to reviews gives an AttributeError exception. This was reported three months ago, and is currently unassigned. Actually, on closer look, it seems to

Re: [Python-Dev] PEP 450 adding statistics module

Hi all, I think that PEP 450 is now ready for a PEP dictator. There have been a number of code reviews, and feedback has been taken into account. The test suite passes. I'm not aware of any unanswered issues with the code. At least two people other than myself think that the implementation is

Re: [Python-Dev] Completing the email6 API changes.

On 31/08/13 15:21, R. David Murray wrote: If you've read my blog (eg: on planet python), you will be aware that I dedicated August to full time email package development. [...] The API looks really nice! Thank you for putting this together. A question comes to mind though: All input strings

Re: [Python-Dev] PEP 450 adding statistics module

I'd like to get some attention for this please. On Sat, Aug 31, 2013 at 12:58:39PM +1000, Steven D'Aprano wrote: > Hi all, > > > I think that PEP 450 is now ready for a PEP dictator. There have been a > number of code reviews, and feedback has been taken into a

Re: [Python-Dev] PEP 450 adding statistics module

On Sun, Sep 08, 2013 at 10:25:22AM -0700, Guido van Rossum wrote: > Steven, I'd like to just approve the PEP, given the amount of > discussion that's happened already (though I didn't follow much of > it). I quickly glanced through the PEP and didn't find anything I'd > personally object to, but th

Re: [Python-Dev] PEP 450 adding statistics module

On Sun, Sep 08, 2013 at 02:41:35PM -0700, Guido van Rossum wrote: > On Sun, Sep 8, 2013 at 1:48 PM, Oscar Benjamin > wrote: > > The most obvious alternative that isn't explicitly mentioned in the > > PEP is to accept either: > > > > def correlation(x, y=None): > > if y is None: > > xs

Re: [Python-Dev] PEP 450 adding statistics module

On Sun, Sep 08, 2013 at 09:14:39PM +0100, Paul Moore wrote: > On 8 September 2013 20:19, Steven D'Aprano wrote: > [...] > > Is this satisfactory or do I need to go into more detail? > > It describes only 7 functions, and yet you state there are 11. I'd > suggest y

Re: [Python-Dev] PEP 450 adding statistics module

On Mon, Sep 09, 2013 at 12:26:05PM +1200, Greg wrote: > On 9/09/2013 5:52 a.m., Guido van Rossum wrote: > >Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are > >long. > > Would it be worth having a transpose() function in the stdlib > somewhere, that returns a view instead

Re: [Python-Dev] PEP 450 adding statistics module

On Mon, Sep 09, 2013 at 05:44:43AM -0500, Skip Montanaro wrote: > > However, it's common in economic statistics to have a rectangular > > array, and extract both certain rows (tuples of observations on > > variables) and certain columns (variables). For example you might > > have data on populatio

Re: [Python-Dev] Add a "transformdict" to collections

On Wed, Sep 11, 2013 at 06:08:25AM -0500, Skip Montanaro wrote: > (I still don't care for the name. "Transform" != "case folding" in my > mind. A quick scan of your links suggests most people think something > like "cidict" or "CaseInsensitiveDict" would be more descriptive.) But the proposal is

Re: [Python-Dev] Add a "transformdict" to collections

On Wed, Sep 11, 2013 at 10:47:12PM +1000, Nick Coghlan wrote: > I'll join the chorus requesting that this live on PyPI for a while first. Another alternative would be ActiveState's Python recipes: http://code.activestate.com/recipes/langs/python which is a lot lighter weight than creating a pac

Re: [Python-Dev] PEP 447: add type.__locallookup__

On Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote: > I don't particularly like __locallookup__ either, but haven't found a > better name yet. "__lookup_in_class__" was the best alternative I > could come up with, and that feels different than other special > methods. The name in

Re: [Python-Dev] PEP 447: add type.__locallookup__

On Fri, Sep 13, 2013 at 03:04:49AM +, Steve Dower wrote: > What about __getlocalattribute__ or __getattributenorecurse__? Long, > but this isn't going to be used often. This has nothing to do with locals, nor does it have anything to do with recursion, so both those names are misleading.

Re: [Python-Dev] PEP 447: add type.__locallookup__

On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote: > Last I checked, looking up in the instance dict us exactly what it > does. Even the example you posted is doing that. The example from the PEP shows: return cls.__dict__[name] not "self.__dict__[name]". It is true that "the ins

Re: [Python-Dev] PEP 447: add type.__locallookup__

On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote: > Perhaps "__getdescriptor__" would work as the method name? Yes, it can > technically return a non-descriptor, So technically that name is, um, what's the term... oh yes, "a lie". :-) > but the *primary* purpose is to > customise t

Re: [Python-Dev] PEP 455: TransformDict

On Fri, Sep 13, 2013 at 11:45:16PM +0200, Antoine Pitrou wrote: > Ok, I have a better (IMO) proposal: > > >>> d = TransformDict(str.casefold, {'Foo': 1}) > >>> d.getitem('foo') > ('Foo', 1) > >>> d.getitem('bar') > Traceback (most recent call last): > File "", line 1, in

Re: [Python-Dev] PEP 450 adding statistics module

On Sun, Sep 08, 2013 at 10:51:57AM -0700, Guido van Rossum wrote: > Never mind, I found the patch and the issue. I really think that the > *PEP* is ready for inclusion after the open issues are changed into > something like Discussion or Future Work, and after adding a more > prominent link to the

Re: [Python-Dev] PEP 455: TransformDict

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 approp

Re: [Python-Dev] PEP 455: TransformDict

On Sat, Sep 14, 2013 at 02:25:42AM +0100, MRAB wrote: > On 14/09/2013 01:49, Steven D'Aprano wrote: > >d = TransformDict(...) > >for key in data: > > key = d.get_canonical(key) > > value = d[key] > > print("{}: {}".format(key, value)) &g

Re: [Python-Dev] PEP 455: TransformDict

On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote: > 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-en

Re: [Python-Dev] PEP 455: TransformDict

On Fri, Sep 13, 2013 at 06:40:06PM -0700, Ethan Furman wrote: > >and if you wanted the transformed key you would apply the transform > >function to the key. > > Indeed. The question is: how? It is entirely possible that your function > has a TransformDict alone, and no memory of the transform

Re: [Python-Dev] PEP 450 adding statistics module

s extensive docstrings, but will also need a separate statistics.rst file. I don't recall any other outstanding issues, if I have forgotten any, please remind me. > On Fri, Sep 13, 2013 at 5:59 PM, Steven D'Aprano wrote: > > > On Sun, Sep 08, 2013 at 10:51:57AM -0700,

Re: [Python-Dev] PEP 450 adding statistics module

On Tue, Sep 17, 2013 at 02:21:16PM -0700, Guido van Rossum wrote: > Congrats, I've accepted the PEP. Nice work! Please work with the reviewers > on the issue on the code. Thank you, and thanks to everyone who contributed with the discussion. > (Steven or Oscar, if either of you could work Oscar's

Re: [Python-Dev] Use an empty def as a lambda

On Thu, Sep 19, 2013 at 01:54:08PM -0700, Ben Gift wrote: > I think the lambda keyword is difficult to understand for many people. It > would be more pythonic to use an empty def call instead. Hi Ben, and welcome! Is this your first post? I'm afraid I don't recognise your name. I think this disc

Re: [Python-Dev] Use an empty def as a lambda

Guys, this thread is not Python-Dev territory. It should have gone to Python-Ideas. I repeat what I posted two days ago: Proposals for changes to syntax and functionality are normally expected to gather feedback on python-ideas before coming to python-dev for final approval or reject

[Python-Dev] Best practice for documentation for std lib

Hi all, I have a question about how I should manage documentation for the statistics module for Python 3.4. At the moment, I have extensive docstrings in the module itself. I don't believe anyone has flagged that as "too much information" in a code review, so I'm going to assume that large doc

Re: [Python-Dev] Best practice for documentation for std lib

On Sun, Sep 22, 2013 at 10:20:46AM +0200, Antoine Pitrou wrote: > On Sun, 22 Sep 2013 13:13:04 +1000 > Steven D'Aprano wrote: > > Hi all, > > > > I have a question about how I should manage documentation for the > > statistics module for Python 3

Re: [Python-Dev] Best practice for documentation for std lib

On Sun, Sep 22, 2013 at 05:54:57AM -0700, Eli Bendersky wrote: > IMHO the right way to think about it is that the .rst files are by far the > more important documentation. Sometimes we forget that most Python > programmers are people who won't go into the source to read docstrings. Docstrings are

Re: [Python-Dev] Best practice for documentation for std lib

On Sun, Sep 22, 2013 at 10:07:28AM -0700, Guido van Rossum wrote: > Authors writing 3rd party packages can do what they want. > > But for the stdlib it's been settled for ages: docstrings should be concise > (but not cryptic(*)), longer documentation go into the separately written > text for docs

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 07:53:00AM -0700, Guido van Rossum wrote: > there is no rule that because you can > access something on the class you should be able to access it on the > instance. Try asking an instance for its class's __mro__ or __bases__. It might not be a rule, but it's certainly the

Re: [Python-Dev] Best practice for documentation for std lib

This is getting off-topic, if you're not interested in English grammar you should stop reading. On Mon, Sep 23, 2013 at 03:18:01PM -0400, Alexander Belopolsky wrote: > I don't think "Returns bar." is a valid English sentence because it lacks > subject. Subjectless sentences are unusual in Engl

Re: [Python-Dev] Why not support user defined operator overloading ?

On Sun, Sep 29, 2013 at 08:51:37PM +0800, 张佩佩 wrote: > Hello: > As far as I know, there is not a language support user defined operator > overloading. > Python3 can overloading belowed operators. [...] > (Do I miss something ?) Yes, many. http://docs.python.org/3/reference/datamodel.html#s

Re: [Python-Dev] Why not support user defined operator overloading ?

On Sun, Sep 29, 2013 at 03:35:27PM -0400, Ned Batchelder wrote: > It isn't just a matter of a more complex parser: where would the parser > get the information about these new operators? The obvious first answer > is that they would be defined as part of classes, but that means the > operator

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Sat, Oct 05, 2013 at 01:27:37AM +0200, Victor Stinner wrote: > I have no idea of the price of renting a botnet, it's probably > expensive (and illegal as well). Twelve cents per machine. Cheaper in bulk, and cheaper still for machines outside of the US. For those on a budget, you can get ten

Re: [Python-Dev] PEP 455: TransformDict

On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: > (If we cannot find a better name, we may add more specialized classes: > KeyInsensitiveDict and IdentiyDict. But I like the idea of using my > own "transform" function.) -1 on a plethora of specialised dicts. I do think that a Tra

Re: [Python-Dev] PEP 455: TransformDict

On Mon, Oct 07, 2013 at 02:55:44PM -0700, Ethan Furman wrote: > On 10/07/2013 02:24 PM, Steven D'Aprano wrote: > >On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: > > > >if type(self) is not dict: > > # This only applies to subclass

Re: [Python-Dev] PEP 455: TransformDict

On Mon, Oct 07, 2013 at 06:17:09PM -0700, Mark Janssen wrote: > Sorry I missed the original discussion, but isn't this a simple case > of putting a decorator around the getitem method (to transform the > input key) and a single line in the body of the setitem method, making > this very easy adaptat

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote: > This PEP proposes a syntax for positional-only parameters in Python. > Positional-only parameters are parameters without an externally-usable > name; when a function accepting positional-only parameters is called, > positional argum

Re: [Python-Dev] type.__subclasses__() doesn't work

On Wed, Oct 09, 2013 at 12:20:18PM +0200, Antoine Pitrou wrote: > > Hello, > > Just noticed the following quirk: > > >>> type.__subclasses__() > Traceback (most recent call last): > File "", line 1, in > TypeError: descriptor '__subclasses__' of 'type' object needs an argument > > Yet it wou

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Wed, Oct 09, 2013 at 02:25:18PM -0400, Terry Reedy wrote: > Unlike Georg, I think '/' is plausibly ok. You should, however, > explicitly say in the PEP that it was selected not randomly but by rough > analogy. Division (/) is the inverse of multiplication (*), and > positional-only is sort o

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Wed, Oct 09, 2013 at 09:46:00PM +0100, Mark Shannon wrote: > There is no need to create an "undefined" value. > Rather than define a parameter by assigning a fake value, just don't > define it. We already do this for non-parameter locals and it could be > extended to parameters. > > 'range'

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Wed, Oct 09, 2013 at 04:15:36PM +0200, Larry Hastings wrote: > >- parameters in optional groups should just have an implied "=None" > >that can be overriden if desired. > > > > No no no! You can't have a default value, and you definitely couldn't > use None. > > range() decides what its ar

Re: [Python-Dev] Support keyword in PEP URL?

On Sat, Oct 12, 2013 at 10:48:41AM +0100, Paul Moore wrote: > On 12 October 2013 01:53, Victor Stinner wrote: > > t's easy to mix up PEP numbers. For example, Martin von Loewis wrote > > two major PEP related to Unicode: 383 and 393. These numbers are > > close, only one digit is different. It's w

Re: [Python-Dev] non-US zip archives support in zipfile.py

On Tue, Oct 15, 2013 at 10:20:03AM +0200, Victor Stinner wrote: > Both issues are related and should be fixed in the *same* commit. > Python should provide an option to encode explicitly filenames to > UTF-8. Or maybe better: encode to UTF-8 by default, with an option to > encode to cp437, and anot

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On Wed, Oct 16, 2013 at 09:24:11AM +1000, Nick Coghlan wrote: > Even though it eventually > convinced me to change the name, this thread still epitomises everything > that sucks about soul destroying, energy draining bikeshed painting that > makes me wonder why I ever bother trying to make anythin

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote: > On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > > On 6/7/2016 1:51 PM, Eric Snow wrote: > > > >> Note: just to be clear, this PEP is *not* about changing > > > >> ``type.__dict__`` to ``OrderedDict``. > > > > By 'type', do you mean

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 15:46:00 -0700 > Ethan Furman wrote: > > > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > > >> remove it entirely in Py

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 08, 2016 at 10:04:08AM +0200, Victor Stinner wrote: > It's common that users complain that Python core developers like > breaking the compatibility at each release. No more common as users complaining that Python features are badly designed and crufty and should be fixed. Whatever w

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 08:26:20AM -0400, Donald Stufft wrote: > random.py > - > > In the abstract it doesn't hurt to seed MT with a CSPRNG, it just doesn't > provide much (if any) benefit and in this case it is hurting us because of the > cost on import (which will exist on other platfor

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 12:39:00PM -0400, Donald Stufft wrote: > There are three options for what do with os.urandom by default: > > * Allow it to silently return data that may or may not be > cryptographically secure based on what the state of the urandom pool > initialization looks like. Jus

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 12:54:31PM -0400, Ben Leslie wrote: > I think an exception is much easier for a user to deal with from a > practical point of view. Trying to work out why a process has hung is > obviously possible, but not necessarily easy. > > Having a process crash due to an exception i

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 06:21:32PM +0100, Paul Moore wrote: > If we put the specific issue of applications that run very early in > system startup to one side, is there a possibility of running out of > entropy during normal system use? Even for a tiny duration? With /dev/urandom, I believe the a

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote: > Hi, > > Last weeks, I made researchs on how to get stable and reliable > benchmarks, especially for the corner case of microbenchmarks. The > first result is a serie of article, here are the first three: Thank you for this! I am ve

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 05:07:18PM +0200, Victor Stinner wrote: > I started to work on visualisation. IMHO it helps to understand the problem. > > Let's create a large dataset: 500 samples (100 processes x 5 samples): > --- > $ python3 telco.py --json-file=telco.json -p 100 -n 5 > --- > > Attache

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 12:06:31AM +0200, Victor Stinner wrote: > > Victor if you could calculate the sample skewness of your results I think > > that would be very interesting! > > I'm good to copy/paste code, but less to compute statistics :-) Would > be interesed to write a pull request, or at

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 11:22:42PM +0200, Victor Stinner wrote: > 2016-06-10 20:47 GMT+02:00 Meador Inge : > > Apologies in advance if this is answered in one of the links you posted, but > > out of curiosity was geometric mean considered? > > > > In the compiler world this is a very common way of

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 07:52:31PM -0700, Nikolaus Rath wrote: > On Jun 09 2016, Guido van Rossum wrote: > > I don't think we should add a new function. I think we should convince > > ourselves that there is not enough of a risk of an exploit even if > > os.urandom() falls back. > > That will be

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 01:06:45PM -0700, Larry Hastings wrote: > > On 06/10/2016 01:01 PM, David Mertz wrote: > >So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), > > That makes... five of us I think ;-) (Larry Guido Barry Tim David) > > > >and the NEW APIs in secrets

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 11:42:40AM -0700, Chris Jerdonek wrote: > And going back to Larry's original e-mail, where he said-- > > On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings wrote: > > THE PROBLEM > > ... > > The issue author had already identified the cause: CPython was blocking on > > getran

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sat, Jun 11, 2016 at 02:16:21PM -0700, Guido van Rossum wrote: [on the real-world consequences of degraded randomness from /dev/urandom] > Actually it's not clear to me at all that it could have happened to Python. > (Wasn't it an embedded system?) A Raspberry Pi. But don't people run Python

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 07:43:18PM -0400, Random832 wrote: > On Fri, Jun 10, 2016, at 21:45, Steven D'Aprano wrote: > > If you express your performances as speeds (as "calculations per > > second") then the harmonic mean is the right way to average them. > >

Re: [Python-Dev] [Python-checkins] cpython (3.5): Fix os.urandom() using getrandom() on Linux

Is this right? I thought we had decided that os.urandom should *not* fall back on getrandom on Linux? On Tue, Jun 14, 2016 at 02:36:27PM +, victor. stinner wrote: > https://hg.python.org/cpython/rev/e028e86a5b73 > changeset: 102033:e028e86a5b73 > branch: 3.5 > parent: 102031:a36

[Python-Dev] Why does base64 return bytes?

Normally I'd take a question like this to Python-List, but this question has turned out to be quite diversive, with people having strong opinions but no definitive answer. So I thought I'd ask here and hope that some of the core devs would have an idea. Why does base64 encoding in Python return

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 05:29:12PM +0100, Mark Lawrence via Python-Dev wrote: > As I've the time to play detective I'd suggest > https://mail.python.org/pipermail/python-3000/2007-July/008975.html Thanks Mark, that's great! -- Steve ___ Python-Dev

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 09:40:51PM -0700, Guido van Rossum wrote: > I'm officially on vacation, but I was surprised that people now assume > RFCs, which specify internet protocols, would have a bearing on programming > languages. (With perhaps an exception for RFCs that specifically specify > how p

Re: [Python-Dev] Why does base64 return bytes?

On Wed, Jun 15, 2016 at 12:53:15PM +, Daniel Holth wrote: > In that case could we just add a base64_text() method somewhere? Who would > like to measure whether it would be a win? Just call .decode('ascii') on the output of base64.b64encode. Not every one-liner needs to be a standard function

Re: [Python-Dev] JUMP_ABSOLUTE in nested if statements

On Sat, Jun 18, 2016 at 11:32:52PM +0100, Obiesie ike-nwosu via Python-Dev wrote: > That is much clearer now. > Thanks a lot Raymond for taking the time out to explain this to me. > On a closing note, is this mailing list the right place to ask these kinds > of n00b questions? That depends wha

Re: [Python-Dev] When to use EOFError?

On Mon, Jun 27, 2016 at 03:47:31PM -0700, Ethan Furman wrote: > On 06/27/2016 03:20 PM, Guido van Rossum wrote: > > >The point is that it's not an error. In Andre Malo's use case, at > >least, EOFError is used as a control flow exception, not as an error. > > Like StopIteration then: only an erro

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, Jul 05, 2016 at 09:53:24AM +0200, Petr Viktorin wrote: > While we're on the subject, I'd like to offer another point for > consideration: not all implementations of Python can provide the full > stdlib, and not everyone wants the full stdlib. > > For MicroPython, most of Python's batterie

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, Jul 05, 2016 at 08:01:43PM +0200, Petr Viktorin wrote: > In the tkinter case, compiling for source is easy on a developer's > computer, but doing that on a headless server brings in devel files for > the entire graphical environment. > Are you saying Python on servers should have a way to

Re: [Python-Dev] digital panels processing text sowftware write with Python language

On Fri, Jul 08, 2016 at 01:16:00PM +, Hadi Montazami safavi via Python-Dev wrote: > Dear SirsWith thanks, iam looking digital panels processing text > sowftware write with Python languagefor my project.Could you please > guide me if there is or guiding to write it personally.Thanking you in

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On Sat, Jul 09, 2016 at 11:50:59PM +1000, Nick Coghlan wrote: > I'm in the process of trying to disentangle > http://bugs.python.org/issue27137 which points out some of the > behavioural differences that arise when falling back from the original > C implementation of functools.partial to the pure P

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On Sun, Jul 10, 2016 at 10:15:33AM +1000, Nick Coghlan wrote: > On 10 July 2016 at 05:10, Steven D'Aprano wrote: > > The other side of the issue is that requiring exact correspondence is > > considerably more difficult and may be over-kill for some uses. > > Hypothetica

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On Mon, Jul 11, 2016 at 01:32:32PM +1000, Chris Angelico wrote: > On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano wrote: > > (1) How much extra effort are we going to *mandate* that core devs put > > in to hide the differences between C and Python code, for the benefit of

[Python-Dev] Changing the licence of statistics.py

I'm the author of statistics.py, and for historical reasons it was originally included in the standard library under the Apache licence. I now wish to change that and have it licenced under Python's standard licence. Is there anything I need to do other than just remove the Apache licence boile

Re: [Python-Dev] Changing the licence of statistics.py

On Sun, Aug 14, 2016 at 04:27:21AM +, Brett Cannon wrote: > Are you the sole author of the statistics module prior to contributing it, > Steve? Yes. There has been at least one patch to the module as part of the standard library by someone else: http://bugs.python.org/issue26002 but prior

[Python-Dev] Would somebody like to review issue27573 please?

I have a tiny patch for issue 27573, "code.interact() should print an exit message". http://bugs.python.org/issue27573 Its a one-line change to code.py, plus a dozen or so lines changed in test_code.py. If its not controversial, I think it would be nice to get it into 3.6. Thanks, -- Ste

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > I'm happy to present PEP 526 for your collective review: Are you hoping to get this in before 3.6 beta? Because I'm not sure I can give this much attention before then, but I really want to. -- Steve __

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 07:15:55PM -0700, Guido van Rossum wrote: > On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote: > > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > >> I'm happy to present PEP 526 for your collective review: > >

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Thu, Sep 01, 2016 at 04:11:05PM +0300, Koos Zevenhoven wrote: > Maybe it's just me, but I've always thought 'def' is Python's least > logically used keyword. It seems to come from 'define', but what is it > about 'define' that makes it relate to functions only. Convention. You can't use "def"

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > - Whether (given PEP 484's relative success) it's worth adding syntax > for variable/attribute annotations. The PEP makes a good case that it does. > - Whether the keyword-free syntax idea proposed here is best: > NAME: TYPE

Re: [Python-Dev] Please reject or postpone PEP 526

Hi Mark, I'm going to trim your post drastically, down to the bare essentials, in order to keep this already long post down to a manageable size. On Fri, Sep 02, 2016 at 02:47:00PM +0100, Mark Shannon wrote: [...] > With type comments, this is intuitively correct and should type check: > def e

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: > A good checker should be able to infer that x is a union type at the > point that it's passed to spam, even without the type annotation. For > example: > > def eggs(cond:bool): > if cond: > x = 1 > else: >

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote: > "I'm not seeing what distinction you think you are making here. What > distinction do you see between: > > x: int = func(value) > > and > > x = func(value) #type: int" > > Not sure whether I agree with Mark on this particu

Re: [Python-Dev] Please reject or postpone PEP 526

On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote: > In other words PEP 484 specifically states that annotations are to help > with type inference. As defined in PEP 526, I think that type > annotations become a hindrance to type inference. I'm pretty sure that they don't. Have you

Re: [Python-Dev] Please reject or postpone PEP 526

On Sun, Sep 04, 2016 at 12:30:18PM +0100, Mark Shannon wrote: > It would be a real shame if PEP 526 mandates against checkers doing as > good as job as possible. Forcing all uses of a variable to have the same > type is a major and, IMO crippling, limitation. This is approaching FUD. Guido has

Re: [Python-Dev] Please reject or postpone PEP 526

Referring to the alternative syntax forms: # Proposed x: int = func(value) # Already accepted x = func(value) #type: int On Sun, Sep 04, 2016 at 11:52:24AM +0100, Mark Shannon wrote: > The key difference is in placement. > PEP 484 style > variable = value # annotation > > Whi

Re: [Python-Dev] Please reject or postpone PEP 526

On Mon, Sep 05, 2016 at 11:19:38AM +0300, Koos Zevenhoven wrote: > On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote: [...] > > On 5 September 2016 at 04:40, Koos Zevenhoven wrote: > >> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi > >> wrote: > >>> On 4 September 2016 at 19:59, Nick Coghlan

Re: [Python-Dev] Please reject or postpone PEP 526

On Mon, Sep 05, 2016 at 04:40:08PM +0300, Koos Zevenhoven wrote: > On Mon, Sep 5, 2016 at 3:10 PM, Steven D'Aprano wrote: > > > > [Koos Zevenhoven] > >> >> How is it going to help that these are equivalent within one checker, > >> >> if the me

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On Mon, Sep 05, 2016 at 04:26:17PM +0100, Mark Shannon wrote: > In this example: > > def bar()->Optional[int]: ... > > def foo()->int: > x:Optional[int] = bar() > if x is None: > return -1 > return x > > According to PEP 526 the annotation `x:Optional[

Re: [Python-Dev] Requesting on python directories

Hello Ramu, This is the wrong place to ask for help with your question, this is for development of the Python interpreter. I suggest you subscribe to the Python-List mailing list. For help with publishing packages, see https://wiki.python.org/moin/CheeseShopTutorial On Tue, Sep 06, 2016 at

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Thu, Sep 22, 2016 at 11:47:20PM -0700, Benjamin Peterson wrote: > > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson : > > > Just dump the compat macros in Python 4.0 I think. > > > > Please don't. Python 3 was so painful because we decided

<    3   4   5   6   7   8   9   10   11   12   >