On Jan 13, 2005, at 12:46 PM, Clark C. Evans wrote:
My current suggestion to make 'transitive adaption' easy for a
application builder (one putting togeher components) has a few
small parts:
- If an adaptation is not found, raise an error, but list in
the error message two additional things:
On Jan 27, 2005, at 1:20 AM, Martin v. Löwis wrote:
I agree. Because of the BDFL pronouncement, I cannot reject the patch,
but I won't accept it, either. So it seems that this patch will have
to sit in the SF tracker until either Guido processes it, or it is
withdrawn.
If people want to restart
On Feb 14, 2005, at 10:41 AM, Tim Peters wrote:
Wouldn't it be more elegant to make builtin_id() return an unsigned
long integer?
I think so. This is the function ZODB 3.3 uses, BTW:
def positive_id(obj):
Return id(obj) as a non-negative integer.
[...]
I think it'd be nice to change it, too.
On Mar 9, 2005, at 4:19 PM, Thomas Heller wrote:
If this were the only use case, you are right. I cannot remember the
use case I once had right now, and probably the code has been rewritten
anyway. But I assume use cases exist, otherwise there weren't so many
recipes for the ordered dictionary.
On Mar 11, 2005, at 2:02 PM, Steven Bethard wrote:
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli [EMAIL PROTECTED]
wrote:
Which reminds me -- could we have a methodcaller relative to
attrgetter
and itemgetter? Sort a list of strings in a case-insensitive way
would become *SO* easy with
On Mar 18, 2005, at 8:19 PM, Greg Ward wrote:
Is having to use fcntl and os really so awful? At least it requires
the programmer to prove he knows what he's doing putting this file
into non-blocking mode, and that he really wants to do it. ;-)
I'd tend to agree. :) Moreover, I don't think
On Apr 9, 2005, at 2:13 PM, Michael Hudson wrote:
The funniest I know is part of PyPy:
def extract_cell_content(c):
Get the value contained in a CPython 'cell', as read through
the func_closure of a function object.
# yuk! this is all I could come up with that works in Python 2.2
too
On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
think. There were some numbers posted to the twisted
On Apr 20, 2005, at 5:43 AM, Paul Moore wrote:
and the substitution of
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
The question of whether assignments within CODE are executed within a
new namespace, as this implies, or in the surrounding namespace,
remains
On May 6, 2005, at 2:49 PM, Nicholas Bastin wrote:
If this is the case, then we're clearly misleading users. If the
configure script says UCS-2, then as a user I would assume that
surrogate pairs would *not* be encoded, because I chose UCS-2, and it
doesn't support that. I would assume that
On May 10, 2005, at 2:48 PM, Nicholas Bastin wrote:
On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote:
Wow, what an inane way of looking at it. I don't know what world
you
live in, but in my world, users read the configure options and
suppose
that they mean something. In fact, they
On May 12, 2005, at 6:32 PM, Ka-Ping Yee wrote:
Suppose exceptions have an optional context attribute, which is
set when the exception is raised in the context of handling another
exception. Thus:
def a():
try:
raise AError
except:
raise
On May 14, 2005, at 2:34 PM, Aahz wrote:
On Fri, May 13, 2005, Greg Ewing wrote:
Sounds reasonable, but it should be equally easy to handle::
raise MyError, message
Make that:
raise MyError(message)
There's really no reason for a multi-argument raise when exceptions
are objects
On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
- When a generator is GC'ed, its close() method is called (which
is a
no-op if it is already closed).
Does this mean that all generators will be ineligible
for cyclic
On May 20, 2005, at 4:31 AM, Ka-Ping Yee wrote:
Guido van Rossum wrote:
Do we really need both __context__ and __cause__?
Well, it depends whose needs we're trying to meet.
If we want to satisfy those who have been asking for chaining
of unexpected secondary exceptions, then we have to
On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
This only helps if you can get to a debugger. What if you're
reading your web server's error log?
Then you're in trouble anyways because you need the contents of some
local to figure out what's going on, also.
James
On Jun 16, 2005, at 10:50 AM, Steven Bethard wrote:
On 6/15/05, Benji York [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
I think having basic context managers in a stdlib module that we know
for a fact that will be handy is a good idea. We should keep the list
short and poignant, but we should have something for people to work
off of. The ones I like below for a
On Jul 28, 2005, at 4:20 PM, Guido van Rossum wrote:
Managing users is especially important -- if a
user is compromised (as has happened in the past for python.org users)
the whole repository is compromised. Now this could happen to SF users
too, but I'm not sure that we know all the tricks
On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
I'd recommend not subclassing SystemExit--there are too many programs
out there which expect the argument (e.g. sys.exit(3)) to mean
something
specific, but that expectation doesn't apply at all to SystemError.
Yes please make note of this
On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
I wouldn't mind using Exception/Error instead of Raisable/Exception
- and it
seriously reduces the pain of making this transition. Indeed, most
of it
becomes doable within the 2.x series - the only tricky parts are
semantic
changes
On Aug 2, 2005, at 12:31 AM, Phillip J. Eby wrote:
If you think that a KeyboardInterrupt is an error, then it's an
indication
that Python's documentation and the current exception class
hierarchy has
failed to educate you sufficiently, and that we *really* need to add a
class like
On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
[...brain hums...]
OK, I'm changing my mind again about the names again.
Exception as the root and StandardError can stay; the only new
proposal would then be to make bare 'except:' call StandardError.
I don't see how that can work. Any
On Aug 4, 2005, at 7:03 AM, Nick Coghlan wrote:
Additionally, consider that a hypothetical ThreadExit exception
(used to
terminate a thread semi-gracefully) would also clearly belong under
ControlFlowException. That is, just because something is
asynchronous with
respect to the currently
+-- NamespaceError (rename of NameError)
+-- UnboundFreeError (new)
+-- UnboundGlobalError (new)
+-- UnboundLocalError
What are these new exceptions for? Under what circumstances are they
raised? Why is this necessary or an improvement?
Renamed
On Aug 5, 2005, at 2:46 PM, Raymond Hettinger wrote:
The PEP moves StopIteration out from under Exception so that it cannot
be caught by a bare except or an explicit except Exception.
IMO, this is a mistake. In either form, a programmer is stating that
they want to catch and handle just
On Aug 9, 2005, at 7:15 PM, Raymond Hettinger wrote:
The data gathered by Jack and Steven's research indicate that the
number
of cases where TerminatingException would be useful is ZERO. Try
not to
introduce a new builtin that no one will ever use. Try not to add
a new
word whose
On Aug 10, 2005, at 7:45 PM, Raymond Hettinger wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it under. Maybe in the platform module instead?
On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
Remember, the Exception reorganization is for Python 3.0/3k/whatever,
not for 2.5 .
Huh, I could *swear* we were talking about fixing things for
2.5...but I see at least the current version of the PEP says it's
talking about 3.0. If that's
On Aug 15, 2005, at 5:04 PM, Bryan O'Sullivan wrote:
The centralised SCM tools all create a wall between core developers
(i.e. people with commit access to the central repository) and people
who are on the fringes. Outsiders may be able to get anonymous
read-only access, but they are left up
On Aug 16, 2005, at 2:52 AM, Martin v. Löwis wrote:
Tim Peters wrote:
It would be best if svn:eol-style were set to native during initial
conversion from CVS, on all files not marked binary in CVS.
Ok, I'll add that to the PEP. Not sure how to implement it, yet...
cvs2svn does that by
On Aug 17, 2005, at 2:55 PM, Timothy Fitz wrote:
On 8/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
-0 The behavior of dir() already a bit magical. Python is much
simpler
to comprehend if we have direct relationships like dir() and vars()
corresponding as closely as possible to the
On Aug 22, 2005, at 11:32 AM, Barry Warsaw wrote:
They are the same machine, with different IP addresses. Anonymous
webdav will require two Apache processes, since different user/groups
are needed and to support different certs for svn.python.org and
(eventually) www.python.org.
It seems a
On Aug 23, 2005, at 10:41 PM, Raymond Hettinger wrote:
[Guido van Rossum]
If we syntactically enforce that the bare except, if present, must be
last, would that remove your objection? I agree that a bare except in
the middle is an anomaly, but that doesn't mean we can't keep bare
except:
On Aug 24, 2005, at 11:10 AM, Guido van Rossum wrote:
On 8/24/05, Michael Chermside [EMAIL PROTECTED] wrote:
Explicit is better than Implicit. I think that in newly written code
except Exception: is better (more explicit and easier to
understand)
than except: Legacy code that uses
On Aug 31, 2005, at 5:00 PM, Robert Kern wrote:
IMO, if we are going to restrict Python 3000 enough to protect that
common subset, then there's not enough payoff to justify breaking
*any* backwards compatibility. If my current codebase[1] isn't
going to
be supported in Python 3000, I'm
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second builtin just to apply the
% operator for you. I've always really liked that Python doesn't have
separate
On Sep 4, 2005, at 12:51 PM, Barry Warsaw wrote:
On Sat, 2005-09-03 at 12:51, James Y Knight wrote:
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second
On Sep 10, 2005, at 6:07 PM, Lisandro Dalcin wrote:
I had that in mind when I wrote my post; changing types is not the
way, that will not work. That is why I proposed __future__ (I really
do not know very well the implementation details of that feature)
because I think the parser/compiler can
On Sep 11, 2005, at 11:24 AM, Guido van Rossum wrote:
But it breaks the desire to keep the Python 3.0 language clean from
deprecated features.
That is a nice goal, another nice goal is to not unnecessarily break
things.
But just installing python3.0 as python and expecting
nothing will
On Sep 28, 2005, at 9:12 AM, Reinhold Birkenfeld wrote:
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |=
On Oct 3, 2005, at 3:47 PM, Fredrik Lundh wrote:
Antoine Pitrou wrote:
If I have an unicode string containing legal characters greater
than
0x7F, and I pass it to a function which converts it to str, the
conversion fails.
so? if it does that, it's not unicode safe.
[...]
what's
On Oct 3, 2005, at 1:53 AM, Piet Delport wrote:
For generators written in this style, yield means suspend
execution of the
current call until the requested result/resource can be provided, and
return regains its full conventional meaning of terminate the
current call
with a given result.
On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
So, instead of having return automatically map to raise
StopIteration
inside generators, I'd like to suggest we keep it illegal to use
return
inside a generator
Only one issue with that: it's _not currently illegal_ to use return
inside
On Nov 9, 2005, at 6:05 PM, Brett Cannon wrote:
I would have no issue with removing .pyo files and have .pyc files
just be as optimized as they the current settings are and leave it at
that. Could have some metadata listing what optimizations occurred,
but do we really need to have a
On Dec 26, 2005, at 11:07 AM, Martin Blais wrote:
Then there's the whole Python list with append() and pop(). It
takes a
method resolution and function call, but at least in Python 2.3,
it is a
hair faster...
Josiah, that's beside the point, because it is not space-efficient,
the
On Jan 8, 2006, at 1:01 PM, Martin v. Löwis wrote:
Fred L. Drake, Jr. wrote:
I like the way trial (from twisted) supports this. The test
method is written
normally, in whatever class makes sense. Then the test is marked
with an
attribute to say it isn't expected to pass yet. When
On Jan 18, 2006, at 11:40 PM, Aahz wrote:
On Wed, Jan 18, 2006, Guido van Rossum wrote:
Can we just all agree that RMS is an asshole now? Bah.
Citing RMS's insanity is a great way to get my blood steaming. --
GvR
Ya know, you don't *have* to use his software. For example, python
could
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:
Several of these files are licensed under GPL:
aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh
ltconfig missing
Are you sure? The copies of aclocal.m4 and config-ml.in both disagree
with you. aclocal seems to have a
On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote:
And licenses are fluid, it may be a piece of cake to
get one of those 'tools' un-GPL'ed, even if they are.
I wouldn't even know whom to ask.
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote:
It shouldn't be too hard to use Python's main
On Feb 1, 2006, at 7:33 AM, Gustavo J. A. M. Carneiro wrote:
Another possility is to extend the 0x syntax to non-hex,
0xff # hex
0o644 # octal
0b1101 # binary
+1
James
___
Python-Dev mailing list
Python-Dev@python.org
On Feb 2, 2006, at 7:11 PM, Bengt Richter wrote:
[1] To reduce all this eye-glazing discussion to a simple example,
how do people now
use hex notation to define an integer bit-mask constant with bits
31 and 2 set?
That's easy:
0x8004
That was broken in python 2.4, though, so there
On Feb 13, 2006, at 7:09 PM, Guido van Rossum wrote:
On 2/13/06, Michael Foord [EMAIL PROTECTED] wrote:
Sorry - I meant for the unicode to bytes case. A default encoding
that
behaves differently to the current to implicit encodes/decodes
would be
confusing IMHO.
And I am in agreement
On Feb 14, 2006, at 12:20 AM, Phillip J. Eby wrote:
bytes(map(ord, str_or_unicode))
In other words, without an encoding, bytes() should simply treat
str and
unicode objects *as if they were a sequence of integers*, and
produce an
error when an integer is out of range. This is a
On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I was just pointing out that since byte strings are bytes by
definition,
then simply putting those bytes in a bytes() object doesn't alter the
existing encoding. So, using latin-1 when converting a string to
Rossum wrote:
On 2/13/06, James Y Knight [EMAIL PROTECTED] wrote:
In py3k, when the str object is eliminated, then what do you have?
Perhaps
- bytes(\x80), you get an error, encoding is required. There is no
such thing as default encoding anymore, as there's no str object.
- bytes(\x80, encoding
On Feb 14, 2006, at 11:25 AM, Phillip J. Eby wrote:
At 11:08 AM 2/14/2006 -0500, James Y Knight wrote:
I like it, it makes sense. Unicode strings are simply not allowed as
arguments to the byte constructor. Thinking about it, why would it be
otherwise? And if you're mixing str-strings
On Feb 15, 2006, at 7:19 AM, Fuzzyman wrote:
[snip..]
I personally like the move towards all unicode strings, basically
any text where you don't know the encoding used is 'random binary
data'. This works fine, so long as you are in control of the text
source. *However*, it leaves the
On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
I don't understand. In the rationale of PEP 333, it says
The rationale for requiring a dictionary is to maximize portability
between servers. The alternative would be to define some subset of a
dictionary's methods as being the standard and
On Feb 22, 2006, at 6:35 AM, Greg Ewing wrote:
I'm thinking of convenience, too. Keep in mind that in Py3k,
'unicode' will be called 'str' (or something equally neutral
like 'text') and you will rarely have to deal explicitly with
unicode codings, this being done mostly for you by the I/O
On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote:
On 2/28/06, Greg Ewing [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
My personal goal in life right now is to stay as
far away from C++ as I can get.
so what C compiler are you using ?
Gcc, mostly. I don't mind if it's capable of
On Mar 29, 2006, at 1:38 PM, Martin v. Löwis wrote:
Given that Barry insists so firmly that there is a need, and that
this need arises from a significant code simplification that can
be achieved through the API, the natural conclusion is to add
the API. That, of course, assumes that you
On Apr 3, 2006, at 3:12 PM, Neil Schemenauer wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
This would require a bit __del__ already called on an object,
but don't we have a whole word of GC-related flags?
No.
Actually there is. Kinda. Currently python's refcounting scheme uses
4 words
On Apr 3, 2006, at 4:02 PM, Tim Peters wrote:
Using which compiler? This varies across boxes. Most obviously, on a
64-bit box all these members are 8 bytes (note that ob_refcnt is
Py_ssize_t in 2.5, not int anymore), but even on some 32-bit boxes the
long double trick only forces 4-byte
On Apr 4, 2006, at 11:41 PM, Alex Martelli wrote:
IMHO, the solution to THAT very real problem is to supply a built-in
function that catches some exceptions and maps them into suitable
return values. Simplest would be something like:
[...]
though I'm sure we can get better syntax if we turn
On Apr 19, 2006, at 3:19 PM, Phillip J. Eby wrote:
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be
On Apr 26, 2006, at 4:49 PM, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
No, you can not make a change which has a tiny (and arguably
On May 1, 2006, at 8:15 AM, Nick Coghlan wrote:
1. PEP 343, 2.5 alpha 1, 2.5 alpha 2 and the discussions here have
no doubt
seriously confused the meaning of the term 'context manager' for a
lot of
people (you can certainly put me down as one such person). Anyone
not already
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote:
Well, you can't def a dotted name, but I realize this isn't a
binding.
I have actually wanted to do that before. It would be nice if you
could. :)
James
___
Python-Dev mailing list
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than
anything
Google has yet released. Twisted also has a reasonably plausible
technical reason to dislike this change.
On Jun 25, 2006, at 9:47 PM, James Y Knight wrote:
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than
anything
Google has yet released. Twisted also has a reasonably
On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
If there are any bugs you think should be considered show stoppers,
mail them to the list and I will update the PEP.
I just submitted http://python.org/sf/1515169 for the ImportWarning
issue previously discussed here. IMO it's important.
James
On Jul 13, 2006, at 12:52 PM, Thomas Heller wrote:
IIUC, the buffer object was broken some time ago, but I think it has
been fixed. Can the 'status' of the buffer function be changed?
To quote the next question from the OP:
Is buffer safe to use? Is there an alternative?
My thinking
On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
Note that it also helps setting the default encoding
to 'unknown'. That way you disable the coercion of strings
to Unicode and all the places where this implicit conversion
takes place crop up, allowing you to take proper action (i.e.
explicit
On Jul 16, 2006, at 5:42 AM, Scott Dial wrote:
Talin wrote:
Scott Dial wrote:
Phillip J. Eby wrote:
A function's func_closure contains cell objects that hold the
variables. These are readable if you can set the func_closure
of some
function of your own. If the overall plan includes
On Jul 15, 2006, at 2:38 PM, Johan Dahlin wrote:
What I want to ask, is it possible to have a sanctioned way to
implement
a dynamic module/namespace in python?
For instance, it could be implemented to allow you to replace the
__dict__ attribute in a module with a user provided object
On Jul 18, 2006, at 1:54 PM, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some
locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now (for the current versions
On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote:
To cut a long story short, it is impractical for a language run-time
system to call user-defined handlers with any degree of reliability
unless the compiled code and run-time interoperate carefully - I have
been there and done that many times,
On Jul 21, 2006, at 12:45 PM, Giovanni Bajo wrote:
Jason Orendorff wrote:
However, I'm also struggling to think of a case other than list vs
deque where the choice of a builtin or standard library data
structure would be dictated by big-O() concerns.
OK, but that doesn't mean the
On Jul 23, 2006, at 4:41 PM, Giovanni Bajo wrote:
I think Martin decided to keep VC71 (Visual Studio .NET 2003) for
another
release cycle. Given the impressive results of VC8 with PGO, and
the fact
that Visual Studio Express 2005 is free forever, I would hope as
well for
the decision
On Aug 2, 2006, at 11:26 PM, Raymond Hettinger wrote:
Also, -10 on changing the semantics of int() to round instead of
truncate. The truncating version is found is so many other languages
and book examples, that it would be a disaster for us to choose a
different meaning.
I'd be happy to
On Aug 3, 2006, at 5:47 PM, M.-A. Lemburg wrote:
The only way this error could be the right thing is if you were
trying
to suggest that he shouldn't mix unicode and bytestrings at all.
Good question. I wonder whether that's a reasonable approach for
Python 2.x (I'd say it is for Py3k).
On Aug 3, 2006, at 2:34 AM, Greg Ewing wrote:
Raymond Hettinger wrote:
-1 on an extra built-in just to save the time for function call
The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has
On Aug 4, 2006, at 12:34 AM, Josiah Carlson wrote:
As an alternate idea, rather than attempting to .decode('ascii') when
strings and unicode compare, why not .decode('latin-1')? We lose the
unicode decoding error, but the right thing happens (in my opinion)
when u'\xa1' and '\xa1' compare.
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 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
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
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
On Aug 15, 2006, at 6:20 PM, Martin v. Löwis wrote:
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation
types,
since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
to
On Aug 15, 2006, at 7:06 PM, Guido van Rossum wrote:
There's no particular reason that a short int must be able to store
the entire range of C long, so, as many bits can be stolen from it
as desired.
There isn't? Actually a lot of APIs currently assumen that.
I thought we were talking about
On Aug 17, 2006, at 1:26 AM, Neal Norwitz wrote:
Thanks Dino.
The attached patch should fix the problem. Once RC1 is cut, I'll
check this in unless someone beats me to it. Since the compiler
changed, I can't backport this. If someone wants to make a similar
fix for 2.4 go for it.
The
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is
On Oct 3, 2006, at 2:26 PM, Nick Maclaren wrote:
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
py x=-0.0
py y=0.0
py x,y
Nobody is denying that SOME C90 implementations distinguish them,
but it is no part of the standard - indeed, a C90 implementation is
permitted
On Oct 25, 2006, at 10:48 PM, Talin wrote:
That's true of textual paths in general - i.e. even on unix, textual
paths aren't guaranteed to be unique or exist.
Its been a while since I used classic MacOS - how do you handle things
like configuration files with path names in them?
You aren't
On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote:
Notice that at least the following objects are shared between
interpreters, as they are singletons:
- None, True, False, (), , u
- strings of length 1, Unicode strings of length 1 with ord 256
- integers between -5 and 256
How do you deal
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to
Py3K, I wonder?
I certainly can't speak for the project as a whole, but I anticipate a
fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0.
I (another
On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote:
I'm plan to try and make the transition as painless as possible.
I'm glad to hear it.
The goal is to have a first alpha sometime this year - there is
absolutely no chance of a 3.0 final this year.
Duly noted.
Basically: my plea is: please
On Jan 12, 2007, at 7:26 PM, Ron Adam wrote:
For me, the thing that will make porting 2.x to 3.x code easy is to
make python
3.0 as clean and organized as you can with excellent
documentation. Half-way
and duel-way approaches will probably not help me as much as this.
Most of the
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
The benefit (to me, and to many others) of 3.x over 2.x is the
promise
of getting rid of cruft.
If we're going to re-add cruft for the sake of temporary
compatibility, we may as well just stick with 2.x. You have to
take a
quantum leap
On Jan 16, 2007, at 12:06 PM, Phillip J. Eby wrote:
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of
1 - 100 of 255 matches
Mail list logo
