Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 23:08, Serhiy Storchaka wrote: > Following issues on GitHub related to new Python releases I have found that > many projects try to fix deprecation warning, but there are projects that are > surprised by ending of deprecation periods and removing

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

I agree with Steve. There is *cognitive* overhead to type annotations. I find that they make Python code harder to read and understand. So I object to them in the documentation and docstrings as well. (Note: while I agree that the notation is compact for the simple types, the fact that it would

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On Nov 6, 2017, at 08:02, Victor Stinner wrote: > > While discussions on the typing module are still hot, what do you > think of allowing annotations in the standard libraries, but limited > to a few basic types: I’m still -1 on adding annotations to the stdlib,

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 06 Nov 2017 17:58:47 + Brett Cannon wrote: [] > > Why suddenly once in 25 years there's a need to do something to > > dict's, violating computer science background behind them (one of > > the reason enough people loved Python comparing to other "practical >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 20:47, Nick Coghlan wrote: >> warnings.silence_deprecations() >> python -X silence-deprecations >> PYTHONSILENCEDEPRECATIONS=x > > It could be interesting to combine this with Tim's suggestion of > putting an upper version limit on the silencing, so the

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On 11/6/2017 1:40 PM, Barry Warsaw wrote: On Nov 6, 2017, at 08:02, Victor Stinner wrote: While discussions on the typing module are still hot, what do you think of allowing annotations in the standard libraries, but limited to a few basic types: I’m still -1 on

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 6, 2017, at 11:23, Paul G wrote: > > Is there a major objection to just adding in explicit syntax for > order-preserving dictionaries? I don’t think new syntax is necessary. We already have OrderedDict, which to me is a perfectly sensible way to spell “I need a

[Python-Dev] Partial support of a platform

Hi, I see more and more proposed changes to fix some parts of the code to "partially" support a platform. I remember that 5 years ago, the CPython code was "full" of #ifdef and other conditional code to support various platforms, and I was happy when we succeeded to remove support for all these

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, 6 Nov 2017 at 08:36 Paul Sokolovsky wrote: > Hello, > > On Mon, 6 Nov 2017 14:30:45 +0100 > Antoine Pitrou wrote: > > > On Tue, 7 Nov 2017 00:14:35 +1100 > > Steven D'Aprano wrote: > > > On Mon, Nov 06, 2017 at 12:27:54PM

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 6, 2017, at 02:18, Paul Sokolovsky wrote: > What it will lead to is further fragmentation of the community. Python2 > vs Python3 split is far from being over, and now there're splits > between: > > * people who use "yield from" vs "await" > * people who use f-strings

Re: [Python-Dev] Partial support of a platform

> The PEP 11 has a nice description to get a *full* support of a new platform: > https://www.python.org/dev/peps/pep-0011/ PEP 11 defines the endpoint, full support, and several requirements to call a platform fully supported. It would be nice if a process was defined for getting from "no

[Python-Dev] Enabling depreciation warnings feature code cutoff

On 2017-11-06, Nick Coghlan wrote: > Gah, seven years on from Python 2.7's release, I still get caught by > that. I'm tempted to propose we reverse that decision and go back to > enabling them by default :P Either enable them by default or make them really easy to enable for development

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On 11/06/2017 01:25 PM, R. David Murray wrote: > Maybe I'm being a curmudgeon standing in the way of progress, but I'm > pretty sure there are a number of people in my camp :) I'm definitely there: anything which optimizes machine-readabilty over readability for the Mark 1 eyeball is a lose.

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Is there a major objection to just adding in explicit syntax for order-preserving dictionaries? To some extent that seems like a reasonable compromise position in an "explicit is better than implicit" sense. A whole lot of code is out there that doesn't require or expect order-preserving

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 6, 2017 at 4:11 AM Nick Coghlan wrote: > Here's a more-complicated-than-a-doctest-for-a-dict-repo, but still > fairly straightforward, example regarding the "insertion ordering > dictionaries are easier to use correctly" argument: > > import json > data =

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

I'm -1 on turning this on by default. As a Python developer, I want to be aware of when deprecations are introduced, but I don't want the users of my library or application to care or know if I don't address those deprecation warnings for a few months or a year. The right solution for me here

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 at 00:30 Victor Stinner wrote: > 2017-11-06 8:47 GMT+01:00 Serhiy Storchaka : > > 06.11.17 09:09, Guido van Rossum пише: > >> > >> I still find this unfriendly to users of Python scripts and small apps > who > >> are not the

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On Mon, Nov 6, 2017, 10:27 R. David Murray, wrote: > I agree with Steve. There is *cognitive* overhead to type annotations. > I find that they make Python code harder to read and understand. So I > object to them in the documentation and docstrings as well. (Note: >

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

I also feel this decision was a mistake. If there's a consensus to revert, I'm happy to draft a PEP. Alex On Nov 6, 2017 1:58 PM, "Neil Schemenauer" wrote: > On 2017-11-06, Nick Coghlan wrote: > > Gah, seven years on from Python 2.7's release, I still get caught by > >

Re: [Python-Dev] Remove typing from the stdlib

On 6 November 2017 at 03:41, Lukasz Langa wrote: > >> On 4 Nov, 2017, at 3:39 AM, Paul Moore wrote: >> >> Lukasz Langa said: >>> So, the difference is in perceived usability. It's psychological. >> >> Please, let's not start the "not in the stdlib isn't an

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 17:09, Guido van Rossum wrote: > I still find this unfriendly to users of Python scripts and small apps who > are not the developers of those scripts. At a distro level, these warnings being off by default has actually turned out to be a problem, as it's

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan wrote: > We've been running the current experiment for 7 years, and the main > observable outcome has been folks getting surprised by breaking > changes in CPython releases, especially folks that primarily use > Python interactively

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote: > That means our choices for 3.7 boil down to: > > * make this a language level guarantee that Python devs can reasonably rely on > * deliberately perturb dict iteration in CPython the same way the > default Go runtime does [1] I

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

2017-11-05 18:50 GMT+01:00 Guido van Rossum : > I don't see this as a reason to not put this into the language spec at 3.7. It can prevent some kinds of optimizations. Dictionaries are used "everywhere" in Python, so they are very important for performance. I would prefer to

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

2017-11-06 8:47 GMT+01:00 Serhiy Storchaka : > 06.11.17 09:09, Guido van Rossum пише: >> >> I still find this unfriendly to users of Python scripts and small apps who >> are not the developers of those scripts. (Large apps tend to spit out so >> much logging it doesn't really

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 18:46, Victor Stinner wrote: > 2017-11-05 18:50 GMT+01:00 Guido van Rossum : >> I don't see this as a reason to not put this into the language spec at 3.7. > > It can prevent some kinds of optimizations. Dictionaries are used >

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 11:33:10 -0800 Barry Warsaw wrote: [] > If we did make the change, it’s possible we would need a way to > explicit say that order is not preserved. That seems a little weird I recently was working on a more or less complex dataflow propagation

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

06.11.17 21:56, Paul Sokolovsky пише: Btw, in all this discussion, I don't remember anyone mentioning sets. I don't recall the way they're implemented in CPython, but they have strong conceptual and semantic resemblance to dict's. So, what about them, do they become ordered too? No, sets are

Re: [Python-Dev] Partial support of a platform

On 06Nov2017 0941, Victor Stinner wrote: [SNIP] But the question here is more about "partial" support. While changes are usually short, I dislike applying them to Python 2.7 and/or Python 3.6, until a platform is fully support. I prefer to first see a platform fully supported to see how much

Re: [Python-Dev] Partial support of a platform

On Mon, 6 Nov 2017 18:41:30 +0100 Victor Stinner wrote: > > Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc. We support POSIX-compatible platforms. Do OpenBSD and NetBSD need special care? Regards Antoine.

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 14:16, Gustavo Carneiro wrote: > But eventually, the warnings in 3rd-party Python modules gradually increased > because, since warnings are disabled by default, authors of command-line > tools, or even python modules, don't even realise they are

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 03:38, Nick Coghlan wrote: > - if we ever write "import foo" ourselves, then we're a Python > developer, and it's our responsibility to work out how to manage > DeprecationWarning when it gets raised by either our own code, or the > libraries and

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 19:14, Steven D'Aprano wrote: > On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote: >> When we did the "insertion ordered hash map" availability review, the >> main implementations we were checking on behalf of were Jython & VOC >> (JVM

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 20:21, Paul Moore wrote: > On 6 November 2017 at 03:38, Nick Coghlan wrote: >> - if we ever write "import foo" ourselves, then we're a Python >> developer, and it's our responsibility to work out how to manage >> DeprecationWarning

[Python-Dev] 3.5.4 doesn't appear in changelog

Hello, Is there a known reason why 3.5.4 doesn't appear in the changelogs at the bottom of https://docs.python.org/3.7/whatsnew/index.html ? (all releases until 3.5.3 do) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I think that Paul has a point. Interestingly, at the same time we're talking about guaranteeing the order of dicts, we're talking about using another, unordered, data structure (hash array mapped tries) to improve the performance of something that resembles a namespace. It seems the "unordered"

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: > MicroPython hashmap implementation is effectively O(n) (average and > worst case) due to the algorithm parameters chosen (like the load factor > of 1). Of course, parameters could be tweaked, but the ones chosen are > so because

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 6, 2017 at 9:36 PM, Stefan Krah wrote: > On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: >> MicroPython hashmap implementation is effectively O(n) (average and >> worst case) due to the algorithm parameters chosen (like the load factor >> of 1).

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 11:36:59 +0100 Stefan Krah wrote: > On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: > > MicroPython hashmap implementation is effectively O(n) (average and > > worst case) due to the algorithm parameters chosen (like the load > >

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, 5 Nov 2017 20:18:07 -0800 Lukasz Langa wrote: > > Interestingly enough, at Facebook we found out that using f-strings is > *faster* at runtime than the lazy form of logging.log("format with %s and > %d", arg1, arg2), including for cases when the log message is not

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 12:05:07 +1000 Nick Coghlan wrote: > > So my proposal is simple (and not really new): let's revert back to > the way things were in 2.6 and earlier, with DeprecationWarning being > visible by default, and app devs having to silence it explicitly > during

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 21:18, Steve Holden wrote: > I have to agree: I find the elevation of a CPython implementation detail to > a language feature somewhat hard to comprehend. Maybe it's more to do with > the way it's been presented, but this is hardly an enhancement the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Sun, 5 Nov 2017 12:04:41 +1000 Nick Coghlan wrote: > On 5 November 2017 at 04:35, Guido van Rossum > wrote: > > This sounds reasonable -- I think when we introduced this in 3.6 we > > were worried that other implementations (e.g. Jython) would

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 6, 2017 at 10:18 AM, Paul Sokolovsky wrote: > Hello, > > What happens now borders on technologic surrealism - the CPython, after > many years of persuasion, switched its dict algorithm, rather > inefficient in terms of memory, to something else, less inefficient >

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote: > > On 6 November 2017 at 16:36, Lukasz Langa wrote: > > - compile annotations like a small nested class body (but returning > the expression result, rather than None) > - emit MAKE_THUNK instead of the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 6, 2017 at 11:23 AM, Paul G wrote: > (Of course, given that CPython's implementation is order-preserving, a > bunch of code is probably now being written that implicitly requires on > this detail, but at least having syntax that makes that clear would give > people

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan wrote: > On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both > mistakenly though the async/await deprecation warnings were missing > from 3.6. Sometimes the universe just throws synchronicity right in your face. I'm working on building an internal tool against Python

Re: [Python-Dev] Partial support of a platform

2017-11-07 0:41 GMT+01:00 Serhiy Storchaka : > Several month ago there was a couple of buildbots including NetBSD and > OpenBSD. What happened to them? Was the support of NetBSD and OpenBSD > officially stopped as well as the support of OpenIndiana? While I don't recall

Re: [Python-Dev] Partial support of a platform

06.11.17 23:24, Antoine Pitrou пише: On Mon, 6 Nov 2017 18:41:30 +0100 Victor Stinner wrote: Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc. We support POSIX-compatible platforms. Do OpenBSD and NetBSD need special care? Yes, because our

Re: [Python-Dev] Partial support of a platform

06.11.17 19:41, Victor Stinner пише: Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc. But the way, is there an exhaustive list of platforms "officially" supported by CPython? Several month ago there was a couple of buildbots including NetBSD and OpenBSD. What happened

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 17:23, Paul G wrote: > Is there a major objection to just adding in explicit syntax for > order-preserving dictionaries? To some extent that seems like a reasonable > compromise position in an "explicit is better than implicit" sense. A whole > lot of

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 6, 2017, at 4:35 AM, Paul Moore wrote: > > 1. Without typing available, some programs using type annotations > won't run. That is, using type annotations (a > test-time/development-time feature) introduces a runtime dependency on > typing, and hence introduces an

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11/6/2017 1:12 PM, Barry Warsaw wrote: On Nov 5, 2017, at 20:47, Nick Coghlan wrote: warnings.silence_deprecations() python -X silence-deprecations PYTHONSILENCEDEPRECATIONS=x It could be interesting to combine this with Tim's suggestion of putting an upper version

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 7 November 2017 at 05:00, Alex Gaynor wrote: > I also feel this decision was a mistake. If there's a consensus to revert, > I'm happy to draft a PEP. Even without consensus to revert, I think it would be great to have a PEP summarising some of the trade-offs between the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Tue, Nov 07, 2017 at 05:28:24PM +1000, Nick Coghlan wrote: > On 7 November 2017 at 16:21, Steven D'Aprano wrote: > > On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote: > >> Maybe OrderedDict can be > >> rewritten to use the dict implementation. But the evidence

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

As memory footprint and import time point of view, I prefer string to thunk. We can intern strings, but not lambda. Dict containing only strings is not tracked by GC, dict containing lambdas is tracked by GC. INADA Naoki On Tue, Nov 7, 2017 at 8:20 AM, Lukasz Langa

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I strongly opposed adding an ordered guarantee to regular dicts. If the implementation happens to keep that, great. Maybe OrderedDict can be rewritten to use the dict implementation. But the evidence that all implementations will always be fine with this restraint feels poor, and we have a

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 7 November 2017 at 03:27, Chris Jerdonek wrote: > On Mon, Nov 6, 2017 at 4:11 AM Nick Coghlan wrote: >> Getting from the "Works on CPython 3.6+ but is technically >> non-portable" state to a fully portable correct implementation that >> ensures a

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 11:33:10AM -0800, Barry Warsaw wrote: > If we did make the change, it’s possible we would need a way to > explicit say that order is not preserved. That seems a little weird > to me, but I suppose it could be useful. Useful for what? Given that we will hypothetically

Re: [Python-Dev] Remove typing from the stdlib

> Beyond the API already proposed in PEP 557, this would mean adding: > > * dataclasses.ClassVar (as proposed above) > * dataclasses.Any (probably just set to the literal string > "dataclasses.Any") > * dataclasses.NamedTuple (as a replacement for typing.NamedTuple) > * potentially

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> On Nov 6, 2017, at 8:05 PM, David Mertz wrote: > > I strongly opposed adding an ordered guarantee to regular dicts. If the > implementation happens to keep that, great. Maybe OrderedDict can be > rewritten to use the dict implementation. But the evidence that all >

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 7 November 2017 at 09:23, Chris Barker wrote: > in short -- we don't have a choice (unless we add an explicit randomization > as some suggested -- but that just seems perverse...) And this is the key point for me: "choosing not to choose" is effectively the same as

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 10:17:23PM -0200, Joao S. O. Bueno wrote: > And also, forgot along the discussion, is the big disadvantage that > other Python implementations would have a quite > significant overhead on mandatory ordered dicts. I don't think that is correct. Nick already did a survey,

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 7 November 2017 at 09:20, Lukasz Langa wrote: > > >> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote: >> >> On 6 November 2017 at 16:36, Lukasz Langa wrote: >> >> - compile annotations like a small nested class body (but returning >> the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 7 November 2017 at 16:21, Steven D'Aprano wrote: > On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote: >> Maybe OrderedDict can be >> rewritten to use the dict implementation. But the evidence that all >> implementations will always be fine with this restraint

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, 6 Nov 2017 at 11:08 Paul Sokolovsky wrote: > Hello, > > On Mon, 06 Nov 2017 17:58:47 + > Brett Cannon wrote: > > [] > > > > Why suddenly once in 25 years there's a need to do something to > > > dict's, violating computer science background behind

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 03:42, Simon Cross wrote: > Maybe there are ways around these things, but I'm not really seeing > what's wrong with the current situation that can't be fixed with > slightly better CI setups (which are good for other reasons too). Given the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote: > For MicroPython, it would lead to quite an overhead to make > dictionary items be in insertion order. As I mentioned, MicroPython > optimizes for very low bookkeeping memory overhead, so lookups are > effectively O(n), but

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: > > I don't think that situation should change the decision, > > Indeed, it shouldn't. What may change it is the simple and obvious fact > that there's no need to change anything, as proven by the 25-year > history of the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I agree with Raymond. dict ordered by default makes better developer experience. So, my concern is how "language spec" is important for minor (sorry about my bad vocabulary) implementation? What's difference between "MicroPython is 100% compatible with language spec" and "MicroPython is almost

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 11/6/2017 9:47 PM, Nick Coghlan wrote: On 7 November 2017 at 05:00, Alex Gaynor wrote: I also feel this decision was a mistake. If there's a consensus to revert, I'm happy to draft a PEP. Even without consensus to revert, I think it would be great to have a PEP

Re: [Python-Dev] Remove typing from the stdlib

On 6 November 2017 at 12:18, Nick Coghlan wrote: > That particular dependency could also be avoided by defining an > "is_class_var(annotation)" generic function and a "ClassVar" helper > object in the dataclasses module. For example: > > class _ClassVar: > def

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote: > I strongly opposed adding an ordered guarantee to regular dicts. If the > implementation happens to keep that, great. That's the worst of both worlds. The status quo is that unless we deliberately perturb the dictionary order,

Re: [Python-Dev] Partial support of a platform

On Mon, 6 Nov 2017 22:49:06 +0100 Victor Stinner wrote: > > CPython already contais 11 "#ifdef (...) __OpenBSD__" in C and 11 > sys.platform.startswith('openbsd') in Python. Supporting a "POSIX" > platform requires some changes :-) Yes... So, the question is: does

Re: [Python-Dev] Partial support of a platform

2017-11-06 23:07 GMT+01:00 Antoine Pitrou : > The reason that testing on > them is interesting, IMHO, is to chase potential Linux-isms in our code > base. Circumventing {Free,Open,Net}BSD-specific deficiences is not. Serhiy found at least an interesting issue thanks to

Re: [Python-Dev] Partial support of a platform

2017-11-06 22:16 GMT+01:00 Steve Dower : > I don't believe CPython *partially* supports any platforms - either they are > fully supported or they are not supported. Ok. So there are two questions: * Where is the list of platforms "endorsed" by CPython ("fully supported")

Re: [Python-Dev] Partial support of a platform

2017-11-06 22:24 GMT+01:00 Antoine Pitrou : > We support POSIX-compatible platforms. Do OpenBSD and NetBSD need > special care? Aha, "POSIX", you are funny Antoine :-D If it was a single #ifdef in the whole code base, I wouldn't have to start such thread on python-dev :-)

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 12:45:27 +0100 Antoine Pitrou wrote: > > I'm on the fence on this. > > I was part of the minority who opposed the original decision. So I > really appreciate your sentiment. Since then, I had to deal with a lot > of very diverse third-party libraries,

[Python-Dev] Allow annotations using basic types in the stdlib?

Hi, While discussions on the typing module are still hot, what do you think of allowing annotations in the standard libraries, but limited to a few basic types: * None * bool, int, float, complex * bytes, bytearray * str I'm not sure about container types like tuple, list, dict, set, frozenset.

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

Related to annotations, are you ok to annotate basic types in the *documentation* and/or *docstrings* of the standard library? For example, I chose to document the return type of time.time() (int) and time.time_ns() (float). It's short and I like how it's formatted. See the current rendered

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

While I appreciate the value of annotations I think that *any* addition of them to the stdlib would complicate an important learning resource unnecessarily. S Steve Holden On Mon, Nov 6, 2017 at 4:07 PM, Victor Stinner wrote: > Related to annotations, are you ok to

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Hi! Just this minute I ran across a case where I’d want DeprecationWarnings on by default (We want to rename a property in an API I’m co-developing. I has mainly scientists as target audience, so end users, not developers) Gustavo Carneiro schrieb am Mo., 6. Nov. 2017 um

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 21:58, Antoine Pitrou wrote: > I guess my takeaway point is that many situations are complicated, and > many third-party library developers are much less disciplined than what > some of us would idealistically expect them to be (those developers >

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 01:03:05PM +0200, Paul Sokolovsky wrote: > > $ time ./micropython xxx.py > > $ time ../../cpython/python xxx.py > > > > > Congratulations ... > > That's why I wrote "Python 3.3", it's hard to argue CPython doesn't do > anything about the "Python is slow" proverb. It's

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Big +1 to turning warnings on by default again. When this behaviour first started, first I was surprised, then annoyed that warnings were being suppressed. For a few years I learned to have `export PYTHONWARNINGS=default` in my .bashrc. But eventually, the warnings in 3rd-party Python modules

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote: > The ordered-ness of dicts could instead become one of those stable > CPython implementation details, such as the fact that resources are > cleaned up timely by reference counting, that people nevertheless > should not rely on if

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Tue, 7 Nov 2017 00:14:35 +1100 Steven D'Aprano wrote: > On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote: > > > The ordered-ness of dicts could instead become one of those stable > > CPython implementation details, such as the fact that resources are > >

Re: [Python-Dev] 3.5.4 doesn't appear in changelog

On Nov 6, 2017, at 13:07, Antoine Pitrou wrote: > Is there a known reason why 3.5.4 doesn't appear in the changelogs at > the bottom of https://docs.python.org/3.7/whatsnew/index.html ? > > (all releases until 3.5.3 do) As things stand now, the changelogs from maintenance

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 23:23:25 +1000 Nick Coghlan wrote: > On 6 November 2017 at 21:58, Antoine Pitrou wrote: > > I guess my takeaway point is that many situations are complicated, and > > many third-party library developers are much less disciplined than

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hi, Could be missed by me but the guarantee that dict literals are ordered implies not that dict must be ordered in all cases. The dict literal: d = {"a": 1, "b": 2} will keep the order of "a" and "b" because it is specified as a dict literal. But d["c"] = 3 can change this order and it is

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 14:30:45 +0100 Antoine Pitrou wrote: > On Tue, 7 Nov 2017 00:14:35 +1100 > Steven D'Aprano wrote: > > On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote: > > > > > The ordered-ness of dicts could instead become