Re: [Python-Dev] IronPython specific code in inspect module
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. > > 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] IronPython specific code in inspect module
On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann 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] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 9:06 AM, Jesse Noller wrote: > On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano > 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 wrote: > On Thu, Nov 12, 2009 at 11:02 AM, David Stanek > 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] argparse ugliness
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
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 wrote:
> On 8 Mar 2010, at 16:53 , David Stanek wrote:
>>
>> On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
>> 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] SVN <-> HG workflow to split Python Library by Module
On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik 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] Tracker status
On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan 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] Looking after the buildbots (in general)
On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl 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] Python wiki
On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik 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] 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] 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] 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
