Re: [Python-Dev] Python wiki
On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik techto...@gmail.com wrote: For me a major annoyance is the empty page with two links on wiki.python.org While it allows to tell new people that there is also a Jython wiki, my vision that it should be instead be oriented on existing contributors immediately providing instruments to work with Python wiki. So if smb. need Jython wiki - it should be moved to wiki.jython.org That's funny, I've never seen that page before. Does it get linked to from somewhere? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org 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 after the buildbots (in general)
On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl g.bra...@gmx.net wrote: The hard part is to know *when* to look. As you might have noticed, the Python test suite does not run in ten seconds, especially on some of the buildbots -- it can take 1-2 there to complete. So if you look too soon, you won't see all the results, and usually the slow systems are the interesting ones. Now we could of course have a commit hook that counts down two hours and then sends an email to the committer Now look at the buildbot!... Why not have buildbot slaves email the committer when their change broke the build. I realize that if you break 25 slaves it would not be pleasant to receive 25 emails, but I've had worse things happen. Or buildbot slaves can report failures to a mailing list or IRC chat. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker status
On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan ncogh...@gmail.com wrote: Are the bug tracker and meta-tracker down for anyone else, or is it just me? It is down for me as well. It appears to be accepting the connection and then just doesn't return any content. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN - HG workflow to split Python Library by Module
On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik techto...@gmail.com wrote: I planned to publish this proposal when it is finally ready and tested with an assumption that Subversion repository will be online and up-to-date after Mercurial migration. But recent threads showed that currently there is no tested mechanism to sync Subversion repository back with Mercurial, so it will probably quickly outdate, and the proposal won't have a chance to be evaluated. So now is better than never. I don't think it would be very hard to update a read-only version of Subversion. It just gets complicated if you plan on committing to both Subversion and Mercurial. Does having many little repos add more value than the pain it creates? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 11:49 AM, Xavier Morel python-...@masklinn.net wrote:
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args
is a sequence of option strings (so you can write
add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs. Either that, or the action would be an *arg
and argparse would have to walk all of its *args type-testing each one to find
if there's an action anywhere.
You could just change my example to:
from argparse.actions import store_true
...
parser.add_argument('--plot', action=store_true)
I would probably still import the actions namespace directly, but
wouldn't have to.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 9:06 AM, Jesse Noller jnol...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano st...@pearwood.info wrote: On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote: Why are there comments on PyPI? Moreso, why are there comments which I cannot control as a package author on my very own packages? That's just absurd. No, what's absurd is thinking that the act of publishing software somehow gives you the right to demand control over what others say about your software. I don't suppose that this rant of yours has something to do with the comment posted today? Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A I find the time to contribute to make it better or B It changes. Where is the code for PyPi? I took a quick look and didn't turn up anything. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 12:06 PM, Jacob Kaplan-Moss ja...@jacobian.orgwrote: On Thu, Nov 12, 2009 at 11:02 AM, David Stanek dsta...@dstanek.com wrote: Where is the code for PyPi? I took a quick look and didn't turn up anything. https://svn.python.org/packages/trunk/pypi/ I've already started on a patch to make comments an option that package maintainers could turn on or off, but I don't want to waste any more time fighting this code unless I have some assurance it'll be checked in. Thanks. If I have some spare time I'm going take a look. Should I post patches to the regular Python bug tracker? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython specific code in inspect module
On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann doug.hellm...@gmail.com wrote: On May 19, 2009, at 10:21 PM, David Stanek wrote: 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? Basically yes. What I proposed is more like a service locator with a pinch of DI. Where can I learn more about what Tarek is working on? Is there a branch somewhere? 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? By executing I mean figure out the mappings and necessarily create them. This enables errors to happen early if the dependencies are not met. This is really useful if the technique is used for more than just the platform specific code. 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. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython specific code in inspect module
On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson benja...@python.org wrote: 2009/5/19 Michael Foord fuzzy...@voidspace.org.uk: 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. I wish we had more of a policy about this. There seems to be a long tradition of special casing other implementations in the stdlib. For example, see types.py and tests/test_support.py for remnants of Jython compatibility. However, I suspect this code has languished with out core-developers using the trunk stdlib with Jython. I suppose this is a good reason why we are going to split the stdlib out of the main repo. 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. 2. Add executing this new configuration to the bootstrapping process. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé [EMAIL PROTECTED] wrote: What about having two level of devs ? + core developers + standard library developers I was also thinking about two levels of developers, but structured a little differently. We have the same core developers with permission to commit anywhere in the repo. Then we have a set of sub-core (or whatever) that only have permission to commit to experimental branches. These experimental branches would be the testing place for some patches. Once a patch has had enough exposure in the experimental branch and has been verified by several people the core team could merge it into the main development branch. A set of buildbot slaves can also check that branch on a variety of systems and architectures. The structure could then look like: * trunk - the mainline of development * branches/release##maint - for each version * branches/experimental## - for the sub-core devs This may start to be a bit messy if the experimental branch diverges too much from trunk. trunk would also have to be periodically merged into the experimental branches. Even so I think it could still be manageable. And if not the no harm/no foul the experimental branches could be abandoned and little core developer time would be wasted. -- David http://www.traceback.org ___ Python-Dev mailing list Python-Dev@python.org 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 security team
On Sat, Sep 27, 2008 at 8:45 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner [EMAIL PROTECTED] wrote: I would like to know if a Python security team does exist. I sent an email about an imageop issue, and I didn't get any answer. Later I learned that a security ticket was created, I don't have access to it. Yes, the PSRT (Python Security Response Team) does exist. We did get your email; sorry we didn't respond. There are very few members on that list and most of them are extremely busy. Responding to your email just slipped through the cracks. I believe Benjamin was the last person to work on your submitted patch. I would be interested in participating. Is there any documentation about the team or the processes? My Google search just turned up a bunch of mailing list posts looking for team members. -- David http://www.traceback.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
On Mon, Jun 06, 2005 at 01:38:36PM -0500, Skip Montanaro wrote: Reinhold - Flat namespace: Should we tend to a more hierarchic library Reinhold (e.g. inet.url, inet.http, inet.nntp)? This would increase Reinhold clarity when searching for a module. We've talked about this before. The main technical challenge seems to be backward compatibility. You need to support both flat (import urllib) and packaged namespaces (from www import urllib), possibly within the same application. That is, postulating a www package, if I execute import urllib from www.urllib import urlopen the module-level code should only be executed once, and urlopen == urllib.urlopen should evaluate to True. Can't this be handled with an __init__ module? Create an inet package and having the __init__ module pull whatever it wanted into it's own namespace. It would be nice to then use warnings to show deprecation messages when the old import is used (import url instead of import inet.url), but I don't think that is quite so easy. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgptKki5DlMrm.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
