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 t
"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 soon
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
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
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
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
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
_
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
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
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 justif
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 y
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 p
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 t
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 war
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__
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 uni
"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
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 dev
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
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
>"locat
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 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.
Ja
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
"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 reference
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 essent
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
> "loc
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.pyth
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 me
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/p
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
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
___
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
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
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. Bu
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
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.pyth
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, P
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 Cook
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 update
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 unlike
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
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 nece
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
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]>
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
>>
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 el
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 the
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 sh
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
-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 suppose
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
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
__
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
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"
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 se
(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 giv
56 matches
Mail list logo
