Re: [Python-Dev] openSSL and windows binaries - license

[Martin v. Löwis]

Greg Ewing schrieb:
>> 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?

Perform it: do the steps that the algorithm says you should
do, or let a machine do it. IOW, run the code.

If your point is that software patents are evil: I fully
agree.

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

[Michael Hudson]

"Jim Jewett" <[EMAIL PROTECTED]> writes:

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

Armin's reason for changing dictionaries in this way was that enormous
debugging pain was caused by dicts swallowing exceptions raised by
__eq__ methods.  Having the __eq__ methods swallow the exceptions by
themselves would make the situation *worse*, not better.

Cheers,
mwh

-- 
  * vegai wears his reading bra.
   umm, I mean glasses   -- from Twisted.Quotes
___
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] SyntaxError: can't assign to function call

[Martin v. Löwis]

Neal Becker schrieb:
> 1) Should assignment to a temporary object be allowed?

Unlike Michael, I think the question does make sense, and
the answer is "no", for the reason Michael gave: you assign
to names, not to objects.

> 2) Should the syntax for creation of a temporary object be a constructor
> call?

Now, *that* question makes no sense. Why do you need special syntax
to create a temporary object?

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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 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?

I'd suggest that we still inform the programmers of the problem
by issuing a warning (which they can then silence at will),
maybe a new PyExc_UnicodeWarning.

Note that these exceptions help programmers making their applications
Unicode compatible, so silencing them completely would remove the
possibility to detect the case of mixing strings and Unicode as
keys in a dictionary.

BTW, in Py3k, this case would not trigger at all, since all text
would be Unicode and bytes wouldn't be comparable to Unicode
anyway. However, that's a different discussion which we can have
after Python 2.5 is out the door.

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

   if (PyErr_Warn(PyExc_UnicodeWarning,
  "mixing unicode and strings "
  "as dictionary keys") < 0)
return NULL;

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 10 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... 

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Note that we are not discussing changing the behavior of the
>> __eq__ comparison between strings and Unicode, since this has
>> always been to raise exceptions in case the automatic propagation
>> fails.
> 
> Not sure what you are discussing: This is *precisely* what I'm
> discussing. Making that change would solve this problem.

... and introduce a whole set of new problems, namely finding
all the places in your code that are not Unicode compatible.

Instead of reverting the patch and continue to silencing exceptions
in the dict lookup, you are proposing to extend the behavior to all
equal comparisons of strings and Unicode. That would be a major
change in the semantics, not just a bug fix as you seem to imply.

Since the problem of mixing strings and Unicode will go away
in Py3k anyway, I suggest we do everything to help programmers
make their applications Unicode compatible instead of trying
to hide all problem cases from them.

Note that all of these problem go away if you stick to Unicode
for all text data in your application. This will also make
porting the application to Py3k a lot easier.

>
>> The discussion is about silencing exceptions in the dict lookup
>> mechanism - something which used to happen and now no longer
>> is done.

Regards,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 10 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Is this a bug?

[Nick Coghlan]

Josiah Carlson wrote:
> 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.

Early versions of the PEP 338 implementation also ran into the problem of a 
module's globals getting cleared when the module itself goes away - that's why 
runpy makes sure to return a copy of the module's global namespace instead of 
the original.

The core of the problem in the atexit case seems to be the fact that holding 
on to a reference to a function from a module only holds a reference to the 
module's dict, rather than the module object itself.

If you kill the reference to the module from sys.modules, the module object 
goes away, and the dict gets cleared. However, any function objects being held 
elsewhere (e.g. in the atexit list, or as a result of a class being subclassed 
in a different module) still have a reference to the now defunct module 
namespace, and will misbehave when called later on if they attempt to access 
any global variables.

Are we really sure that explicitly clearing the module's globals when the 
module's refcount falls to zero solves more problems than it causes? Or is it 
primarily a legacy of the pre-cyclic GC days when it was absolutely essential 
to manually break the cycle between the module namespace and any functions it 
contained?

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] SimpleXMLWriter missing from elementtree

[Ralf Schmitt]

Hi,

any chance to get SimpleXMLWriter (and other modules maybe??) getting 
included into xml.etree? Otherwise people might have to stick to the 
original elementtree, which doesn't really make sense, since most of 
elementtree already is included.

- Ralf

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

[Ralf Schmitt]

Guido van Rossum wrote:
> 
> - the exception could be narrowed even further by only suppressing the
> exception when startkey and key are both either str or unicode
> instances.
> 

I always assumed dictionaries would work exactly like this. So, at least 
it would now work as I had always expected (and others possibly too).

- Ralf

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

[Michael Urman]

On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > 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.
> > What do people think?
>
> I'd suggest that we still inform the programmers of the problem
> by issuing a warning (which they can then silence at will),
> maybe a new PyExc_UnicodeWarning.
>
> BTW, in Py3k, this case would not trigger at all, since all text
> would be Unicode and bytes wouldn't be comparable to Unicode
> anyway. However, that's a different discussion which we can have
> after Python 2.5 is out the door.

I strongly believe that unicode vs str here is the symptom and not the
actual problem. The comparison between two non-us-ascii str/unicode
instances is but one of many ways to raise an exception during
comparison. It's not even obvious ahead of time when it will occur.
Try my example below with (sys.maxint << 1) and -2 instead of 1 and 1.
Do you expect a problem?

Because str/unicode is the common case, we saw it first. If we address
the symptom instead of the problem, someone will be complaining within
a years time because they have a class that they mix in with other
items for a function handler lookup, or who knows what, that works
like the following:

>>> class hasher(object):
...   def __init__(self, hashval):
... self.hashval = hashval
...   def __hash__(self):
... return hash(self.hashval)
...   def __eq__(self, o):
... if not isinstance(o, hasher):
...   raise TypeError("Cannot compare hashval to non hashval")
... return self.hashval == o.hashval

in python2.4:
>>> dict.fromkeys([1, hasher(1)])
{1: None, <__main__.hasher object at 0xa7a5326c>: None}

in python2.5b2:
>>> dict.fromkeys([1, hasher(1)])
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 8, in __eq__
TypeError: Cannot compare hashval to non hashval

Yes this is made up code. But I'm not arguing for a feature; I'm
arguing for backwards compatibility. Because we do not know where
these legitimate uses are, we cannot evaluate their likelihood to
exist nor the level of breakage they will cause. If we make this a
warning for any exception, we can satisfy both imagined camps. Those
in Armin's position can make that warning raise an exception while
debugging, and those using it on purpose can squash it.

I understand the utility of being able to see this case happening. I'm
not sure it's worth the warning. I'm positive it's not worth the
backwards incompatibility of the raised exception.

Michael
-- 
Michael Urman  http://www.tortall.net/mu/blog
___
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] SyntaxError: can't assign to function call

[Michael Urman]

On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> The question doesn't make sense: in Python, you assign to a name,
> an attribute or a subscript, and that's it.

Just to play devil's advocate here, why not to a function call via a
new __setcall__? I'm not saying there's the use case to justify it,
but I don't see anything that makes it a clear abomination or
impossible with python's syntax.

Michael
-- 
Michael Urman  http://www.tortall.net/mu/blog
___
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] __index__ clipping

[Nick Coghlan]

Guido van Rossum wrote:
>> It seems like Nick's recent patches solved the problems that were
>> identified.
> 
> Nick, can you summarize how your patches differ from my proposal?

nb_index and __index__ are essentially exactly as you propose. To make an 
object implemented in C usable as an index you would take either the nb_int 
slot or the nb_long slot and put the same function pointer into the nb_index 
slot. For a Python object, you would write either '__index__ = __int__' or 
'__index__ = __long__' as part of the class definition.

operator.index is provided to support writing __getitem__, __setitem__ and 
__delitem__ methods - it raises IndexError on overflow so you don't have to 
catch and reraise to convert an OverflowError to an IndexError.

On the C API side, the 3 functions you suggest are all present (although the 
version returning a Python object is accessed via PyObject_CallMethod), and 
there's a 4th variant that raises IndexError instead of OverflowError (this 
version is convenient when writing mp_subscript and mp_ass_subscript functions).

Avoiding Py_ssize_t -> PyInt -> Py_ssize_t conversions for all integer types 
implemented in C would be nice, but I don't think it's practical (the latest 
version of the patch does at least avoid it for the builtin integer types).

Cheers,
Nick.



P.S. Here's the detailed rationale for the form the patch has evolved to [1]:

In addition to allowing (2**100).__index__() == 2**100, having nb_index return 
a Python object resulted in a decent reduction in code duplication - 
previously the coercion logic to get a Python integer or long value down to a 
Py_ssize_t was present in 3 places (long_index, instance_index, 
slot_nb_index), and would also have needed to be duplicated by any other C 
implemented index type whose value could exceed the range of a Py_ssize_t. 
With the patch, that logic appears only inside abstract.c and extension types 
can just return a PyLong value and let the interpreter figure out how to 
handle overflow. The biggest benefit of this approach is that a single slot 
(nb_index) can be used to implement four different overflow behaviours in the 
core (return PyLong, raise OverflowError, raise IndexError, clip to 
Py_ssize_t), as well as providing a hook to allow extension module authors to 
define their own overflow handling.

If the nb_index slot does not return a true Python integer or long, TypeError 
gets raised. Subclasses are not accepted in order to rule out Armin's 
favourite set of recursion problems :)

The C level API is based on the use cases in the standard library, with one of 
the functions generalised a bit to allow extension modules to easily handle 
type errors and overflow differently if they want to.

The three different use cases for nb_index in the standard library are:
   - concrete sequence indices (want IndexError on overflow)
   - 'true integer' retrieval (want OverflowError on overflow)
   - slice endpoints (want to clip to Py_ssize_t max/min values)

The proposed fix (Travis & Neal provided some useful comments on earlier 
versions) includes a C API function for each of these different use cases:

   PyNumber_Index(PyObject *obj, int *type_err)
   PyNumber_AsSsize_t(PyObject *obj, int *type_err)
   PyNumber_AsClippedSsize_t(PyObject *obj, int *type_err, int *clipped)

type_err is an output variable to say "obj does not provide nb_index" in order 
to get rid of boilerplate dealing with PyErr_Occurred() in mp_subscript and 
mp_ass_subscript implementations (those methods generally didn't want a 
TypeError raised at this point - they wanted to go on and check if the object 
was a slice object instead). It's also useful if you want to provide a 
specific error message for TypeErrors (sequence repetition takes advantage of 
this). You can also leave the pointer as NULL and the functions will raise a 
fairly generic TypeError for you. PyObject_GetItem and friends, use the 
functions that way.

Avoiding repeated code is also why there are two non-clipping variants, one 
raising IndexError and one raising OverflowError. Raising OverflowError in 
PyNumber_Index broke half a dozen unit tests, while raising IndexError for 
things like sequence repetition turned out to break different unit tests.

The clipping variant is for slice indices. The interpreter core doesn't 
actually care whether or not the result gets clipped in this case (it sets the 
last parameter to NULL), but I kept the output variable in the signature for 
the benefit of extension authors.

All 3 of the C API methods return Py_ssize_t. The "give me a Python object" 
case isn't actually needed anywhere in the core, but is available to extension 
modules via:
   PyObject_CallMethod(obj, "__index__", NULL)

As Travis notes, indexing with something other than a builtin integer will be 
slightly slower due to the temporary object created by calling the nb_index 
slot (version 4 of the patch avoids this overhead for ints, version 5 avoids 
it for longs 

Re: [Python-Dev] __index__ clipping

[Guido van Rossum]

On 8/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> It seems like Nick's recent patches solved the problems that were
> >> identified.
> >
> > Nick, can you summarize how your patches differ from my proposal?
>
> nb_index and __index__ are essentially exactly as you propose.

Then I don't understand why Travis is objecting against my proposal!

I'll review the rest later (right now I'm just doing email triage :-).

--Guido

> To make an
> object implemented in C usable as an index you would take either the nb_int
> slot or the nb_long slot and put the same function pointer into the nb_index
> slot. For a Python object, you would write either '__index__ = __int__' or
> '__index__ = __long__' as part of the class definition.
>
> operator.index is provided to support writing __getitem__, __setitem__ and
> __delitem__ methods - it raises IndexError on overflow so you don't have to
> catch and reraise to convert an OverflowError to an IndexError.
>
> On the C API side, the 3 functions you suggest are all present (although the
> version returning a Python object is accessed via PyObject_CallMethod), and
> there's a 4th variant that raises IndexError instead of OverflowError (this
> version is convenient when writing mp_subscript and mp_ass_subscript 
> functions).
>
> Avoiding Py_ssize_t -> PyInt -> Py_ssize_t conversions for all integer types
> implemented in C would be nice, but I don't think it's practical (the latest
> version of the patch does at least avoid it for the builtin integer types).
>
> Cheers,
> Nick.
>
>
>
> P.S. Here's the detailed rationale for the form the patch has evolved to [1]:
>
> In addition to allowing (2**100).__index__() == 2**100, having nb_index return
> a Python object resulted in a decent reduction in code duplication -
> previously the coercion logic to get a Python integer or long value down to a
> Py_ssize_t was present in 3 places (long_index, instance_index,
> slot_nb_index), and would also have needed to be duplicated by any other C
> implemented index type whose value could exceed the range of a Py_ssize_t.
> With the patch, that logic appears only inside abstract.c and extension types
> can just return a PyLong value and let the interpreter figure out how to
> handle overflow. The biggest benefit of this approach is that a single slot
> (nb_index) can be used to implement four different overflow behaviours in the
> core (return PyLong, raise OverflowError, raise IndexError, clip to
> Py_ssize_t), as well as providing a hook to allow extension module authors to
> define their own overflow handling.
>
> If the nb_index slot does not return a true Python integer or long, TypeError
> gets raised. Subclasses are not accepted in order to rule out Armin's
> favourite set of recursion problems :)
>
> The C level API is based on the use cases in the standard library, with one of
> the functions generalised a bit to allow extension modules to easily handle
> type errors and overflow differently if they want to.
>
> The three different use cases for nb_index in the standard library are:
>- concrete sequence indices (want IndexError on overflow)
>- 'true integer' retrieval (want OverflowError on overflow)
>- slice endpoints (want to clip to Py_ssize_t max/min values)
>
> The proposed fix (Travis & Neal provided some useful comments on earlier
> versions) includes a C API function for each of these different use cases:
>
>PyNumber_Index(PyObject *obj, int *type_err)
>PyNumber_AsSsize_t(PyObject *obj, int *type_err)
>PyNumber_AsClippedSsize_t(PyObject *obj, int *type_err, int *clipped)
>
> type_err is an output variable to say "obj does not provide nb_index" in order
> to get rid of boilerplate dealing with PyErr_Occurred() in mp_subscript and
> mp_ass_subscript implementations (those methods generally didn't want a
> TypeError raised at this point - they wanted to go on and check if the object
> was a slice object instead). It's also useful if you want to provide a
> specific error message for TypeErrors (sequence repetition takes advantage of
> this). You can also leave the pointer as NULL and the functions will raise a
> fairly generic TypeError for you. PyObject_GetItem and friends, use the
> functions that way.
>
> Avoiding repeated code is also why there are two non-clipping variants, one
> raising IndexError and one raising OverflowError. Raising OverflowError in
> PyNumber_Index broke half a dozen unit tests, while raising IndexError for
> things like sequence repetition turned out to break different unit tests.
>
> The clipping variant is for slice indices. The interpreter core doesn't
> actually care whether or not the result gets clipped in this case (it sets the
> last parameter to NULL), but I kept the output variable in the signature for
> the benefit of extension authors.
>
> All 3 of the C API methods return Py_ssize_t. The "give me a Python object"
> case isn't actually needed anywhere in the core, but is available

Re: [Python-Dev] Dict suppressing exceptions

[Guido van Rossum]

On 8/10/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> I strongly believe that unicode vs str here is the symptom and not the
> actual problem.

No. Everywhere when __eq__ fails, we can safely tell the user that
it's a bug in their __eq__ that they should fix (maybe by making it
return False when the other object isn't a type they recognize). But
we can't fix unicode-vs-str comparison without breaking too much code.
So we have to somehow deal with that without changing the behavior of
that particular __eq__.

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

Re: [Python-Dev] Dict suppressing exceptions

[Guido van Rossum]

On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'd suggest that we still inform the programmers of the problem
> by issuing a warning (which they can then silence at will),
> maybe a new PyExc_UnicodeWarning.

Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
issue a warning (and return False) instead of raising
UnicodeException? That won't break much code (it's unlikely that
people *depend* on this exception since it's generally a symptom of
insane mixing of str and unicode). Then no further changes to
dictobject.c are necessary (except fixing that one misleading
comment).

> Note that these exceptions help programmers making their applications
> Unicode compatible, so silencing them completely would remove the
> possibility to detect the case of mixing strings and Unicode as
> keys in a dictionary.

A warning would arguably have the same helping effect. (I suspect
actually that we would have used warnings all along except we didn't
have the warning framework when unicode was first introduced.)

> BTW, in Py3k, this case would not trigger at all, since all text
> would be Unicode and bytes wouldn't be comparable to Unicode
> anyway. However, that's a different discussion which we can have
> after Python 2.5 is out the door.

Which is why I said I would have gladly waited until Py3k to fix this.

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

Re: [Python-Dev] __index__ clipping

[Nick Coghlan]

Guido van Rossum wrote:
> On 8/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> >> It seems like Nick's recent patches solved the problems that were
>> >> identified.
>> >
>> > Nick, can you summarize how your patches differ from my proposal?
>>
>> nb_index and __index__ are essentially exactly as you propose.
> 
> Then I don't understand why Travis is objecting against my proposal!

I must admit to being confused by that, too. . .

Cheers,
Nick.

P.S. Just to mess up the release schedule some more, I'm going to be away from 
13-19 August, so the patch either needs to be approved by Neal or Anthony in 
the next few days, or someone else will need to commit it before rc1.

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

[M.-A. Lemburg]

Guido van Rossum wrote:
> On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> I'd suggest that we still inform the programmers of the problem
>> by issuing a warning (which they can then silence at will),
>> maybe a new PyExc_UnicodeWarning.
> 
> Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> issue a warning (and return False) instead of raising
> UnicodeException? That won't break much code (it's unlikely that
> people *depend* on this exception since it's generally a symptom of
> insane mixing of str and unicode). Then no further changes to
> dictobject.c are necessary (except fixing that one misleading
> comment).

Good idea.

>> Note that these exceptions help programmers making their applications
>> Unicode compatible, so silencing them completely would remove the
>> possibility to detect the case of mixing strings and Unicode as
>> keys in a dictionary.
> 
> A warning would arguably have the same helping effect. (I suspect
> actually that we would have used warnings all along except we didn't
> have the warning framework when unicode was first introduced.)

Probably, yes.

These days, I believe that we should have not gone for the
string-Unicode integration magic at all and instead done the
same of what's planned for Py3k. Sometimes a clean cut is better
than trying to muddle along.

>> BTW, in Py3k, this case would not trigger at all, since all text
>> would be Unicode and bytes wouldn't be comparable to Unicode
>> anyway. However, that's a different discussion which we can have
>> after Python 2.5 is out the door.
> 
> Which is why I said I would have gladly waited until Py3k to fix this.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 10 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] SyntaxError: can't assign to function call

[Josiah Carlson]

"Michael Urman" <[EMAIL PROTECTED]> wrote:
> 
> On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> > The question doesn't make sense: in Python, you assign to a name,
> > an attribute or a subscript, and that's it.
> 
> Just to play devil's advocate here, why not to a function call via a
> new __setcall__? I'm not saying there's the use case to justify it,
> but I don't see anything that makes it a clear abomination or
> impossible with python's syntax.

Describe the syntax and semantics.  Every time I try to work them out, I
end up with a construct that makes less than no sense, to be used in
cases I have never seen. Further, if you want to call a method
__setcall__ on an object just created, you can use 'x().__setcall__(y)'.
There is no reason to muck up Python's syntax.


 - Josiah

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

[James Y Knight]

On Aug 10, 2006, at 12:01 PM, Josiah Carlson wrote:

>
> "Michael Urman" <[EMAIL PROTECTED]> wrote:
>>
>> On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>>> The question doesn't make sense: in Python, you assign to a name,
>>> an attribute or a subscript, and that's it.
>>
>> Just to play devil's advocate here, why not to a function call via a
>> new __setcall__? I'm not saying there's the use case to justify it,
>> but I don't see anything that makes it a clear abomination or
>> impossible with python's syntax.
>
> Describe the syntax and semantics.  Every time I try to work them  
> out, I
> end up with a construct that makes less than no sense, to be used in
> cases I have never seen. Further, if you want to call a method
> __setcall__ on an object just created, you can use 'x().__setcall__ 
> (y)'.
> There is no reason to muck up Python's syntax.

It makes just as much sense as assigning to an array access, and the  
semantics would be pretty similar. There's similarly "no reason" to  
allow x[5] = True. You can just spell that x.__setitem__(5, True).

x(*args, **kwargs) = val could translate into x.__setcall__(val,  
*args, **kwargs).
x(5) = True could translate into x.__setcall__(True, 5)

Please note I'm actually arguing for this proposal. Just agreeing  
that it is not a completely nonsensical idea.

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

[Guido van Rossum]

On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> It makes just as much sense as assigning to an array access, and the
> semantics would be pretty similar.

No. Array references (x[i]) and attribute references (x.a) represent
"locations". Function calls represent values. This is no different
than the distinction between lvalues and rvalues in C.

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

Re: [Python-Dev] SyntaxError: can't assign to function call

[Phillip J. Eby]

At 09:24 AM 8/10/2006 -0700, Guido van Rossum wrote:
>On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> > It makes just as much sense as assigning to an array access, and the
> > semantics would be pretty similar.
>
>No. Array references (x[i]) and attribute references (x.a) represent
>"locations". Function calls represent values. This is no different
>than the distinction between lvalues and rvalues in C.

IIRC, in Lisp a function call can be an lvalue.  OTOH, that's probably 
because in Lisp there isn't anything besides function calls.  :)

I'm having a hard time imagining a use case in Python, though, except to 
allow things like "somedict.setdefault(key,0) += 1".  And I'm not sure 
that's an improvement, although there have certainly been times that I 
started to write that, and then grumbled and wrote "somedict[key] = 
somedict.setdefault(key,0) + 1" instead.

Honestly, it might make more sense to get rid of augmented assignment in 
Py3K rather than to add this.  It seems that the need for something like 
this springs primarily from the existence of augmented assignment.

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

[Guido van Rossum]

On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> > issue a warning (and return False) instead of raising
> > UnicodeException? That won't break much code (it's unlikely that
> > people *depend* on this exception since it's generally a symptom of
> > insane mixing of str and unicode). Then no further changes to
> > dictobject.c are necessary (except fixing that one misleading
> > comment).
>
> Good idea.

Great! Now we need someone to volunteer to write a patch (which should
include doc and NEWS updates) in time for beta 3 (Aug 18).

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

Re: [Python-Dev] SyntaxError: can't assign to function call

[James Y Knight]

On Aug 10, 2006, at 12:19 PM, James Y Knight wrote:
> Please note I'm actually arguing for this proposal. Just agreeing
> that it is not a completely nonsensical idea.

ERK! Big typo there. I meant to say:

Please note I'm NOT*** actually arguing for this proposal.

Sorry for any confusion.

James
___
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] cgi DoS attack

[Guido van Rossum]

FWIW, I've checked this in (while stuck in a meeting, Neal will know
what I mean :-).

svn r51190-r51192/

On 8/9/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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
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] SyntaxError: can't assign to function call

[Josiah Carlson]

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 09:24 AM 8/10/2006 -0700, Guido van Rossum wrote:
> >On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> > > It makes just as much sense as assigning to an array access, and the
> > > semantics would be pretty similar.
> >
> >No. Array references (x[i]) and attribute references (x.a) represent
> >"locations". Function calls represent values. This is no different
> >than the distinction between lvalues and rvalues in C.
> 
> I'm having a hard time imagining a use case in Python, though, except to 
> allow things like "somedict.setdefault(key,0) += 1".  And I'm not sure 
> that's an improvement, although there have certainly been times that I 
> started to write that, and then grumbled and wrote "somedict[key] = 
> somedict.setdefault(key,0) + 1" instead.

Thankfully default dicts in Python 2.5 (they are in, right?) should
solve this particular nit of the language.  And by using default dicts
as an instance __dict__, you get similar behavior for attributes.


> Honestly, it might make more sense to get rid of augmented assignment in 
> Py3K rather than to add this.  It seems that the need for something like 
> this springs primarily from the existence of augmented assignment.

I'm not sure that your characterization is entirely accurate.  I've
used and seen augmented assignments being used for many years now, and
this is the first time that I've seen anyone propose that it should work.


 - Josiah

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

[Travis E. Oliphant]

Guido van Rossum wrote:
> On 8/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
 It seems like Nick's recent patches solved the problems that were
 identified.
>>> Nick, can you summarize how your patches differ from my proposal?
>> nb_index and __index__ are essentially exactly as you propose.
> 
> Then I don't understand why Travis is objecting against my proposal!

I must have missed his most recent patch that changed the result to 
return a Python object.  I thought earlier versions didn't do that.

My objection is not particularly solid.  At this point it's largely a 
wish to avoid the extra overhead (there are some camps that already 
complain about NumPy having too much indexing overhead --- although they 
should be using Python lists for there purposes if indexing overhead 
really is a problem).

As it appears that several people feel this is the best way forward, 
then I'll re-work my NumPy code.   I still appreciate the change that 
allows other Python objects to be integers and eliminates the "only true 
integers allowed" flavor of several places in the Python code.

Thanks for all your hard work.

-Travis

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

[James Y Knight]

On Aug 10, 2006, at 12:24 PM, Guido van Rossum wrote:
> On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>> It makes just as much sense as assigning to an array access, and the
>> semantics would be pretty similar.
>
> No. Array references (x[i]) and attribute references (x.a) represent
> "locations". Function calls represent values. This is no different
> than the distinction between lvalues and rvalues in C.

Yes, function calls cannot be lvalues right now. However, there is no  
reason that a function call _could not_ be an lvalue. That is exactly  
what the addition of __setcall__  would allow.


On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote:
> Honestly, it might make more sense to get rid of augmented  
> assignment in Py3K rather than to add this.  It seems that the need  
> for something like this springs primarily from the existence of  
> augmented assignment.

It makes just as much (and just as little) sense to have normal  
assignment to function calls as it does augmented assignment to  
function calls. I don't see any reason to single out augmented  
assignment here.

Anyhow, enough time wasted on this. I don't really think python  
should add this feature, but it _does_ make sense, and would have  
understandable and consistent semantics if it were added.

James
___
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] Unicode Data in Python2.5 is missing a u cd_4_1_0 object

[Armin Ronacher]

Hi,

I discovered that unicodedata in python2.5 implements unicode 4.1. While
this is ok it's possible enforce unicode 3.2 by using the ucd_3_2_0 object.
But it's not possible to enforce a ucd_4_1_0 standard because that object
does not exist by now.

In the description of #1031288 (http://www.python.org/sf/1031288) Martin v.
Löwis says the following:

| Python relies on the unicodedata 3.2.0, as the IDNA RFCs
| mandate that Unicode 3.2 is used to implement IDNA. So any
| integration of 4.0.1 must
| a) still maintain access to the 3.2.0 data

And furthermore the docstring claims that this module just implements unicode
3.2.0 whereas unidata_version gives me 4.1.0

Doesn't that mean that there should also be an way to enforce unicode 4.1.0?

Regards,
Armin

___
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] Unicode Data in Python2.5 is missing a ucd_4_1_0 object

[Martin v. Löwis]

Armin Ronacher schrieb:
> I discovered that unicodedata in python2.5 implements unicode 4.1. While
> this is ok it's possible enforce unicode 3.2 by using the ucd_3_2_0 object.
> But it's not possible to enforce a ucd_4_1_0 standard because that object
> does not exist by now.

Not sure what you mean by "enforce". Isn't

assert unicodedata.unidata_version == '4.1.0'

enough enforcement?

> And furthermore the docstring claims that this module just implements unicode
> 3.2.0 whereas unidata_version gives me 4.1.0

That's a bug; thanks for pointing it out. I just fixed it in r51194.

> Doesn't that mean that there should also be an way to enforce unicode 4.1.0?

You mean, that there should be a ucd_4_1_0 object? No, why do you think
there should be one? We don't plan to provide a copy of the UCD for each
UCD version that was ever released (e.g. we skipped some between 3.2 and
4.1 also).

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] SimpleXMLWriter missing from elementtree

[Martin v. Löwis]

Ralf Schmitt schrieb:
> any chance to get SimpleXMLWriter (and other modules maybe??) getting 
> included into xml.etree? 

Not in Python 2.5, 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] Dict suppressing exceptions

[Martin v. Löwis]

Guido van Rossum schrieb:
> Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> issue a warning (and return False) instead of raising
> UnicodeException? 

I'm in favour of having this __eq__ just return False. I don't think
the warning is necessary, and believe that people will complain about
getting it, but if that is the only way to achieve consensus,
so be it.

> A warning would arguably have the same helping effect. (I suspect
> actually that we would have used warnings all along except we didn't
> have the warning framework when unicode was first introduced.)

I believe we would have neither had we rich comparisons available
at the time. That unicode-vs-str-__eq__ raises an exception is just
a fall-out of not supporting __cmp__ (and it is good that __cmp__
is not supported - there is no meaningful way to order str/unicode
if the string is not in the system encoding).

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] returning longs from __hash__()

[Martin v. Löwis]

Armin Rigo schrieb:
> 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.

I see you've fixed it - thanks.

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

[Guido van Rossum]

On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 10, 2006, at 12:24 PM, Guido van Rossum wrote:
> > On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> >> It makes just as much sense as assigning to an array access, and the
> >> semantics would be pretty similar.
> >
> > No. Array references (x[i]) and attribute references (x.a) represent
> > "locations". Function calls represent values. This is no different
> > than the distinction between lvalues and rvalues in C.
>
> Yes, function calls cannot be lvalues right now. However, there is no
> reason that a function call _could not_ be an lvalue. That is exactly
> what the addition of __setcall__  would allow.

I have to admit that I don't find it particularly useful -- I still
don't think I like the idea much of using function calls as assignment
targets.

You wrote

  x(5) = True

would mean

  x.__setcall__(True, 5)

What would x(5) += 1 mean? The best I can come up with is

  __tmp = x(5)   # or x.__call__(5)
  if hasattr(__tmp, "__iadd__"):
__val = __tmp.__iadd__(1)
  else:
__val = __tmp + 1
  if __val is NotImplemented:
raise TypeError(...)
  __tmp.__setcall__(__val, 5)

since this is essentially how x[5] += 1 works (except that the
hasattr() check is hidden inside PyNumber_InPlaceAdd and optimized
away to class definition time).

I expect that most people interested in having f() += 1 to work would
have to implement a dummy __setcall__() because their __iadd__ returns
self and there's no additional work to be done for the assignment.

I'm not convinced that all this complexity is worth it. For lists, +=
is syntactic sugar for .extend(). I expect that most use cases you can
come up with can similarly be argued away.

> On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote:
> > Honestly, it might make more sense to get rid of augmented
> > assignment in Py3K rather than to add this.  It seems that the need
> > for something like this springs primarily from the existence of
> > augmented assignment.

I assume this was meant tongue-in-cheek. I see no reason to get rid of
+=. The opportunity for hypergeneralization (== ill-advised
generalization based on the misunderstanding of some mechanism) does
not automatically mean a mechanism should not be added (although it
can sometimes be a warning sign).

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

Re: [Python-Dev] Unicode Data in Python2.5 is missing a u cd_4_1_0 object

[Armin Ronacher]

Hi,

Martin v. Löwis  v.loewis.de> writes:
> > Doesn't that mean that there should also be an way to enforce unicode 4.1.0?
> 
> You mean, that there should be a ucd_4_1_0 object? No, why do you think
> there should be one? We don't plan to provide a copy of the UCD for each
> UCD version that was ever released (e.g. we skipped some between 3.2 and
> 4.1 also).

Right, I didn't know that. From that old bug report it sounded like a programmer
should be able to select a specific UCD version.

Regards,
Armin

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

[Michael Chermside]

Michael Urman writes:
> I strongly believe that unicode vs str here is the symptom and not the
> actual problem. The comparison between two non-us-ascii str/unicode
> instances is but one of many ways to raise an exception during
> comparison.
   [... example ...]
> Yes this is made up code. But I'm not arguing for a feature; I'm
> arguing for backwards compatibility. Because we do not know where
> these legitimate uses are, we cannot evaluate their likelihood to
> exist nor the level of breakage they will cause. If we make this a
> warning for any exception, we can satisfy both imagined camps. Those
> in Armin's position can make that warning raise an exception while
> debugging, and those using it on purpose can squash it.

See also my example from the beginning of this thread
(http://mail.python.org/pipermail/python-dev/2006-August/067978.html).
The example wasn't from real code, but it WAS quite plausible --
straightforward use of a popular Python Cookbook recipe.

But we seem to have reached a rough consensus:

Later, Guido writes:
> How about we change unicode-vs-str __eq__ to
> issue a warning (and return False) instead of raising
> UnicodeException?
  [... Marc-Andre Lemburg agrees ...]
> Great! Now we need someone to volunteer to write a patch (which should
> include doc and NEWS updates) in time for beta 3 (Aug 18).

I don't *strongly* object to this consensus, but if you haven't
glanced at my original example, take a look - it might convince you.
The proposed solution will not help with my example. I'm not sure the
motivation for breaking code like that example -- the bug-hunting
motivation is satisfied by issuing a warning as Michael Urman proposes,
then use an exception after one more release when people have had time
to fix their code.

-- Michael Chermside

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

[Phillip J. Eby]

At 12:28 PM 8/10/2006 -0700, Guido van Rossum wrote:
>>On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote:
>> > Honestly, it might make more sense to get rid of augmented
>> > assignment in Py3K rather than to add this.  It seems that the need
>> > for something like this springs primarily from the existence of
>> > augmented assignment.
>
>I assume this was meant tongue-in-cheek.

Not entirely, no.


>  I see no reason to get rid of
>+=. The opportunity for hypergeneralization (== ill-advised
>generalization based on the misunderstanding of some mechanism) does
>not automatically mean a mechanism should not be added (although it
>can sometimes be a warning sign).

I think it's a warning sign because I *know* what augmented assignment's 
semantics are supposed to be and I *still* try to use it with setdefault() 
sometimes -- but only when I'm doing an augmented assignment.  I never 
mistakenly try to assign to a function call in any other circumstance.

However, I'm also not clear that trying to assign to a function call *is* 
ill-advised.  One of the things that attracted me to Python in the first 
place is that it had a lot of features that would be considered 
"hypergeneralization" in other languages, e.g. the ability to create your 
own sequences, mappings, and callable objects in the first place.

That being said, the benefit of hypergeneralizing assignment seems small 
compared to its price.  So eliminating augmented assignment seems a more 
attractive way to get rid of the nuisance of the perennially repeated 
proposals to "fix" or otherwise extend it.  Sometimes it seems like half 
the time I want to use augmented assignment, I can't use it anyway for one 
reason or another, so it doesn't seem like that big of a loss.

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

[Armin Rigo]

Hi,

On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> I'm in favour of having this __eq__ just return False. I don't think
> the warning is necessary, (...)

+1


Armin
___
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] DRAFT: python-dev summary for 2006-07-16 to 2006-07-31

[Steven Bethard]

Here's the summary for the second half of July. Thanks in advance for
your comments and corrections!


=
Announcements
=

---
Python 2.5 schedule
---

After inserting a third beta release to allow some more time for
testing the new features, Python continues to make progress towards
the final Python 2.5 release. See `PEP 356`_ for more details and the
full schedule.

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

Contributing threads:

- `outstanding bugs to fix for 2.5
`__
- `Py2.5 release schedule
`__

---
How to submit a patch to Python
---

Just a few reminders for all those still new to python-dev. When
submitting a new patch to SourceForge, don't assign it to anyone. Most
python developers get email notifications for new patches and will
assign it to themselves if appropriate. If you feel like the approach
the patch takes might need discussion, it's alright to present it to
python-dev and ask for some feedback. If you do, be sure to put the
patch number and url (e.g. http://bugs.python.org/)
near the top of the message, so that developers can easily find it.

And if you don't want to wait for your patch to be looked at (which
may take some time as all developers are volunteers), a few of the
folks here, including Martin v. Löwis, have offered a five-for-one
deal. Simply find five other patches, and check them for things like:

* Does the code look okay?
* Does Python build with it applied?
* Do all unit tests pass?
* Does the patch have tests?
* Does the patch have documentation?

Then post your notes to the five patch trackers and post a final
message to python-dev indicating the patches you reviewed and the
patch which you'd like to have someone look at for you.

Contributing threads:

- `new guy 
`__
- `first draft of bug guidelines for www.python.org/dev/
`__
- `Patch submitted, now what?
`__


Demos of trackers to replace SourceForge


There are currently three potential trackers that have successfully
imported the SourceForge data with demos online: roundup_, jira_ and
launchpad_. Try 'em out, and send your discussions and comments to
[EMAIL PROTECTED] and put your reports and reviews `on the
wiki`_.

.. _roundup: http://efod.se/python-tracker/
.. _jira: http://jira.python.atlassian.com/secure/Dashboard.jspa
.. _launchpad: https://demo.launchpad.net/products/python/+bugs
.. _on the wiki: http://wiki.python.org/moin/CallForTrackers

Contributing thread:

- `More tracker demos online
`__


=
Summaries
=

--
Restricted execution in Python
--

Brett Cannon decided this fortnight to go for an all-out capabilities
based restricted execution design, and posted a `new design
document`_. As part of this work, Brett planned to rewrite most of the
import machinery in pure Python code, hopefully cleaning up some of
the idiosyncrasies of the current import.c mechanisms, and allowing
him to do things like restrict imports to only .py files, not .pyc
files. Armin Rigo pointed out that a good place to start would be the
`PyPy import implementation`_.

On the restricted execution front, one of the things that is now
likely to happen in Brett's sandboxing branch is that
``object.__subclasses__()`` and dangerous constructors like the one
for the code object will be completely removed from the Python level.
This means a few backwards incompatible changes, but Brett suggested
that they should only break pretty advanced and esoteric Python code.
Since it's for his Ph.D. dissertation, he didn't want to tie his hands
by requiring full backwards compatibility, and he was fine with
waiting to merge his branch until Python 3000.

.. _new design document:
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt
.. _PyPy import implementation:
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.py

Contributing threads:

- `Capabilities / Restricted Execution
`__
- `new security doc using object-capabilities
`__

--
Character case and locales
--

Mihai Ibanescu asked about a `bug in the logging module`_ due to the
fact that ``'INFO'.lower() != 'info'`` in some locales. Marc-Andre
Lemburg and Martin v. Löwis explained that since in Unicode, ne

Re: [Python-Dev] Dict suppressing exceptions

[Guido van Rossum]

On 8/10/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> See also my example from the beginning of this thread
> (http://mail.python.org/pipermail/python-dev/2006-August/067978.html).
> The example wasn't from real code, but it WAS quite plausible --
> straightforward use of a popular Python Cookbook recipe.
[...]
> I don't *strongly* object to this consensus, but if you haven't
> glanced at my original example, take a look - it might convince you.

Alas, I have no idea what it does. Can you come up with an example
that doesn't require enums and localization?


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

Re: [Python-Dev] Dict suppressing exceptions

[M.-A. Lemburg]

Michael Chermside wrote:
>> How about we change unicode-vs-str __eq__ to
>> issue a warning (and return False) instead of raising
>> UnicodeException?
>   [... Marc-Andre Lemburg agrees ...]
>> Great! Now we need someone to volunteer to write a patch (which should
>> include doc and NEWS updates) in time for beta 3 (Aug 18).
> 
> I don't *strongly* object to this consensus, but if you haven't
> glanced at my original example, take a look - it might convince you.
> The proposed solution will not help with my example. I'm not sure the
> motivation for breaking code like that example -- the bug-hunting
> motivation is satisfied by issuing a warning as Michael Urman proposes,
> then use an exception after one more release when people have had time
> to fix their code.

The warning framework gives programmers great flexibility in handling
these situation:

* they can silence the warning, just report it once, always report it
* they can have the warning raise an exception
* they can log the warning in some way

It's very flexible to accommodate for all kinds of ways to handle
the situation.

By introducing a new category of warning for these Unicode-related
warnings, adding specific warning filters will be easy.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 10 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Dict suppressing exceptions

[M.-A. Lemburg]

Guido van Rossum wrote:
> On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
>>> issue a warning (and return False) instead of raising
>>> UnicodeException? That won't break much code (it's unlikely that
>>> people *depend* on this exception since it's generally a symptom of
>>> insane mixing of str and unicode). Then no further changes to
>>> dictobject.c are necessary (except fixing that one misleading
>>> comment).
>> Good idea.
> 
> Great! Now we need someone to volunteer to write a patch (which should
> include doc and NEWS updates) in time for beta 3 (Aug 18).

I'll give it a go.

Not sure what kinds of docs we'll need for this,
though (and more importantly: where to put them, e.g. into the tutorial
in the dictionary section, somewhere into the Unicode section ?)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 10 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Dict suppressing exceptions

[Guido van Rossum]

On 8/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> > issue a warning (and return False) instead of raising
> > UnicodeException?
>
> I'm in favour of having this __eq__ just return False. I don't think
> the warning is necessary, and believe that people will complain about
> getting it, but if that is the only way to achieve consensus,
> so be it.

Not sure I agree. I think that users would find it disturbing (and it
could hide bugs) if u"\xff" == "\xff" returned False without warning
while u"\x7f" == "\x7f" returns True.

> > A warning would arguably have the same helping effect. (I suspect
> > actually that we would have used warnings all along except we didn't
> > have the warning framework when unicode was first introduced.)
>
> I believe we would have neither had we rich comparisons available
> at the time. That unicode-vs-str-__eq__ raises an exception is just
> a fall-out of not supporting __cmp__ (and it is good that __cmp__
> is not supported - there is no meaningful way to order str/unicode
> if the string is not in the system encoding).

Maybe. I agree that 3-way compare has no business guessing the
ordering of u"\xff" and "\xff". I'm not so sure that if we'd had rich
comparison we'd have chosen __eq__ to return False for these.

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

Re: [Python-Dev] Dict suppressing exceptions

[Guido van Rossum]

On 8/10/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > I'm in favour of having this __eq__ just return False. I don't think
> > the warning is necessary, (...)
>
> +1

Can you explain why you believe that no warning is necessary?

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

Re: [Python-Dev] SyntaxError: can't assign to function call

[Guido van Rossum]

On 8/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> That being said, the benefit of hypergeneralizing assignment seems small
> compared to its price.  So eliminating augmented assignment seems a more
> attractive way to get rid of the nuisance of the perennially repeated
> proposals to "fix" or otherwise extend it.  Sometimes it seems like half
> the time I want to use augmented assignment, I can't use it anyway for one
> reason or another, so it doesn't seem like that big of a loss.

I think you are strongly understimating the benefits of augmented
assignments. I held out against it for many years. But the users
didn't stop asking for it. They're mostly happy. That some aren't
happy until we've hypergeneralized it doesn't mean we shouldn't have
done it in the first place. (Similar as with lambda. :)

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

Re: [Python-Dev] __index__ clipping

[Guido van Rossum]

Thanks for your understanding.

Anyway, Nick's patch differs in at least one significant way from my
proposal -- (10**10).__index__() returns sys.maxint in his patch,
while I want it to return 100L. So this is still an open
issue.

--Guido

On 8/10/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
>  It seems like Nick's recent patches solved the problems that were
>  identified.
> >>> Nick, can you summarize how your patches differ from my proposal?
> >> nb_index and __index__ are essentially exactly as you propose.
> >
> > Then I don't understand why Travis is objecting against my proposal!
>
> I must have missed his most recent patch that changed the result to
> return a Python object.  I thought earlier versions didn't do that.
>
> My objection is not particularly solid.  At this point it's largely a
> wish to avoid the extra overhead (there are some camps that already
> complain about NumPy having too much indexing overhead --- although they
> should be using Python lists for there purposes if indexing overhead
> really is a problem).
>
> As it appears that several people feel this is the best way forward,
> then I'll re-work my NumPy code.   I still appreciate the change that
> allows other Python objects to be integers and eliminates the "only true
> integers allowed" flavor of several places in the Python code.
>
> Thanks for all your hard work.
>
> -Travis
>
> ___
> 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/guido%40python.org
>


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

Re: [Python-Dev] Dict suppressing exceptions

[Ron Adam]

M.-A. Lemburg wrote:
> Michael Chermside wrote:
>>> How about we change unicode-vs-str __eq__ to
>>> issue a warning (and return False) instead of raising
>>> UnicodeException?
>>   [... Marc-Andre Lemburg agrees ...]
>>> Great! Now we need someone to volunteer to write a patch (which should
>>> include doc and NEWS updates) in time for beta 3 (Aug 18).
>> I don't *strongly* object to this consensus, but if you haven't
>> glanced at my original example, take a look - it might convince you.
>> The proposed solution will not help with my example. I'm not sure the
>> motivation for breaking code like that example -- the bug-hunting
>> motivation is satisfied by issuing a warning as Michael Urman proposes,
>> then use an exception after one more release when people have had time
>> to fix their code.
> 
> The warning framework gives programmers great flexibility in handling
> these situation:
> 
> * they can silence the warning, just report it once, always report it
> * they can have the warning raise an exception
> * they can log the warning in some way
> 
> It's very flexible to accommodate for all kinds of ways to handle
> the situation.
> 
> By introducing a new category of warning for these Unicode-related
> warnings, adding specific warning filters will be easy.

This sounds like the correct tool to me. +1

Would it be possible to generate warnings when either Unicode or stings 
are coerced to the other implicitly but not explicitly?

That may also generate a warning in the case of the dictionary problem 
being discussed, (I think), and may be more useful for checking for 
non-intentionally mixed Unicode and strings.

Ron


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

[Greg Ewing]

Martin v. Löwis wrote:

> Perform it: do the steps that the algorithm says you should
> do, or let a machine do it. IOW, run the code.

That can't be right, because it would mean that
anyone who runs a program that contains a
patented algorithm, even one bought or otherwise
obtained from someone else, would need to
individually negotiate a licence with the
patent owner. That clearly doesn't happen.

> If your point is that software patents are evil: I fully
> agree.

My point is that software patents don't even
seem to make *sense* -- especially in conjunction
with open source software.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Is module clearing still necessary? [Re: Is this a bug?]

[Greg Ewing]

Nick Coghlan wrote:

> Early versions of the PEP 338 implementation also ran into the problem of a 
> module's globals getting cleared when the module itself goes away

A while back it was suggested that the module-clearing
thing might be dropped now that we have cyclic GC, but
I don't remember there being much discussion about it.
Has anyone had any thoughts on that?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SyntaxError: can't assign to function call

[Greg Ewing]

Michael Urman wrote:

> Just to play devil's advocate here, why not to a function call via a
> new __setcall__?

You still haven't answered the question of what this
buys you over just giving your object a suitably
named method that does whatever your __setcall__
method would have done.

Can you show a realistic use case for this, that
demonstrates a clear advantage to having new
syntax?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Split augmented assignment into two operator sets? [Re: SyntaxError: can't assign to function call]

[Greg Ewing]

Phillip J. Eby wrote:

> I think it's a warning sign because I *know* what augmented assignment's 
> semantics are supposed to be and I *still* try to use it with setdefault() 
> sometimes -- but only when I'm doing an augmented assignment.  I never 
> mistakenly try to assign to a function call in any other circumstance.

I think this problem arises because of the dual semantics
of augmented assignment. One tends to have two *different*
mental models of what it does, depending on whether the
object in question is immutable:

   (1) For immutable objects:

  x += y  <-->  x = x + y

   (2) For mutable objects:

  x += y  <-->  x.__iadd__(y)

and it's easy to forget that case (2) also happens
to have the side effect of assigning the result
back to x, which is usually redundant in the case
of an immutable object, and thus to slip into the
error of thinking that

  x(z) += y  <--->  x(z).__iadd__(y)

should be a reasonable thing to expect. And in
the case of a mutable result from x(z), it's
hard to argue convincingly that it's not
reasonable.

As to what this is a warning of, maybe it's that
the dual semantics were a mistake in the first
place, and that there really should have been
two sets of operators, e.g.

   x += y  <--->   x = x + y  # literally

   x +: y  <--->   x.__iadd__(y)  # with *no* assignment

The +: family of operators would then just be
normal infix operators, not assignments at all,
and one would be able to say

   x(z) +: y

without any trouble (provided the result of x(z)
were mutable, since immutables would not have
an __iadd__ method at all).

Another benefit to this is that the +: operators
would be usable on objects in an outer scope,
since they are not assignments and would therefore
not imply the localness of anything.

Something to consider for Py3k?

PS: Why an extra set of operators, rather than
ordinary methods? One of the motivations for the
augmented assignment operators was Numeric and the
desire to be able to express in-place operations
on arrays concisely. The +: family would fill this
need.

PPS: Yes, I know the use of : might be ill-advised.
It's just an example - any other concise notation
would do as well.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiem! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] Split augmented assignment into two operator sets? [Re: SyntaxError: can't assign to function call]

[Guido van Rossum]

-1. I just don't think we should add more operators -- it'll just
cause more question marks on users' faces...

--Guido

On 8/10/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > I think it's a warning sign because I *know* what augmented assignment's
> > semantics are supposed to be and I *still* try to use it with setdefault()
> > sometimes -- but only when I'm doing an augmented assignment.  I never
> > mistakenly try to assign to a function call in any other circumstance.
>
> I think this problem arises because of the dual semantics
> of augmented assignment. One tends to have two *different*
> mental models of what it does, depending on whether the
> object in question is immutable:
>
>(1) For immutable objects:
>
>   x += y  <-->  x = x + y
>
>(2) For mutable objects:
>
>   x += y  <-->  x.__iadd__(y)
>
> and it's easy to forget that case (2) also happens
> to have the side effect of assigning the result
> back to x, which is usually redundant in the case
> of an immutable object, and thus to slip into the
> error of thinking that
>
>   x(z) += y  <--->  x(z).__iadd__(y)
>
> should be a reasonable thing to expect. And in
> the case of a mutable result from x(z), it's
> hard to argue convincingly that it's not
> reasonable.
>
> As to what this is a warning of, maybe it's that
> the dual semantics were a mistake in the first
> place, and that there really should have been
> two sets of operators, e.g.
>
>x += y  <--->   x = x + y  # literally
>
>x +: y  <--->   x.__iadd__(y)  # with *no* assignment
>
> The +: family of operators would then just be
> normal infix operators, not assignments at all,
> and one would be able to say
>
>x(z) +: y
>
> without any trouble (provided the result of x(z)
> were mutable, since immutables would not have
> an __iadd__ method at all).
>
> Another benefit to this is that the +: operators
> would be usable on objects in an outer scope,
> since they are not assignments and would therefore
> not imply the localness of anything.
>
> Something to consider for Py3k?
>
> PS: Why an extra set of operators, rather than
> ordinary methods? One of the motivations for the
> augmented assignment operators was Numeric and the
> desire to be able to express in-place operations
> on arrays concisely. The +: family would fill this
> need.
>
> PPS: Yes, I know the use of : might be ill-advised.
> It's just an example - any other concise notation
> would do as well.
>
> --
> Greg Ewing, Computer Science Dept, +--+
> University of Canterbury,  | Carpe post meridiem! |
> Christchurch, New Zealand  | (I'm not a morning person.)  |
> [EMAIL PROTECTED]+--+
>


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

Re: [Python-Dev] __index__ clipping

[Travis E. Oliphant]

Guido van Rossum wrote:
> Thanks for your understanding.
> 
> Anyway, Nick's patch differs in at least one significant way from my
> proposal -- (10**10).__index__() returns sys.maxint in his patch,
> while I want it to return 100L. So this is still an open
> issue.
>

I've reviewed Nick's patch and finally see the light for the need of 
nb_index to return a Python object.  It also nicely parallels nb_int and 
nb_long so the same code can often be used (when it's appropriate for 
the object to be an integer).

I understand the general rationale for the C-API, but I share 
reservations about using output arguments to convey error information. 
This seems quite a bit different from what Python normally does.

I am going to beef up PEP-357 to address the main problem of nb_index 
returning a Py_ssize_t and then look at the C-API question more closely.

I'm also going out of town next week (and have a bunch to prepare for 
it) so I'll only have a few hours to look at it.

-Travis


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

[Travis Oliphant]

Guido van Rossum wrote:
>
> What do you think (10**10).__index__() should return (when called from 
> Python)?
>
I'm with Guido on this point.  I think (10**10).__index__() should 
return the full long integer when called from within Python.

-Travis


___
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] Split augmented assignment into two operator sets? [Re: SyntaxError: can't assign to function call]

[Aahz]

On Fri, Aug 11, 2006, Greg Ewing wrote:
> Phillip J. Eby wrote:
>> 
>> I think it's a warning sign because I *know* what augmented
>> assignment's semantics are supposed to be and I *still* try to use it
>> with setdefault() sometimes -- but only when I'm doing an augmented
>> assignment.  I never mistakenly try to assign to a function call in
>> any other circumstance.
>
> I think this problem arises because of the dual semantics of augmented
> assignment. One tends to have two *different* mental models of what it
> does, depending on whether the object in question is immutable:
>
>(1) For immutable objects:
> 
>   x += y  <-->  x = x + y
> 
>(2) For mutable objects:
> 
>   x += y  <-->  x.__iadd__(y)

What I try to do is always remember that

x += y  <-->  x = x.__iadd__(y)

which mostly solves the problem.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan
___
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] SyntaxError: can't assign to function call

[James Y Knight]

On Aug 10, 2006, at 4:57 PM, Phillip J. Eby wrote:

> However, I'm also not clear that trying to assign to a function  
> call *is* ill-advised.  One of the things that attracted me to  
> Python in the first place is that it had a lot of features that  
> would be considered "hypergeneralization" in other languages, e.g.  
> the ability to create your own sequences, mappings, and callable  
> objects in the first place.
>
> That being said, the benefit of hypergeneralizing assignment seems  
> small compared to its price.

Well, it's a mostly obvious extension of an existing idea, so the  
price doesn't seem all that high. The main problem is that so far,  
there have been 0 convincing use cases. So no matter how moderate the  
price, it's definitely bigger than the benefit. But anyhow, speaking  
of hypergeneralization...since this has 0 use cases anyhow, might as  
well hyperhypergeneralize it...

Well, why should assignment be limited to only local variables, item  
access, and function calls. Why shouldn't you be able to potentially  
assign to _any_ expression!

Since
x + a turns into (very roughly...) x.__add__(a),

then,
x + a = 5 could turn into x.__add__.__setcall__(5, a).

Of course, since normal __add__ functions don't have a __setcall__,  
doing this will raise an error. But, a user defined __add__ could  
have one! And what would such a user defined __add__.__setcall__  
actually *do*? Well, that would be a use case, and I sure don't have  
any of those!

Ta Da. Who's going to make the patch? ;)

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

[Guido van Rossum]

On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 10, 2006, at 4:57 PM, Phillip J. Eby wrote:
> > That being said, the benefit of hypergeneralizing assignment seems
> > small compared to its price.
>
> Well, it's a mostly obvious extension of an existing idea, so the
> price doesn't seem all that high.

If you still think that, you don't realize the problem with hypergeneralization.

The extension is *not* obvious, and there are several problems (as I
pointed out before).

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

Re: [Python-Dev] __index__ clipping

[Guido van Rossum]

(adding back python-dev in the CC: list)

Right. I guess I didn't recompile after patching. Silly me (as Orlijn
would say :-).

Neal+Anthony, do you need me to review Nick's patch? If I don't have
to I'd rather pay more attention to py3k, which I've sadly neglected
in the past month (apart from giving a talk about it on at least 4
different occasions :-).

--Guido

On 8/10/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Thanks for your understanding.
> >
> > Anyway, Nick's patch differs in at least one significant way from my
> > proposal -- (10**10).__index__() returns sys.maxint in his patch,
> > while I want it to return 100L. So this is still an open
> > issue.
>
> Just to clarify.  I installed Nick's recent patch and it seems that
> (10**10).__index__() actually returns what Guido wants so I think we are
> all on the same page.
>
> Python 2.5b3 (trunk:51199M, Aug 10 2006, 21:59:31)
> [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> (10**10).__index__()
> 100L
>
>
> -Travis
>
>


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