It appears that the contextmanager implementation (both in the stdlib and
as described in the PEP) doesn't correctly handle the case where the
generator yields a new value in response to throw(). It responds by
suppressing the original exception, but IIRC earlier versions of the PEP
threw a
At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
I think it's overkill to warn for any string exceptions thrown this
way. Since the only use case for using throw() is to pass an exception
you just caught, I don't see that putting the warning is useful --
it's just more code that in practice is
At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
The current state is that it always allows them, right?
No. It doesn't allow them. Support for string exceptions was never
actually implemented; I'm trying to implement it now.
___
Python-Dev
At 03:06 PM 3/24/2006 -0800, Guido van Rossum wrote:
On 3/24/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
The current state is that it always allows them, right?
No. It doesn't allow them. Support for string exceptions was never
At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
Oops, that's definitely a bug. Please go ahead and fix in both places.
Will do.
(I'm still trying to fathom the other PEP 343 issue you brought up.)
Here's the paragraph I'm proposing to add to the PEP to explain that issue:
NOTE: to
At 03:23 PM 3/24/2006 -0800, Guido van Rossum wrote:
And I see no reason to complicate the code with an additional check
that doesn't serve a purpose. The purpose of reminding people not to
write g.throw(abc) seems artificial to me. I'd rather see less code,
meaning less maintenance, and no need
At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
I'm not against recommending in the PEP that __exit__ shouldn't
re-raise but instead should return False to signal a re-raise, and
fixing any existing code that re-raises in __exit__. But I'm still
questioning your use case; why is it important
At 03:58 PM 3/24/2006 -0800, Guido van Rossum wrote:
OK, I give up. I'm giving you a -1 on the test for a non-empty
traceback without explaining it further.
Not a problem; I just wanted to make sure you were rejecting the same thing
that I was proposing. :) I've checked in the your way
At 08:13 PM 3/24/2006 -0800, Guido van Rossum wrote:
I think that the code you added:
+except:
+if sys.exc_info()[1] is not value:
+raise
could use a comment explaining what's going on;
Done.
the difference between
returning None and
At 10:33 AM 3/15/2006 -0800, Guido van Rossum wrote:
Well, absolute imports without the future statement will not use the
5th argument, so they won't break, right? That's what MAL also says.
Someone please fix this.
Why is a 5th argument needed to do absolute imports? Shouldn't it suffice
to
At 01:34 PM 3/15/2006 -0800, Guido van Rossum wrote:
Because Thomas designed it this way. :-)
I believe his design makes sense though: import foo translates to
__import__(foo, ...).
There's a separate setting, only known to the compiler, that says
whether from __future__ import absolute_import
At 02:21 PM 3/14/2006 -0500, Tim Peters wrote:
There _is_ some variation in what critical section means, exactly,
to different thread programming cultures, but in none does it mean:
a section of code such that, once a thread enters it, all other
threads are blocked from doing anything
At 02:47 PM 3/13/2006 -0500, Jim Jewett wrote:
Paul Moore wrote:
Is there any practical way of detecting and flagging
constructs like the above (remotely shadowing a
builtin in another module)?
Phillip J. Eby wrote:
the patch ended up being backed out ... too strict
of a check
At 09:57 PM 3/13/2006 -0500, Raymond Hettinger wrote:
FWIW, the new with-statement makes the above fragment even more readable:
with atomic_transaction():
# do a series of steps without interruption
+1 on the idea, -1000 on the name. It's neither atomic nor a
transaction. I
At 08:50 AM 3/9/2006 -0600, Steven Elliott wrote:
I believe that currently mod.str = my_str alters the module's global
hash table (f-f_globals in the code). One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of
At 08:51 AM 3/9/2006 -0800, Raymond Hettinger wrote:
Perhaps what I'm suggesting isn't feasible for reasons that have already
been discussed. But it seems like it should be possible to make while
True as efficient as while 1.
That is going to be difficult as long as it is legal to write:
At 12:46 PM 3/10/2006 +1300, Greg Ewing wrote:
Steven Elliott wrote:
One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of the default builtins. If it is,
then the module's indexed array of builtins is
At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
see subject and http://python.org/sf/1368955
comments ?
Why can't the UUIDs be immutable, so they can be dictionary keys? Also, it
would be nice if you could just call UUID() to create a generic UUID in a
platform-appropriate way. PEAK's uuid
At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms, although that seems it would clutter things up
unnecessarily -
At 04:11 PM 3/4/2006 -0500, Raymond Hettinger wrote:
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms, although that seems it would clutter things
up
At 12:05 AM 3/5/2006 +0300, Oleg Broytmann wrote:
On Sat, Mar 04, 2006 at 03:45:03PM -0500, Phillip J. Eby wrote:
At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__
At 04:44 PM 3/4/2006 -0500, Raymond Hettinger wrote:
As far as I can understand your position, you seem to be arguing that
whatever we have now is correct, and therefore changing it would be wrong.
Yes, that's pretty much it. IMO, introducing __builtin__.next() would
suck. The sublime
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores.
But then next(ob) should make you even happier, because
At 06:14 AM 2/22/2006 -0500, Jeremy Hylton wrote:
On 2/22/06, Greg Ewing [EMAIL PROTECTED] wrote:
Mark Russell wrote:
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures.
Well, anything that facilitates rebinding in outer
At 03:49 PM 2/23/2006 +1300, Greg Ewing wrote:
Steven Bethard wrote:
And, as you mention, it's consistent
with the relative import feature.
Only rather vaguely -- it's really somewhat different.
With imports, .foo is an abbreviation for myself.foo,
where myself is the absolute name for the
At 11:50 PM 2/21/2006 +0100, Morel Xavier wrote:
Phillip J. Eby wrote:
The '.' would mean this name, but in the nearest outer scope that
defines it. Note that this could include the global scope, so the
'global' keyword could go away in 2.5. And in Python 3.0, the '.' could
become *required
At 01:44 PM 02/18/2006 -0500, James Y Knight wrote:
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
At 10:10 AM 02/17/2006 +0100, Georg Brandl wrote:
Guido van Rossum wrote:
d = DefaultDict([])
can be written as simply
d[key].append(value)
Feedback?
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify either a default
At 11:58 AM 02/17/2006 -0800, Guido van Rossum wrote:
I forgot to mention in my revised proposal that the API for setting
the default_factory is slightly odd:
d = {} # or dict()
d.default_factory = list
rather than
d = dict(default_factory=list)
This is of course because we cut off
At 11:08 AM 2/14/2006 -0500, James Y Knight wrote:
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
(Disclaimer: I'm not currently promoting the addition of bdist_egg or any
egg-specific features for the 2.5 timeframe, but neither am I
opposed. This message is just to clarify a few points and questions under
discussion, not to advocate a particular outcome. If you read this and
think you
At 03:14 PM 2/14/2006 -0800, Bob Ippolito wrote:
I'm also not sure what the uninstallation story
with scripts is.
The scripts have enough breadcrumbs in them that you can figure out what
egg they go with. More precisely, an egg contains enough information for
you to search PATH for its scripts
At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation. There should be are lots of
ways to create bytes objects from string objects, with specific
explicit encodings, and those should
At 10:55 PM 2/13/2006 +0100, M.-A. Lemburg wrote:
Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation
At 12:03 AM 2/14/2006 +0100, M.-A. Lemburg wrote:
The conversion from Unicode to bytes is different in this
respect, since you are converting from a bigger type to
a smaller one. Choosing latin-1 as default for this
conversion would give you all 8 bits, instead of just 7
bits that ASCII provides.
At 03:23 PM 2/13/2006 -0800, Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
The only
use I see for having an encoding for a 'str' would be to allow confirming
that the input string in fact is valid for that encoding. So,
bytes(some_str,'ascii') would
At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I didn't mean that it was the only purpose. In Python 2.x, practical code
has to sometimes deal with string-like objects. That is, code that takes
either strings or unicode
At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote:
PEP 343: The with Statement
Didn't Michael Hudson have a patch?
PEP 343's Accepted status was reverted to Draft in October, and then
changed back to Accepted. I believe the latter change is an error, since
you haven't pronounced on the
At 10:07 AM 2/8/2006 -0800, Guido van Rossum wrote:
On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote:
And to think that people thought that keeping lambda, but changing
the name, would avoid all the heated discussion... :-)
Note that I'm not participating in any attempts to improve lambda.
At 08:35 PM 2/4/2006 +0100, Giovanni Bajo wrote:
- ctime() is documented to be unportable: it has different semantics on UNIX
and Windows. I believe the class should abstract from these details.
Note that this is the opposite of normal Python policy: Python does not
attempt to create
At 01:55 PM 2/1/2006 -0500, Greg Wilson wrote:
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for
At 11:25 AM 1/26/2006 +1300, Tony Meyer wrote:
Against it:
* Zen: Beautiful is better than ugly. Explicit is better than
implicit. Readability counts. There should be one-- and preferably
only one --obvious way to do it.
* Not every platform that Python supports has '/' as the path
At 10:17 AM 01/20/2006 -0800, Guido van Rossum wrote:
The discussion about PEP 343 reminds me of the following. Bram Cohen
pointed out in private email that, before PEP 342, there wasn't a big
need for a shortcut to pass control to a sub-generator because the
following for-loop works well enough:
At 11:19 AM 01/20/2006 -0800, Guido van Rossum wrote:
(There *are*other uses besides the trampoline,
right? :-)
It's easy to come up with use cases where you feed data *into* a generator
(parsers and pipelines, for example). I just don't know of any
simultaneous bidirectional uses other than
At 02:37 AM 1/15/2006 +0100, Christian Tismer wrote:
I assumend the value would be in UTC, but it is obviously not.
Is there a way to circumvent this problem, or am I missing something?
If this is not the expected behavior, then it might make sense
to find a patch.
Windows doesn't store UTC
At 02:36 PM 1/12/2006 -0800, Brett Cannon wrote:
(I have a third, AOP for anything, but I don't think AOP is a good match
for Python and thus not considering it for Python work)
For what it's worth, I've been doing what I'll loosely refer to as
research on implementing a non-traditional form of
At 08:09 AM 1/8/2006 -0800, Ralf W. Grosse-Kunstleve wrote:
--- Thomas Wouters [EMAIL PROTECTED] wrote:
The main difference isn't the lookup of 'self', it's the attribute
retrieval
of 'x' from 'self'.
I see. Thanks!
If you put 'self' into a special category (with corresponding C code),
At 02:01 PM 1/8/2006 +1000, Nick Coghlan wrote:
Samuele Pedroni wrote:
2)
http://homepages.cwi.nl/~ralf/OOHaskell/
state of the art experiment on trying to reconcile object orientation,
type inference and as much as possible expressiveness
PS: I think 1 is much more relevant than 2 for
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at it ?
Why a new factory function ? Can't we just redirect to codecs.open()
in case an encoding keyword argument is passed to open() ?!
I think open is
At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at it ?
Why a new factory function ? Can't we just redirect to codecs.open
At 04:37 PM 12/27/2005 +0100, Fredrik Lundh wrote:
but that was made at a time when it wasn't clear if open or file would
be the preferred way to open a file. now that we've settled on the verb
form, I think textopen or opentext would be slightly more consistent.
Sorry, I'm confused. Who
At 11:04 AM 12/26/2005 -0800, Josiah Carlson wrote:
Not necessarily so as I have pointed out above. You said yourself;
practicality beats purity. While using cons cells are pure, as us using
only flat lists are pure, flat lists are practically smaller than cons
cells in certain cases (by a
At 09:10 PM 12/25/2005 -0500, Martin Blais wrote:
I still haven't had time to cook a proper reply to Guido, but one
thing I see is that many ppl on the list seem to think that because
there aren't many use cases (that they can see), therefore there isn't
much use for a list collection type. I
At 10:27 AM 12/22/2005 +0100, Walter Dörwald wrote:
Phillip J. Eby wrote:
[...]
If someone has examples of actual Pythondoc markup that don't translate
to reST, I'd be really interested in seeing them, just for my own
education. Of course, I'd also be curious how common such constructs
At 04:08 PM 12/22/2005 -0500, Martin Blais wrote:
ReST does an amazing job of inferring generic document structures from
text, but for documenting source code, you really want to be able to
say This is a function, this is an optional argument, etc. ReST
does not provide this kind of
At 08:21 PM 12/21/2005 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote:
And attempting to roundtrip HTML back to reST would lose far too much
information
in a less dogmatic Python universe, that would be considered a major
design flaw in ReST.
Since when is having a more
At 01:43 PM 12/21/2005 -0600, Ian Bicking wrote:
But when I want to focus
on content the markup is very distracting, and even moreso when writing
about programming (where ASCII, newlines, and whitespace is the native
layout technique).
And where characters like '' and '' occur frequently as
At 03:16 PM 12/21/2005 -0500, Barry Warsaw wrote:
Maybe it's just because I came in late on this thread, but what exactly
is broken about the current LaTeX documentation?
As far as I can tell from his comments:
1. Fredrik doesn't want to have to install a LaTeX toolchain in order to
get an HTML
At 01:40 AM 12/22/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
1. Fredrik doesn't want to have to install a LaTeX toolchain in order to
get an HTML version of the documentation
2. Fredrik likes using whatever tools he has for editing HTML better than
whatever he has
At 08:35 AM 12/16/2005 -0500, Barry Warsaw wrote:
On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote:
FYI, this is not the true revision number; it's only the revision
number in
which the directory was last modified, not the latest revision number
within the tree.
Yep, I know
At 07:42 AM 12/16/2005 -0800, Michael Chermside wrote:
Phillip writes:
FYI, this is not the true revision number; it's only the revision number in
which the directory was last modified, not the latest revision number
within the tree.
Barry responds:
I opted against that for several
At 05:17 PM 12/16/2005 +0100, Armin Rigo wrote:
Hi Phillip,
On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote:
The Revision from svn info isn't reliable; it doesn't actually relate
to what version of code is in the subtree. It can change when nothing has
changed.
Indeed
At 08:30 PM 12/16/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The Revision from svn info isn't reliable; it doesn't actually relate
to what version of code is in the subtree. It can change when nothing has
changed.
That is not true. It does relate - it is the revision
At 10:03 PM 12/16/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
But you can also have more than one revision number that represents the
*exact same code*, with no changes at all.
That's correct. I don't see this as a problem - in particular not in
the context of the proposed patch
At 10:16 PM 12/16/2005 +0100, Armin Rigo wrote:
Hi Phillip,
On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote:
Not if you're happy with Last Changed Rev:
LC_ALL=C svn info | grep -i last changed rev | cut -f 4 -d
You left off the all-important -R from svn info
At 10:53 PM 12/16/2005 +0100, Fredrik Lundh wrote:
fwiw, the official way to do this is to use svnversion:
http://subversion.tigris.org/faq.html#version-value-in-source
(this also looks for local changes).
It looks like using 'svnversion -c . | cut -f2 -d:' would get the
most-recent
At 09:30 PM 12/15/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I don't know. I can see that the split makes sense for prefix/exec-prefix
distinctions, but then again, the disutils will install an entire
distribution in exec-prefix if it contains impure parts, so that's
At 10:14 PM 12/15/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Right; the question is why not just EXEC_PREFIX /lib/python VERSION
instead. What benefit does the separate directory offer?
I can only guess: it's primarily a matter of tidiness.
Note that the distutils, when
At 12:16 AM 12/16/2005 -0500, Barry Warsaw wrote:
SF patch # 1382163 is a fairly simple patch to expose the Subversion
revision number to Python, both in the Py_GetBuildInfo() text, and in a
new Py_GetBuildNumber() C API function, and via a new sys.build_number
attribute. This number is
At 08:21 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought
At 09:56 AM 12/14/2005 -0800, Scott David Daniels wrote:
My (admittedly weak) understanding of how packages work is that all
parts of a package should lie off the same node of the PYTHONPATH.
This isn't a requirement; packages have a __path__ attribute which can
include more than one directory.
At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone
At 11:50 PM 12/14/2005 -0600, Ian Bicking wrote:
Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
At 11:17 PM 12/13/2005 +0100, Fredrik Lundh wrote:
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone have a better idea ?
I was under the
At 09:59 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
Jim That's why, in my suggested writeup, I suggested that attributes
Jim should be used if the accessors are trivial.
In my experience it's difficult to find the locations where another module
mucks with your object's state. Using
At 11:35 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
In my experience it's difficult to find the locations where another
module mucks with your object's state. Using properties or accessor
methods coupling between modules is reduced and you can be more
confident that the
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many classes
being tossed about at that point that I try to be more explicit. But I
don't consider that a common
At 10:03 PM 12/12/2005 +0100, Fredrik Lundh wrote:
the xml/__init__.py file contains a cute little hack that overrides
the *entire* xml subtree with stuff from PyXML, if available.
the code basically does
import _xmlplus
sys.modules[__name__] = _xmlplus
(exception handling and version
At 02:59 PM 12/12/2005 -0800, Alex Martelli wrote:
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many
At 06:19 PM 12/12/2005 -0700, Mike Brown wrote:
Some authors of other libs may not even be aware that they could so
easily have their code whisked into stdlib, if it's solid enough.
But here the definition of solid enough includes such credits as being
written by the primary author of CPython's
At 11:51 PM 11/23/2005 +1000, Nick Coghlan wrote:
The key thing that is missing is the imp.getloader functionality discussed
at the end of PEP 302.
This isn't hard to implement per se; setuptools for example has a
'get_importer' function, and going from importer to loader is simple:
def
At 06:32 PM 11/22/2005 -0800, Brett Cannon wrote:
Hmm, it would be nice to give a function a module
name (like from an import statement) and have Python resolve it using
the normal sys.path iteration.
Yep, import path - filename path would be cool.
Zipped and frozen modules don't have
At 06:48 PM 11/15/2005 -0500, Michiel Jan Laurens de Hoon wrote:
Thanks everybody for contributing to this discussion. I didn't expect it
to become this extensive.
I think that by now, everybody has had their chance to voice their opinion.
It seems safe to conclude that there is no consensus on
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, while we're on this subject, can we make the optimization
options be part of the compile() interface? Right now the distutils has to
actually exec another Python process
At 01:47 PM 11/10/2005 +, Donovan Baarda wrote:
Twisted is an async-framework that I believe has support for using a
variety of different event-loops, including Tkinter and wxWidgets, as
well as it's own.
Technically, it just gives Tkinter a chance to run every so often; you
specifically
At 11:32 AM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Osvaldo Santana [EMAIL PROTECTED] wrote:
I've noticed this inconsistency when we stop to use zipimport in our
Python For Maemo distribution. We've decided to stop using zipimport
because the device (Nokia 770) uses a compressed
At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
The only solutions I can think of that use a single file actually
*increase* the file size by having unoptimized and optimized code
side-by-side, or some way to quickly skip the assertions -- the -OO
option is a special case that probably needs
At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
The main way this breaks down is when comparing objects of different
types. While most comparisons typically are defined in terms of
comparisons on simpler or contained objects, two objects of different
types that happen to have the same key
At 01:29 PM 11/6/2005 -0800, Guido van Rossum wrote:
On 11/6/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
The main way this breaks down is when comparing objects of different
types. While most comparisons typically are defined in terms
At 07:12 PM 11/6/2005 -0500, Phillip J. Eby wrote:
At 01:29 PM 11/6/2005 -0800, Guido van Rossum wrote:
On 11/6/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
The main way this breaks down is when comparing objects of different
types
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through
At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
* PEP 328 - absolute/relative import
I assume that references to 2.4 in that PEP should be changed to 2.5, and
so on.
It also appears to me that the PEP doesn't record the issue brought up by
some people about the current absolute/relative
At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
I guess this ought to be recorded. :-(
The issue has been beaten to death and my position remains firm:
rather than playing namespace games, consistent renaming is the right
thing to do here. This becomes a trivial source edit,
Well, it's not
At 10:34 AM 11/1/2005 -0800, Neal Norwitz wrote:
Why can't you add your version's directory to sys.path before importing
pyexpat?
With library code that can be imported in any order, there is no such thing
as before. Anyway, Guido has pronounced on this already, so it's moot.
At 09:19 AM 10/23/2005 -0700, Guido van Rossum wrote:
On 10/23/05, Nick Coghlan [EMAIL PROTECTED] wrote:
However, I'm still concerned about the fact that the following class has a
context manager that doesn't actually work:
class Broken(object):
def __context__(self):
At 06:06 PM 10/23/2005 -0700, Guido van Rossum wrote:
Folks, please focus on what Python 3000 should do.
I'm thinking about making all character strings Unicode (possibly with
different internal representations a la NSString in Apple's Objective
C) and introduce a separate mutable bytes array
At 01:30 AM 10/23/2005 -0400, Raymond Hettinger wrote:
FWIW, a few months ago, I reported that File New or File Open in IDLE
would crash Python as a result of the check-in implementing PEP 342.
Now, with AST checked-in, IDLE has started working again. Given the
reconfirmation, I recommend that
At 11:13 AM 10/21/2005 -0400, Jeremy Hylton wrote:
I don't have a strong sense for how important these changes are. I
don't think the old behavior was documented, but I can imagine some
code depending on these implementation details.
I'm pretty sure I've seen code in the field (e.g. recipes in
At 10:40 PM 10/20/2005 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
This is still rather rough, but I figured it's easier to let everybody
fill
in the remaining gaps by arguments than it is for me to pick a position I
like and try to convince everybody else that it's right. :) Your
At 07:57 PM 10/20/2005 -0700, Guido van Rossum wrote:
(Sorry for the long post -- there just wasn't anything you said that I
felt could be left unquoted. :-)
Wow. You've brought up an awful lot of stuff I want to respond to, about
the nature of frameworks, AOP, Chandler, PEP 342, software
501 - 600 of 848 matches
Mail list logo
