up the good work! Some day I'd like to see NumPy built in
to the standard Python distribution. The incremental, PEP by PEP approach
you are taking is the best route to getting there. But there may be
some changes along the way -- convergence with ctypes may be one of
ke this:
S.partition(sep) -> (head, sep, tail)
S.rpartition(sep) -> (tail, sep, rest)
Perhaps someone else can find something clearer than my suggestion,
but in my own head, the terms "head" and "tail" are tighly bound
with the idea of beginning and end (respective
I think we should note this policy someplace official -- perhaps
in the Language Reference where __eq__ and __lt__ are defined. But
I do not think that these changes should be made until Py3K.
What do others think? Is this the "right" approach?
--
to
release ElementTree in the stdlib exactly as it is in 2.5 and change
it for 2.6.
-- 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
icode but let everyone else using objects that
raise exceptions suffer), but I think it would be more friendly to
use warnings for now and exceptions after another full release
cycle. The warnings should solve the underlying issue (hard-to-debug
problems).
-- Michael Chermside
_
use an exception after one more release when people have had time
to fix their code.
-- 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
Marc-Andre Lemburg writes:
> How about generating a warning instead and then go for the exception
> in 2.6 ?
Agreed. Michael Hudson's explanation convinced me.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@pyth
hen later in the code we could do things like this:
language = 'en'
dayOfWeek = DaysOfWeek.Mon
month = Months.Jan
dayOfMonth = 3
print '%s, %s %s' % (
translations[dayOfWeek][language],
translations[month][language],
dayOfMonth)
# this works in 2.4 but fails in 2.5
- end problem_with_dicts.py
Please reconsider.
-- 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
hat it is always trumped by adding
another digit of precision to your numbers / lookup tables / whatever.
If so, then even more credit needs to be given to the system that
supports adjustable precision (the Decimal module).
-- Michael Chermside
___
Pyt
ze out more digits of
precision per bit of storage than decimal floats, or that binary
floats are faster because they are supported by specialized hardware,
then I'd go along, but they're not a "better model".
-- Michael Chermside
___
be sufficient, or if it is
valuable to allow end users to fine-tune the
restrictions.
-- 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
I quoted this unwritten bit of Python Zen, attributing it to Tim:
> Syntax should not look like grit on my monitor.
mwh writes:
> I think it was Anthony:
>
> http://mail.python.org/pipermail/python-dev/2005-July/054581.html
But that's not the original. Turns out, it WAS Anthony, and I had
mis
. We provide a means for obtaining
a SecureFileWrapper bound to a given file (perhaps open()).
Essentially, we give up on hiding file, which is a frequently-used
type, and very hard to hide, and instead we rely on our ability to
write a reliably secure "SecureFileWra
object references.
> D. A given piece of Python code cannot access or communicate
> with certain Python objects in the same interpreter.
>
> E. A given piece of Python code can access only a limited set
> of Python objects in the same interpreter.
Hmmm. I'm not sure.
-- 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
gh about multiple interpreters to be sure -- but somehow I
thought they had separate object pools.
-- 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
ion('example.com'))
untrusted_object.do_stuff()
...
To sum up: I agree that you cannot rely on prevent all the
possible "python tricks", but I still think that capabilities
are a superior solution. I'd like to find a way to achieve
the user-c
rrier? If so, it would simplify a bit
of your proposal, and make me feel a little less worried.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
ught, nonetheless.
My three-year-old has been working on that 'whee'/'.whee' prohibition,
but he hasn't mastered it yet.
Gotta-go-wash-another-load-of-underpants -lly yours,
Michael Chermside
___
Python-Dev mailing list
Python
I swear it's word-for-word accurate because
the quote burned itself into my memory.)
-- 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
how, in Python only builtins is _really_ global -- even today's
global keyword only refers to module scope. So I believe that it
would be a very reasonable interpretation of "global" to mean
"not local", and implement as "search enclosing scopes in order
to find the
o think carefully about such things, and the documentation
on the option should give a good explanation of the tradeoffs
or at least a link to such an explanation.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
(x)
I presume that Michele's proposal is that inspect.isgenerator() (or
perhaps "inspect.isgenfunc()") would return True for "foo" and "bar"
but false for "foo_or_bar". Can you give a single use case for
he basic format() method
and I would have tried to take one small step at a time.
But please don't read this as saying I object to the above ideas...
I wouldn't have said anything if you hadn't asked what my approach
would be.
-- Michael Chermside
_
eyword argument:
>
> "{0:{1}.{2}d}".format(a, b, c)
This violates the specification given above... it has non-escaped '}'
characters. Make up one rule and be consistant.
-- Michael Chermside
___
Python-Dev mailing list
pointing out what should have been
obvious to me from the start. The ability to use callable objects as
functions is a powerful tool in Python, and ought not be broken by decorator
inconsistencies.
-- Michael Chermside
___
Python-Dev mailing l
abase.duras
database.oracle
there's no need to group the SQL databases.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
skillful Java programmers
out there. Yet it is rare to see them write "catch Throwable" when they
should use "catch Exception". That mistake is far more common among
beginning Python users. Surely we can do at least as well as Java!
-- Michael Chermside
PS: I've intentionall
bt we're going to convince Sun or Microsoft to change
their approach to threading, I think it is unwise to build such a
feature into the Python language. Supporting it in CPython only
requires (I think) no more than a very simple C extension. I think
it should stay as an exte
jects in
hopes of selling it for money to comercial projects is a WONDERFUL
business model. Good luck!
-- Michael Chermside
(PS: too bad I can't buy stock in Coverity. How come all the GOOD
companies are private? I had to wait around 6 years before I could
buy stock in Google.)
;absolute_import" in self.futures)
The only USE I have ever seen for code obscurity was in writing
certain vote-counting software where the true behavior needed
to remain obscure even in the face of source code publication.[1]
-- Michael Chermside
[1] http://graphics.stanford.edu/~danielrh/v
hose as identifiers in your code. Avoid only that portion of
the builtin namespace that you feel is worth keeping.
-- 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
n
of builtins (adding one more for next() won't hurt, but if we make a
practice of it we'll eventually have too many).
All told, I prefer using the underscores. I think that the first
invariant is important. But it's a judgement call, and a close one, so
I'll be
3.0 where text == unicode?
Um... yes. Sorry, I'm not completely used to 3.0 yet. I'll need to borrow
the time machine for a little longer before my fingers really pick up on
the 3.0 names and idioms.
-- Michael Chermside
___
Python-Dev mailing li
howed that it would have been
better the other way.
-- 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
A minor related point about on_missing():
Haven't we learned from regrets over the .next() method of iterators
that all "magically" invoked methods should be named using the __xxx__
pattern? Shouldn't it be named __on_missing__() instead?
ion it is that is still undecided). If a
_trivial_ decision is already made, there's no need for a
PEP, but if a difficult decision has been made, then
documenting it in a PEP saves years of having to justify
it to newbies.
-- Michael Chermside
___
Python
#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
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
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
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
_
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
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
_
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
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
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
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
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
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
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
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
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
_
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
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
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
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
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
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
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
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
this is a FRF (Frequently Requested
Feature). I'm not arguing in favor of it, just pointing out that
using "star unpacking" in tuple and list literals is an idea that
I'm sure I've seen proposed at least a couple of times before.
This doesn't necessarily make it a good id
tinction is
supported by the basic file operations in the C library. To open a
text file in binary mode is technically an error (although in many OSs
you'll get away with it).
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
minor incompatibilities no matter how hard we try, but just imagine how
the Perl5 users today would feel if they were told that they could use
Perl6 code in the Perl5 interpreter by using the "@ .fture. <<" command.
I love making Perl users jealous, so I certainly wouldn't vote
lize
that slice literals are allowed only within subscripts and thus do not
conflict with this use.
-- 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
d to a stream of unicode
characters) and later modified things to allow manual control of the
encoding because "modern" operating systems (like Windows) have two
distinct file types.
Don't blame the language designers, blame the OS folks.
-- Michael Chermside
ity to write in the "Python
3.0 style" (all new-style classes, only raise proper exceptions,
etc) in the 2.x series is a VERY useful feature. We want to handle
the transition better than Perl.
-- Michael Chermside
___
Python-Dev mailing list
7;re calling "string views".
I wonder whether there is a way to instrument a JVM to record how often
the underlying buffers are shared, then run some common Java apps. Since
the feature is exactly analogous to what is being proposed here,
e and complain if it weren't).
Simplicity and elegence are two of the reasons that this is such
an excellent proposal, let's not lose them. We have existing
tools (like split() and the re module) to handle the tricky
problems.
-- Michael Chermside
e, then perhaps someone
would be encouraged to supply a patch.
-- 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
ort simple scripts.
Nearly everything I write these days is larger and more complex, but
I retain a soft spot for short simple scripts and want Python to
continue to be the best tool available for these tasks.
-- Michael Chermside
___
Python-Dev mailing
tion like this one, that you use a new subject
header. It will make it easier for the Python-Dev summary
authors and for the people who look back in 20 years to ask
"That str.partition() function is really swiggy! It's everywhere
now, but I wonder what language had it first and who came
argument for
why we should allow only limited forms in Python 3.0.
And next time that I find myself in need of an obfuscated python
entry, I've got a great trick up my sleeve.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
h
[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE]
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Pytho
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> e
are reasonably
exhaustive. If we cannot produce a warning for these, then I'd
rather not produce the warning for the use of bare "except:".
After all, as it's been pointed out, if the use of bare "except:"
is all you are interested in it is quite easy to grep the code t
ng to be said for simplicity, and having only one kind of
"except" clause for try statements is clearly simpler than having both "except
:" and also bare "except:".
-- Michael Chermside
___
Python-Dev mailing list
Python-De
agree that
this is unwise because the existing meaning is a tempting trap for the
unwary. So I don't see any advantage to keeping bare "except:" in the
long run. What we do to ease the transition is a different question,
but one more easily resolved.
-- Michael Chermside
_
e encoding. Lowercase names for encodings are preferred.
>>> u"äöü".encode('utf-8')
'\xc3\xa4\xc3\xb6\xc3\xbc'
I think that if we just took out the example of str() usage and replaced
it with a sentence or two that DID introduce the (revised) str() func
n be simple enough for _me_ to understand it! I think I'm
going to go frame this and have it posted in my cubical.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
One common example
would be to use them only from the main thread.
-- 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
hreaded programs.
This achieves two things: it makes them available to those who need
them (not everyone uses threads!), and it rather forcefully makes the
point that it's NOT usually a good idea to modify global state info in
a context manager beca
upports 'with' statements I will continue to use "context"
to mean lots of different things (eg: decimal.context).
By the way, great job Nick... these docs read quite nicely.
-- Michael Chermside
___
Python-Dev mailing list
Python
#x27;s
behavior than "leave".
Anyway, this stuff is always very subjective and, as I said, I'm just
expressing an opinion. So take it for what it's worth.
-- 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
use C supplies support for binary FP but
does not offer access to the flags and traps), but this is one of those
few cases where it's worth using platform-and-compiler specific code.
Of course, someone still has to step forward and offer to code it.
-- Michael Chermside
_
then that's
one good reason.
> It could also be done by adding a subprocess.CLOSED constant, which if
> passed to Popen causes a new closed file descriptor to be given to the
> subprocess.
-1.
It is easy enough to create a closed FD to read from... why complicate the
API?
--
y:
c().foo()
except TypeError:
fail('Should not have raised TypeError')
There ARE situations when you want to allow an exception (but not
necessarily expect it) and do nothing when it occurs, but I don't
find them all that common, and I certainly don't fin
Gerrit Holl writes:
> What would happen if...
Raymond replies:
> Every molecule in your body would simultaneously implode at the speed of
> light.
So you're saying it triggers C-language "undefined behavior"?
-- Michael Chermside
__
> f2.write(chunk)
What ever happened to "Not every 3 line function needs to be a builtin"?
It's a common pattern. It's easy to do. Where's the problem?
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@py
code I immediately thought that it WAS the
straightforward way to write that code, and that I was just not
smart enough to have realized it until he showed me.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
4-10 values though, so
O(1) and O(n) may not be THAT different. It's one of those cases where the
only thing I'd really believe was experiments done on real code. But it's
a cool optimization if it actually pays off.
-- Michael Chermside
___
Py
e side effect going on here, I don't see it. What
am I missing?
-- 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
and there are only 5-10 open bugs, we
can send intrepid volunteers digging through the archives to examine
bugs that got closed without proper investigation. I'm not holding my
breath.
-- Michael Chermside
___
Python-Dev mailing list
ver something new
goes wrong. This is the only way I've found to work around the
problem in Java. Wouldn't it be nice if Python could do better?
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
ds, make FULL use of the context in the constructor if a context
is provided, but make NO use of the thread context when no context is
provided.
--
One final point... Thanks to Mike Cowlishaw for chiming in with a detailed
and well-considered explanation of his thoughts on the matter.
-- M
object:
>>> import decimal
>>> decimal.getcontext().prec = 4
>>> decimal.getcontext().create_decimal("1.234567890")
Decimal("1.235")
Frankly, I have no idea WHAT purpose is served by passing a context
to the decimal constructor... I didn
an't make more time for this now.
I understand!
> The short course is that
> a module purporting to implement an external standard should not
> deviate from that standard without very good reasons
Yes, but should we think of the constructor-from-string
ct context precision?
(By the way... even if other constructors begin to respect context
precision, the constructor from tuple should NOT -- it exists to provide
low-level access to the implementation. I'll express no opinion on the
constructor from Decimal, because I don't understand the
oing nothing. I CLEARLY intended to
do the appropriate cleanup (or locking, or whatever), but it doesn't
happen.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
thought "Well, what's the harm in letting the variable
survive the 'with' statement?" I'm a big fan of keeping namespaces
"clean", but it's just not important enough to incurr other penalties.
So in this case, I (reluctantly, after givin
be done with higher precision, AND causes any variables set during
the block will retain their higher precision. (It's because context
controls OPERATIONS but changing context never affects individual
Decimal OBJECTS.) So I fear that the whole with_extra_precision()
idea is just likely to tempt
ed convince me that allowing the use of generators
instead of classes with the "do_template" decorator is quite nice in
practice, even though it gets confusing (for beginners anyhow) if you
start to think about it too much.
-- Michael Chermside
# = SAMPLE #1: increasing preci
1 - 100 of 123 matches
Mail list logo
