[Python-Dev] Python 2.6.9 final final due out 28 October 2013

This is a reminder that Python 2.6.9 final - and by that I mean *really* final as it will be the last supported version of Python 2.6 - is scheduled for release one week from today, on October 28, 2013. All known showstopper security bugs have been applied to the branch. If you know of anything t

Re: [Python-Dev] Hashes on same site as download?

On Oct 21, 2013, at 06:21 PM, Dan Stromberg wrote: >I may be missing something, but it seems the Python tarballs and hashes are >on the same host, and this is not an entirely good thing for security. All the tarballs are signed with the GPG keys of the release managers. The hashes are just a qui

Re: [Python-Dev] OS X 10.9 Mavericks -> 2.7.6/3.3.3 updates needed

On Oct 24, 2013, at 02:11 AM, Ned Deily wrote: >I don't know where any other potential 2.7.6 or 3.3.3 issues stand at this >point. But I'd like Benjamin and Georg to propose an aggressive schedule so >we can get these fixes out there. Does this problem affect 2.6? 2.6.9 final is scheduled for

Re: [Python-Dev] 2.6.9 readline [Was: OS X 10.9 Mavericks -> 2.7.6/3.3.3 updates needed]

On Oct 24, 2013, at 01:12 PM, Ned Deily wrote: >Yes, this problem also affects 2.6. There are some mitigating factors. The >support for libedit on OS X is only enabled when building for an OS X 10.5 or >later ABI because in earlier releases, the readline emulation of libedit was >judged too b

Re: [Python-Dev] 2.6.9 readline [Was: OS X 10.9 Mavericks -> 2.7.6/3.3.3 updates needed]

On Oct 25, 2013, at 07:54 AM, Nick Coghlan wrote: >Since the default build settings work, that sounds reasonable. Perhaps >include a note somewhere that targeting a more recent ABI may involve >copying the 2.7 readline.c? I'll probably add issue 18458 to the announcement and release page. That w

[Python-Dev] RELEASED: Python 2.6.9 final

Hello Pythoneers and Pythonistas, Five years ago this month, we released Python 2.6. It was an important version in Python's evolution, as it was developed in tandem with Python 3.0 and had the express intent of starting the transition toward Python 3. Amazingly, here we are five years later, an

Re: [Python-Dev] python2 and python3 and vim

On Nov 04, 2013, at 08:04 AM, Nick Coghlan wrote: >Since making it work would be a lot of work for minimal benefit, the most >that could realistically be done is to make it fail a little more >gracefully (I believe that would need to be done on the Vim side of things, >though). Right. I can't re

Re: [Python-Dev] Simplify and unify SSL verification

On Nov 07, 2013, at 10:42 PM, Christian Heimes wrote: >You misunderstood me. I'm not proposing a global SSLContext object but a >factory function that creates a context for Python stdlib modules. Right >now every urllib, http.client, nntplib, asyncio, ftplib, poplib and >imaplib have duplicated co

Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted

On Nov 08, 2013, at 12:49 PM, Eric Snow wrote: >I'm pleased to announce that Brett Cannon and Nick Coghlan (the >co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. >Both of them have contributed substantially to the discussions of the >proposal and have helped make it solid. I'

Re: [Python-Dev] Is pygettext.py deprecated?

On Nov 11, 2013, at 04:30 PM, A.M. Kuchling wrote: >Do we want to deprecate pygettext.py? If so, we should rewrite >http://docs.python.org/3/library/gettext.html, which encourages people >to use pygettext, and add it to PEP4. I think we should deprecate it. If we find things that xgettext can't

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote: >2013/11/16 Maciej Fijalkowski : >> Can I see some writeup how -OO benefit embedded devices? > >You get smaller .pyc files. In an embedded device, the whole OS may be >written in a small memory, something like 64 MB or smaller. Removing >doctring

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

On Nov 17, 2013, at 11:05 PM, Maciej Fijalkowski wrote: >My problem with -O and -OO is that their arguments are very circular. >Indeed, I understand the need why you would want in certain and >limited cases to remove both docstrings and asserts. So some options >for doing so are ok. But a lot of a

Re: [Python-Dev] PEP 0404 and VS 2010

On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote: >Many customers are forced to stick with Python 2.X because of other products, >but they require a Python 2.X version which can be compiled using Visual >Studio 2010 or better. This is considered an improvement and not a bug fix, >where I disa

Re: [Python-Dev] PEP 0404 and VS 2010

On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote: >As usual, 'I am not a lawyer', but if Christian wants to push forward with >using 'Python 2.8', I suggest that he consult the PSF Trademark Committee and >lawyer first. Just to make clear, I'm definitely *not* suggesting this particular case ever

Re: [Python-Dev] PEP 0404 and VS 2010

On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote: >Oh, this is the misunderstanding. No one is trying to get permission for >"CPython 2.8", only "Stackless Python 2.8". I think this is a very bad idea. We've worked hard to send the message that the migration path is to Python 3 and wh

Re: [Python-Dev] [Python-checkins] peps: Update list of accepted but not yet implemented or merged peps.

On Nov 22, 2013, at 02:04 AM, Victor Stinner wrote: >Hum, I don't think that regex module will enter Python 3.4 before this >week-end, there is no PEP. Okay thanks, I'll remove this from PEP 429. >For the "Introspection information for builtins", I think the PEP 436 >has been accepted. The code

Re: [Python-Dev] PEP 0404 and VS 2010

On Nov 22, 2013, at 03:55 PM, Antoine Pitrou wrote: >(perhaps Barry will play a bass solo? :-)) Now, now, we don't want to give Chris incentive, do we? :) -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo

Re: [Python-Dev] can someone create a buildbot slave name & password for me?

On Nov 23, 2013, at 10:34 AM, Gregory P. Smith wrote: >I've got a nice ARM box to add to the pool (it should be a lot faster and >more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). Once that's up, let me know. I'd like to eventually retire this box. It's unsupported hard

Re: [Python-Dev] buildbot's are needlessly compiling -O0

On Nov 23, 2013, at 11:13 PM, Gregory P. Smith wrote: >our buildbots are setup to configure --with-pydebug which also >unfortunately causes them to compile with -O0... this results in a python >binary that is excruciatingly slow and makes the entire test suite run take >a long time. It would be f

Re: [Python-Dev] can someone create a buildbot slave name & password for me?

On Nov 23, 2013, at 11:01 PM, Gregory P. Smith wrote: >http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l Cool thanks. Antoine, do you still want or need my buildbot, or can I take it off-line? (FWIW, because the hardware is no longer supported, it's pretty much stuck at Ubunt

Re: [Python-Dev] can someone create a buildbot slave name & password for me?

On Nov 24, 2013, at 06:02 PM, Antoine Pitrou wrote: >If the hardware is not supported anymore, and since the machine was >rather slow, I agree it's ok to let it go. Done! (The machine's name was 'hope', so now we're hope-less :). -Barry ___ Python-Dev

Re: [Python-Dev] Sort error in Misc/ACKS

On Dec 09, 2013, at 04:00 PM, TaeWong wrote: >The name Jonas Wagner comes before Zachary Ware and Barry Warsaw. Maybe it's time to give up on trying to sort by last name, and just sort by first character? No, this is not a bold attempt to jump higher up in the list. -AAA

Re: [Python-Dev] Backward-incompatible change to random.randrange in 2.7.6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Dec 17, 2013, at 01:18 PM, Tres Seaver wrote: >http://hg.python.org/cpython/rev/b1e94e332ec8 > >Do we really want to change an undocumented-but-effectively-public API in >a late-in-the-release-cycle third dot release? It caused, ZODB's tests >to

Re: [Python-Dev] Changing Clinic's output

On Jan 07, 2014, at 08:53 PM, Antoine Pitrou wrote: >- move all generated code to separate C files, which would then be > #included'd into the main module file I'm not a big fan of this approach either, but maybe not as vehemently, so -0. >- gather all generated code to a single place in the C

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote: >Very nice, thanks. If I was to make a blasphemous suggestion I would >even target it for Python 3.4. (No, seriously, this is a big issue >- see the recent discussion by Armin - and the big names involved show >that it is a major holdup of 3.x up

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Jan 07, 2014, at 11:13 AM, Victor Stinner wrote: >Twisted and Mercurial don't support Python 3. > >(I heard that Twisted Core supports Python 3, but I don't know if it's >true nor the Python 3 version.) Parts of Twisted do run on Python 3 (and are even available in Ubuntu), but if PEP 460 help

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Jan 07, 2014, at 05:16 AM, Donald Stufft wrote: >Given the low adoption rates for Python 3 it would not surprise me if people >who are hampered by the lack of this change are willing to wait until a Python >version is released that has it. If that means waiting until 3.5, then I disagree. The

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote: >On Tue, 7 Jan 2014 15:46:50 -0500 >Barry Warsaw wrote: >> >> If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think >> I'd still like to see the following excluded and unknown features adde

Re: [Python-Dev] Changing Clinic's output

On Jan 07, 2014, at 10:39 PM, Serhiy Storchaka wrote: >Only this option will solve all my issues. How hard would it be to put together some sample branches that provide concrete examples of the various options? My own opinion could easily be influenced by having some hands-on time with actual co

[Python-Dev] A test case for what's missing in Python 3 (Re: RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5)

(Resending with an adjusted Subject and not through Gmane. Apologies for duplicates.) On Jan 08, 2014, at 01:51 PM, Stephen J. Turnbull wrote: >Benjamin Peterson writes: > > > I agree. This is a very important, much-requested feature for low-level > > networking code. > >I hear it's much-request

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Jan 08, 2014, at 01:51 PM, Stephen J. Turnbull wrote: >Benjamin Peterson writes: > > > I agree. This is a very important, much-requested feature for low-level > > networking code. > >I hear it's much-requested, but is there any description of typical >use cases? The two unported libraries that

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

On Jan 11, 2014, at 10:38 AM, Ethan Furman wrote: >You've already stated you don't care that much and are willing to let the PEP >as-is be rejected. Why not remove your name and let Victor have it back? Is >he not the original author? (If this is protocol just say so -- remember I'm >still new

Re: [Python-Dev] PEP 460 reboot

On Jan 12, 2014, at 06:11 PM, Guido van Rossum wrote: >Perhaps not, but it's a hint that you should probably think about an >encoding. It's symmetric with how '%s' % b'x' returns "b'x'". Think of >it as payback time. :-) Which unfortunately causes no end of headaches, often difficult to debug. h

Re: [Python-Dev] PEP 460 reboot

On Jan 12, 2014, at 09:45 PM, Glenn Linderman wrote: >Quotes in the stream are a great debug hint, without blowing up. They actually terrible for debugging for exactly the same reason as coercion in Python 2. It's rarely what you really want, it silently succeeds, and it means that the user visi

Re: [Python-Dev] PEP 460 reboot

On Jan 13, 2014, at 02:13 PM, Donald Stufft wrote: > >On Jan 13, 2014, at 1:58 PM, Guido van Rossum wrote: > >> I hear the objections against b'%s' % 'x' returning b"'x'" loud and >> clear, and if the noise about that sub-issue is preventing folks from >> seeing the absurdity in PEP 460, we can t

Re: [Python-Dev] PEP 460 reboot

On Jan 14, 2014, at 10:52 AM, Guido van Rossum wrote: >Which reminds me. Quite a few people have spoken out in favor of loud >failures rather than silent "wrong" output. But I think that in the >specific context of formatting output, there is a long and IMO good >tradition of producing (slightly)

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: >I would rephrase it to "switch to %-formatting for bytes usage for their >common code base". -1. %-formatting is so neanderthal. :) -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mai

Re: [Python-Dev] .clinic.c vs .c.clinic

On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: >Contestant 5: "Put in __clinic__ directory, add .h" > >foo.c -> __clinic__/foo.c.h >foo.h -> __clinic__/foo.h.h This is cached output right? IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycac

Re: [Python-Dev] Python 3.4, marshal dumps slower (version 3 protocol)

On Jan 28, 2014, at 09:17 AM, tds...@gmail.com wrote: >yes I know the main usage is to generate pyc files. But marshal is also used >for other stuff and is the fastest built in serialization method. For some >use cases it makes sense to use it instead of pickle or others. And people >use it not on

Re: [Python-Dev] The docstring hack for signature information has to go

On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote: >But that only fixes part of the problem. Our theoretical extension that >wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can >they support signatures? They can't give PyMethodDefEx structures to 3.3, it >will blow up.

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On Feb 18, 2014, at 08:25 AM, Nick Coghlan wrote: >Thanks, that's enough to persuade me that it is a good idea to restore that >behaviour (and make it an official part of the language spec) as part of >the "eliminate remaining barriers to migration from Python 2" effort in 3.5. At the very least,

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: >Am 17.02.2014 00:25, schrieb Larry Hastings: >> And my local branch will remain private until 3.4.0 final ships! > >sorry, but this is so wrong. Is there *any* reason why to keep this branch >private? IMO, no. read-only for !larry sure, but no

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote: >That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, >everyone *will* have a chance to test it. What value is a preview of the >preview really going to add? Give Larry some trust and freedom to do things >in the way that ma

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote: >But should Ubuntu desires be distorting a volunteer RE's process? Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think if we can hit t

Re: [Python-Dev] cherry pick a change to Enum

On Feb 21, 2014, at 12:36 AM, Ethan Furman wrote: >If not, should we put the change in RC2 / Final? The main reason I'm pushing >for this is that Enum is still new, but after 3.4.0 is cut we then have to >deal with backwards compatibility issues. I concur this should be cherry picked. Let's not

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

On Feb 25, 2014, at 03:03 PM, Maciej Fijalkowski wrote: >Oh, I thought security fixes go to all python releases. Well, not the EOL'd ones of course. Where's the analysis on backporting SIPHash to older Python versions? Would such a backport break backward compatibility? What other impacts woul

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote: >With the new macro in place, the existing Py_CLEAR(x) macro would be >equivalent to Py_SETREF(x, NULL). > >Originally I was also concerned about the "how will people know there's no >implicit incref?", but I've since become satisfied with the fact

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote: >It *is* playing refcounting games - it's decrefing the existing target >while stealing a reference to the new target, just like the existing >SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's >more obvious that we will never

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On Mar 03, 2014, at 10:36 PM, Mark Lawrence wrote: >Will this impact on the decision http://bugs.python.org/issue20846 ? Issue 20808 is my own pet cherry pick for 3.4. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On Mar 05, 2014, at 09:24 AM, Nick Coghlan wrote: >I think it's also the fact that new feature releases are rare and changes >of release manager even more so, meaning there's a fair bit of relearning >involved every time (since what was appropriate a couple of years earlier >may not be appropriate

Re: [Python-Dev] Python 3.4 change in importlib/__init__.py breaking cxFreeze?

On Mar 10, 2014, at 11:25 PM, Nick Coghlan wrote: >__file__ is expected to always be set (including when loaded from a zipfile Actually, __file__ is an optional attribute on modules since PEP 420 and Python 3.2. It's *usually* there, but unlike in previous version of Python, if the module doesn'

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mar 10, 2014, at 02:55 PM, Victor Stinner wrote: >So can we please try to stop scheduling another major Python version >breaking almost all modules and all applications just to be pendantic? > >What do you think? Just that it's crazy to be talking about Python 4 right now. We have at least 9

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote: >> I don't see any reason to bump >> the major version number until after Python 3.9. > >Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Guido famously hates two digit minor version numbers. :) -Barry

Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On Mar 12, 2014, at 11:14 AM, Brett Cannon wrote: >While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a >colon in an expression. I'm -0 on the idea, mostly be cause it's never occurred to me to even need something like this, and because I don't personally think the existing

Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On Mar 12, 2014, at 10:40 AM, Ethan Furman wrote: >Does this mean a better motivation and rationale may cause you to change your >mind? > >My motivation is for simpler, easier to read code: instead of a full-blown >try/except block or a double-lookup into an indexable object I would much >rather d

Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On Mar 13, 2014, at 10:15 AM, Victor Stinner wrote: >It's hard to accept that a wonderful idea at a first look is not a >good idea. Some months later, I now agree and see issues of my PEPs. >The PEP process ensures that the Python "language" (+ stdlib) keeps >consistent and well designed. > >Even

Re: [Python-Dev] PEP URLs

On Mar 14, 2014, at 04:48 PM, Nick Coghlan wrote: >I opened https://github.com/python/pythondotorg/issues/297 to ask for >an ETA on when we can expect them to be fully integrated. Thanks Nick. On the bug I suggest creating peps.python.org. -Barry signature.asc Description: PGP signature _

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On Mar 18, 2014, at 08:29 PM, Serhiy Storchaka wrote: >Poll results: > >Py_(X)SETREF: +3 (Antoine, Kristján, Nick) +1 -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://m

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote: >But enforcing "secure by default" can by construction break backwards >compatibility, which is the very reason we are so conservative with >such changes. Also, many developers who are stuck on Python 2 have already evaluated, designed, and impl

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote: >I'm unclear how this would be better than just biting the bullet and >making a 2.8 release. On the one hand, the 2.7.x number suggests >(based on the existing release protocol) that it should be a drop-in >replacement for earlier 2.7 micro relea

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote: >Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the >standard lib. Then you can go back to the standard 2.7 (if you want >to) by unsetting PYTHONPATH. > >It'd be nice if SEPython defined a modified sys.version for clarity, >but

Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7

On Mar 25, 2014, at 06:11 PM, Nick Coghlan wrote: >I actually agree with this (hence why I wrote the PEP in the first >place), I just became really, really, really, annoyed with certain >organisations over the course of writing the PEP drafts and that is >reflected in the tone of the latest draft.

Re: [Python-Dev] PEP 466 (round 5): selected network security enhancements for Python 2.7

On Mar 26, 2014, at 10:00 PM, Nick Coghlan wrote: >Guido and Antoine persuaded me that selective backports would be a >better idea for the network security enhancements than the wholesale >module backports previously suggested, while Alex and Donald provided >the necessary additional details, so h

Re: [Python-Dev] collections.sortedtree

On Mar 26, 2014, at 01:55 PM, Benjamin Peterson wrote: >It's not a bad idea. (I believe others have proposed an red-black tree.) >Certainly, it requires a PEP and a few months of bikesheding, though. Generally, PEPs aren't necessary for simple or relatively uncontroversial additions to existing m

Re: [Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

On Mar 26, 2014, at 02:27 PM, Benjamin Peterson wrote: >I would have said that, too, several years ago, but I think we've been >requiring (or using anyway) PEPs for a lot more things now. OrderedDict >had a PEP for example. > >I'm not sure if that's a good thing or not. Hmm, me neither! I guess

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote: >Python used to have an alias <> for != and I for one miss <> in 3.x. I >don't think TOOWTDI should be the last word in this debate. PEP 401 to the rescue: % python3 Python 3.4.0 (default, Mar 22 2014, 22:51:25) [GCC 4.8.2] on linux Typ

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Apr 07, 2014, at 06:06 PM, Benjamin Peterson wrote: >> > It occurs to me that since that Aprils' Fools joke is many years old >> > now, we should remove it. >> >> -1 on removal. > >You can't be serious. Hey man, don't break all my code! -Barry __

Re: [Python-Dev] stupid jokes (was PEP 465: A dedicated infix operator for matrix multiplication)

On Apr 07, 2014, at 06:13 PM, Benjamin Peterson wrote: >On Mon, Apr 7, 2014, at 18:11, Barry Warsaw wrote: >> On Apr 07, 2014, at 06:06 PM, Benjamin Peterson wrote: >> >> >> > It occurs to me that since that Aprils' Fools joke is many years old >> >&

Re: [Python-Dev] Language Summit notes

On Apr 10, 2014, at 12:34 PM, Eli Bendersky wrote: >There's absolutely no reason to exempt CFFI, IMHO. On the contrary -- the >dependence on other 3rd party modules (PLY and pycparesr), and the related >dilemma of whether to expose each/both as stdlib modules or hide as >internal implementation de

Re: [Python-Dev] Python "2migr8"

On Apr 15, 2014, at 10:55 PM, Steve Dower wrote: >Really, I'd expect the name to be pretty boring - "Python Straddle", "Python >2 Strict" or "Python Migration Edition" (if anyone can live with Python ME >;-) ) We often call code that works in both Python 2 and 3 from a single source "bi-lingual".

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Apr 19, 2014, at 02:12 PM, Giampaolo Rodola' wrote: >I don't see this as a key porting hassle *at all* and I don't understand >why they think this would significantly help their porting (it wouldn't). >The only real barrier is the str/bytes conversion, really, and this is even >more true for pr

Re: [Python-Dev] pep8 reasoning

On Apr 24, 2014, at 08:18 AM, Chris Withers wrote: >I'm having a tough time persuading some people of the benefits of pep8, >particularly when it comes to applying to an existing large code base. First of all, the purposes of PEP 8 is not to impose mandates of style on your colleagues. :) Two im

Re: [Python-Dev] pep8 reasoning

On Apr 24, 2014, at 06:51 PM, Tal Einat wrote: >I speak two languages as mother tongues - English and Hebrew. Hebrew >has no capital letters (and is also right-to-left) and is the spoken >and written language in the parts of Israel where I've lived most of >my life. Perhaps because of this, I do f

Re: [Python-Dev] pep8 reasoning

On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: >Don't forget that PEP 8 is not the standard for the Python language, >only the Python stdlib. Particularly, there's no strong reason to >follow some of its lesser advices (eg spaces rather than tabs, the >exact maximum line length) for new proje

Re: [Python-Dev] pep8 reasoning

On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote: >And from *outside* of your organization, it's a no-brainer. PEP 8 is >what Python itself and most 3rd party OSS modules use. Getting your >people to use PEP 8 will make it a lot easier for them to learn to >read Python core and stdlib cod

Re: [Python-Dev] pep8 reasoning

On Apr 26, 2014, at 12:33 AM, Janzert wrote: >So the one example under discussion is: >foo = long_function_name( > var_one, var_two, > var_three, var_four) > >and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation > >Specifically the third example with a heading of "Optional".

Re: [Python-Dev] pep8 reasoning

On Apr 27, 2014, at 12:34 PM, Chris Barker wrote: >wow! just looked at that part of the PEP again, and that is a LOT of >options. Is it impossible to come to any consensus on this? And as it >happens, my favorite is not in there, though as far as I can tell not >forbidden: > >foo = long_function_n

Re: [Python-Dev] pep8 reasoning

On Apr 28, 2014, at 11:12 AM, Chris Barker wrote: >No -- stupid variable-width font! > >I don't think anyone should write code with variable width fonts, and I'd >rather not do email that way either, but gmail is making it tough these >days.. Ouch. I'm sure it's gmail being "helpful" the way

Re: [Python-Dev] Where is our official policy of what platforms we do support?

On May 14, 2014, at 02:20 PM, Brett Cannon wrote: >Do we want an official policy written down in a PEP (yes, I can write it)? >Should I keep closing these patches and saying that we are not adding >support for new operating systems and be hand-wavy about it? Yes, I think a PEP describing both pol

Re: [Python-Dev] Download Counts (was: Language Summit notes)

On May 29, 2014, at 07:37 AM, Chris Angelico wrote: >Debian Testing (Jessie) ships both 3.3 and 3.4, with the 'python3' >package pulling in 3.3. That may change before Jessie becomes stable, >I don't know. It already has: https://lists.debian.org/debian-python/2014/05/msg00162.html The question

Re: [Python-Dev] asyncio/Tulip: use CPython as the new upstream

On Jun 06, 2014, at 04:47 PM, MRAB wrote: >Isn't this a little like when bool, True and False were added to >Python 2.2.1, a bugfix release, an act that is, I believe, now regarded >as a mistake not to be repeated? Yes, that was a mistake, but the case under discussion is different. With True/Fa

Re: [Python-Dev] Python 2.7 patch levels turning two digit

On Jun 21, 2014, at 12:27 PM, M.-A. Lemburg wrote: >This opens up a potential backwards incompatibility with existing >tools that assume the Python release version number to use the >"x.y.z" single digit approach, e.g. code that uses sys.version[:5] >for the Python version or relies on the lexicog

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Jul 12, 2018, at 09:23, INADA Naoki wrote: >> >> Yes, the PEP has improved significantly since that time. My guess is the >> same poll taken now could give an opposite result. >> > > I still -0 on PEP 572. But strong -1 on restart discussion about changing it. > We should polish and implem

Re: [Python-Dev] PEP 572 and assert

On Jul 17, 2018, at 07:59, Guido van Rossum wrote: > > Personally I like Barry's example just fine -- assuming `subdirs` is not used > later, this feels like a good use case. Thanks! I thought it was cute. It was just something that occurred to me as I was reviewing some existing code. The

Re: [Python-Dev] PEP 572 and assert

On Jul 17, 2018, at 11:34, Tim Peters wrote: > Assuming the result of list(path.iterdir()) can change over time (seems very > likely), > >assert len(list(path.iterdir())) == 0, list(path.iterdir()) > > _could_ end up both triggering and displaying an empty list in the exception > detail.

Re: [Python-Dev] PEP 572 and assert

On Jul 17, 2018, at 12:18, MRAB wrote: > Why use len(...) == 0 instead of not(...)? > >assert not(subdirs := list(path.iterdir())), subdirs Off-topic, but it’s a style thing. Some style guides (and my personal preference) require to be more explicit when checking for empty sequences. I’

Re: [Python-Dev] Status of Python CIs (buildbots, Travis CI, AppVeyor): july 2018

On Jul 18, 2018, at 13:54, Victor Stinner wrote: > Last May, we worked hard to fix many random test failures on all CIs > before Python 3.7 final release. Thank you thank you thank you Victor for work on keeping the buildbots happy! -Barry signature.asc Description: Message signed with OpenP

Re: [Python-Dev] New _Py_InitializeFromConfig() function (PEP 432)

On Jul 31, 2018, at 15:14, Victor Stinner wrote: > > I finished my work on the _PyCoreConfig structure: it's a C structure > in Include/pystate.h which has many fields used to configure Python > initialization. In Python 3.6 and older, these parameters were scatted > around the code, and it was h

Re: [Python-Dev] Python 2.7 EOL date

On Aug 23, 2018, at 15:23, Eric V. Smith wrote: > > On 8/23/2018 4:30 PM, Victor Stinner wrote: >> Hi, >> The reference is the PEP 373 "Python 2.7 Release Schedule". See the >> "Update" section: >> https://www.python.org/dev/peps/pep-0373/#update > > We could probably make it more clear in this

Re: [Python-Dev] bpo-34595: How to format a type name?

MRAB wrote on 9/11/18 16:06: On 2018-09-11 23:23, Victor Stinner wrote: Last week, I opened an issue to propose to add a new %T formatter to PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat() and PyErr_Format():     https://bugs.python.org/issue34595 I merged my change, but th

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On Sep 19, 2018, at 20:34, Gregory P. Smith wrote: > There's ongoing work to rewrite zipimport.c in python using zipfile itself Great timing! Serhiy’s rewrite of zipimport in Python has just landed in 3.8, although it doesn’t use zipfile. What’s in git now is a pretty straightforward transla

[Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

On Sep 25, 2018, at 03:44, Victor Stinner wrote: > By the way, recently, we had to fix yet another bug in signal > handling. A new function has been added: > > void > _PyEval_SignalReceived(void) > { >/* bpo-30703: Function called when the C signal handler of Python gets a > signal. We

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

On Sep 25, 2018, at 10:18, Antoine Pitrou wrote: > > Not really. Many are just like "static" (i.e. module-private) > functions, except that they need to be shared by two or three different > C modules. It's definitely the case for _PyEval_SignalReceived(). Purely static functions which appear

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

On Sep 25, 2018, at 10:08, Jeroen Demeyer wrote: > > On 2018-09-25 16:01, Barry Warsaw wrote: >> Maybe this is better off discussed in doc-sig but I think we need to >> consider documenting the private C API. > > Even the *public* C API is not fully documented.

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

On Sep 25, 2018, at 11:28, Victor Stinner wrote: > > But if we have a separated documented for CPython internals, why not > documenting private functions. At least, I would prefer to not put it > at the same place an the *public* C API. (At least, a different > directory.) I like the idea of an

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

On Sep 25, 2018, at 12:09, Yury Selivanov wrote: > > My main concern with maintaining a *separate* documentation of > internals is that it would make it harder to keep it in sync with the > actual implementation. We often struggle to keep the comments in the > code in sync with that code. Well,

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

On Oct 3, 2018, at 08:06, Łukasz Langa wrote: > >> On 3 Oct 2018, at 15:51, INADA Naoki wrote: >> >> Really? >> I don't know process to assign BDFL-delegate without BDFL. > > My understand is that accepting *any* PEP by anyone is out of the question > until the governance situation gets resol

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: >> My feeling is that limiting it to strings is fine, but checking those >> strings for resembling identifiers is pointless and wasteful. > > Sure. The question is, do we have t

Re: [Python-Dev] Standardize error message for non-pickleable types

On Oct 29, 2018, at 12:51, Victor Stinner wrote: > >> 4. Use the "a" article or not? > > no: "cannot serialize xxx object" (but i'm not a native english > speaker, so don't trust me :-)) It should be fine to leave off the indefinite article. > >> 5. Use quotes around type name or not? Ideall

Re: [Python-Dev] About "python-porting" mail list

On Dec 23, 2018, at 07:29, Facundo Batista wrote: > > This list (which I co-admin, with Georg) is getting less and less > traffic as months pass by. See: > > https://mail.python.org/pipermail/python-porting/ > > The interwebs has been collecting ton of resources about porting py2 > to 3 during

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