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

On 26 Mar 2014 23:12, "Cory Benfield" wrote: > > Nick, > > On 26 March 2014 12:00, Nick Coghlan wrote: > > As one example, the Python 2 ``ssl`` module does not support the Server > > Name Identification standard. > > Tiny note: SNI is 'Server Name In

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

On 27 Mar 2014 01:28, "Alex Gaynor" wrote: > > This mostly looks good to me, however I'm not sure I understand the point of > this sentence: "Rather, it is intended to send a clear signal to potential > corporate contributors that the core development team are willing to accept > offers of corpora

Re: [Python-Dev] collections.sortedtree

On 27 Mar 2014 07:02, "Guido van Rossum" wrote: > > Actually, the first step is publish it on PyPI, the second is to get a fair number of happy users there. The bar for getting something included into the stdlib is pretty high -- you need to demonstrate that there is a need *and* that having it as

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

cally advises that cross-version compatible code use feature detection rather than version checks. For network security, it's recommended to avoid using the low level modules directly, anyway - it's much better to use a higher level library like requests, to reduce the number of places

Re: [Python-Dev] collections.sortedtree

On 27 March 2014 18:11, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > On 27 Mar 2014 07:02, "Guido van Rossum" wrote: > >> Actually, the first step is publish it on PyPI, the second is to > >> get a fair number of happy users there. The bar f

Re: [Python-Dev] collections.sortedtree

"trust, but verify" comes at a real cost in time and money. However, there are plenty of good reasons that phrase is "trust, but verify" rather than "trust unconditionally". You may choose not to care about those more cautious users, and that's fine - bu

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

ch that they eventually say yes is too time consuming". Helping people to learn exactly how to navigate that process is actually one of the main roles of python-ideas these days, although we don't do a good job (at all) of advertising that fact. Regards, Nick. -- Nick Coghlan |

Re: [Python-Dev] collections.sortedtree

On 27 March 2014 20:38, Chris Angelico wrote: > On Thu, Mar 27, 2014 at 8:58 PM, Nick Coghlan wrote: >>On 27 March 2014 19:10, Maciej Fijalkowski wrote: >>> I just find "my company is stupid so let's work around it by putting >>> stuff to python standa

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

m not sure if the problem is a missing reference, or if the footnote can go away now. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

f PEP 308. I also seem to recall Guido saying he liked it, which flipped the discussion from "do we have a good rationale for including it?" to "do we have a good rationale for the BDFL to ignore his instincts?". However, it would be up to Guido to confirm that recollection

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

by using an asynchronous backend while still presenting a synchronous API. And rather than adding a new API, I'd hope it could propose just getting rid of those warnings by reimplementing the current deadlock prone APIs on top of "run_until_complete()" and exploring the potential

Re: [Python-Dev] Jython site now seems to redirect to docs.python.org???

I'm not sure where the responsibilities of the redesign team end and those of the infrastructure team start, but since the switch to the new site I've been adding anything related to the website parts of python.org to https://github.com/python/pythondotorg/issues If that's not the right place, the

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

On 28 March 2014 21:12, Antoine Pitrou wrote: > On Thu, 27 Mar 2014 20:32:02 +1000 > Nick Coghlan wrote: >> >> Most of the time when I hear people say "the PEP process is too >> difficult", I eventually find that what they really mean is "learning >

Re: [Python-Dev] libpython added to ABI tracker

On 29 March 2014 02:25, Antoine Pitrou wrote: > On Fri, 28 Mar 2014 12:31:59 +0400 > Andrey Ponomarenko wrote: >> Hi, >> >> The libpython library has been added to the ABI tracker: >> http://upstream-tracker.org/versions/python.html >> >> The page lists library versions and changes in API/ABI. >

Re: [Python-Dev] collections.sortedtree

iki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014) :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] PyErr_ Fetch | Restore & friends

(Although don't forget the bit earlier in the function that populates the traceback correctly on the original exception) I thought I had filed a "Add a public API to make properly chained exceptions easier to raise from C" RFE while working on the codec chaining, but I'm n

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

profound than I think any of us realised back in 2006 when Guido first turned the previously hypothetical "Py3k" into a genuine active effort to create a new revision of the language, better suited to the global nature of the 21st century. Cheers, Nick. -- Nick Coghlan | ncogh.

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

se.html#bytes It seems to me that the easiest way to make any forthcoming Python 3.5 enhancements (both binary interpolation and the other cleanups we are discussing over on Python ideas) available to single source 2/3 code bases is to commit to an API freeze for *those particular

Re: [Python-Dev] libpython added to ABI tracker

On 1 Apr 2014 01:38, "Victor Stinner" wrote: > > 2014-03-31 13:38 GMT+02:00 Andrey Ponomarenko : > > The public libpython API changes will be tracked here: > > http://upstream-tracker.org/versions/python_public_api.html > > > > For now I've excluded only symbols starting with an underscore. What o

Re: [Python-Dev] libpython added to ABI tracker

On 1 April 2014 21:23, Andrey Ponomarenko wrote: > > Nick Coghlan wrote: >> >> On 1 Apr 2014 01:38, "Victor Stinner" wrote: >>> >>> 2014-03-31 13:38 GMT+02:00 Andrey Ponomarenko : >>>> >>>> The public libpython API c

Re: [Python-Dev] libpython added to ABI tracker

On 2 Apr 2014 00:54, "Benjamin Peterson" wrote: > > On Tue, Apr 1, 2014, at 4:45, Nick Coghlan wrote: > > Georg, Larry, Benjamin - should checking these be added to PEP 101, so > > we don't get the same thing happening for 3.5? > > I would like it if we

Re: [Python-Dev] libpython added to ABI tracker

On 3 April 2014 00:18, Andrey Ponomarenko wrote: > > Nick Coghlan wrote: >> >> Regarding the warnings for this one - is there a way for the checker >> to warn if data structures are exposed directly, rather than as opaque >> types? It's fine if there isn&#x

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

On 7 Apr 2014 21:58, "MRAB" wrote: > > On 2014-04-08 02:45, Guido van Rossum wrote: >> >> So what? Aren't we allowed to have fun? :-) >> > Next thing you know, he'll be threatening people with The Comfy Chair! You may want to take a look at the packaging metadata 2.0 spec ;) I was also going to

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

WSGI 2.0 (that can assume the Python 3 text model, the restoration of binary interpolation, the availability of asyncio, etc), but most of the likely principals there are still burned out from the WSGI 1.1 debate and the Python 3 transition in general :( > > > -- > mvh/best regards Bjö

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

ides no clear indication as to how the standard operators fail. Note that numpy.matrix is specifically discussed in http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-new-operator (it's the first rejected alternative listed). Cheers, Nick. -- Nick Coghlan |

Re: [Python-Dev] death to 2.7; long live 2.7

On 9 Apr 2014 22:11, "Guido van Rossum" wrote: > > On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson wrote: >> >> >> >> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote: >> > I think this is pretty much what Nick Coghlan implied at the summ

Re: [Python-Dev] Language Summit notes

On 10 Apr 2014 10:23, "Antoine Pitrou" wrote: > > Le 10/04/2014 13:24, Kushal Das a écrit : > >> >> At this time of discussion Nick pointed us to >> `http://speed.python.org/ `_, he asked if >> any of the implementations >> wants to maintain it. We need more volunteers fo

Re: [Python-Dev] Windows installers and OpenSSL

On 10 Apr 2014 18:55, "Benjamin Peterson" wrote: > > On Thu, Apr 10, 2014, at 14:50, Gregory P. Smith wrote: > > Yep. All binary Python distributions that bundle SSL support need > > updating. > > But... what MRAB said. > > > > We also *likely* have SSL certificates and SSH host keys on > > python

Re: [Python-Dev] Language Summit notes

On 11 Apr 2014 05:39, "Armin Rigo" wrote: > > Hi, > > On 10 April 2014 22:12, Paul Moore wrote: > > I agree. I'd like to see a clear explanation of what advantages (and > > disadvantages!) CFFI gives over ctypes, as well as the plan for > > inclusion and how the inevitable confusion over whether

Re: [Python-Dev] Appeal for reviews

On 12 Apr 2014 18:08, "Terry Reedy" wrote: > On 4/12/2014 2:58 PM, Nikolaus Rath wrote: > >> I realize that core developer time is scarce, so I have started to only >> work on patches after I've confirmed that someone is available and >> interested to review them. However, it would be great if som

Re: [Python-Dev] Appeal for reviews

On 14 Apr 2014 01:56, "Stephen J. Turnbull" wrote: > > mar...@v.loewis.de writes: > > > For gaining commit access, it's really more important that the patch > > is factually finished, than that it's author believes it to. If people > > get it right the first time often enough, they get commit a

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 14 Apr 2014 18:37, "Glenn Linderman" wrote: > > On 4/14/2014 2:51 PM, Brett Cannon wrote: >> >> Freezing everything except encodings.__init__, os, and _sysconfigdata, > > > I suppose these are omitted because they can vary in different environments? > > But isn't Python built for a particular e

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

On 14 Apr 2014 17:17, "Donald Stufft" wrote: > > Now I will admit I personally have probably had a harder time than some others because of the nature of the things I was trying to work on, and lately it’s gotten better (although I think that’s partially because I’m more known now, and I think in g

Re: [Python-Dev] Appeal for reviews

On 14 Apr 2014 08:42, "R. David Murray" wrote: > > On Mon, 14 Apr 2014 08:18:13 -0400, Nick Coghlan wrote: > > On 14 Apr 2014 01:56, "Stephen J. Turnbull" wrote: > > > > > > mar...@v.loewis.de writes: > > > > > > &g

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

On 15 Apr 2014 18:56, "Steve Dower" wrote: > From Eric: > > This should be doable with an import hook. For that matter it would be pretty straight-forward to provide a script around the Python binary that installs the import hook. All this could be bundled up and distributed through the cheesesh

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

pecify a zip file that will contain the Mercurial > byte code. For example, we could support a -Z option for the interpreter > which would allow to append a zip file to a script that gets put on > sys.path. Has anyone tried running mercurial as a zipfile with __main__.py and a prepended

Re: [Python-Dev] Timing breakdown of Py_InitializeEx_Private()

. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archi

[Python-Dev] PEP 466: Network security enhancements for Python 2.7.7

that change addresses Guido's main remaining concern, so I think this version is ready for pronouncement. Regards, Nick. PEP: 466 Title: Network Security Enhancements for Python 2.7.7 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghla

[Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 16 Apr 2014 21:03, "R. David Murray" wrote: > There is an 'Installing Python on Windows' link further down the google > results that links to a fairly good page from python-guide.org, whose > first link lets you download the 2.7.6 msi. I guess that's the 32 > bit version. But it then tells yo

Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable

book contract fell through, and I was never able to interest anyone in rescuing the material from the ODF manuscript and migrating it to Sphinx after I donated it to the PSF: http://svn.python.org/view/sandbox/trunk/userref/ (It's also all 2.5 era docs, so would need a fair bit of work to bring it up

Re: [Python-Dev] Language Summit notes

arity. Not tinkering with syntactic details - do the latter for fun and to help people years down the track, but do other things (like helping with packaging or the core development workflow tools or communications projects like Mailman 3 and the HyperKitty archiver) if the long game doesn'

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 12:55, Paul Moore wrote: > On 18 April 2014 16:58, Nick Coghlan wrote: >> As part of thrashing out the respective distribution ecosystem roles >> of pip and conda (still a work in progress), we're at least converging >> on the notion that there are ac

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 15:39, Donald Stufft wrote: > > On Apr 18, 2014, at 3:18 PM, Nick Coghlan wrote: > >> At this point, however, I'm mainly looking for consensus that there >> *are* two different problems to be solved here, and solving them both >> well in a sin

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 16:27, Paul Moore wrote: > On 18 April 2014 20:18, Nick Coghlan wrote: >> At this point, however, I'm mainly looking for consensus that there >> *are* two different problems to be solved here, and solving them both >> well in a single tool is likel

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

ments, and hence pip works in more situations than conda does, but at the cost of being specific to Python packages. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https:

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 17:22, Donald Stufft wrote: > > On Apr 18, 2014, at 5:08 PM, Nick Coghlan wrote: > >> On 18 April 2014 16:50, Donald Stufft wrote: >>> So I’m not really worried about a competition or anything. I’m mostly >>> worried >>> about confusio

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 18:16, Greg Ewing wrote: > Nick Coghlan wrote: >> >> there are actually now *two* main ways of consuming >> Python: > > > Really? We'd better do something about that. We don't want > anyone consuming Python -- we want some left over for

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

understanding and visualising the world. Regards, Nick. > > Paul -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

On 18 April 2014 18:28, Donald Stufft wrote: > > On Apr 18, 2014, at 6:24 PM, Nick Coghlan wrote: > >> On 18 April 2014 18:17, Paul Moore wrote: >>> On 18 April 2014 22:57, Donald Stufft wrote: >>>> Maybe Nick meant ``pip install ipython[all]`` but I

Re: [Python-Dev] PEP 466: Network security enhancements for Python 2.7.7

now, rather than an ongoing policy PEP. I filed separate tracker issues for the four parts of the proposal: os.urandom: http://bugs.python.org/issue21305 hmac: http://bugs.python.org/issue21306 hashlib: http://bugs.python.org/issue21307 ssl:http://bugs.python.org/issue21308 Regards, Nick. -- N

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

Title: Simplified migration of iterator-based mapping code to Python 3 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-04-18 Python-Version: 3.5 Post-History: 2014-04-18 Abstract For Python 3, PEP

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

On 19 Apr 2014 00:27, "Steven D'Aprano" wrote: > > On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: > > After spending some time talking to the folks at the PyCon Twisted > > sprints, they persuaded me that adding back the iterkeys/values/items >

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

On 18 Apr 2014 23:08, "Benjamin Peterson" wrote: > > On Fri, Apr 18, 2014, at 19:31, Nick Coghlan wrote: > > After spending some time talking to the folks at the PyCon Twisted > > sprints, they persuaded me that adding back the iterkeys/values/items > > methods f

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

On 19 Apr 2014 10:53, "Guido van Rossum" wrote: > > Does everyone involved know that "for x in d.iterkeys()" is equivalent to "for x in d" and works the same in Python 2 and 3? Similarly, "list(d)" is a simple, fast way to spell the Python 2 semantics of "d.keys()" that works in both versions (bu

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

On 19 Apr 2014 12:29, "Ezio Melotti" wrote: > > Hi, > > On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano wrote: > > On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote: > >> It is a signigificant portion of the incompatibility, and seems like > >> such a minor concession to com

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

On 20 Apr 2014 08:14, "Markus Unterwaditzer" wrote: > > Also, that's why people demanded a Python 2.8... so that you don't have to > pollute Python 3 instead. It doesn't actually solve the problem in the library and framework cases though - most folks that are straddling 2/3 want to keep compatib

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

On 19 April 2014 12:17, Nick Coghlan wrote: > That may help clarify the tricky warts and edge cases that can arise when > moving from the current relatively straightforward and consistent method > based approach to a more complicated combination of dedicated syntax and > helper fu

Re: [Python-Dev] pep8 reasoning

n misappropriating python-dev's authority :( Regards, Nick. P.S. https://github.com/jcrocholl/pep8/issues/256 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

Re: [Python-Dev] pep8 reasoning

On 25 April 2014 17:52, Carl Meyer wrote: > On 04/25/2014 01:55 PM, Ethan Furman wrote: >> On 04/25/2014 12:45 PM, Florent wrote: >>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan: > I think this fuss is unreasonable and unwarranted. > > I'd like to thank Florent fo

Re: [Python-Dev] pep8 reasoning

t remains "PEP 8 plus extra rules python-dev has never discussed". Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinf

Re: [Python-Dev] pep8 reasoning

On 25 April 2014 19:56, Florent wrote: > 2014-04-26 0:46 GMT+02:00 Nick Coghlan : >> Florent is claiming the endorsement of the PEP 8 authors >> and the consensus of python-dev for the tool's default behaviour >> (as noted above, this makes it personal for me, as I

Re: [Python-Dev] pep8 reasoning

On 25 April 2014 21:29, Nick Coghlan wrote: > On 25 April 2014 19:56, Florent wrote: >> 2014-04-26 0:46 GMT+02:00 Nick Coghlan : >>> Florent is claiming the endorsement of the PEP 8 authors >>> and the consensus of python-dev for the tool's default behaviour &g

Re: [Python-Dev] API and process questions (sparked by Claudiu Popa on 16104

On 28 Apr 2014 16:19, "Ezio Melotti" wrote: > > On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett wrote: > > (1) Should fixes to a docstring go in with a patch, even if they > > aren't related to the changing functionality? > > > > [...] > > > > It is best if a commit changes one small thing at a t

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

uper() objects from C to do cooperative multiple inheritance isn't straightforward (I actually don't know how to do it myself - I'd have to go trawling through the C API docs to figure it out). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-Dev] Python 2.7.7. on Windows

or 2.7.7. However, that's currently not obvious to folks that have only read the final version of the PEP, and didn't see the earlier more open ended versions that included that text. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-Dev] Existence of pythonNN.zip in sys.path

On 6 May 2014 07:51, "Paul Moore" wrote: > > On 5 May 2014 22:32, Anthony Tuininga wrote: > > So my question is: can I safely make use of this "feature"? It has remained > > in place since at least Python 2.6 but I don't want to assume anything. > > Please advise! Thanks. > > I believe this is a

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

ace) in the mix - it quickly becomes impossible if every new dependency from an installation request adds a new point of failure. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On 9 May 2014 00:52, "M.-A. Lemburg" wrote: > > On 08.05.2014 15:57, Nick Coghlan wrote: > > > (even the question of "does this software actually work?" is in our > > sights if you consider a long enough time span). That's hard enough > >

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On 9 May 2014 07:23, "Donald Stufft" wrote: > On May 8, 2014, at 5:02 PM, Paul Moore wrote: > > > Or > > maybe we have to accept that some developers have sound reasons for > > not hosting on PyPI and work with them to find an acceptable > > compromise? Has anyone checked what Stefan's reasons ar

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On 9 May 2014 08:22, "Donald Stufft" wrote: > > > On May 8, 2014, at 6:20 PM, Nick Coghlan wrote: >> >> I actually need to follow up on that, because the terms *were* legally questionable last time I looked (also too hard to review, since as far as I am aware, th

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

gt; So now "pip install Mercurial" always fails? And adding a flag allows > it to work as well as before, but no better? How did that fix the > issue? Seriously - I'm missing something here. Mercurial downloads are now available directly from PyPI. Cheers, Nick. -- Nick Co

Re: [Python-Dev] should tests be thread-safe?

On 10 May 2014 06:53, "akira" <4kir4...@gmail.com> wrote: > > Hi, > > May tests expect that unless they themselves start a thread then there are no threads to worry about? > > I see that some old tests are not thread-safe and I have not found it to be explicitly mentioned in the devguide. > > I've

Re: [Python-Dev] [Python-checkins] cpython: Remove the redundant and poorly worded warning message.

On 11 May 2014 07:37, "Raymond Hettinger" wrote: > > > On May 10, 2014, at 2:18 PM, Alex Gaynor wrote: > >> I think this change is a considerable usability regression for the documentation. Right now the warnings about CSPRNGs are hidden in the introductory paragraph, which users are likely to sk

Re: [Python-Dev] [Python-checkins] cpython: Remove the redundant and poorly worded warning message.

On 11 May 2014 08:24, "Raymond Hettinger" wrote: > > Before proceeding further with stamping distracting security > warnings all over the module documentation, we should look > to other languages to see what others have found necessary. > This warning does not appear anywhere else I've looked > (M

Re: [Python-Dev] devguide: Add myself to developer log and as a Windows expert.

On 11 May 2014 23:59, "Steve Dower" wrote: > > Thanks. Indeed, welcome! > For those who missed the earlier discussions, Martin v. Löwis has handed over responsibility for the Windows installers. It sounds like Brett Cannon and I are both in a position to build 2.7 right now, The other BC: Brian

Re: [Python-Dev] python process creation overhead

pect to have time to get back to for Python 3.5. And yes, one thing those changes should enable is the creation of system Python runtimes on Linux that initialise faster than the current implementation. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

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

d OS in a conditional check, no) - some guidelines for what's needed for a new OS to be added as officially supported (with age and popularity likely being worth taking into account) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

[Python-Dev] Returning None from methods that mutate object state

;> "ABC".lower() is None False That's a deliberate design choice, and one that has been explained a few times on the list when folks ask why "[].sort().reverse()" doesn't work when "'ABC'.lower().replace('-', '_')" does. Wo

Re: [Python-Dev] Returning None from methods that mutate object state

On 17 May 2014 18:26, Terry Reedy wrote: > On 5/17/2014 1:14 AM, Nick Coghlan wrote: >> >> During a conversation today, I realised that the convention of >> returning None from methods that change an object's state isn't >> captured the Program

Re: [Python-Dev] Returning None from methods that mutate object state

On 17 May 2014 19:56, "Antoine Pitrou" wrote: > > On Sat, 17 May 2014 15:14:00 +1000 > Nick Coghlan wrote: > > During a conversation today, I realised that the convention of > > returning None from methods that change an object's state isn't > > c

Re: [Python-Dev] Python 2.7.7 and PEP 466

quot;What are we depending on without committing sufficient development resources to long term maintenance?" problem, large orgs still don't tend to move that fast :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Pyt

Re: [Python-Dev] Language Summit Follow-Up

27;s parser is able to handle the idea (see my final comment for additional restrictions a full proposal would need) For that last point, my interest is as much educational as it is in easing the transition from Python 2. The parentheses in "print('Hello world!')" mean introdu

Re: [Python-Dev] Language Summit Follow-Up

On 31 May 2014 08:42, "Guido van Rossum" wrote: > > 2to3 is poorly named. With different fixers it is a fine tool for converting 2-only code to 2-and-3 straddling code. Even when using six, you need to do things like convert print statements to print() calls with future import, use 'as' in except

Re: [Python-Dev] Language Summit Follow-Up

On 31 May 2014 02:47, "Chris Barker" wrote: > However, I also believe that when teaching it's better to introduce the "right way" to do something up front, rather than a "beginners' way", then later say, well, you really SHOULD do it this other way... So if we want our students to use print as a f

Re: [Python-Dev] Language Summit Follow-Up

On 31 May 2014 03:42, "Mark Roberts" wrote: > > What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. That's what projects like python-future

Re: [Python-Dev] Should standard library modules optimize for CPython?

On 1 Jun 2014 18:13, "Steven D'Aprano" wrote: > > My feeling is that the CPython standard library should be written for > CPython, that is, it should stick to the current naive implementation of > median, and if PyPy wants to speed the function up, they can provide > their own version of the modul

Re: [Python-Dev] Updating turtle.py

lenges of maintenance programming aren't made clear to potential contributors up front, they're going to be disappointed when their patches that might be fine for a green field project, or as part of the development of a particular feature or fix, are instead rejec

Re: [Python-Dev] Internal representation of strings and Micropython

an't > see any requirement in the docs that str[n] must take O(1) time, but > perhaps I have missed something. There's a general expectation that indexing will be O(1) because all the builtin containers that support that syntax use it for O(1) lookup operations. Cheers, Nick. -- Nic

Re: [Python-Dev] Internal representation of strings and Micropython

On 4 June 2014 15:39, wrote: > On Wed, Jun 04, 2014 at 03:17:00PM +1000, Nick Coghlan wrote: > >> There's a general expectation that indexing will be O(1) because all >> the builtin containers that support that syntax use it for O(1) lookup >> operations. > &

Re: [Python-Dev] Internal representation of strings and Micropython

k we're better off if alternative implementations are free to experiment with different internal string representations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] Internal representation of strings and Micropython

those types as well. More on that at http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#what-actually-changed-in-the-text-model-between-python-2-and-python-3 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-Dev] Internal representation of strings and Micropython

locale encoding to be correct, but the startup code will need non-trivial changes for that to happen - the C.UTF-8 locale may even become widespread before we get there). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-Dev] Internal representation of strings and Micropython

all. > > Several core-devs have said that using UTF-8 for MicroPython is perfectly > okay. > I also think it's the right choice and I hope that you guys come up with a > very > efficient implementation. Based on this discussion , I've also posted a draft patc

Re: [Python-Dev] Internal representation of strings and Micropython

On 5 June 2014 22:37, Paul Sokolovsky wrote: > On Thu, 5 Jun 2014 22:20:04 +1000 > Nick Coghlan wrote: >> problems caused by trusting the locale encoding to be correct, but the >> startup code will need non-trivial changes for that to happen - the >> C.UTF-8 locale ma

Re: [Python-Dev] Internal representation of strings and Micropython

On 6 Jun 2014 05:13, "Glenn Linderman" wrote: > > On 6/5/2014 11:41 AM, Daniel Holth wrote: >> >> discover new things >> like dance-encoded strings, bytes decoded using an incorrect encoding >> intended to be transcoded into the correct encoding later, surrogates >> that work perfectly until .enco

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

d by the PEP. The difference with selectors is that it was *not* added as a provisional module - it's subject to all the normal stability requirements. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev ma

Re: [Python-Dev] Internal representation of strings and Micropython

On 6 June 2014 21:15, Paul Sokolovsky wrote: > Hello, > > On Thu, 5 Jun 2014 23:15:54 +1000 > Nick Coghlan wrote: > >> On 5 June 2014 22:37, Paul Sokolovsky wrote: >> > On Thu, 5 Jun 2014 22:20:04 +1000 >> > Nick Coghlan wrote: >> >> pr

Re: [Python-Dev] Internal representation of strings and Micropython

On 7 Jun 2014 00:53, "Paul Sokolovsky" wrote: > > Yes. Except for one small detail - Python3 specifies these code points > to be Unicode code points. And Unicode is a very bloated thing. I rather suspect users of East Asian & African scripts might have a different notion of what constitutes "bloa

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

it can take months for C extension authors to start publishing compatible binaries for a new minor release, so we'd have to assume that time would be even longer for a Python 2.7 maintenance release, if they published updated binaries at all. Regards, Nick. -- Nick Coghlan | ncogh.

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

ilding 64 bit extensions is s serious pain. That was a largely independent discussion, noting that if we come up with a mechanism for dealing with Linux distro variances, it may also be useful for dealing with Windows C runtime variances. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com

<    10   11   12   13   14   15   16   17   18   19   >