Re: [Python-Dev] Information about how cpython in benchmarked
Hi Nick, Jesse, Thanks both for your responses, it's much appreciated! It's very useful to have a clear pointer to the right place to begin looking. Regards, -Tennessee On Tue, Mar 29, 2011 at 10:47 PM, Jesse Noller wrote: > On Tue, Mar 29, 2011 at 7:00 AM, Nick Coghlan wrote: > > On Tue, Mar 29, 2011 at 8:01 PM, Tennessee Leeuwenburg > > wrote: > >> PyPy maintains http://speed.pypy.org/, which provides very clear > information > >> about the relative performance of PyPy trunk against some version of > cpython > >> (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, > but > >> that could easily just be my ignorance speaking. > >> My interest is that I'm looking at building a benchmarking solution at > work. > >> and I can't think of a better way to build something good and general > than > >> to try and write something that could potentially be released as open > source > >> and be useful to others. As such I thought that benchmarking cpython > would > >> be a great use case, but I want to find out as much as I can about how > >> people currently go about benchmarking Python. Initially I'm just > looking at > >> CPU profiling since it's easiest. > > > > One of the points coming out of the VM summit at Pycon is actually > > that we want to create a shared benchmarking site for CPython, PyPy, > > Jython, IronPython (and possibly Stackless) under the python.org > > banner (either speed.python.org, or possibly performance.python.org, > > since we want to do memory profiling as well). > > > > speed.pypy.org will be the reference site for this, but Maciej > > indicated at the VM summit that the code that runs that site needs > > some improvements before it will really be up to the task of > > effectively benchmarking multiple targets. > > > > So, according to http://speed.pypy.org/about/, the place to start with > > your benchmarking system would probably be > > https://github.com/tobami/codespeed. > > > > Cheers, > > Nick. > > Essentially echoing what nick said. I'm currently working on getting > the HW for this together. > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] Information about how cpython in benchmarked
Hi all, Apologies for emailing this list with such an apparently trivial question. Is there some source of documentation or information on how Python is benchmarked? I am aware of the Python regression testing module, regrtest.py, which I presume, if profiled, would good be a good baseline test. PyPy maintains http://speed.pypy.org/, which provides very clear information about the relative performance of PyPy trunk against some version of cpython (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, but that could easily just be my ignorance speaking. My interest is that I'm looking at building a benchmarking solution at work. and I can't think of a better way to build something good and general than to try and write something that could potentially be released as open source and be useful to others. As such I thought that benchmarking cpython would be a great use case, but I want to find out as much as I can about how people currently go about benchmarking Python. Initially I'm just looking at CPU profiling since it's easiest. Anyway, if this is the wrong place to send this email, I'm very sorry for clogging up your inbox. Thanks very much, -Tennessee ___ 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] Shorter release schedule?
On Wed, May 13, 2009 at 1:26 PM, "Martin v. Löwis" wrote: > > Just food for thought here, but seeing how 3.1 is going to be a real > featureful > > schedule despite being released shortly after 3.0, wouldn't it make sense > to > > tighten future release planning a little? > > Do you have any specific releases in mind that you would like to apply > such a tightened schedule to? > > > I was thinking something like doing a > > major release every 12 months (rather than 18 to 24 months as has been > > heuristically the case lately). > If I can just respond with a bit of feedback from my workplace, I'd say that slower is better. I'm grimacing as I write that :) because I personally love to be able to take advantage of the new capabilities in each release. Can I ask if there's any sense in pursuing a release schedule which is slow for whatever might be deemed the "most core modules" but faster for "less core modules"? This is really a response to my workplace environment. The pro of that is that it's a real example, but the con is that it may not be best practise :) Something else which would definitely be useful for me personally would be a kind of update egg which I could apply to, say, Python 3.0 to bring it up to 3.1 capabilities. Something that already happens now at work reasonably often is that on my PC I have Python 2.4, 2.5, 2.6 and 3.0 installed. I tend to develop under 2.6 from preference. However, server X only has 2.4 installed or worse, 2.3 which I don't even have. Recently I was bitten by this as my code was relying heavily on some functionality in datetime which had changed. I was faced with having to do some re-architecting that I really didn't want to do. Now, I don't know of course (I found another way around the issue), but suppose the changes to Python I needed were relatively cosmetic, i.e. the kind of thing I could maybe install into a virtualenv wrapper, then it would have been quite easy for me to run my scripts written for Python 2.6. To get to the point, I wonder if it would be possible to release new versions alongside a patch or egg which someone with only user-level privileges could use on a server to avoid being held back by a slower server update cycle. A more frequent update cycle would then be easier to deal with. More features would get out into use more quickly, while the pressures of the lowest-common-denominator would be eased. Just some thoughts... Regards, -Tennessee ___ 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-Dev Digest, Vol 69, Issue 143
Actually, that's a point. If its' the 31st of Jan, then +1 monthdelta will be 28 Feb and another +1 will be 28 March whereas 31st Jan +2 monthdeltas will be 31 March. That's the kind of thing which really needs to be documented, or I think people really will make mistakes. For example, should a monthdelta include a goal-day so that the example above would go 31 Jan / 28 Feb / 31 March? -T On Fri, Apr 17, 2009 at 11:55 AM, Greg Ewing wrote: > Jess Austin wrote: > > This is a perceptive observation: in the absence of parentheses to >> dictate a different order of operations, the third quantity will >> differ from the second. >> > > Another aspect of this is the use case mentioned right > at the beginning of this discussion concerning a recurring > event on a particular day of the month. > > If you do this the naive way by just repeatedly adding one > of these monthdeltas to the previous date, and the date is > near the end of the month, it will eventually end up > drifting to the 28th of every month. > > -- > Greg > > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Issue5434: datetime.monthdelta
My thoughts on balance regarding monthdeltas: -- Month operations are useful, people will want to do them -- I think having a monthdelta object rather than a method makes sense to me -- I think the documentation is severely underdone. The functionality is not intuitive and therefore the docs need a lot more detail than usual -- Can you specify "1 month plus 10 days"?, i.e. add a monthdelta to a timedelta? -- What about other cyclical periods (fortnights, 28 days, lunar cycles, high tides)? Cheers, -T ___ 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] Issue5434: datetime.monthdelta
Hi Jess, I'm sorry if I'm failing to understand the use of this function from not looking closely at your code. I'm a bit dubious about the usefulness of this (I'm not sure I understand the use cases), but I'm very open to being convinced. Datetime semantics are very important in some areas -- I use them a lot. I'm not convinced the semantics of monthdelta are obvious. A month doesn't have a consistent length -- it could be 28, 29, 30 or 31 days. What happens when you ask for the date in "1 month's" time on the 31st Jan? What date is a month after the 31st Jan? Do you have a good spec (er, I mean PEP) for this describing what happens in the edge cases and what is meant by a monthdelta? The bug notes say it "deals sensibly" with these issues, but that's really not enough to understand what the function is likely to do. At the very least, a few well-chosen examples would help to illustrate the functionality much more clearly. Cheers, -Tennessee On Thu, Apr 16, 2009 at 4:18 PM, Jess Austin wrote: > hi, > > I'm new to python core development, and I've been advised to write to > python-dev concerning a feature/patch I've placed at > http://bugs.python.org/issue5434, with Rietveld at > http://codereview.appspot.com/25079. > > This patch adds a "monthdelta" class and a "monthmod" function to the > datetime module. The monthdelta class is much like the existing > timedelta class, except that it represents months offset from a date, > rather than an exact period offset from a date. This allows us to > easily say, e.g. "3 months from now" without worrying about the number > of days in the intervening months. > >>>> date(2008, 1, 30) + monthdelta(1) >datetime.date(2008, 2, 29) >>>> date(2008, 1, 30) + monthdelta(2) >datetime.date(2008, 3, 30) > > The monthmod function, named in (imperfect) analogy to divmod, allows > us to round-trip by returning the interim between two dates > represented as a (monthdelta, timedelta) tuple: > >>>> monthmod(date(2008, 1, 14), date(2009, 4, 2)) >(datetime.monthdelta(14), datetime.timedelta(19)) > > Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td > > These also work with datetimes! There are more details in the > documentation included in the patch. In addition to the C module > file, I've updated the datetime CAPI, the documentation, and tests. > > I feel this would be a good addition to core python. In my work, I've > often ended up writing annoying one-off "add-a-month" or similar > functions. I think since months work differently than most other time > periods, a new object is justified rather than trying to shoe-horn > something like this into timedelta. I also think that the round-trip > functionality provided by monthmod is important to ensure that > monthdeltas are "first-class" objects. > > Please let me know what you think of the idea and/or its execution. > > thanks, > Jess Austin > _______ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Google Summer of Code/core Python projects - RFC
Well, I think Numpy is of huge importance to a major Python user segment, the scientific community. I don't know if that makes it 'core', but I strongly agree that it's important. Better testing is always useful, and more "core", but IMO less important. -T On Sat, Apr 11, 2009 at 6:38 AM, C. Titus Brown wrote: > Hi all, > > this year we have 10-12 GSoC applications that I've put in the "relevant > to core Python development" category. These projects, if mentors etc > are found, are *guaranteed* a slot under the PSF GSoC umbrella. As > backup GSoC admin and general busybody, I've taken on the work of > coordinating these as a special subgroup within the PSF GSoC, and I > thought it would be good to mention them to python-dev. > > Note that all of them have been run by a few different committers, > including Martin, Tarek, Benjamin, and Brett, and they've been obliging > enough to triage a few of them. Thanks, guys! > > Here's what's left after that triage. Note that except for the four at > the top, these have all received positive support from *someone* who is > a committer and I don't think we need to discuss them here -- patches > etc. can go through normal "python-dev" channels during the course of the > summer. > > I am looking for feedback on the first four, though. Can these > reasonably be considered "core" priorites for Python? Remember, this > "costs" us something in the sense of preferring these over Python > subprojects like (random example) Cython, NumPy, PySoy, Tahoe, Gajim, > etc. > > --- > > Questionable "core": > > 2x "port NumPy to py3k" -- NumPy is a major Python module and porting it >to py3k fits with Guido's request that "more stuff get ported". >To be clear, I don't think anyone expects all of NumPy to get >ported this summer, but these students will work through issues >associated with porting big chunks o' code to py3k. > >One medium/strong proposal, one medium/weak proposal. > > Comments/thoughts? > > 2x "improve testing tools for py3k" -- variously focus on improving test >coverage and testing wrappers. > >One proposes to provide a nice wrapper to make nose and py.test >capable of running the regrtests, which (with no change to >regrtest) would let people run tests in parallel, distribute or >run tests across multiple machines (including Snakebite), tag >and run subsets of tests with personal and/or public tags, and >otherwise take advantage of many of the nice features of nose >and py.test. > >The other proposes to measure & increase the code coverage of >the py3k tests in both Python and C, integrate across multiple >machines, and otherwise provide a nice set of integrated reports >that anyone can generate on their own machines. This proposal, >in particular, could move smoothly towards the effort to produce >a "Python-wide" test suite for CPython/IronPython/PyPy/Jython. >(This wasn't integrated into the proposal because I only found >out about it after the proposals were due.) > >I personally think that both testing proposals are good, and >they grew out of conversations I had with Brett, who thinks that >the general ideas are good. So, err, I'm looking for pushback, >I guess ;). I can expand on these ideas a bit if people are >interested. > >Both proposals are medium at least, and I've personally been >positively impressed with the student interaction. > > Comments/thoughts? > > --- > > Unquestionably "core" by my criteria above: > > 3to2 tool -- 'nuff said. > > subprocess improvement -- integrating, testing, and proposing some of >the various subprocess improvements that have passed across this >list & the bug tracker > > IDLE/Tkinter patch integration & improvement -- deal with ~120 tracker >issues relating to IDLE and Tkinter. > > roundup VCS integration / build tools to support core development -- >a single student proposed both of these and has received some >support. See http://slexy.org/view/s2pFgWxufI for details. > > sphinx framework improvement -- support for per-paragraph comments and >user/developer interface for submitting/committing fixes > > 2x "keyring package" -- see > > http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/ > . > The poorer
Re: [Python-Dev] http://bugs.python.org/issue2240
On Wed, Apr 8, 2009 at 3:55 PM, Jeroen Ruigrok van der Werven < asmo...@in-nomine.org> wrote: > -On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com) > wrote: > >It seems like the bug relates only to an older version of a 'weird' > >operating system and could perhaps be left unfixed without causing > >anyone any problems. > > Being one of the FreeBSD guys I'll throw peanuts at you. :P > > In any case, 6.3 is from early 2008 and 6.4 is from November 2008. The > 6-STABLE branch is still open and a lot of users are still tracking this. > > However, the main focus is 7 and with 8 looming on the horizon. And FreeBSD > 7 does away with libc_r and uses a whole different model for its threading. > Are the tests going ok there? If so, then I shouldn't worry about the 6 > branch. :) Thanks for your input. I've done the paper shuffling so someone else can pick up the FreeBSD cleanup job as a new issue... Cheers, -T ___ 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
[Python-Dev] slightly inconsistent set/list pop behaviour
Now, I know that sets aren't ordered, but... foo = set([1,2,3,4,5]) bar = [1,2,3,4,5] foo.pop() will reliably return 1 while bar.pop() will return 5 discuss :) Cheers, -T ___ 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] http://bugs.python.org/issue2240
On Wed, Apr 8, 2009 at 1:14 PM, Guilherme Polo wrote: > On Tue, Apr 7, 2009 at 11:54 PM, Tennessee Leeuwenburg > wrote: > > This issue has been largely resolved, but there is an outstanding bug > where > > the (reviewed and committed) solution does not work on certain versions > of > > FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported > > platforms', and is FreeBSD 6.3 in it? > > > > What's the policy with regards to supporting dependencies like this? > Should > > I set this issue to 'pending' seeing as no-one is currently working on a > > patch for this? Or is leaving this open and hanging around exactly the > right > > thing to do? > > > > I would find more appropriate to close this as fixed because the issue > was about adding setitimer and getitimer wrappers and that is done. > > We could then create another issue regarding this bug in specific > versions of freebsd towards this setitimer/getitimer wrapper. That is > what makes more sense to me. Hi Guilherme, I'd agree with that. I just wonder whether it's necessary to create another issue, or whether the issue can be marked as 'fixed' without opening the new issue. It seems like the bug relates only to an older version of a 'weird' operating system and could perhaps be left unfixed without causing anyone any problems. Cheers, -T ___ 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
[Python-Dev] http://bugs.python.org/issue2240
This issue has been largely resolved, but there is an outstanding bug where the (reviewed and committed) solution does not work on certain versions of FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported platforms', and is FreeBSD 6.3 in it? What's the policy with regards to supporting dependencies like this? Should I set this issue to 'pending' seeing as no-one is currently working on a patch for this? Or is leaving this open and hanging around exactly the right thing to do? Cheers, -T -- ---------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] Is there an issue with bugs.python.org currently
Sadly, my work firewall/proxy often handles things badly, so I can't actually tell. Is bugs.python.org accepting changes at the moment (I'm trying to update the Stage of an issue)? Cheers, -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] "setuptools has divided the Python community"
I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python The prime limitation of setuptools appears to me to come when there are conflicts. Other than that, for packages where it is available, I have never had an issue with the functioning of setuptools. It's Just Fine. For issues where there are conflicts, where I have been sufficiently motivated, setting up a virtualenv has more than met my needs. In fact, that's and *awesome* piece of functionality. For case one, where I want to install additional functionality into my system Python interpreter "forever", it would be great to have my system manage this. On my ubuntu machine, this happens. The Ubuntu packages take care of things very satisfactorily and I don't see how anyone would have a problem with it. I don't know what the situation is under Windows, however systems such as the Enthought Python Suite do provide kitchen-sink-included Python distributions. Perhaps an automated updates site could be configured such that there was a package for a variety of "Python + some extra modules" scenarios. For installing applications, I would presume that app developers would generally take care of this themselves, through the use of an MSI or .deb file in order to protect their dependencies somewhat. For anyone looking to extend their interpreter for some specific task, virtualenv and setuptools should do the job, and the developer can just go the extra mile to do the work to get it right themselves. Perhaps the most under-served use case is people who want a kitchen-sink-included distribution, to be managed by their system packages. Either they are not away of systems such as EPS or are opposed to it in principle. Were time and effort no obstacle, I would suggest that it may be worth Python.org offering to host and/or maintain a variety of Python distributions available for installation which include various standard extensions. The model that eclipse takes, with a "base" system and plugins, but with flavoured versions available (i.e. Scientic Python Distribution to include SciPy, Numpy and MatPlotLib for example). Thoughts? On Thu, Mar 26, 2009 at 9:56 AM, Ben Finney < bignose+hates-s...@benfinney.id.au >wrote: > Paul Moore writes: > > > If you would, I'd appreciate it. Sometimes I feel that the > > distutils/setuptools discussions need better input from the > > non-web-developer community. And even more so from the "not a > > developer, just a user" community! > > And the often-obscured community: those who desperately want the > Python stuff to just behave the same way everything else on their > system does, i.e. be managed approrpiately by the operating system > package manager. A Python-specific packaging system which makes it > harder to fit Python packages into a broader OS policy works very much > at odds with that. > > However, I, too, am on a different continent from the conference. > > -- > \“Kill myself? Killing myself is the last thing I'd ever do.” | > `\—Homer, _The Simpsons_ | > _o__) | > Ben Finney > > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] "setuptools has divided the Python community"
GSOC? On Thu, Mar 26, 2009 at 6:05 AM, Steven Bethard wrote: > On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote: > > I use Python for systems admin scripts, Windows services, and database > > management. In my experience (and I agree, it's only one, limited, use > > case) availability of download-and-run bdist_wininst installers for > > every package I used was the only significant requirement I had for > > Python package distribution (I remember pre-distutils days, when being > > able to install a 3rd party package on Windows was a nightmare of > > build-it-yourself guesswork). > > > > Since setuptools came on the scene, I can state with some certainty > > that many packages which would otherwise have been distributed as > > bdist_wininst installers, now aren't. In some cases, only source > > packages are provided (on the basis that easy_install will build what > > you need). In those cases, I can accept that maybe the developer would > > not have built Windows installers even before setuptools arrived. But > > in a significant number of cases - including setuptools itself - > > binary, version-specific eggs for Windows are provided, but no > > bdist_wininst installers. If the developer is willing to build an egg, > > he could just as easily have built an installer - but he now has to > > choose - build one or the other, or both. And not everyone chooses the > > same way. > > I'd just like to chime in and agree with Paul here. I'm a Windows > user, and I won't install a Python module that I can't get as a > wininst (or preferably a .msi), because I prefer to use the Windows > package management system, not some Python specific thing. I can > generally build installers myself for Python-only packages, but binary > ones are harder. And I've seen several projects with exactly the kind > of thing Paul describes - where a good Windows installer would > probably have been available if it weren't for the interference of > setuptools. > > Steve > -- > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a > tiny blip on the distant coast of sanity. >--- Bucky Katt, Get Fuzzy > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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 options
Hi Ron,
Good flowchart.
Cheers,
-T
On Wed, Mar 25, 2009 at 1:11 PM, Ron Adam wrote:
>
>
> Tennessee Leeuwenburg wrote:
>
>> Hi all,
>>
>> I'm continuing to (slowly) work through issues. I have been looking
>> particularly at a lot of the open issues regarding strftime.
>>
>> It would be great to put in some of those extra status options that were
>> discussed recently...
>>
>> "Open/New"
>> "Needs help / Chatting"
>> "Under development"
>> "Pending feedback"
>> "Closed"
>>
>> For everyone's reference, after some debate, the above list of status
>> options was where the conversation finished. So the two options "Needs help
>> / chatting" and "Under development" would need to be added. Issues that are
>> "Under development" should revert to "Needs help / chatting" after a month
>> of inactivity.
>>
>> Would it be possible to get these put in? Maybe I'm one of a small number
>> of people who are nibbling at the bottom end of the bugs, but I find it
>> somewhat frustrating not to be able to classify the issues that I find into
>> "needs help / chatting" vs "under development" to help make more sense of
>> the search results.
>>
>> Cheers,
>> -T
>>
>
>
>
> Maybe a flow chart can help unambiguize things a bit. What follows is
> maybe one starting place. I tried to separate steps that might be done by
> users from developers so that there is a clear order to the process. This
> seems to follow the general way that python issues are resolved from what
> I've observed.
>
> While this chart separates the descriptive/brain storming and patch making
> parts of an issue, in actuality, a patch (tests, fix, and docs) can be
> developed partially or fully in the discussion faze for the purpose of
> helping the discussion, then later reused and fine tuned in the patch making
> faze.
>
> Hope this is helpful and doesn't get too mangled in sending.
>
>(new issue)
>|
>v
>
>[discuss issue] <-+
>| |
>v |
> |
>{request issue review}|
>| |
>v |
> |
> (yes)--> [close issue] |
> (no)| |
>| v |
>| (closed) |
>v |
> |
> (no)--+
> (yes)
>|
>v
>
>[develop patch] <--+
>| |
>v |
>|
>{request patch review} |
>| |
>v |
>|
> (no) ---+
> (yes)
>|
>v
>
>[apply patch]
>|
>v
>
>[close issue]
>|
>v
>
>(closed)
>
>
>
>
--
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
___
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 options
On Tue, Mar 24, 2009 at 11:00 AM, "Martin v. Löwis" wrote: > > That would be great. It occurs to me that if we wanted to use > > "Stage" settings, it would be easy to search for issues which are > > not closed by literally searching for 'not closed' rather than > > 'open'. I think it's also unclear whether the 'pending' stage means > > 'suspended pending additional user feedback' or 'resolution of this > > issue is impending'. My understanding was that it meant 'pending > > additional feedback' in the sense of awaiting, rather than imminent. > > > > > > It's the latter; it's "pending feedback". > > Which "latter" (there seem to be multiple pairs in Tennessee's message)? > > In any case, it's not really "pending feedback". Instead, it means "if > there is no feedback really soon, it will get closed". So closure is > impending and imminent. I think this indicates that the flag in not sufficiently self-descriptive. My understanding, and I think the understanding of some others, is that this flag indicates a suspension of development pending additional feedback, rather the impending conclusion of development pending further feedback. In some of my earlier emails to this list, other developers were happy to mark issues that were being deferred as a result of requiring further specification or clarification as "pending feedback", which is quite the opposite of imminent closure. While some may feel that the use of this flag is unambiguously used to signify imminent closure, I respectfully point out the recent occasions where confusion has occurred, and not just from a single individual. Perhaps some developers have a well-established workflow and interpret these flag in a particular, consistent fashion, however part of the purpose of the issue tracker is to allow a diverse group to work on development as a group. On that basis, I feel that more documentation, and clearer terminology, is required in order to support the bug resolution process. I have identified some gaps in the workflow process which impact me personally in classifying issues. These issues will not impact on all developers; clearly they will be entirely superfluous, perhaps even confusing, for some individuals. However the impact still remains for some. There appears to be a general agreement that ability to distinguish between issues on the following bases would be useful: * Whether the nature of the requirement is still under debate or whether it is well-understood * Whether the issue is "up for grabs" by any developer or whether responsibility lies with an individual or group already * Whether the issue is ready for more serious consideration by more experienced or core developers Since these issues relate primarily to the long-standing, dubious or complex issues which are not fully resolved, often of lower priority, it is apparent that more experienced developers will not find a lot of use in the addition of further flag, but I don't see that their workflow would be frustrated either. I'm happy to put my time an effort into classification of low-priority issues, classification, and code development for areas which would probably not otherwise receive much attention. However, to do this effectively, I need to be able to set up additional parameters against the issues to support the search requirements needed. Doing this on the development tracker seems to be the best approach, seeing as there seems to be some closely-held positions regarding the existing set of flags -- it would be quite inappropriate to disrupt existing workflows for the more experienced and core developers without demonstrating the value of new flags. However, I do feel that adding flags is of very clear value to the development process overall. My suggestion remains to add two additional attributes, either as "stage" or "status" options (personally I still feel 'status' is appropriate, but I don't mind where they go): * Under discussion * Under development This would flag "Open" issues as being up for grabs by any developer, "Under discussion" as something which is not ready for a developer to start work on a solution and which is still being worked out. "Under development" similarly means that everyone who needs to be involved is already involved. Issues that were "under discussion" or "under development" would drop back to "Open" after a month of inactivity. Issues which could not be advanced without further feedback would be marked as "suspended pending feedback", and never drop back to Open. The current "pending feedback" which appears to be used to indicate imminent closure should perhaps be altered to "pending closure". Thus, "Open" indicated triage is required. The default view on the issue tracker should be "all issues not closed". The default view for a triage nurse would be "show me everything that is open". I'm all for more debate on options for these new flags, but I haven't heard a whole lot of alternatives
Re: [Python-Dev] tracker status options
Hi Daniel, That would be great. It occurs to me that if we wanted to use "Stage" settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. In any case, let me know when the tracker is online and I will suggest the tag alterations that I think would be appropriate. Regards, -Tennessee On Fri, Mar 20, 2009 at 10:53 AM, Daniel (ajax) Diniz wrote: > Martin v. Löwis wrote: > > In addition, I would like to see a specification of the exact labels to > > be used, plus a one-line description that should be attached to the > > labels. > > Tennessee, > If you'd like to test those additional status options, I'm setting a > test instance of the Python tracker up at > http://bot.bio.br/python-dev/ . It might be frequently offline for a > while, but once things are stable it'll be reliable enough to perform > such experiments. > > If it's easy on resource usage, I might have one instance following > the Python tracker code closely and a more bleeding-edge one :) > > Regards, > Daniel > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] tracker status options
Hi all, I'm continuing to (slowly) work through issues. I have been looking particularly at a lot of the open issues regarding strftime. It would be great to put in some of those extra status options that were discussed recently... "Open/New" "Needs help / Chatting" "Under development" "Pending feedback" "Closed" For everyone's reference, after some debate, the above list of status options was where the conversation finished. So the two options "Needs help / chatting" and "Under development" would need to be added. Issues that are "Under development" should revert to "Needs help / chatting" after a month of inactivity. Would it be possible to get these put in? Maybe I'm one of a small number of people who are nibbling at the bottom end of the bugs, but I find it somewhat frustrating not to be able to classify the issues that I find into "needs help / chatting" vs "under development" to help make more sense of the search results. Cheers, -T ___ 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
[Python-Dev] Capability to alter issue metadata
Hi all, I am continuing to look at issues in the issue tracker. It would be handy to be able to update some of the metadata fields. For contributions, it's fine to just be able to upload patches / post messages, but I can see any number of issues which could use a bit of looking after. e.g. http://bugs.python.org/issue4535 should probably be set to "pending feedback" I'd be happy to do this kind of thing if people are happy for me to do so... -T -- ------ Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] Approaches to argument type-checking
Hi all, I am currently looking at issue 5236. This issue regards the exception raised when a bytes string is passed into time.strptime. In addition to the specific question I have regarding this issue, I wasn't sure if this was something for python-dev or for the issue comment. However, it does concern general Python coding approach, so just give me a pointer over whether this is better kept on the tracker or whether posting to the list was a good idea (I'm slowly learning!) EXAMPLE OF PROBLEM: >>> time.strptime(b'2009', "%Y") Traceback (most recent call last): File "", line 1, in File "/home/tjl/python3/lib/python3.1/_strptime.py", line 454, in _strptime_time return _strptime(data_string, format)[0] File "/home/tjl/python3/lib/python3.1/_strptime.py", line 322, in _strptime found = format_regex.match(data_string) TypeError: can't use a string pattern on a bytes-like object WHEREAS: >>> time.strftime(b"%Y") Traceback (most recent call last): File "", line 1, in TypeError: strftime() argument 1 must be str, not bytes What is occurring here is that the arguments to strftime are being type-checked up-front, whereas in strptime they are not. Further, srtptime is implemented in a python file, _strptime.py, whiel strftime is implemented in timemodule.c. It appears as though it is generally the case (or at least often the case) that C functions are making use of the vgetargs function which performs a goodly bit of type checking. However, the same does not seem to hold for the Python interface functions. >From the Python interpreter perspective, though, both are in the time module (time.strftime and time.strptime) so the inconsistency is a bit jarring. I can see that I could solve this a few ways: * Do a false-parse of the arguments using the same vgetargs1 method, but not do anything with the return value * Perform a type-check on the relevant argument, data_string, in Python and raise a more specific Exception * Write some kind of generic type-checking helper method which could be re-used Is there a general strategy used in Python development which I should be aware of? i.e. is it customary to type-check every argument of an interface method? Or is it customary not to perform type checking up-front and simply allow the exception to occur deeper in the code? Are there performance issues surrounding defensive programming? Regards, -Tennessee -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] Fwd: Addition of further status options to tracker
On Wed, Mar 11, 2009 at 9:43 AM, Brett Cannon wrote: > > > On Tue, Mar 10, 2009 at 15:33, Nick Coghlan wrote: > >> Brett Cannon wrote: >> > If we can come up with a simple solution to this problem (perhaps have >> > issues set to under development with no activity shift down a status >> > level after a month) then maybe we will have something everyone can be >> > happy with. >> >> If an issue is assigned, then somebody has claimed it and is working on >> it (or it has at least been sent to a specific person for consideration). >> > > Right, but that is for core developers only. I think Tennessee is worrying > about non-core folks. > Absolutely, I don't have any issue with the way the most important issues are being worked on now, I just think that less-experienced developers could do a lot more to help out with simple tasks / early-stage tasks. If the rest of us can help ease the burden by getting issues properly sorted out before they go to core developers (writing unit tests, sorting out requirements clearly, documentation, patch suggestions etc) then they won't need to spend as much time on simple maintenance. Cheers, -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Addition of further status options to tracker
> > I don't mind what approach is taken -- I'm happy to work within the >> current infrastructure if someone can suggest a good way. I really just want >> to be able to start distinguishing between issues that are essentially new >> and under debate versus issues that most people agree are a "Good Thing To >> Do", and then helping those issues advance to the point of implementation by >> discussing and, if necessary, formalising or recording requirements against >> them. >> > > I have always viewed it that if Stage is set to anything other than its > empty default it is worth looking into. But it seems to me what you are > after is some obvious way to disambiguate issues that are feature requests > that someone has just asked for and anyone can work on if they want, and > issues that require attention, i.e. bugs and patches. Is that accurate? Pretty much. I've got two views. One is that I'd like to search for issues that are up for grabs which I could take over, hack on, and generally not get underfoot of core development activity. The other is that I think I can help with issue gardening -- splitting issues up into those which still need some more thought, those which someone should pick up and start working on, etc. * Ideas needing more consideration * Ideas being hotly debated * Good ideas with no owning developer * Ideas currently under initial development * Ideas ready for consideration by the core developers In order to make the most use of experienced developers, I'd say it's important that they spend most of their time concentrated at the bottom of that list. Bugs and patches more or less automatically qualify for that, and they can be searched on pretty effectively now. However, doing gardening on the issues which aren't quite there yet is currently pretty clumsy. Say I'm a core developer and very busy. I'd like to quickly address bugs if possible, and I'm happy to help out on important new issues. I certainly don't want to trawl through a whole lot of immature issues and do the triage myself -- what a waste of time! Right now, what can such a person search on to find the relevant issues? It looks like "patch review" or "commit review" will do nicely. This isn't going to change, so that is still supported. Bugs are essentially everything not a feature request, so that doesn't change either. Okay, so the developer workflow is simple and supported. But what about pre-core development workflow? How about for those involved in performing triage and specification? Where I work, at least 50% of the time is spent just working out what to do. There's a lot of real work in triage and specification, and it really shouldn't be done by core developers who could be churning out shiny new stuff. That means that the triage team (or issue janitors) need to be able to support a workflow this is pretty easy on them, too. At this stage, we're not dealing with code, we're just dealing with problems. If we want people with great ideas to get to the top of the heap quickly, we need some way to facilitate that, while issues that are either inappropriate or being hotly contested don't suck time away from more important things. Anyway, I really do just want to fit in. I'm just butting into some workflow things which seem a bit clumsy when doing issue gardening or when finding coding tasks that are up for grabs for a python-dev newbie... Cheers, -T ___ 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
[Python-Dev] Review of Issue http://bugs.python.org/issue2706, timedelta operators
Hi all, I'm just trying to find my feet with regards to the proper process for reviewing. I'm not sure what's best: * Post the review as a comment on the associated issue. Only nosies will be updated. * Post the review as a comment on the issue, then post a one-line information update to this list * Post the review to this list for consideration * other http://bugs.python.org/issue2706 General topic: Math operations on timedelta objects Last activity: 12 Dec 08 Original owner: webograph This issue covers a number of discrete functional changes. I here review each in turn: 1) Allow truediv, the operator '/', to be applied to two timedeltas (e.g. td1 / td2). The return value is a float representing the number of times that td2 goes into td1. Evaluation: Since both time deltas are quantitative values of the same unit, it makes sense they should be able to support basic math operations. In this case, operation to be added is '/' or truediv. I would personally find this functionality useful, and believe it is a natural addition to the code. Recommendation: That this functionality be recommended for development 2) Allow truediv to be applied to a timedelta and an int or float. The return value is a timedelta representing the fractional proportion of the original timedelta. Evaluation: This makes total sense. Recommendation: That this functionality be recommended for development 2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g. td1 % td2). I think there is some debate here about whether the return value be an integer in microsends, or a timedelta. I personally believe that a timedelta should be returned, representing the amount of time remaining after (td1 // td2) * td2 has been subtracted. The alternative is an integer, but due to a lack of immediate clarity over what time quanta this integer represents, I would suggest returning a unit amount. There is also some discussion of returning (long, timedelta), but I personally fail to see the merits of returning the long without some unit attached. 3) Allow divmod, the operator '%', to be applied to a timedelta and an integer or float. (e.g. % 3). I'm not quite as sold on this. I suggest that more discussion is required to flesh this out further. A patch has been attached which implements some of this behaviour. I would suggest that it's valuable to start doing this work in discrete chunks so that progress can be begun before the issues under debate are resolved. I suggest that it would be appropriate to create three smaller issues, each tackling just one piece of functionality. This should make the changes more atomic and the code patch simpler. -T -- ------ Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Addition of further status options to tracker
On Tue, Mar 10, 2009 at 2:39 PM, Brett Cannon wrote: > > > On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg < > tleeuwenb...@gmail.com> wrote: > >> Hi all, >> >> I am beginning reviewing some more issues in the tracker. I think it would >> be useful to have the following status options (new status options marked >> with a '+'): >> Open: Means that the issue has been created and not further reviewed >> + Request Approved: Means that the issue is marked as worth further >> development by the community >> + Specification Approved: Means that the functionality to be developed >> is written down in some form, and agreed at least in general terms >> (preferably in fairly specific terms) >> + Under Development: Means that an implementation is currently under >> development >> Pending Feedback: Means that work is suspended pending feedback >> + Under Final Review: Means that a patch has been submitted and may be a >> flag that core developers can usefully review the work done without having >> to revisit the whole process >> Closed: Means that the issue is either suspended indefinitely or has >> been resolved (see resolution value) > > > I assume you want all of this for the Status field, correct? > > As for the options, some of these overlap with the Stage field. For > instance, if something has been set to any stage other than > "accepted/rejected" it means it needs to be looked into, so that duplicates > your "Request Approved" status. Similar thing with the review stages and > "Under Final Review". > > But a general "under development" status would probably be worth adding. > That way if an issue is "open" it needs attention, "Under development" means > someone is working on a solution, "pending" means someone is blocking the > issue for more information, and "closed" means closed. > > One thing to watch out for, Tennessee, is getting too specific. Like your > "Request Approved" and "Specification Approved" just seems too heavy-handed > to my tastes. Personally, I prefer to make sure the issue workflow to be > somewhat simple so that people don't end up arguing over stuff like whether > something has been specified well enough to have it set to "Spec Approved" > even if someone else disagrees (which you know would happen). > > -Brett > Hi Brett, Some great points. The "stage" settings do overlap a lot of what I had suggested. What I'm trying to reach is a way to flag quite clearly whether a tracker issue is: * In need of a first response * Being taken care of by someone * Needs the attention of core developers, just about ready At the moment, the open/closed settings are a bit useless -- issues are "Open" until they are finished, at which point they are "Closed". I personally suspect that "Pending feedback" is little-used. At the moment, many "Open" issues are in various states of maturity or disrepair, so the only really useful information is whether an issue is "Closed". Examining the stage options more closely, they are very code-oriented. Really they relate to implementation, not other parts of the process. It's difficult for me as someone who wants to help out with the Issue resolution process as much as coding to take an atomic action to help advance the issue through a process. What do you think about the following "Status" flags: * Open: Means newly-created, needs early attention * + Request for Comment: Means that a discussion regarding functionality is requested * + Under Development: Means that a caring developer is taking care of it * Pending Feedback: blocking on new information * Closed: Means closed Once the issue is marked as under development, more information is then provided by the "Stage" flag. "Request for Comment" means that anyone who is stuck on trying to get their ideas sorted or a loose specification agreed on can call for feedback through this flag. There's still some risk of arguments blocking the progression to "Under development", but the issue owner can at least pass to "Under development" at their own will without requiring universal agreement. Core developers can then search on 'commit review' or 'patch review' to see what could use their attention, while people who are happy to contribute to the debate can search on "Open" and "Request for Comment" issues. Obviously the RFC flag is redundant when an issue is first raised, since the submitter always has the option of simply emailing this list. However, for older, potentially stale is
[Python-Dev] Addition of further status options to tracker
Hi all, I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) My reasoning for this is as follows: Example one: I am currently reviewing issue 2706 which covers datetime.timedelta operators. I have a reasonable amount of familiarity with time programming and think I have some valuable input on the functionality aspects, however I'm not a super-great C programmer. I'd like to help with coming up with the final feature specification, but then leave it to others to consider the merits of the C code patch. Being able to help get this marked as "request approved", then "specification approved" might help speed up a lot of the process of developing the patch and getting it accepted. It also saves code developers from having to develop an implementation while a functionality debate is still ongoing... I think that having these additional steps will help to avoid erroneous development of non-features, and also break up the review process into more manageable chunks of work. Of course I realise not everything needs such a delineated process, but by the same token it might assist in keeping some of the less visible/popular changes moving through the process... Comments welcome! Crocker's rules, but please keep it constructive... -T -- ---------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] reviewing patches
Hi all, I have seen it said that one very useful activity is reviewing patches. Of the issues in the tracker, it is not immediately clear to me what is required of such a review. Many of these patches appear to be bundled in with feature requests, leaving the question of whether the review it judging the quality of the code or the merits of the feature request. I do realise that these issues have probably been previously discussed on this list. Let's take as an example the following issue: http://bugs.python.org/issue1818 This has obviously been around for a while, but not been implemented for some reason. There are no links in any of the comments to any email threads regarding its merits, however I recognise the name of the submitter. This makes me think the patch is probably implementing desirable functionality. However, it has no priority set, which makes me think that the community hasn't yet given it any kind of 'status', insofar as a priority can stand in for desirability. It seems to make sense that code quality reviews should be separated from feature request reviews (quality code evaluation vs desirability of function evaluation) but I don't see how this occurs. I feel a lot more qualified to evaluate code quality than desirability of function. Questions like this make it difficult for someone in my position, who is happy to tackle 'whatever needs to be done', to begin the task of patch reviews. While I'm not sure that a formal or semi-formal approval process would make anything better, I think it would be good if there were some kind of 'executive review' process by which an issue could be marked as being a good thing or not. Regards, -Tennessee -- ------ Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
I don't mind whether its "in" or "out", but as a language user I think it's best to minimise undocumented interfaces. According to that principle, if it's "in", then it should also work as documented (and be documented), and be "supported". If it's "out" then it should either be removed entirely or be marked "private" (i.e. leading underscore, unless I'm mistaking my style guidelines). Cheers, -T On Sat, Mar 7, 2009 at 10:19 AM, Raymond Hettinger wrote: > > [Martin v. Löwis] > >> I disagree that our users are served by constantly breaking the >> API, and removing stuff just because we can. I can't see how >> removing API can possibly serve a user. >> > > Am not following you here. My suggestion was to remove the two > methods in Py3.1 which isn't even in alpha yet. This is for a feature > that has a simple substitute, was undocumented for Py3.0, and had > long been documented in Py2.x as being unreliable. > > It's seems silly to me that an incomplete patch from a year ago > would need to wait another two years to ever see the light of day > (am presuming that 3.1 goes final this summer and that 3.2 follows > 18 months later). That being said, I don't really care much. > We don't actually have to do anything. It could stay in forever > and cause no harm. > > > Raymond > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] draft 3.1 release schedule
> Well, that happens. An alternative to withdrawing entirely, would be > increasing the price (eg, to ten patches as you originally suggested). > Or specifying windows in your calendar when the offer is open. Eg, > avoid doubling up on release times when you need make time to build > installers etc. ... but of course just before release is when people > will get antsy about their "lost" patches. > > I hope that somebody will pick up the slack here, because review is > really important to the workflow, and getting more people involved in > reviewing at some level is more important (because it's less > glamorous in itself) than attracting coders. It's funny ... I would have thought that one of the most attractive aspects of offering patches for inclusion was not just getting feature X into the language, but the opportunity to have your code reviewed by the best of the best, or similarly to review the code of others and really think about its strengths and weaknesses. I would have said that participating in a project at that level would basically be the best opportunity for ongoing learning and development available. I guess I'm saying that I'm surprised people aren't a bit more appreciative of the opportunity to review code. I mean, I wouldn't think that Python was "just work" for anyone who has the passion to commit back to the core project. I don't think I would even be on this list or attempting to put together my first (and almost inconseqentially small) patch if it weren't for the fact that I see it as a huge opportunity. It's certainly not an attempt to 'push' anything into the language. Obviously that's what you found though -- people who weren't really understanding of how the language gets put together. I can imagine having held that view in the past myself, also. I can to some extent understand the perspective of feeling you have some fantastic idea which you'd love to get implemented; yet the people who can make it happen are too concerned with their own issues to take the time to roll in your changes. Would you object to my blogging on the topic in line with the comments that I have just made? I almost feel silly making that kind of suggestion after having only been here a short time -- I feel a bit boorish! -- but having run The Python Papers and also no longer being a 'green' developer at work, I feel as though I do have something to contribute on the topic even if it is somewhat immaturely conceived. Regards, -Tennessee ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Hi Jesse, I'm not sure what the most appropriate thing to do is. I could: (a) leave any multiprocessing changes to you, (b) alter the functioning of the method queue_empty inside test_multiprocessing to test for emptiness in a different manner I'm happy to go ahead and try my hand at making the appropriate changes but I don't want to tread in areas of the code that other people have ownership of. It appears as though the only place in multiprocessing which uses the deprecated call is in the test_multiprocessing file. I also found a call to Queue.empty in wsgui.py. I don't see any authorship tags at the top of this file but the last commiter was Andrew Kuchling. Do I need to contact him regarding this or is it appropriate for me to make the appropriate modifications without consulting him? Apologies to anyone if I appear to be overly tentative OR overly pushy -- I am aware that some people take a great deal of personal ownership of their works, while others are impatient with a soft approach. Regards, -Tennessee On Thu, Mar 5, 2009 at 12:41 PM, wrote: > Yup, I'd need to remove support in multiprocessing too. > > > On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg > wrote: > > Hi all, just FYI... sorry for any list pollution > > > > I went ahead and tried adding a warning to my local checkout. The test > suite raised a DeprecationWarning -- it appears those methods are currently > in use by other Lib code: > > > > > > > > test_multibytecodec_support > > test_multiprocessing > > /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: > Queue.empty() is deprecated, and won't be in 3.2. > > DeprecationWarning) > > /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: > Queue.full() is deprecated, and won't be in 3.2. > > > > DeprecationWarning) > > /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: > Queue.empty() is deprecated, and won't be in 3.2. > > DeprecationWarning) > > /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: > Queue.full() is deprecated, and won't be in 3.2. > > > > DeprecationWarning) > > test_mutants > > test_netrc > > test_nis > > > > Regards, > > -T > > > > On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com> > wrote: > > > > > > > > Just noticed that the empty() and full() methods were still there. > > > > IIRC, we agreed to take them out (but leaving qsize() exposed). > > > > The docs entries and test cases were taken out, but the actual > > > > methods were accidentally left in. > > > > > > > > > > > > If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. > > > > > > > > > > > > I recommend adding a warning to 3.0.2 and removing in 3.1. > > > > Waiting for more 3.x uptake doesn't serve our users well. > > > > IIRC, that was the rationale for cmp() removal in 3.0.1. > > > > Even in 2.x, these methods were documented as being unreliable and were > removed from the 3.0 docs entirely. > > > > We discussed removing them and most of the work was done. > > > > > > > > Guido, any thoughts? > > > > > > > > > > > > Raymond > > > > > > _______ > > > > 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/tleeuwenburg%40gmail.com > > > > > > > > > > > > > > -- > > -- > > Tennessee Leeuwenburg > > http://myownhat.blogspot.com/ > > "Don't believe everything you think" > > > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] forgive my patch submission
I am trying to learn the systems... I'm not trying to force a particular approach to the solution but I want to learn how to correctly follow the process. Please feel free to reject this -- I'm not trying to jump the gun given there isn't even an agreed requirement at this stage. Regards, -Tennessee -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
[Python-Dev] What to do about failing tests
On my local checkout I notice a number of failing tests (test_fileio test_grp test_io test_urllib2_localnet). Is there anything that I should attempt to do regarding these? -Tennessee ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods are currently in use by other Lib code: test_multibytecodec_support test_multiprocessing /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) test_mutants test_netrc test_nis Regards, -T On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger wrote: > Just noticed that the empty() and full() methods were still there. >>> IIRC, we agreed to take them out (but leaving qsize() exposed). >>> The docs entries and test cases were taken out, but the actual >>> methods were accidentally left in. >>> >> >> If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. >> > > I recommend adding a warning to 3.0.2 and removing in 3.1. > Waiting for more 3.x uptake doesn't serve our users well. > IIRC, that was the rationale for cmp() removal in 3.0.1. > Even in 2.x, these methods were documented as being unreliable and were > removed from the 3.0 docs entirely. > We discussed removing them and most of the work was done. > > Guido, any thoughts? > > > Raymond > > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
That code doesn't look t scary... is trying to add a DeprecationWarning something that I could try to learn how to do and try my hand at? Maybe if someone else would like to address that more quickly, they'd be able to keep me in the loop so I can start learning how Things are Done? It looks as though all that is required is to add a warn message indicating the planned removal? I'm not sure if it's better for me to have a go at things quietly or to be more interactive about getting to grips with the code... Cheers, -T On Thu, Mar 5, 2009 at 12:04 PM, Benjamin Peterson wrote: > 2009/3/4 Raymond Hettinger : > > Just notices that the empty() and full() methods were still there. > > IIRC, we agreed to take them out (but leaving qsize() exposed). > > The docs entries and test cases were taken out, but the actual > > methods were accidentally left in. > > If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. > > > > -- > Regards, > Benjamin > ___ > 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/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Hello all, First a comment on-thread: I can't wait to get an ordered dictionary in the stdlib! The discussion regarding suggestions for the name appears to be ongoing. What about the name 'orderdict' instead of 'ordereddict'?. It doesn't contain the double-d, is slightly shorter, and I think a little more typo-friendly. Just my 2c, please feel free to ignore. OrderDict would of course be the alternative-casing version. Secondly, regarding this list: I couldn't find a lot of documentation regarding list culture, so I'm quite nervous about the potential for stepping in where I'm not welcome before I have spent a lot of time 'spinning up' on this issues of this list. I am interested in learning more about how Python is written and, if I can, providing some assistance to that task. However it's going to be a long, slow process for me. At the same time, I do have firsthand knowledge of how hard it can be to get people to contribute to anything to any degree, and as such don't want to be a part of the problem by being too tentative in introducing myself. I would appreciate any pointers regarding what is appreciated on this list and what is not. Hopefully, over time I will be able to make some form of useful, concrete code contributions in the form of patches or documentation, but I do realise it will take a lot of hands-on learning first. Trying to grok the discussions on this list seems like a big part of that. Thanks, -Tennessee ___ 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] Removing the GIL (Me, not you!)
Pardon me for talking with no experience in such matters, but... Okay, incrementing a reference counter is atomic, therefore the cheapest possible operation. Is it possible to keep reference counting atomic in a multi-thread model? Could you do the following... let's consider two threads, "A" and "B". Each time an object is created, a reference count is created in both "A" and "B". Let's suppose "A" has a real reference and "B" has no reference really. Couldn't the GC check two reference registers for a reference count? The object would then be cleaned up only if both registers were 0. To exploit multiple CPUs, you could have two persistent Python processes on each CPU with its own mini-GIL. Object creation would then involve a call to each process to create the reference and GC would involve checking each process to see what their count is. However, it would mean that within each process, threads could create additional references or remove references in an atomic way. In a single-CPU system, this would be the same cost as currently, since I think that situation would devolve to having just one place to check for references. This seems to mean that it is the case that it would be no more expensive for a single-CPU system. In a two-CPU system, I'm no expertise on the actual call overheads of object creation and garbage collection, but logically it would double the effort of object creation and destruction (all such operations now need to occur on both processes) but would keep reference increments and decrements atomic. Once again, I'm really sorry if I'm completely off-base since I have never done any actual coding in this area, but I thought I'd make the suggestion just in case it happened to have relevance. Thanks, -Tennessee ___ 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
[Python-Dev] Compiling Python 2.5 and settinf UCS2 flag
Hi all, I have an unusual use case in which some software I work on compiles a version of Python for distribution. I'm not 100% across this as it's not at all my area of responsibility, but I have been having some issues lately. My hand-compiled version of Python 2.5 works just fine, and in turn uses a hand-compiled Tcl/Tk with threading disabled. The system then re-compiles Python2.5 for its own purposes. At this point, it appears to ignore some of the options originally set using configure for Python. I have enough knowledge/control over the system to pass in some additional compiler flags. I would like to try to force some behaviour normally set as a flag to the configure script. Is there a C compiler flag I can use to force the use of UCS2 unicode? Thanks, -Tennessee ___ 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
