Tim Peters wrote:
> [Reinhold Birkenfeld]
>> Recently, someone on dclpy posted about an error he got
>> when he tried to unpack the Python distribution tarball
>> with Sparc Solaris 9's tar:
>>
>> tar: directory checksum error
>>
>> With GNU tar
Recently, someone on dclpy posted about an error he got
when he tried to unpack the Python distribution tarball
with Sparc Solaris 9's tar:
tar: directory checksum error
With GNU tar, it worked correctly.
Is this a known issue, or is it irrelevant?
Reinhold
--
Mail address is perfectly valid!
Ka-Ping Yee wrote:
> 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
Fredrik Lundh wrote:
> Walter Dörwald wrote:
>
>> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
>> sys.inputhook gets passed each line entered and may return True if it has
>> processed the line inself and False if normal handling of the input should be
>> done. This all
[EMAIL PROTECTED] wrote:
> Fredrik> a quit/exit command that actually quits, instead of printing a
> Fredrik> "you didn't say please!" message.
>
> I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't
> occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EO
Fredrik Lundh wrote:
> Reinhold Birkenfeld wrote:
>
>> What is wrong with something like this:
>>
>> >>> class Quitter:
>> ... def __repr__(self): raise SystemExit
>> ...
>> >>> exit = quit = Quitter()
>
>>>> vars() #
Fredrik Lundh wrote:
> sourceforge just went off the air, so I'm posting this patch here, in order
> to distract you all from Christian's deque thread.
>
> this silly little patch changes the behaviour of the interpreter so that
> "quit"
> and "exit" actually exits the interpreter. it does this
Armin Rigo wrote:
> Hi Facundo,
>
> On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
>> >>> d += 1.2
>> >>> d
>> NotImplemented
>
> The situation appears to be a mess. Some combinations of specific
> operators fail to convert NotImplemented to a TypeError, depending on
> old- or
Robey Pointer wrote:
> On 22 Dec 2005, at 3:51, Michael Hudson wrote:
>
>> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>
>>> Checked the python-list archives lately? If you google c.l.python
>>> for the
>>> word "documentation", you'll find recent megathreads with subjects
>>> like
>>> "bitc
Martin v. Löwis wrote:
> Propose first. I have the feeling that the feature will change forth
> and back if everybody gets to say something. I would call it
> sys.svnversion (because that's what it is).
Perhaps it could make sense for sys.svnversion to exist only in a debug
build. This way people
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.
>>>
>>>Actually
Guido van Rossum wrote:
> Has this been handled yet? If not, perhaps showing the good and bad
> bytecode here would help trigger someone's brain into understanding
> the problem.
I've created a tracker item at www.python.org/sf/1370322.
Reinhold
--
Mail address is perfectly valid!
Hi,
don't know if this is known here, but it seems we have quite a long way to go:
http://kuerzer.de/python3
Reinhold
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
Hi,
on my machine, "make test" hangs at test_colorsys.
Careful investigation shows that when the bytecode is freshly generated
by "make all" (precisely in test___all__) the .pyc file is different from what a
direct call to "regrtest.py test_colorsys" produces.
Curiously, a call to "regrtest.py t
Raymond Hettinger wrote:
> [Martin Blais]
>> > I'm always--literally every time-- looking for a more functional
> form,
>> > something that would be like this:
>> >
>> ># apply dirname() 3 times on its results, initializing with p
>> >... = repapply(dirname, 3, p)
>
> [Greg Ewing]
>> Maybe
Michele Simionato wrote:
> As other explained, the syntax would not work for functions (and it is
> not intended to).
> A possible use case I had in mind is to define inlined modules to be
> used as bunches
> of attributes. For instance, I could define a module as
>
> module m():
> a = 1
>
Martin Blais wrote:
> On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>>
>> > How hard would that be to implement?
>>
>> import sys
>> reload(sys)
>> sys.setdefaultencoding('undefined')
>
> Hmmm any particular reason for the call to reload() here?
Sokolov Yura wrote:
> May be allow modules to define __getattr__ ?
>
> def __getattr__(thing):
> try:
> return __some_standart_way__(thing)
> except AttributeError:
> if thing=="Queue":
>import sys
>from Queue import Queue
>
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 list.
>
Martin v. Löwis wrote:
> Reinhold Birkenfeld wrote:
>> One problem is that no Unicode escapes can be used since compiling
>> the file raises ValueErrors for them. Such strings would have to
>> be produced using unichr().
>
> You mean, in Unicode literals? There are va
Hi,
I looked whether I could make the test suite pass again
when compiled with --disable-unicode.
One problem is that no Unicode escapes can be used since compiling
the file raises ValueErrors for them. Such strings would have to
be produced using unichr().
Is this the right way? Or is disabling
Phillip J. Eby wrote:
>>A case where this matters is here: http://python.org/sf/1306777
>
> I've closed it as invalid; the behavior is as-defined.
>
> In principle, there *could* be an optimization to avoid rebinding the
> lvalue in the case where the __i*__ form did return self. But using it
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |= set([1])
Do we want lst.__setitem__ to be called in the second inplac
Sokolov Yura wrote:
> Sorry for looking in every hole.
> Just a suggestion.
>
> A= condition and first or second
> problem is in case when first in (None,0,[],"").
> May be invent new operator 'take'.
> take - returns right operator when left evals to True and stops
> computing condidtional expr
Anthony Baxter wrote:
> Starting in about 11 hours time, the release24-maint branch is FROZEN
> for the 2.4.2c1 release. The freeze will last for around a day, and
> then we're in a state of mostly-frozen for another week, until 2.4.2
> (final). During that week, please don't check things into t
Jason Orendorff wrote:
> Honestly, I think I would prefer this syntax. Examples from real
> code, before and after:
>
> lines = [line for line in pr.block.body
> if line.logical_line.strip() != '']
> lines = [for line in pr.block.body:
> if line.logical_line
Guido van Rossum wrote:
> Given this realization, I'm now -1 on Raymond's idea, and +1 on adding
> a conditional expression. I believe (y if x else z) was my favorite
> last time, wasn't it? I've changed the subject accordingly.
As the PEP states, I'm not sure if changing the customary order of "
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.
No, please not. It's useful sometimes and doesn't hurt most times.
> 1) The construct can be error-prone. When an
Neal Norwitz wrote:
> I ran 2.4.x through valgrind and found two small problems on Linux
> that have been fixed. There may be some other issues which could
> benefit from more eyes (small, probably one time memory leaks). The
> entire run is here:
>
> http://python.org/valgrind-2.4.2.out
>
> (I
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> This last patch includes a new exception, are you sure that this can
> be
>> safely backported?
>
> Not too worried about it. Better to have the exception reported than
> the silent failure that confused the heck o
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892
>
> Modified Files:
> Tag: release24-maint
> urllib.py
> Log Message:
> Sync-up with patches to the head.
> Includes SF 1016880: urllib.urlretrieve si
nality of "dedenting" a block that it's better to keep it as
> Python source code.
>
> On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> some time ago, I proposed a string method "dedent" (which currently is in t
Hi,
some time ago, I proposed a string method "dedent" (which currently is in the
textwrap module). The RFE is at http://python.org/sf/1237680.
Any opinions? If I don't get positive comments, I'll reject it.
Reinhold
--
Mail address is perfectly valid!
e is argument for the call site but parameter for the
> function/method definition. So you can't just count occurrences.
>
> On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> looking at bug #1283289, I saw that the term "keyword parame
Hi,
looking at bug #1283289, I saw that the term "keyword parameter" is used in
Python/getargs.c, mixed with "keyword argument".
Grepping through the source, "keyword parameter" had 43 matches, while
"keyword argument" had 430. Should the "parameter" form be extinguished?
Reinhold
(And BTW, sho
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> This code doesn't really work in general. It assumes that any append
>> function call is a list method, which is obviously invalid. But if a
>> variable is known to be a list (ie, local and assigned as list
>> (BUILD_LIST) or a list comprehension),
Brett Cannon wrote:
> On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
>> [finding Tools/i18n/pygettext.py]
>> > You're right, I think Tools is probably a bad place for
>> > anything. If it's not part of the stdlib, I'll likely never
>> > find it.
>>
>> Agreed. Maybe with the introduction of -m
Raymond Hettinger wrote:
>> Do we really need writef()? It seems to be not much better than its %-
>> formatting
>> equivalent.
>
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if only because of
> precedence issue
,
>
> [Greg Ewing]
>> > There's no way importing a module could add something that
>> > works like the old print statement, unless some serious
>> > magic is going on...
>
> [Reinhold Birkenfeld]
>> You'd have to enclose print arguments in paren
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 module could add som
Bill Janssen wrote:
>> >(*) Regular Expressions
>>
>> This can be orthogonally added to the 're' module, and definitely should
>> not be part of the string method.
>
> Sounds right to me, and it *should* be orthogonally added to the 're'
> module coincidentally simultaneously with the change
A.B., Khalid wrote:
>>>#--- Python 2.4.1 from CVS -#
[test_bz2]
>>>RuntimeError: wrong sequence of bz2 library commands used
>>
>>I don't understand this. The sources for the bz2 modules are exactly equal
>>in both branches.
>
> I know. Even the tests are e
Raymond Hettinger wrote:
> [Martin]
>> For another example, file.read() returns an empty string at EOF.
>
> When my turn comes for making 3.0 proposals, I'm going to recommend
> nixing the "empty string at EOF" API. That is a carry-over from C that
> made some sense before there were iterators.
A.B., Khalid wrote:
> #--- Python 2.5a0 from CVS -#
> # Result: passes
> $ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
>
>
> #--- Python 2.4.1 from CVS -#
> # Result: fails
> $ /g/projs/py24/python/dist/src
Bill Janssen wrote:
>> There are basically two ways for a system, such as a
>> Python function, to indicate 'I cannot give a normal response." One (1a)
>> is to give an inband signal that is like a normal response except that it
>> is not (str.find returing -1). A variation (1b) is to give an
Tim Peters wrote:
> [EMAIL PROTECTED]
>> Update of /cvsroot/python/python/dist/src/Lib/test
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test
>>
>> Modified Files:
>>test_bz2.py
>> Log Message:
>> Add list() around xreadlines()
>>
>>
>>
>> Index: test_bz2.py
>>
A.B., Khalid wrote:
> Hello there,
>
>
> The release24-maint check-ins for today contained this typo:
>
> ===
> RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
> retrieving revision 2.29
> retrieving revision 2.29.4.1
Raymond Hettinger wrote:
>> Deprecation means your code will still work I hope every book that
>> documents "except:" also adds "but don't use this except under very
>> special circumstances".
>>
>> I think you're overreacting (again), Raymond. 3.0 will be much more
>> successful if we can introdu
Hi,
after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder
whether the Tools directory is documented at all. There are many useful
scripts there which many people will not find if they are not listed
anywhere in the docs.
Just a thought.
Reinhold
--
Mail address is perfectly
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
> @@ -114,7 +114,7 @@
> programs, or to test functions during bottom-up program development.
> It is also a handy desk calculator.
>
> -Python allows writing very compact and readable programs. Programs
> +Python enables programs to wri
Christian Robottom Reis wrote:
> In Launchpad (mainly because SQLObject is used) we end up with quite a
> few locals named id. Apart from the fact that naturally clobbering
> builtins is a bad idea, we get quite a few warnings when linting
> throughout the codebase. I've fixed these as I've found t
Guido van Rossum wrote:
> The main problem for a smooth Unicode transition remains I/O, in my
> opinion; I'd like to see a PEP describing a way to attach an encoding
> to text files, and a way to decide on a default encoding for stdin,
> stdout, stderr.
FWIW, I've already drafted a patch for the
Raymond Hettinger wrote:
> 2. There is a lesson to be taken from a story in the ACM risks forum
> where a massive phone outage was traced to a single line of C code that
> ran a "break" to get out of a nested if-statement. The interesting part
> is that this was known to be mission critical code
Reinhold Birkenfeld wrote:
> Ruslan Spivak wrote:
>> Hello.
>>
>> I was reading source code for bltinmodule.c and found probably erroneus
>> stuff in filter function. I'm newbie to python inners and don't know if
>> attached code is worth for a pat
Ruslan Spivak wrote:
> Hello.
>
> I was reading source code for bltinmodule.c and found probably erroneus
> stuff in filter function. I'm newbie to python inners and don't know if
> attached code is worth for a patch submission.
>
> I would appreciate if someone could take a look at it and if it'
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
>
> Modified Files:
> emailutil.tex
> Log Message:
> Note that usegmt is new in 2.4. Closes #1239681.
>
>
> Index: emailutil.tex
> ==
Reinhold Birkenfeld wrote:
> Hi,
>
> while bugs and patches are sometimes tricky to close, RFE can be very easy
> to decide whether to implement in the first place. So what about working a
> bit on this front? Here are several RFE reviewed, perhaps some can be
> closed ("
Hi,
to whom it may concern:
the Python package on PyPI is at version 2.3.2.
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
M.-A. Lemburg wrote:
> Reinhold Birkenfeld wrote:
>> Hi,
>>
>> would anyone care to comment about this patch of mine --
>> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
>>
>> It makes file.encoding read-writ
Hi,
would anyone care to comment about this patch of mine --
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
It makes file.encoding read-write and lets the write() and writelines() methods
obey it.
Reinhold
--
Mail address is perfectly valid!
__
Terry Reedy wrote:
> "Andrew Durdin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Very likely. But given the number of times that similar proposals have
>> been put forth in the past, it is reasonable to expect that they will
>> be brought up again in the future by others, if t
Guido van Rossum wrote:
> On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>> I have written a patch that changes the way triple-quoted strings are
>> scanned so that leading whitespace is ignored in much the same way
>> that pep 257 handles it for docstrings. Largely this was for a
>> learning
Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the m
Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>with sys.trace
>
> Note that it's currently not possible to inspect the trace/profile hooks
> from Python code, only from C, so that might be, um, interesting to implement.
That w
Hi,
I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context man
Paul Moore wrote:
> On 7/6/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
>> Paul Moore writes:
>> > I also like the fact that it offers a neat 1-word name for the
>> > generator decorator, "@context".
>>
>> Well, ok... does anyone *else* agree? I too saw this and thought "neat!
>> a simple one-
Nick Coghlan wrote:
[...]
> If the right hand side of 'as' permitted the same forms as are going
> to be permitted for the 'as' clause in 'with' statements, then Ralf's
> situation could be handled via:
>
>def __init__(self as s, x as s.x, y as s.y, z as s.z):
> pass
>
> Essentially
Michael Hoffman wrote:
> On Wed, 29 Jun 2005, Tony Meyer wrote:
>
>> Maybe this has already been answered somewhere (although I don't
>> recall seeing it, and it's not in the sourceforge tracker) but has
>> anyone asked Jason Orendorff what his opinion about this (including
>> the module in the st
Phillip J. Eby wrote:
> At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
>>os.getcwd() returns a string, but path.getcwd() returns a new path
>>object.
>
> In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
> constructor classmethod by analogy with 'dict.fromkeys()' or
Michael Hoffman wrote:
> On Sun, 26 Jun 2005, Phillip J. Eby wrote:
>
>> At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
>>> On Sun, 26 Jun 2005, Phillip J. Eby wrote:
>>>
* drop getcwd(); it makes no sense on a path instance
>>>
>>> Personally I use path.getcwd() as a class method all th
Tim Peters wrote:
> [EMAIL PROTECTED]
>> Update of /cvsroot/python/python/dist/src/Lib
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib
>>
>> Modified Files:
>>Cookie.py
>> Log Message:
>> bug [ 1108948 ] Cookie.py produces invalid code
[...]
> I assume this accounts for
Phillip J. Eby wrote:
> At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
>>1226256:
>>The "path" module by Jason Orendorff should be in the standard library.
>>http://www.jorendorff.com/articles/python/path/
>>Review: the module is great and seems
Hi,
while bugs and patches are sometimes tricky to close, RFE can be very easy
to decide whether to implement in the first place. So what about working a
bit on this front? Here are several RFE reviewed, perhaps some can be
closed ("should" is always from submitter's point of view):
1193128:
str.
Kay Schluehr wrote:
> Reinhold Birkenfeld wrote:
>
>>>
>>>lambda x,y: x+y*y
>>>lambda x,y: y**2+x
>>>
>>> are essentialy the same functions with different implementations [1].
>>
>>
>> Exce
Kay Schluehr wrote:
> Reduction provides often the advantage to make expressions/statements
> scriptable what they are not in Python. Python is strong in scripting
> classes/objects ( a big plus of the language ) but you can't simply use
> the language to prove that
>
> lambda
Fernando Perez wrote:
> Skip Montanaro wrote:
>
>> I wouldn't mind a stdlib that defined a set of top-level packages (some of
>> which might be wholly unpopulated by modules in the standard distribution)
>> It might, for example, define a gui package and gui.Tkinter and gui._tkinter
>> modules, le
Skip Montanaro wrote:
> Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> >> - Flat namespace: Should we tend to a more hierarchic library (e.g.
> >> inet.url, inet.http, inet.nntp)? This would increase clarity when
> >> s
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, inet.nntp)? This would increase clari
While looking at bug #779191, I saw that sys.path's first element
is '' in interactive sessions, but the current dir otherwise. Is this
intentional?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://
Raymond Hettinger wrote:
>> I've seen some systems that solve this problem by allowing users to
> "vote"
>> for favorite bugs... then you can tell the "important" bugs because
> they
>> are more likely to have lots of votes. As I see it, Facundo is using a
>> variant of that system. He is asking wh
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> would anybody mind if I was given permissions on the tracker and CVS,
> for
>> fixing small
>> things like bug #1202475. I feel that I can help you others out a bit
> with
>> this and
>> I promise I won&#x
Hello,
would anybody mind if I was given permissions on the tracker and CVS, for
fixing small
things like bug #1202475. I feel that I can help you others out a bit with this
and
I promise I won't change the interpreter to accept braces...
Reinhold
--
Mail address is perfectly valid!
Guido van Rossum wrote:
> [François Pinard]
>> It happens once in a while that I want to comment out the except clauses
>> of a try statement, when I want the traceback of the inner raising, for
>> debugging purposes. Syntax forces me to also comment the `try:' line,
>> and indent out the lines fo
Aahz wrote:
> On Wed, May 04, 2005, Paul Moore wrote:
>>
>> Yes, that'd do. I can't say I think it would be common, but it's a
>> valid case. And the workaround is the usual messy flag variable:
>>
>> for name in filenames:
>> found = False
>> opening(name) as f:
>> if f.read(2) ==
Tim Peters wrote:
> [Reinhold Birkenfeld]
>> ...
>> I think the behaviour of the "else" clause is much harder to guess,
>> mainly when used with the looping constructs.
>
> No, that's obvious .
OK, I'm persuaded. Well you wield the Force, mas
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might
Ka-Ping Yee wrote:
> Reinhold Birkenfeld wrote:
>> Well, with it you could create suites with _any_ introducing
>> identifier. Consider:
>>
>> with:
>> (...)
>>
>> synchronized:
>> (...)
>>
>> try:
>> (...)
>>
Tim Peters wrote:
> [Guido]
>> I'm +1 on accepting this now -- anybody against?
>
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clau
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than _
Adam Souzis wrote:
> I'm a bit surpised that no one has yet [1] suggested "begin" as a
> keyword instead "block" as it seems to express the intent of blocks
> and is concise and readable. For example, here are the examples in
> PEP 340 rewritten using "begin":
>
> begin locking():
>...
I don
Paul Moore wrote:
> On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>> On May 4, 2005, at 01:57, Paul Moore wrote:
>> >
>> > I can't think of a reasonable condition which wouldn't involve reading
>> > the file - which either involves an inner loop (and we already can't
>> > break out of two
: $Revision: $
Last-Modified: $Date: $
Author: Reinhold Birkenfeld <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 04-May-2005
Post-History:
Abstract
This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-
Guido van Rossum wrote:
>> Another possibility just occurred to me. How about "using"?
>
> Blah. I'm beginning to like block just fine. With using, the choice of
> word for the generator name becomes iffy IMO; and it almost sounds
> like it's a simple renaming: "using X as Y" could mean "Y = X".
Nick Coghlan wrote:
> Guido van Rossum wrote:
> [snip]
>> - I think there's a better word than Flow, but I'll keep using it
>> until we find something better.
>
> How about simply reusing Iteration (ala StopIteration)?
>
>Pass in 'ContinueIteration' for 'continue'
>Pass in 'BreakIterati
Guido van Rossum wrote:
> [Greg Ewing]
>> I like the general shape of this, but I have one or two
>> reservations about the details.
>
> That summarizes the feedback so far pretty well. I think we're on to
> something. And I'm not too proud to say that Ruby has led the way here
> to some extent (e
Nick Coghlan wrote:
> Interestingly, with this approach, "for dummy in my_resource()" would still
> wrap
> the block of code in the entrance/exit code (because my_resource *is* a
> generator), but it wouldn't get the try/finally semantics.
>
> An alternative would be to replace the 'yield None
Guido van Rossum wrote:
>> What was your opinion on "where" as a lambda replacement? i.e.
>>
>> foo = bar(callback1, callback2) where:
>> def callback1(x):
>> print "hello, "
>> def callback2(x):
>> print "world!"
>
> I don't recall seeing this proposed, but I might h
Rodrigo Dias Arruda Senra wrote:
> | > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra
> wrote:
> | > > Edit libwebbrowser.tex as you see fit, then send it to me
> | > > and I'll TeXify it back to you.
> | >
> | >Uploaded to http://python.org/sf/754022 . I am not a n
Ka-Ping Yee wrote:
> On Wed, 23 Mar 2005, Reinhold Birkenfeld wrote:
>> What does you implementation do for this:
>>
>> >>> somevar = False
>> >>> filter(_ and False, numbers)
>
> It fails. (For the same reason that __len__ doesn't work
1 - 100 of 110 matches
Mail list logo
