Re: [Python-Dev] Small RFEs and the Bug Tracker
On Wed, Feb 20, 2008 at 8:40 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > What's wrong with the rfe type? Why does it have to be a keyword? > > For one it's the name. Personally I didn't know the meaning of RFE until > I googled it. > I agree, the name is a bit confusing when you're not used to it. Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ? Quentin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
Martin v. Löwis wrote: >>> Problem is, we don't have an 'rfe' keyword anymore :) >>> >> Shall we grow one again? > > What's wrong with the rfe type? Why does it have to be a keyword? It must have changed since I last looked at a feature request on the tracker - using a type rather than keyword is fine by me. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl - how to switch back to a plain text socket?
On 20 Feb, 06:08, Bill Janssen <[EMAIL PROTECTED]> wrote: > I suggest using socket.dup(sslsock) to simply create a non-encrypted > copy of the socket, and switch to using that copy. There's no way to > "unwrap" an SSLSocket. It does not seem to work: File "C:\python26\lib\ssl.py", line 115, in read return self._sslobj.read(len) ssl.SSLError: [Errno 1] _ssl.c:1276: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number > > IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they > > apparently didn't read the TLS spec when they wrote the RFC, as the > > I'm pretty dubious about section 5 there. I don't think reverting to > a plaintext state, once you've been in TLS, happens in real life to > real connections being used for FTP. > > Bill I'm not sure, I've seen more than one library and server supporting the CCC command. For example proftpd and tnftpd servers support it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
Andrew MacIntyre wrote: > M.-A. Lemburg wrote: >> If we're down to voting, here's my vote: >> >> +1 on removing the freelists from ints and floats, but not the >>small int sharing optimization >> >> +1 on focusing on improving pymalloc to handle int and float >>object allocations even better >> >> -1 on changing the freelist implementations to use pymalloc for >>allocation of the freelist members instead of malloc, since >>this would potentially lead to pools (and arenas) being held alive >>by just a few objects - in the worst case a whole arena (256kB) >>for just one int object (14 bytes on 32bit platforms). >> >> Eventually, all freelists should be removed, unless there's a >> significant performance loss. > > Sigh... things are never as simple as they seem... > > Prompted by your comment about the small int sharing, which I was aware > of and was not addressing because I was assuming that its value was > unimpeachable, I've been doing some more testing with this and the > freelists. > > I don't have time to write it up tonight, but I've concluded that my > original test scripts and other tests weren't showing the real > performance of the various approaches. Platform (architecture, compiler > etc) oddities & differences complicate life too... I've now written up my testing and attached the write-up to issue 2039 (http://bugs.python.org/issue2039). -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
On Wed, Feb 20, 2008, Andrew MacIntyre wrote: > > I've now written up my testing and attached the write-up to issue 2039 > (http://bugs.python.org/issue2039). Nice work! Too often we (generic we) don't try to re-simplify code. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reminder: bug day on Saturday
We have a bug day this Saturday. Join us on IRC and let's see how many issues we can clear up. http://wiki.python.org/moin/PythonBugDay for more. There are currently 69 bugs marked as 'easy', which is probably more than enough, but if you see anything that's suitable for a new developer, please mark it. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New math functions
On Fri, 15 Feb 2008, Mark Dickinson wrote: > On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> Also, it would be useful to have a new method, float.is_integer(). This >> would be better than the current approach where we make the >> test: if x == floor(x). > > How common is this test? Given the inexact nature of floating-point > arithmetic, checking whether a float is exactly an integer seems like > something that one might actually want to discourage, just like comparing > two floats for equality. Depending on the nature of the computations that produced the float result, there may be no problem with the result being different from the mathematical result. For example, if you are adding up a bunch of multiples of 1/2, a sufficient condition for an exact result is that the (mathematical) total of the absolute values of the numbers isn't too big. After such a computation, meeting the given condition, checking for an integer result is guaranteed to be meaningful and to match what is mathematically wanted. I can't say how often one needs to check a float for being an integer. I believe that "x == floor(x)" is equivalent to "not (x % 1)" which also generalizes to checking for an exact multiple of values other than 1. I suspect, but do not have evidence, that circumstances in which it is useful to check for an integer are likely to be ones in which there is a better-than-usual chance of getting precise float results. How often are you going to check the output of sin() for being an integer? But on the other hand pitfalls will occur if we, for example, replace 1/2 in my example with 1/10, since these are not generally representable in float format. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl - how to switch back to a plain text socket?
> > I suggest using socket.dup(sslsock) to simply create a non-encrypted > > copy of the socket, and switch to using that copy. There's no way to > > "unwrap" an SSLSocket. > > It does not seem to work: > > File "C:\python26\lib\ssl.py", line 115, in read >return self._sslobj.read(len) > ssl.SSLError: [Errno 1] _ssl.c:1276: error:1408F10B:SSL > routines:SSL3_GET_RECORD:wrong version number You're still reading from the _sslobj. Don't do that. Read from the non-encrypted copy, instead. Though I don't believe you'll be able to implement the CCC command this way; the spec specifically says to do the TLS shutdown, and there's no way to emulate it. > I'm not sure, I've seen more than one library and server supporting > the CCC command. > For example proftpd and tnftpd servers support it. But does anyone use it? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
> I agree, the name is a bit confusing when you're not used to it. Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement") > Also I find that, by definition, RFE and feature requests are not > exactly the same. There's a thin line between a new feature and an > enhancement that is supposed to fill a gap/improve things. Should they > really be treated the same way ? I don't understand the difference. Can you please explain it? Are there features that are not enhancements (and if so, why would anybody request them), or are there enhancements which are not features? Are they entirely disjoint sets of things? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: bug day on Saturday
On Feb 20, 2008 8:03 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > We have a bug day this Saturday. Join us on IRC and let's see how > many issues we can clear up. > > http://wiki.python.org/moin/PythonBugDay for more. > > There are currently 69 bugs marked as 'easy', which is probably more > than enough, but if you see anything that's suitable for a new > developer, please mark it. How about marking already submitted patches as easy to get help reviewing? For instance, there are a bunch of test rewrites to move old tests to unittest where it would be rather nice to have another pair of eyes make sure that the tests are thorough enough. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
On Feb 20, 2008 12:39 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > I agree, the name is a bit confusing when you're not used to it. > > > > Renaming it is easy. To the native speakers reading it: What should > > it be called? (please try to come up with something shorter than > > "request for enhancement") > > "feature request"? +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: bug day on Saturday
On Wed, Feb 20, 2008 at 12:37:42PM -0800, Brett Cannon wrote: > How about marking already submitted patches as easy to get help > reviewing? For instance, there are a bunch of test rewrites to move > old tests to unittest where it would be rather nice to have another > pair of eyes make sure that the tests are thorough enough. Sure, go ahead and mark those, too. Though not all patches are easy to review, test improvements are likely to be OK. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
> > Renaming it is easy. To the native speakers reading it: What should > > it be called? (please try to come up with something shorter than > > "request for enhancement") > > > > "feature request"? How about calling it just "enhancement"? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
> It must have changed since I last looked at a feature request on the > tracker - using a type rather than keyword is fine by me. I'm fairly certain the rfe type was there ever since the switchover (at least that's what subversion says: the rfe type was added along with all other types in r52825, on 2006-11-23). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I agree, the name is a bit confusing when you're not used to it. > > Renaming it is easy. To the native speakers reading it: What should > it be called? (please try to come up with something shorter than > "request for enhancement") > "feature request"? > > Also I find that, by definition, RFE and feature requests are not > > exactly the same. There's a thin line between a new feature and an > > enhancement that is supposed to fill a gap/improve things. Should they > > really be treated the same way ? > > I don't understand the difference. Can you please explain it? Are there > features that are not enhancements (and if so, why would anybody request > them), or are there enhancements which are not features? Are they > entirely disjoint sets of things? > The differences are so minimal that it feels like squabbling over minute semantics. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
Guido van Rossum wrote: > On Feb 20, 2008 12:39 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: I agree, the name is a bit confusing when you're not used to it. >>> Renaming it is easy. To the native speakers reading it: What should >>> it be called? (please try to come up with something shorter than >>> "request for enhancement") >> "feature request"? I already had it at enhancement :-) In any case, by BDFL pronouncement, it's "feature request" now. http://bugs.python.org/issue_type6 (as an aside - can anybody tell me how to suppress link/unlink notifications in the history of each issue_type? I don't think we need them (unlike the reverse link's history, i.e. the history of the issue's type field)) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
I consider a feature request something like asking a factorial method ( http://bugs.python.org/issue2138). As for the RFE, (from Wikipedia) "while not technically a bug, it is often tracked in the same manner as a bug as it represents a failure to meet expected behavior, or simply out of convenience". But on second thought, I realize I'm really splitting hairs here. It's not worth treating them separately, I'm perfectly fine with the "feature request" type :-) Quentin On Wed, Feb 20, 2008 at 9:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I agree, the name is a bit confusing when you're not used to it. > > Renaming it is easy. To the native speakers reading it: What should > it be called? (please try to come up with something shorter than > "request for enhancement") > > > Also I find that, by definition, RFE and feature requests are not > > exactly the same. There's a thin line between a new feature and an > > enhancement that is supposed to fill a gap/improve things. Should they > > really be treated the same way ? > > I don't understand the difference. Can you please explain it? Are there > features that are not enhancements (and if so, why would anybody request > them), or are there enhancements which are not features? Are they > entirely disjoint sets of things? > > Regards, > Martin > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl - how to switch back to a plain text socket?
On 20 Feb, 17:39, Bill Janssen <[EMAIL PROTECTED]> wrote: > > I'm not sure, I've seen more than one library and server supporting > > the CCC command. > > For example proftpd and tnftpd servers support it. > > But does anyone use it? > It is useful to permit passive connection behind firewall devices. This is what proftpd documentation says about it: --- quote --- The CCC command makes an encrypted control channel revert back to an unencrypted channel. This helps to solve data connection problems in situations where network equipment (such as firewalls, routers, NAT) peek at the control channel in order to see which ports open. By sending the CCC command and unecrypting the control channel, the network equipment can once again peek at the commands (i.e. PORT and EPRT) in the control channel. Since the CCC command must come after the client has logged in, the USER and PASS commands on the control channel will still be protected by SSL/TLS. --- /quote --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
Martin v. Löwis wrote: >> It must have changed since I last looked at a feature request on the >> tracker - using a type rather than keyword is fine by me. > > I'm fairly certain the rfe type was there ever since the switchover > (at least that's what subversion says: the rfe type was added along > with all other types in r52825, on 2006-11-23). Perhaps we had duplication between the type and the keyword then? It's also possible I'm just misremembering and actually thinking of a completely different bug tracker that had nothing to do with Python. It's a bit of a moot point now anyway. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
Virgil Dupras wrote:
On 2/19/08, Virgil Dupras <[EMAIL PROTECTED]> wrote:
closed_status = db.status.lookup('chatting')
Oops, replace 'chatting' with 'closed'
Ok, I ran the script. It said
Low activity tickets (180 days) broken down per resolution status:
- no selection -547
wont fix423
works for me194
accepted1233
fixed 2257
duplicate 176
later 49
invalid 275
postponed 20
out of date 304
remind 5
rejected448
Attached is the updated script.
Notice that a day has more than 3600 seconds. With
if date2.differenceDate(date1).as_seconds() >= ACTIVITY_DAY_THRESHOLD *
24 * 3600
it gives
- no selection -118
wont fix189
works for me62
accepted310
fixed 611
duplicate 75
later 17
invalid 73
postponed 6
out of date 193
remind 1
rejected180
Regards,
Martin
#!/usr/bin/env python
# I'm building this out of a demo db of roundup, and it doesn't have a
# "Resolution", so I'm doing guesswork here. It shouldn't be very hard
# to modify the script to fit the python db.
PATH_TO_TRACKER = '.'
ACTIVITY_DAY_THRESHOLD = 180
import roundup.instance
def has_large_activity_gap(issue, db):
for first, second in zip(issue.messages, issue.messages[1:]):
date1 = db.msg.getnode(first).date
date2 = db.msg.getnode(second).date
if date2.differenceDate(date1).as_seconds() >= ACTIVITY_DAY_THRESHOLD * 3600:
return True
return False
tracker = roundup.instance.Tracker(PATH_TO_TRACKER)
db = tracker.open()
closed_status = db.status.lookup('closed')
resolution2count = {None:0}
for resolution_id in db.resolution.getnodeids():
resolution2count[resolution_id] = 0
closed_issues = (db.issue.getnode(issue_id) for issue_id in db.issue.find(status=closed_status))
low_activity_issues = (issue for issue in closed_issues if has_large_activity_gap(issue, db))
for issue in low_activity_issues:
resolution2count[issue.resolution] += 1
print 'Low activity tickets (%d days) broken down per resolution status:' % ACTIVITY_DAY_THRESHOLD
print
for resolution_id, count in resolution2count.items():
if resolution_id is None:
resolution = "- no selection -"
else:
resolution = db.resolution.getnode(resolution_id).name
print '%s\t%d' % (resolution, count)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
