"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Actually after all the -1 responses I wasn't going to reconsider this
> for 2.x; maybe for py3k.
I think there may be proposals to review and possibly revise the packing
and import mechanisms for 3.0. So I think y
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> def sortwords(*wordlist, case_sensitive=False):
The rationale for this is pretty obvious. But ...
> The second syntactical change is to allow the argument name to
> be omitted for a varargs argument:
>
>
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Compound names are a sequence of simple names seperated by
separated
> The string and unicode classes will have a class method called
> 'cformat' that does all the actual work of formatting; The
> format() met
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>>
>> Why? Why not let the user type the additional argum
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Talin" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Now, suppose you wanted to have 'key' be
> ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
>> Are you asking why that feature (keyword-only arguments) is desirable?
Joe Smith asked essentially the same question in a different way:
"However, I'm not sure what the use case is for keyword only arguments on
functions that do *not*
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> There are two subproposals: first, keyword-only args after a variable
>> number of positional args, which requires allowing keyword parameter
>>
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
> I clipped it because I couldn't understand your question: "Why" what?
> (the second question only gives "Why not") I then assumed that the
> question must have applied to the text that immediately preceded the
> question - hence that's th
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> which reminds me of the following little absurdity gem from the language
> reference:
>
>The following identifiers are used as keywords of the language, and
>cannot be used as ordinary identifiers. They must be
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> A function/method could have one argument that is obviously needed and
> a whole slew of options that few people care about. For most people,
> the signature they know is foo(arg). It would be nice if all the
> opti
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> which reminds me of the following little absurdity gem from the language
>> ref
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You weren't asking for a reason, you were asking for an example:
No wonder we weren't connecting very well. You somehow have it backwards.
'Why' means "for what reason". But to continue with examples:
my way to
"Benji York" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I've not followed the PEP 3102 (keyword-only arguments) discussion
> closely enough to know if this has been mentioned, but we were
> discussing a need at work today for the ability to enforce position-only
> arguments.
Y
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>BJörn Lindqvist wrote:
>> would have thought that the one obvious way to get rid of
>> the wanky feeling would have been to write:
>> def make_person(name, age, phone, location): ...
>> make_person(name, age, phone, locati
"Mike Orr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
> separate PEP.
I am glad to see this idea resurface and developed. So +1 on an alternate
PEP.
> The main difficulty with this approach is it's so radi
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
>> The dispute is about the sensibility and
>> politeness of requiring a small fixed number of required, no-default
>> args
>> to be passed by name only
>T
"Michael Urman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> At present, Python allows this as a choice.
I made that statement in the context of comparing these syntaxes
def make_person(name,
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Friday 05 May 2006 02:38, Terry Reedy wrote:
> > My point has been that the function writer should not make such a
> > requirement (for four no-defaut, required params) and that p
"Heiko Wundram" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>As I've noticed that I find myself typing the latter quite often
>in code I write, it would only be sensible to add the corresponding
>syntax for the for statement:
>
> for node in tree if node.haschildr
"Facundo Batista" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Just end user experience's two cents here
> (btw, this line is correct at English level?)
Since you asked...your question would be better written "is this line
correct English?"
And the line before, while not form
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> several string methods accepts either strings or objects that support
> the buffer api, and ends up raising a "expected a character buffer
> object" error if you pass in something else. this isn't exactly helpful
> for
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>>> Just end user experience's two cents here
>>> (btw, this line is correct at English level?)
>>
>> Since you asked...your q
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> It looks like there were a lot of additions to the string test suite,
>> that's great. I'm not sure if the other areas touched got similar
>> boosts to their tests. It would be good to upgrade all tests to
>> verify c
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Is there still time for new feature requests in Python 2.5?
> I am missing a isgenerator function in the inspect module. Right now
> I am using
>
> def isgenerator(func):
>return func.func_code.co_flags == 99
>
>Perhaps more people could chime in? Am I being too anal about backward
> >compatibility here?
As a sometimes bug report reviewer, I would like the reported discrepancy
between the public docs and visible code behavior fixed one way or the
other (by changing the docs or code) since that is my w
--
Contributor agreements
--
If you're listed in the `Python acknowledgments`_, and you haven't
signed a `contributor agreement`_, please submit one as soon as
possible. Note that this includes even the folks that have been
around forever -- the PSF would l
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Neal Norwitz gmail.com> writes:
>>
>> > I wonder whether a check shouldn't just return (co_flags & 0x20),
>> > which
>> > is CO_GENERATOR.
>>
>> Makes more sense.
>
> Okay, but my point is that the final user shou
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> No, that check would match generator objects, not generators tout court.
tout court?? is not English or commonly used at least in America
> On a related notes, inspect.isfunction gives True on a generator, such
>
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yep, this is the crux. types.GeneratorType refers to generator objects,
> which in an improper sense are "instances" of a "generator function".
> I.e.
>
> def g(): yield 1 # this is a generator
>
> go = g() # this
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Granted, I hit a couple of web pages while doing this and my spam
>> filter processed my mailbox in the background...
Hardly a setting in which to run comparison tests, seems to me.
> Using the minimum looks like the
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> This is by design.
>
> The intent is that as long as you call something that returns no
> value, your last result is not thrown away. IOW _ is the last result
> that wasn't None.
>
> Please don't change this.
What m
Many math books have an index or glossary of symbols connecting the symbols
used in the text with their meaning in that text. I have often found these
useful.
I believe that people learning and using Python would similarly benefit
from an index to the non-alphabetic symbols (and multi-symbol s
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, Jun 08, 2006 at 12:18:23AM -0400, Terry Reedy wrote:
>> [I just realized that some links need to be within-page rather than to
>> the
>> top of the page and that I can cu
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sunday 11 June 2006 16:26, Sam Ruby wrote:
> > Planet is a feed aggregator written in Python. It depends heavily on
> > SGMLLib. A recent bug report turned out to be a deficiency in sgmllib,
> > and I've submi
"Fabio Zadrozny" <[EMAIL PROTECTED]> wrote in message
>Jython 2.1 on java1.5.0 (JIT: null)
>Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
>win32
Jython 2.1 intends to match Python 2.1, I believe.
Python 2.2, which I still have loaded, matches Python 2.4 in the behavior
"Martin Blais" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Any idea how this idiom could be supported using a more portable
> solution (i.e. how would I make this idiom under Windows, is there
> some equivalent to /dev/null)?
On a DOS/Windows command line, '>NUL:' or '>nu
"Boris Borcic" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>being transformed to profit from simplifications I expected sets to allow.
>There, itemwise augmented assigments in loops very naturally transform to
>wholesale augmented assignments without loops. Except for this wart.
"Boris Borcic" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
>> Your transformation amounted to switching from collection mutation to
>> object rebinding. In Python, that is a crucial difference.
>Ok, that is a crucial difference.
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> SC22WG14? is that some marketing academy? not a very good one,
>> obviously.
>
> http://www.open-std.org/jtc1/sc22/wg14/
>
> Looks like python-dev for C, only with extra servings of international
> bureaucracy and ve
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces
>
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [Giovanni Bajo]
>> Yes but:
>>
> a = []
> for i in range(10):
>> ... a.append(lambda: i)
>> ...
> print [x() for x in a]
>> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>. Do you agree that it would be ideal if the
"Darryl Dixon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Python on Windows. The Python interface to this function is in the C
> code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
> OS system call.
I think Fredrik made two points in this regard. 1) The cu
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'd also be happy with
>
> def __init__(self, self.x, self.y, self.z):
>
> which wouldn't be too different from unpacking tuples
If you are willing to require that the args be passed as a tuple (ext
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thing is, there may be no resource; in my talk at EuroPython:
>
>http://starship.python.net/crew/mwh/recexc.pdf
>
> I used a with statement to establish and dis-establish an error
> handler -- would you call that a
"Darryl Dixon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I'm sorry, I don't seem to have done a very good job at explaining
> the situation. I'll try again:
Actually, I think you did fine the first time, and the second time, and I
see nothing new here. You, like thousan
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Aahz wrote:
>> Hrm. I thought we told people to start with comp.lang.python for
>> porting questions, but I'm happy to be corrected.
>
> I'm unaware of such a policy, but I may have missed the relevant
> discussion
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In general, I find triple-quoted strings to be very handy,
> particularly for standalone scripts. However, the fact that they have
> to be written in the left-hand column to avoid leading whitespace
> really grates, par
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In general, I find triple-quoted strings to be very handy,
> particularly for standalone scripts. However, the fact that they have
> to be written in the left-hand column to avoid leading whitespace
> really grates, par
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Here's the draft PEP I wrote up:
I believe there were some current alternatives and concerns already
expressed that have not been included yet that maybe should be.
Some of your examples look worse than needed by put
"Walter Dörwald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>x = blist()
>x(1)
>with blist(x) as x:
>x(2)
>with blist(x) as x:
> x(3)
>x(4)
>x(5)
>This would create the list:
>[1, [2, [3], 4], 5]
>With the current version of PEP 343, we would either have to us
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Phillip J. Eby wrote:
>> I suggest changing this to something like this:
>>
>> class tag(object):
>> def __init__(self,name):
>> self.name = name
>> def __enter__(self):
>> pri
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> In order to lower the barrier for reporting bugs, writing patches, and
>> handling CVS commits, I am writing up checklists for each and I will
>> put them up on python.org.
>
> -0 on the checklists.
I am more enth
"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 this is rejected--and
> in
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The main outcome of the PEP 343 terminology discussion was some proposed
> documentation I put on the Sourceforge patch tracker ([1]).
Is this a proposal for the Language Reference manual?
> [1] http://www.python.org/s
"Pranav Bagora" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I am getting a permission denied error...
> Please help,
The Python-dev mailing list (or gmane.comp.python.devel newsgroup) is for
development of future Python releases. Please direct help questions to
comp.lang.pyt
"falcon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello python-list,
>
> As I Understood, semantic may be next:
[snip]
This was properly posted to the general Python discussion group/list.
Reposted here, to the Python development list/group, it is offtopic.
If you did not g
"Grégoire Dooms" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>This patch is about to celebrate its second birthday :-)
>What should I do to get it reviewed further ?
The guaranteed-by-a-couple-of-developers way is to review 5 other patches,
post a summary here, and name this as
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> PEP 8 doesn't express any preference between the
>> two forms of raise statements:
>> raise ValueError, 'blah'
>> raise ValueError("blah")
>>
>> I like the secon
> PEP: 349
> Title: Generalised String Coercion
...
> Rationale
>Python has had a Unicode string type for some time now but use of
>it is not yet widespread. There is a large amount of Python code
>that assumes that string data is represented as str instances.
>The long term plan f
> Another fwd, describing how Steve Alexander's group user bazaar.
I found this rather clear and easy to understand even without having
directly used CVS (other than to browse). Some of the automation features
seem useful but I don't know whether they are specific to bazaar. Anyway,
my though
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Except from PEP 7:
>
> "Use ANSI/ISO standard C (the 1989 version of the standard)."
Just checked (P&B, Standard C): only one L allowed, not two. But with C99
compilers becoming more common, accidental usages of
Can str.find be listed in PEP 3000 (under builtins) for removal?
Would anyone really object?
Reasons:
1. Str.find is essentially redundant with str.index. The only difference
is that str.index Pythonically indicates 'not found' by raising an
exception while str.find does the same by anomalousl
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> Yes please. (Except it's not technically
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> FWIW, here is a sample code transformation (extracted from zipfile.py).
> Judge for yourself whether the index version is better:
I am sure that
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
Guido has already approved, but I will try to expl
"FAN" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You know Jython (Java version of Python) has only a stable version of
> 2.1, and two alpha version was release after 3 years.
> So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail
> change list was need, and it's
> I'm not convinced. Where would you ever care about reading a file in
> N-bytes chucks?
This was once a standard paradigm for IBM mainframe files. I vaguely
remember having to specify the block/record size when opening such files.
I have no idea of today's practice though.
Terry J. Reedy
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [M.-A. Lemburg]
>> Also, as I understand Terry's request, .find() should be removed
>> in favor of just leaving .index() (which is the identical method
>> without the funny -1 return code logic).
My proposal is to
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in
> Yes, there is a precise spec and yes it always returns three strings.
While the find/index discussion was about "what is the best way to indicate
'cannot answer'", part of the conclusion is that any way can be awkward.
So I am generally in favo
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> One (1a) is to give an inband signal that is like a normal
>> response except that it is not (str.find returing -1).
>>
>> Python as distri
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote in message
> before, sep, after = s.partition('?')
> ('http://www.python.org', '', '')
>
> before, sep, after = s.rpartition('?')
> ('', '', 'http://www.python.org')
I can also see this as left, sep, right, with the sep not found case
putting al
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'd rather see it reversed from what it is as well. While I don't have
> the
> time myself (and don't consider it a critical issue), I certainly won't
> revert a patch to make the change without good reason. :-)
"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You can do both: make partition() return a sequence with attributes,
> similar to os.stat(). However, I would call the attributes "before",
> "sep", and "after".
One could see that as a special-case back-compatibilit
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>>> You can do both: make partition() return a sequence with
> attributes,
>>> similar to os.stat(). However, I would call the attributes
> "before",
>>> "sep", and "after".
>
>Terry> One could see that as a special-
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> FWIW, after this is over, I'll put together a draft list of these
> principles. The one listed above has served us well. An early draft of
> itertools.ifilter() had an invert flag. The toolset improved when that
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 8/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I think that would be a good idea. Return an honest-to-goodness stat
>> object
>> and also strip the "st_" prefixes removed from the attributes. There's
>> for some use cases, a naive partition-based solution is going to be a
>> lot slower
>> than the old find+slice approach, no matter how you slice, index, or
>> unpack the
>> return value.
The index+slice approach will still be available for such cases. I am sure
we will see relative speed v
"Paul F. Dubois" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Remove the print statementI laughed until my sides hurt. Hello? Try
> dating girls and talking to normal people, geek boys.
>
> We scientists still use these for debugging. We never 'move on' very far
> from the tu
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> With so many people expressing a gut response and not saying what in
> the proposal they don't like, it's hard to even start a response.
> Is it...
For me a bit of several things though with quite variable intensity
"Ron Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> # standard printing
> write.ln(1, 2, 3)
> # print without trailing newline
> write(1, 2, 3)
This violates this design principle:
When there are two options and one is overwhelmingly more common in use (in
this case, with
"Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I take this chance to state my humble opinion. Please keep the print
> function print(), not writeln()! "printing stuff" is everyone's
> favorite anachronistic expression, even though the output doesn't g
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Summarizing, my main problems with print as a statement are the
> transformations -- when print doesn't cut it, you have to switch to
> something entirely different. If it were a function the switch would
> feel much
I consider the current situation to be a consistency feature. To a first
approximation, Python function calls 'pass' objects by name-binding:
param_name_list = arg_object_list
Disabling structure unpacking in this assignment would make the language
slightly more complex. Someone else posted
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In fact, I think Raymond's example is more properly considered an
> argument for adding a conditional expression than for removing the
> current behavior of the and/or shortcut operators; had we had a
> conditional e
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Given the later addition of generator expressions with mandatory
>> parentheses , the mandatory-parentheses version of a con
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I just finished debugging some code that broke after upgrading to
> Python 2.4 (from 2.3). Turns out the code was testing list iterators
> for their boolean value (to distinguish them from None).
This seem unnecessar
"John J Lee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The stricter form where you don't allow 'elif' will get used in more
> restricted circumstances, so gives less encouragement for widespread
> abuse
> of conditional expressions by people who don't like whitespace-based
>
Guido:
When you invited resumed discussion, did you intend to proceed from where
the revised PEP left off (with a few variations on the table), or to start
over from point zero (with potentially anything and everything on the
table). In particular, do we need to rehash the reasons for rejectio
"Christian Stork" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> On Tue, Aug 30, 2005 at 12:49:26PM +1200, Greg Ewing wrote:
>> A more descriptive name than 'partition' would be 'split_at'.
>
> 'split_at' is really what's happening. (I came up with it independently
> of Greg, if t
"Alexander Myodov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Why the variables defined inside "for"/"while"/"if" statements
> (including loop variables for "for") are visible outside this scope?
Questions about why Python is the way it is belong on comp.lang.python, the
gene
"Bill Janssen" <[EMAIL PROTECTED]> wrote in message
news:05Sep22.141518pdt."58617"@synergy1.parc.xerox.com...
> Sokolov Jura writes:
>> It is so simple to write application server in Python.
>> It is so difficult to make it scallable in CPython.
>> CPython will not be wide popular without real mu
>> Need I continue? Or is the dead still dead?
Since 'a if b else c' is not obviously dead, I will summarize my argument
against it thusly:
It is ambiguous to people because it is can be parsed (by people, who are
not automatons) as either '(a if) b (else c)' or 'a (if b) (else c)'. The
firs
"Jim Jewett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
A nice summary, to which I will add just a little.
> For a conditional expression, I think the choices are really down
> to the following, which was already way too much freedom last
> (http://www.python.org/peps/pep-0308.
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>
>> Many people, perhaps most, including me, read
>>
>> exp1 if exp2 else exp3 # as
>> cond if etrue else efalse # in direct analogy with
>> cond
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I am reminded of how some people seem to react to fingernails on a
blackboard, while the screech is just another noise to me, except that I am
in the opposite position with respect to a if b else c.
> Does it help if
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> After all there's nothing wrong with and/or.
This is one reason 'no addition' got a relatively high rank in the vote.
Examples...
> telnet~1.py:'DO' if cmd == DO else 'DONT',
versuscmd =
>> http://effbot.org/lib/os.path.join
On this page, 8 of 30 entries have a 'new in' comment. For anyone with no
interest in the past, these constitute noise. I wonder if for 3.0, the
timer can be reset and the docs start clean again. To keep them backwards
compatible, they would also have to
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Michael Hudson wrote:
>> I think 2.58 actually had a brown-paper-bag release style bug, but
>> 2.59 has been out for ages now. If we were prepared to
>> AC_PREREQ(2.59), I think this whole issue could go away.
>
>
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hell no. If I want to write a real function, I already have perfectly
> good
> syntax for that in the form of a def statement. I want to *increase* the
> conceptual (and pedagogical) difference between deferred expressi
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Note that this is the opposite of normal Python policy: Python does not
> attempt to create cross-platform abstractions, but instead chooses to
> expose platform differences.
I had the opposite impression about Python
2401 - 2500 of 2504 matches
Mail list logo
