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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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:
201 - 255 of 255 matches
Mail list logo
