On Tue, 22 May 2007, Steve Holden wrote:
But doesn't *everyone* now know that documentation contributions don't
have to be marked up? It's certainly been said enough. Maybe that fact
should be more prominent in the documentation? Then we'll just have to
worry about getting people to read it
I fully support the removal of implicit string concatenation
(explicit is better than implicit; there's only one way to do it).
I also fully support the removal of backslashes for line continuation
of statements (same reasons). (I mean this as distinct from line
continuation within a string;
On Sat, 10 Mar 2007, Greg Ewing wrote:
Collin Winter wrote:
Treat dates as if they have a time-part of midnight. This is my preferred
solution, and it is already what the datetime module does, for example,
when subtracting two dates.
Does it really? Seems to me you can pick any time of
On Thu, 4 Jan 2007, Talin wrote:
One issue that needs to be worked out, however, is the division of
responsibility between markup processor and output formatter. Does a
__markup__ plugin do both jobs, or does it just do parsing, and leave
the formatting of output to the appropriate HTML / text
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.
It's probably a good idea to explain how
On Sun, 3 Dec 2006, Fredrik Lundh wrote:
Martin v. Löwis wrote:
Well, the proposal was to interpret m[i] as m.group(i), for all values
of i. I can't see anything confusing with that.
it can quickly become rather confusing if you also interpret m[:] as
m.groups(), not to mention if you add
Wow. Did you catch this news?
http://www-tech.mit.edu/V125/N65/coursevi.html
The first four weeks of C1 will be a lot like the first
four weeks of 6.001, Abelson said. The difference is
that programming will be done in Python and not Scheme.
-- ?!ng
On Mon, 6 Nov 2006, Armin Rigo wrote:
I know it's a discussion that comes up and dies out regularly. My two
cents is that it would be saner to have two separate concepts: cache
files used internally by the interpreter for speed reasons only, and
bytecode files that can be shipped and
Hi Brett,
Here are some comments on your proposal. Sorry this took so long.
I apologize if any of these comments are out of date (but also look
forward to your answers to some of the questions, as they'll help
me understand some more of the details of your proposal). Thanks!
Introduction
On Fri, 4 Aug 2006, Oren Tirosh wrote:
Compatibility with Windows GUIDs may be one of the most important
use cases for the UUID module. It's important to resolve this or users
will have unpleasant surprises. I did.
[...]
alternatives:
1. Default is big endian byte order. Little endian is
as network byte order).
Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC
4122 compliant and have an illegal version field.
[...]
If the correct byte order is used the UUIDs generated by Windows XP
are valid version 4 UUIDs:
I see. I stand corrected, then. My interpretation
On Thu, 3 Aug 2006, Greg Ewing wrote:
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.
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as to make an integer. So
On Fri, 28 Jul 2006, Neal Norwitz wrote:
This only fixes 1 of the 2 failures in test_uuid. The other one is
due to _unixdll_getnode() failing. This is because
_uuid_generate_time is None because we couldn't find it in the uuid
library. This is just broken, not sure if it's the code or the
On Sat, 29 Jul 2006, Neal Norwitz wrote:
I just checked in a change to disable testing 2 uuid functions
(_ifconfig_get_node and unixdll_getnode) that fail on many platforms.
Here's the message:
Disable these tests until they are reliable across platforms. These
problems may mask more
On Wed, 19 Jul 2006, Brett Cannon wrote:
I have decided to go with object-capabilities for
securing interpreters. I have rewritten my design doc from scratch and
deleted the old one. The new doc is named securing_python.txt and can be
found through the svn web interface at
On Thu, 13 Jul 2006, Wolfgang Langner wrote:
On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote:
Things that struck me as peculiar is the old:
if __name__ == __main__:
whatever()
This is so out of tune with the rest of python it becomes a nuisance.
It is not
On Thu, 13 Jul 2006, Greg Ewing wrote:
Would it help if sys were pre-imported into the builtins?
Or do you think that args shouldn't live in sys at all?
I feel like the command-line arguments don't really belong in sys,
and i'd rather not have 'sys' pre-imported into the builtins.
I think of
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the meaning to me. I suspect that
means one's ultimately
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
On Mon, 10 Jul 2006, Jeremy Hylton wrote:
It's a made-up word. You won't find it in the dictionary and the
google define: query
On Sun, 9 Jul 2006, Andrew Koenig wrote:
Sounds reasonable to me. If we're talking py3k I'd chuck global as a
keyword though and replace it with something like outer.
I must say that I don't like outer any more than I like global. The
problem is that in both cases we are selecting the
On Fri, 7 Jul 2006, Guido van Rossum wrote:
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of a side
On Fri, 7 Jul 2006, Talin wrote:
While I was typing this, I did realize a drawback to poisoned objects,
which I will illustrate by the following example:
Suppose we want to grant to the sandboxed program permission to read and
write cofiguration properties. We don't want to give them
After reading the messages on this thread i'm starting to think
that it would be good to clarify what kinds of threats we are
trying to defend against, and specify what invariants we are
intending to preserve.
For example, here are a few things Brett mentioned:
Right. I am thinking more of an
On Wed, 21 Jun 2006, Brett Cannon wrote:
I have been working on a design doc for restricted execution of Python
as part of my dissertation for getting Python into Firefox to replace
JavaScript on the web.
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a few
On Thu, 6 Jul 2006, Phillip J. Eby wrote:
As much as I'd love to have the nested scope feature, I think it's only
right to point out that the above can be rewritten as something like this
in Python 2.5:
def spam():
local_A = do_work()
result_1 = yield
On Wed, 5 Jul 2006, Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Using the classic nonsense example:
def counter(num):
def inc():
.num += 1
return .num
return inc
Would this also use ..num to refer to
On Wed, 5 Jul 2006, Brett Cannon wrote:
On 7/4/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
In response to Guido's comment about confusing the words trusted and
untrusted, how about empowered and restricted?
Maybe. I am really starting to lean towards trusted and sandboxed.
It can be risky
Hi Brett,
Here are some comments on the description of the restricted execution
model that you posted.
When referring to the state of an interpreter, it is either trusted or
untrusted. A trusted interpreter has no restrictions imposed upon any
resource. An untrusted interpreter has at least
On Sat, 1 Jul 2006, Andrew Koenig wrote:
I'd rather see a simpler rule: = never defines a variable in a surrounding
scope. If you want to affect the binding of such a variable, you have to
define it explicitly in the scope in which you want it.
Example:
x = 42
def f():
On Sat, 1 Jul 2006, Greg Ewing wrote:
I don't disagree with anything you said, but I think it
would be a good idea to avoid using phrases like proper
lexical scopes, which is likely to set people off on
a tangent. The issue isn't lexicality, it's writeability.
Fully functional lexical scopes,
On Fri, 30 Jun 2006, Andrew Koenig wrote:
I saw messages out of sequence and did not realize that this would be a
change in behavior from 2.4. Sigh.
Yes, this is not a good time to change it.
I hope Py3000 has lexical scoping a la Scheme...
Me too -- that would be really nice.
-- ?!ng
On Fri, 30 Jun 2006, Brett Cannon wrote:
On 6/30/06, Armin Rigo [EMAIL PROTECTED] wrote:
object.__subclasses__()
[..., type 'file']
Maybe this one won't work if __subclasses__ is forbidden, but in general
I think there *will* be a way to find this object.
Yeah, that's been my
On Fri, 30 Jun 2006, Guido van Rossum wrote:
On 6/30/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Fri, 30 Jun 2006, Andrew Koenig wrote:
I hope Py3000 has lexical scoping a la Scheme...
Me too -- that would be really nice.
That's not a very constructive proposal (especially since I
On Fri, 30 Jun 2006, Andrew Koenig wrote:
The fundamental principle is that the binding of every name is determined
during compilation, not during execution. This property does not quite
apply to Python at present.
I think this property does apply. In your example:
def g():
On Tue, 27 Jun 2006, Jim Jewett wrote:
(Almost) everyone agrees that the case expressions SHOULD be run-time
constants. The disagreements are largely over what to do when this
gets violated.
I like your summary and understood most of it (options 1, 2, 3, 5, 6).
The only part i didn't
On Mon, 26 Jun 2006, Guido van Rossum wrote:
I've written a new PEP, summarizing (my reaction to) the recent
discussion on adding a switch statement. While I have my preferences,
I'm trying to do various alternatives justice in the descriptions.
Thanks for writing this up!
The section that
On Mon, 26 Jun 2006, Guido van Rossum wrote:
Can you please edit the PEP yourself to add this? That will be most efficient.
I've done so, and tried to clarify the next line to match (see below).
With school I, if you want to
optimize using a hash table (as in PEP 275 Solution 1) you have to
On Mon, 26 Jun 2006, Guido van Rossum wrote:
Most school I proponents (perhaps you're the only exception) have
claimed that optimization is desirable, but added that it would be
easy to add hash-based optimization. IMO it's not so easy in the light
of various failure modes of hash(). (A
Here's a possible adjustment to the School-II approach that i think
avoids the issues i've been raising, while giving the desired
O(n)-to-O(1) speedup in common situations. It's basically School-II
dispatch, plus a check:
On compilation, freeze any cases that meet the School-II conditions
and
On Sat, 24 Jun 2006, Raymond Hettinger wrote:
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 case statement, and 3) handling overlapping cases.
Here's a simple approach that will
On Sat, 24 Jun 2006, Phillip J. Eby wrote:
At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
Cases values must be ints, strings, or tuples of ints or strings.
-1. There is no reason to restrict the types in this fashion. Even if you
were trying to ensure marshallability, you could still
On Sun, 25 Jun 2006, Guido van Rossum wrote:
In your eagerness to
rule out surprises, you're creating the biggest surprise of all: the
restriction to literals is certainly a surprise!
I disagree. Perhaps what we mean by surprise is different. In
Raymond's design, there is a simple rule for
On Mon, 26 Jun 2006, Georg Brandl wrote:
Raymond Hettinger wrote:
five = 5
eight = [8]
def f(x, six=6):
seven = 7
a = static(five + 4)# this is legal
b = static(six + 4) # this is illegal
c = static(seven + 4) # this is
On Sun, 25 Jun 2006, Guido van Rossum wrote:
What do you think of Nick C's 'once'?
It's a bit closer to the right meaning... but what about:
def f(x):
def g(y):
return y + once x
return g
Does once mean not really once here, but once for each new function
object
On Fri, 23 Jun 2006, Josiah Carlson wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct.
This doesn't make sense as a rule.
Consider:
If x.y ends up functionally identical to getattr(x, 'y'),
then
On Wed, 21 Jun 2006, Guido van Rossum wrote:
I worry (a bit) about this case:
y = 12
def foo(x, y):
switch x:
case y: print something
which to the untrained observer (I care about untrained readers much
more than about untrained writers!) looks like it would print
something
On Wed, 21 Jun 2006, Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
I don't think switch-for-efficiency (at least if efficiency is the
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases for
switch x:
case 3: foo(x)
case is y:
On Mon, 19 Jun 2006, Josiah Carlson wrote:
I personally don't find switch/case statements to be significantly (if
at all) easier to read than if/elif/else chains, but that is subjective,
and I note that Ka-Ping finds switch/case to be significantly easier to
read.
Uh, i didn't mean to say
On Mon, 19 Jun 2006, Guido van Rossum wrote:
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that a switch should only exist
On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
As for the comment: It apparently *is* misleading, George mistakenly
took it as a requirement for future changes, rather than a factual
statement about the present (even though it uses the tense of simple
present). Anybody breaking 2.3
On Mon, 19 Jun 2006, Guido van Rossum wrote:
If you want to encourage people to use your module
with older versions, the right path is to have a distribution (can be
very light-weight) on your own website and add it to PyPI
Okay, i've removed the comment and submitted the package to PyPI.
--
On Sun, 18 Jun 2006, George Yoshida wrote:
uuid.py says in its docstring:
This module works with Python 2.3 or higher.
And my question is:
Do we plan to make it 2.3 compatible in future releases?
If so, uuid needs to be listed in PEP 291.
Otherwise, the comment is misleading.
The
On Sun, 11 Jun 2006, Giovanni Bajo wrote:
Some comments on the code:
for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
Can we get rid of these absolute paths? Something like this should suffice:
from ctypes import *
buf = create_string_buffer(4096)
On Sun, 11 Jun 2006, Phillip J. Eby wrote:
At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
I've added code to make uuid1() use uuid_generate_time() if available
and uuid4() use uuid_generate_random() if available. These functions
are provided on Mac OS X (in libc) and on Linux (in libuuid
On Mon, 12 Jun 2006, Giovanni Bajo wrote:
GetSystemDirectory() is the official way to find the system directory.
You're right. I've added a call to GetSystemDirectory, with a fallback
to the usual locations if it doesn't work.
Another thing that you might do is to drop those absolute system
Thomas Heller wrote:
I don't know if this is the uuidgen you're talking about, but
on linux there is libuuid:
Thanks!
Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py .
Phillip J. Eby wrote:
By the way, I'd love to see a uuid.uuid() constructor that simply calls the
I did this earlier:
hex(9)
'0x9184e729fffL'
and found it a little jarring, because i feel there's been a general
trend toward getting rid of the 'L' suffix in Python.
Literal long integers don't need an L anymore; they're automatically
made into longs if the number is too
On Sat, 10 Jun 2006, Greg Ewing wrote:
I'm having trouble seeing a real use for a 0D array as
something distinct from a scalar, as opposed to them
just being an oddity that happens to arise as a side
effect of the way Numeric/Numpy are implemented.
I think the whole discussion about the
Okay. I have done as Fredrik suggested:
6. Combine 2 and 3: require the user to pass in a MAC argument
to uuid1, but provide a SlowGetMacAddress helper that wraps
the existing code.
I agree with Thomas Wouters:
That sounds like the right thing to do, although I
On Sat, 10 Jun 2006, Mike Brown wrote:
I have a couple of suggestions for improving that implementation:
1. You're currently using os.urandom, which can raise a NotImplementedError.
You should be prepared to fall back on a different PRNG...
The latest version (http://zesty.ca/python/uuid.py)
On Thu, 8 Jun 2006, Neal Norwitz wrote:
If you plan to make a checkin adding a feature (even a simple one),
you oughta let people know by responding to this message. Please get
the bug fixes in ASAP. Remember to add tests!
Just to make this appear on this thread: i'm planning to check in
the
Hi Thomas,
This does not work, for several reasons.
1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you
cannot slice:
You're right. The PEAK code must have been based on an earlier
version of the CreateGuid() routine.
I've fixed this, and added detection of the UUID
On Sat, 10 Jun 2006, Thomas Heller wrote:
I have not tested the speed, but extending my snippet to also work
on 98 should be nearly trivial:
try:
_func = windll.rpcrt4.UuidCreateSequential
except AttributeError:
_func = windll.rpcrt4.UuidCreate
def CreateGuid():
uuid = UUID()
On Sat, 10 Jun 2006, Paul Moore wrote:
Actually, the code uses ifconfig, which doesn't exist on Windows.
You want the command ipconfig /all.
I fixed that before you posted this message. :)
-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
Quite a few people have expressed interest in having UUID
functionality in the standard library, and previously on this
list some suggested possibly using the uuid.py module i wrote:
http://zesty.ca/python/uuid.py
This module provides a UUID class, functions for generating
version 1, 3, 4,
Hi folks. I had been planning to attend PyCon this year and was really
looking forward to it, but i need to cancel. I am sorry that i won't
be getting to see you all in a couple of weeks.
If you know anyone who hasn't yet registered but wants to go, please
contact me -- we can transfer my
On Sun, 15 Jan 2006, Georg Brandl wrote:
does Python have an official icon? Not py.ico from PC/, that's a bit
ugly and does not scale. Has no designerhead ever done such a thing?
There have been a couple of proposed logos -- i found some images
at http://www.pythonology.com/logos -- but i don't
On Fri, 30 Dec 2005, Reinhold Birkenfeld wrote:
Ka-Ping Yee wrote:
Constants in all caps:
NONE, TRUE, FALSE, ELLIPSIS
That's ugly.
I know it looks ugly to you now. But there's a good reason why we use
capitalization for class names -- anyone reading code who comes across
Brett Cannon wrote:
I am fine with changing the built-in types, but changing the built-in
singletons just looks *really* odd to me. So odd that I just don't
want to see them changed. I mean when I think of constants, I think
of a variable that references an object and that reference never
On Fri, 30 Dec 2005, Martin v. Löwis wrote:
Ka-Ping Yee wrote:
That would be cool. If so, it would make sense for them to be all in
lowercase.
And rename None to null in the process :-)
Is there a really good reason to do that? It's not obvious to me.
-- ?!ng
On Fri, 30 Dec 2005, Fred L. Drake, Jr. wrote:
On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
Is there a really good reason to do that? It's not obvious to me.
No more than there is to rename None to none or NONE.
For that, there is a reason: None is not a class.
-- ?!ng
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the question for Python 2.*, but
it would be nice to keep these in mind for Python 3K.
Constants in all caps:
NONE,
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin. So why not do that?
I see two options. Either:
(a) Simply let __builtins__.exit = sys.exit. Then we get:
exit
built-in function exit
which may be enough of a clue
On Wed, 28 Dec 2005, Fredrik Lundh wrote:
Ka-Ping Yee wrote
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin.
no, what's being proposed is what the subject says: a quit/exit command
that actually quits, instead of printing a you didn't say
Would there be any interest in extending the compiler package with tools
for AST transformations and for emitting Python source code from ASTs?
I was experimenting with possible translations for exception chaining
and wanted to run some automated tests, so i started playing around
with the
On Sat, 21 May 2005, James Y Knight wrote:
On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
This only helps if you can get to a debugger. What if you're
reading your web server's error log?
Then you're in trouble anyways because you need the contents of some
local to figure out what's
Guido van Rossum wrote:
Do we really need both __context__ and __cause__?
Well, it depends whose needs we're trying to meet.
If we want to satisfy those who have been asking for chaining
of unexpected secondary exceptions, then we have to provide that
on some attribute.
If we also want to
On Thu, 19 May 2005, Nick Coghlan wrote:
With PEP 344, this could simply be:
try:
parser.parseFile(file)
exeption Exception, exception:
raise type(exception)(Error at line %s in file %s % (x,y))
Only if we also made all exceptions new-style classes.
That's just a minor
This PEP is a concrete proposal for exception chaining, to follow
up on its mention here on Python-Dev last week as well as earlier
discussions in the past year or two.
http://www.python.org/peps/pep-0344.html
I've tried to summarize the applications for chaining mentioned in
these
On Sun, 15 May 2005, Shane Hathaway wrote:
You might add to the PEP the following example, which could really
improve the process of building GUIs in Python:
class MyFrame(Frame):
def __init__(self):
with Panel():
with VerticalBoxSizer():
On Wed, 11 May 2005, Guido van Rossum wrote:
[Steven Bethard]
exc = ()
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
stmt_exit(*exc)
would this make any of the examples impossible to write? All you have
to
- Ka-ping Yee thinks we need separate entry points for the exceptional
and the normal termination case. I disagree; this would end up in
unnecessary duplication of code (or boilerplate to equate the two
methods) in most cases. The whole *point* is that finally gets to
do its clean
Here's another use case to think about.
Example 2: Replacing a File.
Suppose we want to reliably replace a file. We require that either:
(a) The file is completely replaced with the new contents;
or (b) the filesystem is unchanged and a meaningful exception is thrown.
We'd like to be
On Thu, 12 May 2005, Guido van Rossum wrote:
[Ka-Ping Yee]
Example 1: Exception Chaining.
As has been previously discussed, the information from an exception can
be lost when the handling of the exception runs into a problem. It is
often helpful to preserve the original reason
It occurred to me as i was messing around with handling and re-raising
exceptions that tossing around these (type, value, traceback) triples
is irritating and error-prone.
How about just passing around a single value? All we'd have to do is
put the traceback in value.traceback.
Implementation:
Suppose exceptions have an optional context attribute, which is
set when the exception is raised in the context of handling another
exception. Thus:
def a():
try:
raise AError
except:
raise BError
yields an exception which is an instance of BError.
On Thu, 12 May 2005, Guido van Rossum wrote:
Define raise. Does that involve a raise statement?
Not necessarily; it could be a raise statement or an inadvertently
triggered exception, such as in the example code i posted.
What about 1/0?
That counts.
What if you call a method that executes
On Thu, 12 May 2005, Brett C. wrote:
whether bare 'except' statements should go or only catch certain exceptions.
Maybe bare 'except' should be spelled 'except *'.
I don't think it can be removed altogether because sometimes you just
need to be able to do magic, but it can be made a little more
On Thu, 12 May 2005, Guido van Rossum wrote:
How is except: less greppable?
Duh. I'm slow today.
-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, 6 May 2005, Guido van Rossum wrote:
There's one alternative possible (still orthogonal to PEP 340):
instead of __next__(), we could add an optional argument to the next()
method, and forget about the next() built-in.
I prefer your original proposal. I think this is a good time to
On Thu, 5 May 2005, Delaney, Timothy C (Timothy) wrote:
Aahz wrote:
My standard workaround is using exceptions, but I'm not sure how that
interacts with a block:
try:
for name in filenames:
with opened(name) as f:
if f.read(2) == 0xFEB0:
On Wed, 4 May 2005, Shane Hathaway wrote:
I'd like to suggest a small language enhancement that would fix this
example. Allow the break and continue statements to use a keyword,
either for or while, to state that the code should break out of both
the block statement and the innermost for or
Reinhold Birkenfeld wrote:
There is one problem with using no keyword: You cannot use arbitrary
expressions in the new statement.
[...]
resource = opening(file.txt)
resource:
(...)
The latter would have to be forbidden.
Noam Raphael wrote:
Can you explain why it would have to be
On Fri, 29 Apr 2005, Phillip J. Eby wrote:
At 08:21 PM 4/29/05 -0500, Ka-Ping Yee wrote:
All the statements in Python are associated with keywords, except
for assignment, which is simple and extremely common. I don't
think the block statement is simple enough or common enough for
that; its
On Fri, 29 Apr 2005, Guido van Rossum wrote:
The more I think about it the more I like having no keyword at all
(see other messages).
I hope you'll reconsider this. I really think introducing a new
statement requires a keyword, for pedagogical reasons as well as
readability and consistency.
On Thu, 28 Apr 2005, Greg Ewing wrote:
If such an explanation can't be found, I strongly suspect
that this doesn't correspond to a cohesive enough concept
to be made into a built-in language feature. If you can't
give a short, understandable explanation of it, then it's
probably a bad idea.
On Thu, 21 Apr 2005, Guido van Rossum wrote:
Perhaps it could be even simpler:
[assignment_target '=']* expr ':' suite
This would just be an extension of the regular assignment statement.
It sounds like you are very close to simply translating
expression... function_call(args):
I hope you will not mind too much if I ask a small favor. Sorry
for this off-topic post.
I am working on a new design for displaying online conversations.
(Some of you saw this at PyCon.) I'm conducting a short survey to
gather some opinions on the current design.
If you have just a few
On Sun, 10 Apr 2005, Eyal Lotem wrote:
It may be really hard to get it right, unless we are overlooking some simple
solution.
To get it right, you at least need to know exactly what your
operators mean. I messed up because i failed to realize that
'==' can be redefined, and 'in' depends on
1 - 100 of 105 matches
Mail list logo
