Re: [Python-Dev] 2.5 status

2006-08-09 Thread Georg Brandl 
Tim Peters wrote:
> [Georg Brandl, on
>  http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords
> potential core dump
> ]
>> This one's almost fixed if we can decide what to do with "levels".
>> I wrote some time ago:
>>
>> """
>> With respect to this bug (which is about stack issues in Python/getargs.c
>> involving misuse of the "levels" array), I think that we can drop the
>> "levels" thing completely. It's only there to tell the user which exact item
>> passed as part of a tuple argument cannot be accepted (and only if that
>> function is implemented in C code). As tuple arguments
>> are very rare "argument x" should be enough to tell the user that
>> something's wrong with that tuple.
>> """
> 
> More, the problem that remains is purely "a head bug":  nobody ever
> bumped into it, and the only way to provoke it is to write C (calling,
> e.g., PyArg_ParseTupleAndKeywords) nesting tuple codes in an argument
> descriptor string to an absurd depth.  This is far from serious --
> heck, it's far from even interesting <0.5 wink>.

I have now found a different solution: as the format code is checked for '('
anyway and the nesting level is tracked, I introduced an upper bound for
it (rev. 51158). I believe that fixes the problem.

Georg

___
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] openSSL and windows binaries - license

2006-08-09 Thread Martin v. Löwis 
Gregory P. Smith schrieb:
> disabling/enabling a cipher in openssl that isn't commonly used and
> isn't even directly exposed via any API to a python user hardly sounds
> like dropping a feature to me.

Strictly speaking, it is dropping a feature: a connection that can get
established with 2.5b3 might not get established with 2.5c1, assuming
a server that requires some IDEA-based cipher.

> (any sane SSL connection will negotiate AES or 3DES
> as its cipher; IDEA isn't required)

Ok, I'll believe you that there isn't a practical risk associated with
dropping that algorithm; I'll see what I can do.

> If the release manager declares, "absolutely no changes to the windows
> build process!"

He didn't declare that: bug fixes are always possible. He declared
"absolutely no new features without explicit permission".

> Then clearly none of the changes I submitted will
> make it in and neither would removing any hint of IDEA in 2.5 as
> they're both too late.

Those changes still need permission, as they constitute a new feature.

> yeah i'd just do that if you're worried about the code being in the
> binary causing a problem.

See, my own worries come from the "if". Should I risk breaking
somebody's application just because somebody else is worried about
breaking patents? You haven't indicated whether you also worry:
do you?

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] openSSL and windows binaries - license

2006-08-09 Thread Gregory P. Smith 
> Strictly speaking, it is dropping a feature: a connection that can get
> established with 2.5b3 might not get established with 2.5c1, assuming
> a server that requires some IDEA-based cipher.
> 
> > (any sane SSL connection will negotiate AES or 3DES
> > as its cipher; IDEA isn't required)
> 
> Ok, I'll believe you that there isn't a practical risk associated with
> dropping that algorithm; I'll see what I can do.

yep.  nothing uses it.  Plus the RFC for TLS (SSL) lists the minimum
supported cipher that all implementations need as 3DES.

> > yeah i'd just do that if you're worried about the code being in the
> > binary causing a problem.
> 
> See, my own worries come from the "if". Should I risk breaking
> somebody's application just because somebody else is worried about
> breaking patents? You haven't indicated whether you also worry:
> do you?

I'm not worried about breaking applications at all in this case.  Many
linux distributions ship with their OpenSSL (used by pretty much all
software on the system including python) without IDEA support.

-greg

___
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] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post)

2006-08-09 Thread Robin Bryce 
This has an sf number now #1537167, and hopefully a clearer
explanation of what I think the problem is. This is not a duplicate of
the earlier "PEP 302 Fix" thread.

Thanks,
Robin


On 07/08/06, Robin Bryce <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Appologies for the lack of an sf#. I tried to submit this there but
> couldn't. (sf is logging me out each time I visit a new page and it is
> refusing my attempt to post anonymously).
>
> Python 2.5b3 (trunk:51136M, Aug  7 2006, 10:48:15)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
>
>
> The need for speed patch commited in revision r46372 included a change
> whose intent was to reduce the number of open calls. The `continue`
> statement at line 1283 in import.c:r51136 has the effect of skipping
> the builtin import machinery if the find_module method of a custom
> importer returns None.
>
> In Python 2.4.3, if find_module returned None the builtin machinery is
> allowed to process the path tail.
>
> In my particular case I am working on an importer that deals with kid
> templates that may or may not exist as .py[c] files.
>
> The short of it is that in Python 2.4.3 this produces a usable module
> ``__import__('foo.a/templateuri')`` wheras in 2.5b3 I get import
> error. The python 2.4.3 implementation *allows* module paths that are
> not seperated with '.' Python 2.5b3 does not allow this and it does
> not look like this was an intentional change. I believe this point
> about 'illeagal' module paths is actualy independent of the regresion
> I am asserting. Detailed session logs are attatched (following the sf
> guidance even though I'm posting to py-dev)
>
> The 'use case' for the importer is: Robin wants to package a default
> template file as normal python module and provide a custom importer
> that allows users of his package to reference both: there own
> templates and html files on the file system in arbitrary locations AND
> the stock templates provided as python modules under the same name
> space. He would like to leave normal imports to the standard
> machinery.
>
> Cheers,
>
> Robin
>
>
>
___
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] returning longs from __hash__()

2006-08-09 Thread Armin Rigo 
Hi Martin,

On Tue, Aug 08, 2006 at 11:14:56PM +0200, "Martin v. L?wis" wrote:
> -   h = PyInt_AsLong(res);
> +   if (PyLong_Check(res))
> +   h = res->ob_type->tp_hash(res);

This bug will keep showing up forever :-)  It's unsafe against a user
subclassing 'long' and overriding __hash__ of that subclass to return
the object itself -- it would cause an infinite C recursion.

Instead, we need either a new API like PyLong_Hash(), or call
'PyLong_Type.tp_hash(res)'.

Same in the other change.


A bientot,

Armin
___
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] Is this a bug?

2006-08-09 Thread Georg Brandl 
Is this considered a bug? Sure, deleting modules from sys.modules
isn't quite common, but it happened to me on one occasion.

Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
 >>> import logging
 >>> import sys
 >>> del logging
 >>> del sys.modules['logging']
 >>> ^D
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
   File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
 for h in _handlerList[:]: # was _handlers.keys():
TypeError: unsubscriptable object
Error in sys.exitfunc:
Traceback (most recent call last):
   File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
 for h in _handlerList[:]: # was _handlers.keys():
TypeError: unsubscriptable object

Obviously, _handlerList (as a global) is already cleaned up, which is why
the subscript fails.

Georg

___
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] Is this a bug?

2006-08-09 Thread Matt Fleming 
On 09/08/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Is this considered a bug? Sure, deleting modules from sys.modules
> isn't quite common, but it happened to me on one occasion.
>
> Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
>  >>> import logging
>  >>> import sys
>  >>> del logging
>  >>> del sys.modules['logging']
>  >>> ^D
> Error in atexit._run_exitfuncs:
> Traceback (most recent call last):
>File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
>  func(*targs, **kargs)
>File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
>  for h in _handlerList[:]: # was _handlers.keys():
> TypeError: unsubscriptable object
> Error in sys.exitfunc:
> Traceback (most recent call last):
>File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
>  func(*targs, **kargs)
>File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
>  for h in _handlerList[:]: # was _handlers.keys():
> TypeError: unsubscriptable object
>
> Obviously, _handlerList (as a global) is already cleaned up, which is why
> the subscript fails.
>
> Georg
>
> ___


Could it be considered a bug in the atexit module (or is that what you
meant)? Seeing as there's no _decent_ way to recover from this error,
perhaps it could just slip silently passed?

-- 
Matt

http://mattssanctuary.blogspot.com
___
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] Is this a bug?

2006-08-09 Thread Josiah Carlson 

Georg Brandl <[EMAIL PROTECTED]> wrote:
> 
> Is this considered a bug? Sure, deleting modules from sys.modules
> isn't quite common, but it happened to me on one occasion.
> 
> Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
>  >>> import logging
>  >>> import sys
>  >>> del logging
>  >>> del sys.modules['logging']
>  >>> ^D
> Error in atexit._run_exitfuncs:
> Traceback (most recent call last):
>File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
>  func(*targs, **kargs)
>File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
>  for h in _handlerList[:]: # was _handlers.keys():
> TypeError: unsubscriptable object
> Error in sys.exitfunc:
> Traceback (most recent call last):
>File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
>  func(*targs, **kargs)
>File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown
>  for h in _handlerList[:]: # was _handlers.keys():
> TypeError: unsubscriptable object
> 
> Obviously, _handlerList (as a global) is already cleaned up, which is why
> the subscript fails.

Interestingly enough, I recently ran into a series of errors relating to
manipulating sys.modules and using imp.load_module...

The imp.load_module and the 3 other simple variants involved importing a
module 'x.y' without the package 'x' having been imported first.  This
resulted in all C-modules being re-initialized (builtins, 3rd party, etc.),
causing things like sys.stdout wrappers to be removed, and in the case
of wx, segfaults galore (especially during shutdown).  Python 2.3 and
2.4 performed these imports silently, while 2.5 complains "SystemError:
Parent module 'x' not loaded", which is actually a useful message, and
helped me fix it.


I have a use-case for replacing sys.modules['__main__'] with a different
module, and initial attempts to do:
sys.modules['__main__'] = other_module
other_module.main()

Resulted in:
AttributeError: 'NoneType' object has no attribute 'main'

This is the case for Python 2.3, 2.4, and 2.5 beta.  prefixing the above
two operations with:
sys.modules['_oldmain'] = sys.modules['__main__']

Is sufficient to prevent Python from tearing down everything after the
sys.modules['__main__'] reassignment.  Not a big deal, but a sys.modules
manipulation that has a gotcha.

 - Josiah

___
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] Is this a bug?

2006-08-09 Thread skip 

Matt> Could it be considered a bug in the atexit module (or is that what
Matt> you meant)?

Or a bug in the logging package?

Skip
___
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] openSSL and windows binaries - license

2006-08-09 Thread Jim Jewett 
On 8/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:

> If distributing the source doesn't violate the patent,
> and distributing a binary doesn't violate the patent,
> then what *would* constitute a violation of a software
> patent?

> Writing new code using the algorithm? Compiling
> something which uses it?

Any of the above, depending on the particular judge.

The difference is that there is now some precedent saying that source
(can be) an expression, rather than an implementation.  There is no
such precedent suggesting protection for anything executable.  This
still doesn't mean that (writing or distributing) source code is
automatically safe -- but in practice, it means lawsuits would be
filed first against those using or distributing a binary.

Since the PSF does not have deep pockets, plaintiffs would prefer not
to involve them.  If the actual defendants had made an affirmative
choice to violate (by changing their own build instructions), other
BigCorps might not blame python for the risk.

"Martin v. Löwis"

> IANAL, but AFAICT, the rights controlled by patent law
> are the right to make, to use, to sell, to offer to sell,
> and to import. ... In general, the right to sell and to offer to
> sell would be relevant for software as well, but not
> so for free software (I assume).

Giving it away interferes with the patent owner's ability to sell it,
and is therefore considered interference with the exclusive right to
sell.

-jJ
___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Neal Becker 
class X (object):
pass

X() += 2

> SyntaxError: can't assign to function call

Suppose I actually had defined __iadd__ for class X.  Python says this
syntax is invalid.  I wish is wasn't.

Here's where I might use it.  Suppose I have a container class.  Suppose I
could make a slice of this container, like so:

c = Container()
s = Slice (c, 0, 10)

where "Slice" is a class.  Then:

s += 2

Would perform iadd on the slice of the container.  A convenient syntax would
be:

Slice (c, 0, 10) += 2

Does anyone else think this would be a good addition to Python?


___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Josiah Carlson 

Neal Becker <[EMAIL PROTECTED]> wrote:
> 
> class X (object):
> pass
> 
> X() += 2
> 
> > SyntaxError: can't assign to function call
[snip]
> Does anyone else think this would be a good addition to Python?

No.  += implies assignment.  As the syntax error states, "can't assign
to function call".

-1

 - Josiah

___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Terry Reedy 

"Neal Becker" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> class X (object):
>pass
>
> X() += 2
>
>> SyntaxError: can't assign to function call
>
> Suppose I actually had defined __iadd__ for class X.  Python says this
> syntax is invalid.  I wish is wasn't.

If you translate to x() = x() +2, with x called just once, it does not make 
sense.  You can bind to names and slots in compound objects, but not to 
objects.

> Here's where I might use it.  Suppose I have a container class.  Suppose 
> I
> could make a slice of this container, like so:
>
> c = Container()
> s = Slice (c, 0, 10)
>
> where "Slice" is a class.  Then:
>
> s += 2
>
> Would perform iadd on the slice of the container.  A convenient syntax 
> would
> be:
>
> Slice (c, 0, 10) += 2

If this were made to work, the unbound object you are making an 
'assignment' to, purely for side effect, would disappear.  So if you don't 
want a separate object to be named and kept around, give your container a 
sliceadd method:
c.sliceadd((0,10), 2)

>
> Does anyone else think this would be a good addition to Python?

I don't.  Augmented assigment is confusing enough to many.

Terry Jan Reedy 



___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Neal Becker 
Terry Reedy wrote:

> 
> "Neal Becker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> class X (object):
>>pass
>>
>> X() += 2
>>
>>> SyntaxError: can't assign to function call
>>
>> Suppose I actually had defined __iadd__ for class X.  Python says this
>> syntax is invalid.  I wish is wasn't.
> 
> If you translate to x() = x() +2, with x called just once, it does not
> make
> sense.  You can bind to names and slots in compound objects, but not to
> objects.
> 
>> Here's where I might use it.  Suppose I have a container class.  Suppose
>> I
>> could make a slice of this container, like so:
>>
>> c = Container()
>> s = Slice (c, 0, 10)
>>
>> where "Slice" is a class.  Then:
>>
>> s += 2
>>
>> Would perform iadd on the slice of the container.  A convenient syntax
>> would
>> be:
>>
>> Slice (c, 0, 10) += 2
> 
> If this were made to work, the unbound object you are making an
> 'assignment' to, purely for side effect, would disappear.  So if you don't
> want a separate object to be named and kept around, give your container a
> sliceadd method:
> c.sliceadd((0,10), 2)
> 
>>
>> Does anyone else think this would be a good addition to Python?
> 
> I don't.  Augmented assigment is confusing enough to many.
> 

I guess I confused things with the augmented assignment.  It's not a
question specific to augmented assignment.  There are 2 questions:

1) Should assignment to a temporary object be allowed?
2) Should the syntax for creation of a temporary object be a constructor
call?

___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Michael Hudson 
Neal Becker <[EMAIL PROTECTED]> writes:

> 1) Should assignment to a temporary object be allowed?

The question doesn't make sense: in Python, you assign to a name,
an attribute or a subscript, and that's it.

Cheers,
mwh

-- 
   I think there's a rather large difference between a stale
twinkie and a kernel swap daemon
-- from Twisted.Quotes
___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Georg Brandl 
Terry Reedy wrote:
> "Neal Becker" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> class X (object):
>>pass
>>
>> X() += 2
>>
>>> SyntaxError: can't assign to function call
>>
>> Suppose I actually had defined __iadd__ for class X.  Python says this
>> syntax is invalid.  I wish is wasn't.
> 
> If you translate to x() = x() +2, with x called just once, it does not make 
> sense.  You can bind to names and slots in compound objects, but not to 
> objects.

This is similar to

x = ([1], 2)
x[0] += [2]

which doesn't currently work either, though it could.

Georg

___
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] httplib and bad response chunking

2006-08-09 Thread John J Lee 
On Sun, 30 Jul 2006, Greg Ward wrote:
[...]
> Did you look at the crude attempt at testing for this bug that I hacked
> into test_httplib.py?  I posted it to bug #1486335 here:
>
>  
> http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=186245&aid=1486335
>
> The idea is simple: put various chunked responses into strings and then
> feed those strings to HTTPConnection.  The trouble is that StringIO does
> not behave the same as a real socket: where HTTPResponse fails one way
> reading from a real socket (eg. infinite loop), it fails differently (or
> not at all) reading from a StringIO.  Makes testing with the FakeSocket
> class in test_httplib.py problematic.

There are always ways around unit testing problems, but...


> Maybe the right way to test httplib is to spawn a server process
> (thread?) to listen on some random port, feed various HTTP responses at
> HTTPConnection/HTTPResponse, and see what happens.  I'm not sure how to
> do that portably, though.  Well, I'll see if I can whip up a Unix-y
> solution and see if anyone knows how to make it portable.

I think adding this kind of functional test is extremely valuable, given 
that we don't seem to have any for httplib at present 
(Lib/test/test_httplib.py does not send any network packets).  Maybe you 
could add a basic smoke test that does a simple successful GET, while 
you're going about adding your chunked encoding regression test(s)?

Oh, wait: there is a functional test that uses the network, but it's at 
the end of httplib.py rather than being part of the test suite, and it 
follows the "Guru Watches Output" pattern :-)

I tried to add a test for urllib2 recently that relied on a python.org URL 
being set up, but the python.org guys are pretty overworked already and 
haven't had time to enable that yet -- so I think that simply from that 
point of view your run-your-own-server approach is better.  Why does it 
need to be unix-y, though?  We have SimpleHTTPServer.  We're not trying to 
test the OS, so I don't see a problem with using loopback and a single 
process -- and that would keep test run times down.  Um, except that MS 
OSes seem a bit odd re the loopback interface -- ISTR that, at least back 
with NT4, you just didn't get a loopback i/face unless you had an ethernet 
driver installed (back then, I was on dialup).

More unit tests would also be valuable, of course.


John

___
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] SyntaxError: can't assign to function call

2006-08-09 Thread Guido van Rossum 
On 8/9/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> > "Neal Becker" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> class X (object):
> >>pass
> >>
> >> X() += 2
> >>
> >>> SyntaxError: can't assign to function call
> >>
> >> Suppose I actually had defined __iadd__ for class X.  Python says this
> >> syntax is invalid.  I wish is wasn't.
> >
> > If you translate to x() = x() +2, with x called just once, it does not make
> > sense.  You can bind to names and slots in compound objects, but not to
> > objects.
>
> This is similar to
>
> x = ([1], 2)
> x[0] += [2]
>
> which doesn't currently work either, though it could.

No it couldn't. You can't assign to x[0]. L += R is defined as L =
L.__iadd__(R) so L must be a valid assignment target.

-- 
--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] SyntaxError: can't assign to function call

2006-08-09 Thread Georg Brandl 
Guido van Rossum wrote:

>> This is similar to
>>
>> x = ([1], 2)
>> x[0] += [2]
>>
>> which doesn't currently work either, though it could.
> 
> No it couldn't. You can't assign to x[0]. L += R is defined as L =
> L.__iadd__(R) so L must be a valid assignment target.
> 

Thanks for making that clear. I actually had filed a bug about that
behavior (http://python.org/sf/1436226), and from your comment to my
proposed patch I inferred that the report was valid, only the patch
wasn't.

Cheers,
Georg

___
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] Dict suppressing exceptions

2006-08-09 Thread Guido van Rossum 
I've been happily ignoring python-dev for the last three weeks or so,
and Neal just pointed me to some thorny issues that are close to
resolution but not quite yet resolved, yet need to be before beta 3 on
August 18 (Friday next week).

Here's my take on the dict-suppressing-exceptions issue (I'll send out
separate messages for each issue where Neal has asked me to weigh in).

It wasn't my idea to stop ignoring exceptions in dict lookups; I would
gladly have put this off until Py3k, where the main problem
(str-unicode __eq__ raising UnicodeError) will go away.

But since people are adamant that they want this in sooner, I suggest
that to minimize breakage we could make an exception for str-unicode
comparisons.

I came up with the following code to reproduce the issue; this prints
0 in 2.2, False in 2.3 and 2.4, but raises UnicodeDecodeError in 2.5
(head):

  a = {u"1": 1}
  x = hash(u"1")
  class C(str):
  def __hash__(s): return x
  print C("\xff") in a

The following patch makes this print False in 2.5 again.

Notes about the patch:

- this also fixes an out-of-date comment that should be fixed even if
the rest of the idea is rejected (lookdict_string() can return NULL
when it calls lookdict)

- the exception could be narrowed even further by only suppressing the
exception when startkey and key are both either str or unicode
instances.

What do people think?

--- Objects/dictobject.c(revision 51180)
+++ Objects/dictobject.c(working copy)
@@ -230,7 +230,8 @@
 lookdict() is general-purpose, and may return NULL if (and only if) a
 comparison raises an exception (this was new in Python 2.5).
 lookdict_string() below is specialized to string keys, comparison of which can
-never raise an exception; that function can never return NULL.  For both, when
+never raise an exception; that function can never return NULL (except when it
+decides to replace itself with the more general lookdict()).  For both, when
 the key isn't found a dictentry* is returned for which the me_value field is
 NULL; this is the slot in the dict at which the key would have been found, and
 the caller can (if it wishes) add the  pair to the returned
@@ -259,8 +260,13 @@
if (ep->me_hash == hash) {
startkey = ep->me_key;
cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
-   if (cmp < 0)
-   return NULL;
+   if (cmp < 0) {
+   if (PyErr_Occurred()==PyExc_UnicodeDecodeError) 
{
+   PyErr_Clear();
+   }
+   else
+   return NULL;
+}
if (ep0 == mp->ma_table && ep->me_key == startkey) {
if (cmp > 0)
return ep;
@@ -289,8 +295,13 @@
if (ep->me_hash == hash && ep->me_key != dummy) {
startkey = ep->me_key;
cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
-   if (cmp < 0)
-   return NULL;
+   if (cmp < 0) {
+   if (PyErr_Occurred()==PyExc_UnicodeDecodeError) 
{
+   PyErr_Clear();
+   }
+   else
+   return NULL;
+}
if (ep0 == mp->ma_table && ep->me_key == startkey) {
if (cmp > 0)
return ep;


-- 
--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

[Python-Dev] __index__ clipping

2006-08-09 Thread Guido van Rossum 
Here's another issue where Neal thought it would be useful if I
weighed in. I'm not quite sure of the current status, but perhaps the
following would work?

- Called from Python, (10**10).__index__() should return 100L,
not raise an exception or return sys.maxint.

- The nb_index slot is changed to return an object; it should return a
Python int or long without clipping (same as __index__() called from
Python).

- There should be three C APIs (perhaps fewer if some of them are never needed):

  - One to call the nb_index slot, or raise an exception if it's not
set, returning the object

  - One to return the clipped value without an exception
(can still return an exception if something else went wrong)

  - One to return the value if it fits, raise OverflowError if it doesn't

I know this is quite the deviation from the current code but it seems
the most rational and future-proof approach.

-- 
--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

[Python-Dev] cgi DoS attack

2006-08-09 Thread Guido van Rossum 
This is regarding #1112549. I think this can go in. It should also be
backported to 2.4 and to 2.3 (if we ever release another one of that).
I reviewed the code and added some minor comments to the SF tracker.

-- 
--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

[Python-Dev] Dict suppressing exceptions

2006-08-09 Thread Jim Jewett 
> It wasn't my idea to stop ignoring exceptions in dict lookups; I would
> gladly have put this off until Py3k, where the main problem
> (str-unicode __eq__ raising UnicodeError) will go away.

> But since people are adamant that they want this in sooner,

Is this true for dictionaries specifically?

Would there really be strong objections to continuing to swallow
any Exception (not BaseException) raised by __eq__ ?

Writing an __eq__ method that doesn't handle generic objects is
sloppy, but it does happen, and I would hate to wrap all dictionaries
of objects.

-jJ
___
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] openSSL and windows binaries - license

2006-08-09 Thread Greg Ewing 
Martin v. Löwis wrote:

> In the context of an encryption algorithm, the right to
> use would be the most prominent one; you wouldn't be
> allowed to use the algorithm unless you have a patent
> license.

But what does "use" *mean* in relation to an
algorithm?

--
Greg
___
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] __index__ clipping

2006-08-09 Thread Travis E. Oliphant 
Guido van Rossum wrote:
> Here's another issue where Neal thought it would be useful if I
> weighed in. I'm not quite sure of the current status, but perhaps the
> following would work?
> 
> - Called from Python, (10**10).__index__() should return 100L,
> not raise an exception or return sys.maxint.
> 
> - The nb_index slot is changed to return an object; it should return a
> Python int or long without clipping (same as __index__() called from
> Python).

I don't like this approach because nb_int and nb_long are already 
available to convert an object into an int or a long, so the only value 
of nb_index is to make sure that floats aren't able to be converted this 
way.

The value of nb_index is that it provides a "small-overhead" means to 
quickly convert any object that allows it into a Py_ssize_t value which 
is needed in many internal situations (mostly indexing related).

Rather than assume a Python integer is the only candidate for conversion 
to a Py_ssize_t value,  nb_index allows other objects to be used in that 
fashion.  Having another level of indirection where one object is first 
converted to a Python int or Python long (whichever is needed) and then 
to a Py_ssize_t value seems like un-necessary waste to me and will 
needlessly slow certain indexing operations down.

It seems like Nick's recent patches solved the problems that were 
identified.

-Travis













> 
> - There should be three C APIs (perhaps fewer if some of them are never 
> needed):
> 
>   - One to call the nb_index slot, or raise an exception if it's not
> set, returning the object
> 
>   - One to return the clipped value without an exception
> (can still return an exception if something else went wrong)
> 
>   - One to return the value if it fits, raise OverflowError if it doesn't
> 
> I know this is quite the deviation from the current code but it seems
> the most rational and future-proof approach.
> 

___
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] __index__ clipping

2006-08-09 Thread Guido van Rossum 
On 8/9/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Here's another issue where Neal thought it would be useful if I
> > weighed in. I'm not quite sure of the current status, but perhaps the
> > following would work?
> >
> > - Called from Python, (10**10).__index__() should return 100L,
> > not raise an exception or return sys.maxint.
> >
> > - The nb_index slot is changed to return an object; it should return a
> > Python int or long without clipping (same as __index__() called from
> > Python).
>
> I don't like this approach because nb_int and nb_long are already
> available to convert an object into an int or a long, so the only value
> of nb_index is to make sure that floats aren't able to be converted this
> way.
>
> The value of nb_index is that it provides a "small-overhead" means to
> quickly convert any object that allows it into a Py_ssize_t value which
> is needed in many internal situations (mostly indexing related).
>
> Rather than assume a Python integer is the only candidate for conversion
> to a Py_ssize_t value,  nb_index allows other objects to be used in that
> fashion.  Having another level of indirection where one object is first
> converted to a Python int or Python long (whichever is needed) and then
> to a Py_ssize_t value seems like un-necessary waste to me and will
> needlessly slow certain indexing operations down.

Not if the object is implemented in Python, since then the value is
necessarily returned as an int or long object anyway.

Is performance of __index__ really that important?

What do you think (10**10).__index__() should return (when called from Python)?

> It seems like Nick's recent patches solved the problems that were
> identified.

Nick, can you summarize how your patches differ from my proposal?

-- 
--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] Is this a bug?

2006-08-09 Thread Neal Norwitz 
On 8/9/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> 2.4 performed these imports silently, while 2.5 complains "SystemError:
> Parent module 'x' not loaded", which is actually a useful message, and
> helped me fix it.

Can you make a small, self-contained test case?  The SystemError
should be a normal exception and might indicate a deeper problem.

Thanks,
n
___
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] DRAFT: python-dev summary for 2006-07-01 to 2006-07-15

2006-08-09 Thread Steven Bethard 
Here's the summary for the first half of July. Corrections and
comments are greatly apprecieated. Particularly for the section on
restricted execution (though my understanding is that the current
plans are somewhat different than what was discussed during the first
half of July).

=
Announcements
=

---
Python 2.5 schedule
---

Python continues to make progress towards Python 2.5 final. See `PEP
356`_ for more details and the full schedule.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

- `TRUNK FREEZE for 2.5b2, tomorrow Tuesday 11th, 00:00 UTC
`__
- `Subject: RELEASED Python 2.5 (beta 2)
`__
- `TRUNK is UNFROZEN.
`__

--
ctypes in the Python trunk
--

Martin v. Löwis successfully imported the ctypes history into the
Python trunk, so ctypes now shares its repository with the rest of
Python. Thanks everyone for your hard work!

Contributing threads:

- `Moving the ctypes repository to python.org
`__
- `Subversion outage Friday 15:00 GMT
`__
- `SVN write access is back
`__
- `Extended Subversion outage: Friday 16:40 GMT
`__


=
Summaries
=

-
Rebinding non-local names
-

A bug in the Python trunk that allowed augmented assignment to rebind
names in outer scopes initiated a new discussion about how to allow
Python code to rebind non-local names, e.g.::

def counter(n=0):
def increment(i=1):
n += i # change the n in counter
return n
return increment

Guido definitely didn't like the idea of introducing a new rebinding
operator, e.g. ``:=`` or ``.=``. Phillip J. Eby suggested that a dot
prefix to the name could indicate rebinding, e.g.::

def counter(n=0):
def increment(i=1):
.n += i
return .n
return increment

Guido felt uncomfortable with this proposal because it would mean that
in referencing a value the only difference between ``.NAME`` and
``NAME`` was whether or not the name was assigned to at another place
in the same function. This ambiguity could be avoided by requiring all
references to names in outer scopes to be prefixed by the dot, but
that seemed like too large of a change for Python.

There was also some discussion of trying to reuse the global keyword,
but most folks felt that ``outer`` or ``nonlocal`` was a better name::

def counter(n=0):
def increment(i=1):
nonlocal n
n += i
return n
return increment

Guido requested a PEP on the subject, but at the time of this summary,
none was available.

Contributing threads:

- `2.5 and beyond
`__
- `Lexical scoping in Python 3k
`__
- `Explicit Lexical Scoping (pre-PEP?)
`__

--
Python and backwards incompatibilities
--

A `complaint by Greg Black`_ about Python introducing backward
incompatibilities started a long discussion about how Python
developers could stay in better touch with existing user code. Greg
Black's code had relied on undocumented behavior in time.strftime()
that had allowed zeros to be passed in as default values. When that
behavior changed in Python 2.4, Greg's code (along with a number of
other people's code) was broken. Python core didn't have any unittests
for the behavior, so no tests started failing when the change was
made.

Glyph suggested adding a mechanism so that user projects could submit
buildslaves to run their test suites when changes are made to Python.
The goal here would be to identify any de facto coding standards that
weren't tested for in Python's test suite. If a change to Python
caused major projects like Twisted or Zope to start failing
dramatically, that change should be reconsidered even if it didn't
break any documented behavior. People generally thought this was a
great idea, particularly since it might catch some of these changes
earlier than alpha or beta releases.

There was also some concern that the Python 2.5 release cycle had been
sped up too much and users hadn't had enough time to report errors.
However, adding more beta releases (which seemed to be the major
suggestion) also adds more work for release managers and requires more
sche

Re: [Python-Dev] Is this a bug?

2006-08-09 Thread Josiah Carlson 

"Neal Norwitz" <[EMAIL PROTECTED]> wrote:
> 
> On 8/9/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > 2.4 performed these imports silently, while 2.5 complains "SystemError:
> > Parent module 'x' not loaded", which is actually a useful message, and
> > helped me fix it.
> 
> Can you make a small, self-contained test case?  The SystemError
> should be a normal exception and might indicate a deeper problem.


Create a module z.py whose contents are:

#z.py
import sys
import imp

sys.stdout = None
try:
y = imp.load_source('x.y', 'x/y.py', open('x/y.py'))
except:
raise
else:
print "printing should raise an AttributeError, but doesn't"

#end of listing for z.py

Create a module x/y.py whose contents are: (x/__init__.py not required)

#x/y.py
import sys

#end of listing for x/y.py


Running z.py in Python 2.3 and 2.4 produces:
printing should raise an AttributeError, but doesn't

Running z.py in Python 2.5b2 produces:
Traceback (most recent call last):
  File "test.py", line 7, in 
y = imp.load_source('x.y', 'x/y.py', open('x/y.py'))
  File "x/y.py", line 1, in 
import sys
SystemError: Parent module 'x' not loaded


 - Josiah

___
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