On Tue, Jun 2, 2015 at 5:19 PM, Steven D'Aprano
wrote:
> but that's not what my second example says. Look closely, and consider that
> sometimes we write "Mark's hat" and sometimes "the hat of Mark".
... and sometimes "the hat Mark's talking through", which appears to
put "hat" and "Mark's" the o
On Tuesday 02 June 2015 07:45, TheDoctor wrote:
> On Wednesday, September 11, 2013 at 6:40:22 PM UTC-5, Steven D'Aprano
> wrote:
>> On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote:
>>
>> > 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Oh? How abou
On Tuesday 02 June 2015 10:10, TheDoctor wrote:
> On Friday, September 13, 2013 at 12:08:04 AM UTC-5, Steven D'Aprano wrote:
Mark, you are digging up a conversation from nearly two years ago.
Seriously?
>> It makes no difference whether I write:
>>
>> atoms -> stars -> galaxies
>>
>> or
On Friday, September 13, 2013 at 12:08:04 AM UTC-5, Steven D'Aprano wrote:
> On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote:
> which would be silly. Only somebody who doesn't understand how
> inheritance works in Python would do that. There's simply no need for it,
> and in fact it would
On Wednesday, September 11, 2013 at 6:40:22 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote:
>
> > 1) It tried to make Object the parent of every class.
>
> Tried, and succeeded.
Oh? How about:
class superdict(dict):
"""I'm going to extend the
On 2013-09-18, wxjmfa...@gmail.com wrote:
1and 0
> 0
'a'or 1
> 'a'
5if True else 999
> 5
Curse you, FSR!
Oh, wait...
--
Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
>>> 1and 0
0
>>> 'a'or 1
'a'
>>> 5if True else 999
5
jmf
--
https://mail.python.org/mailman/listinfo/python-list
On Sep 18, 2013, at 11:12 AM, Chris Angelico wrote:
> On Thu, Sep 19, 2013 at 1:08 AM, Neil Cerutti wrote:
>> On 2013-09-18, Chris Angelico wrote:
>>> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti wrote:
There's lots of poetry with significant indentation, though.
Imbuing the shape
On Thu, Sep 19, 2013 at 1:08 AM, Neil Cerutti wrote:
> On 2013-09-18, Chris Angelico wrote:
>> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti wrote:
>>> There's lots of poetry with significant indentation, though.
>>> Imbuing the shape of the text on the page with significance is a
>>> thing.
>>
On 2013-09-18, Chris Angelico wrote:
> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti wrote:
>> There's lots of poetry with significant indentation, though.
>> Imbuing the shape of the text on the page with significance is a
>> thing.
>
> And you can do that with C code, too. Doesn't mean that
>
On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti wrote:
> There's lots of poetry with significant indentation, though.
> Imbuing the shape of the text on the page with significance is a
> thing.
And you can do that with C code, too. Doesn't mean that indentation is
important to C; it means that you
On 2013-09-13, Chris Angelico wrote:
> On Sat, Sep 14, 2013 at 5:32 AM, Terry Reedy wrote:
>> Poetry, including that in English, often *is* concerned with formatting.
>> Code is more like poetry than prose.
>>
>>
>>> You can take this
>>> paragraph of text, unwrap it, and then reflow it to any wi
Op 15-09-13 04:37, Mark Janssen schreef:
Ha, "only the direction reversed". That little directionality that
you're passing by so blithely is the difference between whether you're
talking about galaxies or atoms.
It makes no difference whether I write:
atoms -> stars -> galaxies
or
Really? Are you saying you (and the community at-large) always derive
from Object as your base class?
>>>
>>> Not directly, that would be silly.
>>
>> Silly? "Explicit is better than implicit"... right?
>
> If I'm inheriting from str, I inherit from str explicitly:
>
> class MyStr(str):
Chris Angelico wrote:
> Making line breaks significant usually throws people. It took my
> players a lot of time and hints to figure this out:
> http://rosuav.com/1/?id=969
fukin' Gaston!
--
By ZeD
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Sep 13, 2013 at 4:57 PM, Chris Angelico wrote:
> Evangelical vicar in want of a portable second-hand font. Would
> dispose, for the same, of a portrait, in frame, of the Bishop-elect of
> Vermont.
>
> I think you could quite easily reconstruct the formatting of that,
> based on its interna
On Sat, Sep 14, 2013 at 5:32 AM, Terry Reedy wrote:
> Poetry, including that in English, often *is* concerned with formatting.
> Code is more like poetry than prose.
>
>
>> You can take this
>> paragraph of text, unwrap it, and then reflow it to any width you
>> like, without materially changing m
On 9/13/2013 7:16 AM, Chris Angelico wrote:
On Fri, Sep 13, 2013 at 8:13 PM, Steven D'Aprano
wrote:
On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
Not only that. There are a lot of python code snippets on the net that
for whatever reason lost their indentation. There is no algorithm
Op 13-09-13 12:13, Steven D'Aprano schreef:
> On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
>
>> Op 10-09-13 12:20, Chris Angelico schreef:
>>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano
>>> wrote:
What design mistakes, traps or gotchas do you think Python has?
Gotchas
On Fri, Sep 13, 2013 at 8:13 PM, Steven D'Aprano
wrote:
> On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
>
>> Op 10-09-13 12:20, Chris Angelico schreef:
>>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano
>>> wrote:
What design mistakes, traps or gotchas do you think Python has?
>
On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
> Op 10-09-13 12:20, Chris Angelico schreef:
>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano
>> wrote:
>>> What design mistakes, traps or gotchas do you think Python has?
>>> Gotchas are not necessarily a bad thing, there may be good re
On Fri, Sep 13, 2013 at 3:08 PM, Steven D'Aprano
wrote:
> For example, take intersection of two sets s and t. It is a basic
> principle of set intersection that s&t == t&s.
Note that, while this is true, the two are not actually identical:
>>> set1 = {0,1,2}
>>> set2 = {0.0,1.0,3.0}
>>> set1&set
Op 10-09-13 12:20, Chris Angelico schreef:
> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has? Gotchas
>> are not necessarily a bad thing, there may be good reasons for it, but
>> they're surprising.
>
> Significant indentat
On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote:
>>> Really? Are you saying you (and the community at-large) always derive
>>> from Object as your base class?
>>
>> Not directly, that would be silly.
>
> Silly? "Explicit is better than implicit"... right?
If I'm inheriting from str, I i
>> Really? Are you saying you (and the community at-large) always derive
>> from Object as your base class?
>
> Not directly, that would be silly.
Silly? "Explicit is better than implicit"... right?
>> But wait is it the "base" (at the bottom of the hierarchy) or is it the
>> "parent" at the to
On 12.09.2013 01:27, Chris Angelico wrote:
> On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother wrote:
>> 3. The default return value of methods is None instead of self.
>> If it was self, it would be possible to chain method calls (which
>> is called a cascade in smalltalk).
>>
>>
>>
On 9/12/13 2:24 PM, Markus Rother wrote:
On 10.09.2013 08:09, Steven D'Aprano wrote:
What design mistakes, traps or gotchas do you think Python has? Gotchas
are not necessarily a bad thing, there may be good reasons for it, but
they're surprising.
I have one more:
Dictionaries should iterate o
On Fri, Sep 13, 2013 at 4:13 AM, Markus Rother wrote:
> On 12.09.2013 01:27, Chris Angelico wrote:
>> On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother
>> wrote:
>>> 3. The default return value of methods is None instead of self.
>>> If it was self, it would be possible to chain method call
On 9/12/2013 2:24 PM, Markus Rother wrote:
Dictionaries should iterate over their items instead of their keys.
Dictionaries *can* iterate by keys, values, or items. You would prefer
that the default iteration be by items rather than keys.
Looking forward to contrary opinions.
When the is
On 11.09.2013 23:15, Ethan Furman wrote:
> On 09/11/2013 01:41 PM, Markus Rother wrote:
>> >>> () == []
>> False
>>
>> But:
>>
>> >>> bool(().__eq__([]))
>> True
>
> This is not a trap, this is simply the wrong way to do it. The magic
> methods (aka dunder methods) are th
On 2013-09-12, Markus Rother wrote:
> On 11.09.2013 23:15, Ethan Furman wrote:
>> On 09/11/2013 01:41 PM, Markus Rother wrote:
>>> >>> () == []
>>> False
>>>
>>> But:
>>>
>>> >>> bool(().__eq__([]))
>>> True
>>
>> This is not a trap, this is simply the wrong way to do it.
On 2013-09-11, Ben Finney wrote:
> "Prasad, Ramit" writes:
>
>> This email is confidential and subject to important disclaimers and
>> conditions including on offers for the purchase or sale of securities,
>> accuracy and completeness of information, viruses, confidentiality,
>> legal privilege,
On 2013-09-12, Markus Rother wrote:
> On 10.09.2013 08:09, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has? Gotchas
>> are not necessarily a bad thing, there may be good reasons for it, but
>> they're surprising.
>
> I have one more:
>
> Dictionaries shou
On 09/12/2013 10:51 AM, Markus Rother wrote:
On 11.09.2013 23:15, Ethan Furman wrote:
On 09/11/2013 01:41 PM, Markus Rother wrote:
>>> () == []
False
But:
>>> bool(().__eq__([]))
True
This is not a trap, this is simply the wrong way to do it. The magic
methods
On 10.09.2013 08:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
I have one more:
Dictionaries should iterate over their items instead of their key
On Wed, 11 Sep 2013 00:53:53 +, Steven D'Aprano wrote:
> and most routines that handle file names accept either text strings or
> bytes strings:
I was going to say "that just leaves environ and argv". But I see that
os.environb was added in 3.2. Which just leaves argv.
--
https://mail.pyth
On 12 September 2013 10:27, Skip Montanaro wrote:
>
> More likely, JP Morgan's mail system added that footer to the message
> on the way out the virtual door. My recommendation would be to not
> post using your company email address. Get a free email address.
It wouldn't surprise me if JPMorgan w
More likely, JP Morgan's mail system added that footer to the message
on the way out the virtual door. My recommendation would be to not
post using your company email address. Get a free email address.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
By the way, please keep attributions for those you are quoting. It is
rude otherwise.
On Wed, 11 Sep 2013 17:49:09 -0700, Mark Janssen wrote:
>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Really? Are you saying you (and the community at-large) alway
On Wed, 11 Sep 2013 22:43:20 -0400, Roy Smith wrote:
> In article <523127e2$0$29988$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> just 3 bits if you only cared about decimal digits.
>
> That's a neat trick.
Well obviously it's compressed.
:-)
Sorry for the typo, I mean
On 11 September 2013 11:38, Burak Arslan wrote:
> On 09/10/13 09:09, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has?
>
> My favourite gotcha is this:
>
> elt, = elts
>
> It's a nice and compact way to do both:
>
> assert len(elts) == 0
> elt =
On Thu, Sep 12, 2013 at 12:43 PM, Roy Smith wrote:
> In article <523127e2$0$29988$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> just 3 bits if you only cared about decimal digits.
>
> That's a neat trick.
It is! It's one of the fancy things we can do in the Land Downunder.
In article <523127e2$0$29988$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> just 3 bits if you only cared about decimal digits.
That's a neat trick.
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, 12 Sep 2013 10:31:26 +1000, Chris Angelico wrote:
> On Thu, Sep 12, 2013 at 10:25 AM, Mark Janssen
> wrote:
>> Well now, this is an area that is not actually well-defined. I would
>> say 16-bit Unicode is binary data if you're encoding in base 65,536,
>> just as 8-bit ascii is binary da
On Thu, Sep 12, 2013 at 10:49 AM, Mark Janssen
wrote:
>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Really? Are you saying you (and the community at-large) always derive
> from Object as your base class?
Uhh, yep? It kinda happens automatically for me:
On 9/11/2013 8:49 PM, Mark Janssen wrote:
1) It tried to make Object the parent of every class.
Tried, and succeeded.
Really? Are you saying you (and the community at-large) always derive
from Object as your base class?
The name is 'object', and yes, everyone does it because it is automati
Mark Janssen writes:
> > Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> > word "encod[e]", which is the standard way to turn Unicode into bytes
> > anyway. No, a Unicode string is a series of codepoints - it's most
> > similar to a list of ints than to a stream of bytes.
>
On Wed, Sep 11, 2013 at 5:37 PM, Mark Janssen wrote:
>> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
>> word "encod[e]", which is the standard way to turn Unicode into bytes
>> anyway. No, a Unicode string is a series of codepoints - it's most
>> similar to a list of ints t
>> 1) It tried to make Object the parent of every class.
>
> Tried, and succeeded.
Really? Are you saying you (and the community at-large) always derive
from Object as your base class?
>> No one's close enough to God to make that work.
>
> Non-sequitor. One doesn't need to be close to a deity to
On Thu, Sep 12, 2013 at 10:37 AM, Mark Janssen
wrote:
>> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
>> word "encod[e]", which is the standard way to turn Unicode into bytes
>> anyway. No, a Unicode string is a series of codepoints - it's most
>> similar to a list of ints
> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> word "encod[e]", which is the standard way to turn Unicode into bytes
> anyway. No, a Unicode string is a series of codepoints - it's most
> similar to a list of ints than to a stream of bytes.
Okay, now you're in blah, blah
>> Why is this so difficult?
>> Add a Graph class to the collections module (networkx is quite good)
>> and simply check for circular imports.
>
> Er? That doesn't address the task of importing a module from a source
> code file given its path on the filesystem.
That's true, I guess was hooked on
On Thu, Sep 12, 2013 at 10:25 AM, Mark Janssen
wrote:
>>> On Tue, 10 Sep 2013, Ben Finney wrote:
>>> > The sooner we replace the erroneous
>>> > “text is ASCII” in the common wisdom with “text is Unicode”, the
>>> > better.
>>>
>>> I'd actually argue that it's better to replace the common wisdo
>> On Tue, 10 Sep 2013, Ben Finney wrote:
>> > The sooner we replace the erroneous
>> > “text is ASCII” in the common wisdom with “text is Unicode”, the
>> > better.
>>
>> I'd actually argue that it's better to replace the common wisdom with
>> "text is binary data, and we should normally look a
On 9/11/2013 7:19 PM, Ben Finney wrote:
Er? That doesn't address the task of importing a module from a source
code file given its path on the filesystem.
Other languages have the equivalent of ‘include "/path/to/file.py"’,
Some includes are equivalent to
with open("/path/to/file.py") as f:
On Wed, 11 Sep 2013 22:41:50 +0200, Markus Rother wrote:
> 2. Reduce removed from standard library. That is a big fail, in my
> opinion.
And Guido's Time Machine strikes again!
py> from functools import reduce
py> reduce
[...]
> 4. As has been mentioned already, some built-in
On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote:
> 1) It tried to make Object the parent of every class.
Tried, and succeeded.
> No one's close enough to God to make that work.
Non-sequitor. One doesn't need to be close to a deity to have a single
root of the object hierarchy.
> 2)
Mark Janssen writes:
> > * Imports are fiendishly complex, hidden below deceptively simple
> > syntax.
> >
> > It's a reasonable expectation that one can import a module from a
> > source code file given its path on the filesystem, but this turns out
> > to be much more complicated than i
On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother wrote:
> 3. The default return value of methods is None instead of self.
> If it was self, it would be possible to chain method calls (which
> is called a cascade in smalltalk).
>
>
> >>> lst = []
> >>> lst.append(1).append(2).appe
"Prasad, Ramit" writes:
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of securities,
> accuracy and completeness of information, viruses, confidentiality,
> legal privilege, and legal entity disclaimers, available a
Wayne Werner writes:
> On Tue, 10 Sep 2013, Ben Finney wrote:
> > The sooner we replace the erroneous
> > “text is ASCII” in the common wisdom with “text is Unicode”, the
> > better.
>
> I'd actually argue that it's better to replace the common wisdom with
> "text is binary data, and we should
Mark Janssen wrote:
> 1) It tried to make Object the parent of every class. No one's close
> enough to God to make that work.
> 2) It didn't make dicts inherit from sets when they were added to Python.
> 3) It used the set literal for dict, so that there's no obvious way to
> do it. This didn't g
On 09/11/2013 01:41 PM, Markus Rother wrote:
4. As has been mentioned already, some built-in functions do magic
stuff behind the scenes:
That's why they're called magic methods. ;)
>>> () == []
False
But:
>>> bool(().__eq__([]))
True
This is not a tra
1) It tried to make Object the parent of every class. No one's close
enough to God to make that work.
2) It didn't make dicts inherit from sets when they were added to Python.
3) It used the set literal for dict, so that there's no obvious way to
do it. This didn't get changed in Py3k.
4?) It all
Hello all,
Thanks for this thread. Here are my two cents...
On 10.09.2013 08:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
"""
1. Occas
> * Imports are fiendishly complex, hidden below deceptively simple
> syntax.
>
> It's a reasonable expectation that one can import a module from a
> source code file given its path on the filesystem, but this turns out
> to be much more complicated than in many other languages.
Why is thi
On 09/11/13 17:52, Ethan Furman wrote:
> On 09/11/2013 03:38 AM, Burak Arslan wrote:
>> On 09/10/13 09:09, Steven D'Aprano wrote:
>>> What design mistakes, traps or gotchas do you think Python has?
>>
>> My favourite gotcha is this:
>>
>> elt, = elts
>>
>> It's a nice and compact way to do bot
On 09/11/2013 03:38 AM, Burak Arslan wrote:
On 09/10/13 09:09, Steven D'Aprano wrote:
What design mistakes, traps or gotchas do you think Python has?
My favourite gotcha is this:
elt, = elts
It's a nice and compact way to do both:
assert len(elts) == 0
Perhaps you meant 'assert
On Thu, Sep 12, 2013 at 12:32 AM, Neil Cerutti wrote:
> On 2013-09-11, Burak Arslan wrote:
>> My favourite gotcha is this:
>>
>> elt, = elts
>>
>> It's a nice and compact way to do both:
>>
>> assert len(elts) == 0
>> elt = elts[0]
>
> I'm confused. Your rewrite looks like an assertio
On 2013-09-11, Burak Arslan wrote:
> On 09/10/13 09:09, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has?
>
> My favourite gotcha is this:
>
> elt, = elts
>
> It's a nice and compact way to do both:
>
> assert len(elts) == 0
> elt = elts[0]
I'm
On 11/9/2013 07:42, Wayne Werner wrote:
> On Tue, 10 Sep 2013, Ben Finney wrote:
>> The sooner we replace the erroneous
>> “text is ASCII” in the common wisdom with “text is Unicode”, the
>> better.
>
> I'd actually argue that it's better to replace the common wisdom with
> "text is binary dat
On Tue, 10 Sep 2013, Ben Finney wrote:
The sooner we replace the erroneous
“text is ASCII” in the common wisdom with “text is Unicode”, the
better.
I'd actually argue that it's better to replace the common wisdom with
"text is binary data, and we should normally look at that text through
U
On 09/10/13 09:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has?
My favourite gotcha is this:
elt, = elts
It's a nice and compact way to do both:
assert len(elts) == 0
elt = elts[0]
but it sure looks strange at first sight. As a bonus, it
On Wed, Sep 11, 2013 at 11:46 AM, Chris Rebert wrote:
> * The value of the loop variable at call-time for functions defined
> within a loop trips people up.
Related: The confusion of 'with' vs __del__ vs del wrt open files etc.
Using 'with' does not guarantee the object's destruction, but the
des
* No explicit variable declarations (modulo `global`+`nonlocal`) means
that variable name typos can't be reliably detected at compile-time.
* The value of the loop variable at call-time for functions defined
within a loop trips people up.
* No self-balancing tree datatype of any kind is included in
On Wed, 11 Sep 2013 01:03:48 +0100, Nobody wrote:
> On Tue, 10 Sep 2013 17:07:09 +1000, Ben Finney wrote:
>
>> * Python requires every programmer to know, or quickly learn, the
>> basics
>> of Unicode: to know that text is not, and never will be again,
>> synonymous with a sequence of bytes.
On Tue, 10 Sep 2013 17:07:09 +1000, Ben Finney wrote:
> * Python requires every programmer to know, or quickly learn, the basics
> of Unicode: to know that text is not, and never will be again,
> synonymous with a sequence of bytes.
If only the Python developers would learn the same lesson ..
On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
Significant indentation. It gets someone every day, it seems.
The fact
Op 10-09-13 08:09, Steven D'Aprano schreef:
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of
> Perl":
>
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
>
>
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, t
encountering the problem.
* Somewhat related, and not really part of language design: The import
mechanism and the packaging tools are woefully behind the state of the
art in getting applications and their libraries to cooperate with
operating system package management.
This has the te
No exactly bad, but can suprise
>>> foo=([],)
>>> foo[0] += ['bar']
Traceback (most recent call last):
File "", line 1, in
TypeError: 'tuple' object does not support item assignment
>>> foo
(['bar'],)
Dne úterý, 10. září 2013 8:09:25 UTC+2 Steven D'Aprano napsal(a):
> Some time ago, Tom Chri
Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of
Perl":
http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
What design mistakes, traps or gotchas do you think Python has? Gotchas
are not necessarily a bad thing, there may be good reasons for it, but
they're surprising.
T
Opened a ticket for this and attached a patch. (experimental)
http://bugs.python.org/issue5736
On Fri, Apr 10, 2009 at 8:39 AM, "Martin v. Löwis" wrote:
I assumed there were some decisions behind this, rather than it's just
not implemented yet.
>>> I believe this assumption is wrong - i
>>> I assumed there were some decisions behind this, rather than it's just
>>> not implemented yet.
>> I believe this assumption is wrong - it's really that no code has been
>> contributed to do that.
>
> But doesn't the issue at http://bugs.python.org/issue662923 imply that
> there *was* suitable
"Martin v. Löwis" wrote:
>> I assumed there were some decisions behind this, rather than it's just
>> not implemented yet.
>
> I believe this assumption is wrong - it's really that no code has been
> contributed to do that.
But doesn't the issue at http://bugs.python.org/issue662923 imply that
the
> I assumed there were some decisions behind this, rather than it's just
> not implemented yet.
I believe this assumption is wrong - it's really that no code has been
contributed to do that.
For gdbm, you can also use the firstkey/nextkey methods.
Regards,
Martin
--
http://mail.python.org/mailma
Joshua> Why not
Joshua> for key in d.keys():
Joshua> print key
Joshua> That worked for me.
Time & space. One motivation for using dbm files is to write large (huge,
in fact) mappings to disk. Simply reconstituting the entire set of keys may
consume a lot of time (they must
keys() returns a list and my question was not about "how to" but more
like "why"...
I assumed there were some decisions behind this, rather than it's just
not implemented yet.
Best,
On Friday, April 10, 2009, Joshua Kugler wrote:
> Akira Kitada wrote:
>
>> The loop has to be:
>> """
> k = d.f
Akira Kitada wrote:
> The loop has to be:
> """
k = d.firstkey()
while k != None:
> ...print k
> ...k = d.nextkey(k)
> key2
> key1
> """
Why not
for key in d.keys():
print key
That worked for me.
j
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I was wondering why *dbm modules in Python do not give us an iterable interface?
Take a look at an example below
"""
# Python 2.6
>>> import gdbm
>>> d = gdbm.open("spam.db", "n")
>>> d["key1"] = "ham"
>>> d["key2"] = "spam"
>>>
>>> for k in d:
... print k
...
Traceback (most recent call
guthrie wrote:
> I'm pretty new to Python, and trying to parse the grammar.
>
> Q: What is the scope of the testlist in a list_for?
>
> For example;
> Instead of;
> for x in [ x in dict if dict[x]=="thing" ]:
> in this:
> for x in dict and dict[x]=="thing":
> x is undefined.
In the abo
Larry Bates wrote:
> First things first:
>
> Don't name a variable "dict" because if you do it shadows
> the built in dict function (same goes for list, str, ...).
> This WILL bite you later, so start now by not naming
> variables by any built in names.
-- Thanks, got it!
>
> Now to your quest
guthrie wrote:
> I'm pretty new to Python, and trying to parse the grammar.
>
> Q: What is the scope of the testlist in a list_for?
>
> For example;
> Instead of;
> for x in [ x in dict if dict[x]=="thing" ]:
> in this:
> for x in dict and dict[x]=="thing":
> x is undefined.
>
> And wh
First things first:
Don't name a variable "dict" because if you do it shadows
the built in dict function (same goes for list, str, ...).
This WILL bite you later, so start now by not naming
variables by any built in names.
Now to your question:
for x in : requires be an iterable
(e.g. list, tup
I'm pretty new to Python, and trying to parse the grammar.
Q: What is the scope of the testlist in a list_for?
For example;
Instead of;
for x in [ x in dict if dict[x]=="thing" ]:
in this:
for x in dict and dict[x]=="thing":
x is undefined.
And why doesn't this work:
for x in
Fredrik Lundh wrote:
> "Bryan" wrote:
>
>>> and how do you make sure that everything subclasses this base class ?
>> in this hypothetical case, i was assuming len() would be put in object and
>> every
>> class subclasses object implicitly or explicitly (ie, new style classes
>> only).
>> if it w
> >>> isinstance(1, object)
> True
>
> What's 1 . len() ?
That's easy!
since 1 is actually syntactic sugar for set([set([])]), clearly 1.len()
== 1.
;-)
v.
(actually, make that frozenset([frozenset([])])...)
--
http://mail.python.org/mailman/listinfo/python-list
Bryan wrote:
> Fredrik Lundh wrote:
>
>>Bryan wrote:
>>
>>
>>>could you get the same result by putting these methods in base
>>
>> > class object that everything subclasses?
>>
>>and how do you make sure that everything subclasses this base class ?
>>
>>
>>
>
> in this hypothetical case, i was as
"Bryan" wrote:
>> and how do you make sure that everything subclasses this base class ?
>
> in this hypothetical case, i was assuming len() would be put in object and
> every
> class subclasses object implicitly or explicitly (ie, new style classes only).
> if it was done that way, would len(obj)
Fredrik Lundh wrote:
> Bryan wrote:
>
>> could you get the same result by putting these methods in base
> > class object that everything subclasses?
>
> and how do you make sure that everything subclasses this base class ?
>
>
>
in this hypothetical case, i was assuming len() would be put in
1 - 100 of 165 matches
Mail list logo
