On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes 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. SpiderMonkey (Mozil
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 ma
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:
h
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 JavaSc
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 refcount
On 8/29/07, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti wrote:
> > C doesn't have an exponentiation operator. You use the pow() function,
> > instead:
>
> Wouldn't it make more sense, then, to have unary +/- have higher
> precedence than the ** operator, so that -3**2 == 9?
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 q
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
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 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!
> :-)
Scheme is adding Unicode support in an upcoming standard:
(DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
I have two questions for the python-dev team about Python's Unicode
experiences. If it's convenient, please take a moment to reply.
Thanks in advance.
1. In hindsight, wha
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.
&g
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. It seems to be more a matter of what's not
documented, or what's not covered by the regression tests.
So. I'd be happy to do some diffing be
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
> in
On 3/5/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Any ideas for fixing this problem?
The current developer FAQ says:
2.4 How can I become a developer?
There's only one way to become a developer, and that's through
the School of Hard Knocks.
http://mail.python.org/pipermail/python-de
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 countin
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 ca
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 th
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 y
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 o
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. Th
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
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
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 i"xyzzy" 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 typ
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:
>
>
On 2/22/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
@classmethoddef fromhex(self, data):data = "" '', data)return bytes(binascii.unhexlify(data))If it's to be a classmethod, I guess that should be "return self(
binascii.unhexlify(data))".-j
__
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
On 1/28/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Please note that my point was entirely different from trying to decide
> whether to subclass strings.
Noted -- sorry I took you out of context there; that was careless.
> Jason> Filesystem paths are in fact strings on all operating
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/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
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
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 expe
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
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
function
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 (i
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 h
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 criterion
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 o
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.
>
>
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 cert
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, w
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
-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 possi
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 de
Martin,
These two cases generate different bytecode.
def foo(): # foo.func_code.co_flags == 0x43
print x# LOAD_FAST 0
x = 3
class Foo: # .co_flags == 0x40
print x# LOAD_NAME 'x'
x = 3
In functions, local variables are just numbered slots.
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) was
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 decora
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
gen
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 built
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 ?:.
>
>
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
http://mail.python.org/mailman/listinfo/python-de
61 matches
Mail list logo
