Stephen J. Turnbull wrote:
> In the meantime, it's better to let people using a competing "standard"
> (even if it's neither very good nor a "real" standard) do their thing
> until they see the light.
It's not even about the people who consume egg-info data seeing the light,
it's about PEP-345 da
Hi there,
I'm going to add my own 2 cents to the discussion as I'm involved in the
matter here at the DZUG conference.
Tarek Ziadé wrote:
> Now you want to publish another metadata format at PyPI ? If PyPI takes
> that direction and adopts, promotes and publishes a standard that is not
> the one
Ben Finney wrote:
> I'd count this as another (minor) point in favour of making the 'fail*'
> methods canonical: the names are consistent *and* gramatically sensible:
-1
I'm surprised nobody (that I've noticed) has brought up the point yet that
test code is a lot easier to read if it makes posit
Jiwon Seo wrote:
> After lambda being made more useful, can I hope that I will be able to use
> lambda with multiple statements? :) Lambdas in Lisp and Python are
> different, but in the usability perspective they don't need to differ too
> much.
I don't think it helps usability much if anonymous
Steven Bethard wrote:
> Guido van Rossum wrote:
>> After so many attempts to come up with an alternative for lambda,
>> perhaps we should admit defeat. I've not had the time to follow the most
>> recent rounds, but I propose that we keep lambda, so as to stop wasting
>> everybody's talent and time
Hi,
I've noticed some behaviour of hasattr when used on properties which I'm
inclined to call a bug, or at least unexpected behaviour:
Python 2.4.2 (#1, Oct 29 2005, 13:11:33)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
[...]
>>> class Foo(object):
... def get(self):
...
Barry Warsaw wrote:
>> x = (if a then
>> b
>> elif c then
>> d
>> else
>> e
>> )
[...]
>
> I guess that's my point. To me, your latter is actually worse than
>
> if a:
> x = b
> elif c:
> x = d
> else:
> x = e
Can't see a difference as far as r
Barry Warsaw wrote:
> I'm not so sure. Once you start writing such a complicated thing, I think
> readability will favor just breaking the code out into traditional
> if-blocks. I'd be happy enough with just a binary condition.
Nothing prevents you from spreading the code over multiple lines, l
Guido van Rossum wrote:
> I think I'd prefer (if then else ) i.e. no colons.
> None of the other expression forms (list comprehensions and generator
> expressions) involving statement keywords use colons.
While I like the looks of the form without colons better, I can't quite
follow this argum
Nick Coghlan wrote:
> I don't think that's a good idea. What would the following monstrosity
> mean?:
>
>if 0:
>print "Ran the if"
>else for item in (1, 2, 3):
>print item
>else try:
>print "No exception here!"
>except:
>pass
>else:
>pri
Ron Adam <[EMAIL PROTECTED]> wrote:
> 1. With an if, if you think in terms of flow testing you get the same
> results as if you look at it in in terms of value testing. Either the
> if-block will execute or the else-block will, but never any part of
> one and then the other. A binary solution
Jack Diederich <[EMAIL PROTECTED]> wrote:
> I can't say I use it for much else, if I really want a default I do
> found = None
> for (thing) in searchlist:
> if (matches(thing)):
> found = None
> break
>
> That could end with 'else: found = None' to assign a default but I
> like the def
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I also notice that your only example is very repetitive, and would be
> better written as a loop, using Python's dynamic nature:
Sure, that's true for the example given. Getting other stuff into a form
which allows for looping may require additional c
Hi,
this is my first message to this list, so let me say hello first.
I want to ask what you think about introducing a keyword 'eltry' which
would be the counterpart of 'elif' for try statements. This had been
suggested before on python-list a couple of years ago by Jonathan
Gardner, but nothing
14 matches
Mail list logo
