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

On Jun 16, 2016, at 09:51 AM, Random832 wrote: >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: >> *If* we can guarantee that os.urandom() will never block or raise an >> exception when only poor entropy is available, then it may be indeed >> indistinguishably backwar

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

On Jun 16, 2016, at 07:34 AM, Donald Stufft wrote: >Well, I don’t think that for os.urandom someone using it for security is >running “counter to it’s original intent”, given that in general urandom’s >purpose is for cryptographic random. Someone *may* be using it for something >other than that,

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

On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote: >Regardless of what we document it as, people are going to use os.urandom for >cryptographic purposes because for everyone who doesn’t keep up on exactly >what modules are being added to Python who has any idea about cryptography at >all is going

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

On Jun 16, 2016, at 01:40 AM, Larry Hastings wrote: >As Robert Collins points out, this does change the behavior ever-so-slightly >from 3.4; Ah yes, I misunderstood Robert's point. >if urandom is initialized, and the kernel has the getrandom system call, >getrandom() will give us the bytes we

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

On Jun 16, 2016, at 12:36 AM, Nathaniel Smith wrote: >Basically this is a question of whether we should make an (unlikely) error >totally invisible to the user, and "errors should never pass silently" is >right there in the Zen of Python :-). I'd phrase it differently though. To me, it comes

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

On Jun 16, 2016, at 12:53 AM, Nathaniel Smith wrote: >> We have introduced churn. Predicting a future SO question such as "Can >> os.urandom() block on Linux?" the answer is "No in Python 3.4 and earlier, >> yes possibly in Python 3.5.0 and 3.5.1, no in Python 3.5.2 and the rest of >> the 3.5.x

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

On Jun 16, 2016, at 07:26 PM, Robert Collins wrote: >Which is a contract change. Someone testing in E.g. a chroot could have a >different device on /dev/urandom, and now they will need to intercept >syscalls for the same effect. Personally I think this is fine, but assuming >i see Barry's point

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

On Jun 15, 2016, at 11:52 PM, Larry Hastings wrote: >Well, 3.5.2 hasn't happened yet. So if you see it as still being broken, >please speak up now. In discussion with other Ubuntu developers, several salient points were raised. The documentation for os.urandom() in 3.5.2rc1 doesn't make sense:

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

On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote: >No, this is a bad idea. Asking novice developers to make security >decisions they're not yet qualified to make when it's genuinely >possible for us to do the right thing by default is the antithesis of >good security API design, and os.urandom()

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

On Jun 10, 2016, at 12:05 PM, David Mertz wrote: >OK. My understanding is that Guido ruled out introducing an os.getrandom() >API in 3.5.2. But would you be happy if that interface is added to 3.6? I would. >It feels to me like the correct spelling in 3.6 should probably be

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On Jun 09, 2016, at 05:35 PM, Neil Schemenauer wrote: >Amber Brown claimed that she spent $60k of her time porting Twisted to Python >3. I think there is lots of room to make our porting tools better. Amber gave a presentation at the language summit and a Pycon talk. The latter video is up on

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

On Jun 09, 2016, at 03:22 PM, Larry Hastings wrote: >On 06/09/2016 08:52 AM, Guido van Rossum wrote: >> That leaves direct calls to os.urandom(). I don't think this should > block >> either. > >Then it's you and me against the rest of the world ;-) FWIW, I agree with you and Guido. I'm also

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

On Jun 08, 2016, at 02:01 AM, Martin Panter wrote: >Bytes.byte() is a great idea. But what’s the point or use case of >bytearray.byte(), a mutable array of one pre-defined byte? I like Bytes.byte() too. I would guess you'd want the same method on bytearray for duck typing APIs. -Barry

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

On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >> What's wrong with b[i:i+1] ? >It always succeeds while indexing can trigger an IndexError. Right. You want a method with the semantics of __getitem__() but that returns

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

On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > ``memoryview.iterbytes`` alternative iterators +1 but I want to go just a little farther. We can't change bytes.__getitem__ but we can add another method that returns single byte

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

On Jun 06, 2016, at 01:02 PM, Łukasz Langa wrote: >There’s a problem with this approach. It will force people to write >deprecated code because you never know if your library is going to run on >3.5.0 or 3.5.1. Barry, Ubuntu wily, xenial and yakkety currently package >3.5.0 or 3.5.1. When 3.5.2

Re: [Python-Dev] Removing the provisional label from pathlib

On May 24, 2016, at 02:03 PM, Koos Zevenhoven wrote: >I guess we might consider adding __fspath__ in maintenance releases, >and make open() support it? That would cover a significant share of >use cases, although it might be weird if code written for 3.5.2 >doesn't run on 3.5.1... Please, no.

Re: [Python-Dev] File system path PEP, 3rd draft

On May 13, 2016, at 06:37 PM, Brett Cannon wrote: >PEP: NNN >Title: Adding a file system path protocol >Version: $Revision$ >Last-Modified: $Date$ >Author: Brett Cannon , >Koos Zevenhoven >Status: Draft >Type: Standards Track >Content-Type: text/x-rst

Re: [Python-Dev] Yearly PyPI breakage

On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote: >On 05/05/2016 23:22, Stefan Krah wrote >> >> Fredrik Lundh is also affected (and might not have received any mail, >> same as me): >> >> https://pypi.python.org/pypi/PIL Maybe, but then there's the friendly fork:

Re: [Python-Dev] Terminal console

On Apr 27, 2016, at 01:40 AM, Steven D'Aprano wrote: >I don't think it's just Google. If I remember correctly, having a clearly >visible and *working* unsubscribe link in the body of the email (not merely >hidden away in the headers where non-technical users would never think to >look) is a

Re: [Python-Dev] Terminal console

On Apr 26, 2016, at 09:02 AM, Paul Moore wrote: >I'm not against having an easy reminder of how to unsubscribe, but the >clickable link on every message that requests that the poster be >unsubscribed seems like the wrong way to do it, to me... And yet, we have it anyway! This list turns on full

Re: [Python-Dev] When the infamous Bier trunk hits ... where is our Python backup?

On Apr 21, 2016, at 10:43 PM, Chris Angelico wrote: >I still have no clue what you're talking about. Every project has a >leader. If Guido dies, goes insane [1], or gets bored with the Python >project, someone else can and will take over. Fortunately, the Python Secret Underground (PSU) which

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

On Apr 15, 2016, at 09:53 AM, Guido van Rossum wrote: >After a fruitful discussion on python-ideas I've decided that it's fine to >break lines *before* a binary operator. Thanks Guido, your changes look great. -Barry ___ Python-Dev mailing list

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Apr 14, 2016, at 11:17 PM, Victor Stinner wrote: >You're right that incrementing the global version is useless for these >specific cases, and using the version 0 should work. It only matters >that the version (version? version tag?) is different. > >I will play with that. If I don't see any

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Apr 14, 2016, at 09:49 PM, Victor Stinner wrote: >It would be nice to hear Barry Warsow who was opposed to the PEP in >january. He wanted to wait until FAT Python was proven to really be faster, >which is still not case right now. (I mean that I didnt't run seriously >benchmarks, but early

Re: [Python-Dev] When should pathlib stop being provisional?

On Apr 06, 2016, at 12:44 PM, Nick Coghlan wrote: >The next challenge would then be to make a list of APIs to be updated >for 3.6 to implicitly accept "rich path" objects via the agreed >convention, with pathlib.PurePath used as a test class: > >* open() >* codecs.open() (et al) >* io.* >*

Re: [Python-Dev] When should pathlib stop being provisional?

On Apr 05, 2016, at 09:29 PM, Ethan Furman wrote: >We should either remove it or make the rest of the stdlib work with it. >Currently, pathlib.*Paths are second-class citizens, and working with them is >not significantly better than working with os.path.* simply because we have >to cast to str

[Python-Dev] Accepted: PEP 493 (HTTPS verification migration tools for Python 2.7)

As BDFL-Delegate, I am officially accepting PEP 493. Congratulations Nick, Robert, and MAL. I want to personally thank Nick for taking my concerns into consideration, and re-working the PEP to resolve them. Thanks also to everyone who contributed to the discussion. Cheers, -Barry

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Feb 11, 2016, at 09:22 AM, Georg Brandl wrote: >based on the feedback so far, I revised the PEP. There is now >a much simpler rule for allowed underscores, with no exceptions. >This made the grammar simpler as well. I'd be +1, but there's something missing from the PEP: what the underscores

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Feb 11, 2016, at 05:57 PM, Georg Brandl wrote: >D'oh :) I added (hopefully) clarifying wording. I saw the diff - perfect! Thanks. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

On Feb 06, 2016, at 04:38 PM, Chris Angelico wrote: >Right, sure. The technical problems are still there. Although I'm >fairly confident that Debian's binaries would correspond to Debian's >source - but honestly, if I'm looking for sources for anything other >than the kernel, I probably want to

Re: [Python-Dev] More optimisation ideas

On Feb 01, 2016, at 11:40 AM, R. David Murray wrote: >Well, Brett said it would be optional, though perhaps the above >paragraph is asking about doing it in our Windows build. But the linux >distros might make also use the option if it exists, so the question is >very meaningful. However, you'd

Re: [Python-Dev] Fun with ancient unsupported platforms

Just as long as you can still build and run Python on Guido's ancient SGI machine . -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 07:16 PM, Victor Stinner wrote: >Barry also wrote: "Did you address my suggestion on python-ideas to >make the new C API optionally compiled in?" > >Well, it is an option, but I would prefer to have the API for AST >optimizer directly built in Python. In my plan, it would be,

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On Jan 17, 2016, at 07:10 PM, Brett Cannon wrote: >Anyone object if I update PEP 7 to remove the optionality of curly braces >in PEP 7? +1 for requiring them everywhere, -1 for a wholesale reformatting of existing code. New code and significant refactoring/rewriting can adopt braces everywhere.

Re: [Python-Dev] PEP 509: Add a private version to dict

On Jan 18, 2016, at 11:43 PM, Victor Stinner wrote: >Is someone opposed to this PEP 509? > >The main complain was the change on the public Python API, but the PEP >doesn't change the Python API anymore. > >I'm not aware of any remaining issue on this PEP. Have you done any performance analysis

Re: [Python-Dev] Boolean value of an Enum member

On Jan 15, 2016, at 10:22 AM, Ethan Furman wrote: >So the question now is: for a standard Enum (meaning no other type besides >Enum is involved) should __bool__ look to the value of the Enum member to >determine True/False, or should we always be True by default and make the >Enum creator add

Re: [Python-Dev] [Python-ideas] PEP 9 - plaintext PEP format - is officially deprecated

On Jan 11, 2016, at 03:25 PM, anatoly techtonik wrote: >On Wed, Jan 6, 2016 at 2:49 AM, Barry Warsaw <ba...@python.org> wrote: > >> reStructuredText is clearly a better format > >Can you expand on that? I use markdown everywhere reST is better than plain text. Mark

[Python-Dev] PEP 9 - plaintext PEP format - is officially deprecated

I don't think this will be at all controversial. Brett suggested, and there was no disagreement from the PEP editors, that plain text PEPs be deprecated. reStructuredText is clearly a better format, and all recent PEP submissions have been in reST for a while now anyway. I am therefore

Re: [Python-Dev] async/await behavior on multiple calls

On Dec 15, 2015, at 05:29 PM, Roy Williams wrote: >@Kevin correct, that's the point I'd like to discuss. Most other >mainstream languages that implements async/await expose the programming >model with Tasks/Futures/Promises as opposed to coroutines PEP 492 states >'Objects with __await__ method

[Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote: >I wholeheartedly agree with what Nick writes there As do I. One interesting point will be what *nix calls the /usr/bin thingie for Python 4. It would seem weird to call it /usr/bin/python3 and symlink it to say /usr/bin/python4.0 but maybe

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

On Dec 02, 2015, at 11:26 PM, Gregory P. Smith wrote: >Except that we should skip version 4 and go directly to 5 in homage to >http://www.montypython.net/scripts/HG-handgrenade.php. Five is right out. https://youtu.be/QM9Bynjh2Lk?t=3m35s -Barry pgplrHBCVtY0F.pgp Description: OpenPGP digital

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote: >New draft pushed: https://hg.python.org/peps/rev/f602a47ea795 > >This is a significant rewrite that switches the PEP to a Standards Track PEP >proposing two new features for 2.7.12+: an "ssl._verify_https_certificates()" >configuration function,

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 26, 2015, at 02:13 PM, Nick Coghlan wrote: >PEP 476 rejected providing a public indefinitely maintained API for this, so >PEP 493 is specifically about helping commercial redistributors offer a >smoother transition plan to customers without affecting the public Python >level API, and

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote: >I'm not a big fan of it either, but it's the way sustainable >commercial open source distribution works in practice: While it's inevitable that redistributors have to deviate from upstream, in Debian and Ubuntu, we really try to keep that at a

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

There's a lot to process in this thread, but as I see it, the issue breaks down to these questions: * How should PEP 493 be implemented? * What should the default be? * How should PEP 493 be worded to express the right tone to redistributors? Let me take on the implementation details here. On

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 24, 2015, at 09:16 AM, Toshio Kuratomi wrote: >It sounds like the implementation sections of the PEP are acceptable Well, see my follow up to MAL's email. From Rob's and RDM's responses, it seems we're not alone. :) I like all your other proposed changes, although I'll note the

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 24, 2015, at 02:12 PM, Nick Coghlan wrote: >On 24 November 2015 at 11:59, Barry Warsaw <ba...@python.org> wrote: >> We'd have to also handle >> migration paths to newer Ubuntu releases, which probably means removing the >> config file on future upgrades. > &g

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 25, 2015, at 03:39 PM, R. David Murray wrote: >I think we should include the environment variable support in CPython >and be done with it (nuke the PEP otherwise). Which is what I've >thought from the beginning :) +1. I'd like to see my proposed convenience function added too. I'm -0

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote: >Since we already know Red Hat are OK with the draft recommendations, >and I missed the RHEL 7.2 release date anyway, perhaps Barry or >Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable >release update windmill? I know there

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote: >For Debian, Ubuntu and SUSE, their original determinations for the >relevant CVE were "too intrusive to backport", so folks currently need >to upgrade to newer versions of those distros to get the improved >default behaviour: This is an example

Re: [Python-Dev] Clarification of PEP 394 for scripts that run under Python 2 and 3

On Nov 13, 2015, at 10:32 PM, Damien George wrote: >1. What is the true intent of PEP 394 when only Python 3 is installed? Is >"python" available or not to run scripts compatible with 2.x and 3.x? > >2. Is it possible to write a shebang line that supports all variations of >Python installations

Re: [Python-Dev] PYC filename and optimization

On Nov 05, 2015, at 11:33 AM, Victor Stinner wrote: >- Lib/__pycache__/os.cpython-36.pyc: default mode >- Lib/__pycache__/os.cpython-36.fat-0.pyc: FAT mode > >With -O: > >- Lib/__pycache__/os.cpython-36.opt-1.pyc: default mode >- Lib/__pycache__/os.cpython-36.fat-1.pyc: FAT mode > > >With -OO: >

Re: [Python-Dev] Bytcode "magic tag"

On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote: >The "following table" is a comment, that contains a few references to >the tag "cpython-", specifically cpython-32. It doesn't seem >that the tag is routinely updated in the comment. IIRC, it used to have to be changed in the code, but with

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

On Oct 02, 2015, at 11:46 AM, Victor Stinner wrote: >Should I write a PEP for a new field in sys.implementation? Specifically PEP 421 says that a PEP is needed if the new sys.implementation attribute is required to be defined in all implementations, i.e. it's a new required attribute. Will

Re: [Python-Dev] Migrating to Python 3: the python 3 install issue

On Oct 03, 2015, at 01:05 AM, Victor Stinner wrote: >Ubuntu is also working on a similar change. I don't know when it will happen. For the desktop, we're aiming for 16.04 LTS. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP acceptance and SIGs

On Sep 30, 2015, at 09:14 PM, Alexander Belopolsky wrote: >When I faced a similar situation with PEP 495, Guido's advise was "I think >that a courtesy message to python-dev is appropriate, with a link to the >PEP and an invitation to discuss its merits on datetime-sig." [1] Certainly

[Python-Dev] Washington DC Python sprint report

Yesterday (27-Sep-2015), four Washington DC area Python developers got together for a local Python hacking sprint. Andrew, Eric, Jason, and I were joined remotely by the esteemed R. David Murray. We did stuff and had fun! We hope to do stuff and have fun again! If you want to join us for stuff

Re: [Python-Dev] Washington DC Python sprint report

On Sep 28, 2015, at 02:38 PM, Guido van Rossum wrote: >Your comments make total sense -- we're just short on people who can write >that kind of docs. :-( Oh well, maybe someday we will! ;) -Barry pgpGVDxk58hN8.pgp Description: OpenPGP digital signature

Re: [Python-Dev] Washington DC Python sprint report

On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote: >I saw that you had a need for an asyncio tutorial. I wonder if the "500 >lines" chapter on asyncio would help? I didn't write it; I only write the >500 lines of code, A. Jesse Jiryu Davis wrote the text, and it's wonderful:

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote: >I currently use pyvenv directly, but I agree with starting a migration >to only supporting the more explicit "python -m venv". There's always >an inherent ambiguity on *nix with unqualified version sensitive >Python commands as to whether they're

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote: >I propose that the pyvenv script be deprecated in Python 3.5.1 and >removed in Python 3.8. The reason for this proposal is because it is >non-obvious what version of Python a pyvenv command is tied to (heck, >it isn't necessarily obvious that

Re: [Python-Dev] PEP: Collecting information about git

On Sep 16, 2015, at 09:34 AM, R. David Murray wrote: >My experience with DVCS started with bazaar, moved on to hg for the >CPython project, and finally git. Through all of that I did not >understand the DAG, and had trouble wrapping my mind around what was >going on, despite being able to get

Re: [Python-Dev] PEP: Collecting information about git

On Sep 12, 2015, at 03:54 PM, Oleg Broytman wrote: >This Informational PEP collects information about git. There is, of course, a >lot of documentation for git, so the PEP concentrates on more complex (and >more related to Python development) issues, scenarios and examples. Thanks for this Oleg.

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

On Sep 08, 2015, at 10:02 AM, Guido van Rossum wrote: >#2 sounds fine to me. Agreed. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 04, 2015, at 08:01 PM, Guido van Rossum wrote: >And I'm ready to accept it. As I've mentioned to Eric, I think it's a great PEP, so congratulations on getting one through The Gauntlet. I know that in my own code, I'm looking forward to using it in however many years it takes for 3.6 to

Re: [Python-Dev] PEPs and PEP 8 changes

On Sep 05, 2015, at 03:57 PM, Jim J. Jewett wrote: >Would it be reasonable to ask PEPs to start including a section on any >recommended changes to PEP8? (e.g., "If an embedded expression >doesn't fit on a single line, factor it out to a named variable.") Yes, I think it's reasonable to

[Python-Dev] Compiler hints to control how f-strings are construed

On Aug 17, 2015, at 01:36 PM, Guido van Rossum wrote: 1. Barry wants the substitutions to look like $identifier and possibly ${identifier}, and the PEP 498 proposal just uses {}. 2. There needs to be a way to identify interpolated strings and i18n strings, and possibly combinations of those.

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 17, 2015, at 11:02 AM, Paul Moore wrote: print(fIteration {n}: Took {end-start) seconds) This illustrates (more) problems I have with arbitrary expressions. First, you've actually made a typo there; it should be {end-start} -- notice the trailing curly brace. Second, what if you

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote: The linters could tell you that you have no 'end' or 'start' just as easily when it's in that form as when it's written out in full. Certainly the mismatched brackets could easily be caught by any sort of syntax highlighter. The rules for

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015, at 11:05 PM, ISAAC J SCHWABACHER wrote: code.putlines(f static char {entry.doc_cname}[] = { split_string_literal(escape_bytestring(docstr))}; { # nested! f #if CYTHON_COMPILING_IN_CPYTHON struct wrapperbase {entry.wrapperbase_cname}; #endif if entry.is_special else ''}

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: I think I would be happy with f-strings, or perhaps i-strings if we use Nick's ideas about internationalisation, and limit what they can evaluate to name lookups, attribute lookups, and indexing, just like format(). I still think you really

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015, at 02:49 PM, Eric V. Smith wrote: It's possible. But my point is that Barry doesn't even want attribute/item getters for an i18n solution, and I'm not willing to restrict it that much. Actually, attribute chasing is generally fine, and flufl.i18n supports that. Translators can

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 09, 2015, at 06:14 PM, David Mertz wrote: That said, there *is* one small corner where I believe f-strings add something helpful to the language. There is no really concise way to spell: collections.ChainMap(locals(), globals(), __builtins__.__dict__). If we could spell that as, say

Re: [Python-Dev] How far to go with user-friendliness

On Jul 14, 2015, at 02:06 PM, Dima Tisnek wrote: Michael and Kushal are of the opinion that assret is a common typo of assert and should be supported in a sense that it also triggers AttributeError and is not silently ignored like a mocked user attribute. It's seems like a dubious special case.

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On Jul 09, 2015, at 08:47 PM, Nick Coghlan wrote: That strikes me as just the kind of not-quite-as-finished-as-we-thought case that the beta cycle is designed to flush out, so the minor further enhancement sounds like a good idea to me. Cool. RDM provided some good feedback in the review, so

[Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

Larry and others, I'd like to bring your attention to issue #15014. This issue added arbitrary auth methods to smtplib, which is a good thing. Implicitly though, a regression was introduced w.r.t. RFC 4954's optional initial-response for the AUTH command, for authentication methods that support

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote: To me, the main question is whether you are sure that your proposal is the right fix, or whether you might reasonably do something different (with the new arguments) if changes were reverted for the present and you two took more time to think about

Re: [Python-Dev] What's New editing

On Jul 06, 2015, at 09:32 PM, Raymond Hettinger wrote: FWIW, it took me 100+ hours. Doing this right is a non-trivial undertaking (in modern times, there are an astonishing number of changes per release). That said, it is rewarding work that makes a difference. Indeed. During distro Python

[Python-Dev] Getting ready for Python 3.5

[Apologies for the cross-posting! -BAW] For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default Python 3 version. It's currently undecided whether we will keep Python 3.4 as a supported version, but a lot of that depends on how easily an archive port to Python 3.5 goes.

Re: [Python-Dev] RM for 3.6?

On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Cheers, -Barry pgpArSFCqg7XM.pgp Description: OpenPGP digital signature

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On May 30, 2015, at 06:55 PM, Nick Coghlan wrote: Intel are looking to get involved in CPython core development *specifically* to work on performance improvements, so it's important to offer folks in the community good reasons for why we're OK with seeing at least some of that work applied to

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On May 29, 2015, at 04:04 PM, Guido van Rossum wrote: There are a fair number of people on this thread whose employer pays them to work on Python. My guess is that as Python 2.7 gets longer in the tooth, and it becomes harder to motivate volunteers to shepherd contributed patches into Python 2,

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

On May 28, 2015, at 11:48 PM, Matthias Klose wrote: And the very same place where you are working is investing in getting shared libraries working for Go. Single binaries may be popular for distributing end user applications, but definitely not for distributing a core OS or a SDK. Yep, I

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 28, 2015, at 12:44 PM, Donald Stufft wrote: Pex would be improved by having native support for importing .so’s from within a zipfile via zipimport. It would also be improved by having good, built in support for extraneous resources in the stdlib too. Completely agree on both points.

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 28, 2015, at 09:23 AM, Chris Barker wrote: Barry Warsaw wrote: I do think single-file executables are an important piece to Python's long-term competitiveness. Really? It seems to me that desktop development is dying. What are the critical use-cases for a single file executable? And I'd

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 28, 2015, at 11:39 AM, Donald Stufft wrote: You don’t need a fully functioning Python for a single file binary, you only need enough to actually run your application. For example, if you're making an application that can download files over HTTP, you don't need to include parts of the

[Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

Go seems to be popular where I work. It is replacing Python in a number of places, although Python (and especially Python 3) is still a very important part of our language toolbox. There are several reasons why Go is gaining popularity. Single-file executables is definitely a reason; it makes

Re: [Python-Dev] Preserving the definition order of class namespaces.

On May 27, 2015, at 06:34 PM, Nick Coghlan wrote: I'd actually like to pursue a more nuanced view of what's permitted in maintenance releases, based on a combination of the language moratorium PEP, and an approach inspired by PEP 466, requiring that every feature added in a maintenance release be

[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

On May 27, 2015, at 05:15 PM, Terry Reedy wrote: How about a feature release once a year, on a schedule we choose as best for us. We discussed timed releases ages ago and they were rejected by the majority. Time-based releases can make a lot of sense, especially if the interval is short enough.

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On May 12, 2015, at 10:38 AM, Larry Hastings wrote: It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings

Re: [Python-Dev] A macro for easier rich comparisons

On Apr 28, 2015, at 11:13 AM, Victor Stinner wrote: It would be nice to have a six module for C extensions. I'm quite sure that many projects are already full of #ifdef PYTHON3 ... #else ... #endif macros. Maybe encapsulating some of the recommendations here:

Re: [Python-Dev] async/await in Python; v2

On Apr 24, 2015, at 08:03 PM, Greg Ewing wrote: Putting it at the end would seem least likely to cause breakage: def useful() async: That's not bad IMHO. I wonder how crazy it is in the face of, ahem, function annotations. Cheers, -Barry ___

Re: [Python-Dev] async/await in Python; v2

On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote: It seems to me that tools that search for r^\s*def\s+spam\s*\( are They would likely search for something like r^\s*def\s+[a-zA-Z0-9_]+ which will hit def async spam but not async def. Cheers, -Barry

Re: [Python-Dev] async/await in Python; v2

On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote: To my eye 'async def name()', 'async with', 'async for' look better than 'def async name()', 'with async' and 'for async'. But that's highly subjective. Would you be willing to add this as an alternative to the PEP, under the Why async def

Re: [Python-Dev] async/await in Python; v2

On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote: The updated version of the PEP should be available shortly at https://www.python.org/dev/peps/pep-0492 and is also pasted in this email. There's a lot to like about PEP 492. I only want to mildly bikeshed a bit on the proposed new syntax. Why

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Apr 21, 2015, at 01:34 PM, Steven D'Aprano wrote: Putting the type information in a stub file is an exponentially more distant fourth best, or to put it another way, *the worst* solution for where to put type hints. Not only do you Repeat Yourself with the name of the parameter, but also the

Re: [Python-Dev] Surely nullable is a reasonable name?

On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote: We should rename types to accept. accept should takes a set of types; these types specify the types of Python objects the Clinic parameter should accept. For the funny pseudo-types needed in some Clinic declarations (buffer, robuffer, and

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Apr 20, 2015, at 07:30 PM, Harry Percival wrote: tldr; type hints in python source are scary. Would reserving them for stub files be better? I think so. I think PEP 8 should require stub files for stdlib modules and strongly encourage them for 3rd party code. Cheers, -Barry

Re: [Python-Dev] PEP 8 update

On Apr 06, 2015, at 06:08 PM, Guido van Rossum wrote: I've taken the liberty of adding the following old but good rule to PEP 8 (I was surprised to find it wasn't already there since I've lived by this for ages): Be consistent in return statements. Either all return statements in a

<    1   2   3   4   5   6   7   8   9   10   >