Hi, this is my first post here and I've been following this very
interesting discussion as is has developed.
A really short intro about me, I was trained as a computer tech in the
early 80's... ie. learned transistors, gates, logic etc... And so my
focus tends to be from that of a
to the following
statement block.
(Details of how to use SERVE blocks and SERVERS.)
Ron Adam
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
I expect there's an obvious reason why this hasn't been suggested
already that I'm not currently thinking of, but here it is anyway. :-)
How about an *extended while* syntax as a block keyword alternative?
Reasoning: The block statement resembles a while block in some ways in
that it is a
Gustavo Niemeyer wrote:
Greetings,
Reasoning: The block statement resembles a while block in some ways in
that it is a conditional block that may be executed only once, or
possibly not at all (or many times). And the word while is also
descriptive of how a block is used.
while VAR1
Eric Nieuwland wrote:
Ron Adam wrote:
Eric Nieuwland wrote:
This is linear. No looping whatsoever. And easily translated to a
simple language construct and a protocol:
class resource(object):
def __init__(self,...):
# store resource parameters
def
Ron Adam wrote:
A minor correction to the Block class due to re-editing.
def __call__(self, *args):
self.block(*args)
self.__del__()
This should have been.
def __call__(self, *args):
try:
self.block(*args)
except Exception, self
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
non-starter; re-read the 200+ messages in the
Nick Coghlan wrote:
Ron Adam wrote:
I agree, re-using or extending 'for' doesn't seem like a good idea to me.
I agree that re-using a straight 'for' loop is out, due to performance and
compatibility issues with applying finalisation semantics to all such
iterative
loops (there's
Nick Coghlan wrote:
Iterating over a sequence. If it's single-pass (and always single pass), you
should use a user defined statement instead.
That's the technique suggested for the single-pass user defined statements.
However, a 'for loop with finalisation' is *still fundamentally an
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Yes, so just do [VAR from] EXPR1:
Regardless of the 'finalization' syntax, I'm talking about the fact that
including extra 'if EXPR' or 'while EXPR' is not going to be an option.
Yes, I meant for the syntax to be the shorter form
A additional comment (or 2) on my previous message before I go back to
lurk mode.
If the recommended use of each resource template is kept to a single
resource, then each enter and exit can be considered a whole block of
code that will either pass or fail. You can then simplify the previous
Reinhold Birkenfeld wrote:
Hello,
I am currently having some thoughts about the standard library, with regard
to Python 2.5 and 3.0. Since I don't want to withhold them from you, here
are they ;)
- Flat namespace: Should we tend to a more hierarchic library (e.g.
inet.url, inet.http,
Bob Ippolito wrote:
On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote:
Ron Adam wrote:
[snip]
Having less in the core distribution means smaller complete
applications
to install when py2exe is used. There also needs to be some assurance
that the standard library has as few bugs
Keith Dart wrote:
On Mon, 20 Jun 2005, Keith Dart wrote:
But then I wouldn't know if it overflowed 32 bits. In my usage, the
integer will be translated to an unsigned (32 bit) integer in another
system (SNMP). I want to know if it will fit, and I want to know early if
there will be a problem,
Nick Coghlan wrote:
Raymond Hettinger wrote:
Whatever term is selected, it should be well thought-out and added to
the glossary. The choice of words will likely have a great effect on
learnability and on how people think about the new tool.
I tried to bring this up on python-list, but I
Raymond Hettinger wrote:
On a separate note, I also propose that __exit__() be renamed to
__leave__(). The enter/leave word pairing are a better fit in standard
English:
I tend to associate leave with leaving, and leaving with arriving.
I didn't even think the __enter__ / __exit__ names
Raymond Hettinger wrote:
Hmm, that got me to thinking a bit more. Here's another subjective two
cents worth. exit seems to be a more global concept and leave seems
more local. For instance, I leave a room but exit a building. In
Python, sys.exit and os._exit are grand exits rather than
Nick Coghlan wrote:
On the other hand 'enter and exit' rolls off the tongue
significantly better than 'enter and leave'
My only concern is enter and exit may be too general. They are
frequently used in other places, although __enter__ and __exit__ are
less common, so maybe it's a non issue.
Raymond Hettinger wrote:
There is no value in expanding a concept to the point of being
meaningless (i.e. meaning whatever you want it to or nothing at all).
Instead, we need a phrase that expresses the essence of the following:
abc = EXPR
exc = (None, None, None)
Michael Hudson wrote:
Ron Adam [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
I even wonder if else-clauses on for/while were a good idea. (The one
on try is definitely a good idea since the use case is quite frequent
and only clumsily handled otherwise; the use cases for else
Thomas Lotze wrote:
Ron Adam [EMAIL PROTECTED] wrote:
3. In a while loop, it's a value test, where the else block gets
executed if the while condition evaluates as false, the while block
may or may not execute. You still need a flag to test for that.
You're effectively arguing for do
Michael Hudson wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
I, as
Guido van Rossum wrote:
On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote:
[several new syntax proposals]
Please stop proposing new syntax. The PEP was accepted after quite
enough back-and-forth; there's no point opening this up yet again.
My apologies Guido.
Subtracting the inappropriate
Raymond Hettinger wrote:
Hey guys, don't give up your bare except clauses so easily.
Yes, Don't give up. I often write code starting with a bare except,
then after it works, stick a raise in it to determine exactly what
exception I'm catching. Then use that to rewrite a more explicit except
Raymond Hettinger wrote:
Looking at sample code transformations shows that the high-power
mxTextTools and re approaches do not simplify code that currently uses
s.find(). In contrast, the proposed partition() method is a joy to use
and has no surprises. The following code transformation
Raymond Hettinger wrote:
[Delaney, Timothy (Tim)]
+1
This is very useful behaviour IMO.
Thanks. It seems to be getting +1s all around.
Wow, a lot of approvals! :)
Have the precise return values of partition() been defined?
+1 on the Name partition, I considered split or parts, but i
Benji York wrote:
Raymond Hettinger wrote:
[Fredrik Lundh]
it is, however, a bit worrying that you end up ignoring one or more
of the values in about 50% of your examples...
It drops to about 25% when you skip the ones that don't care about the
found/not-found field:
! _, sep, port =
Fredrik Lundh wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port = host.partition(':').head
Nick Coghlan wrote:
Ron Adam wrote:
I don't feel there is a need to avoid numbers entirely. In this case I
think it's the better way to find the n'th seperator and since it's an
optional value I feel it doesn't add a lot of complication. Anyway...
It's just a suggestion.
Avoid
Reinhold Birkenfeld wrote:
Greg Ewing wrote:
Charles Cazabon wrote:
Perhaps py3k could have a py2compat module. Importing it could have the
effect of (for instance) putting compile, id, and intern into the global
namespace, making print an alias for writeln,
There's no way importing a
Jim Jewett wrote:
Another real problem with print is that, while the
automatic insertion of spaces is nice for beginners,
it often gets in the way, and what you have to do to
avoid this is pretty nasty: either drop print altogether
in favor of sys.stdout.write(), or use string concatenation
or
Paul Moore wrote:
On 9/2/05, Ron Adam [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
Putting the spaces back in (without a format string) would
be even worse. Charles Cazabon's pointed out that it *could*
be as simple as
writeln(' '.join( ... ))
Why not just offer an addition method
Nick Coghlan wrote:
All,
I put up a Wiki page for the idea of replacing the print statement with an
easier to use builtin:
http://wiki.python.org/moin/PrintAsFunction
Cheers,
Nick.
Looks like a good start, much better than just expressing opinions. :-)
How about making it a class?
Fred L. Drake, Jr. wrote:
It would be good to have more specific guidelines for documentation.
Would it be possible to have each item in the documentation start out by
auto quoting that items __doc__ string?
Then omissions, errors, and contradictions would be easy to find and the
full
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got
Nick Coghlan wrote:
Greg Ewing wrote:
One nice thing about x if b else y is that it
chains without needing any more keywords:
x if b else y if c else z
But if you require parens, it's not so nice:
(x if b else (y if c else z))
If Guido chose this form, I would expect the chaining to
Steven Bethard wrote:
Please no more syntax proposals! There were enough in the PEP. It
looks like most people support a conditional expression of some sort.
We need to leave the syntax to Guido. We've already proved that like
the decorators discussions, we can't as a community agree on a
Greg Ewing wrote:
Ron Adam wrote:
(a if e then b)
((a1 if e1 then b1) if e then b)
(a if e then (a2 if e2 then b2))
((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
Yes of course, thanks for correcting
Antoine Pitrou wrote:
The only problem is that it's not easy to come up with a regex-based
way to transform
C and X or Y
into
X if C else Y
One way is to parse it manually to a list. This was just a test, but
more samples can be added friarly easy.
samples = [
# start, cond,
Delaney, Timothy (Tim) wrote:
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is
Reinhold Birkenfeld wrote:
Greg Ewing wrote:
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a
Nick Coghlan wrote:
Ron Adam wrote:
I wonder if something like the following would fulfill the need?
Funny you should say that. . .
A pre-PEP propsing itertools.iunpack (amongst other things):
http://mail.python.org/pipermail/python-dev/2004-November/050043.html
And the reason
to an accepted value
diff = abs(observed, accepted)
if diff abs_err: return True
try:
return 100 * abs_diff / accepted rel_err
except ZeroDivisionError:
pass
return False
Cheers,
Ron Adam
___
Python-Dev
Greg Ewing wrote:
Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
What would bytes(abc\xf0, latin-1) *mean*?
I'm saying that XXX would be the same encoding
Greg Ewing wrote:
I think you don't understand what an encoding is. Unicode
strings don't *have* an encoding, because theyre not encoded!
Encoding is what happens when you go from a unicode string
to something else.
Ah.. ok, my mental picture was a bit off. I had this reversed somewhat.
Josiah Carlson wrote:
Bob Ippolito [EMAIL PROTECTED] wrote:
On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
Stephen J. Turnbull wrote:
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido - b = bytes(t, enc); t = text(b, enc)
+1 The coding
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Bengt Richter had a good idea with bytes.recode() for strictly bytes
transformations (and the equivalent for text), though it is ambiguous as
to the direction; are we encoding or decoding with bytes.recode
Aahz wrote:
On Sat, Feb 18, 2006, Ron Adam wrote:
I like the bytes.recode() idea a lot. +1
It seems to me it's a far more useful idea than encoding and decoding by
overloading and could do both and more. It has a lot of potential to be
an intermediate step for encoding as well as being
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
[snip]
Again, the problem is ambiguity; what does bytes.recode(something) mean?
Are we encoding _to_ something, or are we decoding _from_ something?
This was just an example of one way that might work, but here
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Except that ambiguates it even further.
Is encodings.tounicode() encoding, or decoding? According to everything
you have said so far, it would be decoding. But if I am decoding binary
data, why should it be spending any time
Bengt Richter wrote:
On Sat, 18 Feb 2006 09:59:38 +0100,
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
Thinking about bytes recently, it occurs to me that bytes are really not
intrinsically
numeric in nature. They don't necessarily represent uint8's. E.g., a binary
Jeremy Hylton wrote:
On 2/21/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
I had to lookup top-post :-).
On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED]
wrote:
Jeremy
Hey, only Guido is allowed to top-post. He said so ;-)
Greg Ewing wrote:
Ron Adam wrote:
Storing byte information as 16 or 32 bits ints could take up a rather
lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than
Terry Reedy wrote:
Greg Ewing [EMAIL PROTECTED] wrote in message
Which is why I think that only *unicode* codings should be
available through the .encode and .decode interface. Or
alternatively there should be something more explicit like
.unicode_encode and .unicode_decode that is thus
logical analysis, it might be of some interest even if
it's reviewing the obvious to those who already know.
(And hopefully I didn't make any really obvious errors myself.)
Stephen J. Turnbull wrote:
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron We could call it transform or translate
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
Nick Coghlan wrote:
All the unicode codecs, on the other hand, use encode to get from characters
to bytes and decode to get from bytes to characters.
So if bytes objects *did* have an encode method, it should still result in a
unicode object, just the same as a decode method does (because
Greg Ewing wrote:
Ron Adam wrote:
While playing around with the example bytes class I noticed code reads
much better when I use methods called tounicode and tostring.
b64ustring = b.tounicode('base64')
b = bytes(b64ustring, 'base64')
I don't like that, because it creates
Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
u = unicode(b)
u = unicode(b, 'utf8')
b = bytes['utf8'](u)
u = unicode['base64'](b) # encoding
b = bytes(u, 'base64') # decoding
u2 = unicode['piglatin'](u1) # encoding
u1 = unicode(u2, 'piglatin') #
Greg Ewing wrote:
Ron Adam wrote:
This uses syntax to determine the direction of encoding. It would be
easier and clearer to just require two arguments or a tuple.
u = unicode(b, 'encode', 'base64')
b = bytes(u, 'decode', 'base64')
The point of the exercise was to avoid
Greg Ewing wrote:
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return
[EMAIL PROTECTED] wrote:
Skip There seem to be other places where Python is beginning to require
Skip parens even though they aren't strictly necessary to resolve
Skip syntactic ambiguity.
Guido In the style guide only, I hope.
Alex Technically, I believe the first
Fredrik Lundh wrote:
Guido van Rossum wrote:
just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR
Raymond Hettinger wrote:
From what I can see, almost everyone wants a switch statement, though perhaps
for different reasons.
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a
Given that variant, my reasons for preferring Option 2 over Option 3 are:
- the semantics are the same at module, class and function level
- the order of execution roughly matches the order of the source code
- it does not cause any surprises when switches are inside conditional logic
Guido van Rossum wrote:
On 6/27/06, Ron Adam [EMAIL PROTECTED] wrote:
I use dict base dispatching in a number of my programs and like it with
the exception I need to first define all the code in functions (or use
lambda) even if they are only one line. So it results in a three step
process
Guido van Rossum wrote:
What was intended probably would be more closely related to constructing
a switch with BASICS gosub command.
I understand now.
But I have a question: if I write
for i in range(10):
switch S:
case i: print 42
(i.e. the switch is *inside* the for
Ron Adam wrote:
In this instance the switch would be redefined 10 times. The ending
switch would be:
switch S:
case 10: print 42
Silly mistake correction... :)
switch S:
case 9: print 42
___
Python-Dev mailing
I believe at least one poster has pointed out that 'once' (if defined
suitably) could be used as a better way to do this:
def index_functions(n):
return [(lambda: once i) for i in range(n)]
But delaying the evaluation of the once argument until the function is
called would break
Christos Georgiou wrote:
I haven't followed the complete discussion about once, but I would assume it
would be used as such:
once name = expression
that is, always an assignment, with the value stored as a cellvar, perhaps,
on first execution 0f the code.
Typically I would use it as:
the pydoc output (or selected parts of it) along with the longer
explanation and discussion. Having pydoc produce xml as an intermediate
format makes these types of things easier to do.
Cheers,
Ron Adam
___
Python-Dev mailing list
Python-Dev
Nick Maclaren wrote:
M.-A. Lemburg [EMAIL PROTECTED] wrote:
You often have a need for controlled rounding when doing
financial calculations or in situations where you want to
compare two floats with a given accuracy, e.g. to work
around rounding problems ;-)
The latter is a crude hack, and
Greg Ewing wrote:
Raymond Hettinger wrote:
-1 on an extra built-in just to save the time for function call
The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has put forward an argument to
Nick Coghlan wrote:
Ron Adam wrote:
Consider an example where you are combining data that had different
number of significant digits. Keeping all the digits of your answer
gives a false since of accuracy. The extra digits are meaningless
because the margin of error is greater than any
M.-A. Lemburg wrote:
Terry Reedy wrote:
Michael Hudson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Michael Chermside [EMAIL PROTECTED] writes:
I'm changing the subject line because I want to convince everyone that
the problem being discussed in the unicode hell thread has
M.-A. Lemburg wrote:
Michael Chermside wrote:
How about we change unicode-vs-str __eq__ to
issue a warning (and return False) instead of raising
UnicodeException?
[... Marc-Andre Lemburg agrees ...]
Great! Now we need someone to volunteer to write a patch (which should
include doc and
Michael Chermside wrote:
Jim Jewett writes:
This change [in docs] looks wrong:
PyDoc_STRVAR(rpartition__doc__,
-S.rpartition(sep) - (head, sep, tail)\n\
+S.rpartition(sep) - (tail, sep, head)\n\
Raymond Hettinger replies:
It is correct. There may be some confusion in terminology. Head
Ron Adam wrote:
Correcting myself...
I hope this discussion is only about the words used and the
documentation and not about the actual order of what is received. I
would expect both the following should be true, and it is the current
behavior.
''.join(s.partition(sep)) - s
Raymond Hettinger wrote:
Another thought is that strings don't really have a left and right.
They have a beginning and end. The left/right or top/bottom distinction
is culture specific.
Well, it should have been epartition() and not rpartition() in that case. ;-)
Is python ever edited
Josiah Carlson wrote:
BJörn Lindqvist [EMAIL PROTECTED] wrote:
If there are rampant criticisms of the Python docs, then those that
are complaining should take specific examples of their complaints to the
sourceforge bug tracker and submit documentation patches for the
relevant sections. And
Nick Coghlan wrote:
Hans Polak wrote:
Hi,
Just an opinion, but many uses of the ‘while true loop’ are instances of
a ‘do loop’. I appreciate the language layout question, so I’ll give you
an alternative:
do:
body
setup code
while
Michael Urman wrote:
On 10/1/06, Ron Adam [EMAIL PROTECTED] wrote:
(I don't think this has been suggested yet.)
while enter_condition, exit_condition:
body
[snip]
Putting both the entry and exit conditions at the top is easier to read.
I agree in principle, but I thought
Nick Coghlan wrote:
Fuzzyman wrote:
Nick Coghlan wrote:
In my example, the 3 sections (setup code, loop body and loop
completion
code are all optional. A basic do-while loop would look like this:
do:
setup code
while condition
(That is, setup code is still
Gregory P. Smith wrote:
I've never liked the .join([]) idiom for string concatenation; in my
opinion it violates the principles Beautiful is better than ugly. and
There should be one-- and preferably only one --obvious way to do it..
(And perhaps several others.) To that end I've submitted
Josiah Carlson wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote:
Ron Adam wrote:
I think what may be missing is a larger set of higher level string
functions
that will work with lists of strings directly. Then lists of strings can
be
thought of as a mutable string type by its use
Nicko van Someren wrote:
On 6 Oct 2006, at 12:37, Ron Adam wrote:
I've never liked the .join([]) idiom for string concatenation; in my
opinion it violates the principles Beautiful is better than ugly. and
There should be one-- and preferably only one --obvious way to do
it..
...
Well I
The only benefit I imagine would be for an extension module library
writer and for users of the struct and array modules. But, other than
that, I don't know. It actually doesn't have to be exposed to Python.
I used Python notation in the PEP to explain what is basically a
C-structure.
.
The still very rough source files can be downloaded from:
http://ronadam.com/dl/_pydoc.zip
There is still much to do, but I think having some experienced feed back on
where it should go is important.
Cheers,
Ron Adam
ps.. Please disregard the website for now, it's purpose was to share
Laurent Gautier wrote:
Ron,
I agree that pydoc could benefit a bit from some cleanup.
As you point it out, the ability to write quick viewers would be
very helpful. I came across that when wanting to develop script
on a remote web server for which I only had FTP access: I ended
up having
Ka-Ping Yee wrote:
Hi Ron and Laurent,
I welcome attempts to improve pydoc (especially since I don't have
much time to work on improving it myself). I definitely agree that
moving to CSS is long overdue, though I would like some input on
the style of the produced pages.
Additional input
Larry Hastings wrote:
Just asking--are you going in a PEP-287-ly way as you work? If not,
would your work make PEP 287 easier to implement?
Pydoc does no reformatting or changes to doc strings. They are displayed as
is in plain text. About the only formatting that is done is to wrap long
Laurent Gautier wrote:
Ron,
Thanks for your detailed answer.
I inserted comments below.
You welcome.
I think any API issues could be worked out. Are there any programs
you know of,
(yours?), that import pydoc besides the python console?
What I did barely qualifies as a hack
Laurent Gautier wrote:
2007/1/6, Ron Adam [EMAIL PROTECTED]:
Laurent Gautier wrote:
[...]
I read your comment about having not too many things changed for 2.6.
(or that will be bumped to 3000).
A suggestion I would have would be to create an html/htmlrender module
in the pydoc-package
Neal Becker wrote:
No time to review this now, but I'd just like to say that the 1 thing I'd
like to see is support for decent mathematical markup. I think at this
point that support for latex markup is the way to achieve this.
There are two separate issues related to this I'd like to point
Laurent Gautier wrote:
2007/1/7, Ron Adam [EMAIL PROTECTED]:
Laurent Gautier wrote:
2007/1/6, Ron Adam [EMAIL PROTECTED]:
[...]
I'd like to know more about using the sandbox, I know it would be easy
for
people to read the source there, but who all can have write access to
it without
Raymond Hettinger wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why would I switch to a bytes type
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to
Georg Brandl wrote:
Martin v. Löwis schrieb:
Anthony Baxter schrieb:
and the wrapper class idea of Nick Coghlan:
attrview(obj)[foo]
This also appeals - partly because it's not magic syntax wink
I also like this. I would like to spell it attrs, and
I think its specification is
class
Martin v. Löwis wrote:
Ron Adam schrieb:
Would it be possible for attrview to be a property?
Sure. It might conflict with a proper name of an attribute, of course.
Something like... (Probably needs more than this to handle all cases.)
class obj(object):
def _attrview(self
Larry Hastings wrote:
Neal Becker wrote:
Instead, bool fails in _the worst possible way_: it silently gives a
_wrong result_.
I disagree with the word fail there; Python is working correctly. The
behavior of converting expressions to a boolean is well-defined:
1 - 100 of 247 matches
Mail list logo
