Neal Norwitz [EMAIL PROTECTED] wrote:
On 8/9/06, Josiah Carlson [EMAIL PROTECTED] wrote:
2.4 performed these imports silently, while 2.5 complains SystemError:
Parent module 'x' not loaded, which is actually a useful message, and
helped me fix it.
Can you make a small, self-contained
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
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
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
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
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 (and
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
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
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
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
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__?
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,
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
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.
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
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.
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 references (x[i]) and
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
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.
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
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
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
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 references
Hi,
Martin v. Löwis martin at 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
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
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
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
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,
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
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
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
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
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?
--
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
include doc and
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
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
-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
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 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
(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
46 matches
Mail list logo
