Re: [Python-Dev] Small RFEs and the Bug Tracker
> No, I don't, which is why I would find it interesting to run some > queries on the roundup database to have completion statistics for low > activity tickets. Is is possible to get a copy of that db somehow? I would rather not make it available, as it contains certain privacy-related information that we need to withhold. If you provide some SQL statement or Python script that you want me to run on the server - that should be possible. Regards, Martin ___ 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] Small RFEs and the Bug Tracker
Steve Holden wrote: > There there's the Status field. I understand "open" and "closed", but > what's the semantic of "pending". Is it awaiting triage, awaiting status > assignment, or what? I've used pending for two states. For one I've put an issue on pending state when it was fixed on the trunk but we haven't decided if the bugs needs to be fixed in 2.5 as well. I've also set old bugs as pending to give the op a change to reopen the bug within a month. Christian ___ 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] Small RFEs and the Bug Tracker
On 2/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > No, I don't, which is why I would find it interesting to run some
> > queries on the roundup database to have completion statistics for low
> > activity tickets. Is is possible to get a copy of that db somehow?
>
> I would rather not make it available, as it contains certain
> privacy-related information that we need to withhold. If you provide
> some SQL statement or Python script that you want me to run on the
> server - that should be possible.
Hum, Roundup has a rather nice little API to it's issues. Here we go.
It would be nice to have stats for 360 days as well.
#!/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 = 'demo'
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('chatting')
resolution2count = {}
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():
resolution = db.resolution.getnode(resolution_id)
print '%s\t%d' % (resolution.name, count)
___
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] Small RFEs and the Bug Tracker
On 2/19/08, Virgil Dupras <[EMAIL PROTECTED]> wrote:
> closed_status = db.status.lookup('chatting')
Oops, replace 'chatting' with 'closed'
Virgil
___
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] Small RFEs and the Bug Tracker
Brett Cannon wrote: > My issue with keeping the RFEs in the tracker as they are is that it > artificially inflates the open issue count. Python does not have over > 1,700 open bugs. That's a problem with our status reporting, not with the fact that there are RFE's in the issue tracker ;) Adding a 'bug' keyword to go along with the existing 'rfe' keyword might have some merit, allowing separate stats to be reported for 'rfe', 'bug' and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been set). It may also be interesting to separate out the documentation bugs (based on the existing category field), as while those are traps for the unwary and need to be fixed, they're easy to deal with once you realise that the documentation is wrong. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ssl - how to switch back to a plain text socket?
Hi all,
I'm trying to extend the base ftplib module to add SSL/TLS support as
described in RFC-4217 (see also issue 2054).
RFC-4217 defines a certain command ("CCC") which permit to return to a
plain text socket state without closing the connection.
That is useful since that, being FTP a port-hopping protocol (i.e.
data channels may use a random port chosen during the communication),
firewalls need to read passing packets to allow the secondary data
connections.
I've read through ssl.py but I didn't notice anything useful.
It seems that ssl.SSLSocket class does not provide any method/facility
to switch back to a plain text socket state.
___
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] Small RFEs and the Bug Tracker
Christian Heimes wrote: > Steve Holden wrote: >> There there's the Status field. I understand "open" and "closed", but >> what's the semantic of "pending". Is it awaiting triage, awaiting status >> assignment, or what? > > I've used pending for two states. For one I've put an issue on pending > state when it was fixed on the trunk but we haven't decided if the bugs > needs to be fixed in 2.5 as well. I've also set old bugs as pending to > give the op a change to reopen the bug within a month. I've used pending for the former case as well (i.e. when I wanted a verdict from the release manager on whether or not to backport a particular fix to 2.5, but didn't want the issue hanging around as open when I had already fixed it for the trunk). We really do need to write some of this down in an information track PEP so we're all using the same values to mean the same thing... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl - how to switch back to a plain text socket?
> I've read through ssl.py but I didn't notice anything useful. > It seems that ssl.SSLSocket class does not provide any method/facility > to switch back to a plain text socket state. 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. Bill ___ 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] Error in PEP3118?
Lisandro Dalcin wrote: > On 2/11/08, Travis Oliphant <[EMAIL PROTECTED]> wrote: >> My perception is that you are seeing too much of a connection between >> the C-compiler and the PEP description of memory. Perhaps that's not >> it, and I'm missing something else. >> > > Travis, all this make me believe that (perhaps) the 'format' > specification in the new buffer interface is missing the 'C' or 'F' > ordering in the case of a countiguos block. I'm missing something? Or > should we always assume a 'C' ordering? There is an ability to specify 'F' for the overall buffer. In the description of each element, however, (i.e. in the struct-syntax), the multi-dimensional character is always communicated in 'C' order (last-dimension varies the fastest). I thought about adding the ability to specify the multi-dimensional order as 'F' in the struct-syntax for each element, but felt against it as you can simulate 'F' order by thinking of the array in transpose fashion: i.e. your 3x5 Fortran-order array is really a 5x3 (C-order array). Of course, the same is true on the larger scale when we are talking about multi-dimensional arrays of "elements," but on that level connecting with Fortran libraries is much more common and so we have found the help useful in NumPy. -Travis O. ___ 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] Optional positional-only parameters (was Re: [Python-3000] PEP 3102)
Nick Coghlan wrote:
> We've also veered fairly far off topic for the Py3k list - further ideas
> for positional-only argument syntax or decorators should probably be
> kicked around on python-ideas rather than here or python-dev.
For a function specification like this:
def f(w, x=1, *, y, z=2): ...
My preference is for w and x to be positional only, w is required; y and
z are keyword only, y is required.
I personally like the idea that for functions like range([start,] stop
[,step]) that the function describes which combinations of positional
functions are allowed. An alternative would be overloading, which I
would use, albeit rarely:
def _range(x, y, z): ...
def range(y): return _range(None, y, None)
def range(x, y): return _range(x, y, None)
def range(x, y, z): return _range(x, y, z)
As for this relative nonsense:
def test([arg1=1, [[*arg2,] arg3=3,]] arg4): ...
Someday I'll dig around in the interpreter enough to make this work,
just to see what it would be like. But not today.
> Another use would be allowing the '_cache trick' with a varargs
> function, i.e.
>
> def f(*args, _cache={}):
> ...
>
> Personally I don't like this trick though...
My preference for defining persistent variables with a local scope would
be to introduce a "local" or "static" keyword like "global":
def f(*args):
static cache={}
...
But I'm sure that that has been discussed before.
Joel
___
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] Small RFEs and the Bug Tracker
On Tue, Feb 19, 2008, Nick Coghlan wrote: > Brett Cannon wrote: >> >> My issue with keeping the RFEs in the tracker as they are is that it >> artificially inflates the open issue count. Python does not have over >> 1,700 open bugs. > > That's a problem with our status reporting, not with the fact that there > are RFE's in the issue tracker ;) +1 -- speaking as someone who has done lots of tech support, I'm a big fan of the "one database" system. -- 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 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] Small RFEs and the Bug Tracker
Nick Coghlan schrieb: > Brett Cannon wrote: >> My issue with keeping the RFEs in the tracker as they are is that it >> artificially inflates the open issue count. Python does not have over >> 1,700 open bugs. > > That's a problem with our status reporting, not with the fact that there > are RFE's in the issue tracker ;) > > Adding a 'bug' keyword to go along with the existing 'rfe' keyword might > have some merit, allowing separate stats to be reported for 'rfe', 'bug' > and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been > set). Problem is, we don't have an 'rfe' keyword anymore :) Georg ___ 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] Small RFEs and the Bug Tracker
2008/2/19, Georg Brandl <[EMAIL PROTECTED]>: > > Problem is, we don't have an 'rfe' keyword anymore :) > Shall we grow one again? What would happen with PEP 42? will it be deprecated? -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
Facundo Batista wrote: > What would happen with PEP 42? will it be deprecated? It seems 42 isn't the answer at all. What a shame. *scnr* :) Christian ___ 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] trunk-math
On Fri, Feb 15, 2008 at 10:53:14PM -0500, Mark Dickinson wrote: >* New float methods: is_finite, is_inf, is_integer and is_nan. >* New cmath functions: phase, polar and rect, isinf and isnan. >* New complex method: is_finite. This may be a dumb question, but is there any particular reason that the float methods are "is_inf" and "is_nan" but the cmath methods are "isinf" and "isnan"? Anyway, this all looks very useful. Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
On Feb 19, 2008 12:22 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/2/19, Georg Brandl <[EMAIL PROTECTED]>: > > > Problem is, we don't have an 'rfe' keyword anymore :) > > Shall we grow one again? Isn't the RFE type field enough? > What would happen with PEP 42? will it be deprecated? I think it wasn't experiment that doesn't seem to have worked all that well. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] small Grammar questions
I'm finishing up a PLY lexer and parser for the current CVS version of
the Python grammar. As part of it I've been testing a lot of dark
corners in the grammar definition and implementation. Python 2.5 has
some small and rare problems which I'm pleased to note have been
pretty much fixed in Python 2.6.
I have two questions about the grammar definition. Here's a
difference between 2.5 and 2.6.
% cat x.py
c = "This is 'c'"
def spam((a) = c):
print a
spam()
% python2.5 x.py
This is 'c'
% python2.6 x.py
File "x.py", line 2
def spam((a) = c):
SyntaxError: non-default argument follows default argument
I don't understand why that's changed. This shouldn't be a
SyntaxError and there is no non-default argument following the default
argument.
Note that this is still valid
>>> def spam((a,) = c):
... pass
...
I think 2.6 is incorrect. According to the documentation at
http://docs.python.org/ref/function.html
defparameter::= parameter ["=" expression]
sublist ::= parameter ("," parameter)* [","]
parameter ::= identifier | "(" sublist ")"
funcname::= identifier
Second question is about trailing commas in list comprehension. I
don't understand why the commented out line is not allowed.
[x for x in 1]
#[x for x in 1,] # This isn't legal
[x for x in 1,2]
[x for x in 1,2,]
[x for x in 1,2,3]
The Grammar file says
# Backward compatibility cruft to support:
# [ x for x in lambda: True, lambda: False if x() ]
# even while also allowing:
# lambda x: 5 if x else 2
# (But not a mix of the two)
testlist_safe: old_test [(',' old_test)+ [',']]
but if I change it to also allow
testlist_safe : old_test ','
then PLY still doesn't report any ambiguities in the grammar and I
can't find an expression that exhibits a problem.
Could someone here enlighten me?
Andrew
[EMAIL PROTECTED]
___
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] Small RFEs and the Bug Tracker
> We really do need to write some of this down in an information track PEP > so we're all using the same values to mean the same thing... There is actually an official meaning to pending: An issue marked pending will get automatically closed by the tracker after some period of time (which used to be two weeks on SF). The tracker will add a message that the issue was closed because of inactivity. Unfortunately, that feature is not yet implemented. Regards, Martin ___ 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] Nosy lists on issue tracker.
Hi, What is the policy regarding nosy lists? Is it appropriate it add people to it besides oneself? As I cannot assign items, I'm sometimes tempted to add someone relevant to the list. (ie Should I add Georg to documentation related issues?) Thanks for your patience, Benjamin -- Benjamin Peterson Composer, Clarinetist, Programmer, Wikipedian, Food enthusiast, and full-time student "Nothing is more beautiful than an oboe; unless it's a chicken stuck in a vacuum cleaner" ___ 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] Small RFEs and the Bug Tracker
>> 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? Regards, Martin ___ 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] 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. But shouldn't there be a way to invoke SSL_shutdown? You need to get the close_notify alert message sent, IIUC. Regards, Martin ___ 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] Nosy lists on issue tracker.
> What is the policy regarding nosy lists? Is it appropriate it add people > to it besides oneself? As I cannot assign items, I'm sometimes tempted > to add someone relevant to the list. (ie Should I add Georg to > documentation related issues?) I would find it appropriate. In theory, there should be auto-assignment, but that isn't really implemented, and I don't know whether Georg would want to be auto-assigned Documentation or Sphinx issues. It would also be possible to grant users the permission to assign, but given the experience on SF, I'd rather not (users tend to assign their issues to core developers in the hopes of expediting processing of the issue, not realizing that assignment often impedes processing). Regards, Martin ___ 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] small Grammar questions
On Feb 19, 2008 1:38 PM, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> I'm finishing up a PLY lexer and parser for the current CVS version of
> the Python grammar. As part of it I've been testing a lot of dark
> corners in the grammar definition and implementation. Python 2.5 has
> some small and rare problems which I'm pleased to note have been
> pretty much fixed in Python 2.6.
>
> I have two questions about the grammar definition. Here's a
> difference between 2.5 and 2.6.
>
> % cat x.py
> c = "This is 'c'"
> def spam((a) = c):
> print a
> spam()
>
> % python2.5 x.py
> This is 'c'
> % python2.6 x.py
> File "x.py", line 2
> def spam((a) = c):
> SyntaxError: non-default argument follows default argument
>
>
> I don't understand why that's changed. This shouldn't be a
> SyntaxError and there is no non-default argument following the default
> argument.
>
The error might be odd, but I don't see why that should be allowed
syntax. Having a parameter surrounded by a parentheses like that makes
no sense in a context of a place where arbitrary expressions are not
allowed.
> Note that this is still valid
>
> >>> def spam((a,) = c):
> ... pass
> ...
>
> I think 2.6 is incorrect. According to the documentation at
> http://docs.python.org/ref/function.html
>
> defparameter::= parameter ["=" expression]
> sublist ::= parameter ("," parameter)* [","]
> parameter ::= identifier | "(" sublist ")"
> funcname::= identifier
Looking at Grammar/Grammar, the relevant rules are::
parameters: '(' [varargslist] ')'
varargslist: ((fpdef ['=' test] ',')*
('*' NAME [',' '**' NAME] | '**' NAME) |
fpdef ['=' test] (',' fpdef ['=' test])* [','])
fpdef: NAME | '(' fplist ')'
fplist: fpdef (',' fpdef)* [',']
>From what I can tell the grammar does not prevent it. But it is
possible that during AST creation or bytecode compilation a specific
check is made that is throwing the exception...
And checking Python.ast.c:672 seems to suggest it is something the AST
is doing. I don't have time to dig deeper, but if you tried ``svn
blame`` and found out when that line was added the log message give
some clues as to why this is occurring.
>
>
> Second question is about trailing commas in list comprehension. I
> don't understand why the commented out line is not allowed.
>
> [x for x in 1]
> #[x for x in 1,] # This isn't legal
> [x for x in 1,2]
> [x for x in 1,2,]
> [x for x in 1,2,3]
>
> The Grammar file says
>
> # Backward compatibility cruft to support:
> # [ x for x in lambda: True, lambda: False if x() ]
> # even while also allowing:
> # lambda x: 5 if x else 2
> # (But not a mix of the two)
> testlist_safe: old_test [(',' old_test)+ [',']]
>
> but if I change it to also allow
>
> testlist_safe : old_test ','
>
> then PLY still doesn't report any ambiguities in the grammar and I
> can't find an expression that exhibits a problem.
>
> Could someone here enlighten me?
>
Are you asking why the decision was made to make the expression
illegal, or why the grammar is flagging it is wrong?
-Brett
___
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] small Grammar questions
On Feb 19, 2008 1:38 PM, Andrew Dalke <[EMAIL PROTECTED]> wrote: > def spam((a) = c): > print a On Feb 20, 2008 12:29 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > The error might be odd, but I don't see why that should be allowed > syntax. Having a parameter surrounded by a parentheses like that makes > no sense in a context of a place where arbitrary expressions are not > allowed. I'm fine with that. This is a corner that no one but language lawyers will care about. The thing is, the online documentation and the Grammar file allow it, as did Python 2.5. In any case, the error message is not helpful. > From what I can tell the grammar does not prevent it. But it is > possible that during AST creation or bytecode compilation a specific > check is made that is throwing the exception... In my code it's during AST generation... Your pointer to ast.c:672 was helpful. It's stuff jeremy.hylton did in r54415. Now I have to figure out how Python's internal ASTs work.. Which might take a while. > Are you asking why the decision was made to make the expression > illegal, or why the grammar is flagging it is wrong? Why it's illegal. Supporting a comma doesn't seem to make anything ambiguous, but PLY's LALR(1) might handle things that Python itself doesn't and I don't have the experience to tell. There are other places where the grammar definition allows syntax that is rejected later on. Those I can justify by saying it's easier to define the grammar that way (hence f(1+1=2) is legal grammar but illegal Python), or to produce better error messages (like "from .a import *"). But this one prohibiting [x for x in 1,] I can't figure out. Andrew [EMAIL PROTECTED] ___ 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] Nosy lists on issue tracker.
"Martin v. Löwis" writes: > > What is the policy regarding nosy lists? Is it appropriate it add people > > to it besides oneself? As I cannot assign items, I'm sometimes tempted > > to add someone relevant to the list. (ie Should I add Georg to > > documentation related issues?) > > I would find it appropriate. My personal feeling is that it depends on the person. Some people may be prefer to "pull" their issues by searching the tracker regularly, or to read the regular Tracker reports. Overall, in my own project I want developers to think of the tracker as their friend, as an aid to getting the work done that they want done, rather than as a proxy nanny looking out for user interests. The problem of looking out for user interests is important, but IMO a nanny tracker would be counterproductive (nb I have no experience to back that up). I intend to address that by further encouraging developers to "own" the users' problems. > In theory, there should be auto-assignment, but that isn't really > implemented, and I don't know whether Georg would want to be > auto-assigned Documentation or Sphinx issues. I haven't looked closely at the Python tracker, but I noticed that you have a "busybody" detector. I thought that requesting to be on the nosy list was what this detector was for? ___ 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] ssl - how to switch back to a plain text socket?
> But shouldn't there be a way to invoke SSL_shutdown? You need to get > the close_notify alert message sent, IIUC. Perhaps that would be nice, but switching to plain-text use of the socket can be coordinated outside the SSL protocol. I had an accessor for SSL_shutdown, in an earlier version, but there were semantic conflicts with the socket shutdown() method, and I didn't think anyone would use it anyway :-). Bill ___ 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] small Grammar questions
Andrew Dalke wrote: > On Feb 19, 2008 1:38 PM, Andrew Dalke <[EMAIL PROTECTED]> wrote: >> def spam((a) = c): >> print a > > On Feb 20, 2008 12:29 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: [..] >> Are you asking why the decision was made to make the expression >> illegal, or why the grammar is flagging it is wrong? > > Why it's illegal. Supporting a comma doesn't seem to make anything > ambiguous, but PLY's LALR(1) might handle things that Python itself > doesn't and I don't have the experience to tell. > It's illegal, in short, because formal parameters can be names or tuples, and a parenthesized expression (albeit one containing only a single term) is neither. You could argue that parenthesizing a name shouldn't turn it into a value, but to me there does seem to be a significant difference between a and (a) - in Algol 68 terms, the former can be dereferenced automatically while the latter cannot. It's a pretty fine hair to split, though. > There are other places where the grammar definition allows syntax that > is rejected later on. Those I can justify by saying it's easier to > define the grammar that way (hence f(1+1=2) is legal grammar but > illegal Python), or to produce better error messages (like "from .a > import *"). > > But this one prohibiting [x for x in 1,] I can't figure out. > The one that surprised me was the legality of def eggs((a, )=c): pass That just seems like unpacking-abuse to me. You might argue that c might be a singleton tuple, though that is known when the definition is processed, but there's no way you can say the same of a float. Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> def eggs((a, )=2.1): ... pass ... >>> Oops. 'def eggs((a, )=(2.1, )):' I'd have gone for, but your example just seems broken. You really *have* been poking around in little-known crevices, haven't you? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Small RFEs and the Bug Tracker
2008/2/19, "Martin v. Löwis" <[EMAIL PROTECTED]>: > >> 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? For me, none. I'm just trying to converge the mail thread to a result, :) As far as I can see, the place to keep a RFE is the Issue tracker, and in the future we should decide if we deprecate the PEP 42 and move those items to the tracker. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] small Grammar questions
Steve Holden wrote: [...] > The one that surprised me was the legality of > > def eggs((a, )=c): > pass > > That just seems like unpacking-abuse to me. > Needless to say, a call that tries to *use* the default value fails horribly, as the parameter form does require an iterable: >>> def eggs((a, )=2.1): ... pass ... >>> eggs() Traceback (most recent call last): File "", line 1, in File "", line 1, in eggs TypeError: 'float' object is not iterable >>> eggs((2.1, )) >>> regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Nosy lists on issue tracker.
> I haven't looked closely at the Python tracker, but I noticed that you > have a "busybody" detector. I thought that requesting to be on the > nosy list was what this detector was for? No. We also have a mailing list (python-bugs) to which any tracker change is mailed. That's the busybody list. Regards, Martin ___ 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] small Grammar questions
Okay, my conclusion is def f((a)=5) is wrong, and the code should be changed to report a better error message. I'll file a bug against that. and I'm going with Brett suggestion that [x for x in 1,] is not supported because it's almost certainly a programming error. I think therefore the comment in the Grammar file is distracting. As comments can be. On Feb 20, 2008 3:08 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > The one that surprised me was the legality of > > def eggs((a, )=c): > pass > > That just seems like unpacking-abuse to me. Yep. Here's another abuse, since I can't figure when someone needs a destructuring del statement. >>> class X(object): pass ... >>> X.a = 123 >>> X.b = "hello" >>> X.c = 9.801 >>> X.a, X.b, X.c (123, 'hello', 9.8012) >>> del (X.a, (X.b, (X.c,))) >>> X.a, X.b, X.c Traceback (most recent call last): File "", line 1, in AttributeError: type object 'X' has no attribute 'a' >>> Is this going to be possible in Python3k? > You really *have* been poking around in little-known crevices, haven't you? Like this bug from 2.5, fixed in 2.6 >>> from __future__ import with_statement >>> with f(x=5, 6): ... pass ... ValueError: field context_expr is required for With :) Andrew [EMAIL PROTECTED] ___ 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] ssl - how to switch back to a plain text socket?
> Perhaps that would be nice, but switching to plain-text use of the > socket can be coordinated outside the SSL protocol. I had an accessor > for SSL_shutdown, in an earlier version, but there were semantic > conflicts with the socket shutdown() method, and I didn't think anyone > would use it anyway :-). 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 TLS RFC doesn't seem to have a protocol primitive called TLSShutdow()). If the protocol mandates it, coordinating switching to plain-text outside the SSL protocol is no option, no? Regards, Martin ___ 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] small Grammar questions
On Feb 19, 2008 6:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > Steve Holden wrote: > [...] > > The one that surprised me was the legality of > > > > def eggs((a, )=c): > > pass > > > > That just seems like unpacking-abuse to me. > > > Needless to say, a call that tries to *use* the default value fails > horribly, as the parameter form does require an iterable: > > >>> def eggs((a, )=2.1): > ... pass > ... > >>> eggs() > Traceback (most recent call last): >File "", line 1, in >File "", line 1, in eggs > TypeError: 'float' object is not iterable > >>> eggs((2.1, )) > > >>> And this is another reason why they will not appear in Python 3.0. -Brett ___ 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] ssl - how to switch back to a plain text socket?
> 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 ___ 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] Small RFEs and the Bug Tracker
On Feb 18, 2008, at 1:21 PM, Jeroen Ruigrok van der Werven wrote: > A bug tracker is a much better way of registering such information. > It also > can be easier referenced in the future since even though when it is > closed, > the debate and other stuff will remain in the tracker's tickets for > posterity. :) > > PEP: -1 > tracker: +1 I agree with Jeroen completely on this. Using a PEP for this is just plain silly. -Fred -- Fred Drake ___ 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] Nosy lists on issue tracker.
Benjamin Peterson schrieb: > Hi, > What is the policy regarding nosy lists? Is it appropriate it add people > to it besides oneself? As I cannot assign items, I'm sometimes tempted > to add someone relevant to the list. (ie Should I add Georg to > documentation related issues?) In my case, yes please. Georg ___ 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] Small RFEs and the Bug Tracker
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. Christian ___ 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
