Re: [Python-Dev] Small RFEs and the Bug Tracker

2008-02-19 Thread Martin v. Löwis
> 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

2008-02-19 Thread Christian Heimes
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

2008-02-19 Thread Virgil Dupras
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

2008-02-19 Thread Virgil Dupras
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

2008-02-19 Thread Nick Coghlan
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?

2008-02-19 Thread Giampaolo Rodola'
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

2008-02-19 Thread Nick Coghlan
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?

2008-02-19 Thread Bill Janssen
> 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?

2008-02-19 Thread Travis Oliphant
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)

2008-02-19 Thread Joel Bender
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

2008-02-19 Thread Aahz
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

2008-02-19 Thread Georg Brandl
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-02-19 Thread Facundo Batista
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

2008-02-19 Thread Christian Heimes
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

2008-02-19 Thread Andrew McNabb
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

2008-02-19 Thread Guido van Rossum
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

2008-02-19 Thread Andrew Dalke
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

2008-02-19 Thread Martin v. Löwis
> 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.

2008-02-19 Thread Benjamin Peterson
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

2008-02-19 Thread Martin v. Löwis
>> 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?

2008-02-19 Thread Martin v. Löwis
> 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.

2008-02-19 Thread Martin v. Löwis
> 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

2008-02-19 Thread Brett Cannon
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

2008-02-19 Thread Andrew Dalke
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.

2008-02-19 Thread Stephen J. Turnbull
"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?

2008-02-19 Thread Bill Janssen
> 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

2008-02-19 Thread Steve Holden
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-02-19 Thread Facundo Batista
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

2008-02-19 Thread Steve Holden
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.

2008-02-19 Thread Martin v. Löwis
> 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

2008-02-19 Thread Andrew Dalke
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?

2008-02-19 Thread Martin v. Löwis
> 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

2008-02-19 Thread Brett Cannon
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?

2008-02-19 Thread Bill Janssen
> 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

2008-02-19 Thread Fred Drake
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.

2008-02-19 Thread Georg Brandl
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

2008-02-19 Thread Christian Heimes
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