On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes li...@cheimes.de wrote:
The patch makes use of a GCC feature where labels can be used as values:
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know
about the feature and got confused by the unary operator.
Right.
What I really want is for the need to be less common. What if assert
recognized certain commonly used expression types and actually
generated appropriate error messages?
assert foo.answer == 42
AssertionError: expected foo.answer == 42; actual: 'a suffusion of yellow'
Maybe that's too
On Fri, Apr 4, 2008 at 9:38 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
What specific code breaks? Maybe we need to turn this into a warning
in order to be more backwards compatible?
I looked at Mercurial.
It doesn't use __hash__ at all. It uses __eq__ in two files, three total uses:
On Nov 29, 2007 11:54 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
But then I thought, what if we renamed the __builtin__ module instead
to builtins, and left __builtins__ alone?
Hmm. __builtins__ is a magic hook, but __builtin__-the-module isn't
the thing it hooks, exactly, not the way
On 9/13/07, Justin Tulloss [EMAIL PROTECTED] wrote:
1. Use message passing and transactions. [...]
2. Do it perl style. [...]
3. Come up with an elegant way of handling multiple python processes. [...]
4. Remove the GIL, use transactions for python objects, [...]
The SpiderMonkey JavaScript
On 9/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Now we are getting into details: you do NOT have to lock
an object to modify its reference count. An atomic
increment/decrement operation is enough.
One could measure the performance hit incurred by using atomic
operations for refcounting by
On 5/18/07, Guido van Rossum [EMAIL PROTECTED] wrote:
While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
Operators) by Greg Ewing.
-1. and and or affect the flow of control. It's a matter
of taste, but I feel the benefit is too small here to add
another flow-control quirk.
OK, here's the patch I'd like to direct attention to:
http://python.org/sf/1704134
[ 1704134 ] minidom Level 1 DOM compliance
This is only the first step toward DOM Level 1 compliance. It fixes
the stuff that's easy to fix.
Here are the patch reviews. I put more detailed comments in the SF
On 4/17/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Perhaps a rewrite could target 3.0 and 2.6 could use a backported
version of this *if* py3k compatibility mode is enabled? I'd love to
see at least the 3.0 version cleaned up.
A lot of these bugs can be fixed without forking. I've been
I'm working on minidom's DOM Level 1 compliance, targeting Python 2.6.
We have some bugs involving DOM property behavior. For example,
setting the nodeValue attribute of an Element is supposed to have no
effect. We don't implement this.
The right way to implement these quirks is using new-style
On 4/13/07, Andrew Clover [EMAIL PROTECTED] wrote:
Jason Orendorff wrote:
I don't suppose you'd be willing to update it for Python 2.5, would you?
Can do, but at this point I'm not aware of any work having been done on
the issues listed there between the 2.3 and 2.5 releases.
I've been
On 4/7/07, Andrew Clover [EMAIL PROTECTED] wrote:
Jason Orendorff wrote:
OK, I think this is worthwhile then. :) I'll read the spec and submit
a patch.
You're planning to implement EntityReference in minidom? That'll be fun!
:-) One of the nastier corners of DOM and XML in general.
Mmm
On 4/7/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
In any case, the *claim* certainly is that minidom supports
level 2 core. Any proof to the contrary indicates a bug;
patches are welcome.
OK-- I'll work on this. I can fix the easy ones, anyway.
-j
On 3/23/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jason Orendorff schrieb:
The lib ref claims that minidom supports DOM Level 1. Does anyone
know what parts of Level 2 are not implemented? I wasn't able to find
anything offhand.
I now looked at it closely, and the only thing missing
On 3/12/07, Miguel Lobo [EMAIL PROTECTED] wrote:
Anyway, I'm intrigued about this review 5 other patches procedure you
suggest. What exactly would be involved in such a review? Please note that
I hadn't touched CPython code before I wrote my patch and I haven't been
following CPython
On 3/7/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Terry Jones schrieb:
I do think the behavior can be improved, and that it should be fixed, but
at a place where other incompatible changes will also be being made,
Indeed, 2.6 is such a place. Any feature release can contain
incompatible
Way back on 11/22/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nick Coghlan schrieb:
Martin v. Löwis wrote:
I personally consider it good style to rely on implementation details
of CPython;
Is there a 'do not' missing somewhere in there?
No - I really mean it. I can find nothing wrong
On 11/27/06, Aahz [EMAIL PROTECTED] wrote:
On Mon, Nov 27, 2006, Jason Orendorff wrote:
Way back on 11/22/06, Martin v. L?wis [EMAIL PROTECTED] wrote:
[...] I can find nothing wrong with people relying on
reference counting to close files, for example. It's a property of
CPython
On 9/30/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
OK. Pronouncement: PEP 355 is dead. [...]
It would be terrific if you gave us some clue about what is
wrong in PEP355, [...]
Here are my guesses. I believe Guido rejected this PEP for a lot of reasons.
By the way,
On 9/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
(I just checked the program I'm working on, and my analysis tells me
that the most common floating point value in that program is 121.216,
which occurs 32 times. from what I can tell, 0.0 isn't used at all.)
*bemused look* Fredrik, can you
On 7/21/06, Nick Coghlan [EMAIL PROTECTED] 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 information is unimportant. +1 on
On 5/26/06, Facundo Batista [EMAIL PROTECTED] wrote:
I think that we can do one of the following, when we found -1 * (1, 2, 3):
- Treat -1 as 0 and return an empty tuple (actual behavior).
- Treat the negative as a reverser, so we get back (3, 2, 1).
- Raise an error.
No, no, no. The
Vladimir,
Your examples seem to indicate that you've misunderstood the change
that's proposed for Python 3000. Especially this:
On 5/17/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
# BEGIN: Emulation python3000
if type(a) is not type(b) and (
On 5/11/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
If for Python-3000 similar it will be shown concerning types
str(), int(), complex() and so on, and the type of exceptions
will strongly vary, it will make problematic redefinition of
behavior of function of sorting.
I don't see what
On 4/30/06, Edward Loper [EMAIL PROTECTED] wrote
(referring to keyword-only arguments):
I see two possible reasons:
- A function's author believes that calls to the function will be
easier to read if certain parameters are passed by name, rather
than positionally; and they want
Talin, everything you wrote is really compelling. If path.py weren't
so ridiculously useful to me, I would be completely convinced. :)
For example, I agree 100% with this:
Another reason why I am a bit dubious about a class-based approach
is that it tends to take anything that is related to
A compiler hook on string initialization, eh?
I have a distantly related story--this isn't important, just another
random Python use case for the file. (The ixyzzy proposal wouldn't
help this case.)
In scons, your SConscripts (makefiles, essentially) are Python source
code. You typically have
1. Maybe there should be a more obvious way to spell bytes([0])*N.
I went through bytes([0]*N) and bytes('\0'*N) before I realized
there was a memory-efficient way to do it.
1a. Likewise, slice-assignment nicely handles memmove(), but there's
no memset().
2. Having a plural noun as a type
Neil Schemenauer wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Why was it decided that the unicode encoding argument should be ignored
if the first argument is a string? Wouldn't an exception be better
rather than give the impression it does something when it doesn't?
From the PEP:
There is
On 2/20/06, Mark Mc Mahon [EMAIL PROTECTED] wrote:
It seems that the Path module as currently defined leaves equalitytesting up to the underlying string comparison. My guess is that thisis fine for Unix (maybe not even) but it is a bit lacking for Windows.
Should the path class implement an __eq__
On 2/15/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Actually users trying to figure out Unicode would probably be better served if bytes.encode() and text.decode() did not exist.[...]It would be better if the signature of text.encode() always returned a
bytes object. But why deny the bytes
Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106])
It's
It's controversial that Path subclasses str. Some people think it's
flat-out wrong. Even Bjorn argues that it's a practicality-vs-purity
tradeoff. But a strong argument can be made that Path *should* be a
string subclass, practicality be damned. Proof follows.
I. Here's an example of the sort
On 1/25/06, Toby Dickenson [EMAIL PROTECTED] wrote:
On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote:
#Replacing glob.glob
glob.glob(/lib/*.so)
==
Path(/lib).glob(*.so)
This definition seems confusing because it splits the glob pattern string in
two ('/lib', and
On 1/24/06, Ian Bicking [EMAIL PROTECTED] wrote:
There's kind of a lot of methods in here, which is a little bothersome.
It also points towards the motivation for the class -- too many
options in too many places in the stdlib. But throwing them *all* in
one class consolidates but doesn't
Thanks for doing this. I'm not sure anyone that matters here is
actually keen on path, but I guess we'll see. A few comments:
On 1/24/06, BJörn Lindqvist [EMAIL PROTECTED] wrote:
The following points summarizes the design:
- Path extends from string, therefore all code which expects
On 1/20/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Jason Orendorff wrote:
DecimalContext has a few problems. In code where it matters, every
function you write has to worry about it. (That is, you can't just
write __decimal_context__ = ... at the top of the file and be done
I just noticed that my name is in PEP 343 attached to the idea of the
__context__() method, and I'm slightly queasy over it.
The rationale was to help e.g. decimal.DecimalContext support 'with'.
Maybe that's a bad idea.
DecimalContext has a few problems. In code where it matters, every
On 1/18/06, Donovan Baarda [EMAIL PROTECTED] wrote:
I think supporting arbitrary bases for floats is way overkill and not
worth considering.
If you mean actual base-3 floating-point arithmetic, I agree. That's
outlandish.
But if there were a stdlib function to format floats losslessly in hex
On 1/17/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
But this doesn't apply to the Python Standard Library, for example see
line 1348 of imaplib.py: if isinstance(date_time, (int, float)):.
[...]
Being able to change imaplib to use basenumber instead of (int, float)
It seems dumb to support *parsing* integers in weird bases, but not
*formatting* them in weird bases. Not a big deal, but if you're going
to give me a toy, at least give me the whole toy!
The %b idea is a little disappointing in two ways. Even with %b,
Python is still dumb by the above
Brett,
You could create a downloadable corpus of Python source code, and
maybe a web site through which people can easily browse/search it,
contribute to it, and maintain it. The point would be to support
language designers, tool developers, and researchers. Several
python-dev folks have their
Guido van Rossum wrote:
On 12/13/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Having to define classes that conform to a certain API and registering
instances of those classes as callbacks with the parser doesn't look
that pythonic to me. An iterator API seems much more pythonic.
Perhaps.
On 12/13/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote: BTW, what's the policy wrt. Jython-specific modules in the standard library?I don't think there is enough precedence to have a policy. So far, theonly places that explicitly support Jython is the test suite, pickle,
and
Barry Warsaw wrote:
- If your class is intended to be subclassed, and you have attributes
that you do not want subclasses to use, consider naming them with
double leading underscores and no trailing underscores. This invokes
Python's name mangling algorithm,
On 12/13/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I don't think that SAX is unpythonic, but it's pretty low-level and
mostly of use to people writing higher-level XML parsers (my parsexml
module uses it).
Having to define classes that conform to a certain API
-1 on keeping the source encoding of string literals. Python should
definitely decode them at compile time.
-1 on decoding implicitly as needed. This causes decoding to happen
late, in unpredictable places. Decodes can fail; they should happen
as early and as close to the data source as
On 10/7/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
the whole concept might be perfectly fine on the this construct corre-
sponds to this code level, but if you immediately end up with things that
are not what they seem, and names that don't mean what the say, either
the design or the
Martin,
These two cases generate different bytecode.
def foo(): # foo.func_code.co_flags == 0x43
print x# LOAD_FAST 0
x = 3
class Foo: # code object.co_flags == 0x40
print x# LOAD_NAME 'x'
x = 3
In functions, local variables are just
The argument I am going to try to make is that Python coroutines need
a more usable API.
Try to explain the semantics of the with statement without referring to the
__enter__ and __exit__ methods, and then see if you still think they're
superfluous ;)
The @contextmanager generator decorator
Right after I sent the preceding message I got a funny feeling I'm
wasting everybody's time here. I apologize. Guido's original concern
about speedy C implementation for locks stands. I don't see a good
way around it.
By the way, my expansion of 'with' using coroutines (in previous
message)
I'm -1 on PEP 343. It seems ...complex. And even with all the
complexity, I *still* won't be able to type
with self.lock: ...
which I submit is perfectly reasonable, clean, and clear. Instead I
have to type
with locking(self.lock): ...
where locking() is apparently either a new
Phillip J. Eby writes:
You didn't offer any reasons why this would be useful and/or good.
It makes it dramatically easier to write Python classes that correctly
support 'with'. I don't see any simple way to do this under PEP 343;
the only sane thing to do is write a separate @contextmanager
On 9/20/05, Guido wrote:
On 9/20/05, Jason Orendorff [EMAIL PROTECTED] wrote:
return (if q: q.popleft() else: None)
return (if q then q.popleft() else None)
return q ? q.popleft() : None
Hmmm. Score one for ?:.
Why? Just because it's shorter?
Just a gut response
Concerning names for partition(), I immediately thought of break().
Unfortunately it's taken.
So, how about snap()?
head, sep, tail = line.snap(':')
-j
___
Python-Dev mailing list
Python-Dev@python.org
55 matches
Mail list logo
