Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

On 13 February 2014 20:54, Donald Stufft wrote: > > On Feb 13, 2014, at 3:53 PM, Paul Moore wrote: > >> Can someone please take a look at http://bugs.python.org/issue20621 >> for me? It appears that there is a significant problem with zipimport >> in 3.3.4. It'

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

On 14 February 2014 10:20, Antoine Pitrou wrote: > Hmm, it seems you're right, but I'm quite sure some DBMSes have a > consistent way of ordering NULLs when using ORDER BY on a nullable > column. ORDER BY xxx [NULLS FIRST|LAST] is the syntax in Oracle, with (IIRC) NULLS LAST as default. But I agr

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

On 13 February 2014 20:58, Paul Moore wrote: > On 13 February 2014 20:54, Donald Stufft wrote: >> >> On Feb 13, 2014, at 3:53 PM, Paul Moore wrote: >> >>> Can someone please take a look at http://bugs.python.org/issue20621 >>> for me? It appears t

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

On 16 February 2014 08:19, Georg Brandl wrote: > As soon as a patch has been provided and tested, I will make a schedule > for 3.3.5 including the fix. Until then, using 3.3.3 is probably the > best solution. Fantastic - thanks for that. Paul ___ Pytho

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

is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sur

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

On 17 February 2014 11:49, Gustavo Carneiro wrote: > >> >> FWIW, I don't think we need to invent a new name for it, just add >> an appropriate tp_richcompare slot to the PyNoneType or readd the >> special case to Object/object.c. This would also aid in porting >> existing Python 2 code to Python 3

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

Thanks, I see. Greg already filed a tracking issue, so it's covered anyway. On 17 February 2014 15:33, Larry Hastings wrote: > On 02/16/2014 03:45 PM, Paul Moore wrote: > > <http://bugs.python.org/issue20621> is significant enough to be > resulting in a 3.3.5 release - ca

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

On 18 February 2014 07:35, Greg Ewing wrote: > If you don't want to touch comparison in general, > how about an option to sort()? > > results = sorted(invoices, key=attrgetter('duedate'), none='first') Or alternatively, a "default on None" function - Oracle SQL calls this nvl, so I will too: d

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

On 18 February 2014 21:17, Greg Ewing wrote: > What I'd *really* like to be able to write is: > >sort(invoices, keyattr = 'duedate', none = 'first') Which is of course a pretty trivial utility function to write. But I understand your point - these "trivial helpers" add up over time into a bit

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

On 21 February 2014 11:35, Nick Coghlan wrote: >> Just as PEP 308 introduced a means of value-based conditions in an >> expression, this system allows exception-based conditions to be used >> as part of an expression. > > Great work on this Chris - this is one of the best researched and > justifie

Re: [Python-Dev] GSoC 2014 - Email Module

On 26 February 2014 16:13, Brett Cannon wrote: >>> >>> Please sign up for core-mentorship list and ask questions there. >> >> >> Is this for students too? Because I want to join as a student. > > > The mailing list is for anyone who wants to contribute to Python's > development and wants some help

Re: [Python-Dev] GSoC 2014 - Status for Core Python

On 26 February 2014 18:53, Terry Reedy wrote: > On 2/26/2014 12:34 PM, Paul Moore wrote: > >> The subject of this email mentions GSoC, it's probably worth >> clarifying that the GSoC process is still under way and there isn't >> (as far as I know, I'm n

Re: [Python-Dev] Windows 'for current user' installation - 32/64-bit registrations overwrite each other

On 10 March 2014 13:03, Jurko Gospodnetić wrote: > Is this as issue or desired behaviour? Should I open an issue for it? Sounds like a bug, but a pretty long-standing one. I can't think that the registry schema Python uses would *ever* have distinguished (the WOW64 component of the all-users entr

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

On 10 March 2014 17:08, R. David Murray wrote: > We had this discussion a bit ago, and my sense was that we tentatively > decided that we were just going to deprecate and remove things as > appropriate, irregardless of version number. I used "4.0" in my > message about 'U' as a shorthand for "som

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

On 10 March 2014 19:42, Serhiy Storchaka wrote: > 10.03.14 20:50, Paul Moore написав(ла): > >> I have seen a number of postings recently pointing to things as "not >> until Python 4000" or "not until Python 4.0" (yours was not one that I >> not

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

On 12 March 2014 16:05, Chris Angelico wrote: > Tooling issues should already have been solved for lambda, but if you > don't like the colon, go with one of the other options - Brett > expressed support for 'then', which makes very good sense (it does > require creating a new keyword, but it's a f

[Python-Dev] PEP URLs

On 13 March 2014 13:28, Barry Warsaw wrote: > > http://legacy.python.org/dev/peps/pep-0274/ Are these "legacy.python.org" URLs the canonical locations for PEPs these days? The main page redirects there, but I'd have hoped there would be a www.python.org location... (Just checking before I update

Re: [Python-Dev] Intricacies of calling __eq__

On 18 March 2014 19:46, Maciej Fijalkowski wrote: >> A question: how far away will this optimization apply? >> >> if x in d: >> do_this() >> do_that() >> do_something_else() >> spam = d[x] > > it depends what those functions do. JIT will inline them and if > the

Re: [Python-Dev] Making proxy types easier to write and maintain

On 19 March 2014 18:46, Antoine Pitrou wrote: > In http://bugs.python.org/issue19359#msg213530 I proposed to introduce a > "proxy > protocol" (__proxy__ / tp_proxy) that would be used as a fallback by > _PyObject_LookupSpecial to fetch the lookup target, i.e.: > > def _PyObject_LookupSpecial(obj,

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

On 22 March 2014 23:07, Donald Stufft wrote: > As someone who is deeply biased towards improving the packaging tool chain > and getting people to use it I think that most people will simply use the > Stdlib even if a more secure alternative exists. Infact one does exist and I > still see almost ev

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

On 22 March 2014 23:49, Donald Stufft wrote: > In the case of requests they already have an optional dependency on > pyopenssl. It's just many people either don't know they should use it, are > unable to use it, or unwilling to use the python packaging tool chain > because of its current flaws. D

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

On 22 March 2014 21:11, Nick Coghlan wrote: > Full PEP included inline below, and available in more readable form at > http://www.python.org/dev/peps/pep-0466/ Disclaimer: I pretty much don't use 2.x, or write server-type software, so my practical requirement for the changes proposed here is negl

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

On 23 March 2014 07:07, Nick Coghlan wrote: > Advance warning: while I was able to get this revision turned around > pretty quickly, future revisions are likely to take a fair bit longer. > It was already a rather busy month before I decided to start this > discussion on top of everything else :)

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

On 25 March 2014 13:09, Nick Coghlan wrote: > * MvL has indicated he is not prepared to tackle the task of trying to > integrate a newer OpenSSL into the also aging Python 2.7 build > infrastructure on Windows (unfortunately, we've looked into upgrading > that build infrastructure, and the b

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

On 25 March 2014 13:47, Nick Coghlan wrote: > It's not like we're going to just be giving the PEP to vendors as a spec and > leaving them to it - it's largely an invitation to participate more directly > upstream to help resolve a particularly thorny problem, not a Statement of > Work :) :-) I d

Re: [Python-Dev] collections.sortedtree

On 27 March 2014 08:16, Maciej Fijalkowski wrote: > And random pieces of C included in the standard library can be > shuffled under the carpet under the disguise of upgrade or what are > you suggesting? The sort of thing that happens is that the relevant approvers will accept python-dev as a "tru

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

On 28 March 2014 05:09, Josiah Carlson wrote: > So yeah. Someone want to make a decision? Tell me to write the docs, I will. > Tell me to go take a long walk off a short pier, I'll thank you for your > time and leave you alone. I had a need for this a few years ago. It's messy to do on Windows (c

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

I'm not sure if this is a result of the recent website reorg, but www.jython.org seems to be redirecting to docs.python.org for me. Presumably this is an error - where do I report it and/or is it a known issue? Thanks, Paul. ___ Python-Dev mailing list P

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

On 28 March 2014 10:53, Nick Coghlan wrote: > 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/py

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

On 28 March 2014 11:24, Donald Stufft wrote: > Probably infrastructure-st...@python.org OK, I've emailed them as well. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.

Re: [Python-Dev] collections.sortedtree

On 28 March 2014 16:22, Tres Seaver wrote: > On 03/28/2014 12:18 PM, Tres Seaver wrote: >> I'm mostly arguing the FLOSS project should feel free to ignore >> high-maintenance-cost commercial concerns until those concerns bring >> either blook (funded developer time) or treasure (pooled to pay for

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

On 28 March 2014 13:46, Benjamin Peterson wrote: > This was my fault, though maybe apache 2.2's weird virtual host > selection rules can share some of the blame. Fixed now. Thanks Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.pytho

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

On 10 April 2014 02:58, Benjamin Peterson wrote: >> What will a lack of provided installers do to Windows support? It's >> easy enough on Linux to say "either build it from source, or let your >> upstream package provider build it for you", but AIUI, most Windows >> users want to get a ready-made

[Python-Dev] Windows installers and OpenSSL

Given the OpenSSL vulnerability and the fact that we bundle OpenSSL with the Windows installers (1.0.1e in Python 3.4.0) should we be releasing updated installers? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/lis

Re: [Python-Dev] Language Summit notes

On 10 April 2014 20:30, Antoine Pitrou wrote: > FWIW, I do hope there would be a PEP before including CFFI... Actually I > don't understand what would justify an exemption. I agree. I'd like to see a clear explanation of what advantages (and disadvantages!) CFFI gives over ctypes, as well as the

Re: [Python-Dev] Language Summit notes

On 11 April 2014 10:36, Armin Rigo wrote: > This would be superficial, but change the perception of CFFI to be "a > preprocessor that produces C extension modules". Thanks, that clarification helps a lot. Does this mean that "API-mode" CFFI is competing with things like swig (which is not used mu

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

On 15 April 2014 18:09, Daniel Holth wrote: > For me Python's startup time (warm) takes about 1/4 of the hg startup > time in the worst case. I expect to both notice and appreciate any > speedups and encourage all optimizers to optimize. My experience is essentially irrelevant (as a Windows user,

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

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 actually now *two* main ways of consuming > Python: as a "software integrator"

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

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 likely to be nigh on impossible. (I'm aware > we're really on the wrong list for that

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

On 18 April 2014 21:59, Nick Coghlan wrote: > What I am advocating for is that *we are currently doing it wrong*, as > these are unlikely to be the best thing to install for most new Python > users. For Windows users at least, I disagree. I have directed a lot of people to the python.org Windows

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

On 18 April 2014 22:08, Nick Coghlan wrote: > Note that one of my requirements was that "pip install foo" *must* do > the right thing in conda environments (whatever we decide the "right > thing" means in that context). Is this specifically a requirement for conda? Or do you expect the same to be

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

On 18 April 2014 22:40, Nick Coghlan wrote: > Perhaps we can get the "pip install ipython" experience to a good > place faster than I currently expect, and we can duck this entire > question (at least for Windows and Mac OS X). Huh? Last time I tried, it was pretty trivial. pip install pyzmq pyr

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

On 18 April 2014 22:57, Donald Stufft wrote: > Maybe Nick meant ``pip install ipython[all]`` but I don’t actually know what > that > includes. I’ve never used ipython except for the console. The hard bit is the QT Console, but that's because there aren't wheels for PySide AFAICT. Paul _

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

On 20 April 2014 03:49, Steven D'Aprano wrote: > I don't believe that will happen, the line *will* be drawn somewhere, > before Python 3 dies a death of a thousand cuts. I think that the right > place to draw the line is *here*, not the next time, or the time after > that. I think that the decisio

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

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 100% supported feature of Python (since 2.6, as you men

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

On 8 May 2014 16:46, Donald Stufft wrote: > Anything can be changes or reconsidered of course. I feel pretty strongly that > an installer should not install things from places other than the index > without > a specific opt in. That discussion would be best done on distutils-sig as it > would req

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

On 9 May 2014 05:34, Donald Stufft wrote: > On May 8, 2014, at 5:22 PM, Donald Stufft wrote: > >>> Socially, this change does not seem to be having the effect of >>> persuading more package developers to host on PyPI. The stick doesn't >>> appear to have worked, maybe we should be trying to find

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

On 9 May 2014 12:44, Donald Stufft wrote: > We still wouldn't be forcing anyone to upload things to PyPI. We are, however, > discouraging people from not hosting on PyPI and providing incentives to doing > that. But you're doing so by inflicting pain on people using pip to install those packages.

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

On 9 May 2014 13:06, Donald Stufft wrote: >>> I think it's important to point out that one of the driving factors that >>> caused >>> me to finally push for changes and what lead to PEP438 being created was >>> that >>> Mercurial's external hosted was being extremely flaky. I can't remember the

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

On 9 May 2014 13:25, Donald Stufft wrote: >> You're claiming that Mercurial moved to hosting on PyPI solely because >> users suddenly needed to add a flag to install from pip? As opposed to >> because PyPI gave them a more reliable hosting platform, for example? >> OK. I certainly can't give any e

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

On 4 June 2014 14:39, Serhiy Storchaka wrote: > I think than breaking O(1) expectation for indexing makes the implementation > significant incompatible with Python. Virtually all string operations in > Python operates with indices. I don't use indexing on strings except in rare situations. Sure I

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

On 5 June 2014 14:15, Nick Coghlan wrote: > As I've said before in other contexts, find me Windows, Mac OS X and > JVM developers, or educators and scientists that are as concerned by > the text model changes as folks that are primarily focused on Linux > system (including network) programming, an

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

On 5 June 2014 21:51, Nathaniel Smith wrote: > Is there a better idea I'm missing? Just a thought, but the temporaries come from the stack manipulation done by the likes of the BINARY_ADD opcode. (After all the bytecode doesn't use temporaries, it's a stack machine). Maybe BINARY_ADD and friends

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

On 5 June 2014 22:47, Nathaniel Smith wrote: > To make sure I understand correctly, you're suggesting something like > adding a new set of special method slots, __te_add__, __te_mul__, > etc. I wasn't thinking in that much detail, TBH. I'm not sure adding a whole set of new slots is sensible for

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

On 6 June 2014 16:41, Steve Dower wrote: > Basically, what I am offering to do is: > > * Update the files in PCBuild to work with Visual Studio "14" > * Make any code changes necessary to build with VC14 > * Regularly test the latest Python source with the latest MSVC builds and > report issues/s

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

On 6 June 2014 20:20, "Martin v. Löwis" wrote: > 2. what is the risk of installing a beta compiler on what might >otherwise be a "production" developer system? In particular, could >it interfere with other VS installations, and could it require a >complete system reinstall when the fin

Re: [Python-Dev] Returning Windows file attribute information via os.stat()

On 10 June 2014 05:02, Ben Hoyt wrote: > To solve this problem, what do people think about adding an > "st_winattrs" attribute to the object returned by os.stat() on > Windows? +1. Given the precedent of Linux- and OS X-specific attributes, this seems like a no-brainer to me. Paul __

Re: [Python-Dev] Criticism of execfile() removal in Python3

On 10 June 2014 08:36, Nick Coghlan wrote: > The standard implementation of run_path reads the whole file into > memory, but MicroPython would be free to optimise that and do > statement by statement execution instead (while that will pose some > challenges in terms of handling encoding cookies, f

Re: [Python-Dev] Returning Windows file attribute information via os.stat()

On 10 June 2014 13:19, Ben Hoyt wrote: > Because these are fixed-forever constants, I suspect in library code > and the like people would just KISS and use an integer literal and a > comment, avoiding the import/constant thing: The stat module exposes a load of constants - why not add the (curren

Re: [Python-Dev] Returning Windows file attribute information via os.stat()

On 10 June 2014 13:58, Ben Hoyt wrote: > So stat.FILE_ATTRIBUTES_HIDDEN and the like? Yep. (Maybe WIN_FILE_ATTRIBUTES_HIDDEN, but the Unix ones don't have an OA name prefix, so I'd go with your original). Paul ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On 12 June 2014 05:34, Florian Bruhin wrote: > Do the lookup in PATH yourself, it's not like that's rocket science. Am I missing something here? I routinely do subprocess.check_call(['hg', 'update']) or whatever, and it finds the hg executable fine. Paul _

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On 15 June 2014 00:15, Greg Ewing wrote: > However, it says the Windows version uses CreateProcess, which > doesn't use PATH. Huh? CreateProcess uses PATH: >py -3.4 Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits"

Re: [Python-Dev] Criticism of execfile() removal in Python3

On 19 June 2014 20:39, Joseph Martinot-Lagarde wrote: > Another way is to open the file in binary, then exec() checks itself if an > encoding is defined in the file. This is what is used in spyder: > > exec(open(file, 'rb').read()) > > Here is the discussion for reference: > https://bitbucket.org/

Re: [Python-Dev] Removal of install_misc command from distutils

On 7 July 2018 at 01:25, Ned Deily wrote: > On Jul 6, 2018, at 19:43, Alexander Belopolsky > wrote: >> I think it will be prudent to get this command back in Python 3.7.1. My >> work-around was to simply copy the 20-something lines that define >> install_misc from Python 3.6 to my setup.py f

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On 9 July 2018 at 17:01, Steve Dower wrote: > On 09Jul2018 0803, Cosimo Lupo wrote: >> >> If one goes to httWhps://www.python.org/downloads >> from a Windows browser, the default >> download URL is for the 32-bit installer instead of the 64-bit one. >> I wonder w

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On 11 July 2018 at 06:39, Steven D'Aprano wrote: > On Wed, Jul 11, 2018 at 05:14:34AM +0300, Ivan Pozdeev via Python-Dev wrote: >> On 11.07.2018 1:41, Victor Stinner wrote: >> >2018-07-09 18:01 GMT+02:00 Steve Dower : >> >>The difficulty is that they *definitely* can use the 32-bit version, and >>

Re: [Python-Dev] [DLFILTER] Exporting Python functions on AIX

On 27 July 2018 at 20:23, Rob Boehne wrote: > Why would a VIM build refer to the export file for python? Because vim includes an optional embedded Python interpreter. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

Re: [Python-Dev] ​improvement on shutil.make_archive

On Mon, 20 Aug 2018 at 15:58, Zhao Lee wrote: > > The current behavior of shutil.make_archive caused many issues , the problem > is mainly on the extracted archive directory hierarchy. These are the proofs: > > https://stackoverflow.com/questions/51914467/directory-hierarchy-issue-when-using-shut

Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?

On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote: > > Hi, > > It's no longer possible to merge any change in the 3.6 branch of > CPython, because the AppVeyor job fails: > https://bugs.python.org/issue34575 > > It seems like AppVeyor has a build cache and this cache is outdated. I > tried to use

Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?

On Wed, 5 Sep 2018 at 12:24, Antoine Pitrou wrote: > For some reason it seems to be located in a hidden directory > (".github/appveyor.yml"). Not the most intuitive decision IMHO. > Travis' own config file ".travis.yml" is still at repository root, which > makes things more confusing. Thanks, ag

Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?

On Wed, 5 Sep 2018 at 14:47, Zachary Ware wrote: > > On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote: > > On Wed, 5 Sep 2018 11:03:48 +0100 > > Paul Moore wrote: > > > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote: > > > > Who ows the "pyth

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

On Fri, 14 Sep 2018 at 23:28, Neil Schemenauer wrote: > > On 2018-09-14, Larry Hastings wrote: > > [..] adding the stat calls back in costs you half the startup. So > > any mechanism where we're talking to the disk _at all_ simply > > isn't going to be as fast. > > Okay, so if we use hundreds of

Re: [Python-Dev] wininst-*.exe files in Lib/distutils/command

They are for the distutils bdist_wininst command (mostly obsolete now, wheels are the preferred binary distribution format these days). The source appears to be in PC\bdist_wininst in the CPython repository. Paul On Thu, 18 Oct 2018 at 15:10, VanL wrote: > > Hi all, > > I am looking into an issue

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Tue, 13 Nov 2018 at 21:02, Victor Stinner wrote: > My plan is to select something like the top five most popular C > extensions based on PyPI download statistics. I cannot test > everything, I have to put practical limits. You should probably also consider embedding applications - these have

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Wed, 14 Nov 2018 at 14:28, Victor Stinner wrote: > > assuming the experiment is successful, forced (as opposed to opt-in) > > migration to the new API would be handled in a gradual, > > No, the current C API will remain available. No one is forced to do > anything. That's not part of my plan.

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Wed, 14 Nov 2018 at 14:39, Paul Moore wrote: > If it is the case that there's no need for any 3rd party code to > change in order to continue working with 3.8+, then I apologise for > the interruption. This is where being able to edit posts, a la Discourse would be useful :-)

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Wed, 14 Nov 2018 at 16:00, Victor Stinner wrote: > > In short, you don't have to modify your C extensions and they will > continue to work as before on Python 3.8. [...] > I hope that "later" we will get a faster CPython using new optimizations there>, only compatible with C extensions compile

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Fri, 16 Nov 2018 at 17:49, Brett Cannon wrote: > And Just to be clear, I totally support coming up with a totally > stripped-down C API as I have outlined above as that shouldn't be > controversial for any VM that wants to have a C-level API. If a stripped down API like this is intended as "

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

> Maybe we should consider finally having that discussion once the governance > model is chosen and before we consider adding a new module as things like > people's inability to access PyPI come up pretty consistently (e.g. I know > Paul Moore also brings this up regularly). I&#x

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, 29 Nov 2018 at 14:56, Benjamin Peterson wrote: > While I'm sympathetic to users in such situations, I'm not sure how much we > can really help them. These are the sorts of users who are likely to still be > stuck using Python 2.6. Any stdlib improvements we discuss and implement > today

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, 29 Nov 2018 at 15:52, Oleg Broytman wrote: > > On Thu, Nov 29, 2018 at 09:36:51AM -0500, Benjamin Peterson > wrote: > > - stdlib modules become a permanent maintenance burden to CPython core > > developers. > >Add ditributions maintainers here. Well, given that "you shouldn't use p

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, 29 Nov 2018 at 16:28, Steve Dower wrote: > My experience is that the first group would benefit from a larger > _standard distribution_, which is not necessarily the same thing as a > larger stdlib. > > I'm firmly on the "smaller core, larger distribution" side of things, > where we as the

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, 29 Nov 2018 at 19:08, Nathaniel Smith wrote: > > On Thu, Nov 29, 2018, 10:32 Antoine Pitrou > >> On Thu, 29 Nov 2018 09:49:32 -0800 >> Nathaniel Smith wrote: >> > >> > There are a lot of challenges to switching to a "standard distribution" >> > model. I'm not certain it's the best option.

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, 29 Nov 2018 at 17:52, Nathaniel Smith wrote: > > On Thu, Nov 29, 2018, 08:34 Antoine Pitrou > >> >> Le 29/11/2018 à 17:25, Steve Dower a écrit : >> > >> > My experience is that the first group would benefit from a larger >> > _standard distribution_, which is not necessarily the same thing

Re: [Python-Dev] Standard library vs Standard distribution?

On Thu, 29 Nov 2018 at 18:09, Steve Dower wrote: > > On 29Nov2018 0923, Antoine Pitrou wrote: > > I think the whole argument amounts to hand waving anyway. You are > > inventing an extended distribution which doesn't exist (except as > > Anaconda) to justify that we shouldn't accept more modules

Re: [Python-Dev] Standard library vs Standard distribution?

On Thu, 29 Nov 2018 at 21:33, Nathaniel Smith wrote: > > On Thu, Nov 29, 2018 at 10:22 AM Antoine Pitrou wrote: > > > > Le 29/11/2018 à 19:07, Steve Dower a écrit : > > > On 29Nov2018 0923, Antoine Pitrou wrote: > > >> I think the whole argument amounts to hand waving anyway. You are > > >> inve

Re: [Python-Dev] Standard library vs Standard distribution?

On Fri, 30 Nov 2018 at 00:17, Steven D'Aprano wrote: > Especially not *Paul's* problems, as I understand he personally is > reasonably satisfied with the stdlib and doesn't use any of those > third-party distros. (Paul, did I get that right?) That's correct. And not just "reasonably satisfied" -

Re: [Python-Dev] Usage of the multiprocessing API and object lifetime

On Tue, 11 Dec 2018 at 15:13, Antoine Pitrou wrote: > On Tue, 11 Dec 2018 15:21:31 +0100 > Victor Stinner wrote: > > > > Pablo's issue35378 evolved to add a weak reference in iterators to try > > to detect when the Pool is destroyed: raise an exception from the > > iterator, if possible. > > That

Re: [Python-Dev] Usage of the multiprocessing API and object lifetime

On Tue, 11 Dec 2018 at 17:50, Pablo Galindo Salgado wrote: > I agree that misusage of the pool should not be encouraged but in this > situation the fact that > this code hangs: > > import multiprocessing > > for x in multiprocessing.Pool().imap(int, ["4", "3"]): > print(x) > > > is a bit worr

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

On Fri, 18 Jan 2019 at 09:52, Steven D'Aprano wrote: > Code-wise, I'm not doing anything with ctypes. > > Language-wise, I'm trying to get a definitive answer of whether or not > id() returning the address of the object should be a guaranteed feature > or not. > > Across the entire Python ecosyste

Re: [Python-Dev] Lost sight

On Sat, 19 Jan 2019 at 10:15, Serhiy Storchaka wrote: > > I have virtually completely lost the sight of my right eye (and the loss > is quickly progresses) and the sight of my left eye is weak. That is why > my activity as a core developer was decreased significantly at recent > time. My apologies

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger wrote: > My recommendation is Option 4 as being less disruptive and more beneficial > than the other options. In the unlikely event that anyone is currently > depending on the reordering methods for the output of _asdict(), the > remediation is t

Re: [Python-Dev] Making PyInterpreterState an opaque type

On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote: > > On Thu, 21 Feb 2019 12:13:51 +0100 > Victor Stinner wrote: > > > > Premature optimization is the root of all evil. Most C extensions use > > premature optimization > > How do you know it's premature? Some extensions _are_ meant for speed.

Re: [Python-Dev] Making PyInterpreterState an opaque type

On Thu, 21 Feb 2019 at 12:12, Antoine Pitrou wrote: > Actually, it would be interesting to have some kind of survey of C > extensions (through random sampling? or popularity?) to find out why the > developers had to write a C extension in the first place and what their > concerns are. Indeed. Th

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 09:21, Inada Naoki wrote: > The document of the optionxform shows example > overrides it to identity function `lambda option: option`. > https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform > > BPO-35838 is issue about optionxform can be c

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 10:06, Inada Naoki wrote: > > On Thu, Mar 7, 2019 at 6:57 PM Paul Moore wrote: > > > > I'm not keen on the term "idempotent" here - I wasn't at all clear > > what it was intended to convey. But from looking at the bug report, I

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 12:42, Steven D'Aprano wrote: > > I'm not keen on the term "idempotent" here - I wasn't at all clear > > what it was intended to convey. But from looking at the bug report, I > > see that it basically means "optionxform should be a function which, > > when applied more than

Re: [Python-Dev] Using CLA assistant for Python contributions

On Fri, 8 Mar 2019 at 02:32, Mariatta wrote: > > Thought I'll be a little more clearer: you'll need to re-sign the CLA only > for your future contributions (aka when you make new pull request to Python). My preference would be to just re-sign the CLA *immediately*, and not wait for when I have a

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 23:58, Greg Ewing wrote: > > Paul Moore wrote: > > There's a subtle difference in the mathematical > > and computing meanings [of idempotent] (around functions > > with side-effects, which aren't a thing in maths) > > Not really an is

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Fri, 8 Mar 2019 at 02:54, Inada Naoki wrote: > > Personally speaking, I think technical jargon is much easier than > normal English idioms or complex English syntax. > > I learned "idempotent" long ago while learning HTTP. On the other hand, > I don't know normal English idioms even 5-year chi

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