slightly
more wordy and less clever. But that's just one person's opinion.
Thanks Guido, for maintaining your patience in the face of this
discussion.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
everyone. It makes
complete sense to me that empty iterators and Queue.Queues are True...
it follows the general rule that everything is true except the above
(short) list of objects and user-defined (or library) classes that
want to mimic the behavior of one of these
trick Greg is proposing, but I
do agree that _IF_ everything else were equal, then Queue seems
to belong in the threading module. My biggest reason is that I
think anyone who is new to threading probably shouldn't use any
communication mechanism OTHER than Queue or something similar
which has
o=1, bar=2, **kwds)
>
> but the current grammar doesn't allow it.
Hmm why doesn't the current grammar allow it, and can we fix that?
I don't see that it's a limitation of the one-token-lookahead, could
we permit this syntax by rearanging bits of the grammer?
-- M
ython-dev, it is very rare to encounter a
problem that cannot be solved (and readably so) using the existing
tools and constructs.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
itously break code
by renaming it until 3.0 arrives.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Aahz writes:
> I'm suggesting that we add a doc note that using the thread module is
> discouraged and that it will be renamed in 3.0.
Then we're apparently all in agreement.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev
sed on functionality rather than style, and
there wouldn't have been any need for discussion.
Oh yeah, and you can also put extra info into an exception object
besides just the error message. (We don't do that as often as we
should... it's a powerful technique.)
-- Michael Chermsi
ations). However,
I think such a PEP would be rejected. Building your own thing that
works well with Python would NOT be rejected. The idea is interesting,
and it _may_ be sound; only an actual implementation could prove this
either way.
-- Michael Chermside
_
efault __eq__
behavior has to cater to one of these -- clearly either "value"
objects or "identity" objects. Guido chose to cater to "identity"
objects believing that they are actually more common in most
situations. A beneficial side-effect is that the default behavior
of __eq
cimals (they sometimes still have
surprising behavior, but less often than with binary floats). And
backward compatibility argues in favor of floats. Myself, I'm an
"expert" user (at least to this extent) and I could easily handle
eithe
say that there's one
rule for all *normal* attributes and a slightly different rule for all
double-underbar methods except for __context__ which is just like a normal
attribute. That feels too big for my brain -- what on earth is so special
about __context__ that it has to be different f
w libraries that have struck
me as being canidates for the "one good implementation" that
serves the basic needs of the typical user.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s of Python would
> pass muster in the current XML-SIG.
Yes, I'm sorry about not being clearer, and thanks for correcting me. It
was the more recent work in XML which I was thinking of.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev
bar" because that's what PEP 8 says.
I believe recall the conversation that preceded putting that into
PEP 8, and the impetus for that particular decision was input from
non-native English speakers (particularly those not coming from a
European alphabet) that it was far easier to r
n't think we can change it now, but I _do_ believe that
the lack of such conventions is a bit distracting. (Not enough to
make me prefer Java, of course!)
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
s. I think the best all-around solution is to
include cElementTree and use it wherever possible unless the user
specially imports the pure-python version. Perhaps importing
"xml.etree" gets you cElementTree unless that isn't compiled on your
platform, but you can import "xml.p
us
solution. And if that's not the problem we're trying to solve here, then
what IS? Because I don't know of very many ACTUAL (as opposed to
theoretical) use cases for abstract base classes of fundamental types.
-- Michael Chermside
_
onable for a container to support __getitem__, but not support
__len__. Perhaps the container uses an algorithm to generate the
items and is effectively of infinite size. In your hierarchy, this
wouldn't even be a basecontainer (and thus, clearly not a
basesequence). But if all you want to do is
m the current system
(submit a patch to sourceforge), except that the format for entering
the change would be simpler.
Of course, the person who REALLY gets to decide how it works isn't me;
it's whoever decides to spend the time to BUILD this system.
-- Michael Chermside
_
to specify which category they think
this particular note belongs to so the doc editors can read only the ones
that people thought ought to be included in the docs.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
I think users will be understanding
if we're honest about what are the accidents -- every language or
software package has some, and just because it's an accident does NOT
mean we should "fix" it.
-- Michael Chermside
___
Python-D
#x27;m much
more open to being convinced. They are less often used, thus
more suitable for a global fix-and-replace or at tweak to the
input statements at the top of the file. Being less frequently
used also means that consistancy in naming is more important
because p
101 - 123 of 123 matches
Mail list logo
