[python-committers] Re: Policy around compile-time flags in bugfix releases
On Sun, Mar 01, 2020 at 12:17:30PM -0800, Gregory P. Smith wrote: > FWIW that is a configure flag, not a flag to the compiler, so I see no > problem with this. The default build has not changed, it just exposes > another way to build the interpreter. We've done this in the past with > things like --enable-optimizations and such flags. > > In this case it appears to enable "new" code... though from the looks of > the issues around this one, perhaps that is really old code just being > readded and made available via a flag? That isn't clear to me at a quick > glance on the issues. Just that it used to use TLS, was changed to > ContextVar, and this flag allows it to keep using TLS. Yes, that's pretty much it. The code that looks new is the exact TLS context code that was present from 3.3 to 3.6. This code is cleanly separated from the 3.7 ContextVar code using #ifndef WITH_DECIMAL_CONTEXTVAR. To verify that the TLS code has not changed, checkout the revision before the ContextVar: bc4123b0b380edda774b8bff2fa1bcc96453b440 Compare _decimal.c to 3.7, 3.8 and master. That diff is empty between the #ifdefs. I have verified manually on Linux (3.7, 3.8, 3.9) and Windows (3.8, 3.9) that the default is indeed decimal.HAVE_CONTEXTVAR==True. I don't have a compiler for Windows/3.7 but the diff is the same as for 3.8. Now why the backport? The issue that prompted the flag is this: https://bugs.python.org/issue39776 While the exact cause is yet unknown (it can be anything like a bug in the interpreter unrelated to ContextVars), I would like to be able to tell people in the future to compile --without-decimal-contextvar if they have such an issue and need a hotfix for their production 3.7. Also, due to the size of _decimal.c and the complexity of the context handling code, it is really unpleasant to have large diffs between master and the two previous versions. I understand that Lukasz and Ned will have extra work if something happens, but I don't see how this could be the case here. Stefan Krah ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/OBF4OAKDQ4HSCNBXJBO3DQ4Q3Z4DHGWD/ Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Sat, Nov 03, 2018 at 11:06:12AM -0700, Barry Warsaw wrote: > On Nov 2, 2018, at 20:24, Tim Peters wrote: > > > Nevertheless, I probably won't vote - I object to public ballots on > > principle. That's been raised by others, so I won't repeat the > > arguments, and I appear to be very much in a minority here. > > I also prefer private ballots on principle, but I’ll still vote if they are > public. I don’t completely buy into the rationale in PEP 8001 on why they > must be public. Same here. I don't think it's that much of a minority (and I'm concerned that Tim may not vote because of this). Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote: > On 11/03/2018 03:55 AM, Paul Moore wrote: > > >Frankly, I feel pretty disenfranchised by the process > >at the moment. > > +1 I wouldn't go as far as disenfranchised, but just this thread made it clear to me that taking in information is at least 10x faster if presented on a mailing list. Discourse feels like eating soup with a fork, especially now that the volume is higher. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] discuss.python.org participation
On Wed, Oct 17, 2018 at 02:30:33PM +0100, Łukasz Langa wrote: > > I find the presentation of threaded conversations in linear format to be > > confusing, figuring out what I have and have not read to be difficult, and > > the overall frustration to not be worth it. > > Are there any linear-formatted communication methods that you find more > comfortable? For discussing a single PEP honestly I'd find even Mediawiki - not any Wiki, exactly the one used at Wikipedia! - more suitable. There'd need to be a tacit understanding that only the PEP author is allowed to edit. Discourse gets more tolerable if one disables Javascript in uBlockOrigin and adds a filter for loading pictures. But I can't login without Javascript, so it's not a great solution. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] discuss.python.org participation
On Fri, Oct 12, 2018 at 11:55:32AM -0700, Brett Cannon wrote: > I will also note that Benjamin, Larry, and Raymond can be a bit quiet at > times and so they may not have signed up yet because they have not had > anything to say to compel them to create accounts (Stefan has already > stated he doesn't like this idea so I'm assuming that might be why he has > not signed up yet). FTR, I have signed up, but Jack's original point still stands. Very few people apart from PEP stakeholders are participating, so merely signing up should not be considered an endorsement of Discourse. Even participating shouldn't, because folks might choose their battles, especially in a pre-election situation. In order to get an overview if I'm the only one: I've searched for people's opinions on Discourse, and its reputation is far from spotless even among people who explicitly *want* a web forum. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] discuss.python.org participation
On Tue, Oct 09, 2018 at 11:20:08PM -0400, Jack Diederich wrote: > I don't think it was deliberate, but it looks like the new format is > actively discouraging everyone but those most deeply invested with the most > free time from participating. I'm actively discouraged by various visual effects on the Discourse site. Fade-in, progress spinner, moving elements when scrolling, long load times. There are recurrent discussions about attracting developers. As far as C developers are concerned, I doubt that this forum is going to attract any. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Non-active devs, become active! (was: python-committers is dead, long live discuss.python.org)
On Sat, Sep 29, 2018 at 11:00:48AM +0100, Łukasz Langa wrote: > > Sorry if I misunderstand this, but is the plan to moderate *core developers* > > on python-committers? > > If you label it with an abstract term like this, it sounds like we just > formed the Python Thought Police ;-) Well, it gets worse. :-) I mean, moving the list *just* before the election and having a simultaneous discussion about who is considered a core developer might evoke associations with gerrymandering away the non-active people, who are probably more likely not to move to discourse or even miss this thread. You can all have the best motives, but I'm really taken aback by these developments. Has this concern not been mentioned at the summit? Perhaps that is what you get if only recently active devs are invited. I strongly suggest that the vote-eligibility and governance discussions take place here. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, Sep 29, 2018 at 02:01:20PM +0200, Antoine Pitrou wrote: > > A couple of years ago http://news.individual.net/index.php (maintained > > by FU-Berlin (university)) worked well. > > Does it provide mailing-list mirrors? It's not obvious by the description. Ah yes, it only has comp.lang.python <==> python-list, which is useless of course: ftp://ftp.fu-berlin.de/doc/news/fu-berlin/active My good memories of the service were for other groups like sci.crypt. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, Sep 29, 2018 at 12:11:12PM +0200, Antoine Pitrou wrote: > On the more general idea of Discourse, I'm all for experimenting as I do > agree with the advantages you mention. Like Serhiy I also like my Gmane > workflow, but Gmane has worked less and less well recently, and admins > basically don't respond anymore (for example, it's become impossible to > start posting to new mailing-lists, since the autoresponder doesn't work > anymore). A couple of years ago http://news.individual.net/index.php (maintained by FU-Berlin (university)) worked well. It's not free though (EUR 10,- per year). Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, Sep 29, 2018 at 10:40:02AM +0100, Łukasz Langa wrote: > > Especially on the eve of critical governance discussions that will heavily > > impact the future of python-dev. > > Ironically it's the very gravity of those upcoming discussions that made us > decide to move fast on this. Sorry if I misunderstand this, but is the plan to moderate *core developers* on python-committers? Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, Sep 29, 2018 at 06:53:58PM +1000, Nick Coghlan wrote: > On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: > > I’m all for supporting the next generation of developers, but not > > necessarily at the expense of *decades* of established workflow for current > > developers. Moving to Discourse breaks this and proliferates browser tab > > syndrome. It’s an experiment worth conducting, but I do think it’s a bit > > cavalier to shut down python-committers without further discussion. > > > > Especially on the eve of critical governance discussions that will heavily > impact the future of python-dev. Indeed. > This is exactly the kind of arbitrary decision making by an insufficiently > representative group that led to us banning making any binding decisions at > language summits: their in-person nature means that they're inherently > exclusive environments that lead to requirements being overlooked and > decisions being made without involving most of the people affected. I'm surprised how decisions are made on summits as well. It's quite telling that already 6 core devs, most of whom have contributed huge amounts of code, apparently have not been at that exclusive summit and have indicated that they are uncomfortable with that decision. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Language moratorium
On Thu, Jul 19, 2018 at 10:24:17AM +0200, Victor Stinner wrote: > On of the reason which motivated Facebook and Instagram to migrate > from Python 2.7 directly to 3.5 was to get the new async and await > keywords. So new syntaxes can be the new "killer feature" of a > specific Python release, at least for some use cases. This is definitely true. But Python is very strong now, much stronger than during the last moratorium. So in general I think making a decision for a 12 months moratorium should not be viewed by the community as a weak "policy of not having a policy", but as a signal of strength. Suppose people take long vacations, take a distance to the whole PEP 572 situation, perhaps reevaluate; there is always the possibility of overlooking a very simple solution that becomes apparent after a while. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Language moratorium
On Wed, Jul 18, 2018 at 11:47:22AM -0700, Barry Warsaw wrote: > On Jul 18, 2018, at 09:11, Stefan Krah wrote: > > > if I remember correctly, we had a moratorium for language changes around > > versions 3.2-3.3. I think during that time relatively few BDFL-level > > decisions were required. > > > > Perhaps we could have one again, say for 12 months so we can figure things > > out. Other Python implementations may welcome the moratorium so they can > > catch up. > > I agree that we’ll effectively have language moratorium until we have a new > governance structure. But let me ask, what do you propose to do about PEP > 572? That’s already been accepted, but not yet implemented. Would it be > exempt from the moratorium or scoot in under the wire? That is a tough question. :) I meant a moratorium for new decisions and subsequent changes, so I kind of assumed PEP 572 would go in. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Language moratorium
Hi, if I remember correctly, we had a moratorium for language changes around versions 3.2-3.3. I think during that time relatively few BDFL-level decisions were required. Perhaps we could have one again, say for 12 months so we can figure things out. Other Python implementations may welcome the moratorium so they can catch up. During that time we could just informally listen very closely to Guido if anything requires a decision and he happens to be around. But there may be no decisions at all. And yes, I guess we can successfully attempt to be nice, especially to him (thanks for this wonderful language!). Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Comments on moving issues to GitHub
On Sun, May 20, 2018 at 10:56:21AM +0200, Antoine Pitrou wrote: > If that's on the table, it seems to me that categorization, sorting and > filtering on GitHub issues is rather poor, while the basic UI experience > (editing messages, etc.) is better. Also, I think customization (e.g. > of the default view) is basically inexistent. Also search via Google "site:bugs.python.org " usually gives quite nice results, while the same for GitHub issues usually does not work at all (far too many unrelated results). Then there's the original promise of the GitHub migration that in the case of GH bankruptcy or a sudden lockdown the tracker would still be available. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?
+0.5 Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official way to check out a tag?
On Tue, Jan 23, 2018 at 11:29:49AM +0100, Antoine Pitrou wrote: > > This just worked in mercurial, but doing the above results in a > > compile error: > > > >threadmodule.c:1355: multiple definition of `PyInit__thread' > > Did you try "make distclean"? Thanks, that works! I assumed that I mishandled git and completely overlooked the easier solution. :-) Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
On Tue, Dec 12, 2017 at 02:04:42PM +0100, Christian Heimes wrote: > If you don't the trust closed-source Yubico hardware, there is plenty of > other hardware out. https://www.nitrokey.com/ is good German engineering > with fully open-sourced hardware and software. > > Adam has compiled a nice list of U2F and 2FA tokens, too. > https://www.imperialviolet.org/2017/10/08/securitykeytest.html The PSF then also must provide developer laptops along with the usb thingy. I would assume that in extremely security conscious enviroments plugging *anything* into an USB port is forbidden (if there are USB ports at all). Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2FA: only needed at the *first* GitHub login, not needed for commits
On Tue, Dec 12, 2017 at 10:42:56AM +0100, Victor Stinner wrote: > Let me explain how GitHub uses 2FA. > > * Let's say that you are not logged on GitHub (or log out to test yourself). > * Log in GitHub: enter email and password, then you are asked for an > "Authentication code". > * You're logged in, congrats :-) > * Close Firefox > * Open Firefox, go to GitHub: you are already logged in. No more > password nor Authentication code asked. Well, my security model is different. I have full disk encryption with a long passphrase. I shut down the computer when I leave, so I have to enter that passphrase several times a day. I have an encrypted text file that contains per-website passwords, protected by another long passphrase. I have to decrypt that file at least once after booting. Finally, due to the garbage that modern browsers store (run rsync and watch what is accumulated even in a day), I clear all the history etc. when Firefox is closed. This means that I have to log in ***multiple times into GitHub per day***. My GitHub password should be only on GitHub, so when there's a breach GitHub is already pwned (which it has been in the past but the prevailing doctrine does not permit to mention it, and if anyone dares to he is ignored). Given the snake oil history in crypto products (Crypto AG, RSA SecureID, Infineon chips, closed source in YubiKey), quite franky MY security model won't allow inserting such a product into an USB slot. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
On Mon, Dec 11, 2017 at 08:00:37AM -0500, Alex Gaynor wrote: > It's possible to generate a key on a regular computer and transfer it to a > YubiKey if you prefer. (It's not like software key generation has been > flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life). Thanks, I did not know that. I'm still against overuse of public key cryptography (also in home banking). The reason is simply that *if* you're the victim of a key generation screwup that is not yet publicly known, you have a lot of explaining to do. This is one of the standard reasons many cryptography experts give against home banking using card readers. It puts all the responsibility on the customer/user. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
On Mon, Dec 11, 2017 at 01:47:50PM +0100, Victor Stinner wrote: > 2017-12-11 13:29 GMT+01:00 Stefan Krah <ste...@bytereef.org>: > > Ssh isn't available everywhere, I don't want to install an app or give > > out my phone number to half of Silicon Valley [1]. > > SMS and FreeOTP are just a few options that you have to generate/get OTP. > > I suggest to use Yubikey. It doesn't need to install an app or to give > your phone number, but it costs 50$. The advantage is that you can use > it to store your SSH and GPG keys. I'm not a fan of hardware key generation. :-) https://en.wikipedia.org/wiki/YubiKey "In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] Yubico publicized a tool to check if a Yubikey is affected and replaces affected tokens for free.[21]" ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
On Mon, Dec 11, 2017 at 12:19:46PM +0100, Victor Stinner wrote: > 2017-12-11 12:05 GMT+01:00 Stefan Krah <ste...@bytereef.org>: > > https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise > > https://gist.github.com/peternixey/1978249 > > > > I'm pretty sure my long GitHub-only password is more secure than several > > key-gen algorithms on smart cards ... > > I wouldn't comment the attack on RSA SecurID, but I disagree that a > single password is stronger than password + OTP. > > The principle of the 2-factor auth is that the attacker has to break > two auths rather than only one. So even if you break RSA SecurID, the > hacker still has to break your ultra secure GitHub-only password ;-) Well sure, but the bureaucracy increases and ultimately the entity being protected is still a ruby on rails web app (at least that's what I have heard, I may be wrong). Ssh isn't available everywhere, I don't want to install an app or give out my phone number to half of Silicon Valley [1]. Buying a GitHub-only sim card would be an option still... Stefan Krah [1] Which is probably the real reason why 2FA is so popular. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
On Mon, Dec 11, 2017 at 03:46:23PM +0530, Kushal Das wrote: > On a related note, we should ask all committers to enable 2FA and then > make the organization to 2FA only on github. That is a standard policy of > many organizations on github. https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise https://gist.github.com/peternixey/1978249 I'm pretty sure my long GitHub-only password is more secure than several key-gen algorithms on smart cards ... Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Hacktoberfest
On Thu, Sep 28, 2017 at 09:21:04AM -0700, Mariatta Wijaya wrote: > October is hacktoberfest (https://hacktoberfest.digitalocean.com/) > In the month of October, people can sign up and contribute to open source > projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll earn a > limited edition T-Shirt. This may sound grumpy to some, but I'm against gamification of open source and also against giving GitHub a special role. Any open source activity is somehow credited to or associated with some commercial entity. What has changed in the last 7-10 years? Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Discussions on PRs
On Mon, Feb 13, 2017 at 08:48:08AM -0500, Donald Stufft wrote: > It looks like the person in question is commenting on the issue tracker. Is *now* commenting on the issue tracker as opposed to when I wrote the mail. But hey, it sounds much more impressive the way you phrased it ... Stefan ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Discussions on PRs
On Mon, Feb 13, 2017 at 10:33:58AM +0100, M.-A. Lemburg wrote: > With the move to Github, I'm seeing a move away from > discussions on the issue tracker towards discussions on > pull requests. > > Example: https://github.com/python/cpython/pull/4 > > Is this something we should encourage or better ask the OPs > to open a ticket on the tracker first and reference the PR > there ? > > Discussion on the PRs would then only be for code review > aspects. I agree completely. I find the whole workflow very distracting. What I see now is that patches without comments emerge really fast: https://github.com/python/cpython/pull/65 Actually I expected this competitive atmosphere, because that's what GitHub encourages. Realistically, my workload tripled for this one particular issue compared to our previous workflow. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] PVS-Studio licences
As Serhiy pointed out, there is no new issue: A diff exists in #27587. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] PVS-Studio licences
Hello, as many here know, the recent comparison of Python/Ruby w.r.t. static analysis done by viva64.com (PVS-Studio) accidentally included the external packages that are automatically downloaded in the scripted build (like OpenSSL). I've notified viva64.com, and they were nice enough to do a second analysis, this time done with the Linux version of PVS-Studio: http://www.viva64.com/en/b/0418/ They found another issue. :) Andrey Karpov has offered a key for PVS-Studio for the Python Team (python.org), valid for half a year. It's a *single shared key*: We have to keep it secret and it's obviously only for Python core development. If you want it, mail me privately -- similar to the MSDN licences. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Xavier de Gaye as a core developer
Victor Stinner gmail.com> writes: > I propose to promote Xavier de Gaye as a Python core developer. > > I noticed that he is proposing good patches since a lot time ago > (first one around 2010! issue #9250). He now looks to be motivated to > help porting CPython to Android. IMHO it's a good thing to support > this platform. It's a common user request, Android platform becomes > more and more popular. +1. The Android patches are very good -- he would be the ideal maintainer. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] CFFI is slow
Larry Hastings hastings.org> writes: > 2. How important is this speed difference? I suppose the answer, > as always, is "it depends". It depends on how often you call the > C library, and how long you spend in the routine when you get > there. Certainly a benchmark for library X is a worst-case > scenario; in real-world code, for most libraries, perhaps the > performance of the glue code isn't crucial. Several of the early adopters of library X were the sqlalchemy people, who absolutely had real-world issues. > Of course this is all academic. I absolutely don't think we can > get rid of the C API, or even modify it in any meaningful way that > would let us abstract away implementation details like reference > counting. As I said in my original email, this magic wand simply > doesn't exist./arry Sorry for misquoting, indeed you said that. I was a little concerned that CFFI was mentioned by several people as a solution and wanted to highlight the drawbacks. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] CFFI is slow (was: Re: Redoing the C API?)
Stefan Krah bytereef.org> writes: > We're talking about a slowdown of at least an order of magnitude here: > > https://mail.python.org/pipermail/python-dev/2013-December/130772.html > > I think people who don't need the C-API can use PyPy. Or, of course, use CPython with Numba, which handles an ever increasing amount of traditional bottlenecks: For example, it is possible to write a "native speed" transpose function for NumPy arrays in plain Python. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] CFFI is slow (was: Re: Redoing the C API?)
Larry Hastings hastings.org> writes: > If we could wave a magic wand and get all extension authors to > switch to writing their extensions in Python and using cffi, we > should absolutely do it. CFFI is slow. This would effectively kill one of the strongholds of CPython. IMO CPython's C-API is the best out there and a large part of Python's success. We're talking about a slowdown of at least an order of magnitude here: https://mail.python.org/pipermail/python-dev/2013-December/130772.html I think people who don't need the C-API can use PyPy. Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Making the PSF CoC apply to core developers
Thomas Wouters python.org> writes: > On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah bytereef.org> wrote:Wondering what a Monty Python episode about CoCs would look like ... > > I think you're misunderstanding Monty Python's humour if you think they'd have made one about the CoC :) They were very much for punching upward, not kicking downward. They ridiculed themselves and the environments they came from, not those thinking of others. Certainly not measures taken to make the playing field more open and clear for everyone. (Contrast with, say, South Park, which inherited Monty Python's visual humour with an entirely different stance on social responsibility ;P) Sorry, this is a huge strawman. Core developers are already very much on a level playing field. If you want, I can post a IRC log where people who are undoubtedly in favor of the CoC a) gossip about two core devs, b) ask if said core-devs "had any influence", and c) make fun of the works of said core-devs. Some of these people have impeccable manners on mailing lists, and not addressing Machiavellianism is one of the most glaring flaws of this CoC. I'm quite upset about you bringing in "kicking downward" (even if qualified by a smiley). Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Making the PSF CoC apply to core developers
M.-A. Lemburg egenix.com> writes: > > This particular CoC specifically addresses conference misbehavior, which is > > fine. > > The PSF CoC has a focus on community interaction, not on conferences. > It's different from eg. the PyCon US conference CoC. Consider me schooled. :) > Mix all that with a good dose of Monty Python's don't-take-yourself- > too-seriously, add some Tim Peters takes-one-to-know-one-ly and > I believe we can all be on the same page > > Hmm, perhaps we ought to make reading some Python humor a > prerequisite for core developers instead... I would throw in "Life of Brian" (in particular the "we are all individuals" dialogue) and "Yes Minister" (don't get me started on that one). Wondering what a Monty Python episode about CoCs would look like ... Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Making the PSF CoC apply to core developers
Brett Cannon python.org> writes: > I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. > Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change. When I started here, the PSF and python-dev were considered disjoint entities (quoting MvL from memory). Looking at https://www.python.org/psf/records/board/history/ , half of the current directors have never appeared anywhere on the python-dev infrastructure, most notably on python-checkins. Contrast this with e.g. the period of 2003-2004, where I still know all of the directors even though I did not know Python at that time! Some very prolific contributors do not appear in the list of PSF members at all. This particular CoC specifically addresses conference misbehavior, which is fine. No CoC short of an 800 page volume can address the many forms of human shortcomings in more complex situations. I'm not going to go into detail here, but "suaviter in modo, fortiter in re", even though usually depicted as desirable behavior, can easily lead to more stagnation and friction than occasional superficial impoliteness. I think python-dev should remain an entity where interested people can just come and "hack on something" instead of being overburdened by regulations. As for the devguide, briefly mentioning the categorical imperative should suffice. ;) Stefan Krah ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] hg clone cpython newrepo aborts
Senthil Kumaran sent...@uthcode.com wrote: warning: copy source of 'Modules/_threadmodule.c' not in parents of 60ad83716733 warning: copy source of 'Objects/bytesobject.c' not in parents of 64bb1d258322 warning: copy source of 'Objects/stringobject.c' not in parents of 357e268e7c5f 9872 files, 83957 changesets, 185453 total revisions 3 warnings encountered! The warnings are known and apparently harmless: http://mail.python.org/pipermail/python-dev/2012-August/121390.html 83941: empty or missing Lib/idlelib/idle_test/@README.txt Lib/idlelib/idle_test/@README.txt@83941: 7573717b9e6f in manifests not found 3 integrity errors encountered! (first damaged changeset appears to be 83941) This is new though. Stefan Krah ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Pending contributor agreement
Serhiy Storchaka storch...@gmail.com wrote: Robert Xiao (nneonneo) http://bugs.python.org/issue17051 The patch is trivial, so you can commit without an agreement. Stefan Krah ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] SVN repository is now read-only
Georg Brandl g.bra...@gmx.net wrote: Antoine and me are starting the conversion now (it takes quite a while to get the SVN repo and convert it, so we're doing it overnight). The majority of the work will be done tomorrow: pushing the new repositories live, enabling and testing all integration into python.org services and probably more work on the new devguide. Please join us in #python-dev if you have questions. Would it interfere with your plans if I commit an svnmerge for py3k-cdecimal? Or is this now impossible? Thanks, Stefan Krah ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
