Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: > Hello all, > > PyCon, and the Python Language Summit, is nearly upon us. We have a good > number of people confirmed to attend. If you are intending to come to the > language summit but haven't let me know please do so. > > The agenda of topics for discussion so far includes the following: > > * A report on pypy status - Maciej and Armin > * Jython and IronPython status reports - Dino / Frank > * Packaging (Doug Hellmann and Monty Taylor at least) Since the time I suggested we add packaging to the agenda, Nick has set up a separate summit meeting for Friday evening. I don't know if it makes sense to leave this on the agenda for Wednesday or not. Nick, what do you think? Doug > * Cleaning up interpreter initialisation (both in hopes of finding areas > to rationalise and hence speed things up, as well as making things > more embedding friendly). Nick Coghlan > * Adding new async capabilities to the standard library (Guido) > * cffi and the standard library - Maciej > * flufl.enum and the standard library - Barry Warsaw > * The argument clinic - Larry Hastings > > If you have other items you'd like to discuss please let me know and I can > add them to the agenda. > > All the best, > > Michael Foord > > -- > http://www.voidspace.org.uk/ > > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing > http://www.sqlite.org/different.html > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 2, 2013, at 11:41 AM, Nick Coghlan wrote: > On Fri, Mar 1, 2013 at 9:39 AM, Doug Hellmann wrote: >> >> On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: >> >>> Hello all, >>> >>> PyCon, and the Python Language Summit, is nearly upon us. We have a good >>> number of people confirmed to attend. If you are intending to come to the >>> language summit but haven't let me know please do so. >>> >>> The agenda of topics for discussion so far includes the following: >>> >>> * A report on pypy status - Maciej and Armin >>> * Jython and IronPython status reports - Dino / Frank >>> * Packaging (Doug Hellmann and Monty Taylor at least) >> >> Since the time I suggested we add packaging to the agenda, Nick has set up a >> separate summit meeting for Friday evening. I don't know if it makes sense >> to leave this on the agenda for Wednesday or not. >> >> Nick, what do you think? > > I think it's definitely worth my taking some time to explain my goals > for the Friday night session, and some broader things in terms of > where I'd like to see packaging going, but a lot of the key packaging > people aren't involved in Python language development *per se*, and > hence won't be at the language summit. OK, a summary seems like a good idea. > > There's also one controversial point that *does* need to be raised at > the summit: I would like to make distutils-sig the true authority for > packaging standards, so we can stop cross-posting PEPs intended to > apply to packaging in *current* versions of Python to python-dev. The > split discussions suck, and most of the people that need to be > convinced in order for packaging standards to be supported in current > versions of Python aren't on python-dev, since it's a tooling issue > rather than a language design issue. Standard lib support is necessary > in the long run to provide a good "batteries included" experience, but > it's *not* the way to create the batteries in the first place. Until > these standards have been endorsed by the authors of *existing* > packaging tools, proposing them for stdlib addition is premature, but > has been perceived as necessary in the past due to the confused power > structure. +1 -- anything to reduce the confusion about where to get involved :) > > This means that those core developers that want a say in the future > direction of packaging and distribution of Python software would need > to be actively involved in the ongoing discussions on distutils-sig, > rather than relying on being given an explicit invitation to weigh in > at the last minute through a thread (or threads) on python-dev. The > requirement that BDFL-delegates for packaging and distribution related > PEPs also be experienced core developers will remain, however, as > "suitable for future stdlib inclusion" is an important overarching > requirement for packaging and distribution standards. Such delegates > will just be expected to participate actively in distutils-sig *as > well as* python-dev. > > Proposals for *actual* standard library updates (to bring it into line > with updated packaging standards) would still be subject to python-dev > discussion and authority (and would *not* have their Discussions-To > header set). Such discussions aren't particularly relevant to most of > the packaging tool developers, since the standard library version > isn't updated frequently enough to be useful to them, and also isn't > available on older Python releases, so python-dev is a more > appropriate venue from both perspectives. > > At the moment, python-dev, catalog-sig and distutils-sig create an > awkward trinity where decision making authority and the appropriate > venues for discussion are grossly unclear. I consider this to be one > of the key reasons that working on packaging issues has quite a high > incidence of developer burnout - it's hard to figure out who needs to > be convinced of what, so it's easy for the frustration levels to reach > the "this just isn't worth the hassle" stage (especially when trying > to bring python-dev members up to speed on discussions that may have > taken months on distutils-sig, and when many of the details are > awkward compromises forced by the need to support *existing* tools and > development processes on older versions of Python). Under my proposal, > the breakdown would be slightly clearer: > > distutils-sig: overall authority for packaging and distribution > related standards, *including* the interfaces between index servers > (such as PyPI) and automated tools. If a PEP
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
Excerpts from R. David Murray's message of 2016-06-09 08:41:01 -0400: > On Thu, 09 Jun 2016 13:12:22 +0100, Cory Benfield wrote: > > The Linux kernel can���t change this stuff easily because they mustn���t > > break userspace. Python *is* userspace, we can do what we like, and we > > I don't have specific input on the rest of this discussion, but I disagree > strongly with this statement. The environment in which python programs > run, ie: the python runtime and standard library, are *our* "userspace", > and the same constraints apply to our making changes there as apply > to the linux kernel and its userspace...even though we knowingly break > those constraints from time to time[*]. > > --David > > [*] Which I think the twisted folks at least would argue we shouldn't > be doing :) I agree with David. We shouldn't break existing behavior in a way that might lead to someone else's software being unusable. Adding a new API that does block allows anyone to call that when they want guaranteed random values, and the decision about whether to block or not can be placed in the application developer's hands. Christian's points about separating the various cases and solutions also make sense. Doug ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
> On Jun 9, 2016, at 9:27 AM, Cory Benfield wrote: > > >> On 9 Jun 2016, at 13:53, Doug Hellmann wrote: >> >> I agree with David. We shouldn't break existing behavior in a way >> that might lead to someone else's software being unusable. > > What does ‘usable’ mean? Does it mean “the code must execute from beginning > to end”? Or does it mean “the code must maintain the expected invariants”? If > it’s the second, what reasonably counts as “the expected invariants”? The code must not cause the user’s computer to completely freeze in a way that makes their VM appear to be failing to boot? > > The problem here is that both definitions of ‘broken’ are unclear. If we > leave os.urandom() as it is, there is a small-but-nonzero change that your > program will hang, potentially indefinitely. If we change it back, there is a > small-but-nonzero chance your program will generate you bad random numbers. > > If we assume, for a moment, that os.urandom() doesn’t get called during > Python startup (that is that we adopt Christian’s approach to deal with > random and SipHash as separate concerns), what we’ve boiled down to is: your > application called os.urandom() so early that you’ve got weak random numbers, > does it hang or proceed? Those are literally our two options. I agree those are the two options. I want the application developer to make the choice, not us. > > These two options can be described a different way. If you didn’t actually > need strong random numbers but were affected by the hang, that program failed > obviously, and it failed closed. You *will* notice that your program didn’t > start up, you’ll investigate, and you’ll take action. On the other hand, if > you need strong random numbers but were affected by os.urandom() returning > bad random numbers, you almost certainly will *not* notice, and your program > will have failed *open*: that is, you are exposed to a security risk, and you > have no way to be alerted to that fact. > > For my part, I think the first failure mode is *vastly* better than the > second, even if the first failure mode affects vastly more people than the > second one does. Failing early, obviously, and safely is IMO much, much > better than failing late, silently, and dangerously. > > I’d argue that all the security disagreements that happen in this list boil > down to weighting that differently. For my part, I want code that expects to > be used in a secure context to fail *as loudly as possible* if it is unable > to operate securely. And for that reason: > >> Adding a new API that does block allows anyone to call that when >> they want guaranteed random values, and the decision about whether >> to block or not can be placed in the application developer's hands. > > I’d rather flip this around. Add a new API that *does not* block. Right now, > os.urandom() is trying to fill two niches, one of which is security focused. > I’d much rather decide that os.urandom() is the secure API and fail as loudly > as possible when people are using it insecurely than to decide that > os.urandom() is the *insecure* API and require changes. > > This is because, again, people very rarely notice this kind of new API > introduction unless their code explodes when they migrate. If you think you > can find a way to blow up the secure crypto code only, I’m willing to have > that patch too, but otherwise I really think that those who expect this code > to be safe should be prioritised over those who expect it to be 100% > available. > > My ideal solution: change os.urandom() to throw an exception if the kernel > CSPRNG is not seeded, and add a new function for saying you don’t care if the > CSPRNG isn’t seeded, with all the appropriate “don’t use this unless you’re > sure” warnings on it. All of which fails to be backwards compatible (new exceptions and hanging behavior), which means you’re breaking apps. Introducing a new API lets the developers who care about strong random values use them without breaking anyone else. Doug ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split Misc/NEWS into individual files
Excerpts from Barry Warsaw's message of 2017-02-22 11:42:57 -0500: > On Feb 22, 2017, at 01:27 PM, Victor Stinner wrote: > > >OpenStack happily fixed this issue one or two years ago with "reno": > >https://pypi.python.org/pypi/reno > > reno looks interesting but there is at least one thing I think would need > changing for us. Aside: I'm not super psyched about its requiring YAML files > for its input. Their structure can be fairly arcane for drive-by > contributors, but I suppose with good documentation and a CI gate, we can live > with that. > > I'm also not thrilled with having to learn yet another command line tool to > submit changes to Python. > > The main dissonance for us is I think the sections that reno supports > > https://docs.openstack.org/developer/reno/usage.html > > Our release notes have different sections: > > * Core and Builtins > * Extension Modules > * Library > * Windows > * C API > * Documentation > * Build > * Tools/Demos > * Tests > (others?) > > I don't know if those are configurable in reno or it would require a fork, but > I'd like to preserve that organizational structure. If reno can also help > wrap long lines, enforce/encourage bpo-* mentions, and clean up whitespace, > then I'm for trying it out. > > -Barry FWIW, I've been planning to work on a demonstration patch using reno for cpython so we can identify feature gaps like this. I have permission to work on this as part of my day job, to make reno suitable for both communities. I'm at a conference this week, but will try to put something together after I get back to work, and definitely before the language summit at PyCon. We have a patch up for review to support configuring the sections, including the keys within the input file and the titles in the output, so that should take care of that gap. The use of lists within each section is also something I think we could either make smart or explicitly configurable, and that would simplify the file format to just section keys and an RST blob. The "report" command assembles the RST embedded in the YAML and then passes it through docutils to produce text output. In the process, it does wrap lines, standardize bullets for lists, etc. For an example of the output, you can look at the release announcement for nova from earlier today [1]. The content of that email up to the git log output at the end was produced by reno based on the input files in [2]. Doug [1] http://lists.openstack.org/pipermail/release-announce/2017-February/000784.html [2] http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/notes ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython specific code in inspect module
On May 19, 2009, at 10:21 PM, David Stanek wrote: On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson > wrote: 2009/5/19 Michael Foord : I have IronPython specific versions of several of these functions which use .NET reflection and inspect could fallback to if sys.platform == 'cli'. Would it be ok for me to add these to the inspect module? Obviously the tests would only run on IronPython... The behaviour for CPython would be unaffected. [...] However that still leaves the question of how to handle putting code like this in. Should we ask that all code be implementation-independent as much as possible from the original authors? Do all all changes against the stdlib have to be run against several implementations? Should we sprinkle if switches all over the codebase for different implementations, or should new support files be added? It seems that using a technique similar to dependency injection could provide some value. DI allows implementations conforming to some interface to be injected into a running application without the messy construction logic. The simple construction-by-hand pattern is to create the dependencies and pass them into the dependent objects. Frameworks build on top of this to allow the dependencies to be wired together without having any construction logic in code, like switch statements, to do the wiring. I think a similar pattern could be used in the standard library. When the interpreter goes through its normal bootstrapping process in can just execute a module provided by the vendor that specifies the platform specific implementations. Some defaults can be provided since Python already has a bunch of platform specific implementations. An over simplified design to make this happen may look like: 1. Create a simple configuration that allows a mapping of interfaces to implementations. This is where the vendor would say when using inspect you really should be using cli.inspect. That sounds like a plugin and the "strategy" pattern. Tarek is doing some work on providing a standard plugin mechanism as part of the work he's doing on distutils, isn't he? 2. Add executing this new configuration to the bootstrapping process. Maybe I misunderstand, but wouldn't it make more sense to initialize the platform-specific parts of a module when it is imported rather than bring in everything at startup? Are we only worried about interpreter-implementation-level dependencies, or should there be a way for all platform-specific features to be treated in the same way? There are quite a few checks for Windows that could be moved into the platform-specific modules if there was an easy/standard way to do it. Doug 3. Add generic hooks into the library where needed to load the dependency instead of platform specific if statements. 4. Rip out the platform specific code that is hidden in the if statements and use that as the basis for the sane injected defaults. 5. Document the interfaces for each component that can be changed by the vendor. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python on PowerPC?
On May 20, 2009, at 3:31 AM, Chris Plasun wrote: Hi, I'm to develop console apps on a Linux embedded PowerPC board (Freescale MPC8313). Is there a Python release for the PowerPC platform? We used to run a version of the interpreter on PPC for a microcontroller board we had, but we built it ourselves. Have you tried building from source? It might Just Work. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sep 27, 2009, at 6:00 PM, Michael Foord wrote: Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. I've used argparse and really like it. I could also have done with the subcommand support in recent changes to unittest. +1 for inclusion. +1 as well. I wish I had been able to use this library for a recent project using sub-commands. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
On Oct 5, 2009, at 4:59 AM, Ben Finney wrote: Fredrik Lundh writes: it's revews like this that makes me wonder if releasing open source is a good idea: no egg - worst seen ever, remove it from pypi or provide an egg (jensens, 2009-10-05, 0 points) Heh. If harsh, uninformed responses make you wonder whether it's worth doing free software, then you're in the wrong social philanthropy movement. Make the software good quality, release it in the standard format (in this case, a Distutils ‘sdist’ on PyPI), respond in a timely manner to genuine requests for help. Eggs are certainly not a requirement, nor is responding to hostility like the above comment. If you *want* to respond, you can politely direct them to http://docs.python.org/install/> where they can learn how to install Python distributions — no mention of eggs at all. Package owners are not allowed to comment on their own PyPI packages, so responding to comments requires tracking down the person who left them and contacting them in some other way. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new way to configure logging
On Oct 8, 2009, at 10:47 AM, Vinay Sajip wrote: I've had bad experiences in the past with dictionary-based APIs. They seem "simpler" in the short run, because the user "only needs to create some dictionaries". Once the complexity of that nested dictionary grows to a certain point, though, one has to refer back to documentation constantly to make sure Fair point, and agreed that the schema needs some care, here's roughly what I'm thinking of as an example configuration (YAML): formatters: brief: format: '%(levelname)-8s: %(name)-15s: %(message)s' precise: format: '%(asctime)s %(name)-15s %(levelname)-8s %(message)s' filters: allow_foo: name: foo handlers: console: class : logging.StreamHandler formatter: brief level : INFO stream : sys.stdout filters: [allow_foo] file: class : logging.handlers.RotatingFileHandler formatter: precise filename: logconfig.log maxBytes: 1024 backupCount: 3 debugfile: class : logging.FileHandler formatter: precise filename: logconfig-detail.log mode: a loggers: foo: level : ERROR handlers: [debugfile] spam: level : CRITICAL handlers: [debugfile] propagate: no bar.baz: level: WARNING root: level : DEBUG handlers : [console, file] It's not too deeply nested, and I can't see any need for it being more deeply nested. It more or less mirrors the way you'd have to write the corresponding ConfigParser-compatible configuration, but if you use a dict as a common format, you have the benefits which I mentioned of supporting JSON, YAML or Python code in a Django settings.py. Yes, that makes sense. the structure conforms to the "schema". Building a simple config tree using light-weight classes with documented APIs tends to be more sustainable in the long run. When you say 'config tree using light-weight classes', I presume you mean a parallel set of classes to the actual logging classes which will be instantiated? ISTM logging classes are already reasonably usable for programmatic configuration, but this doesn't address e.g. updating configurations easily without program code changes, or the ability to configure from say a YAML node, where YAML may be being used for application configuration as a whole. (Unless of course I've misunderstood what you're getting at.) The probably are light-weight enough, but I didn't want to assume those classes would be used directly. I suspect they could be, though. I guess there aren't *so* many levels or keys that the data structure will become unwieldy. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new way to configure logging
On Oct 7, 2009, at 10:49 AM, Vinay Sajip wrote: All three of the contenders for the title of "commonly found configuration mechanism" - JSON, YAML and Python code - will be expressible, in Python, as Python dicts. So it seems to make sense to add, to logging.config, a new callable bound to "dictConfig" which will take a single dictionary argument and configure logging from that dictionary. I've had bad experiences in the past with dictionary-based APIs. They seem "simpler" in the short run, because the user "only needs to create some dictionaries". Once the complexity of that nested dictionary grows to a certain point, though, one has to refer back to documentation constantly to make sure the structure conforms to the "schema". Building a simple config tree using light-weight classes with documented APIs tends to be more sustainable in the long run. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On Nov 3, 2009, at 3:42 PM, Michael Foord wrote: Barry Warsaw wrote: On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote: I've checked draft (!) PEP 3003, "Python Language Moratorium", into SVN. As authors I've listed Jesse, Brett and myself. On python-ideas the moratorium idea got fairly positive responses (more positive than I'd expected, in fact) but I'm bracing myself for fierce discussion here on python-dev. It's important to me that if if this is accepted it is a "rough consensus" decision (working code we already have plenty of :-), not something enforced by a vocal minority or an influential individual such as myself. If there's too much opposition I'll withdraw the PEP so as not to waste everybody's time with a fruitless discussion. The PEP tries to spell out some gray areas but I'm sure there will be others; that's life. Do note that the PEP proposes to be *retroactive* back to the 3.1 release, i.e. the "frozen" version of the language is the state in which it was released as 3.1. I think this is a great idea. I'd love to see the energy normally put into evolving the language into making the stdlib really kick ass. +lots Ditto. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhancing the shutil module
On Jan 18, 2010, at 8:34 AM, Masklinn wrote: On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: Tarek Ziadé wrote: There's one remaining external call for "zip" done if the zip module is not found, but I am happy to remove it and throw an exception if it's not found, and keep the external "zip" call on Distutils side, so shutil stays 100% stdlib-powered. +1 for that approach. These changes all sound like nice additions to shutil, and hooray for every module that gets adopted by an active maintainer :) Isn't it a bit weird to include that to shutil though? shutil advertises itself as "a number of high-level operations on files and collections of files." and from what I understood it was a bunch of shell-type utility functions to easily copy, move or remove files and directories (that's pretty much all there is in it at this time). Wouldn't it make more sense to put those "archive utils" functions/ objects in a new module separate from shutil, dealing specifically with cross-archive APIs and linked from the current archive-specific modules (essentially, just take the current archive_util, move it to the toplevel of the stdlib and maybe rename it)? It would also make the module much easier to find when searching through the module listing, I think. +1 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
On Feb 25, 2010, at 2:34 PM, Martin v. Löwis wrote: Doug Hellmann wrote: We've recently run into an issue with subprocess on Solaris, as described (by an earlier reporter) in issue #7242. The patch there solves our problem, and has been verified to work by other users as well. What's the status of the ticket? Is there anything I can do to help move it forward to be included in a patch release for 2.6? The usual 5-for-one deal applies: review five issues, and I'll review that one (with more energy than at the moment). I have commit access, can I just check in the patch? Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
On Feb 25, 2010, at 2:47 PM, Antoine Pitrou wrote: Le Thu, 25 Feb 2010 14:38:42 -0500, Doug Hellmann a écrit : I have commit access, can I just check in the patch? If you are sure of yourself, you can. But in this case see my comment on the tracker. OK, good point. I'll see about a test or two and post an update to the ticket. Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Feb 26, 2010, at 5:59 PM, Michael Foord wrote: On 26/02/2010 22:09, Brett Cannon wrote: On Thu, Feb 25, 2010 at 16:13, Greg Ewing > wrote: Michael Foord wrote: I thought we agreed at the language summit that if a .pyc was in the place of the source file it *could* be imported from - making pyc only distributions possible. Ah, that's okay, then. Sorry about the panic! Michael is right about what as discussed at the language summit, but Barry means what he says; if you look at the PEP as it currently stands it does not support bytecode-only modules. Barry and I discussed how to implement the PEP at PyCon after the summit and supporting bytecode-only modules quickly began to muck with the semantics and made it harder to explain (i.e. what to set __file__ vs. __compiled__ based on what is or is not available and how to properly define get_paths for loaders). But a benefit of no longer supporting bytecode-only modules by default is it cuts back on possible stat calls which slows down Python's startup time (a complaint I hear a lot). Performance issues become even more acute if you try to come up with even a remotely proper way to have backwards-compatible support in importlib for its ABCs w/o forcing caching on all implementors of the ABCs. As for having a dependency on a loader, I don't see how that is obscure; it's just a dependency your package has that you handle at install-time. And personally, I don't see what bytecode-only modules buy you. The obfuscation argument is bunk as we all know. Bytecode contains so much data that disassembling it gives you a very clear picture of what the original code was like. Well, understanding bytecode is *still* requires a higher level of understanding than the *majority* of Python programmers. Added to which there are no widely available tools that *I'm* aware of for decompiling recent versions of Python (decompyle worked up to Python 2.4 but then went closed source as a commercial service [1]. The situation is analagous to .NET assemblies by the way (which *can* be trivially decompiled by several widely available tools). Having a non-source distribution prevents your users from changing things and then calling you for support without them having to go to a lot more effort than it is worth. There are several companies who currently ship bytecode only. (There was someone on the IronPython mailing list only last week asking if IronPython could support pyc files for this reason). For many pointy- haired-bosses 'some' protection is enough and having Python not support this (out of the box) would be a black mark against Python for them. We ship bytecode only, basically for the reason Michael states here (keeping support costs under control from "ambitious" users). I think it's almost a dis-service to support bytecode-only files as it leads people who are misinformed or simply don't take the time to understand what is contained in a .pyc file into a false sense of security about their code not being easy to examine by someone else. For many use-cases some protection is enough. After all *any* DRM or source-code obfuscation is breakable in the medium / long term - so just enough to discourage the casual looker is probably sufficient. The fact that bytecode only distributions exist speaks to that. Right. We're more concerned with not having users muck with stuff than with keeping the implementation a secret, although having a bit of obfuscation doesn't hurt. Whether you believe that allowing companies who ship bytecode is a disservice to them or not is fundamentally irrelevant. If they believe it is a service to them then it is... :-) As you can tell, I would be disappointed to see bytecode only distributions be removed from the out-of-the-box functionality. +1 Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Feb 26, 2010, at 8:30 PM, Brett Cannon wrote: So what is the burden of including a single source file that added the support to load from bytecode-only modules? I am not saying you shouldn't be able to have this functionality, just that I personally don't want to pay for the overhead (both performance-wise and development-wise) by default just because you and some other people want this functionality for some clients. If such a module was available, we'd use it if that was the way to achieve what we want. We could write something like that on our own, but we'd be more likely to decide to just stick with Python 2 for longer because we're going to prioritize new features over doing "hidden" maintenance work like that. So, we want the ability to ship bytecode-only versions of the software, but the specific mechanism for doing so doesn't matter a lot. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] audience-instructors for Teach Me Python Bugfixing needed
What an excellent idea! We should have these at *every* regional
conference.
Doug
On May 6, 2010, at 10:47 AM, Catherine Devlin wrote:
Hey, everybody... I'm Catherine, a database administrator who makes
up excuses to write Python instead.
I'm not actually here as a core developer, but as somebody who hopes
to become a developer and recruit some more, which brings me to my
question:
Who lives close enough to Ohio to make it to PyOhio this summer? I
want to use PyOhio to create new Python devs (including myself), but
I need some existing ones to seed the process.
I need a few veterans (3?) who can commit to come to PyOhio and take
part as audience/instructors in a "Teach Me [Python core / standard
library] Bugfixing" session. (See http://catherinedevlin.blogspot.com/2010/04/bugfixing-at-pyohio.html.)
The PyOhio Call for Proposals is up May 10 so I'd better find you
quick!
I'm pretty much ignorant enough to lead a Teach Me session. In a
Teach Me session, the person at the projector *doesn't* know the
material. Instead, she asks the audience questions ("How do I find
a bug to work on?"), and they talk her through it. It's based on
Teach Me Twisted, a mind-blowing session Steve Holden led at PyCon
2008 (http://catherinedevlin.blogspot.com/2008/03/teach-me-twisted.html
). I think it's a fantastic way to teach, but it depends on some
veterans being in the audience. There are folks in the greater
Python community eager to get hold of a video of such a session...
if we do this well, it could become an important tool in keeping the
quality of core Python code high.
And all I need from you, my audience-instructors, is a promise to
show up (no preparation necessary). Can you make it? Can you pass
the appeal on to others you know of?
Thanks! Hope to see you in July!
--
- Catherine
http://catherinedevlin.blogspot.com/
*** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org ***
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)
On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote: On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik wrote: 4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain. Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python- dev archives but was unable to find much. I just set up a PSF account on BitBucket for hosting the Pulse newsletter repository. I can assist with setting up a public repository for the source under that account, too. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] framework build for 2.7 using old sqlite?
I'm trying to write a little program that uses the full text search extension module for sqlite with Python 2.7 on Snow Leopard. I installed Python by downloading the DMG file from python.org. According to the Python docs (http://docs.python.org/library/sqlite3.html#sqlite3.Connection.enable_load_extension), 2.7 should include the functions for handling extension modules, but when I try to use them they are not defined (I get an AttributeError when I call the related methods on the Connection object). In Modules/_sqlite/connection.c I see that there is an #ifdef for HAVE_LOAD_EXTENSION, which is in turn only defined if both the version number is high enough and SQLITE_OMIT_LOAD_EXTENSION is not set. I think the problem is that the build of Python in the DMG I download was created with an old version of the SQLite libraries: farnsworth:dhellmann:~:503 $ which python /Library/Frameworks/Python.framework/Versions/2.7/bin/python farnsworth:dhellmann:~:501 $ python Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 >>> sqlite3.version_info (2, 6, 0) Can anyone confirm that the installer image for OS X 10.5 and later (http://python.org/ftp/python/2.7/python-2.7-macosx10.5.dmg) was created with an old SQLite library? Is there some way to update that DMG, or do I need to build Python from source myself? Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] framework build for 2.7 using old sqlite?
On Oct 3, 2010, at 11:29 AM, Doug Hellmann wrote: > I'm trying to write a little program that uses the full text search extension > module for sqlite with Python 2.7 on Snow Leopard. I installed Python by > downloading the DMG file from python.org. According to the Python docs > (http://docs.python.org/library/sqlite3.html#sqlite3.Connection.enable_load_extension), > 2.7 should include the functions for handling extension modules, but when I > try to use them they are not defined (I get an AttributeError when I call the > related methods on the Connection object). > > In Modules/_sqlite/connection.c I see that there is an #ifdef for > HAVE_LOAD_EXTENSION, which is in turn only defined if both the version number > is high enough and SQLITE_OMIT_LOAD_EXTENSION is not set. > > I think the problem is that the build of Python in the DMG I download was > created with an old version of the SQLite libraries: > > farnsworth:dhellmann:~:503 $ which python > /Library/Frameworks/Python.framework/Versions/2.7/bin/python > > farnsworth:dhellmann:~:501 $ python > Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sqlite3 > >>> sqlite3.version_info > (2, 6, 0) Forget that, the version info is for pysqlite, not the underlying libraries. I found that Python's setup.py has SQLITE_OMIT_LOAD_EXTENSION set, which disables this feature (http://svn.python.org/view?view=rev&revision=78688). Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: > On Wed, Mar 9, 2011 at 01:15, Stefan Behnel wrote: >> Actually, why not put up a web page of "upcoming changes" somewhere, that >> lists major decisions with user impact that were taken on python-dev? >> Including a link to the relevant discussion and decision. Often enough, >> decisions are taken inside of huge mailing list threads that get off-topic >> before someone has "the right idea" and everyone who's still there to listen >> agrees. Even for people lurking around on python-dev, it's easy enough to >> miss these moments. > > We used to do biweekly-ish Python-Dev summaries for this reason. > > The original links at python.org appear to be down, but I found an > example mirrored at > ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html > > Would resuming these and putting them back on python.org address the issue? > > It's been on my back burner for about two years now, but I want to > make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 11, 2011, at 7:12 PM, Paul Moore wrote: > On 11 March 2011 23:24, Guido van Rossum wrote: >>> I'm interested in the task and I guess I'll follow-up with Doug Hellman. I >>> don't follow -ideas close enough to summarize it, but I'd contribute to a >>> -dev blog. >> >> Awesome! (And we don't need to stop at one blogger. Many hands make light >> work.) > > I'm interested but probably haven't got time to take something like > this on "properly". Helping out occasionally would probably be > something I could do, though. (Was that tentative enough? :-)) I'm on > -ideas, too, so I could do something there as well. Thanks Brian and Paul! I have sent you both invitations to join the communications team mailing list so we can work out the details. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 16, 2011, at 11:07 AM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/03/11 22:50, Guido van Rossum wrote: >> I propose we try to find an "embedded blogger" who participates in >> python-dev but is focused on making regular blog posts about the >> interesting tidbits. There's no requirement to be complete (which I >> think always weighed the python-dev-summaries task down). >> >> Ditto for python-ideas -- it would be nice if it was the same person >> but doesn't have to be. >> >> This might be an opportunity for increasing diversity. > > +1. I would love to see this. Too bad I don't have the time myself to > keep up with python-dev & python-ideas... Forwarding the request to > python-es mailing list. Crossing fingers. Jesus, if anyone expresses interest in helping out please have them contact me directly, off list. Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote: > On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy wrote: >> On 3/17/2011 1:45 PM, Benjamin Peterson wrote: >>> >>> 2011/3/16 Thomas Heller: >>>> >>>> I would like my committer rights to be retracted. >>>> >>>> I have been contributing to Python here and there for 10 years now, >>>> and it was a pleasant experience. >>>> >>>> Unfortunately, since about a year I have lots more things to do, and >>>> I won't be able to contribute anymore (I have not even started to >>>> learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own >>>> Python projects. >>> >>> Thank you very much for you work. We'd always be happy to have you back. >> >> In the meanwhile, it would be nice to have another ctypes maintainer, as >> there are several open issues. There is certainly a opening for a new person >> with C experience. >> > > I'll ask doug hellmann if this is something we can do a blog post > about on the PSF blog. Having another ctypes expert is pretty critical > (everyone I know is using it) This does seem like a good use of the blog. The team is working on setting up the dev blog, and I expect to have something up soon. This can be our second post there (the first being an introduction). Is there a "job description" for a ctypes maintainer? Where should we send people for more details about this request? We would link to the dev guide and this mailing list, but is there something more specific? Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] blogroll for the new blog
We are nearly ready to launch the new blog for python-dev. If you have a personal blog where you talk about your Python work, we would like to include a link in the sidebar as part of our blog-roll. Send me the URL (off-list) and I'll make sure you are included. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] blogroll for the new blog
On Mar 21, 2011, at 10:10 PM, Senthil Kumaran wrote: > Doug Hellmann wrote: >> We are nearly ready to launch the new blog for python-dev. > > Cool. But I always thought planet.python.org was a kind of blog for > python-dev. How will python-dev blog be different? Will add additional > redundancy to my RSS reader which gets planet posts as well as > individual posts from the same author? > > Yes, this question is not related to blogroll but was for my > understanding and I am sorry, if it was already discussed elsewhere and I > missed it. Perhaps you will be covering this in the introductory > post too, if not, it would be a good idea to cover this point. Blogs linked from the blogroll will appear on the sidebar of Python Insider with your name and a link to your blog (or whatever URL you give me, I suppose). This isn't an aggregator feed. We will be writing all new content based on the activities of the Python development team. There was a brief discussion immediately before PyCon (http://mail.python.org/pipermail/python-dev/2011-March/109027.html) and it also came up during the Language Summit. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "Meet the Team" on Python Insider
We would like to run a series of interviews with the Python developers to get the new blog going. There is a short list of questions below this message. If you would like to be included in the series, please reply directly to me with your answers. We will be doing one or two posts per day, depending on the number of responses and availability of other information to post. We'll have to wait until we have several responses before we start, so we don't announce a new series and then post two messages before it peters out. Please help us by sending your answers as quickly as you can so we can tell what we'll be dealing with. Posts will be published in roughly the order the responses are received, with the text exactly as you send it (unedited, except for formatting it as HTML). If the questions don't apply to you, you can't remember the answer, or don't have an answer, then you can either leave that question blank or interpret it more broadly and give some related information. Blank questions will be omitted from the posts. Thanks, Doug Personal information: name location (city, country, whatever you want to give--we don't need your mailing address) home page or blog url Questions: 1. How long have you been using Python? 2. How long have you been a core committer? 3. How did you get started as a core developer? Do you remember your first commit? 4. Which parts of Python are you working on now? 5. What do you do with Python when you aren't doing core development work? (day job, other projects, etc.) 6. What do you do when you aren't programming? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new blog
On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote: > On Mon, 21 Mar 2011 21:50:53 -0400 > Doug Hellmann wrote: >> We are nearly ready to launch the new blog for python-dev. > > Is any core dev allowed to post on this blog? (how?) > Or is there an editorial team dedicated to writing posts? Both! If you want to write for the blog, just send me your Blogger account name so I can give you authorship permission. There are also a few volunteers who are going to be posting, but we would LOVE to have developers writing their own posts. Doug > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new blog
On Mar 23, 2011, at 1:26 PM, Antoine Pitrou wrote: > Le mercredi 23 mars 2011 à 13:19 -0400, Doug Hellmann a écrit : >> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote: >> >>> On Mon, 21 Mar 2011 21:50:53 -0400 >>> Doug Hellmann wrote: >>>> We are nearly ready to launch the new blog for python-dev. >>> >>> Is any core dev allowed to post on this blog? (how?) >>> Or is there an editorial team dedicated to writing posts? >> >> Both! >> >> If you want to write for the blog, just send me your Blogger account >> name so I can give you authorship permission. > > I don't know yet if I will write for the blog (I would imagine posting > about new features or interesting fixes), but I definitely don't have a > Blogger account - and would like not to create one. > > (or does it work with Google accounts) As far as I understand, those are the same thing. If you have a gmail address, you can use it to login to blogger. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop OS/2 and VMS support?
On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote: > Victor Stinner wrote: >> Hi, >> >> I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, >> our OS/2 maintainer, answered: >> http://mail.python.org/pipermail/python-dev/2010-April/099477.html >> >> Extract: << The 3.x branch needs quite a bit of work on OS/2 to >> deal with Unicode, as OS/2 was one of the earlier OSes with full >> multiple language support and IBM developed a unique API. I'm still >> struggling to come to terms with this, partly because I myself don't >> "need" it. >> >> >> So one year later, Python 3 does still not support OS/2. >> >> -- >> >> About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if >> Python 3 does work on VMS. I bet that it does just not compile :-) >> >> I don't know anyone using VMS or OS/2. >> >> -- >> >> There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait >> until someone work on these OSes to ensure that the test suite pass. But >> if nobody cares of these OSes and nobody wants to maintain them, it >> would be easier for the maintenance of the Python source code base to >> remove specific code. >> >> Well, not "remove" directly, but plan to remove it using the PEP 11 >> procedure (mark OS/2 and VMS as unsupported, and remove the code in >> Python 3.4). > > The Python core team is not really representative of the Python > community users, so I think this needs a different approach: > > Instead of simply deprecating OSes without notice to the general > Python community, how about doing a "call for support" for these > OSes ? > > If that doesn't turn up maintainers, then we can take the PEP 11 > route. Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Insider translations
I wanted to take a few minutes to let you all know that the recent call for help with translating Python Insider was met with a wave of enthusiastic contributors. We now have teams prepared to translate all posts to Simplified and Traditional Chinese, German, Japanese, Portuguese, Romanian, and Spanish. Setting up each blog takes a bit of effort, so we are launching them in batches as they are ready. When all of the existing teams are launched, I will be looking for translators for additional languages. The next time you have Python related information that you would like to share with the community, I hope you will consider working with us and publishing it through Python Insider, so it can reach the widest possible audience. Either Brian Curtin or I can help you get set up, so contact one of us directly when you are ready. Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] looking for a contact at Google on the Blogger team
Several of the PSF blogs hosted on Google's Blogger platform are experiencing issues as fallout from the recent maintenance problems they had. We have already had to recreate at least one of the translations for Python Insider in order to be able to publish to it, and now we can't edit posts on Python Insider itself. Can anyone put me in contact with someone at Google from the Blogger team? I would at least like to know whether the "bX-qpvq7q" problem is being worked on, so I can decide whether to take a hiatus or start moving us to another platform. There are a lot of posts about the error on the support forums, but no obvious response from Google. Thanks, Doug -- Doug Hellmann Communications Director Python Software Foundation http://python.org/psf/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] looking for a contact at Google on the Blogger team
On May 20, 2011, at 5:47 PM, Martin v. Löwis wrote: >> As Jesse has said, there is an RFP in development to improve >> python.org to the point where we can self-host blogs and the like and >> deal with the associated user account administration appropriately. > > To run a blog on www.python.org, a PEP is not needed. If anybody would > volunteer to set this up, it could be done in no time. The blog is working again, so we can continue using the tool chain we have. Thanks, Doug -- Doug Hellmann Communications Director Python Software Foundation http://python.org/psf/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language summit writeup anyone?
On Jun 20, 2011, at 4:08 AM, Maciej Fijalkowski wrote: > Hi. > > Unfortunately I'm missing Europython (and language summit) this year. > Did anyone do a writeup on what was discussed? Brian Curtin or I can help get the writeup posted to the Python Insider blog. I'm sure there are a lot of people who don't follow this list who would be interested in hearing about the outcome. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] www.python.org/doc and docs.python.org hotfixed
On Oct 2, 2008, at 7:28 AM, Thomas Wouters wrote: On Thu, Oct 2, 2008 at 12:44, Antoine Pitrou <[EMAIL PROTECTED]> wrote: Thomas Wouters python.org> writes: > > If anyone feels particularly frustrated by the old URLs breaking, I wouldn't mind adding a redirection for each individual URL as long as I don't have to build that mapping Well in general URLs aren't supposed to break (except the ones which are deliberately temporary). Could a RewriteRule do the trick? Not a single one, no. The URLs *all* changed. There is not a single one that's the same. We may be able to do a single rewrite rule for most of the module-*.html URLs, but everything else -- and there is quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better mapping. Feel free to send me that mapping :-) Perhaps it has already been suggested and rejected for some reason, but we could include the major/minor version numbers in the URLs. That would make it easier to rewrite old URLs, and I assume there will be 2.x and 3.x documentation available online for some period of time? docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/* docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and include a link to docs.python.org/3.0/ That way all of the old references (in Google and bookmarks) would still work. Perhaps we should restore the old version of the files until this is resolved? Being redirected to the top landing page is a little disconcerting if you come to the site through a search engine and aren't familiar with the organization of the manual. For example, I went to look for the documentation on how slots work, and ended up at the top of the reference manual. The local search didn't work (no results), "slots" isn't in the index, and google still has the old URL. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] www.python.org/doc and docs.python.org hotfixed
On Oct 2, 2008, at 8:17 AM, Georg Brandl wrote: Doug Hellmann schrieb: Not a single one, no. The URLs *all* changed. There is not a single one that's the same. We may be able to do a single rewrite rule for most of the module-*.html URLs, but everything else -- and there is quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better mapping. Feel free to send me that mapping :-) Perhaps it has already been suggested and rejected for some reason, but we could include the major/minor version numbers in the URLs. That would make it easier to rewrite old URLs, and I assume there will be 2.x and 3.x documentation available online for some period of time? docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/* That would be possible, but not sensible IMO -- it doesn't make people update their links, instead keeps links to outdated documentation. The documentation isn't outdated if you're still running Python 2.5, as a lot of people will be. Not everyone gets to upgrade right away when there's a new release. For example, the product we build at work depends on 2.5 and we don't have time in our schedule to upgrade right away. It may be several months before we do. docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and include a link to docs.python.org/3.0/ We already have archived versioned docs at http://www.python.org/doc/X.Y . Great, so we can just redirect the old links over there. If you can make them point to the correct form of the new docs, that would be even better, but at least sending them to the old docs means they point to *something* useful. That way all of the old references (in Google and bookmarks) would still work. Perhaps we should restore the old version of the files until this is resolved? Being redirected to the top landing page is a little disconcerting if you come to the site through a search engine and aren't familiar with the organization of the manual. For example, I went to look for the documentation on how slots work, and ended up at the top of the reference manual. The local search didn't work (no results), "slots" isn't in the index, and google still has the old URL. __slots__ is in the index (with the underscores). The local search shows me __slots__ as the first result when I search for "__slots__" or "slots". OK, searching for "slots" at http://docs.python.org found several results this time. I don't know why it would have given me no results the last time, but I found what I needed. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] www.python.org/doc and docs.python.org hotfixed
On Oct 2, 2008, at 8:34 AM, Georg Brandl wrote: If linking to the new version could be done easily, we could as well directly redirect. The problem is that having that mapping in the first place is hard. I was looking for the easy route. If the layout of the new docs changed completely, anything that starts with the old abbreviations (/ lib/, /tut/, /ref/, etc.) could just go over to the 2.5.2 docs, right? You don't need to map every sub-section to its new URL unless you feel really strongly that links to pages in the old organization should point to the new location. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation idea
On Oct 16, 2008, at 5:11 PM, Raymond Hettinger wrote: Raymond Hettinger wrote: * It will assist pypy style projects and other python implementations when they have to build equivalents to CPython. * Will eliminate confusion about what functions were exactly intended to do. * Will confer benefits similar to test driven development where the documentation and pure python version are developed first and doctests gotten to pass, then the C version is created to match. I haven't seen anyone comment about this assertion of "equivalence". Doesn't it strike you as difficult to maintain *two* versions of every function, and ensure they match *exactly*? Glad you brought this up. My idea is to present rough equivalence in unoptimized python that is simple and clear. The goal is to provide better documentation where code is more precise than English prose. That being said, some subset of the existing tests should be runnable against the rough equivalent and the python code should incorporate doctests. Running both sets of test should suffice to maintain the rough equivalence. This seems like a large undertaking. I'm sure you're not underestimating the effort, but I have the sense that you may be overestimating the usefulness of the results (or maybe I'm underestimating them through some lack of understanding). Would it be more optimal (in terms of both effort and results) to extend the existing documentation and/or docstrings with examples that use all of the functions so developers can see how to call them and what results to expect? Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "Meet the Team" on Python Insider
[Renewing this request for participation since there are a few new members since the original request went out.] We are running a series of interviews with the Python developers on the python-dev blog (http://blog.python.org). There is a short list of questions below this message. If you would like to be included in the series, please reply directly to me with your answers. We will be doing one or two posts per week, depending on the number of responses and availability of other information to post. We'll have to wait until we have several responses before we start, so we don't announce a new series and then post two messages before it peters out. Please help us by sending your answers as quickly as you can so we can tell what we'll be dealing with. Posts will be published in roughly the order the responses are received, with the text exactly as you send it (unedited, except for formatting it as HTML). If the questions don't apply to you, you can't remember the answer, or don't have an answer, then you can either leave that question blank or interpret it more broadly and give some related information. Blank questions will be omitted from the posts. Thanks, Doug Personal information: name location (city, country, whatever you want to give--we don't need your mailing address) home page or blog url Questions: 1. How long have you been using Python? 2. How long have you been a core committer? 3. How did you get started as a core developer? Do you remember your first commit? 4. Which parts of Python are you working on now? 5. What do you do with Python when you aren't doing core development work? (day job, other projects, etc.) 6. What do you do when you aren't programming? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Meet the Team" on Python Insider
I should have made clear that if you have already completed the survey, we still have your data in the queue. The invitation is for anyone who has not yet sent us the info, including new team members. Doug On Aug 7, 2011, at 11:09 AM, Doug Hellmann wrote: > [Renewing this request for participation since there are a few new members > since the original request went out.] > > We are running a series of interviews with the Python developers on the > python-dev blog (http://blog.python.org). There is a short list of questions > below this message. If you would like to be included in the series, please > reply directly to me with your answers. > > We will be doing one or two posts per week, depending on the number of > responses and availability of other information to post. We'll have to wait > until we have several responses before we start, so we don't announce a new > series and then post two messages before it peters out. Please help us by > sending your answers as quickly as you can so we can tell what we'll be > dealing with. > > Posts will be published in roughly the order the responses are received, with > the text exactly as you send it (unedited, except for formatting it as HTML). > If the questions don't apply to you, you can't remember the answer, or don't > have an answer, then you can either leave that question blank or interpret it > more broadly and give some related information. Blank questions will be > omitted from the posts. > > Thanks, > Doug > > > > Personal information: > > name > location (city, country, whatever you want to give--we don't need your > mailing address) > home page or blog url > > Questions: > > 1. How long have you been using Python? > > 2. How long have you been a core committer? > > 3. How did you get started as a core developer? Do you remember your first > commit? > > 4. Which parts of Python are you working on now? > > 5. What do you do with Python when you aren't doing core development work? > (day job, other projects, etc.) > > 6. What do you do when you aren't programming? > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Mirroring Python repos to Bitbucket
Charles McLaughlin of Atlassian has set up mirrors of the Mercurial repositories hosted on python.org as part of the ongoing infrastructure improvement work. These mirrors will give us a public fail-over repository in the event that hg.python.org goes offline unexpectedly, and also provide features such as RSS feeds of changes for users interested in monitoring the repository passively. Thank you, Charles for setting this up and Atlassian for hosting it! Doug Begin forwarded message: > From: Charles McLaughlin > Date: August 10, 2011 3:43:06 PM EDT > To: Jesse Noller , Doug Hellmann > Subject: Mirroring Python repos to Bitbucket > > Hey, > > You guys expressed some interest in mirroring repos to Bitbucket a > couple weeks ago. I mentioned we mirror a few Python repos here: > > https://bitbucket.org/mirror/ > > But that doesn't cover everything from hg.python.org. So, I wrote a > little script that scrapes the Python HgWeb and mirrors everything to > Bitbucket. Here's the script in case you're curious: > > https://bitbucket.org/cmclaughlin/mirror-python-repos/ > > We're running the script hourly to keep the mirrors up to date. The > mirrored repos live under this URL: > > https://bitbucket.org/python_mirrors > > A few people here have mentioned "python_mirrors" is a strange name. I > can change that if you'd like. I don't have any better ideas though. > Also, anyone can fork my script if they see any room for improvement :) > > Please feel free to forward this email to mailing lists, etc to get the > word out. > > Regards, > Charles ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mirroring Python repos to Bitbucket
On Aug 13, 2011, at 7:23 PM, Antoine Pitrou wrote: > On Sat, 13 Aug 2011 19:08:40 -0400 > Doug Hellmann wrote: >> >> Charles McLaughlin of Atlassian has set up mirrors of the Mercurial >> repositories hosted on python.org as part of the ongoing infrastructure >> improvement work. These mirrors will give us a public fail-over repository >> in the event that hg.python.org goes offline unexpectedly, and also provide >> features such as RSS feeds of changes for users interested in monitoring the >> repository passively. > > There is already an RSS feed at http://hg.python.org/cpython/rss-log > Another possibility is the gmane mirror of python-checkins, which has > its own RSS feed: http://rss.gmane.org/gmane.comp.python.cvs Thanks for the tip, I didn't know about either of those. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On Nov 14, 2012, at 5:37 PM, Chris Withers wrote: > On 14/11/2012 10:11, [email protected] wrote: >> >> Zitat von Chris Withers : >> >>> a_dict = dict( >>>x = 1, >>>y = 2, >>>z = 3, >>>... >>>) >> >>> What can we do to speed up the former case? >> >> It should be possible to special-case it. Rather than creating >> a new dictionary from scratch, one could try to have the new dictionary >> the same size as the original one, and copy all entries. > > Indeed, Doug, what are your views on this? Also, did you have a real-world > example where this speed difference was causing you a problem? No, not particularly. I noticed people using dict() and wondered what impact it might have in a general case. > >> I don't know how much this would gain, though. You still have to >> create two dictionary objects. For a better speedup, try >> >> def xdict(**kwds): >> return kwds > > Hah, good call, this trumps both of the other options: > > $ python2.7 -m timeit -n 100 -r 5 -v > "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" > raw times: 1.45 1.45 1.44 1.45 1.45 > 100 loops, best of 5: 1.44 usec per loop > $ python2.6 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' > raw times: 2.37 2.36 2.36 2.37 2.37 > 100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n 100 > -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' > raw times: 0.548 0.533 0.55 0.577 0.539 > 100 loops, best of 5: 0.533 usec per loop > > For the naive observer (ie: me!), why is that? > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] question about packaging
A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can start figuring out where we might be able to help? Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question about packaging
Is that where the discussions are actively happening? Last time I looked at it I thought there was a google group or something. It's bee quite a while, though, so I may just be confused. On Dec 28, 2012, at 6:12 PM, Antonio Cavallo wrote: > There's the distutil mailing list: > > http://mail.python.org/mailman/listinfo/distutils-sig > > > > Doug Hellmann wrote: >> A couple of us from the OpenStack project are interested in getting involved >> in the packaging rewrite/update project. I was following that work for a >> while, but have lost track of its current state. Can someone point me to the >> right mailing list, and maybe a status page or something so I can start >> figuring out where we might be able to help? >> >> Thanks, >> Doug >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question about packaging
On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote: > On Fri, 28 Dec 2012 17:59:05 -0500 > Doug Hellmann wrote: >> A couple of us from the OpenStack project are interested in getting involved >> in the packaging rewrite/update project. I was following that work for a >> while, but have lost track of its current state. Can someone point me to the >> right mailing list, and maybe a status page or something so I can start >> figuring out where we might be able to help? > > The current effort seems to be distlib, Vinay's project to gather the > "good parts" of packaging and distutils as a library API: > http://packages.python.org/distlib/ > (there's an active bitbucket repo) > > Regards > > Antoine. Thanks, I'll start digging in there and reading the PEPs to catch up. Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
